デジタルイノベーションラボのゴルゴです。
先日、PagerDutyとSentryを活用して、バッチ処理で特定のアラート条件を満たした際に、担当の営業にオートコールを行うシステムを構築しました。今回はそのシステムの紹介をしたいと思います。
背景
ラボでは以前から、特定のアラートが発生すると営業部に対してSlackで通知を行っていたのですが、Slack通知だけでは担当者が自ら確認する必要があります。すぐに気付いて対応してもらいたいので、電話でもコールされるようにしたかったのです。
ラボの運用チームがアラートを検知して、手動で営業部にコールする方法も考えられましたが、それでは運用チームの負担が大きくなってしまうので、できるだけ運用チームを介さずに、直接営業部にオートコールを行うことを目指しました。
幸い、ラボ内では既にシステム障害を検知して運用チームにオートコールを行う仕組みがあったので、今回はその既存の仕組みを応用し、特定のアラート時には営業部に直接オートコールを行うようシステムを構築しました。
利用サービス
Sentry https://sentry.io/welcome/
アプリケーションに組み込んでおくことで、エラーの発生検知と追跡を支援してくれるサービスです。 今回は特定の条件を満たした場合にアラートを発生させ、PagerDutyに通知するために使用します。
PagerDuty https://www.pagerduty.co.jp/
インシデント対応の自動化を提供するクラウドサービスで、システム障害や重要なイベントが発生した際に、適切なメンバーにリアルタイムでアラートを送信してくれます。 今回はSentryからのアラートを受け取り、受電担当者にオートコールするために使用します。
通知の流れ
今回実現したシステムでの通知の流れです
導入までの流れ
1.営業部門との調整
まず最初に行ったのは担当部署との調整です。課題の説明と、オートコールの受電担当者を決めて貰うよう相談し、担当者が受電したあとにどのような対応をしてもらうかも予め調整しておきます。
2.PagerDutyとSentryのIntegration設定
2.0.サービスの登録
今回はPagerDutyとSentryいずれのサービスもラボ内で導入済みだったのでアカウント作成はしていませんが、必要に応じてそれぞれのサービスのアカウント作成から行ってください。
2.1.PagerDuryにサービスの作成
公式ガイドのサービスを作成を参考にして、今回のシステム用に新規のサービスとエスカレーションポリシーを作成します。 エスカレーションポリシーには最終的には担当部門のメンバーを登録しますが、この時点では開発メンバ等を登録しておくといいでしょう。
2.2.PagerDuty側にインテグレーション設定
サービスを作成したら今度はSentryとのインテグレーション設定を既存のサービスにインテグレーションを追加するを参考に行います。 設定すると Integration Key が生成されますが、このKeyはあとでSentry側に設定する必要があるので控えておきます。
2.3.Sentry側にIntegration設定
今度はSentryの管理画面で、PagerDutyへのIntegration設定を追加します。 Sentryの公式ガイドを参考に行ってください。
3.バッチ設定
続いて実際にバッチの改修に入ります。
3.1.バッチへのSentry組み込み
まずはバッチからSentryへメッセージを送れるようにSentrySDKの組み込みと設定が必要です。今回のバッチはMicronautで実装しているのでJavaの設定手順に従ってSDK組み込みと設定を行いましたが、プラットフォームによって設定方法は異なるので、こちらから調べて設定してください。
3.2.アラートメッセージ送信
設定ができたら、実際にバッチで条件を満たした際に、Sentryへイベントメッセージを送るようにコードを修正します。 ここで設定したメッセージが最終的にPagerDutyからの通知でも使用されるので、ある程度内容がわかるようにしておきます。
// 通知条件を満たした場合の処理
Sentry.captureMessage("XXXでエラーが発生しました。至急Slackを確認して対応してください", SentryLevel.ERROR)
4.Sentry管理画面でのアラート設定
次はSentryの管理画面で設定を行います。
Sentryにログインし、Alerts > Create Alerts でアラート条件の作成をします。
特に大切なのがSet Conditionsで、次のように WHEN, IF, THEN の設定をします。
WHEN
イベントを受信のたびにオートコールしたいので、毎回アラートが作成されるように条件は全て消しておきます。
初期状態だとA new issue is createdが設定されていますが、これだと最初の一回しかアラートが発動しないので注意してください。
しばらく条件を無しにできることに気付かず苦労しました。
IF 今回はイベントの message に 先ほど設定したメッセージを含んでいることを条件にします。
THEN
PagerDutyへ通知を送りたいので、Send a notification PagerDuty を選択し serviceにはIntegration設定しておいたサービスを選びます。
5.設定確認テスト
ここまでの設定を終えたら、バッチからアラートメッセージ送信→Sentryでのアラート検知→PagerDutyで検知しオートコール、という一連の流れを確認できるはずなので、検証環境等を使って動作確認しておきます。
6.受電担当者のPagerDutyアカウント作成
動作確認がうまくいったら、PagerDutyのエスカレーションポリシーに登録するため、受電担当者のPagerDutyアカウントを作成します。 ユーザーの追加ガイドを参考に、先に決めておいた受電担当者に招待メールを送り、登録作業をしてもらいます。
7.エスカレーションルール設定
複数の受電担当者がいる場合には通知の順序や、一人目が応答しない場合に次の人に連絡するまでの間隔等を設定します。
8.テストコール
エスカレーションルールへの設定順の確認や、実際に受電する人に慣れてもらうためにもテストコールをします。 PagerDutyではオートコールが掛かってきた際にダイヤルボタン回答で、Acknowledge（対応する）や、Resolved（解決済み）にステータスを設定できるのですが、着信に出なかったり応答してもステータスを回答しなければ、次の受電者へ通知がされます。 テストコールを実施してエスカレーションルールどおりになっていることを確認できれば、全ての設定が完了です。
お疲れ様でした。
終わりに
今回の仕組みの導入により、運用の負荷を上げずに担当部署に緊急連絡することができるようになりました。 導入しておよそ１ヶ月ですが「休日にアラートのSlack通知が発生しても気付けないかも。。」といった心配事が減り、こころなしか眠りが深くなった気がします（笑。 これからも、充実した眠りのために？自動化をすすめていきたいと思います。
この記事がどなたかの助けになれば幸いです。
