Sentry と Datadog による短縮リンクの監視: どちらが何を担当するか

短縮リンクの監視は、この2つのツールにきれいに分かれます。Sentry は Elido がリンクのヘルスイベントを送る先です。応答しなくなった行き先、期限切れになったリンク、上限に達したクリック数、検証に失敗したカスタムドメインなどです。Datadog は Elido がクリックを送る先で、訪問ごとに1つのログと、1分ごとに3つのクリック数メトリクスを送信します。リダイレクトのレイテンシはどちらにも送られません。Elido がそれをエクスポートしないためで、合成プローブを使って外部から測定する必要があります。

この記事はその全体像のうち Sentry 側を中心に扱い、「どちらのツールで何をするか」への率直な答えも示します。Datadog のダッシュボードが目当てなら、Datadog リダイレクトメトリクスガイドがクリックメトリクス、ログの形式、Synthetics ベースのレイテンシボードを詳しく扱っているので、ここでは繰り返しません。

設定に入る前に、ひとつ前提を共有しておきます。リンクが死んでいても、リダイレクト自体は完全に健全な場合があります。短縮 URL は数ミリ秒で応答しつつ、ユーザーを404ページへ送ってしまうのです。だからこそ短縮リンクの URL 監視には、行き先を意識したシグナルと速度のシグナルの両方が必要であり、単一のツールの1つのフィードだけでは両方をカバーできません。p95 15ms未満の内訳では、速度面での「健全」がどのようなものかを説明しています。

短縮リンクの監視が捉えるべきもの

障害は3つのバケツに分類しています。それぞれ異なるツールが必要になるためです。

リンクが壊れたケース。行き先が4xxや5xxを返す、タイムアウトする、あるいはドメインが名前解決できなくなる、といった状況です。リダイレクト自体は動作し続けますが、今やユーザーをエラーページへ転送してしまいます。Elido は毎日の行き先チェックでこれを検出し、link.broken を発生させます。

意図的にリンクが停止したケース。期限日やクリック上限に達したため、Elido がリダイレクトを止めた場合です。技術的には何も問題はありませんが、キャンペーンがまだそのリンクを指しているなら誰かが気づく必要があります。これが link.expired と link.cap_reached です。検証が完了しなかったカスタムドメインは domain.ssl_failed を発生させ、これも同じ分類に入ります。

リダイレクト自体が遅くなった、あるいはダウンしたケース。これが速度のシグナルであり、Elido がメトリクスとして出力しないものです。外部から監視する必要があります。

トラフィックは4つ目のシグナルですが、やや弱いものです。通常は1時間に数千クリックあるキャンペーンが突然数十クリックしかなくなった場合、たいていは広告の一時停止やQRステッカーが剥がされたなど、上流で何かが変わったことを意味します。クリック数は Datadog にあるので、急減の監視もそこに置きます。

Elido が Sentry に送信する内容

Sentry は Elido の通知システムにおける送信チャンネルの種類の1つで、Discord、Telegram、通常の署名付き webhook と並びます。webhookと同じ配信パイプラインに乗りますが、1点だけ異なります。生の Elido イベントの代わりに、小さな Sentry イベントを送信する点です。

各配信は、Elido が DSN から導き出したプロジェクトの store エンドポイントへ送信される1つの JSON イベントです。https://[email protected]/8 が与えられた場合、送信先は https://o4711.ingest.sentry.io/api/8/store/ となり、公開鍵は X-Sentry-Auth ヘッダーに入ります。経路のどこにも Sentry の SDK は存在せず、DSN のホストはハードコードではなく解析されるため、セルフホストの Sentry 互換サーバーでも同じように動作します。ペイロードはSentry のイベントペイロード形式に従います。

{
  "event_id": "9f0c4e1b2a7d4c33b8e5d6a1f2c3b4a5",
  "timestamp": 1790000000,
  "level": "error",
  "logger": "elido",
  "platform": "other",
  "message": "<humanized event name, e.g. Link / Broken>",
  "environment": "production",
  "tags": { "event_type": "link.broken", "workspace_id": "42" }
}

レベルはイベント名から決まります。「このリンクは今動作していない」ことを意味するものはすべて error として届きます。.broken、.expired、cap_reached、ssl_failed です。削除やダウングレードは warning として届き、それ以外はすべて info として届きます。

