複数の信号損失インシデントを同一 Issue にまとめてアラート通知を削減する

大量のアラート通知は、初めての経験であれば最悪の体験の一つでしょう。 数十個のアラートが一斉に通知されれば、次々に通知される内容に追いつけず大障害を予感させます。分間数百・数千の通知で webhook で連携するサードパーティツールではポスト上限に達し、web メールや携帯電話のキャリアメールは制限が適用され始めるでしょう。さらに数万の通知はときに自社のメールサーバを停止させるなど、元の通知のほかに２次被害を引き起こすことさえあります。

通知の原因を辿れば、たった１つのルータやホストが停止しただけだった、あるいはクラウドや監視システムの障害だったということもあります。

システム障害検知を見逃さないために、隙間なくアラートを設定することは重要なことですが、 アラート設計者または設定者は、何が起きたらどのアラートが通知されるのか、どの程度のアラート通知が発生するのかという点を認識しておく必要があります。そしてその通知量に運用面で耐えられるかを考慮しておく必要があります。

対応者もまたそのような状況が想定されていれば、次々と発生する通知にも、冷静に原因の分析を行うことができ、障害の規模に見合った対応を行うことができます。 アラート通知は受信者・対応者にとっても少ない方がいいでしょう。重複する内容の通知が過剰に届くような場合は、アラート設計自体を見直すチャンスです。

本ポストでは、大量の通知を抑止する方法としてアラートポリシー・コンディション例や Decision 機能を利用した単一の Issue にまとめる簡易的な設計例をご紹介します。 アラート設計見直しの一歩目の取り組み例としてご参照ください。

個別の通知を抑制する機能

インシデントはアラートコンディション×閾値×FACET 値ごとに作成されます。インシデントは Issue に所属し、Issue には1つまたは複数のインシデントが所属します。
workflow 通知は Issue へのイベントがトリガーとなります。複数のインシデントを同一の Issue にまとめることで、通知数を削減することができます。

メールや slack 通知は対応開始のきっかけで、障害対応をする際は Issue ページにアクセスし、まとめられたインシデントを確認します。

• Issue Creation Preference (policy ごと, condition ごと, signal ごと) の設定
  • per condition & signal ではアラートシグナル (アラートコンディション×FACET 値) ごとに Issue が作成されることになります。FACET ごとに Issue が作成され、そのたびに通知されます
  • per condition では同一コンディションのインシデントは同一 Issue に所属します
  • per policy では同一ポリシーに属するコンディションのインシデントは、同一 Issue にまとめられます
  • ref. イシューが作成されるタイミングを決定する
• Correlation (decision) の活用
  • 対象が同じだった場合や特定のタグなどを指定して、同一 Issue にまとめるルールをカスタマイズで作成することができます
  • ref. アラートの相関関係に基づく根本原因の追究とノイズの低減
• Notify when .. (activated, acknowledged, investigated, priority change, other updates, closed)
  • workflow 通知の対象イベントを設定することができます
  • activated, closed のみであれば、Issue の作成時とクローズ時のみ通知されます (※ activated は外すことができません)
  • other updates が有効な場合、Issue にインシデントが追加された場合やインシデントの1つがクローズされた場合にも通知されます
  • ref. アラート通知タイミングの有効・無効の変更方法

Host Not reporting コンディションの活用例

NRQL 型 の Host Not Reporting (HNR) アラートコンディション

クラッシアラートに分類されるインフラストラクチャ型アラートコンディションでは Host Not reporting というアラート種別にてホストエンティティのデータ受信が滞った場合に検知する設定が準備されていました。
ref. インフラストラクチャの「ホストがレポートしない」条件を作成する

NRQL 型アラートコンディションでもガイドモードから同様の設定を作成することができます。
ref. インフラストラクチャの「ホストがレポートしない」条件を作成する

ガイドモードでは下記のアラートクエリで設定されて

SELECT count(`cpuPercent`) FROM SystemSample FACET entityName

Warning/Critical 閾値なしで、Signal lost 閾値のみを設定します。

クエリでは インフラエージェント経由で収集される SystemSample イベントの (cpuPercent カラムの) データ数を エンティティごとに収集し Signal lost 閾値で設定した時間以上、データ受信がなかった場合に信号損失インシデントが作成されます。
インシデントは エンティティごとに作成されます。

(改良型) OS 再起動検知および Host Not Reporting アラートコンディション

SystemSample では OS の稼働時間である uptime (秒) を収集しています。
この値は OS の再起動を検知するアラートに利用されてきました。
アラートクエリで uptime を収集し、静的閾値を設定することで、HNR だけでなく OS の再起動の検知もできるようになります。

• アラートクエリ

SELECT min(uptime) FROM SystemSample FACET entityName

• WD: 1分
• Event flow (delay 30秒)
• 静的閾値: result < 600 (秒) at least once in 1分
  • OS 再起動を検出するための閾値
  • uptime が 10分未満のデータを受信した場合違反判定、10分以上のデータを受信すると回復と判定
• Signal lost 閾値: 10分 with Open & Close アクション
  • 'Close all current open incidents' と 'Open new "lost signal" incident. Notification sent based on issue creation preference' アクションを設定
  • SystemSample データ未受信が 5分継続で信号損失違反、シグナル出荷で回復 (エージェントが 95秒以上 稼働) と判定されます
