モニタリングシステム連携とインシデントの抑制

連載3回目は、外部のアプリケーションと連携させて、様々なアラートをPagerDutyで一元管理する方法をご紹介します。

モニタリングシステムとの連携

第2回の冒頭でも書きましたが、PagerDuty自体にはサーバやサービスの状態を監視する機能がありません。監視機能はほかのツール、サービスを利用します。具体的には、Serviceの設定項目にあるIntegrationsタブで使用するモニタリングシステムを選択できます。

現在約200種類のシステムと連携が可能となっており、著名なものはほぼ全てカバーされています。モニタリングシステムではない JIRA 、Slack、Zendeskといったサービスとも連携させることができるので、カスタマーサポートなどの用途でも利用できるようになっています。ここではモニタリングSaaSであるDatadogとの連携を例に進めたいと思います。

PagerDuty側の設定

プルダウンから「Datadog」を選んでAdd Integrationボタンをクリックします。この時点で Integration Key というものが払い出されて一覧に表示されていますが、今後の手順に沿って作業すれば自動的に入力されるため、特に気にしなくても問題ありません。基本はこれで終わりなのですが、最初の1回のみ、Datadogが使用するAPI Keyを払い出す必要があります。ConfigurationのAPI Accessから、Create New API Keyをクリックします。

Datadogのv1のAPIは2018年10月19日に廃止されることがアナウンスされていますので、API versionはv2を使ったほうが良いでしょう。Create KeyボタンをクリックするとAPI Keyが表示されますが、API Keyはこの一度しか見ることができません。必ずコピーすることをお忘れなく。後ほどDatadog側の設定でこのAPI Keyが必要になります。

次にDatadog側でPagerDutyに通知を飛ばすように設定する必要があります。

Datadog側の設定

メニューのIntegrationsを選択し、

テキストボックスにPagerDutyと入力するとAvailableのボタンが表示されます。マウスオーバーするとInstallボタンになるのでクリックします。ダイアログが表示されるのでConfigurationタブをクリックするとPagerDutyとのインテグレーション確認画面になります。

ここでAlert with PagerDutyボタンをクリックするとPagerDutyにリダイレクトされます。

PagerDutyへのログインにメールアドレスとパスワードを使っている場合は上段、シングルサインオンを使っている場合は下段をそれぞれ埋めてボタンをクリックします。次の画面で、PagerDutyのどのサービスを連携させるか選択します。

すると自動的に先ほどのIntegration Keyが入力されます。API Token欄に、PagerDutyのAPI Keyをペーストします。これは最初の1回のみ行なえばよく、Serviceを追加する際には不要です。

連携の確認

ここまで終わったら、きちんと連携できているか実際に動かして確認してみましょう。Datadog の Event streamで、テキストボックスに @pagerduty と打ち込むと Suggest が出てくるはずです。先ほどIntegrationで設定したServiceを選択します。

ここでは "@pagerduty-TEST_Service 連携テストです" と入力して Post してみます。

無事にインシデントがトリガーされました。

インシデントの抑制

ときにはインシデントを抑制したくなる場合もあります。例えば計画的にあるサーバをシャットダウンしたいとか、特定のサービスにおいてサーバを一時的にダウンさせてメンテナンスを行うということは、運用上よくあることだと思います。PagerDutyではいくつかの方法でインシデントを抑制できます。

Maintenance Window

Maintenance Windowを作成することで、特定のサービスのインシデントを特定の時間抑制できます。ConfigurationのServicesからMaintenance Windowsタブを開き、Schedule Maintenanceボタンをクリックします。

次にMaintenanceに入れたいサービスと時間を設定することで、そのサービスに対するインシデントは指定した時間帯では抑制されます。Maintenance Window内に発生したインシデントについては、完全に無視されてどこにも記録されませんのでその点だけご注意ください。

Event Rule

Serviceをまるごと黙らせてしまうMaintenance Windowでは都合が悪いこともあります。例えばプロセスの死活監視については抑制したいが、ロードアベレージの監視は抑制したくないというようなことがあります。そういう場合はEvent Ruleによってきめ細かくインシデントを抑制できます。

Event RuleはService Detailsの画面にEvent Rulesというタブがあり、そこで設定できます。もしEvent Rulesタブがない場合は、Service設定のIncident BehaviorがCreate incidentsに設定されています。Create alerts and incidentsに変更するとEvent Rulesを使うことができるようになります。

最初に event field を選択します。指定したfieldの特定の値を含む／含まない、存在する／しない、正規表現でマッチする／しないという設定で条件を設定します。そこで条件が合致したインシデントに対して、抑制するか、あるいはseverity（重症度）を変更するかというactionを選べます。

event fieldですが、あらゆるインシデントに上記すべてのものが含まれているわけではないことに注意が必要です。インシデントをトリガーする際に設定されるものなので、利用しているモニタリングサービスによって設定されるevent fieldとその値は異なります。custom details も同様で、モニタリングサービス次第で変わってきます。

実際に試してみるため、以下のようなEvent Ruleを設定してみます。custom detailsのbodyにsuppressという文字が含まれていたらインシデントを抑制します。

先程と同様にDatadogからsuppressという文字を含めてアラートを送信します。

送信してもインシデントが起きないはずです。Service設定のIncident BehaviorがCreate alerts and incidentsになっている場合、Incidentにならない場合でもAlerts画面で確認できます。

Alert Grouping

最後にGroupingをご紹介します。例えば1分おきに負荷がスパイクするような状況になった場合、高負荷でインシデントがトリガーされるがすぐにResolve（解決）され、また1分後にトリガーされ……と連続で同じインシデントが来てしまうことになります。対応作業中なのに再度電話が鳴ると煩わしいです。そういう場合はGroupingを設定しましょう。

Service設定のAlert Grouping Behaviorで、Time-based alert grouping for the following durationを選択し、抑制したい時間をプルダウンから選びます。

この設定をすることで、最初の1回のみインシデントがトリガーされ、指定時間以内のインシデントはトリガーされなくなります。

一覧では1つだけがトリガーされているように見えますが、

実際にはこのようにまとめられており、1つResolveするとどちらもResolveされました。SMSも最初の1通しかきていません。

インシデント抑制のまとめ

インシデントを抑制する方法を3つご紹介しました。どの方法にも一長一短ありますので、その時々でどの方法を選ぶか適切に決める必要があります。不用意にMaintenance Windowを設定すると本来気付くべきだったことに気付かない、という事になりかねません。また、どれもサービス単位での設定となるため、いちばん重要なのはこのサービスをどの粒度で分けて作成するかです。開発や運用の体制に大きく依存するので、なかなかベストプラクティスと呼べるものはないと思いますが、インシデントを抑制するのはサービス単位でしかできない、ということを念頭に入れて設計するのがよいでしょう。