1分で読了エンジニアリング

SentryとDatadogを使った短縮リンクの監視

4xx/5xxリダイレクトイベントとエッジレイテンシp99をSentryにissueとして、Datadogにメトリクスとして送信する方法。サンプルダッシュボードとアラート閾値。

Marius Voß
DevRel · edge infra
短縮リンクの監視シグナルがSentryとDatadogのダッシュボードに送られる様子を示した図

Instagramキャンペーンの配信中に短縮リンクが30秒間5xxを返し続けると、コホートの約4〜7%を失います。ほとんどのエンジニアリングチームは翌朝、誰かがSlackのスクリーンショットを貼って初めて気づきます。このガイドは、Ellidoで使っている2つのツール - issueにはSentry、メトリクスにはDatadog - を使ってリダイレクト障害を60秒以内に検知するためのプレイブックです。月間約2億4000万件のリダイレクトをp99 13msで提供する自社エッジPOPで実際に使っている構成です。

一言で言うと:Sentryはリダイレクトにおいて1つのことが得意で、それは「壊れた送信先ごとに1つのissue、そこにヒットしたslugの一覧付き」です。Datadogはその直交する役割 - 時系列データ - を担います。両方が必要で、Ellidoはネイティブに両方に送信します。Sentryは現在Beta(DSNを貼るだけで完了)、Datadogは専用メトリクスコレクター付きでLiveです。以下では、どのシグナルが重要か、Sentry連携の内部動作、そしてリダイレクト正常性のDatadogダッシュボードが実際に何を含むべきかを解説します。

リダイレクト監視で重要なシグナル

何かを設定する前に、本当に何を重視するかを決めましょう。リダイレクト監視はフルAPMよりも限定的な問題で、シグナルセットは小さいです。4つのシグナルで実際のインシデントの約95%をカバーできます。

4xxリダイレクトイベント。 短縮リンクの404はほぼ常に3つのうちのいずれかです。slugが削除された、slugが期限切れになった、または誰かがドメインをファジングしています。410は意図的でノイジーなのでアラートから除外します。451(ジオブロック)は集計でのみ興味深いです。イベント単位の4xxボリュームはページングには騒がしすぎます。メトリクスとして扱い、issueとしては扱わないようにしましょう。

5xxリダイレクトイベント。 これはオンコールへの連絡が必要です。5xxはエッジがRedis(L2キャッシュ)に到達できなかった、api-core(オリジンgRPC)に到達できなかった、またはHEADチェック中に送信先URLでDNS障害が発生したことを意味します。それぞれ異なるランブックがあります。api-coreのSentryトランスフォーマーは根本原因にタグを付けるため、issueのタイトルは5xx: redis-timeout (12スラグ影響, 最後の発生14秒前)のようになり、汎用的なInternal Server Errorにはなりません。

エッジレイテンシp99。 キャッシュHITのリダイレクトは3つのPOPのいずれからもp99で15ms未満で提供されるべきです。p99が5分間50msを超え続けた場合にアラートを出します。単一のクエリが遅くても5分間p99を高く保つことはありませんが、Redisレプリカの同期外れならそうなります。レイテンシ予算の詳細はリダイレクトp95を15ms以下にを参照してください。

クリックレート異常とスキャン失敗。 クリックレート異常は遅延警告システムです。キャンペーンが通常4000クリック/時間なのに突然200になった場合、上流で何かが壊れています(広告が不承認になった、QRステッカーが剥がれた、誰かが誤ったリンクを削除した)。スキャン失敗はurl-scannerサービスから来るもので、送信先をマルウェアのスクリーニングします。スキャン失敗の急増は通常、アカウントが侵害されてフィッシングリンクが作成されていることを意味します。

シグナルを適切なツールに振り分ける

すべてのシグナルがすべてのツールに適しているわけではありません。4xxボリュームをissueとしてSentryに送ると、実際の「壊れた送信先」issueがノイズの下に埋もれます。p99レイテンシをアラートとしてSentryに送るのも不自然で、Sentryのアラートシステムは時系列ではなくissueの頻度を中心に構築されています。メンタルモデル:Sentry = 例外、Datadog = メトリクス、Slack = 人間、Linear = フォローアップチケット。

