vague memory

うろ覚えを無くしていこうともがき苦しむ人の備忘録

AWS から PagerDuty への通知連携(6)

EventBridge -> Service Integration (Custom Event Transformer)

"Amazon CloudWatch Integration" は Metric Alarm 専用で、EventBridge には対応していません。

Service Integration で受け付ける方法は二通りあります。 2パターン目として Custom Event Transformer を使用します。

Custom Event Transformer Integration Guide | PagerDuty

受信したイベントを JavaScript により変換する機能です。 機能詳細については以下のドキュメント内に記載があります。



Amazon EventBridge Integration について

Amazon EventBridge Integration Guide | PagerDuty

EventBridge のインテグレーションは PagerDuty -> EventBridge の連携用です。
EventBridge -> PagerDuty の方向では使用できません。

導入

PagerDuty Service に "Custom Event Transformer" インテグレーションを追加し、Integration URL を取得します。

f:id:htnosm:20220403140747p:plain

AWS SNS の Subscription に Integration URL を HTTPS Endpoint として指定します。

f:id:htnosm:20220403140750p:plain

インテグレーションが初期状態(スクリプト未編集)の場合、"Custom Event Transform" の件名でインシデントが作成されるので、confirm を実施することで利用できるようになります。

f:id:htnosm:20220403140755p:plain

PagerDuty Service での自動Resolve設定を行っていない限りは、Resolveされないので手動で実施します。

インシデント

インテグレーションが初期状態(スクリプト未編集)の場合で確認します。

スクリプトはインテグレーション設定で確認が行なえます。

f:id:htnosm:20220403140759p:plain

rawBody にイベント内容が入ります。

f:id:htnosm:20220403140803p:plain

重複排除

The transformer deduplicates events based upon the incident_key property within the normalized_event object.

normalized_event.incident_key で指定します。

var normalized_event = {
  event_type: PD.Trigger,
  description: "Custom Event Transform",
  details: PD.inputRequest,
  incident_key: XXXXX,
};

スクリプトの変更はインテグレーション設定から行います。

f:id:htnosm:20220403140808p:plain

Event API v2

Event API には v1 と v2 のバージョンが有り、Custom Event Transformer の初期スクリプトは v1 となっています。

機能拡張されており、Severity の指定などはv2からの機能となります。

Custom Event Transformer のドキュメントは v1 配下に有り、v2についての明記はありません。 しかし、v1/v2 とも、 PD オブジェクトを使用する形となっており、Custom Event Transformer も v2 での記述が可能です。
v2版での PD オブジェクトについては DEVELOPER PLATFORM の "Writing App Event Transformers" ページが参考になります。

インシデント(v2版)

初期スクリプトをv2の記述に変更して確認します。

let body = PD.inputRequest.rawBody;

let normalized_event = {
  event_action: PD.Trigger,
  payload: {
    summary: "Custom Event Transform v2",
    source: "raw event",
    severity: PD.Critical,
    custom_details: body
  },
};

PD.emitEventsV2([normalized_event]);

f:id:htnosm:20220403140812p:plain

インシデント(v2 SNS版)

SNS のイベントに合わせて整形して確認します。

let body = JSON.parse(PD.inputRequest.rawBody);

let summary = body.TopicArn;
let custom_details = body;
if (body.Message) {
    try {
        custom_details.Message = JSON.parse(body.Message);
    } catch(e) {
        ;
    }
}

let normalized_event = {
    event_action: PD.Trigger,
    payload: {
        summary: summary,
        source: "sns",
        severity: PD.Critical,
        custom_details: custom_details
    },
};

PD.emitEventsV2([normalized_event]);

f:id:htnosm:20220403140816p:plain

注意点

スクリプトを編集した後に SNS Subscription の Confirm を行う場合、通常のメッセージ(Type:Notification) とは異なる形式でイベントが送信されます。 confirm を実施するためには、"Subscription Confirmation"(Type:SubscriptionConfirmation) の形式にもスクリプトが対応している必要があります。

f:id:htnosm:20220407030919p:plain

AWS から PagerDuty への通知連携(5)

EventBridge -> Service Integration (Email)

