はじめに
こんにちは、SREブロックの岩切です。普段はZOZOTOWN Yahoo!店の連携基盤のリプレイスを担当しています。
ZOZOTOWN Yahoo!店では、FTPによるデータ連携の遅延をSplunkアラートで検知し、PagerDutyにインシデントを作成して運用しています。しかし、遅延が解消してもインシデントは自動でResolveされず、手動で対応する必要がありました。
Splunk × PagerDutyの運用では、「アラートは自動だがResolveは手動」という課題に悩まされがちです。本記事では、追加のミドルウェアなしでインシデントを自動Resolveする実装パターンを紹介します。
目次
この記事で得られる知見
- Splunk Add-on for PagerDutyの制約と、その回避方法
- PagerDutyの
dedup_keyを活用したインシデントのライフサイクル管理 - 「検索結果が0件のときだけアラートを発火する」SPLテクニック
背景・課題
ZOZOTOWN Yahoo!店では、商品情報などのデータをFTPで連携しています。FTPによるデータ反映が一定時間遅れると、Splunkのアラートが発火し、PagerDutyのインシデントが作成されます。
しかし、遅延が解消してもインシデントは自動Resolveされず、毎回オンコール担当者が手動でResolveしていました。この手動対応が繰り返され、運用上の負担になっていました。
手動Resolveの課題は以下のとおりです。
- 対応コスト：遅延解消を確認し、PagerDutyを開いてResolveする作業が都度発生する
- Resolve忘れのリスク：インシデントが残り続けると、新たなアラートとの区別がつきにくくなる
- オンコール負荷：深夜・休日に遅延が解消しても、Resolveのためだけに対応が必要になる場合がある
自動Resolveの要件整理
PagerDutyのインシデントを自動Resolveするには、以下の2つを満たす必要があります。
- インシデント作成時と同じ
dedup_keyでresolveイベントを送ること - イベントの
event_actionがresolveであること
dedup_keyとは、PagerDutyがイベントをインシデントに紐づけるための一意キーです。同じdedup_keyを持つイベントは同一インシデントとして扱われ、重複排除やResolveの対象になります。
要件自体はシンプルに見えますが、Splunk Add-on for PagerDutyにはresolveイベントを直接送信する機能がありません。そのため、Splunk側とPagerDuty側の両方に工夫が必要でした。
解決策の検討
最終的な設計に至るまで、いくつかのアプローチを検討・検証しました。
各アプローチの説明へ入る前に、本記事で登場するPagerDutyの主要な概念を整理します。
- Event Transformer統合：Splunkなどの外部ツールからイベントを受け取り、PagerDuty形式に変換する統合タイプ。
incident_keyの設定により、受信したイベントのどのフィールドをdedup_keyとして使うかを決定する - Service Event Orchestration：サービスに届いたイベントをルールベースで加工する機能。条件に応じて
event_actionの変更、優先度の設定などが可能
アプローチ1：Splunk Add-onのparam.dedup_keyを使う
Splunk Add-onのparam.dedup_keyパラメータでdedup_keyを明示的に指定する方法です。しかし、Event Transformer統合はincident_key設定に基づいてdedup_keyを自動生成するため、Splunk側のparam.dedup_keyは無視されます。この方法では意図したdedup_keyを指定できず、採用を見送りました。
アプローチ2：Events API v2統合を使う
Events API v2統合であれば、ペイロードのdedup_keyをそのまま使えます。しかし、Splunk Add-onはSplunk固有のペイロード形式で送信するため、Events API v2統合ではペイロードを解釈できず、インシデントが作成されませんでした。
アプローチ3：Event Transformer統合 + Service Event Orchestration（採用）
新しいEvent Transformer統合を作成し、incident_key=sourceに設定します。SPLにeval source="yshp-ftp-delay-warning"を追加することで、トリガーと解消で同じdedup_keyを生成します。そのうえで、Service Event Orchestrationでresolveに変換します。
全体のアーキテクチャ
自動Resolveの仕組みは、インシデント作成とインシデント自動Resolveの2つのフローで構成されます。設計のポイントは以下の2点です。
- dedup_keyをSPL側で強制的に統一する：
eval source="yshp-ftp-delay-warning"でトリガーと解消に同じ値を付与 - resolveはPagerDuty側で変換する：Splunkからは
triggerとして送り、Orchestrationでresolveに変換
インシデント作成（遅延発生時）
Splunk：「Yahoo!FTPデータ反映遅延警告」アラートが遅延ファイルを検出して発火
SPL：末尾の
eval source="yshp-ftp-delay-warning"により結果にsourceフィールドを付与- Event Transformer：
incident_key=sourceの設定によりdedup_key="yshp-ftp-delay-warning"を生成 - Service Event Orchestration：
event.summaryに「解消」を含まないため、そのまま通過（trigger）。なお、Splunkのsearch_name（アラート名）はPagerDutyではevent.summaryとして受信される - 結果：インシデント作成（同一
dedup_keyなら重複排除）
インシデント自動Resolve（遅延解消時）
- Splunk：「Yahoo!FTP遅延解消チェック」アラートが遅延ファイル0件を検出して発火
- SPL：
| stats count | where count = 0 | eval source="yshp-ftp-delay-warning"で遅延ファイルが0件のときだけ結果を返す - Event Transformer：
dedup_key="yshp-ftp-delay-warning"（トリガーと同一キー） - Service Event Orchestration：
event.summaryに「解消」を含むため、event_actionをresolveに変換 - 結果：同一
dedup_keyのインシデントを自動Resolve
以上の仕組みで解決した技術的課題をまとめます。
| 課題 | 解決方法 |
|---|---|
Splunk Add-onはresolveを送れない |
Service Event Orchestrationでtrigger→resolveに変換 |
| trigger/resolveのインシデント紐づけ | SPLにeval source="yshp-ftp-delay-warning"を追加し、Event Transformerのincident_key=sourceで同一dedup_keyを生成 |
| 解消イベントの識別 | event.summaryに「解消」を含めてOrchestrationルールで判別 |
既存統合のincident_key=search_nameではdedup_key不一致 |
FTP遅延専用のEvent Transformer統合を新規作成しincident_key=sourceに設定 |
設定の詳細
Splunk側の設定
トリガーアラート（既存設定の変更）
「Yahoo!FTPデータ反映遅延警告」アラートに以下の変更を加えました。
integration_key/urlを新しいEvent Transformer統合に変更- SPL末尾に
| eval source="yshp-ftp-delay-warning"を追加 - 発火条件・スケジュールは変更なし
解消アラート（新規作成）
「Yahoo!FTP遅延解消チェック」アラートを新規作成しました。
| 設定項目 | 値 | 備考 |
|---|---|---|
| SPLクエリ | トリガーと同一ベース + | stats count | where count = 0 | eval source="yshp-ftp-delay-warning" |
遅延ファイル0件のときのみ結果を返す |
| counttype | number of events |
SPL結果の行数で判定 |
| quantity / relation | 0 / greater than |
result_count > 0で発火 |
| cron_schedule | 02-59/10 * * * * |
10分毎（トリガーと同一間隔） |
ここでのポイントは、SPLに追加した| stats count | where count = 0の組み合わせです。
通常、Splunkアラートは「検索結果が存在するとき」に発火します。しかし今回実現したいのは「遅延ファイルが0件のとき（＝遅延が解消したとき）」の発火です。遅延ファイルが0件だと検索結果も0件になり、アラートが発火しません。
そこで、ベースとなるSPLの後に| stats count | where count = 0を追加します。stats countは検索結果の件数を常に1行で返すため、遅延ファイルが0件ならcount=0の1行が出力され、where count = 0を通過します。逆に遅延ファイルが存在する場合はcount > 0となり、where count = 0で除外されて結果が0行になります。
これにより、「結果が0件のときだけ発火する」という逆転の発火条件をSPLだけで実現しています。
PagerDuty側の設定
Event Transformer統合（新規作成）
FTP遅延のトリガー・解消アラート専用に、新しいEvent Transformer統合を作成しました。
| 項目 | 値 |
|---|---|
| 統合名 | Splunk (自動Resolve用) |
| 対象サービス | zozo-yshp-alert |
| incident_key | source |
既存のEvent Transformer統合はincident_key=search_nameに設定されており、アラート名がそのままdedup_keyになります。トリガーと解消でアラート名が異なるため、既存統合ではdedup_keyが一致せずResolveできません。そこでincident_key=sourceに設定した専用統合を新規作成し、SPLで付与したsourceフィールドを共通のdedup_keyとして使用します。
Service Event Orchestration
| 項目 | 値 |
|---|---|
| ルール | event.summary matches part '解消' → event_action = resolve |
| catch_all | そのまま通過（変換なし） |
Service Event Orchestrationは対象サービスのイベントのみに適用されます。他のアラートは従来のEvent Transformer統合を使用しており、影響はありません。
動作シナリオ
正常時（遅延なし）
解消アラートが10分毎に発火し、PagerDutyにresolveイベントが送信されます。これは設計上意図した動作です。PagerDutyは、対応するdedup_keyのインシデントが存在しない場合、resolveイベントを無視します。新規インシデントが作成されることはないため、副作用はありません。
遅延発生から解消までの流れ
実際の動作を時系列で示します。遅延が発生するとインシデントが作成され、解消後に最初の解消チェックが走ったタイミングで自動Resolveされます。
まとめ
Splunk Add-on for PagerDutyにはresolveを直接送れない制約があります。今回はこの制約を、Event Transformer統合のincident_key設定とService Event Orchestrationの組み合わせで解決しました。
この仕組みの導入により、以下の改善が得られました。
- オンコール担当者の手動Resolve作業がなくなった
- インシデントのライフサイクルが実際の障害状況と一致するようになった
- Splunk Add-onの制約内で、追加のミドルウェアなしに実現できた
Splunk × PagerDutyの運用では、同様の「アラートは自動だがResolveは手動」という課題を抱えているケースがあるかもしれません。本記事の設計パターンが参考になれば幸いです。
ZOZOでは、一緒にサービスを作り上げてくださる方を募集中です。ご興味のある方は、ぜひ採用ページをご覧ください。
