モニタリング技術に触れる方の中で「アラート設定」と深く向き合ったことがある方はさほど多くないと思います。本エントリではアラート設定を深く理解する足がかりとして、アラート設定の構成要素を紹介します。

特定のサービスやプロダクトに限らず利用できる、モニタリングにおいて一般的な知識です。

ポイント

• アラート設定は「対象データ指定」「対象期間指定」「判定タイミング指定」「判定条件指定」の4つで構成されている
• これらを組み合わせて「的確に検知する」「偽陽性アラートや空振りを減らす」を実現する

 

監視テクノロジの設定や運用経験がある方向けのTips

現代の監視テクノロジにおけるアラート機能の多くは、保持している時系列データから特定のデータを取り出して、そのデータが特定の条件を満たすか否かを判定します。

かつての監視テクノロジと異なり、チェックの工程（言い換えるとデータを集める工程）と、判定する工程のタイミングが別制御です。

アラート設定の構成要素外観

 

ここでは「判定するための設定」を”アラート設定”、設定されたそれぞれを”監視項目”、「判定した結果、状態が遷移したことおよびその報告」を”アラート”（あるいは”インシデント”）、「報告そのもの」を”通知”と呼びます。

※以後は構成要素1〜4の番号を振っていますが、説明の都合で採番しただけであり、数字や順番に特に意味はありません。

構成要素1：対象データ指定

どのデータをどのように取り出すか指定します。時系列データベースに対してクエリを発行しデータを取得します。Datadog用でのクエリは「クエリ」、New Relic用でのクエリは「NRQL」と呼ばれています。

RDBMSで言うところのSQLのように、標準的に採用されている規格や文法はいまのところありません。

SQLはRDBMSが持つデータの集合に対して論理演算を行うもので、監視テクノロジで扱う時系列データにそのままピッタリではありません。でもイメージしやすくなると思うので引き合いに出してみました。

時系列データはシリーズとデータポイントで構成されます。対象データを指定するときは、まずシリーズを絞り込み、その後に必要に応じて加工します。

絞り込んだシリーズをまたいで集計したうえで、評価対象とすることもあります（シリーズをまたぎ横方向に集計したり、時系列方向に集計したりできます）。

たとえば「データポイントが1分おきに登録されており、アラート条件は5分で100回を超えたらCRITICAL」という場合は、絞り込んだ結果の1分おきのデータ5つを合計して5分おきのデータに加工します。

 

データを読む・処理する・評価する上でいくつか代表的な注意点があります。

 

例えば評価時点でデータポイントが欠落している場合があります。

データポイントが欠落する理由は、対象の停止や観測系統の異常など様々です。

欠落値がある場合に「データなしと扱う」「特定ステータスと見做す(OK|WARN|CRIT)」「特定の値と扱う」「欠損値の前の値と同じと見做す」などの処理方法があります。

 

またデータを読むうえでは「評価時点で」というのもポイントです。何らかの遅延によりデータの到着が遅れたため、あとから振り返ってみるとデータポイントがあるのに、判定時点ではデータポイントがない（まだ来ていなかった）ということもあります。

構成要素2：対象期間指定

SQLではテーブルにある全データを対象として処理を行います。

監視テクノロジで扱うのは時系列データであり、かならず個々のデータが時間情報を持っています。

 

アラート設定のときには、いつのデータ（いつからいつのデータ）を使って判断するかが重要で、これを必ず指定します。

SQLで言うところの WHERE で created_at の範囲を必ず指定するイメージです。

 

アラート設定においては最新状態が重要ですから、対象期間を短くするのがよいように思いがちです。

しかしあまりに短いと一時的な変動による誤報（例えばアラートを受け取って対処を始めたときにはリカバリしている）が多くなったり、短期間にアラートが連発したり（フラッピング）します。

Actionableでないアラートはアラート疲れや無視につながり、アラート全体の価値を毀損します。ないほうがマシなので避けなければなりません。

 

対象期間と判定タイミングは「監視される側で何かが起きてから監視システムが検出するまでの所要時間」に深く関わります。