4xx、5xx、レイテンシ、スキャン失敗のシグナルがSentry、Datadog、Slack、Linearに振り分けられるマトリクス

EllidoはXがある場所に送信します。4xxイベントはSentryに送りません。例外ではないからです。すべてのクリックイベントをDatadogに送ることもしません。コストに見合わないからです(Datadogのカスタムメトリクスはユニークなタグのコンビネーションごとに課金され、slug x リージョン x ティアのカーディナリティは中規模ワークスペースで月$4000になります)。上記の分割は9ヶ月間システムを内部運用した結果たどり着いたものです。

Sentry連携:DSNの貼り付けとエンベロープトランスフォーマー

EllidoのSentry統合はBetaですが機能的には完成しています。セットアップは3クリックです。/integrationsに行ってSentryを見つけ、DSNを貼り付け、転送するイベントタイプを選択します。DSNが唯一のシークレットです。ADR-0036に従いエンベロープ暗号化(KMS-wrapped)でPostgresに保存するため、DBadminでも平文では読めません。

内部で起きていること:api-coreには内部イベントバス(Redpandaトピックredirect.errors)を購読し、マッチするイベントをSentryエンベロープにパッケージするwebhookトランスフォーマーがあります。エンベロープフォーマットはSentryのEnvelope仕様に記載されています - JSONヘッダー行、JSONアイテムヘッダー、JSONアイテムペイロードを改行で区切ったHTTP POSTです。リクエストパスにSentry SDKはありません。これによりエッジコード(services/edge-redirect)を小さく保ち、ホットパスへの依存を避けています。

トランスフォーマーは3つの有用なことをします。

フィンガープリンティング。 Sentryはフィンガープリントでイベントをグループ化します。単純なフィンガープリントはすべての5xxを1つの巨大なissueにまとめてしまい、役に立ちません。私たちのトランスフォーマーはerror_class:destination_hostでフィンガープリントを作成するため、acme.comへのリンクのRedisタイムアウトとglobex.comへのリンクのRedisタイムアウトは別々のissueになります。これにより「壊れた送信先1つ = issue1つ」が実際に成立します。

Slugの集約。 各Sentryイベントは影響を受けた最初の50 slug、ワークスペースID、リダイレクトドメインを列挙したtagsブロックを持ちます。800のslugが1つの送信先を共有していてその送信先がDNS NXDOMAINを返し始めると、800の個別アラートではなく、slugs_affected: 800と50のサンプルを持つ1つのissueが表示されます。

ワークスペースごとのレート制限。 不具合のあるキャンペーンを運用しているワークスペースは60秒で10,000件の5xxを生成することがあります。Sentryはそれをすべて受け入れて請求します。トランスフォーマーはワークスペースごとに毎分50エンベロープに制限し、残りを件数付きの単一の「suppressed」イベントにまとめます。顧客が400万件の短縮リンクを503を返し始めたドメインに向けたときに痛い目を見て学びました。

Ellidoのトランスフォーマーを使わずに自分でインジェストを処理したい場合は、オブザーバビリティドキュメントに代替パスが記載されています:webhookイベントバスを購読して自分のインフラでイベントをSentryエンベロープに変換します。ほとんどのチームはそこまでしません。トランスフォーマーは自分で構築するより使う方が速いです。

「issue」として表示されるものについての注記:SentryのUIは各グループ化イベントをスパークライン、サンプルイベント、タグ一覧を持つissueカードとして扱います。リダイレクトエラーで最も役立つタグはcache_result(HIT、MISS、BYPASS)です。cache_result: BYPASSの5xxの波が見えたら、チームの誰かがテスト用にキャッシュバイパスを強制するデプロイをして戻し忘れた可能性があります。実際にあった話で、この1年で2回起きています。

Datadog連携:メトリクスコレクターとダッシュボード

