Datadog Anomaly Monitorでアラートノイズを80%削減した話

こんにちは！
株式会社カンリーのプラットフォーム部でSREをしている吉村です。

今回は、Datadogの Anomaly Monitor を活用して、プロダクトごとのログ傾向に合わせた監視設定をチューニングし、アラートのノイズを大幅に削減した取り組みについて紹介します。

カンリーのマルチプロダクト前提の監視運用

カンリーでは、複数のサービス（マルチプロダクト）を提供しており、それぞれのプロダクトが異なる性質や利用パターンを持っています。たとえば、toB向けサービスと、toC向けサービスとではトラフィックの傾向やシステムの動き方が大きく異なるケースも珍しくありません。

そのため、一律の監視設定ではプロダクト特性にフィットしない場面が出てくることもあります。SREとしては、こうした違いに丁寧に向き合い、プロダクトごとに最適な監視構成を柔軟に設計することが重要だと考えています。

今回ご紹介するDatadogの Log Anomaly Monitor 改善も、まさにこの「プロダクトごとの特性を踏まえた監視構成」の一環として取り組んだものです。

🚨 アラートの頻発

とあるBtoBtoC向けプロダクトにおいて、DatadogのLog Anomaly Monitor（ログ量の異常検知）を運用していたところ、毎週特定の日時にアラート通知が繰り返される現象が見られました。

これは、SlackのDatadog連携チャネルにも毎週定期的に通知が飛ぶ状態となり、チーム内で「これはノイズでは？」という声が挙がるきっかけになりました。

この時点では明確に「誤検知」と断定できるわけではありませんでしたが、似たような通知が毎週のように繰り返されていたため、将来的に“確認 → スルー”が習慣化してしまうリスクや、オンコール対応者の負担増加が懸念される状況になっていました。

👀 発生状況の定量的な把握

検知ルール（seasonality = daily）のまま運用していた〜6月前半までの状況を振り返ると、以下のようなアラート件数になっていました。

期間	発生件数	備考
5/1〜6/2（週次比較前）	16件	月曜0時台に集中。繰り返し発生する傾向あり
6/3〜6/10（変更適用直後）	9件	設定変更(daily→weekly)後の傾向学習期間。誤検知がやや残る傾向
6/11〜6/14（週次学習反映後）	2件	傾向の学習後。アラート頻度が大幅に低下

❓ seasonality（周期性）とは？

DatadogのAnomaly Monitorでは、「いつと比較して（検知対象が）異常か？」 という基準として seasonality というパラメータを指定できます。

選択肢は以下の通りです。

設定値	概要	適したケース例
hourly	1時間単位の周期変動を学習し、異常を検知	1日の中で明確なピークがあるサービス（例：夜間に集中アクセス）
daily	前日と同じ時間帯との比較で異常を検知（デフォルト）	安定した日次パターンがあるサービス
weekly	同じ曜日・時間帯の過去データをベースに異常を検知（今回の対応）	曜日ごとに利用傾向が異なるサービス

🔍 今回のプロダクトの傾向と選定理由

今回対象のプロダクトは、toC向けという特性上、平日と休日のアクセス傾向が異なるという特徴がありました。

とくに以下のようなパターンが見られ、Anomaly Monitorの通知が月曜日に集中していました。

• 火曜日〜金曜日までは緩やかなアクセス
• 土日は平日に比べて微増
• 月曜の朝にアクセスが一時的に急増

[1週間のログ量推移]

このような場合、前日と比較する daily ではうまく異常かどうかを判断できず、月曜の正常なアクセス急増が異常と判断されてしまうリスクがありました。
これは一見すると異常に見えますが、実際にはプロダクトの特性に起因する正常な利用傾向であり、誤検知と捉えるべきものでした。

そのため、「月曜の朝は月曜の過去(先週)データと比較して判断してほしい」 という意図で weekly を選択しました。

📝 修正内容とTerraformモジュール対応

設定の変更内容

• seasonality: daily → weekly

Terraform モジュールの拡張

既存のDatadog Monitor用のTerraformモジュールに対して、seasonality や algorithm を明示的に外部から指定できるよう変数化を行いました。

これにより、デフォルトでは daily を採用しつつ、各プロダクトの特性に応じて weekly などの値に柔軟に上書きできる構成が実現しました。

結果として、マルチプロダクト環境でも共通で再利用できる、汎用的な監視テンプレートへと発展させることができました。

🧩 Terraform 設定例（抜粋）

variable.tf

...
variable "seasonality" {
  type        = string
  default     = "daily"
  description = "Anomaly detection seasonality (hourly, daily, weekly)"
}

variable "algorithm" {
  type        = string
  default     = "agile"
  description = "Anomaly detection algorithm (basic or agile)"
}
...

module内部

resource "datadog_monitor" "log_anomaly" {
  name    = var.name
  type    = "log alert"
  message = <<EOT
{{#is_alert}}
🚨 Log Anomaly Detected!
{{/is_alert}}

@slack-your_channel
EOT

  query = <<EOT
logs("service:${var.service} AND @env:${var.env}")
  .rollup("count")
  .anomalies("${var.algorithm}", 2,
    direction="above",
    interval=60,
    alert_window="last_15m",
    seasonality="${var.seasonality}",
    count_default_zero="true"
  ) >= ${var.critical_threshold}
EOT
...
}

module呼び出し側（使用例）

module "anomaly_log_volume" {
  source            = "github.com/hoge-inc/terraform-datadog-modules//monitor/anomaly/datadog_log_anomaly_event?ref=v0.1.0"
  name              = "Log Volume Anomaly Monitor"
  service           = "sample-service"
  env               = "production"
  seasonality       = "weekly"     # ← 指定可能
  algorithm         = "agile"      # ← 指定可能
  critical_threshold = 200
  evaluation_delay  = 900
  tags              = ["env:production", "service:sample-service"]
}

📈 効果とその後の展開

• ノイズ的なアラートが80%以上減少
• チームのアラートチャネルが静かになり、必要な通知に集中できる環境を整備
• オンコール担当の心理的負担軽減にもつながる結果に
• 他のプロダクトでも類似傾向が見られたため、拡張した設定を横展開中

📖 まとめ

• seasonality の適切な設定は、Anomaly Monitor活用の最重要ポイント
• Datadogのアノマリー検知はとても強力だが、プロダクト特性に合わない設定だと逆効果になることもある
• Terraformモジュールを柔軟にしておくことで、継続的な改善とプロダクト横断での最適化が可能

SREとして、監視環境の品質を高めることは「チーム全体の安心」をつくることにつながると感じています。
今後もDatadogの機能を活かしつつ、より良い運用に向けて改善を続けていきます。

ご質問・ご意見などあればお気軽にコメントください！