はじめに
タイトルの通り、Rulesets/Event RuleのEOLに伴い、Event Orchestrationへの移行を検討しました。検証中にいくつか制約に引っかかり試行錯誤しましたので、初歩的な内容になりますが、いくつか紹介したいと思います。
参考にした資料
主に以下の資料を参照しました。
Event Orchestrationの概要・使い方などは、以下をご参照ください。
公式ドキュメント
PagerDutyさんの記事
PagerDuty 設定ガイド (トリアージ編4) - Event Orchestrationでアラートへの対処を自動化する
前提
Service Event Ruleを使用している場合は、以下の通り簡単にService Orchestrationに移行できます。
Service Orchestrationへの切り替え
ただ、Global Event Ruleについては、簡単に切り替えることはできず、手動でService Orchestrationに移行する必要があるようです。
1. ルールセットの制限
Orchestration Rulesは、縦横に複数のEvent Ruleを作成することができます。
そして、縦に作っていく一連のルールのグループをルールセットと呼ぶようです。
そのルールセットの制限として、一つのルールセットには最大で25個までしかルールを作成できません。
2. ルールのネスト
定義したいルールが多い場合、縦に25個しかルールを作成できないので、ルールをネストする（横に広げる）など工夫する必要があります。
ルールをネストする機能は、条件を管理しやすくなるので便利だと感じました。
ただ、ルールをネストする機能については、プランをAdvanced Event Orchestrationにする必要があります。プランがBasic Event Orchestrationの場合は利用できません。
3. Conditionsでの時間ベースの条件指定
Event Ruleを作成する際、Conditionsで条件を指定できます。
ただ、以下のConditionを選択した場合、GUIではAND条件が設定でないため、PCLで定義する必要があります。
- On a recurring weekly schedule: 週次
- During a scheduled date range: 特定の期間
- Depends on event frequency: Eventの受信頻度
実際に、ConditionでOn a recurring weekly scheduleを選択し、条件ブロックを追加すると、以下の通り自動的にORとなります。
例えば、以下のように文字列マッチと時間ベースの条件をandで指定したい場合には、PCLで定義する必要があります。
インシデントのタイトルに「XXX」という文字列を含む and 特定の期間
なお、PCLについても、文字列の長さなど制約があります。
4. Conditionsの制限
ルールの中で条件ブロックを作成するにあたっては、以下の制限に留意する必要があります。
- 1つのルール内に最大25個の条件ブロックを作成できる
- 1つの条件ブロックに最大64個の演算子(例:AND ,OR )、または最大2048バイト(例:PCLを使用している場合)を設定することができる
さいごに
元々Rulesetsの定義が少ないサービスではあまり関係ない制約もありますが、たくさんのRulesetsを定義しているサービスもあると思います。
実際に私が対応したサービスでは数百のRulesetsがあったため、Event Orchestrationでどう定義していくか、条件をまとめられないか検討することとなりました。
内容的には既にご存じの方が多いと思いますが、少しでも役に立てば幸いです。
最後までご覧いただきありがとうございました！