DatadogはLiveです。こちらも3クリックですが、アーキテクチャが異なります。イベントごとのトランスフォーマーではなく、api-core側でメトリクスコレクターを実行し、リダイレクトテレメトリをDatadogのメトリクスフォーマットに集約して、DatadogのカスタムメトリクスAPI経由で10秒ごとにバッチ送信します。コレクターは事前集約するため、生のイベントを送信することはありません。カスタムメトリクスのカーディナリティを低く保ち、Datadog請求を管理可能な範囲に収めます。

デフォルトで送信するメトリクス:

  • elido.redirect.count - カウンター、domain、tier、region、cache_result、status_class(2xx/3xx/4xx/5xx)でタグ付け
  • elido.redirect.latency.ms - ディストリビューション、domain、tier、region、cache_resultでタグ付け
  • elido.click.count - カウンター、domain、tier(click-ingester境界で重複除外済み)でタグ付け
  • elido.scanner.failure.count - カウンター、reason(malware、phishing、expired_cert、dns_nxdomain)でタグ付け

タグがレバーです。「FRAでのlink.acme.comの過去4時間のp99レイテンシ」を1行のクエリで表示できます。ドメインごとにダッシュボードを事前に作る必要はありません。メトリクスリファレンスとタグ分類については/integrations/datadogを参照してください。

リージョン別p99レイテンシ、ドメイン別エラーレート、ティア別クリックボリューム、壊れたリダイレクト数を示す4パネルのDatadogダッシュボードのモックアップ

上記の4つのパネルが自社NOCの画面に表示しているものです。日々のオンコールビューをカバーします。リージョン別エッジレイテンシp99 はPOPレベルの退行を検知します(Hetzner FRAの不調はOVH SGPの不調とは見え方が異なり、並べて確認できます)。ドメイン別エラーレートTop 10 はノイジーな顧客を浮かび上がらせます。acme.comが8%の5xxで他全員が0.02%なら、Ellidoの問題ではなくacmeの問題です。ティア別クリックボリュームティア分離のf/s/b、それぞれfree、starter、business)はトラフィックスパイクが有料テナントからか、レート制限すべきフリーティアのキャンペーンからかを示します。過去24時間の壊れたリダイレクト数 はクロージング指標で、4xxを返したリダイレクトは24時間以内に修正されるか、期限切れで削除されるべきです。自動修正パスはリンク劣化防止を参照してください。

推奨アラート閾値(これらが私たちのデフォルトです。ワークスペースごとに上書きできます):

  • elido.redirect.latency.ms p99 > 50ms 5分継続 - オンコール呼び出し

  • elido.redirect.count{status_class:5xx} レート > 0.5% 2分継続 - オンコール呼び出し

  • elido.redirect.count{status_class:4xx} レート > 5% 10分継続 - Slackのみ

  • elido.scanner.failure.count レート > 10/min ワークスペース単位 - セキュリティレビュー、呼び出しなし

    0.5%の5xx閾値は保守的です。ベースラインは約0.01%(主に顧客送信先のDNS不具合)なので、0.5%は50倍の偏差であり、本物の問題を示します。

どちらをいつ使うか

/solutions/developersで開発者向けプロダクトを運営する小チームなら、Sentryだけで十分かもしれません。本物の5xxで呼び出され、issueを確認して修正できます。Datadogを$1.50/ホスト/月の管理コストに見合わせるためのダッシュボード文化はまだ必要ないでしょう。

SREオンコールローテーションを持つ/solutions/enterpriseの大企業には両方が必要です。Sentryがissueストリーム、Datadogがダッシュボード、Slackアラートをページング用にPagerDutyに接続します。そのルートを取る場合のPagerDutyサービスマッピングはオブザーバビリティガイドに記載されています。

その間のすべての人向けには:初日からSentry(月5000イベント未満なら無料ティアで十分)、リダイレクトドメインが2つ以上になるかトラフィックリージョンが複数になったらDatadogを追加。典型的なElido Businessワークスペースでのメトリクスコレクターの費用は月約$35で、エンジニアが日曜にnginxログをgrepしなくて済む代金です。

汎用uptimeモニターでは得られないもの