対象期間が長いと、監視される側の状態が変化したことを監視システム側で確信するまでに時間がかかります。

 

対象期間の開始タイミングはおおまかに、判定タイミングを基準にする方法と、暦の日時を基準にする方法があります。

開始タイミングを判定タイミング基準にする方法はrolling windowと呼びます。実装の多くは暦日ではなく開始タイミング基準だと思います。

開始タイミングのうち判定タイミングを基準にしたうえで「N秒前から」とする場合があります。これは判定用のデータが監視システムに反映されるまでの遅延に対応するためのものです。例えばAWS CloudWatchのデータをモニタリングSaaSで処理する場合、データの取り込み手法によっては〜10分程度の遅延が発生します。

暦の日時の場合、大抵は月単位〜時間単位です。恐らくは実装上の理由で、分単位のような短い間隔での暦日基準はあまり見かけません。

 

大抵の場合は1回の判定で時間方向に複数の（＝複数タイミングの）データポイントが含まれます。例えば対象期間15分であれば、5分ごとのデータポイントが2〜3個含まれます。

 

時間方向の集約方法として「もろもろ集計したあとのひとつの値で判定する」こともあるし、タイミングごとに集計したうえで「そういうデータポイントがいくつ以上あったら」などとする場合もあります。

 

構成要素3：判定タイミング指定

いつ判定するか指定します。

データ受領ごとに判定してほしいような気がしますが、データが欠落している場合の対処を考えるとデータ受領時だけでなく定期的にも判定してほしいものです。

私が知る限り、多くの監視システムは1分ごとなど定期的に判定するようになっています。

なお判定タイミングを指定できないプロダクト・サービスも見かけます。

 

対象期間と判定タイミングは「監視される側で何かが起きてから監視システムが検出するまでの所要時間」に深く関わります。

判定タイミングの間隔が長いとそれだけ所要時間が長くなります。

例えばデータポイントが1分ごとにあっても、判定タイミングが5分ごとであればデータポイントが登録されてから判定まで最大5分かかります。

 

この判定タイミングはOK→NonOKの所要時間だけでなく、NonOK→OKの所要時間にも関わります。

もし判定タイミングが1時間に1回だとすると、異常状態を脱してから最大1時間はリカバリしません。

 

なお判定タイミングの間隔がデータポイントの間隔より短いと、判定するごとに「データポイントがあるとき」と「データポイントがひとつもないとき」がでてきてしまいます。

 

なお多くの監視システムでこの間隔は厳密ではありません。

1分ごとに設定したとして、キッチリ60秒おきであることは保証されないでしょう。

構成要素4：判定条件指定

対象データ指定・対象期間指定・判定タイミング指定で判定対象になるデータが揃うので、その結果得られたデータをもとにどのように判断するかを指定します。

 

指定の種類はほとんどが閾値です。「データの値がx以上であればCRITICAL、そうでなくともy以上であればWARNINGと判断する」といった具合です。

値との一致を指定できる場合もありますが、ログ監視のような文字列一致については対象データ指定のほうで指定することが多いです（対象データを「この文字列を含むログの出力件数」と指定する）。

 

固定値を指定する代わりに、何らかの予測アルゴリズムや機械学習、AIなどの手法を用いて判定する方法もあります。

ただ私の身近では、誤報抑止の重要性を鑑みて参考程度に留めており、強い通知は行いません。

補足

監視される側のシステムが全断したときなどに、アラートが同時多発することがあります（俗にアラートストームと呼ばれます）。

このような困った事態の抑止は、ここまで登場した設定だけでは実現できません。

別途保持しているシステム構成情報などを参考にする、あるいはアラートの通知先ごとに時間単位で通知をまとめるなどが考えられます。

お知らせ

オブザーバビリティ運用のシステムと組織への定着を促す「OBServe」の提供を開始しました。

 

Webエンジニアのためのモニタリング‧オブザーバビリティ実践ガイドと併せてご活用ください。