"Amazon CloudWatch Integration" は Metric Alarm 専用で、EventBridge には対応していません。

Service Integration で受け付ける方法は二通りあります。 1パターン目として Email Integration を使用します。

Email Integration Guide | PagerDuty



導入

SNS Subscription では Email または Email-JSON で送信できるので、2パターン試します。

PagerDuty Service に "Email" インテグレーションを追加し、Integration Email を取得します。

f:id:htnosm:20220403140233p:plain

AWS SNS の Subscription に Integration Email を Email または Email-JSON として指定します。

f:id:htnosm:20220403140236p:plain

"AWS Notification - Subscription Confirmation" の件名でインシデントが作成されるので、confirm を実施することで利用できるようになります。

PagerDuty Service での自動Resolve設定を行っていない限りは、Resolveされないので手動で実施します。

インシデント

インシデントタイトルはメール件名で作成されます。

AWS Notification Message

詳細欄はメール本文です。

Email は Message の内容のみとなるので、 Email-JSON の方が若干情報量が多いです。

重複排除

インテグレーション設定から変更します。 デフォルトは メール件名 です。 また、件名/本文/差出人に対してのフィルタリング設定も行えます。

f:id:htnosm:20220403140301p:plain

細かな設定方法は以下ドキュメントに記載されています。

Email Management: Filters and Rules

AWS から PagerDuty への通知連携(4)

Metric Alarm -> Global Orchestration

グローバルオーケストレーションのEndpointへイベントを通知します。 その内置き換わると思いますが、現時点では CloudWatch 固有のドキュメントはありません。

Event Orchestration

導入方法は上記の Global Orchestrations を参考にします。 前回のGlobal Ruleset と似たような感じです。


導入

PagerDuty "Automation" -> "Event Orchestration"。 初期状態では空です。

f:id:htnosm:20220328063517p:plain

"New Orchestration" からオーケストレーションを作成し、 "Global Orchestration Key" 内の Integration Key を使用します。

f:id:htnosm:20220328063522p:plain

Integration URL はドキュメントに記載がありませんが、 グローバルルールセット同様、以下の形式で指定します。

https://events.pagerduty.com/x-ere/[YOUR_INTEGRATION_KEY_HERE]

AWS SNS の Subscription に Integration URL を HTTPS Endpoint として指定します。 自動的に Confirm されます。

f:id:htnosm:20220328063540p:plain

Rule はまだ設定していない状態ですが、Alert が発行され comfirm されます。 Ruleset とは異なり、PDAutoSubscribe の出力は有りませんでした。

f:id:htnosm:20220328063545p:plain

f:id:htnosm:20220328063549p:plain

インシデント発行する Rule が設定済みである場合、 インシデントタイトル "Incident routed via a Ruleset" で発行されます。

ルール(ルーティング)

初期状態では 何もしない ルールのみが存在します。

f:id:htnosm:20220328063834p:plain

イベント受信時にインシデント発行を行うため、"New Service Route"から新しいルールを追加します。

ルール作成画面の右画面に受信したイベント履歴が出力されます。 事前に Integration URL にイベント発行を行っておくとルール作成がしやすいと思います。

f:id:htnosm:20220328063838p:plain

ルーティングルール

例として、Service への振り分け条件を TopicArnとします。 CEF 形式でないため、 raw_event.TopicArn としています。 参考: Common Event Format (PD-CEF)

f:id:htnosm:20220328063842p:plain

サービスルール

作成したルーティングルールのサービスルールを編集します。
初期状態では Default Behavior ルールのみ存在し、イベントを受信すると Severity: Critical でインシデントを発行します。

f:id:htnosm:20220328063845p:plain

ビジュアルエディタが開くので "New Rule" にルールを追加します。 例として、Severity を warning でインシデント発行するルールにします。

f:id:htnosm:20220328063849p:plain

  • Conditions

f:id:htnosm:20220328064442p:plain

  • Alert Actions

f:id:htnosm:20220328064445p:plain

  • 一覧(条件が複数ある場合は右上のメニューの Move... で優先順変更)

f:id:htnosm:20220328064450p:plain

尚、ルールセットのネストはオプションとのことです。

f:id:htnosm:20220328064454p:plain

