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

Networking KQL Patterns

Azure networking incidentで使うKQLを、time scope、5-tuple、NTANetAnalytics、NTAIpDetails、resource-specific logsの読み分けと再利用可能なquery patternで整理する。

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

Networking KQL Patternsを理解するための前提

KQLは「何となくworkspace全体を検索」せず、time range→resource→source/destination→port/protocolの順でscopeを狭める。 VNet Flow Logs + Traffic Analyticsのcurrent primary tableはNTANetAnalytics。SubType == "FlowLog"とschema version/field semanticsを確認する。

AzureNetworkAnalytics_CLはlegacy NSG Flow Logs系queryで見かけるため、既存runbookをVNet Flow Logsへ移行するときにtable名/column suffix差を吸収する。 NTAIpDetailsはIP enrichment用。public/geo/threat contextをflow rowと同じ「通信の事実」と混同しない。

TimeGenerated、FlowStartTime、FlowIntervalStartTime等は意味が違う。incident timestampへ合わせる前にschemaを確認する。 query結果は保存可能なevidenceとして、query text、workspace、UTC range、result count、export timestampをincident recordへ残す。

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

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

Scope first

TimeGenerated > ago(...) + target resource/subscription/VNetで最初に減らす。

Tuple next

SrcIp/DestIp/DestPort/L4Protocolでconversation候補へ。

Aggregate consciously

summarize後のrowはraw eventではない。group keyを明示。

Correlate

flow、Firewall/WAF、AppGW、platform logsを同じUTC window/request ID/5-tupleで結ぶ。

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

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

  1. incident開始/終了時刻をUTCで固定し、workspaceとtarget resource IDを記録する。
  2. 最初のqueryはtakeよりschema/known fieldsを確認し、VNet Flow/legacy tableのどちらかを判定する。
  3. 5-tupleまたはFQDN→resolved IPでflow candidateを絞る。
  4. Allowed/Denied/bytes/direction/FlowType等をprojectし、必要なgroup keyだけでsummarizeする。
  5. resource logsがある場合は同じtime windowでFirewall/WAF/AppGW等へ横展開し、request ID/tupleで相関する。
  6. queryをincident-specificな値と再利用可能templateに分け、修正後のpost-checkにも同じtemplateを使う。

仕組みと読み方

KQLで最も多い失敗は、table/schemaを確認せず過去のcolumn名を貼り付けることと、集計後のrowをraw eventのように解釈することです。Traffic Analyticsはaggregation/enrichment layerなので、summarize前からすでにraw packetではありません。結果の意味を「このwindowにこういうflow aggregateがあった」と表現します。

またnetwork incidentは複数telemetry sourceを跨ぎます。flow logでdenyが無くてもAzure Firewall application rule、WAF、App Gateway backend health、guest firewall、DNSが原因になり得ます。1つの巨大joinを最初から作るより、各sourceで確実なcandidateを作ってtimestamp/tuple/request IDで段階的に相関する方が安全です。

運用設計

判断軸運用設計
Query headerworkspace、UTC range、target IDs、assumptionをcommentで残す。
Schema pinningtable/column/schema versionをcurrent docsで確認。
Reusable functionsIP/port/timeをparameter化したrunbook queryを維持。
Result limitsincident時の全件exportを避け、project/summarize/topで必要情報へ。
Legacy migrationAzureNetworkAnalytics_CL依存queryをNTANetAnalyticsへ棚卸し。

確認手順 / 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
# Log Analytics query実行方法は組織のAzure Monitor運用/認証方式に合わせる
# まず対象workspace/resource IDとUTC rangeを固定する
PowerShell — read-only first
# PowerShellからもAzure Monitor Logsを取得可能だが、query text自体をrunbookのsource of truthとして管理する
KQL — scope first
let startTime = ago(1h);
let src = "10.0.0.4";
let dst = "10.20.0.8";
NTANetAnalytics
| where SubType == "FlowLog" and TimeGenerated >= startTime
| where SrcIp == src and DestIp == dst
| project TimeGenerated, FlowStartTime, FlowEndTime, SrcIp, DestIp,
          DestPort, L4Protocol, FlowStatus, BytesSrcToDest, BytesDestToSrc,
          AclGroup, AclRule, TargetResourceId
| order by TimeGenerated asc

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

観測結果証明できることそれだけでは証明できないこと
Rows in time windowtableに該当analytics recordが存在。raw packet chronologyの完全再現。
AclRule / FlowStatusanalyticsが付与したsecurity decision context。WAF/Firewall/guest policyすべて。
BytesSrcToDest > 0aggregateでsource→destination byte記録。application transaction success。
No resultそのquery条件ではrowなし。traffic不存在。schema/time/scope/lagの誤りを先に排除。
Join matches timestamptelemetry間に時間的相関。因果関係。追加evidenceで確定する。

よくある切り分けの失敗

症状 / 状態疑う層次の証拠
0件table/schema/time/resource誤りschema→UTC→scope→processing lagの順で確認。
大量resultscope不足time/resource/tupleを先にwhere。
旧queryが失敗legacy column/tableNTANetAnalytics current schemaへ移行。
bytesが倍に見えるduplicate logging/aggregationNSG+VNet duplicateとgroup keyを確認。
原因断定が早いcorrelationをcausation扱いactive test/packet/config diffで裏付ける。

変更時の確認と rollback

  • KQL/alert変更はforwarding設定と別changeとして扱う。
  • saved queryを更新した場合はknown fixture/time windowで期待rowが返ることを確認する。
  • legacy query削除前にVNet Flow Logs/NTANetAnalytics migrationがproductionで成立していることを確認する。
Change safety: 診断中にsecurity、route、DNS、proxy/backendを同時変更すると、どの差分が効いたか分からなくなります。1 hypothesisずつ変更し、同じtest vectorでbefore/afterを取ります。

Current notes — 2026-09-11

Current behavior / guidance

Microsoft Learnのcurrent Traffic Analytics query guideはVNet Flow LogsのNTANetAnalyticsとNTAIpDetailsを中心に例示し、legacy NSG Flow Logs向けAzureNetworkAnalytics_CLも別sectionで残しています。本ページは両者を混同しないmigration-awareなKQL referenceに更新しています。

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

Official sources

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