Datadogのエラートラッキングにおける効果的なアラート設計について考える

著者：sugar cat
目次

はじめに

昨今のシステム開発では、複雑な分散システムや多様なユーザーインターフェースが一般的になり、エラーの一元管理はシステムの健全な運用において必要不可欠です。特にバックエンドシステムでは、APMを活用することでエラーを効率的に検知し迅速に対応することが可能になります。

この記事ではDatadogを使ったバックエンドのエラートラッキングにおける効果的なアラート設計について考えます。

APMとエラートラッキングの基本

APMはアプリケーションのパフォーマンスを監視するためのツールであり、トレース、メトリクス、ログを収集・分析することでシステムの健全性を把握できます。

オブザーバビリティの文脈ではモニタリングは全ての基盤となる要素です。特にエラー監視においてはログやトレースを活用することで単にエラーを検知するだけでなく、原因特定のための属性情報も収集できます。

Datadogにおけるエラートラッキング

Datadogでは、APMのTrace Spanに対してerror.type/error.message/error.stackという属性を設定することで、エラーを検知します。 https://docs.datadoghq.com/ja/tracing/error_tracking/

Datadogはこれらの属性を持つエラースパンを自動的に収集し、同じフィンガープリントを持つエラーはグループ化されて同じ問題として扱われます。

この記事では具体的な計装方法については触れません。 以下執筆記事ですが、興味があればご参照ください。

  • OrchestrionとError Trackingの検証

https://zenn.dev/king/articles/35e3efb8735923

  • Datadog×Sentryで実現するエラートラッキング

https://zenn.dev/cover_corp/articles/fa3be55ecb1d78

エラーの原因特定

バックエンドのエラー、例えば一般的なREST APIやgRPCにおいては、Trace Metricsに紐づくTagから情報を得られる場合があります。Datadogでは以下のようなメトリクスとタグが自動的に収集されます。

trace.<SPAN_NAME>.hits.by_http_status

このメトリクスには以下のようなタグが付与されています：

  • env
  • service
  • version
  • resource
  • resource_name
  • http.status_class
  • http.status_code

これらのタグを利用することで、アラートの通知内容を充実させ、エラーの原因特定を容易にすることができます。

アラートの内容を考える

アラートの内容は、人間が一目見た時に何が起きたかわかるような情報を含めることが重要です。具体的には下記のような項目を含めるべきです：

- エラーが起きたサービス名(環境情報も含む)
- エラーが起きたリソース名(API Endpointなど)
- エラーメッセージ
- エラーが発生した日時、発生頻度
- 各種Link(APM、Runbookなど)

Datadogのモニターでの表現方法

DatadogのError Tracking Monitorでは、以下のようにテンプレート変数を使って通知内容をカスタマイズできます：

サービスとリソース情報

サービス: {{service.name}}
リソース: {{resource_name.name}}

これは、Trace Metricsに対してHTTP Componentで付与されたTagから自動的に取得されます。サービス名と処理されたリソース（エンドポイントなど）を表示します。

エラーメッセージ

エラーメッセージ: {{issue.attributes.error.message}}

Datadogではerror.messageの属性がError TrackingのIssue上のエラーメッセージとして使用されます。これにより具体的なエラー内容を通知に含めることができます。

発生日時と頻度

エラーが発生した日時: {{local_time 'last_triggered_at' 'Asia/Tokyo'}}
エラーが発生した頻度: {{value}} {{comparator}} {{threshold}}
  • last_triggered_at: モニターの条件がOK → WARN、WARN → ALERTに変更された時点のUTC時間を取得します
  • local_time: 指定したタイムゾーン（例：‘Asia/Tokyo’）でISO 8601形式の読みやすい時間に変換します
  • value: 現在のメトリクス値を表示します
  • comparator: 比較演算子（>、<、== など）を表示します
  • threshold: アラートの閾値を表示します

これらを組み合わせることで「この時間にこの閾値を超えたエラーが発生した」という情報を伝えられます。(※TraceをIngestしたタイミングとモニターの条件変更の間にはラグがあるのであくまでおおよその発生日時を知れるものになります)

リンク

APMリンク: https://app.datadoghq.com/apm/traces?query=status:error+env:{{env.name}}+service:{{service.name}}+resource_name:"{{urlencode "resource_name.name"}}"&start={{eval "last_triggered_at_epoch-5*60*1000"}}&end={{eval "last_triggered_at_epoch+5*60*1000"}}&paused=true

ここでは代表としてAPMのリンクを示しますが、Query Parameterとevalを利用して時間範囲を指定し、エラー発生時の前後5分間のトレースを表示するリンクを生成します。resource_nameを等をクエリに含める場合にはurlencode関数を使ってURLに含める値を適切にエンコードする必要があります。

アラートのノイズを減らす

アラートのノイズとなる要因には主に2つあります：

  1. 通知量が多すぎる：重要なアラートがわからない(オオカミ少年)
  2. 通知内容に余分な情報がある：1通知に情報量が多く、何が起きたのかの判断が難しい

通知量を減らすための方法

  • 特定のStatus Codeのみをアラート対象にする：例えば500系エラーのみに絞る(Queryで@http.status_code:500を指定)
  • New Issueの場合はTime Windowを長めに設定し、同一fingerprintのアラートが連続して通知されるのを防ぐ
  • Error OccurrencesやImpacted Usersなどの閾値を継続的に見直す

通知内容をシンプルにする

Datadogのモニター通知では、デフォルトで実行したクエリやその他の情報が含まれますが、これらをHide Allオプションで非表示にすることで、通知内容をシンプルにできます。

https://docs.datadoghq.com/ja/monitors/notify/#%E8%BF%BD%E5%8A%A0%E3%82%B3%E3%83%B3%E3%83%86%E3%83%B3%E3%83%84%E3%81%AE%E3%83%88%E3%82%B0%E3%83%AB

まとめ

Datadogを活用したバックエンドのエラートラッキングで効果的なアラート設計を行なっていきましょう。