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

Connection Monitor

Connection Monitorを継続的なsynthetic reachability/latency監視として設計し、test group・endpoint・alert・incident drill-downをproduction運用へ結び付ける。

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

Connection Monitorを理解するための前提

Connection Monitorはendpoint間のconnectivityを継続監視し、TCP、ICMP、HTTP probeによるpacket loss/latency等を時系列で追う。 Connection Monitor (classic) はdeprecatedかつ利用不可。新規設計やmigration後のrunbookでは現行Connection Monitorを基準にする。

監視はsource endpoint、destination endpoint、test configuration、test groupの組み合わせとして定義する。1 monitorに異なるcritical pathを詰め込みすぎない。 alertは「一時的な1 probe failure」と「持続したservice-impact」を区別できるthreshold/windowで設計する。

synthetic probe successは全ユーザーtrafficの成功を証明しない。source位置、DNS、protocol/port、TLS/HTTP条件が実trafficとどこまで一致するかを明示する。 incident時はConnection Monitorで発生時刻と範囲を絞り、Connection Troubleshoot/Next Hop/IP Flow Verify/Packet Captureへdrill downする。

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

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

Baseline

平常時のlatency/loss/reachability。変更前baselineと時間帯変動を持つ。

Detection

test groupの失敗率やlatency悪化。いつ・どのpairから崩れたかを検知。

Localization

source/destination pairやtest config比較でscopeを狭める。

Confirmation

専用diagnostic toolと実application journeyで原因/復旧を確定。

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

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

  1. business-critical pathを「source endpoint→destination endpoint→protocol/port/HTTP条件」に分解し、monitoring intentを明文化する。
  2. 複数region/site/subnetから代表sourceを置き、単一monitoring VMの故障を全体障害と誤認しない構成にする。
  3. 平常時baselineを蓄積し、平均だけでなく失敗率/latencyの分布とmaintenance windowを把握する。
  4. alert発報時は最初のbad timestamp、affected test group、source/destination、recent changeを固定する。
  5. 同じpairをConnection Troubleshootでpoint-in-time再検査し、routing/security/port faultへ落とす。
  6. 修正後はalertが自然回復したことだけでなく、同じtest groupの連続成功と実applicationを確認する。

仕組みと読み方

Connection Monitorは「常時PCAP」ではありません。定義したprobeを一定間隔で実行し、その成功/失敗やlatencyを監視するsynthetic telemetryです。この性質により、断続障害の開始時刻・影響pair・region/site差を見つけるのに向きます。一方、payload、session reuse、特定ユーザーのDNS cache、複雑なapplication transactionは直接再現しません。

監視設計ではendpoint数を増やすほどcoverageは上がりますが、原因判定可能性も考える必要があります。例えば全branch→単一Azure VMだけでなく、branch→private endpoint、hub→spoke、spoke→on-premなど設計上の境界ごとにtest groupを分けると、failure domainを早く特定できます。

運用設計

判断軸運用設計
Test topologynetwork boundaryごとに代表pairを置く。大量endpointの全組合せ監視は目的を明確にする。
Thresholdbaselineからalert thresholdを決める。単発failureだけでsev1にしない。
Ownershipmonitor/test groupにservice ownerとescalation先を紐付ける。
Change correlationdeployment/change windowをmonitor timelineへ重ねられる運用を用意する。
Classic migrationclassic前提のrunbook/automationが残っていないか棚卸しする。

確認手順 / 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 connection-monitor list --location <region> -o table
az network watcher connection-monitor show --location <region> --name <monitor> -o jsonc
az network watcher connection-monitor query --location <region> --name <monitor> -o jsonc
PowerShell — read-only first
Get-AzNetworkWatcherConnectionMonitor -NetworkWatcherName <watcher> -ResourceGroupName <network-watcher-rg>

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

観測結果証明できることそれだけでは証明できないこと
Monitor healthy定義したprobeが直近windowで成功。未監視protocol/path/user transactionの成功。
One source failsそのsource/test configに局所化できる兆候。source host障害かnetwork障害か。source healthを追加確認。
All sources faildestination/common transit/shared policyの可能性上昇。必ず共通componentが原因とは限らない。recent changeとactive diagで確認。
Latency regressionsynthetic pathのround-tripがbaselineより悪化。どのhop/queue/applicationが遅いか。
Alert clearedthreshold条件が回復。root cause解消や実application完全回復。

よくある切り分けの失敗

症状 / 状態疑う層次の証拠
false positiveが多いthreshold/test frequency不適切baselineからwindow/thresholdを再設計。
実障害なのにmonitor正常coverage gap本番clientとsource/DNS/protocol/portが一致するか確認。
一部pairだけ悪化route/region/site依存pairごとのNext Hop/Connection Troubleshootへ。
classic monitorが前提deprecated path現行Connection Monitorへmigrationしautomationを更新。
alert後に原因不明monitorだけで完結させているactive diagnostic + flow/packet evidenceへdrill down。

変更時の確認と rollback

  • monitoring設定変更はtraffic転送設定と別changeとして扱う。
  • thresholdを緩めてalertを消すことを障害復旧とみなさない。
  • monitor再構成後はknown-good/known-badの両testで意図した検知ができるか確認する。
Change safety: 診断中にsecurity、route、DNS、proxy/backendを同時変更すると、どの差分が効いたか分からなくなります。1 hypothesisずつ変更し、同じtest vectorでbefore/afterを取ります。

Current notes — 2026-09-11

Current behavior / guidance

Connection Monitor (classic) はMicrosoft Learnでdeprecatedかつno longer availableと明記されています。現行Connection MonitorはAzure/hybridの継続connectivity監視として扱い、point-in-time診断はConnection Troubleshootへ分離します。

Connection Troubleshoot
同じtest vectorを別の観測面から確認する。Network Watcher
同じtest vectorを別の観測面から確認する。Incident: First 15 Minutes
同じtest vectorを別の観測面から確認する。Network Change Validation
同じtest vectorを別の観測面から確認する。

Official sources

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