はじめに
本記事ではAWS CloudWatch アラーム → PagerDuty（オンコール & インシデント管理）→ Jira（課題管理・ITSM）の構成で連携方法について検証結果を整理する。
また、検証時にはまったポイントをまとめておく。
1.連携全体像
CloudWatch Alarm → SNS → PagerDuty Events API
↓
PagerDuty Incident → Jira Issue
↑
（ステータスマッピング）
2.手順➀：PagerDuty Serviceを作成
- Servicesから新規作成、結合するサービスで「Events API V2」or「Amazon CloudWatch」を選択
- 作成できたら、Integration Key,URLを控える
このキーが SNS → PagerDuty 通信の宛先
3. 手順➁：AWS SNS → PagerDuty の連携を設定
SNSトピック作成
トピックを作成後、サブスクリプション作成
プロトコル：HTTPS
エンドポイント(Service作成時のキー)：
https://events.pagerduty.com/integration/<IntegrationKey>/enqueue
4. 手順➂：CloudWatchアラームを作成し、SNSと紐づけ
- CloudWatchからアラーム作成
通知検証ようなためstressですぐアラーム状態にできるような定義を適当に設定
閾値：>= 20%
期間：1データポイント（30秒～5分など）
ここまででCloudWatch → SNS → PagerDutyまでのパイプラインは完成
5. 手順➃：PagerDutyでインシデント動作確認
CloudWatchアラームを手動でALARM状態にすると、Incidentが生成される。
➤CloudWatchの状態変更
➤PagerDutyのアラート確認
➤アラート詳細
➤Event情報
画面下部の「View Message」からEventのJsonを確認可能
| 項目 | 内容 |
|---|---|
| Alert Payload | CloudWatch の JSON が入る |
| Severity | デフォルトは "error" になる |
6. 手順➄：PagerDuty → Jira連携を構成
-
Integrationから「Jira Cloud」を選択
-
Jira OAuth 認証を通す
-
Jiraの対象スペースを選択、PagerDuty内のServiceや名前を設定
-
Jira内の設定
Creation Type：アラーム時にJiraチケットの自動作成 or アラームから手動チケット作成を設定
Jira Field mapping：PagerDuty ↔ Jiraのフィールドマッピングを定義
➤ステータスマッピング
| PagerDuty 状態 | Jira 状態 |
|---|---|
| Triggered | オープン |
| Acknowledged | 進行中 |
| Resolved | クローズ |
JiraからPagerDutyの「確認済み（ACK）」には変更不可
例）Jira側のステータスをクローズ時、PagerDuty側のステータスも自動で「Resolved」に更新される。
7. 注意点
- １つのService内でJiraの連携可否制御はできそうにない
例）
Sev0の時だけJiraに送る
Sev2はJiraに送らない
これはpagerduty単体だけでの制御は不可
非検証であるが、以下により制御可能と想定、それぞれメリデリあり
- Lambda Wrapperを使う
自作のコードとなるため自由に組み込めそうだが開発コストあり
CloudWatch → SNS → Lambda → PagerDuty Events API → Jira
- サービスを分ける
最も単純だが、パターンが増えるほどサービスが増えSNSトピックの使い分けと
システムの見通しが悪くなりそう。
critical-service（Jira連携 ON）
normal-service（Jira連携 OFF）
-
Jira側でフィルタリング
PagerDutyからは全件、Jira連携を行いJira側の自動化で条件不一致のチケットは削除 or 自動クローズ
ごみチケットが生成されてしまう。 -
チケット起票を手動
Jira管理対象のインシデントは対象のアラートのみ「Create Isuue」からチケット作成
運用体制に依存するが、最も安そう。
例）
エスカレーションや復旧が必要なアラームのみチケット作成
