AZ VNet SpaceAzure Networking Wiki
Home / Operations & Troubleshooting
Operations & Troubleshooting参照資料確認: 2026-09-11

Traffic Analytics

Traffic AnalyticsをVNet Flow Logsのaggregate/enrichment layerとして使い、top talker、allowed/blocked、cross-region、public exposureをLog Analyticsで解析する。

この記事の目次
要点証拠診断順序仕組み設計確認証明範囲切り分け変更安全CurrentSources

Traffic Analyticsを理解するための前提

Traffic AnalyticsはNetwork Watcher flow logsを解析し、Azure network trafficをLog Analyticsへ集約・enrichして可視化するcloud-based solution。 raw flow logの1 entryをそのまま1 rowにするのではなく、common source/destination/port/protocol等のflowをaggregationして地理・security・topology情報を付加する。

VNet Flow Logsでは主にNTANetAnalytics、IP enrichmentではNTAIpDetailsを使うcurrent query patternがMicrosoft Learnに掲載されている。 SubType == "FlowLog"をscope条件に使い、schema versionやTimeGenerated/FlowStartTimeの意味を確認してqueryする。

Traffic Analytics enable時にはNWTA prefixのDCR/DCE resourcesをLog Analytics workspaceと同じresource groupに管理する。手動変更すると機能不全の可能性がある。 dashboard/aggregateはincidentの俯瞰に強いが、packet-by-packetの即時真実ではない。緊急時はraw flow log、Connection Troubleshoot、Packet Capture等と組み合わせる。

通信や判断の流れを追う
症状を再現設定を確認能動試験ログ / packetアプリ確認

診断結果をどう読み分けるか

Ingest

VNet/NSG flow logsをinputにする。raw sourceが無ければTraffic Analyticsだけでは生成できない。

Aggregate

同一conversationをまとめ、flow/bytes/count等の分析単位へ縮約。

Enrich

Azure topology、geo、security contextを加える。

Query / alert

Log Analytics/KQLでincident、top talker、public exposure、capacityを分析。

判定原則あるtoolがPASSしたら、そのtoolの責任範囲だけを通過条件にします。「Allow」「Reachable」「Healthy」をnetwork/application全体の正常証明へ拡大しません。

障害が起きたときの調べ方

  1. VNet Flow Logsが対象VNetで正常にStorageへ出ていることを先に確認する。
  2. Traffic Analyticsをenableし、workspace、interval、managed NWTA DCR/DCEを記録する。
  3. known test flowを生成し、NTANetAnalyticsでtarget resource/source/destination/portが確認できることを待って検証する。
  4. production queryは必ずtime windowとscopeを先頭で絞り、全workspace scanを避ける。
  5. aggregate値を読むときはFlowDirection、BytesSrcToDest/BytesDestToSrc、FlowType、Src/Dest fieldsの意味をschemaで確認する。
  6. incidentではaggregate trendでscopeを見つけ、必要なconversationをraw flow/active diagnostic/packetへ落とす。

仕組みと読み方

Traffic Analyticsはraw flow dataを「運用で問いやすい形」に変換するlayerです。たとえば「過去30日でpublic IPと会話したsubnet」「region間の転送量」「on-premから最もtrafficを受けたVM」といったqueryが可能です。したがって容量計画やセキュリティレビュー、incidentのscope発見に向きます。

ただしaggregationされたrowを1 packet/1 connectionと解釈すると誤ります。特にbytes方向、flow開始/終了、schema version、SrcIp/DestIpが空になるpublic flowなどはcurrent schemaに従って読む必要があります。

運用設計

判断軸運用設計
Workspace strategynetwork telemetryのworkspace境界とRBAC/retentionを決める。
DCR/DCE ownershipNWTA managed resourcesを手動編集対象から除外し監視する。
Query libraryincident/use caseごとにtested KQLをversion control。
Cost / intervalanalytics processing volumeとintervalを目的に合わせる。
Raw fallbackTraffic Analyticsだけでなくraw Storage flow logへの調査pathを維持。