• title template: {{tag.entityName}} 再起動発生
• Violation Limit: 3日 (任意)

アラート通知を抑止するためのポイント

この HNR コンディション以外のインフラデータに関するアラートコンディションでは 信号損失閾値は設定しない ようにしましょう。

プロセス監視やディスク使用率のアラートコンディションで、プロセスやパーティションを FACET に指定しているような場合、
各コンディションで信号損失閾値も設定しているとホストの停止やデータ受信が滞った場合、各 FACET 値ごとに信号損失インシデントが発生してしまいます。

各ホストで10個のプロセスの稼働をアラートとして設定していた場合、対象ホストで停止すると 10個のインシデントが作成されることになります。
一方で、各コンディションで Signal lost 閾値は設定せず、HNR コンディションが存在していた場合は、インシデントは 1つだけ作成されます。

ネットワークなどの問題で複数ホストの情報が収集できなくなった場合を想像してみましょう。
ホストごとに 1つのインシデントが作成されるだけで十分ではないでしょうか。

たくさんのホストが存在するので、ホストごとの通知でも多くなりそうという場合は、アラートポリシーの Issue Creation Preference 設定を調整します。

HNR アラートコンディションを新規アラートポリシーの下に作成しておきましょう。

Issue Creation Preference 設定で、Issue per condition & signal に設定した場合は、Issue はホスト単位で作成されます。
Issue per condition に設定した場合は Issue はアカウント単位で作成されます。

各プロセス監視のアラートコンディションで信号損失閾値を設定しておきたいという場合

Issue Creation Preference 設定で、Issue per policy (ポリシーごとにまとめる) を設定しましょう。

各コンディションの FACET 値単位で、インシデントが発生しますが、同一ポリシーであれば同一 Issue に所属することになります。
workflow の通知は、ポリシー単位で通知されることになります。

また、この場合はポリシー内のコンディション由来のインシデントは同一 Issue になるため、後発の関連のない障害のインシデントも同じ Issue に所属してしまう場合も想定できます。
Issue はクローズするまで対応するなどの運用体制をとる方が安全かもしれません。

Correlation の活用例

アラートポリシーの設定で Correlation を有効にした場合、Correlation が有効なポリシー間の Issue は Decision ルールによって Issue にまとめられるようになります。

信号損失インシデントを含む Issue に対する Decision 例

• Correlation で 以下のような decision を作成します (いずれかでよい)
  • タイトルが “Signal lost for ” で始まる
    • Filter by specific values: title starts with “Signal lost for ”
    • Correlate by attributes: なし
    • Time window: 20 分 ~ 2 時間で任意の値を設定
  • EvaluationType が expiration の場合
    • Filter by specific values: evaluation.evaluationType = “expiration”
    • Correlate by attributes: なし
    • Time window: 20 分 ~ 2 時間で任意の値を設定

この場合 Correlation が有効化されているポリシーで 信号損失インシデントを含む Issue は 1つの Issue にまとめられるようになります。
decision の Time window: 20 分 ~ 2 時間で設定可能なので、その場で回復しなかった場合でも、後続インシデントがマージされ続けるということはありません。

これまで Decisions を活用していない場合は、この Decision だけを有効化、その他のデフォルト decision はオフで、各アラートポリシーの correlation を有効化すると、これまでの動作を大きく変えずに導入いただけます。

また Correlation は Issue のグルーピングルールであるため、Issue Creation Preference 設定は per condition & signal で始めた方が感覚とあう可能性があります。
信号損失インシデントを含む Issue A と 信号損失インシデントを含まない Issue B がそれぞれ Open 状態で存在する場合に、Issue B に新しく 信号損失インシデントが追加しされた場合、既存の Issue B に属するすべてのインシデント (信号損失インシデントを含まないインシデントも含めて) が Issue A にマージ (合流します) されます。
(マージ後に Issue B はクローズとなり、クローズ通知も発生します。)

新規作成の Issue の場合でも、処理時間の関係上 Issue の作成後に Correlation ルールが適用され、マージされるという場合があります。
この場合は、マージ対象の (子 Issue に関して) アクティベート通知やクローズ通知が発生する場合がありますので、Issues & Activity ページでの Open 中の Issue を確認いただくのが良いかと思います。

次のステップへ

本稿で紹介したような簡易的なアラート検知の工夫に止まらず、アラート要件や項目の見直しに着手するのもいいでしょう。

アラート通知が常態化しているような組織では、受信したアラートを分析し、分析結果に応じて自動復旧や振り分け先に通知するシステムを導入するような方向性でもよいでしょう。現代風に AI での原因分析をとりいれようというのもいいでしょう。

システムを冗長化し、耐障害性を高めるなどシステム構成の変更に帰結させるのもいいでしょう。サービスや仕組みを導入・変更し、より大規模に解決を試みるのもいいでしょう。

アプリケーション自体にエラーを補足・対応する仕組みを追加することもよいでしょう。 あるいは次の新しいアプリ・システムでは、活かそうという気持ちだけでも良いのです。

アラートは、ソフトウェアエンジニアにとって最良の友にも最悪の友にもなり得ます。さらに転機をもたらす親友にもなり得るでしょう。