GA版のDevOps AgentでPagerDutyを連携してみた
こんにちは。たかやまです。
以前、AWS DevOps Agent（Preview）でPagerDutyと連携する方法を検証した際は、Webhookを経由する必要がありました。
PagerDutyからDevOps Agentに調査をトリガーするために、Lambda関数でWebhookペイロードを変換する仕組みを自前で構築していたのですが、GA版ではPagerDutyがネイティブなCapability Providerとして追加されました。
そこで今回はGA版のDevOps AgentでPagerDutyをネイティブに連携する手順を紹介します。
さきにまとめ
- GA版AWS DevOps AgentでPagerDutyがネイティブなCapability Providerとして追加された
- OAuth 2.0（Scoped OAuth）による認証で、自前での設定（Webhook経由でのリクエスト送信等）が不要
- PagerDuty連携をすることでDevOps Agentの調査結果が自動でPagerDutyのNotesに追加されるようになる
- OAuth連携により双方向のデータアクセスが可能で、DevOps AgentがインシデントにアクセスするだけでなくPagerDutyのオンコールスケジュールやサービス情報も参照できる
やってみる
AWS DevOps AgentのPagerDuty連携は、OAuth 2.0（Scoped OAuth）を使用してPagerDutyアカウントに接続します。
この連携により、DevOps Agentはインシデント調査や自動応答の際に以下の情報にアクセスできるようになります。
- インシデントデータの参照・更新
- オンコールスケジュールの確認
- サービス情報の取得
PagerDutyの登録はAWSアカウントレベルで行われ、そのアカウント内のすべてのAgent Spaceで共有されます。
PagerDuty側の設定
まず、PagerDuty側でOAuthアプリケーションを作成します。
PagerDutyにログインし、「Integrations」>「App Registration」を選択します。
「New App」ボタンをクリックして新しいアプリを作成します。
認証方式は「OAuth 2.0」を選択します。
ドキュメントに記載されている最低限のスコープとして「Permissions」で以下の権限を付与します。
| スコープ | 説明 |
|---|---|
incidents.read |
インシデントの読み取り |
incidents.write |
インシデントの更新 |
services.read |
サービス情報の読み取り |
設定すると「Client ID」と「Client Secret」が発行されます。これらの値は後のAWS側の設定で使用するので控えておきます。
また、AWS DevOps AgentとPagerDuty間の双方向通信を可能にするために、「Events Integration」を有効にします。
設定はそのままで「Save」ボタンをクリックします。
「Events Integration」に ✅ がついていればOKです。
AWS DevOps Agent側の設定
Step 1: PagerDutyの登録（Capability Providers）
AWSマネジメントコンソールにサインインし、DevOps Agentコンソールに移動します。
左ペインの「機能プロバイダー」（Capability Providers）ページを開きます。
「コミュニケーション」（Communication）セクションにPagerDutyが表示されているので、「Register」を選択します。
「PagerDutyでのアクセスの設定」（Configure access in PagerDuty）のガイドに従って設定を進めます。
- ステップ1
- PagerDutyのリージョン（USまたはEU）選択
- PagerDutyのサブドメインを入力（例:
your-company）
- ステップ2
- アクセス許可スコープを選択（スペース区切り）
incidents.read incidents.write services.read
- アクセス許可スコープを選択（スペース区切り）
- ステップ3
- クライアント名 : 任意の識別名
- クライアント ID : PagerDuty設定で取得したClient ID
- クライアントシークレット : PagerDuty設定で取得したClient Secret
設定内容を確認し、「追加」 をクリックします。
すると、エラーがでました。権限的に webhook_subscriptions.readとwebhook_subscriptions.writeも必要のようです。
最終的な権限は以下のとおりです。
| スコープ | 説明 |
|---|---|
incidents.read |
インシデントの読み取り |
incidents.write |
インシデントの更新 |
services.read |
サービス情報の読み取り |
webhook_subscriptions.read |
Webhookの読み取り |
webhook_subscriptions.write |
Webhookの更新 |
PagerDuty側でwebhook_subscriptionsの権限を付与して再登録します。
DevOps Agent側の「アクセス許可スコープ」も更新して再登録します。
権限が足りていれば「Currently registered」にPagerDutyが表示され、機能プロバイダーとしては追加完了です。
Step 2: Agent Spaceへの追加
Capability Providerとして登録しただけでは、まだAgent Spaceでは利用できないため、個別のAgent Spaceに追加する必要があります。
DevOps Agentコンソールで対象のAgent Spaceを選択し、「Capabilities」タブを開きます。
「Communications」セクションの「追加」をクリックし、利用可能なプロバイダーの一覧からPagerDutyを選択します。
選択画面ではPagerDutyで用意されているService Directoryが表示されます。
関連付けるService Directoryを選択して「サービスを関連付ける」を選択します。
「コミュニケーション」にPagerDuty連携が表示されていれば完了です。
動作確認
ではCloudWatch Alarmでテストイベントを作成してPagerDutyにインシデントを作成してDevOps Agentが起動することを確認します。
テスト用の環境は公式ドキュメントで用意されている オプションB を使ってテストします。
テスト用の環境とPagerDutyとの連携はすでに設定済みです。
Amazon CloudWatch Integration Guide | PagerDuty
今回の構成は以下のとおりです。
こちらの状態でテスト用のLambda関数でエラーを発生させるとPagerDutyにインシデントが作成されます。
インシデント作成を契機にPagerDutyからDevOps Agentに調査をトリガーしていることがNotesから確認できます。
数分経つと調査結果がNotesに追加される形で表示されました。
もちろんDevOps Agent側でインシデントレスポンスが生成されていることが確認できます。
Notesに記載される内容と同じ内容なので、Notesには根本原因の内容が記載されるようですね。
最後に
GA版のAWS DevOps AgentでPagerDutyのネイティブ連携を設定してみました。
以前のPreview版ではPagerDutyからDevOps Agentに調査をトリガーするためにWebhookとLambda関数を使った仕組みを構築する必要がありましたが、今回のネイティブ連携ではOAuth 2.0の設定だけで完了します。
自前のLambda関数やペイロード変換が不要になったことで、連携の構築・運用コストが大きく下がりました。
PagerDutyでインシデントが発生したらDevOps Agentが自動で調査を開始するという流れを、ネイティブ連携だけで実現できるのは嬉しいですね。
また、今回の検証では確認できませんでしたが、OAuth連携であれば双方向のデータアクセスが可能になっているので、DevOps Agentがインシデント調査の際にPagerDutyのオンコールスケジュールやサービス情報を参照できるようになるようです。
こちらについては今後の検証で確認していきたいと思います。
このブログがどなたかの参考になれば幸いです。
以上、たかやま(@nyan_kotaroo)でした。
