PR

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

2018年3月16日(金)
尾形 暢俊

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

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

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

画面1 Integration Type

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

PagerDuty側の設定

画面2 Add Integration

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

画面3 Create API Key

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

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

Datadog側の設定

画面4 Datadog Integrations

メニューのIntegrationsを選択し、

画面5 PagerDutyで検索

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

画面6 PagerDuty Integration

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

画面7 確認

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

画面8 サービスの選択
画面9 設定画面

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

連携の確認

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

画面10 DatadogEvent stream

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

画面11 インシデントテスト

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

インシデントの抑制

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

Maintenance Window

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

画面12 Maintenance Windowの設定

次に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を使うことができるようになります。

画面13 Event Ruleの作成

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

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

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

画面14 Custom Details

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

画面15 suppressのテスト

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

画面16 SuppressされたIncident

Alert Grouping

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

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

画面17 Groupingの設定

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

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

画面18 Groupingのテスト

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

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

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

スマートニュース株式会社

スマートニュース株式会社エンジニアリングマネージャ。Site Reliability Engineering担当。オペレーションの自動化、コード化、標準化やモニタリング、プロビジョニング、デプロイの整備、開発やインシデント対応のフロー整備、ログ解析基盤の改善などチーム横断的な業務を行っている。
Twitter:@nobu666

連載バックナンバー

Think IT会員サービス無料登録受付中

Think ITでは、より付加価値の高いコンテンツを会員サービスとして提供しています。会員登録を済ませてThink ITのWebサイトにログインすることでさまざまな限定特典を入手できるようになります。

Think IT会員サービスの概要とメリットをチェック

他にもこの記事が読まれています