New Relicで監視しているシステムの異常を迅速に検知し、適切な担当者に通知することは、サービスの安定稼働に不可欠です。本記事では、New Relicのアラートをインシデント管理ツールであるPagerDutyに連携する方法を、「サービス単位の統合」と「アカウント単位の統合」の2つの側面から詳しく解説します。
はじめに：なぜNew RelicとPagerDutyを連携するのか
New Relicは強力な監視機能を提供しますが、インシデント発生時の通知、オンコール管理、エスカレーション、インシデントライフサイクル管理はPagerDutyの得意分野です。この2つのツールを連携することで、監視からインシデント対応までの一貫したワークフローを構築し、ダウンタイムの最小化と運用効率の向上が期待できます。
New Relicのアラートの基本
New Relicのアラートは以下の要素で構成されます。
-
アラート条件 (Alert Conditions): 特定のメトリックやログ、NRQLクエリの閾値に基づいてインシデントをトリガーするルール
-
ポリシー (Policies): 複数のアラート条件をまとめるグループ。インシデントの集約方法を定義します
-
宛先 (Destinations): アラートの通知を送信する宛先を定義する機能。これには、PagerDuty、メールアドレス、Slackチャンネル、Webhookなどが含まれます。宛先は、どのサービスに対して通知を送るかを指定する役割を果たします
-
ワークフロー (Workflows): アラートが発生した際にどのような処理を実行するかを定義する機能。ここでは、特定のアラートの内容に基づいて、通知を送信するDestinationを決定したり、通知メッセージをカスタマイズしたりなどを設定できます
PagerDutyの基本概念
PagerDutyはインシデントの管理とオンコール対応を効率化するためのツールです。
-
サービス (Service): PagerDutyにおける監視対象の論理的な単位。アプリケーションやインフラのコンポーネントに対応します。インシデントはこのサービスに対して発生します
-
エスカレーションポリシー (Escalation Policy): インシデント発生時に誰に、どのような順番で、どのくらいの時間で通知するかを定義します
-
オンコールスケジュール (On-Call Schedule): エスカレーションポリシーで参照される、オンコール担当者のローテーションを定義します
サービス単位の統合：特定のPagerDutyサービスと連携する
サービス単位の統合 (Service Integration) は、New Relicの特定のアラートを、PagerDutyの特定のサービスに連携したい場合に適しています。これは、各開発チームが独立したサービスを運用し、それぞれが自身のサービスのインシデント対応を担当するようなマイクロサービスアーキテクチャや分散型組織に特に有効です。
特徴
PagerDutyのEvents APIキーを使用: PagerDutyサービスごとに生成される専用のAPIキーを利用します。
-
単方向連携: 基本的にNew RelicからPagerDutyへのインシデント作成のみが行われます（New Relic上でPagerDutyのステータス変更は反映されません）
-
New Relic側の設定がシンプル: 設定が比較的簡単で、特定のPagerDutyサービスとNew Relicのワークフローを1対1で紐付けます
連携手順
1. PagerDuty側の設定
PagerDutyサービスの作成または選択:
PagerDutyコンソールにログインし、連携したいサービスを選択するか、新規にサービスを作成します。
サービスの設定画面で Integrations タブを開き、Add an Integration をクリックします。
New Relic Integrationの追加:
検索バーで「New Relic」と入力し、「New Relic Events API」を選択して追加します。
追加された統合の設定からキーを確認します。
「Integration Key (Events API Key)」が生成されています。このキーはNew Relic側の設定で必要になるため、控えておきましょう。
2. New Relic側の設定
PagerDuty Destinationの作成:
New Relicコンソールにログインし、Alerts > Destinations に移動します。
Add a destination をクリックし、PagerDuty を選択します。
Integration type で「Service integration」を選択します。
PagerDutyで取得した Integration Key を入力し、Destination name を分かりやすい名前に設定します（例: PagerDuty_ServiceX）。
Save destination をクリックして保存します。
Workflowの作成とDestinationへの紐付け:
Alerts > Workflows に移動し、Create a workflow をクリックします。
Workflow の名前を設定し、PagerDutyに送信したいアラートを選択するための Filter を設定します（例: 特定のポリシー名、エンティティ名など）。
Add channel の中から PagerDutyを選択し、PagerDuty destination から作成したを選択し、先ほど作成したPagerDutyのDestination (PagerDuty_ServiceX) を選択します。
必要に応じてメッセージテンプレートをカスタマイズし、「Save message」をクリックします。
アカウント単位の統合：PagerDuty の高度な機能を活用する
アカウント単位の統合 (Account integration) は、New Relicの全てのアラート（または一部）を PagerDuty アカウント全体と連携し、双方向同期や高度なルーティングを活用したい場合に適しています。これは、中央集権的な運用チームが複数のサービスのアラートを一元的に管理する場合や、PagerDuty のインシデント管理機能を最大限に活用したい場合に特に推奨されます。
特徴
PagerDuty の REST API キーを使用: PagerDuty アカウント全体に紐付く API キーを利用します。
双方向同期: PagerDuty 上でインシデントが解決されると New Relic のアラートも自動的に解決されるなど、ステータスが同期されます。
単一の New Relic Destination から複数の PagerDuty サービスへルーティング可能: New Relic のワークフロー内で PagerDuty のどのサービスにアラートを送信するかを柔軟に設定できます。
連携手順
1. PagerDuty側の設定
REST APIキーの生成:
REST API キーには General access key と Personal user tokens の2種類があります。今回は Personal user tokens を使用する際の手順を紹介します。
PagerDuty コンソールにログインし、MyProfile > User Settings に移動します。
Create API User Token をクリックします。
Description を設定し（例: New Relic Integration）、必要に応じてAPIの権限を設定します。
生成された API Key を控えておきましょう。このキーはNew Relic側の設定で必要になります。
2. New Relic側の設定
PagerDuty Destinationの作成:
New Relicコンソールにログインし、Alerts > Destinations に移動します。
Add a destination から PagerDuty を選択します。
Integration type で「Account integration」を選択します。
PagerDutyで生成した API Key を入力し、Destination name を分かりやすい名前に設定します（例: PagerDuty_Account_Integration）。Test connection を実行して「Connection successful」が表示されることを確認してください。
Save destination をクリックして設定を保存します。
Workflowの作成とDestinationへの紐付け:
Alerts > Workflows に移動し、Add a workflow をクリックします。
Workflow の名前を設定し、PagerDutyに送信したいアラートを選択するための Filter を設定します。
Add channel の中から PagerDutyを選択し、PagerDuty destination から作成した Destination (PagerDuty_Account_Integration) を選択します。
ここで重要なのは、PagerDuty Service で、この workflow で発生したアラートをどの PagerDuty サービスに送信するかを指定することです。複数のサービスがある場合、必要に応じて workflow を分けることでルーティングを分岐させることも可能です。
必要に応じてメッセージテンプレートをカスタマイズし、Save をクリックします。
どちらの統合タイプを選ぶべきか？
| 項目 | サービス単位の統合 | アカウント単位の統合 |
|---|---|---|
| API キー | PagerDutyサービスごとに生成されるEvents API キー | PagerDuty アカウント全体に紐付くREST API キー, ユーザーに紐づく API キー |
| 同期 | 基本的に単方向 (New Relic -> PagerDuty) | 双方向同期 (PagerDuty での解決が New Relic にも反映される) |
| ルーティング | New Relic の Destination ごとに特定の PagerDuty サービスへ通知 | 単一の New Relic Destination から、Workflow 内で複数の PagerDuty サービスへルーティング可能 |
| 複雑度 | 設定が比較的シンプル | やや複雑だが、より柔軟な設定が可能 |
| 適したケース | 各チームが独立したサービスを管理するマイクロサービスアーキテクチャ、小規模な組織 | 中央集権的なアラート管理、大規模な組織、PagerDuty の高度な機能を活用したい場合 |
連携におけるベストプラクティスと考慮事項
アラートの粒度とアクション可能性: アラートは「アクション可能」であるべきです。通知を受け取った担当者が何を行うべきか明確になるように、詳細な情報を含めましょう。アラート疲労を避けるために、本当に必要なアラートのみを PagerDuty に送信することが重要です。
Runbook の整備: PagerDuty のインシデントに、対応手順や関連ドキュメントへのリンク（Runbook URL）を含めることで、迅速な初動対応を支援できます。
メッセージテンプレートの活用: New Relic のワークフローでは、PagerDuty に送信されるメッセージをカスタマイズできます。インシデントの状況を把握しやすいように、関連情報を盛り込みましょう。
通知の抑制と集約: PagerDuty のエスカレーションポリシーやサプレッションルールを活用し、重複したアラートや一時的な障害による過剰な通知を防ぎましょう。
定期的な見直し: アラート条件、ポリシー、エスカレーションポリシー、オンコールスケジュールは、運用状況の変化に合わせて定期的に見直し、最適化することが重要です。
トラブルシューティングのヒント
API キーの確認: New Relic と PagerDuty で設定した API キーが正しいか、権限が適切かを確認してください。
ワークフローのフィルター: New Relic の workflow で設定したフィルターが意図した通りにアラートをキャッチしているか確認してください。
New Relic の Workflows 実行履歴: New Relic の Workflows 画面で実行履歴を確認し、通知が正しく送信されているか確認できます。
まとめ
本記事では、New Relic のアラートと PagerDuty の連携について、サービス単位とアカウント単位の2つの方法を解説しました。それぞれの特徴と連携手順を理解し、貴社の運用体制やニーズに合わせて最適な統合方法を選択してください。適切に連携することで、システムの安定稼働と迅速なインシデント対応を実現できるでしょう。
New Relicでは、新しい機能やその活用方法について、QiitaやXで発信しています！
無料でアカウント作成も可能なのでぜひお試しください！
New Relic株式会社のX(旧Twitter) や Qiita OrganizationOrganizationでは、
新機能を含む活用方法を公開していますので、ぜひフォローをお願いします。
無料のアカウントで試してみよう！
New Relic フリープランで始めるオブザーバビリティ！
