PagerDutyのEvent Orchestrationを使ってEmailの同一インシデントの自動解決をやってみた

たかやまです。

CloudWatch AlarmからSNS経由でPagerDutyにメール通知を送信している環境で、以下のような問題が発生していました。

• インシデント #204: ALARM: "sample-prod-web04-os-high-loadaverage" in Asia Pacific (Tokyo) - Triggered
• インシデント #209: OK: "sample-prod-web04-os-high-loadaverage" in Asia Pacific (Tokyo) - Triggered

本来であれば、#204がOK通知を受けて自動解決されるべきですが、別々のインシデントとして作成されてしまいます。

ただ、実際の運用現場ではAWS環境に手を加えられない事情や、既存のメール通知経路をそのまま使いたいといったケースも多くあります。

そうした場合、CloudWatchの通知をSNS経由でPagerDutyのメールインテグレーションに届けていると、ALARMとOKが別々のインシデントとして発生してしまい、手動でクローズする手間が生じます。

本記事では、AWS側の構成を変更できない・既存のメール配信を維持したい場合に、PagerDutyのEvent Orchestrationを活用したALARM/OK通知の同一インシデント化と自動解決の方法を紹介します。

さきにまとめ

• Email経由のCloudWatch Alarm通知にEvent Orchestrationルールを適用するにはEvent Orchestration Integrationが必要
• 正規表現でアラーム名を抽出し、同じdedup_keyを設定することでALARM/OK通知を同一インシデント化
• OK通知時にevent_action="resolve"を設定することで既存インシデントを自動解決

全体概要

今回はPagerDuty側のみの設定で問題を解決する方法として、Event Orchestration機能を活用します。

https://support.pagerduty.com/main/lang-ja/docs/event-orchestration#deduplication

Event Orchestrationでは主に以下のような制御ができます。

• イベントのsummaryから正規表現によるアラーム名の抽出
• 抽出した値をdedup_keyに動的にセット（重複排除・グルーピングの要）
• event_actionをtrigger/resolveで切替（ALARM→発生、OK→自動解決）
• その他アクション分岐も可能

ここでのポイントは「dedup_key」の設定です。

dedup_key フィールドは、イベントの重複排除やグルーピングのために利用され、同じdedup_keyを持つイベントは一つのアラート（インシデント）としてマージされます。

また、解決通知（OK）も同じdedup_keyを指定することで、該当インシデントに対する自動解決アクションが可能となります。

重複排除
dedup_key フィールドは、イベントを1つのアラートにマージするために使用されます。同じdedup_key を持つイベントは、マージされたアラートのステータスを更新することができます。

https://support.pagerduty.com/main/lang-ja/docs/event-orchestration#deduplication

この仕組みにより、「CloudWatchアラームをメール方式でPagerDutyに連携している場合でも、dedup_keyによる同一インシデント化と自動解決」が実現できます。

システム全体の構成イメージは以下の通りです。

dedup_keyを活用することで、ALARMとOKが別々のインシデントにはならず、適切に一連のインシデントとして管理・解決されます。

やってみる

前提条件

Email経由でEvent Orchestrationルールを適用するには**Event Orchestration Integration（Email）**を使用する必要があります。

Service Orchestration rules are not applied to service-level email integration events. If you would like to utilize Orchestration rules with email events, please integrate directly with an Event Orchestration.

日本語訳:
サービスオーケストレーションルールは、サービスレベルのメール統合イベントには適用されません。メールイベントでオーケストレーションルールを利用する場合は、イベントオーケストレーションと直接統合してください。

https://support.pagerduty.com/main/docs/email-integration-guide#integrate-with-a-pagerduty-service

これはService DirectoryのEmail Integrationを指しており、Event Orchestration Integrationを使用する必要があります。

Rule 1: ALARM通知の処理

ALARM通知を受け取った際に、アラーム名を抽出してdedup_keyとして設定します。

Condition :

Variables :

Event Fields :

正規表現の動作例は以下のとおりです。

Rule 2: OK通知の処理（自動解決）

OK通知を受け取った際に、同じdedup_keyを設定し、event_actionを"resolve"に設定することで既存インシデントを自動解決します。

Condition :

Variables :

Event Fields :

Alert Data :

正規表現の動作例は以下のとおりです。

最終的な全体設定はこちらです。

ちなみにPagerDutyはTerraformで設定することも可能です。

https://dev.classmethod.jp/articles/terraform-pagerduty-provider-intro/

terraform {
  required_version = ">= 1.0"
  required_providers {
    pagerduty = {
      source  = "PagerDuty/pagerduty"
      version = "~> 3.0"
    }
  }
}

provider "pagerduty" {
  token = var.pagerduty_token
}

variable "pagerduty_token" {
  description = "PagerDuty API Token"
  type        = string
  sensitive   = true
}

variable "service_id" {
  description = "PagerDuty Service ID"
  type        = string
}

resource "pagerduty_event_orchestration_service" "sample" {
  service = var.service_id

  set {
    id = "start"

    # Rule 1: ALARM通知のdedup_key設定
    rule {
      label = "CloudWatch ALARM - set dedup_key"

      condition {
        expression = "event.summary matches part 'ALARM:'"
      }

      actions {
        variable {
          name  = "alarm_name"
          path  = "event.summary"
          value = "ALARM: (.+)"
          type  = "regex"
        }

        extraction {
          target   = "event.dedup_key"
          template = "{{variables.alarm_name}}"
        }
      }
    }

    # Rule 2: OK通知のdedup_key設定 + インシデント自動解決
    rule {
      label = "CloudWatch OK - set same dedup_key and resolve"

      condition {
        expression = "event.summary matches part 'OK:'"
      }

      actions {
        event_action = "resolve"

        variable {
          name  = "alarm_name"
          path  = "event.summary"
          value = "OK: (.+)"
          type  = "regex"
        }

        extraction {
          target   = "event.dedup_key"
          template = "{{variables.alarm_name}}"
        }
      }
    }
  }

  catch_all {
    actions {}
  }
}

動作確認

Event Orchestration Integration経由でALARM通知メールを送信し、インシデントが作成されることを確認します。

• 送信先: Event Orchestration Integrationのメールアドレス
• Subject: ALARM: test-dedup-key-check in Asia Pacific (Tokyo)

インシデントがTriggered状態で作成され、dedup_keyにアラーム名が設定されていることを確認します。

Event Orchestration動作状況は Timeline > 該当 Alert から確認できます

以下のメッセージからdedup_keyにアラーム名が設定されていることを確認できます

Assigned new value "test-dedup-key-check in Asia Pacific (Tokyo)" to dedup_key using RegEx {{variables.alarm_name}} by an Event Orchestration

続いてOK通知メールを送信し、既存インシデントが自動解決されることを確認します。

• 送信先: Event Orchestration Integrationのメールアドレス
• Subject: OK: test-dedup-key-check in Asia Pacific (Tokyo)

既存インシデントがResolved状態に変更され、OKイベントで新規インシデントは作成されないことを確認できました！

ちなみにOK通知メールは該当インシデントのAlertにAlert Logから確認できます。

最後に

PagerDutyのEvent Orchestrationを使って、CloudWatch AlarmのALARM/OK通知を同一インシデントとして処理し、自動解決する方法を紹介しました。

dedup_keyとevent_actionの組み合わせにより、ALARM/OK通知が適切に同一インシデントとして処理され、ノイズアラートを削減できます。

AWS側の設定変更ができない環境でも、PagerDuty側のみで対応できるのは大きなメリットですね。

このブログがどなたかの参考になれば幸いです。

以上、たかやま(@nyan_kotaroo)でした。