Datadog Anomaly Monitorの活用事例

参考になった

レビュー投稿日の情報になります

株式会社カンリー / yyoosshh

メンバー / SRE / 従業員規模: 101名〜300名 / エンジニア組織: 11名〜50名

最終更新日2025/08/22投稿日2025/08/22

利用機能	ツールの利用規模	事業形態
Monitors	11名〜50名	B to B

導入の背景・解決したかった問題

カンリーではマルチプロダクトの運用をしています。

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

これにより、連携しているSlackのアラートチャンネルに通知が頻発する状態になり、本来はログ量の急上昇を検知するためのアラートが 毎週同じ時間帯に鳴ってしまうノイジーアラート となっていました。

目指したのはノイジーアラート解消とアラートの信頼性向上が実現され、本来の健全な監視環境が整った状態です。

具体で言うと下記が整っていると健全な監視環境といえると考えていますが、

項番2の「どうズレたら発報するのか」の部分で深掘りができておらず、精緻な設定がしきれていませんでした。

アラート設計の適合性向上：前日比（Daily）→同曜日・同時刻比（Weekly）へ。プロダクト特性と判断基準が一致。
運用の集中度向上：アラートチャンネルが静穏化し、対応が必要な通知へ集中。オンコールの心理的負担と判断コストを低減。
説明可能性の確立：「どのズレを異常とみなすか」を明文化し、レビューの意思決定がスムーズに。
IaCによる再利用性：Terraformで Seasonality（デフォルト daily）等を外部変数化し、プロダクトの特性に応じて選択可能な状態へ。
標準化の前進：Seasonality選定ガイドを整備し、アラート設計標準化を推進。
ノイズ削減の実績
- 週次で再発していたノイズアラートは約80%削減。

  * アラート件数の推移（実データ）
    * 5/1〜6/2（週次比較前）：16件（主に月曜0時台に集中）
    * 6/3〜6/10（切り替え直後）：9件（`weekly` への変更の学習期間でやや残存）
    * 6/11〜6/14（学習反映後）：2件（大幅減少）

まず目的を「週次で同時刻に繰り返し発生するノイジーアラートを解消し、監視・検知の品質を上げること」と明確化しました。

現状の Seasonality=daily の前日比判定のままでは、BtoBtoC特性による月曜の正常スパイクが“異常”として扱われ、Slackが恒常的に騒がしくなっている点を共有しました。

原因は「曜日差のある利用パターン」と「前日比というSeasonality（季節性）」のミスマッチであり、打ち手としては下記の2点と説明しました。

プロダクトの特性に応じて、Seasonality(季節性)の選定が必要なのでプロダクトを利用するユーザー動向の理解が必要です。

Seasonality(季節性) の選定基準
- hourly：毎時、明確なピーク/ボトムが存在する（例：hh:15, hh:30 で処理が集中する等）
- daily：日次で安定（前日同時刻比較が妥当）
- weekly：曜日差が大きい（例：月曜朝だけ突出して伸びる BtoC/BtoBtoC、土日注文が増えるモバイルオーダーなど）
運用上のコツ
- 切り替え直後は学習期間（1〜数週）の残存アラートを前提に観察。
- キャンペーン/リリース等でベースラインが動くときはレビューを定例化。