ここでタグについて正直に述べておきます。すべてのイベントには event_type と workspace_id のタグが付き、チャンネルで設定すれば environment と release のフィールドも入ります。cap-reached イベントには clicks タグも付きます。しかし broken-link イベントには、現状スラッグや行き先がタグとして含まれていないため、Sentry の issue はワークスペース42のどこかのリンクが壊れたことしか教えてくれません。そこから Elido のリンク一覧を開き、壊れたリンクに付いたフラグを確認することになります。深夜2時に slug タグを探し回るより、今のうちに正直に伝えておきたいと思います。

壊れたリンクのアラート用に Sentry チャンネルを設定する

設定には数分かかり、必要な認証情報は DSN だけです。Sentry チャンネルには Beta のマークが付いています。これは Sentry プロジェクトを自分で作成する必要があるためです。Sentry のインテグレーションプラットフォームを通じたワンクリックインストールはロードマップに載っていますがまだ構築されておらず、現状は DSN を貼り付ける方式です。

1. Sentry でプロジェクトを作成し、Other プラットフォームを選び、次の画面で DSN をコピーします。DSN の解説では、どの部分がキーでどの部分がプロジェクト ID かを示しています。
2. Elido のダッシュボードで Notifications を開き、チャンネルを追加して Sentry を選び、DSN を貼り付けます。任意で production のような環境名も指定できます。
3. デフォルトのイベントのままにするか、自分で選びます。デフォルトは link.broken、link.expired、link.cap_reached、domain.ssl_failed です。

Elido は保存時に DSN をチェックします。http または https であること、公開鍵を含むこと、プロジェクト ID で終わることが必要です。形式が不正な場合はその場で拒否され、後で静かに失敗することはありません。

設定をコードとして管理している場合、同じチャンネルは1回の API 呼び出しで作成できます。チャンネルは kind を持つ webhook エンドポイントです。

curl -X POST https://api.elido.app/v1/workspaces/42/webhooks \
  -H "Authorization: Bearer elido_live_xxx" \
  -H "Content-Type: application/json" \
  -d '{
    "kind": "sentry",
    "url": "https://[email protected]/8",
    "events": ["link.broken", "link.expired", "link.cap_reached", "domain.ssl_failed"],
    "description": "Link health to Sentry",
    "config": { "environment": "production", "release": "spring-campaign" }
  }'

Sentry への配信は HMAC 署名されません。Sentry は代わりに鍵でリクエストを認証するためです。ただし通常のリトライポリシーは適用されます。合計3回の試行で、失敗の5分後と15分後にリトライし、その後配信は失敗としてマークされます。/v1/workspaces/{workspace_id}/webhooks/{id}/deliveries で一覧を確認し、手動で再送信することもできます。

このチャンネルにはテストボタンがありません。私が知る最も確実なテスト方法は、1〜2分後に期限が切れる使い捨てのリンクを作成して待つことです。Elido は5分ごとに新しく期限切れになったリンクをスキャンするので、その少し後に error レベルの issue が Sentry に届くはずです。

リンクのヘルスイベントが Sentry に届くようになったら、次の問題はそれをどう扱うかであり、それは Sentry がそれらをどうグルーピングするかに左右されます。まだプランを選んでいる段階なら、チャンネルを設定する前に各ティアに含まれる内容を比較しておきましょう。

Sentry が Elido のリンクヘルスイベントをどうグルーピングするか

これらのイベントにはスタックトレースも例外もないため、Sentry のフォールバックグルーピングはメッセージ単位でグルーピングします。実際には、イベントタイプごとに1つの issue になるということです。壊れたリンクのイベントはすべて1つの issue にまとまってイベント数が積み上がり、期限切れは別の issue にまとまります。

これはページングには有用ですが、トリアージにはあまり向きません。次の2つの工夫が役立ちます。

• チャンネルに環境を設定する。ワークスペースごと、あるいは環境ごと(production、campaigns)に個別のチャンネルを用意すれば、それぞれが issue ストリームで独自のフィルターを持ち、アラートルールを1つに絞り込めます。
• 複数のワークスペースを1つのプロジェクトにまとめて送っていて、ワークスペースごとに issue を分けたい場合は、Sentry のプロジェクト設定で tags.workspace_id に対するフィンガープリントルールを追加する。

