イベントとアラートとインシデントの違いとは？

## はじめに

***イベント***、***アラート***そして***インシデント***という言葉は、一般的なIT用語として幅広く使われています。<br> 時にこれら3つの言葉が大きな違いを持たされず、言い回しを変えるための目的であったりなど、混同して使われる状況に遭遇されることもあるかとも思います。

ここですでに勘の良い方はお気づきかもしれませんが、実はPagerDuty内ではこの***イベント***と***アラート***と***インシデント***というものを明確に区別して定義しております。

各種機能や動作・設定等を正しく理解する上で、それらの違いや関係・関連性を正しく把握することが実は非常に重要となっています。<br> さらにPagerDuty自体をより効率的・効果的に使っていただく上でも必ず押さえておきたいポイントともなりますので、ぜひこの機会に理解を深めていただければと考えています。

![Alert_and_Incident3.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3621498/6c2c6958-1ee5-d4d0-0d39-35835d3a7ee9.jpeg)




## イベントとアラートとインシデントの定義

まず、それぞれの用語の説明文としては、以下のようになります。 <br><br>

- 「***イベント***」：　監視やモニタリングツール等から発せられPagerDuty側で受け取る"信号"を表します。
- 「***アラート***」：　PagerDuty側で受け取った***イベント***からまず***アラート***がトリガー(=作成)されます。***イベント***情報はアラート作成時に自動的に***アラート***に詳細情報(details)として付加・管理されます。
- 「***インシデント***」： 前述の***アラート***によりトリガー(=作成)され、作成された***インシデント***内にトリガー元となる該当***アラート***が紐付けて管理されます。各***インシデント***はPagerDutyのサービス上で発生し、紐づけられたエスカレーションポリシーなどに基づきオンコール担当者に通知される、対処して解決する必要がある問題や課題を表します。
<br>
文章による説明だけですとちょっとイメージが掴みにくい・・・という方が多くいらっしゃるかと想像します。<br>次に、もう少しPagerDuty内での処理の流れを踏まえて説明します。

## イベント受信からオンコール担当者への通知までの流れ

PagerDutyでは、PagerDuty Event API V2、もしくはEvent API V2をベースに開発・提供された統合機能を通じて送信されたイベントを受信し、そこからPagerDuty内でアラートが作成されます。<br>また、その際に受け取ったイベント情報はアラートに追加されます。<br>その後の基本的な動作としては、インシデントが作成され、通知の緊急度やエスカレーションポリシーにおける通知先の設定などに基づいて、オンコール担当者への通知が行われます。
<br>
下記のフロー図では、上記流れの詳細を示しています。 

1. 各種監視ツールからPagerDutyに対しイベントが送信される
1. 受信したイベントからPagerDuty内にてアラートがTriggerされる
1. アラートからTrigger状態のインシデントが作成され、元となったアラートが当該インシデントに関連付けられる
1. インシデント作成によりオンコール担当者に通知が送信される
1. オンコール担当者がその通知を受信する<br> <br>

[イベント/アラート/インシデントのフロー図]
![フロー図2.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3621498/d3487f29-6011-a253-dbfd-c966e873afaa.jpeg)




## Webコンソール上での見え方

