😵‍💫

バックエンドからSREになって半年、Datadog監視の「閾値を決められない問題」と向き合った記録

に公開
監視
Datadog
SRE
monitoring
閾値
idea

はじめに

はじめまして、くのです！

私はこれまでバックエンドエンジニアとして働いてきましたが、SRE に部署を移動してから半年ほどが経ちました。業務内容が大きく変わり、特に異動直後はシステム監視の難しさを実感する日々を過ごしていました。開発者としてコードを書いていた頃とは異なり、システム全体の異常をいかに未然に検知するかという課題に向き合う中で、その難しさを強く痛感しています。

そこで今回は、Datadogを用いた監視を始めるにあたって、押さえておきたい監視の種類や、特に判断が難しい閾値設定をどのように考え、解決していくかについて、学んだ内容をまとめていきます。

この記事を読んでほしい人

  • Datadogのアラートの種類を網羅的に知りたい方
  • アラートの閾値設定に頭を悩ませたことがある方
  • アラート疲れ（トイル）を削減したい方

閾値を決められないという課題

これまで私は、Datadog でアラートを設定する際には、必ず明確な閾値が必要だと考えていました。しかし、実際にさまざまなケースに対してアラートを設定しようとすると、固定の数値を設定するのが困難なケースが多く発生することに気づきました。

閾値の設定がトイルを生む

たとえ閾値を設定したとしても、その設定が本当に妥当かどうかを継続的に評価し、定期的に調整する運用作業（トイル）は避けられません。さらに、その閾値が適切でなかった場合には、微調整を繰り返す作業に時間を取られてしまいますが、これは本来できるだけ避けたいですよね。

だからこそ、Datadog が提供するアラートの種類を幅広く理解し、状況に応じて適切な異常検知の手札を持っておくことが重要だと感じました。

Datadogで利用できる主な監視の種類

Datadog には多種多様なモニタータイプが用意されています。比較的使いそうな種類をピックアップして整理してみました。

1. Metric Monitor

特定の数値（CPU使用率、メモリ消費量、エラー数など）が、あらかじめ設定した閾値を超えた場合に通知する最も標準的な監視です。

2. Log Monitor

システムが出力するログをスキャンし、特定のキーワードの出現や、パターンの発生回数を監視する仕組みです。エラーの検知はもちろんですが、「見えにくい処理が最後まで正しく走りきったか」を担保する際にも有効です。下記に例を記載します。

① キーワードから「異常」を検知する

  • 例：エラーキーワード監視
  • 内容： ログの中に [ERROR] や Connection Timeout といった任意の文字列に対して記録された場合に通知します。集計する時間や何回記録された場合にエラーを出すかといったことも柔軟に設定できます。

② 「非同期ジョブ」の完走を担保する（実体験例）

  • 例：非同期処理の実行成功監視
  • 内容： 私の担当ケースでは、「リクエストは受理されたが、裏側の非同期ジョブが本当に成功したか」を確実に見届けるために活用しました。
  • 背景と課題：
    非同期処理の場合、APIリクエスト自体は「受理しました（202 Accepted）」として即座に成功を返します。しかし、実際に裏側で動くジョブが、処理の途中で落ちてしまったり、異常終了したりしても、メトリクスだけではその失敗に気づくことができませんでした。
  • 解決策：
    ジョブの最後に必ず出力される「完了ログ」を監視対象に設定しました。これにより、一連のワークフローが「確実に最後まで完走したこと」をログベースで証明できるようにしました。

3. Anomaly Detection

過去のデータ傾向を機械学習で分析し、通常とは異なる動きをした際に検知します。時間帯による変動が激しいメトリクスの監視に有効です。こちらに関しては、後のセクションで詳細を後述します。

4. Outlier Detection

同じ属性を持つグループの中で、他と比べて明らかに異なる挙動をしている「外れ値」を特定する仕組みです。全体の平均値に埋もれてしまう「特定の個体」の異常を見つけ出したい場合に威力を発揮します。

具体例として、GraphQLトラフィックの監視が挙げられます。数百あるUUIDの中で、ごく一部のUUIDだけが異常に高い頻度でクエリを発行しているユーザーを特定したい場合に利用できます。実際に、GraphQLの特定のエンドポイントが、あるユーザーに対して無限ループしてしまう障害が発生したことがありました。

このように、全体の平均値では気づきにくい一部の異常を検知したいケースで、Outlier Detectionは活躍します。

クエリ例：
count:graphql.queries{env:prod} by {payload.uuid}

5. Forecast Monitor

データの推移から将来の状態を予測します。例えば、ディスク使用率が24時間以内に100パーセントに達するという予測に基づいた通知や、CPU使用率の急増トレンドを事前に警告する場合に使用します。

6. Cost Monitor

Cost Monitorは、DatadogのCost Explorer機能を有効化することで利用できるようになります。主に、AWSやGitHub Actionsにおける異常検知では、コストに関する指標が用いられることが多いです。

