Datadog Error TrackingのCustom Groupingで運用負荷を軽減
お久しぶりです、yumaです
今日はDatadogのError Trackingでアラート数を削減し、各チームが自律的にDevOpsできる環境を構築した事例を紹介します🚀
この記事は、「KNOWLEDGE WORK Blog Sprint」第3日目の記事です
背景・課題
Datadog Error Trackingには、スタックやtraceなどの情報を元に自動でIssueをまとめる機能があります。
しかし、同じエラーメッセージでもtraceやコンテキストが異なると別Issueとして扱われ、ノイズが増えがちです。
ナレッジワークでは、context canceled
を含むエラーがまとまらず、毎週数十件の同様アラートが発生していました。
Datadog上で個別にIgnoreしても、微妙に異なるtraceのため新しいIssueとして再出現して、いたちごっこの状態になっていました。
結果、週次の非同期トリアージ会で毎回ignore作業が発生し、運用負荷になっていました。
対応
実装
Datadog Error TrackingのCustom Groupingの機能を使って、別物と判定されてしまう同義のエラーを一つのErrorとしてまとめられるようにします。
Datadog Logsに送信されるエラーに以下のようにerror.fingerprint
というプロパティを付与するだけで完了です。
{
// other properties...
"error": {
"fingerprint": "{FingerprintName}"
}
}
fingerprintを設定してもサービスを超えてまとまることはないので、適切にserviceを設定しておくことで過剰にまとまりすぎることを抑制できます。
また、Google Cloudではerror.fingerprint
は特別な意味を持たないため、まずlabels.datadog_fingerprint
として送信し、Datadog側でリマップする方式を採用しました。バックエンドサーバーからは以下のようなjsonを送信します。
{
// other properties...
"message": "context canceled: some error message",
"labels": {
"datadog_fingerprint": "{FingerprintName}"
}
}
そしてDatadog LogsのPipelineでlabels.datadog_fingerprint
をerror.fingerprint
にリマップしたら完了です。
以下がterraformでの実装例です。
resource "datadog_logs_custom_pipeline" "error_tracking_remap" {
// ...
processor {
attribute_remapper {
name = "error.fingerprint-remapper"
is_enabled = true
sources = [
"labels.datadog_fingerprint",
]
source_type = "attribute"
target = "error.fingerprint"
target_type = "attribute"
preserve_source = true
override_on_conflict = false
}
}
}
セルフサービス化
ナレッジワークでは複数プロダクトの開発チームが存在しています。
以前はDatadogのデフォルト設定をそのまま使用していましたが、各チームがオーナーシップを持って自律的にDevOpsできるよう、設定を各チームが所有するコードベースから行えるインターフェースを用意しました。
// fingerprintを設定する条件とfingerprint名を指定できる
log.AddHook(cloudlogging.DatadogFingerprintHook(
cloudlogging.FingerprintRule{
Name: "teamA-custom_error",
Condition: func(event *zerolog.Event, msg string) bool {
return strings.Contains(msg, "teamA")
},
},
))
まとめ
結果的に画像のように、別のエラーが一つのエラーとしてまとまっているのが確認できました。
Before: Issueのリスト画面
After: Issueの詳細画面
この対応により、毎週数十件発生していたcontext canceled
エラーが1つに集約され、実質的にアラート件数が0になりました
週次のエラートリアージ会でも、これらのエラーをignoreする作業が不要になり、運用工数を大幅に削減できました。また各チームが自律的にError Tracking管理できる環境も構築できました👏
Datadog Error Trackingのfingerprintを使ったCustom Groupingは文献が少なかったので、ぜひ参考にしてみてください!
KNOWLEDGE WORK Blog Sprint、明日9/4の執筆者はQAエンジニアのtettanです。
お楽しみに!
Discussion