f.elido.meのPingdomやUptimeRobotチェックはエッジが稼働中かどうかを教えてくれます。しかし、slug summer24の送信先が12分前にDNS NXDOMAINを返し始めたこと、あるいはRedpandaのパーティションリーダーが再起動したためにSGPのp99がFRAの4倍になっていることは教えてくれません。リダイレクト監視は送信先を意識した問題です。リダイレクト自体は正常でも、リンクは死んでいることがあります。

上記のSentry + Datadogの組み合わせは、カスタムプローブを書かずに送信先を意識した可視性を提供します。Sentryは送信先レベルで何が壊れているかを教えます。Datadogはエッジレベルで何が劣化しているかを教えます。Slackが人間に伝え、Linearがフォローアップを保持します。Sentryへの接続はDSNを貼るだけ、Datadogは1つのOAuthフローです。今日からSentryを始めて、リダイレクトドメインが2つ以上になったらDatadogを追加してください。

料金とどのティアにどの統合が含まれるかは/pricingを参照してください。独自に構築したい場合のイベントサブスクリプション周りのAPIサーフェスは、/features/analytics12のGoサービスにまたがるSentryの詳細がイベント分類をカバーしています。

よくある質問

短縮リンクの監視とは何ですか?なぜ重要なのですか?

短縮リンクの監視とは、リダイレクト層で4xx/5xxレスポンス、レイテンシの低下、異常なクリックパターンを監視する取り組みです。壊れた短縮リンクは、エッジでトラフィックがオリジンに到達する前に障害が発生するため、通常のアプリ監視では見えません。有料キャンペーンをリダイレクトドメイン上で運用している場合、5xxが30秒続くだけで取り返しのつかない広告費が無駄になります。

リダイレクトエラーはSentryに送るべきですか、それともDatadogですか?

両方に送るべきですが、目的が異なります。Sentryは壊れた送信先を1つのissueに集約し、影響を受けたslugの一覧を表示する点で優れています。午前3時に対応するオンコールエンジニアが必要とするのはまさにこれです。一方Datadogは、地域別のエッジレイテンシp99やティア別クリックボリュームといった時系列データの保存先として最適であり、SREがオフィスの画面でチェックするものです。

短縮リンクのリダイレクトにおける健全なp99とはどれくらいですか?

EllidoのエッジPOP(FRA、ASH、SGP)では、キャッシュHITのリダイレクトはp99で15ms未満で提供されます。api-coreまでフォールスルーするキャッシュMISSは通常25〜40msです。5分間50msを超え続けた場合にアラートを出します。単一のクエリが遅いだけでは5分間p99が上昇し続けることはなく、Redisレプリカの同期外れを意味することが多いためです。

EllidoはSDKのフルインストールなしにどうやってSentryにイベントを送っているのですか?

Ellidoはエンベロープを公開フォーマットで直接SentryのHTTPインジェストエンドポイントに送信します。インテグレーションページにDSNを貼り付けるだけで、api-core内のwebhookトランスフォーマーが4xx/5xxイベントをSentry互換のJSONにパッケージします。SDKを組み込む必要はなく、エージェントを実行する必要もありません。管理するシークレットはDSNだけです。

共有ドメインf.elido.meとは別にカスタムドメインを監視できますか?

できます。Datadogのメトリクスコレクターはすべてのリダイレクトにドメイン、ティア(f/s/b)、リージョン、キャッシュ結果のタグを付けます。カスタムコードを書かずにドメインごとのエラーレートをグラフ化したり、カスタムドメインと共有フリーティアのp99を比較したりできます。

Elidoを試す

URLを貼り付けて短縮リンクを取得

登録不要。リンクは30日間有効。永久に保存するには登録してください。

Free、登録不要 · 1日あたり2件

Elidoを試す

EUホスティングのURL短縮サービス。カスタムドメイン、詳細な分析、オープンAPI付き。無料プラン - クレジットカード不要。

タグ
short link monitoring
sentry url monitoring
datadog short link metrics
redirect monitoring saas
edge latency monitoring

続きを読む