Project Description
本記事は米国PagerDuty社のサイトで公開されているインテグレーションガイドをそのまま日本語に翻訳したものです。日本語環境での動作を保証するわけではありません。原文はこちらを参照してください。
Prometheusは、オープンソースのシステム監視とアラートツールキットです。多次元データモデル、多次元構造を活用するための柔軟なクエリ言語、分散ストレージに依存せず、時系列のコレクションはHTTP経由のプルモデルを介して行われます。時系列のプッシュは中間ゲートウェイ経由でサポートされ、ターゲットはサービスの検出や静的な設定が可能で、グラフ化とダッシュボードの複数のモードがサポートされています。
Prometheus Alertmanager v0.11以降の重要な注意事項：AlertmanagerはEvents API v2をサポートしました。ただし、routing_keyプロパティを設定してv2を使用する場合、routing_key値に対応するインテグレーションタイプもEvents API v2でなければなりません。PagerDutyのインテグレーションタイプとしてPrometheusを選択した場合は、Events API v1タイプを使用し、代わりにservice_keyプロパティの値を設定する必要があります。
PagerDutyでの作業
- ConfigurationメニューからServiceを選択します。
- 新しいサービスを作成する場合はServiceページで
- +Add New Serviceをクリックします。
- 既存のサービスに追加する場合は、サービスの名前をクリックします。その後、Integrationsタブをクリックし、+New Integrationボタンをクリックします。
- Integration Typeメニューからアプリケーションを選択し、Integration Nameを入力します。新しいサービスを作成する場合は、General Settingsで、新しいサービスのNameを入力します。次にインシデント設定で、新しいサービスのEscalation Policy（エスカレーションポリシー）、Notification Urgency（通知の緊急性）、Incident Behavior（インシデントの動作）を指定します。
- Add ServiceまたはAdd Integrationボタンをクリックして、インテグレーションを保存します。するとサービスのIntegrationsページにリダイレクトされます。
- 新しいインテグレーションのIntegration Keyをコピーします。
Prometheusサーバで
- まだインストールされていない場合は、Prometheus Alertmanagerをインストールしてください。このインテグレーションには、PrometheusからPagerDutyへのルーティングアラートを処理するため、Alertmanagerが必要です。
- Alertmanager設定ファイルがない場合は作成します。設定ファイルの例はGitHubにあります。
- 設定ファイルにPagerDutyの
receiverを作成します。インシデントを処理するチームの名前やPagerDutyのインテグレーション名などのnameをレシーバに付け、以前にコピーしたインテグレーションキーをservice_keyフィールドに貼り付けてから、設定ファイルを保存します。
レシーバー:
– name: YOUR-RECEIVER-NAME
Pagerduty_configs:
– service_key: YOUR-INTEGRATION-KEY
- Prometheusのデフォルト
routeを設定して、カスタムルートと一致しないすべてのアラートを新しいPagerDutyreceiverに送信することができます。以下はデフォルトrouteをどのように設定するかを示す例です。
route:
Group_by: [cluster]
受信者: YOUR-RECEIVER-NAME
- さまざまな
receiverアラートを送信するようにカスタムroutesを設定することもできます。たとえば、重大度がwarningのアラートのみをPagerDutyに送信する場合は、別のデフォルトルートを設定し、次のような特別なwarningルートを作成します。
route:
– match
severity: ‘warning’
receiver：YOUR-RECEIVER-NAME
- Prometheus Alertmanagerの強力な
routesとreceiver設定オプションにより、異なるPagerDutyインテグレーションキーで複数のreceiverを構成し、異なるroutesによる特定のタイプのアラートを異なるreceiverに送信するように設定できます。
ここでは、データベースサービスのアラートをキャプチャすると、DBAに直接通知するPagerDutyサービスにリンクされた receiver に送信し、それ以外のすべてのアラートは異なるインテグレーションキーを持つキーデフォルトの receiver に送る設定例を示します。
route:
group_by: [cluster]
receiver: DEFAULT-RECEIVER
group_interval: 5m
route:
– match:
service: database
receiver: PRIMARY-INTEGRATION-KEY
receiver:
– name: DEFAULT-RECEIVER
pagerduty_configs:
– service_key: PRIMARY-INTEGRATION-KEY
– name: DATABASE-RECEIVER
pagerduty_configs:
– service_key: DATABASE-INTEGRATION-KEY
- AlertManagerを起動するか、すでに実行している場合は設定の変更を有効にするために再起動してください。
- これで、PrometheusはPagerDutyでインシデントをトリガーして解決できるようになりました。次の
curlコマンドを使用してテストインシデントをトリガーすることで、これを確認できます。
curl -d ‘[{“labels”:{“アラート名”：”PagerDuty Test”}}]’ http:// localhost:9093 /api/v1/alerts
よくある質問
Prometheusでアラートが解決されると、PagerDutyインシデントは解決されますか？
send_resolved オプションが false に設定されていなければ答えはYesです。デフォルト値は true ですので、PagerDutyインシデントを自動的に解決するために send_resolved: true を指定する必要はありません。
また、解決通知が送信されるのが次の group_intervalまで待たされることがあり、Prometheusチームに従って通知をPagerDutyに送信する「ベストエフォート」のみが行われます。
複数の異なるPrometheusアラートに対して1つの通知しか受け取れません。どうすればこの問題を解決できますか？
PagerDutyルートのmatchおよびgroup_byオプションを調整してみてください。アラートイベントが固有の問題に関係しているかどうかを判断するために使用される重複排除キー（別名インシデントキー）は、これらのオプションに基づいて生成されます。一連のアラートがgroup_byのプロパティと同じ値を持つ場合、重複排除キーの値は同じになるため、新しいトリガーではなく、最初のアラート／インシデントにマージされます。
