Activity Log / Change Correlationを理解するための前提
Azure Activity LogはAzure resourceのmanagement/control-plane operationを既定で記録し、追加設定なしで収集される。 Activity Logは通常create/update/delete/actionを記録し、read operationは通常記録しない。
イベントは通常発生後3〜20分で分析・alertに利用可能になり、Azure側の既定保持は90日。 90日を超えて保持するにはdiagnostic settingでLog Analytics/Storage/Event Hubs等へexportする。
resource creator informationはActivity Logにのみあるため、監査要件がある環境では90日より長いretentionを設計する。
Control plane と Data plane
仕組みと設計上の意味
ネットワーク障害で最初に聞くべき質問の一つは「直前に誰が何を変えたか」です。Activity LogはNSG/UDR/VNet/Firewall/Application Gateway等のARM management operationを記録し、caller、operation、status、timestamp、correlation IDを持ちます。packet traceでは見えないcontrol-plane changeをincident timelineへ結び付ける役割です。
一方、Activity Logはdata planeのpacket allow/denyやapplication requestを示しません。設定変更がSucceededでも、trafficが成功したとは限りません。またread operationは通常対象外なので、「誰が設定を閲覧したか」の完全な監査ログとして扱わないでください。
Operational / decision path
対象scopeと時刻を固定し、read-only evidence → 判断 → change → same testで再検証の順を崩さない。
- incident start/endの時刻をUTCへ正規化する。
- affected resource ID、resource group、subscriptionを固定する。
- start前後のActivity Logを取得し、Write/Delete/Actionとfailed deploymentを並べる。
- correlationId/caller/operationNameから同じdeploymentやautomation runを束ねる。
- 疑わしいchangeごとにresource config diffとdata-plane testを取り、単なる時刻一致と因果関係を分ける。
設計判断
| 判断点 | 推奨 | 理由 |
|---|---|---|
| Retention | 90日超ならDiagnostic settingでexport | creator/監査情報を失わない |
| Time | incident evidenceはUTCを正本 | Portal local timeとの混乱を避ける |
| Correlation | resource ID + correlationId + caller | 同じdeployment operationを束ねる |
| Causality | Activity Log + config diff + runtime test | Succeeded change＝原因、と短絡しない |
確認手順
Azure Portal
- Monitor → Activity log、または対象resource → Activity logでresource filterを固定。
- Event initiated by / Operation / Status / Timespanをincident windowへ絞る。
- Change historyが利用可能なeventはbefore/afterを確認し、correlation IDを記録。
Evidence contract
Read-only first: 以下のCLI/PowerShellは原則として参照系から開始します。コメントでMUTATINGと示した操作は、必要性・scope・rollbackを確認した後にのみ実行します。
start="2026-09-11T06:00:00Z"
end="2026-09-11T08:00:00Z"
resourceId="<resource-id>"
az monitor activity-log list --resource-id "$resourceId" --start-time "$start" --end-time "$end" --select eventName operationName status eventTimestamp correlationId resourceId caller -o jsonc$start = [datetime]"2026-09-11T06:00:00Z"
$end = [datetime]"2026-09-11T08:00:00Z"
Get-AzActivityLog -ResourceId <resource-id> -StartTime $start -EndTime $end |
Select-Object EventTimestamp, OperationName, Status, Caller, CorrelationId, ResourceId障害切り分け
| 症状 | 疑う点 | 証拠 | 次の確認 |
|---|---|---|---|
| 変更したはずだが見えない | 3〜20分のavailability、別scope、data-plane operation | UTC timestamp + target resource ID | subscription/RG scopeでも検索 |
| 90日より前を調べられない | default retention expired | diagnostic setting destination | Log Analytics/Storage exportの有無を確認 |
| Succeeded change直後に障害 | 相関はあるが因果未確定 | config diff + effective state + runtime test | change内容がpathに影響するか検証 |
| callerがservice principal | automation/IaC deployment | object ID + correlationId | pipeline/run historyと相関 |
変更・rollback
- Activity Log export用diagnostic settingは既存destination/retention/成本を確認して変更する。
- incident中に疑わしいresourceを即rollbackする前に、Activity Log eventとcurrent effective stateを保存する。
- rollback後も同じtest vectorを再実行し、Activity Log上のSucceededだけで復旧完了としない。
- 長期保存先を変更する場合はdual-write期間を設け、query continuityを確認してから旧destinationを停止する。