では実際にコンソール画面にて、***イベント***, ***アラート***, ***インシデント***それぞれがどのように確認できるか？を、Event API V2を通じて送信されたイベントをもとに見てゆきます。
（Event API V2の使い方は[こちら](https://developer.pagerduty.com/api-reference/368ae3d938c9e-send-an-event-to-pager-duty)をご参照ください）

#### [***アラート***]

これまでの順番と前後しますが、まず作成された***アラート***の確認方法としては、
<br> (1) コンソール上部の "Incidents">"Alerts"を開く
![Alertsメニューを開く.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3621498/60e5b81d-6d75-5f82-e06c-d27fd094d7bd.jpeg)

<br> (2) 表示されたアラート一覧から該当するアラートのSummary部分をクリック詳細を表示させる
![Alert_details1.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3621498/dfc88ac4-1caf-e818-24ef-9d966aae7664.jpeg)



#### [***イベント***]

前述しました様に、アラート作成時にイベント情報がアラートに追加されるため、イベント自体を単独で参照する機能はありません。<br>
従って参照したい場合には、イベントによって作成されたアラートの詳細情報から行います。
<br>(1) 先ほどの***アラート***情報の画面をスクロールダウンしてDetailsを表示させる
![Alert Detail内のイベント情報.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3621498/eb00e3cf-9c75-cb7a-d0ca-12845b3288c7.jpeg)
<br>(2) さらにその最下部にあるView Messageリンク（上記添付スクショの赤枠）をクリックして、***イベント***詳細情報を表示させる
![イベント詳細情報.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3621498/cb1b4f4f-559b-e487-e72b-679c749f5eca.jpeg)



#### [***インシデント***の]

最後に作成された***インシデント***の確認方法となります。


<br> (1) コンソール上部の "Incidents">"All Incidents"を開く
![All Incidentメニューを開く.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3621498/c0e7a27a-1f3c-8a57-f64b-6a196ee94c85.jpeg)

<br> (2) 表示された***インシデント***一覧から、該当する***インシデント***のTitle部分をクリックし、インシデント詳細を表示させる
また画面下部のAlertsタブ(=青枠)にあるように、紐付けられている***アラート***情報も参照可能
![Incident詳細.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3621498/d93aab8d-74ad-e0a4-7987-47f89dca2063.jpeg)

<br>※補足: PagerDutyでは、1つの***インシデント***に複数の***アラート***を紐付けて管理することにより、インシデント通知を受けるオンコール担当者にとって取り扱いやすい単位にて通知を受けることが可能となっています。
したがって、複数のアラートがグルーピングされている場合には、ここに複数の***アラート***が一覧として表示されます。




## さらに一歩踏み込んで： <br> ***イベント***/***アラート***/***インシデント***を階層構造で理解する

先ほど、”１つの***インシデント***に複数の***アラート***を紐づけて管理することが可能”、と言いました。また、***アラート***はその中に自動的に***イベント***を付加して管理する機能もあるとも説明しました。
<br> 実はもう一歩踏み込んで説明しますと、PagerDutyでは一つの***アラート***内に複数の***イベント***を紐付けて管理することができます。
この階層構造による管理機能により、複数のレイヤーで集約が行われ、より効率的にそれぞれを管理することが可能となっています。
<br>
イメージとしては下記になりますが、1つの***アラート***を”特定のデータ値”であったり"監視項目"として捉えていただくと、各***イベント***が、それぞれ特定の時点におけるデータの状態＝つまりスナップショットとも捉えていただけると思います。

[イベント/アラート/インシデントの階層構造]
![階層構造で管理.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3621498/b3260685-a857-82af-3bef-2d6f0ca08aa2.jpeg)

<br>ではこれがどの様にPagerDutyコンソール上で見えるかというと、以下の様になります。
<br>(1) 該当する***アラート***情報を開き、画面をスクロールダウンして"Alert Log"を表示させる
![Alert_Log.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3621498/a8d94bf6-a18b-0c82-0ec0-2c9ae8ce868e.jpeg)
※上記階層構造のイメージ図とAlert Logのタイムスタンプは異なっておりますが、ご了承ください。


<br>※補足: ちなみにですが、[イベント/アラート/インシデントの階層構造]で示された***インシデント***="App A SLO違反:Response Time"をResolved/解決するには、紐づけられた***アラート***それぞれ全てがResolvedになるか、インシデント自体を手動でResolveする必要があります。

## ここでちょっと注意ポイント

ここまで***イベント*** > ***アラート*** > ***インシデント***の流れにてそれぞれがトリガー＆作成される・・・といったお話をしてきましたが、実はアラートを作成をともわないインシデントがあります。
例えば下記方法や手段で作成されたインシデントは、アラート作成を伴いません。
- Webコンソールやモバイルアプリなどを通じて手動でトリガーされたインシデント
- REST API経由で作成されたインシデント 
    - (注意： イベント送信先となる上述の[PagerDuty Event API V2](https://developer.pagerduty.com/api-reference/368ae3d938c9e-send-an-event-to-pager-duty) と [PagerDuty REST API](https://developer.pagerduty.com/api-reference/a7d81b0e9200f-create-an-incident)は異なります）
<br>

したがって、もし ***アラート*** や***イベント***が見つからない（そもそも"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日間 無料トライアル](https://ja.pagerduty.com/sign-up/)