確認手順 / read-only first

実行前に固定する情報

  • subscription / resource group / resource ID / region
  • source IP/NIC/subnet と destination FQDN/IP
  • protocol / source port / destination port
  • UTC time window + JST表示
  • expected result と known-good comparison

Evidence to keep

  • command/query textとraw JSON/CSV
  • Portal screenshotだけでなくresource IDを含む機械可読結果
  • 変更前/変更後の同一test vector
  • negative test と adjacent critical path
  • rollback実施時の復帰確認
Azure CLI — read-only first
az network watcher flow-log show --location <region> --name <flow-log-name> -o jsonc
# trafficAnalyticsConfiguration / workspace / interval を確認
PowerShell — read-only first
Get-AzNetworkWatcherFlowLog -NetworkWatcher <watcher>
# Traffic Analyticsがenableか、対象workspaceを確認
KQL — scope first
NTANetAnalytics
| where SubType == "FlowLog" and TimeGenerated > ago(1h)
| where isnotempty(SrcIp) and isnotempty(DestIp)
| summarize TotalBytes=sum(BytesSrcToDest + BytesDestToSrc)
    by SrcIp, DestIp, DestPort, L4Protocol
| top 50 by TotalBytes desc

この結果で何を証明できるか

観測結果証明できることそれだけでは証明できないこと
Top talker rowanalytics windowでaggregate trafficが大きいendpoint。packet lossやapplication slownessの原因。
Denied flow countflow analytics上deny eventが集計。全security devicesのdeny。
Cross-region bytesenriched SrcRegion/DestRegion間の転送傾向。exact billing/packet timing。
No row yetanalytics tableに該当aggregateが未確認。raw traffic不存在。processing lag/configを確認。
NTAIpDetails enrichmentpublic IP/security/geo contextが付与。外部IPの所有者・悪性を絶対保証。別sourceで確認。

よくある切り分けの失敗

症状 / 状態疑う層次の証拠
tableに出ないflow log/TA config/processing delayraw Storage→flow log config→NWTA resourcesの順。
query結果が二重NSG/VNet flow logs重複target resource/log migrationを確認。
bytesが直感と違うdirection/schema誤読schemaのSrcToDest/DestToSrcを確認。
NWTA resourceが変更されているmanaged DCR/DCE破損手動changeを戻しTA設定を正規pathで管理。
legacy queryだけ動くAzureNetworkAnalytics_CL依存VNet flow用NTANetAnalytics queryへ更新。

変更時の確認と rollback

  • analytics設定を変更する前にworkspace/interval/DCR/DCE IDを保存する。
  • query/alert変更とflow log enable/disableを同時changeにしない。
  • 機能復旧後はknown flowがraw logとNTANetAnalyticsの両方で見えることを確認する。
Change safety: 診断中にsecurity、route、DNS、proxy/backendを同時変更すると、どの差分が効いたか分からなくなります。1 hypothesisずつ変更し、同じtest vectorでbefore/afterを取ります。

Current notes — 2026-09-11

Current behavior / guidance

current Traffic Analytics docsはVNet Flow LogsをinputとしてNTANetAnalytics/NTAIpDetailsを使うquery例を提供しています。またTraffic Analyticsが管理するNWTA prefix DCR/DCEを変更すると機能しない可能性があるため、運用上の保護対象として明記しました。

VNet Flow Logs
同じtest vectorを別の観測面から確認する。Networking KQL Patterns
同じtest vectorを別の観測面から確認する。Incident: First 15 Minutes
同じtest vectorを別の観測面から確認する。Packet Walk Method
同じtest vectorを別の観測面から確認する。

Official sources

動作、support boundary、preview/GA、retirement、schemaはMicrosoft Learnのcurrent documentationを基準にしています。productionで使う際は対象subscription/region/resource provider/API/CLI versionの最新documentationを再確認してください。