一通り実行結果を確認できたのでまとめます。
AWSからの送信を題材にしていますが、他サービスからの連携でも利用できると思います。
参考URL
- Knowledge Base
- 機能概要、ベストプラクティス、利用方法 などのドキュメント
- Integrations
- インテグレーションの検索とガイドへのリンク
- PagerDuty Developer Platform and Documentation
- API提供機能の概要、API Reference などのドキュメント
- トップページ以外はURLにランダム文字列を含んでおり、不定期に変わってそう (例：https://developer.pagerduty.com/docs/ZG9jOjQ2NDA2-introduction)
- PagerDuty Community
- コミュニティ フォーラム
- サポートへの問合せ前に利用を推奨される
- 中の人が投稿しているトピックなどもある
- Blog - PagerDuty
- リリース情報やベストプラクティスなど
- Pricing | PagerDuty
- プラン別機能一覧
内容は充実していますが、情報が散らばっている印象です。
イベントフロー
各機能の流れと関係はこのようになると思います。
対象外とした機能
App
Developer Mode にした上で利用する形となるため、今回は除外しています。
Developer Platform の "Build App & Integration" 辺りにドキュメントがあります。
Custom Event Transformer Integration のように、
JavaScript による Event Transformer 機能を持っており、
各 Service 配下の Integration 設定で行っていたスクリプトを1箇所で管理するなどができるようです。
Service Rule
今後は後継の Service Orchestration に置き換わっていくと思われるため、今回は除外しています。
各 PagerDuty Service に振り分けされたイベントを操作する際に使用します。 (Service Event Rules)
設定画面上も、 Switch to Service Orchestrations ボタンがあり、今後は Service Orchestration 機能に移行していく事が推奨されているようです。ドキュメントにも記載があります。(Switch to Service Orchestrations
)
選択肢
どの機能を使用するかの判断はこのようになると思います。
Service か Global か
Service 配下の方が小回りが効きます。管理外のシステムから他社に連携してもらう場合など、固有Endpointの方が向いているでしょう。
Global は一箇所でまとめて管理できるメリットがありますが、権限やプランの関係で利用できない可能性があります。
Orchestration か Rulesets かという点は、特に支障が無ければ Orchestration が推奨されると思います。 使ってみた限りでは Rulesets にできて Orchestration にできないことはありませんでした。
Service の Endpoint
Service の場合、提供されているなら Integration が使いやすいと思います。
Custom Event Transfer は自前で Integration を作成するイメージで、JavaScript を書く必要がありますが自由度は高いです。
API 実行で送信を行う場合は Events API v2 インテグレーションを利用します。
Email しか送信手段が無ければ Email Integration になりますが、細かな制御はできません。 抽出・変換は後述 Service Orchestration で行う形になります。
Global の Endpoint
Global の場合、 PD-CEF に対応していれば Integration URL へそのまま送信できます。
Global Orchestration
Global Rulesets
非対応形式の場合は HTTP endpoint か Email となります。 HTTP endpoint へは API を実行して送信します。
Email は、Email Integration 同様、抽出・変換は後述 Service Orchestration で行う形になります。
- Global Orchestration
- Global Rulesets
ルーティング後の操作
Service Orchestration にて実施します。 Service にルーティングされたイベントに対して実行できます。 Global Orchestration 経由である必要はありません。 参考例としては、前述の Global Orchestration の記事内 Transformations で使用しています。
コード化
各種APIが提供されているのでコード管理も可能です。
Terraformの PagerDutyプロバイダ が提供されているので利用しています。
Terraform 未サポートリソース
いずれも PagerDuty API は提供されていますが、検証時点では Terraform (PagerDuty Provider) ではサポートしていませんでした。
- Event Orchestration
- 各 Service Integration の詳細設定
- Add email_filters to pagerduty_service_integration of type generic_email_inbound_integration · Issue #88 · PagerDuty/terraform-provider-pagerduty · GitHub
- Email Fileter は v2.4.0 で追加されました
resource/pagerduty_service_integration: Add Email Filters to Service Integrations (#468)
まとめのまとめ
これまで Integration を利用することが多かったのですが、 新機能の Orchestration が発表されたことで改めて手法を確認し、様々な連携方法があることを知りました。 各種Webサービスのイベント連携は何かしらで行えそうです。
ノーコードでルール設定できる Orchestration は利用頻度が上がりそうです。特に、受信した内容をそのままルールの条件値として使用できる raw_event が使えるのは良いと思います。
今回の検証した結果の記事一覧は以下になります。
今回試した AWS と PagerDuty の連携例をコード(Terraform)化した物は以下に置いています。
