はじめに
イベント、アラートそしてインシデントという言葉は、一般的なIT用語として幅広く使われています。
時にこれら3つの言葉が大きな違いを持たされず、言い回しを変えるための目的であったりなど、混同して使われる状況に遭遇されることもあるかとも思います。
ここですでに勘の良い方はお気づきかもしれませんが、実はPagerDuty内ではこのイベントとアラートとインシデントというものを明確に区別して定義しております。
各種機能や動作・設定等を正しく理解する上で、それらの違いや関係・関連性を正しく把握することが実は非常に重要となっています。
さらにPagerDuty自体をより効率的・効果的に使っていただく上でも必ず押さえておきたいポイントともなりますので、ぜひこの機会に理解を深めていただければと考えています。
イベントとアラートとインシデントの定義
まず、それぞれの用語の説明文としては、以下のようになります。
- 「イベント」： 監視やモニタリングツール等から発せられPagerDuty側で受け取る"信号"を表します。
- 「アラート」： PagerDuty側で受け取ったイベントからまずアラートがトリガー(=作成)されます。イベント情報はアラート作成時に自動的にアラートに詳細情報(details)として付加・管理されます。
- 「インシデント」： 前述のアラートによりトリガー(=作成)され、作成されたインシデント内にトリガー元となる該当アラートが紐付けて管理されます。各インシデントはPagerDutyのサービス上で発生し、紐づけられたエスカレーションポリシーなどに基づきオンコール担当者に通知される、対処して解決する必要がある問題や課題を表します。
文章による説明だけですとちょっとイメージが掴みにくい・・・という方が多くいらっしゃるかと想像します。
次に、もう少しPagerDuty内での処理の流れを踏まえて説明します。
イベント受信からオンコール担当者への通知までの流れ
PagerDutyでは、PagerDuty Event API V2、もしくはEvent API V2をベースに開発・提供された統合機能を通じて送信されたイベントを受信し、そこからPagerDuty内でアラートが作成されます。
また、その際に受け取ったイベント情報はアラートに追加されます。
その後の基本的な動作としては、インシデントが作成され、通知の緊急度やエスカレーションポリシーにおける通知先の設定などに基づいて、オンコール担当者への通知が行われます。
下記のフロー図では、上記流れの詳細を示しています。
- 各種監視ツールからPagerDutyに対しイベントが送信される
- 受信したイベントからPagerDuty内にてアラートがTriggerされる
- アラートからTrigger状態のインシデントが作成され、元となったアラートが当該インシデントに関連付けられる
- インシデント作成によりオンコール担当者に通知が送信される
- オンコール担当者がその通知を受信する
[イベント/アラート/インシデントのフロー図]
Webコンソール上での見え方
では実際にコンソール画面にて、イベント, アラート, インシデントそれぞれがどのように確認できるか？を、Event API V2を通じて送信されたイベントをもとに見てゆきます。
（Event API V2の使い方はこちらをご参照ください）
[アラート]
これまでの順番と前後しますが、まず作成されたアラートの確認方法としては、
(1) コンソール上部の "Incidents">"Alerts"を開く
(2) 表示されたアラート一覧から該当するアラートのSummary部分をクリック詳細を表示させる
[イベント]
前述しました様に、アラート作成時にイベント情報がアラートに追加されるため、イベント自体を単独で参照する機能はありません。
従って参照したい場合には、イベントによって作成されたアラートの詳細情報から行います。
(1) 先ほどのアラート情報の画面をスクロールダウンしてDetailsを表示させる
(2) さらにその最下部にあるView Messageリンク（上記添付スクショの赤枠）をクリックして、イベント詳細情報を表示させる
[インシデントの]
最後に作成されたインシデントの確認方法となります。
(1) コンソール上部の "Incidents">"All Incidents"を開く
(2) 表示されたインシデント一覧から、該当するインシデントのTitle部分をクリックし、インシデント詳細を表示させる
また画面下部のAlertsタブ(=青枠)にあるように、紐付けられているアラート情報も参照可能
※補足: PagerDutyでは、1つのインシデントに複数のアラートを紐付けて管理することにより、インシデント通知を受けるオンコール担当者にとって取り扱いやすい単位にて通知を受けることが可能となっています。
したがって、複数のアラートがグルーピングされている場合には、ここに複数のアラートが一覧として表示されます。
さらに一歩踏み込んで：
イベント/アラート/インシデントを階層構造で理解する
先ほど、”１つのインシデントに複数のアラートを紐づけて管理することが可能”、と言いました。また、アラートはその中に自動的にイベントを付加して管理する機能もあるとも説明しました。
実はもう一歩踏み込んで説明しますと、PagerDutyでは一つのアラート内に複数のイベントを紐付けて管理することができます。
この階層構造による管理機能により、複数のレイヤーで集約が行われ、より効率的にそれぞれを管理することが可能となっています。
イメージとしては下記になりますが、1つのアラートを”特定のデータ値”であったり"監視項目"として捉えていただくと、各イベントが、それぞれ特定の時点におけるデータの状態＝つまりスナップショットとも捉えていただけると思います。
[イベント/アラート/インシデントの階層構造]
ではこれがどの様にPagerDutyコンソール上で見えるかというと、以下の様になります。
(1) 該当するアラート情報を開き、画面をスクロールダウンして"Alert Log"を表示させる
※上記階層構造のイメージ図とAlert Logのタイムスタンプは異なっておりますが、ご了承ください。
※補足: ちなみにですが、[イベント/アラート/インシデントの階層構造]で示されたインシデント="App A SLO違反:Response Time"をResolved/解決するには、紐づけられたアラートそれぞれ全てがResolvedになるか、インシデント自体を手動でResolveする必要があります。
ここでちょっと注意ポイント
ここまでイベント > アラート > インシデントの流れにてそれぞれがトリガー＆作成される・・・といったお話をしてきましたが、実はアラートを作成をともわないインシデントがあります。
例えば下記方法や手段で作成されたインシデントは、アラート作成を伴いません。
- Webコンソールやモバイルアプリなどを通じて手動でトリガーされたインシデント
- REST API経由で作成されたインシデント
- (注意： イベント送信先となる上述のPagerDuty Event API V2 と PagerDuty REST APIは異なります）
したがって、もし アラート やイベントが見つからない（そもそも"Alerts Tab"が表示されない）インシデントの場合には、これらの方法にて作成されたものとも考えられます。
最後に
いかがでしたでしょうか？
イベント/アラート/インシデントの十分な理解があれば、トリアージ等のよりアドバンスな機能の正しい理解や活用が、より円滑に進むかと思います。(※重複排除やグルーピング及び抑制は、アラートレベルで実施 etc)
ナレッジベースドキュメントには、それぞれのより詳細な情報も詰まっておりますので、合わせ確認してみてください。
参考リソース
Incidents - https://support.pagerduty.com/docs/incidents
Alerts - https://support.pagerduty.com/docs/alerts
Alerts Table - https://support.pagerduty.com/docs/alerts-table
PagerDuty - 14日間 無料トライアル