条件の追加は "Add Sibling Below" で行えます。

f:id:htnosm:20220328064458p:plain

インシデント

インシデントタイトルは SNSから通知される $.Subject で作成されます。

{NewStateValue}: \"{AlarmName}\" in {Region}

f:id:htnosm:20220328065207p:plain

詳細欄にはSNSから通知される $.Message が入ります。

f:id:htnosm:20220328065421p:plain

ルールで指定した通り、Severity を warning としている事が確認できます。

f:id:htnosm:20220328065216p:plain

OK Action 通知での Resolve はされません。

f:id:htnosm:20220328065220p:plain

受信したイベント履歴を見ると、"event_action": "resolve" となっているので Resolve されることを期待したのですが、ルールを調整する必要があるようです。

Resolve

サービスルールにルールを追加して "OK Action" 受信時にインシデントを Resolve するようにします。

ALARM 用ルール

追加済みのルールの Condition を 件名(Subject) に "ALARM:" を含むという条件に編集します。

`raw_event.Subject` matches part "ALARM:"

f:id:htnosm:20220403062536p:plain

OK 用ルール

Condition "Always" のルールを追加します。 Alert Actions で Resolve を指定します。

f:id:htnosm:20220403062541p:plain

ルール追加を行った状態は以下のようになります。

f:id:htnosm:20220403062544p:plain

受信確認

"OK" を受け取った際にインシデントの Resolve が行われます。

  • Alert Log
    • f:id:htnosm:20220403062548p:plain
  • Incident Timeline
    • f:id:htnosm:20220403062551p:plain

課題: イベントの形式差異

上記では "ALARM" を条件に Trigger、それ以外を Resolve としています。 本来は逆の条件("OK"を条件に Resolve、それ以外をTrigger)が良かったのですが振り分けが期待通り動作せず断念しました。

詳細は不明ですが、"OK"受信時の Condition が効かない状態でした。 "Examples of recent events" を見ると、"ALARM" と "OK" で表示差異があり、イベント形式が異なっているのではないかと思います。(イベント内容は一緒なので謎ではありますが...)

f:id:htnosm:20220403062555p:plain

グローバルとサービス

サービスオーケストレーションの設定は、 PagerDuty Service -> Settings -> "Event Management" -> "Service Orchestration Rules" からも辿れます。 (エディタの表示が統合されていて少々混乱しました。)

Global Orchestrations

When an incoming event stream has more than one service destination, you can use Global Orchestrations to route events from the same source to different services.

グローバルオーケストレーションは Service へのルーティング機能のみです。

Service Orchestrations

When integrations exist on a service, you can use Service Orchestrations to evaluate your incoming events and perform additional actions.

以降のアクション実行はサービスオーケストレーションの機能です。

  • Orchestration から参照した場合

f:id:htnosm:20220328070127p:plain

  • Service から参照した場合

f:id:htnosm:20220328070131p:plain

重複排除

Ruleの "Transformations" から変更します。

f:id:htnosm:20220328070134p:plain

AWS から PagerDuty への通知連携(3)

Metric Alarm -> Global Ruleset

グローバルルールセットのEndpointへイベントを通知します。

Amazon CloudWatch Integration Guide | PagerDuty

導入方法はガイド (Integrate With Event Rules) に記載の通りです。


導入

PagerDuty "Automation" -> "Event Rules" に Default Global Ruleset が存在します。 "Incoming Event Source" 内の Integration Key を使用します。

f:id:htnosm:20220328061425p:plain

f:id:htnosm:20220328061432p:plain

Integration URL はドキュメントに記載がある以下の形式で指定します。

https://events.pagerduty.com/x-ere/[YOUR_INTEGRATION_KEY_HERE]

AWS SNS の Subscription に Integration URL を HTTPS Endpoint として指定します。 自動的に Confirm されます。

f:id:htnosm:20220328061429p:plain

Rule はまだ設定していない状態ですが、 Alert が発行され、Event Detail を確認すると、 comfirm を実行していることが確認できます。

f:id:htnosm:20220328061437p:plain

f:id:htnosm:20220328061441p:plain

