Zenn
🐾

Datadog Error Tracking for Logsを使って日々のエラーログ監視を省力化する

2023/12/12に公開
Terraform
Google Cloud
datadog
#
monitoring
#
errortracking
tech

この記事は 検索エンジンプロダクトを一緒に開発してた同窓会 Advent Calendar 2023 の12日目の記事です。
昨日は kazunee さんの Network Namespace上でVRFを試してみる でした。

はじめに

サービスを開発運用していると日々発生する多くのエラーログを適切に監視する必要があります。
エラーログを検知した場合、都度しっかり原因調査して根本対応したりログレベルを適切に調整したりするのが理想ですが、実際には機能開発を優先して増え続けるエラーログに手が回らず消耗することも多いと思います。
ここではDatadog Error Tracking for Logsを導入することで日々の監視業務を省力化してみたいと思います。

エラーログ監視の課題

エラーログをSlackに通知した場合のよくある課題として、以下のようなものがあるのではないでしょうか。

  • エラーログの通知量が多い
  • 同じエラーログが何度も流れる
  • 検知したい新規エラーが埋もれる
  • 修正の優先順位が付けづらい

Error Tracking for Logs

類似のエラーを自動的にグループに分類して可視化してくれるDatadogのサービスです。

詳細は以下などを参照ください。

モニターと連携することで必要な場合のみ柔軟に通知することができます。
Datadogのログを利用していると追加料金なしで使用できるようです。

注意：この記事を書いている時点でまだβ版です

設定方法

まずはError Tracking for Logsの画面から機能を有効にします。
その後、 バックエンドエラーの追跡 を参考にエラーログの以下の属性に適切に値が入るように設定します。

属性 説明
error.stack 実際のスタックトレース
error.message スタックトレースに含まれるエラーメッセージ
error.kind エラーのタイプまたは「種類」(“Exception” や “OSError” など)

実際に試したところ、どれか1つでも値が入っていないと正しく分類されなかったので、確実に全て値が入るようにLog PipelineのRemapperを設定すると良さそうです。

正しく設定されるとこのようにエラーごとに分類され、エラー発生回数が可視化されます。

モニター作成

モニターは以下の2種類から作成できます。

  • Count: グループごとにエラーが一定数を超えたら通知
  • New Issue: 新規エラーが発生したら通知

まずは最低限New Issueを設定して、大量にエラーが発生したことも検知できるようにCountも必要に応じて通知設定を入れると良いのではと思います。

TerraformでNew Issueのモニターを実装するには datadog_monitor リソースを用いてtypeに error-tracking alert を指定します。
queryは独特なので、初めて作る際はWebコンソール上から作成してインポートするのが良さそうです。

resource "datadog_monitor" "error_tracking_new_issue" {
  name    = "[error tracking] New Issue"
  type    = "error-tracking alert"
  message = "@some-mention"
  query   = <<-QUERY
    error-tracking-logs("issue.age:<=86400000 OR issue.regression.age:<=86400000").index("*").rollup("count").by("issue.id").last("1d") >= 1
  QUERY

  monitor_thresholds {
    critical = 1
  }
}

同様にCountの実装例です。
ここでは1hで同一エラーが10件以上発生した際に通知してみます。

resource "datadog_monitor" "error_tacking_count" {
  name    = "[error tracking] Count"
  type    = "error-tracking alert"
  message = "@some-mention"
  query   = <<-QUERY
    error-tracking-logs("*").index("*").rollup("count").by("issue.id").last("1h") >= 10
  QUERY

  monitor_thresholds {
    critical = 10
  }
}

Slack通知はこのようになります。

改善効果

抱えていた課題に対して以下のように改善に繋がりました。

  • エラーログの通知量が多い
    • 新規エラー発生時と同一エラーの大量発生時のみしか通知されないので通知量は大幅に減る
  • 同じエラーログが何度も流れる
    • 同じエラーは大量に発生時のみしか通知されないので何度も流れなくなる
  • 検知したい新規エラーが埋もれる
    • 必要な場合のみしか通知されないので埋もれることがなくなる
  • 修正の優先順位が付けづらい
    • エラー数が多い順に視覚的に並ぶため優先順位を戦略的につけやすくなる

最後に

Datadog Error Tracking for Logsを導入することで不要な通知がなくなり、日々のエラーログ監視業務が劇的に改善しました。
Google Cloudにも似た機能である Error Reporting があるようなので、今後はこちらも試してみて機能や分類精度を比較検討してみたいなと考えています。

Discussion