例えば、GitHub Actionsの実行時間が異常に長くなった場合や、AWSリソースが不正に利用され、通常は使用しないリージョンにリソースが作成された場合などの検知に役立ちます。

固定の閾値では解決できないケース

監視を運用していると、単純な数値で閾値を決められないケースに必ず直面します。その代表例が ALB（Application Load Balancer）のリクエスト数です。

サービスにはユーザーの生活リズムが色濃く反映されます。平日の昼間はアクセスが多く、深夜は少ないといった周期性や、週末やキャンペーン期間中だけに発生するスパイクがあります。このようなメトリクスに対して、〇〇リクエストを超えたらアラートといった固定の閾値を設定してしまうと、日中のピーク時には頻繁に誤検知が発生し、逆に深夜の異常な微増を見逃してしまうことになります。

本来検知したいのは、ある絶対的な数値を超えたかどうかではなく、普段のその時間帯と比べて異常な変化が起きているかどうかです。もし、通常の時間帯におけるリクエスト数と大きな乖離が見られる場合には、DDoS攻撃の可能性を疑い、速やかに原因調査へと進むことができます。

Anomaly Detectionによる機械学習の活用

固定の閾値を設定することが難しいケースで特に強力なのが、Anomaly Detection です。この機能では、Datadog が過去のデータを学習し、期待される値の範囲となる信頼帯を自動的に算出してくれます。

設定の容易さ

機械学習と聞くと難しそうに感じますが、Datadog の設定画面で対象のメトリクスを選び、アルゴリズムを選択するだけで利用可能です。複雑な計算式を自作する必要はありません。

下記でも説明していきますが、詳細については公式ドキュメントをご参照ください。
https://docs.datadoghq.com/ja/monitors/types/anomaly/#季節性

季節性の考慮

メトリクスの挙動に合わせて3つの「季節性」を選択できます。これにより、単なる数値の増減ではなく、期待されるパターンからの逸脱を正確に捉えることが可能になります。

Hourly（時間単位）
1時間の中での特定の分が、過去の同じ時間帯の分と同様に挙動すると想定します。例えば、今日の17時15分の挙動を、過去の17時15分のデータと比較します。

Daily（日単位）
今日の特定の時間が、過去の同じ時間と同様に挙動すると想定します。例えば、今日の17時の挙動を、昨日の17時の挙動と比較します。

Weekly（週単位）
今週の特定の曜日が、過去の同じ曜日と同様に挙動すると想定します。例えば、今週の火曜日の挙動を、過去の火曜日のデータと比較します。

異常検知アルゴリズムの選択肢

また、データの特性に合わせて、以下のアルゴリズムも選択できます。

  • Basic：特筆すべき周期性がないデータに適しています。
  • Agile：明確な季節性があり、かつ直近の変化にすばやく適応させたい場合に適しています。
  • Robust：季節性があるデータに対して、一時的なノイズや外れ値の影響を受けにくく、安定した監視を行いたい場合に適しています。

監視を使い分けるための判断基準

もちろん、全ての監視を Anomaly Detection にすれば良いわけではありません。用途に応じた使い分けが、運用していく上での負荷を下げる鍵となります。

標準的な閾値監視（Metric Monitor）を使う例

  • メモリ使用率など、ハードウェアの制限が明確なもの
  • 特定の重大なエラーなど、閾値の基準が明確なもの

Anomaly Detection を使う例

  • 時間帯によって期待値が大きく変動するもの(リクエスト数など)
  • ログイン回数や購入完了数などのビジネス指標

迅速なアクションを促すアラート文の設計

適切な監視手法を選ぶことも大切ですが、それと同じくらい重要なのが「アラートが飛んできた後にどう動くか」の設計です。

閾値調整などの試行錯誤を始める前に、まずは「アラートを受け取った人が迷わない状態」を定義しておくことで、監視の目的（＝迅速な復旧）がブレなくなります。

私の部署では、以下のような要素を通知に盛り込んでいます。

  • 適切な担当者へのメンション
  • 発生している事象の原因
  • 具体的な対処法や手順

これらをセットで伝えることで、誰が何をすべきかを明確にし、迅速な復旧を目指しています。

まとめ

監視を考えるうえで大切なのは、数値を機械的に監視することではなく、「いつもと違う状態」にきちんと気づき、即座に次のアクションに繋げることだと感じています。

メトリクスの性質によっては、「固定の閾値」を設定することで、かえって過検知を招き、運用の負担（アラート疲れ）になってしまうケースも少なくありません。
Datadog にはさまざまな監視の選択肢が用意されているため、直面している課題に対して適切な打ち手を選べるよう、それぞれの特徴を理解しておくことが重要だと感じています。

監視の道は奥が深いですが、実戦を通して最適な監視ができるよう、これからもCloud Praticaでもしっかり学び精進していきたいと思います！

Discussion