アラートには、Sentry 自体のissue アラートルールを活用しましょう。「新しい issue が作成された」ルールは最初に壊れたリンクを捕捉し、「issue が1時間にN回以上検出された」ルールは、たとえばランディングドメインがダウンしたキャンペーン全体のようなまとまった障害を捕捉します。その裏にある検出のペースを頭に入れておいてください。行き先チェックは1日に1回実行され、最初の失敗はすぐに発火し、壊れたままのリンクは24時間後に再び発火します。Sentry はこの用途には適した受信箱ですが、5分単位の障害検知器ではありません。そうであるかのように装うつもりはありません。

リダイレクト監視における Datadog の役割

Datadog が受け取るのはクリックであり、リンクのヘルスではありません。すべてのクリックは、Datadog サイトの Logs 取り込み先に送られる1つのログとなり、ソースは elido、タグは workspace_id、vendor:elido、link_id、クリックのフィールドは attributes 配下に入ります。Elido はさらに1分ごとに、ワークスペースごとに3つのゲージ elido.clicks、elido.clicks_by_country、elido.clicks_by_device を送信します。

そこに含まれていないものも同じくらい重要です。レイテンシのメトリクスもステータスコードもなく、ドメイン、ティア、リージョンのタグもありません。ログの POST が失敗した場合は1回だけリトライされ、その後は破棄されます。設定は最大5分間キャッシュされるため、新しく保存したキーが反映されるまで少し時間がかかります。また、ダッシュボードの Test connection ボタンはテストログを1件送信し、Datadog からの応答を表示しますが、これで分かるのは間違ったキーやサイトの誤りだけで、ログを取りこぼすパイプラインの不具合までは分かりません。そのため、実際のクリックが届くことだけが今も動作の証明になります。

つまり、ここでの Datadog の役割はトラフィックです。1分あたりのクリック数、上位の国、そして「クリックがほぼゼロまで急減した」ことを検知するモニターです。Datadog URL 監視ガイドにはクエリと設定手順があり、インテグレーションページにはフィールド一覧があります。合計値は、信頼できる記録として残るElido のクリック分析と突き合わせて確認してください。

外部からリダイレクトのレイテンシを監視する

速度のシグナルには、カナリア短縮リンク、つまり監視専用に作成するリンクに対して合成チェックを向けます。これによりプローブがキャンペーンの数字と混ざることはありません。Datadog のHTTP テストはこれをうまく行いますし、リダイレクトをスキップできる稼働監視サービスであれば何でも使えます。

その数字に意味があるかどうかは、次の3つの設定次第です。

• リダイレクトの追跡をオフにする。欲しいのはランディングページが描画されるまでの時間ではなく、301や302が返ってくるまでの時間です。
• ステータスコードと Location ヘッダーをアサートする。これにより間違った行き先へのリダイレクトはチェックが失敗するようになります。
• bot を含む User-Agent を送信する。Elido は既知の bot エージェントに対するクリックイベントをスキップするため、プローブがクリック数を水増ししません。

プローブは、対象の読者に近いロケーションから実行してください。リージョン内でキャッシュヒットしたリダイレクトは15msのp95予算を十分に下回るはずで、持続的な悪化はページングに値します。カスタムドメインへのチェックは、TLS証明書がまだ有効かどうかも教えてくれます。これはクリックフォワーダーには決してできないことです。

どちらのツールで何をするか

有料キャンペーンを短縮リンクで運用しているチーム向けに、私ならこう分けます。

小さなチームなら、まず Sentry チャンネルだけで始められます。これは広告費を静かに無駄にする類の障害をカバーします。実際にトラフィックダッシュボードを見る人が出てきたら Datadog を追加し、遅いリダイレクトがお金を失わせるようになった日にプローブを追加しましょう。Sentry がチームの受信箱でない場合、同じリンクヘルスイベントはDiscord や Telegramにも送れますし、壊れたリンクからLinear のチケットを作成することもできます。

コーナーストーン記事を読む → リダイレクトのp95を15ms未満にする

ブログの関連記事

• 短縮リンクのための Datadog URL 監視 - クリックメトリクス、ログ、Synthetics レイテンシボード。
• リンク切れ防止の戦略 - 壊れたリンクの issue が届いた後にすべきこと。
• 短縮リンクの Discord と Telegram アラート - 同じリンクヘルスイベントをチャットチャンネルで受け取る。
• リンクアラートから Linear チケットを作成 - 壊れたリンクを追跡可能なタスクに変える。