インシデント発行する Rule が設定済みである場合、 インシデントタイトル "Incident routed via a Ruleset" で発行されます。

ルール

初期状態では 何もしない ルールのみが存在します。

f:id:htnosm:20220328061444p:plain

イベント受信時にインシデント発行を行うため、"New Event Rule"から新しいルールを追加します。

ルール作成画面の右画面に受信したイベント履歴が出力されます。 事前に Integration URL にイベント発行を行っておくとルール作成がしやすいと思います。

f:id:htnosm:20220328061448p:plain

例として、Service への振り分け条件を TopicArnとし、 Severity を info でインシデント発行するルールにします。

f:id:htnosm:20220328061452p:plain

f:id:htnosm:20220328061456p:plain

尚、スケジュール設定機能は Business Plan 以上の機能とのことです。

f:id:htnosm:20220328061500p:plain

一覧画面に戻り、作成したルールの優先順を指定します。

f:id:htnosm:20220328061504p:plain

インシデント

インシデントタイトルは SNSから通知される $.Subject で作成されます。

{NewStateValue}: \"{AlarmName}\" in {Region}

f:id:htnosm:20220328061516p:plain

詳細欄にはSNSから通知される $.Message が入ります。

f:id:htnosm:20220328061508p:plain

OK Action を設定していた場合、Metric Alarm に連動し Resolve されます。

f:id:htnosm:20220328061512p:plain

ルールで指定した通り、Severity を info としている事が確認できます。

重複排除

Ruleの "Customize Event Fields" から変更します。

f:id:htnosm:20220328061519p:plain

未指定時のデフォルトは Alarm Name のようです。 ドキュメント上には見当たりませんでしたが、 Alert Log を確認すると dedup_key の値を確認できます。

f:id:htnosm:20220328061523p:plain

f:id:htnosm:20220328061527p:plain

GitHub Actions で CloudFormation Linter 実行時に config file を読みたい

結果的に README 記載の通りでしたが備忘録です。

CloudFormation Linter

AWS謹製 CloudFormation テンプレートの検証ツールです。

オプションは実行時引数で渡すか、 config file .cfnlintrc で指定ができます。

直接実行しても良いのですが、cfn-lint を実行する GitHub Action がいくつか公開されていたので、今回は以下の2つを使わせてもらって確認します。

ディレクトリ構成

.
├── .cfnlintrc
├── .github
│   └── workflows
│       ├── cfn-lint.yml

aws-cloudformation/cfn-lint: CloudFormation Linter を参考に .cfnlintrc にパラメータを書きます。

templates:
    - "**/*.yaml"
    - "**/*.yml"
ignore_templates:
    - "etc/**"

Workflow

cfn-lint-action の場合

Usage を参考にワークフローを書きます。
cfn-lint コマンドを実行しているだけなので、所定の場所に config file を格納しておけば読み込んでくれます。

jobs:
  cloudformation-linter:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout
        uses: actions/checkout@v2

      - name: Testing with CFN Lint Command
        uses: scottbrenner/cfn-lint-action@v2
        with:
          command: cfn-lint --debug

actions-cfn-lint の場合

README には記載が無いですが、参考例が Template file not found due to use of quotes around multiple template file paths · Issue #187 · shogo82148/actions-cfn-lint にあります。 複数ファイルを対象にする場合に使います。

args--config-file を指定することでconfig fileを読み込ませます。 (config file を読み込ませるだけであればargsの変更は不要で、同様に所定の場所に config file を格納しておけば読み込んでくれます。)

jobs:
  cloudformation-linter:
    runs-on: ubuntu-latest

    steps:
    - name: Checkout
      uses: actions/checkout@v2

    - name: Testing with CFN Lint Command
      uses: shogo82148/actions-cfn-lint@v1
      with:
        args: --debug --config-file .cfnlintrc

AWS から PagerDuty への通知連携(2)

Metric Alarm -> Service Integration

検索すると真っ先に出てくる公式インテグレーションです。

Amazon CloudWatch Integration Guide | PagerDuty

導入方法はガイド (Integrate With a PagerDuty Service) に記載の通りです。 SNS Subscription 設定を行うと自動的に Confirm され利用できるようになります。


導入

