PagerDuty Advent Calendar 12日目の記事です。
ノイズ削減機能の1つ、Alert Groupingについて説明します。
アラートをグループ化して扱うメリット
以下はグループ化されたアラートの例です。1つのインシデントに5つのアラートが紐付けられています。
もしAlert Groupingの機能がなかった場合、このアラートの数だけ通知が行われます。インシデントへの対応はすでに開始しているにもかかわらず、アラートが発生するたびに担当者の電話やアプリが鳴り、アラートの内容を確認する必要が出てきます。
また大量のアラートが発生した際には、深刻なアラートの見落としや対応の遅れにも繋がります。
関連するアラートをグループ化し、1つのインシデントとして管理することで、余計な通知や担当者の手間を減らし、重要なインシデントへの対応を速やかに行うことができます。
Alert Groupingの設定
Alert Groupingの設定はService毎に行います。
既存Serviceの設定を変更する場合は Services > Service Directory > {サービス名} を開き、Settingsタブ内のReduce Noise欄でEditをクリックします。
AIによるGrouping(推奨)を行う場合は、Intelligentにチェックを入れます。
Intelligent以外の方法では、Alert Content(アラートに含まれるフィールドを指定し、そのフィールドの値が一致したものをグループ化)とTime only(一定時間内に受信したアラートをグループ化)が利用できます。
rolling windowは同一インシデントにまとめるアラートの最大時間間隔を指定します。以下の例では、直近で受信したアラートと現在受信したアラートの受信時間の差が60分以内であれば、1つのインシデントにグループ化します。
当該Serviceで過去にアラートを受信していれば、推奨の値が "recommended" として表示されます。
Previewをクリックすると、過去45日間に受信したアラートについてIntelligent Alert Groupingでどの程度アラートを削減できたか(インシデントにまとめられたか)を確認できます。
AIにフィードバックを行い、Grouping精度を高める
Intelligent Alert Groupingでは、「アラートの類似性」と「ユーザーからのフィードバック」を基に、グループ化のルールをAIが管理しています。
例えば以下の例では、"Response Time Alert..."の3つはアラートに含まれる情報の類似性からAIが1つのグループにまとめるべきと判断しています。一方で、その他2つはアラートに含まれる情報が全く異なるため、元々はグループ化されていませんでした。これらはユーザーからのフィードバックによってグループ化するよう学習したものです。
複数のインシデントをチェックボックスで選択し、Merge Incidentsボタンをクリックすると、1つのインシデントのまとめることができます。Intelligent Alert Groupingでは、この操作からどのアラートをグループ化すべきか学習します。
また、1つのインシデントにまとめたアラートを別々のインシデントとして扱うよう、フィードバックを行うこともできます。
インシデント詳細画面で、アラートのプルダウンメニューから"Move to a new incident"を選ぶと、新しいインシデントを起票し、そのインシデントにアラートを紐付けます。"Move to an existing incident"では、既存の別インシデントを選択し、そのインシデントにアラートを紐づけます。
グループ化のルールをAIで管理するメリット
Alert Content(Content-Based)モードを利用し、グループ化のルールを人を管理することもできます。しかし、この方法では管理が煩雑になり、徐々にルールと運用が乖離してしまうなどの問題が起こる場合があります。
現場でインシデント対応を行う担当者が、ルールをきちんと理解した上で、日々の運用と並行してルールを更新し続けるのが難しいためです。
AIを利用したIntelligent Alert Groupingでは、Groupingのルールが現在どうなっているのかについての知識は必要ありません。また、現場の担当者はどのアラートをまとめるべきかについては良く理解しているため、適切なフィードバックを行うことができます。
AIの支援を活用することで、労力をかけずにルールを常に最新で適切なものに保つことができます。
FAQ
EventとAlertとIncidentの違いについて教えてください
Eventは、監視ツールからPagerDutyへ送信するデータの最小単位であり、ある時点における監視項目の状態です。
監視ツールは、監視項目が閾値を超えると、HTTPS(Event API)またはEmailでEventを送ります。Eventには監視項目毎にユニークな値(dedup_key)が付与されます。
Alertは、監視ツールにおける監視項目に該当します。
(例:あるサーバーのCPU使用率、WebサイトのHTTPレスポンスタイム等)
同一のdedup_keyを持つEventは、同一の監視項目の状態変化として、Alert内のAlert Logに時系列で記録されます。
以下はあるAlertの詳細画面です。
同一Alertに3つのEventが記録され、最新のEventはResolvedになっていたため、AlertのステータスもResolvedに更新されています。
Incidentは、「対応が必要な課題」です。1つのIncidentに、関連する複数のAlertをまとめて管理することが可能です。
IncidentのステータスをResolvedに変更すると、関連する全てのAlertもResolvedに変更されます。
逆に、Incidentに紐づく全てのAlertがResolvedになると、IncidentもResolvedになります。
以下では、1つのIncidentに5つのAlertがまとめられています。
参考: イベントとアラートとインシデントの違いとは？
Eventを送りましたが、インシデントが起票されません。アラート一覧にも見つかりません。
同一のdedup_keyを持つEventは、1つのAlertにまとめられ、Alert詳細画面のAlert Logに記録されます。Triggered状態のAlertの中に、同じdedup_keyをもつものがないか確認ください。
新たにAlertを作成するには、既存Alertの状態をResolvedに変更するか、異なるdedup_keyを付与してEventを送ってください。
なお、EmailでEventを送る場合には、Emailの件名がdedup_keyとして使われます。そのため、複数のEmail Eventを同一の件名で送ると、1つのAlertにまとめられます。
件名を変更して、再度送信してください。
Content-Based Alert Groupingを設定したのですが、グループ化されません。
Email Integrationでは、Content-Based Alert Groupingを利用できません。
Event APIを利用してEventを送ってください。
PagerDuty設定ガイド 目次
検知編 | トリアージ編 | 動員編 | 解決編 | 学習編
- 一次対応を自動化する
- [Alert Groupingでアラートノイズを削減する] << イマココ
- Auto Pauseで一過性アラートの通知を削減する
- Event Orchestrationでアラートへの対処を自動化する
- 診断や復旧作業を自動化する