Diagnostic Settings / Network Loggingを理解するための前提
platform metricsとActivity Logは自動収集されるが、resource logsは既定では収集されずDiagnostic settingが必要。 1 resourceあたり作成できるdiagnostic settingsは最大5つ。
destinationはLog Analytics workspace、Storage account、Event Hubs、partner solution等を用途に応じて選ぶ。 resourceを削除・rename・別RG/subscriptionへmoveする場合、古いdiagnostic settingを残すと同名resource再作成時に意図せず適用される可能性がある。
network incidentで「ログがない」はtrafficがなかった証明ではない。collection configuration、category、destination ingestion、retentionの順に欠測を切り分ける。
Control plane と Data plane
仕組みと設計上の意味
Diagnostic settingsはAzure Monitorへの「配線」です。resourceが出せるlog/metric categoryを選択し、Log Analytics、Storage、Event Hubsなどへ送ります。NSG/Firewall/Application Gateway/VPN/ExpressRoute等は各resource typeでcategoryが異なるため、テンプレートを一律copyするだけでは必要な証拠が欠けます。
resource logは既定収集ではありません。IncidentでKQLを打って0件だった場合、最初に「その時刻・category・resourceが本当にcollection対象だったか」を確認します。Log Analytics destinationが設定されていても、対象categoryがoffなら0件は正常です。
Operational / decision path
対象scopeと時刻を固定し、read-only evidence → 判断 → change → same testで再検証の順を崩さない。
- 対象resource typeが提供するlog/metric categoryを列挙する。
- 現在のdiagnostic settings、destination IDs、enabled categoriesをread-onlyで取得する。
- incident/use caseごとに必要なcategoryとretentionを定義する。
- destination側でingestion/table/storage container/Event Hub受信まで確認する。
- 変更時はdual-writeまたは短い重複期間を設け、queryでnew destinationを検証してから旧設定を外す。
設計判断
| 判断点 | 推奨 | 理由 |
|---|---|---|
| Destination | Log Analytics=interactive query、Storage=長期archive、Event Hubs=stream/SIEM | 用途ごとにretention/latency/costが異なる |
| Categories | resource typeごとに明示 | AllLogs category groupの有無や新category追加を確認 |
| Scale | Policy/initiativeでdeployIfNotExistsを検討 | 手作業の漏れを減らす |
| Lifecycle | resource delete/move時にsettingも棚卸し | stale settingの再適用を防ぐ |
確認手順
Azure Portal
- 対象resource → Monitoring → Diagnostic settingsで現在設定とdestinationを確認。
- Categoriesでresource-specific logs/metricsを確認。
- Log Analytics destinationではLogsからresource ID/time rangeで実データを確認。
Evidence contract
Read-only first: 以下のCLI/PowerShellは原則として参照系から開始します。コメントでMUTATINGと示した操作は、必要性・scope・rollbackを確認した後にのみ実行します。
resourceId="<resource-id>"
# read-only: available categories / current settings
az monitor diagnostic-settings categories list --resource "$resourceId" -o table
az monitor diagnostic-settings list --resource "$resourceId" -o jsonc$resourceId = '<resource-id>'
Get-AzDiagnosticSettingCategory -ResourceId $resourceId
Get-AzDiagnosticSetting -ResourceId $resourceId障害切り分け
| 症状 | 疑う点 | 証拠 | 次の確認 |
|---|---|---|---|
| KQLが0件 | category未有効/時間範囲/ingestion latency | diagnostic setting + category list | destination table/storageまで追う |
| 設定はあるが一部log欠落 | resource-specific category変更/collection semantics | category list + resource log reference | category group/個別categoryを再確認 |
| 新settingを追加できない | 5 settings上限 | diagnostic-settings list | 不要/stale settingのownershipを確認 |
| resource再作成後に意図せず送信 | stale diagnostic setting | Activity Log + setting ID | delete/rename/move時のcleanup手順を修正 |
変更・rollback
- 既存log destinationを置換するとincident evidenceが分断されるため、可能ならdual-writeしてnew pathを先に検証する。
- 大量resourceへPolicy適用する前に代表resourceでcategory/destination/tableを確認し、remediationのblast radiusを把握する。
- 診断設定削除前にretention先のデータ存続条件を確認する。setting削除とstored log削除は同義ではない。
- rollbackでは旧destination/category構成をJSONとして保存し、同じresource ID/time queryでcollection復旧を確認する。