PagerDuty Service に "Amazon CloudWatch" インテグレーションを追加し、Integration URL を取得します。

f:id:htnosm:20220328060244p:plain

AWS SNS の Subscription に Integration URL を HTTPS Endpoint として指定します。 自動的に Confirm され、利用できるようになります。

f:id:htnosm:20220328060249p:plain

インシデント

インシデントタイトルはメトリックネームをベースに生成されます。

{Statistic} {MetricName} {ComparisonOperator} {Threshold}

f:id:htnosm:20220328060253p:plain

詳細欄にはSNSから通知される $.Message が入ります。

f:id:htnosm:20220328060257p:plain

OK Action を設定していた場合、Metric Alarm に連動し Resolve されます。

f:id:htnosm:20220328060301p:plain

重複排除

インテグレーション設定から変更します。 デフォルトは Alarm Name です。

  • Integration 歯車アイコン

f:id:htnosm:20220328060305p:plain

  • Edit Integration

f:id:htnosm:20220328060310p:plain

  • Correlate events by

f:id:htnosm:20220328060315p:plain

AWS から PagerDuty への通知連携(1)

PagerDuty への通知方法が増えていたので調査しました。

公式ドキュメントに導入手順の詳細がありますが、実際どのような通知結果になるのかそれぞれ確認したいと思います。

参考: PagerDuty Knowledge Base


仕様と前提

通知方式

AWS からの通知を例に取って確認します。 以下2種類の方法でイベントを発行します。いずれも SNS 経由となります。

CloudWatch Metric Alarm

CloudWatch メトリクスの閾値監視です。 "Alarm Action", "OK Action" にSNS Topicを指定して通知します。 PagerDuty 上の、 "CloudWatch" という表記は大抵こちらを指します。

f:id:htnosm:20220328054617p:plain

EventBridge

以前は CloudWatch Events と呼ばれていた機能です。 "Target" にSNS Topicを指定して通知します。

f:id:htnosm:20220328054653p:plain

Endpoint

PagerDuty が受ける Endpoint は範囲別に2種類存在します。

  • Global
    • route events from the same source to different services.

    • PagerDuty サブドメインの Endpoint にイベントを送信、各PagerDuty Service に振り分け設定を行う
  • Service
    • evaluate your incoming events and perform additional actions.

    • PagerDuty Service 配下に Integration を設定し、Integration URL (Endpoint) にイベントを送信

処理方式

PagerDuty がイベントを受信し、インシデント発行などの処理を行う方式が複数存在します。 大きく分けると以下3種類になります。

以下はいずれも、 PagerDuty に連携されたイベントに対し、各Serviceへのルーティングや処理を、任意のルールで行えるという機能です。
Rulesets には legacy feature との記載あり、今後は Orchestration に移行していく事になりそうです。

  • Rulesets
    • route events to an endpoint and create collections of event rules

  • Event Orchestration
    • route events to an endpoint and create nested rules

    • 2022年1月 にリリースされた Rulesets の拡張機能

プラン

PagerDuty の契約プランにより、利用可能な機能、設定可能数が異なります。 Service 配下に設定する機能制限は無いようです。
特に Orchestration はリリースされたばかりなので詳細はサポートに問合せするのが確実だと思います。

参考: Pricing | PagerDuty

f:id:htnosm:20220328054657p:plain f:id:htnosm:20220328054701p:plain f:id:htnosm:20220328054706p:plain

重複排除

PagerDuty にイベントを送信し、インシデントを発行する際に重複排除が働きます。 各処理方式によりデフォルト値や設定方法が異なります。

参考: Event Management

重大度(Severity)と緊急度(Urgency)

インシデント発行時に Serverity を指定し、緊急度を変更することができます。 今回、ルールに合致したか否かの確認のため Serverity を変更していますが、インシデントに反映させるには PagerDuty Service の設定で Dynamic Notification の機能を使用する必要があります。

参考: Dynamic Notifications

これにより Serverity を info, warning とすることで、 インシデントの Urgency が Low となります。 Service 側の設定を High, Low 固定とした場合は、Service 側の設定が優先され固定値となります。

f:id:htnosm:20220328054710p:plain