みなさん、こんにちは。
明るい笑顔がトレードマーク、ルイボスティーが大好きな芦沢(＠ashi_ssan)です。
インシデント管理、していますか？
PagerDutyはシステムのインシデント対応を一元化し、インシデント管理効率を向上させるツールです。
監視ツールとPagerDutyの連携は、基本的にAPIを利用して行われます。
しかし、従来の監視ツールであるZabbixやJP1などをシステムで利用している場合、ツールがAPIによるアラート通知にネイティブに対応していないことも考えられます。またアウトバウンド通信が制限された閉域網にシステムが構築されていて、インターネット向けにAPIを送信することが運用上難しいケースも考えられます。
ただ、そのような制約がある場合もAPI通知ではなくメール通知、アウトバウンド向けのメール送信が許可されていることが多く、メール経由でインターネットにアラートを送信することができます。
PagerDutyのEメールインテグレーション機能を利用すると、メール経由でのアラートを利用したインシデント管理ができます。これにより、APIや外部通信の制限を考慮せずPagerDutyにアラート送信可能となります。
本エントリでは主題の機能を使って、メールを送信しアラートを発報するところまでを検証してみます。
前提
前提として、事前にPagerDutyのアカウントを準備してください。
アカウントを持っていない方は、こちらを参考にトライアルアカウントを作成してみましょう。
また、今回紹介する手順は、以下PagerDutyナレッジベースにあるEmailインテグレーションガイドをベースとしたものです。
PagerDutyでは、アラートを設定する方法が3つあります。
- Rulessets
- 統合したツールから連携されるイベント(アラート)の内容によって、実行するアクションを設定したい場合
- Event Orchestrations
- 統合したツールから連携されるイベント(アラート)の内容によって、実行するアクションをネスト化して設定したい場合
- PagerDuty Service
- 統合したツールから連携されるイベント(アラート)の内容によるアクションの設定が不要なとき
今回アラートの内容に応じたアクションは設定しないため、一番シンプルなPagerDuty Serviceを利用した方法で実装します。
使ってみた
それでは、早速やっていきます。
PagerDutyの設定
PagerDutyコンソールの画面上部、Services > Service Directoryから、Service Directory にアクセスし、New Serviceをクリックしてください。
Service Directory の名称と説明を入力します。
続いて、エスカレーションポリシーを指定します。
エスカレーションポリシーとは、「アラートが発生した際に誰にどんな順番で通知するのか決めたルール」です。
詳しく知りたい方は以下のブログをご覧ください。
今回は事前に作成したものを利用しますが、新規のエスカレーションポリシーを作成して後で定義することも可能です。
次にノイズ削減(Reduce Noise)に関する設定項目です。
Alert Groupingは同様のアラートが発生した際に、1つのインシデントに統合することで通知ノイズを削減できる機能です。全ての機能について、PagerDuty AIOpsアドオン もしくはLegacy Event Intelligenceアドオンが有効になっている場合のみに利用できます。
- Intelligent
- 直近のコンテンツの類似性や過去に学習させたアラートをもとに、指定した時間内にトリガーされたアラートを機械学習ベースでグループ化(=1つのインシデントにまとめる)します。
- Content-Based
- コンテンツに含まれる要素（フィールド）を条件として設定し、条件に完全一致したアラートをグループ化します
- Time-Based
- アラートがトリガーされてから数えて事前に設定した時間内(アラート発生から2分以内など)にトリガーされたインシデントをグループ化します。
- Turn Off Alert Grouping
- アラートのグルーピングを利用しない
今回利用する検証アカウントではPagerDuty AIOpsアドオンが有効になってることもあり、ここではIntelligentを利用し、5分を指定します。
Transient Alerts（一時的なアラート）は「一過性のアラート」、つまり時間によって解決されるアラートに対して通知を一時停止できる機能です。
Auto-pause incident notificationsを設定すると、機械学習で検出された一過性のアラートに対して、指定した時間内の間通知を停止します
先述した通りアドオンが有効なアカウントなので、機能を有効化し5分を指定します。
続いて、インテグレーションするサービスを指定します。ここでEmailを指定してください。
そのまま、Create Serviceすると、Emailインテグレーションが作成できました。
Integration Email欄に表示されているものが、送信先のメールアドレスです。
デフォルトでは[Service Directory名].[ランダムな文字列]@[PagerDutyドメイン名].pagerduty.comの形式で設定されています。
後半のドメイン名(@以降)は変更できませんが、前半のユーザー名は任意の文字列に変更できます。
これでPagerDuty側の最低限の準備が完了しました。
通知テスト
発行したメールアドレスにメールを送信してテストしてみます。
任意のツール(今回はGmail)から、先ほど発行した送信先のメールアドレスにメールを送信します。
件名にTest Incident、本文にHello, PagerDuty!と入力してみました。
メールを送信してしばらく待つと、PagerDutyでインシデントが検知されました。
インシデントの詳細画面はこのようになっています。
画面下部のAlerts欄に、今回発報されたアラートの内容が表示されていました。
Summary欄にメールの件名が、DetailのBODY欄にメールの本文が入力されていますね。
続いて、アラートグルーピングが機能することを期待してメールを3通連続で送ってみます。
件名にTest Incident[1〜3]、本文にHello, PagerDuty[1〜3]!と、括弧内の数字を増やしてメールを連続して送っていきます
メールを3通送信し終わってしばらくすると、PagerDutyでインシデントが検知されます。一番はじめに送信したTest Incident1の名前で検知していますね。
しばらくすると、Alerts欄に続いて送った２件のメールが追加されました。
インシデント一覧にTest Incident2,3は表示されていないですし、想定通りグルーピングされていることがわかります。
検証は以上になります。
参考: インシデントのステータス変更
参考までにですが、インシデントのステータスのライフサイクルについて記載しておきます。
インシデントを確認したら、私が対応します！という意思表示をするため、Acknowledge しておきます。
四角で囲ったステータスがTriggered からAcknowledge に変わりました。
Resolved をクリックするとインシデントがクローズされます。
今回は、テストイベントのなのでそのままクローズさせてしまいました。
エスカレーションポリシーの設定によっては、インシデントの状態をTriggeredのままにしておくと通知が延々と届くことになりかねないため、テストインシデントのクローズは忘れずにやっておきましょう。
最後に
ここまで見ていただいたように、PagerDutyのEメールインテグレーションによって非常にシンプルな設定で、通知先のメールアドレスの発行・アラートの発報まで簡単に実装・テストできます。
主題とは関係ないですが、PagerDutyのアラートグルーピングの機能についても検証しました。AIOpsの機能を利用すると同時に発生したアラートが集約されて、ノイズが減りオンコールの負荷削減が期待できそうです。
この記事を見てPagerDutyについて気になった方へ。14日間の無料トライアルが利用できますのでトライアルアカウントの作成からお試しください。
以上、芦沢(＠ashi_ssan)でした。
13
