Network Watcher のメトリックとログを使用したネットワークのトラブルシューティング

  • 9 分

問題をすばやく診断する場合は、Azure Network Watcher ログで利用可能な情報を理解する必要があります。

エンジニアリング会社では、スタッフがネットワーク構成の問題を診断して解決するのにかかる時間を最小限に抑える必要があります。 彼らがどのログにどの情報が含まれているかを確実に把握できるようにしたい。

このモジュールでは、フロー ログ、診断ログ、トラフィック分析に重点を置き、これらのツールが Azure ネットワークのトラブルシューティングにどのように役立つかを学習します。

使用量とクォータ

各 Microsoft Azure リソースは、そのクォータまで使用できます。 各サブスクリプションには個別のクォータがあり、使用量はサブスクリプションごとに追跡されます。 リージョンごとにサブスクリプションごとに必要な Network Watcher のインスタンスは 1 つだけです。 このインスタンスでは、クォータに達するリスクがあるかどうかを確認できるように、使用量とクォータが表示されます。

使用状況とクォータの情報を表示するには、[ すべてのサービス>Networking>Network Watcher] に移動し、[ 使用量とクォータ] を選択します。 ここでは、使用状況とリソースの場所に基づいて詳細なデータが表示されます。 次のメトリックのデータがキャプチャされます。

  • ネットワーク インターフェイス
  • ネットワーク セキュリティ グループ (NSG)
  • 仮想ネットワーク
  • パブリック IP アドレス

ポータルの使用量とクォータを示す例を次に示します。

Network Watcher を使用した使用量とクォータを示すスクリーンショット。

ログ

ネットワーク診断ログには、接続とパフォーマンスの問題をより深く理解するための詳細なデータが用意されています。 Network Watcher には、次の 3 つのログ表示ツールがあります。

  • ネットワーク セキュリティ グループ (NSG) フロー ログ
  • 診断ログ
  • トラフィック分析

これらの各ツールを見てみましょう。

ネットワーク セキュリティ グループ (NSG) フロー ログ

NSG フロー ログでは、ネットワーク セキュリティ グループのイングレス IP トラフィックとエグレス IP トラフィックに関する情報を表示できます。 フロー ログには、フローが適用されるネットワーク アダプターに基づいて、規則ごとに送信フローと受信フローが表示されます。 NSG フロー ログは、キャプチャされた 5 タプル情報に基づいてトラフィックが許可されたか拒否されたかを示します。 この情報には、次のものが含まれます。

  • 発信元 IP
  • 送信元ポート
  • 宛先 IP
  • 宛先ポート
  • プロトコル

この図は、NSG が従うワークフローを示しています。

受信トラフィックからルールの一致、そしてパケットを許可または拒否するまでのワークフローを示すNSGのスクリーンショット。

フロー ログは、JSON ファイルにデータを格納します。 特に Azure に大規模なインフラストラクチャがデプロイされている場合は、ログ ファイルを手動で検索することで、このデータに関する分析情報を得るのは困難な場合があります。 この問題を解決するには、Power BI を使用します。

Power BI では、さまざまな方法で NSG フロー ログを視覚化できます。 例えば次が挙げられます。

  • トップ トーカー (IP アドレス)
  • 方向ごとのデータフロー (受信と送信)
  • 意思決定別のフロー (許可および拒否)
  • 宛先ポート別のフロー

オープン ソース ツールを使用して、Elastic Stack、Grafana、Graylog などのログを分析することもできます。

注

NSG フロー ログは、Azure クラシック ポータルのストレージ アカウントをサポートしていません。

診断ログ

Network Watcher では、診断ログは、Azure ネットワーク リソースのログを有効または無効にする中心的な場所です。 これらのリソースには、NSG、パブリック IP、ロード バランサー、アプリ ゲートウェイが含まれる場合があります。 目的のログを有効にした後、ツールを使用してログ エントリのクエリと表示を行うことができます。

診断ログは、Power BI やその他のツールにインポートして分析できます。

トラフィック分析

クラウド ネットワーク全体のユーザーとアプリのアクティビティを調査するには、トラフィック分析を使用します。

このツールは、サブスクリプション全体のネットワーク アクティビティに関する分析情報を提供します。 オープン ポート、既知の不適切なネットワークと通信する仮想マシン (VM)、トラフィック フロー パターンなどのセキュリティ上の脅威を診断できます。 トラフィック分析では、Azure リージョンとサブスクリプション全体の NSG フロー ログが分析されます。 データを使用して、ネットワーク パフォーマンスを最適化できます。

このツールには Log Analytics が必要です。 Log Analytics ワークスペースは、サポートされているリージョンに存在する必要があります。

ユース ケース シナリオ

次に、Azure Network Watcher のメトリックとログが役立つユース ケース シナリオをいくつか見てみましょう。

パフォーマンスの低下に関する顧客レポート

パフォーマンスの低下を解決するには、問題の根本原因を特定する必要があります。

  • サーバーはトラフィックの影響で過剰に制限されていませんか?
  • VM サイズはジョブに適していますか?
  • スケーラビリティのしきい値は適切に設定されていますか?
  • 悪意のある攻撃は発生していますか?
  • VM ストレージの構成は正しいですか?

まず、VM サイズがジョブに適していることを確認します。 次に、VM で Azure Diagnostics を有効にして、CPU 使用率やメモリ使用量などの特定のメトリックに関するより詳細なデータを取得します。 ポータルを使用して VM 診断を有効にするには、 VM に移動し 、[診断設定] を選択して、診断を有効にします。

正常に実行されている VM があるとします。 ただし、VM のパフォーマンスは最近低下しています。 リソースのボトルネックがあるかどうかを特定するには、キャプチャされたデータを確認する必要があります。

報告された問題の前後にキャプチャされたデータの時間範囲から始めて、パフォーマンスの正確なビューを取得します。 これらのグラフは、同じ期間に異なるリソースの動作を相互参照する場合にも役立ちます。 確認すべきことは次の通りです。

  • CPU のボトルネック
  • メモリのボトルネック
  • ディスクのボトルネック

CPU のボトルネック

パフォーマンスの問題を確認するときは、傾向を調べて、サーバーに影響があるかどうかを把握できます。 傾向を特定するには、ポータルから監視グラフを使用します。 監視グラフには、さまざまな種類のパターンが表示される場合があります。

  • 分離されたスパイク。 スパイクは、スケジュールされたタスクや予想されるイベントに関連している可能性があります。 このタスクが何であるかがわかっている場合、必要なパフォーマンス レベルで実行されますか? パフォーマンスが問題ない場合は、容量を増やす必要がない可能性があります。
  • 急上昇と一定。 新しいワークロードがこの傾向を引き起こす可能性があります。 VM で監視を有効にして、負荷の原因となるプロセスを確認します。 消費の増加は、非効率的なコードが原因であるか、新しいワークロードの通常の消費である可能性があります。 消費が正常な場合、プロセスは必要なパフォーマンス レベルで動作しますか?
  • 定数。 VM は常にこのようになっていますか? その場合は、ほとんどのリソースを消費するプロセスを特定し、容量の追加を検討する必要があります。
  • 着実に増加しています。 消費が一定に増加していますか? その場合、この傾向は、非効率的なコードや、より多くのユーザー ワークロードを引き受けるプロセスを示している可能性があります。

CPU 使用率が高い場合は、次のいずれかを実行できます。

  • VM のサイズを大きくして、より多くのコアでスケーリングします。
  • 問題をさらに調査します。 アプリとプロセスを見つけて、それに応じてトラブルシューティングを行います。

VM をスケールアップしても CPU が 95% を超えて実行されている場合、アプリのパフォーマンスは向上していますか、それともアプリのスループットが許容できるレベルまで高いのでしょうか。 そうでない場合は、その個々のアプリのトラブルシューティングを行います。

メモリのボトルネック

VM が使用するメモリの量を表示できます。 ログは、傾向と、問題が発生した時刻にマップされているかどうかを理解するのに役立ちます。 使用可能なメモリは、いつでも 100 MB 未満にする必要があります。 次の傾向に注意してください。

  • 急上昇と継続的な消費。 メモリ使用率が高い場合は、パフォーマンスが低下する原因にならない可能性があります。 リレーショナル データベース エンジンなどの一部のアプリは、設計上メモリを集中的に消費します。 ただし、メモリ不足のアプリが複数ある場合は、メモリの競合によってディスクへのトリミングとページングが発生するため、パフォーマンスが低下する可能性があります。 これらのプロセスは、パフォーマンスに悪影響を及ぼします。
  • 使用量は着実に増加しています。 この傾向は、アプリが ウォームアップしている可能性があります。 データベース エンジンが起動する場合が一般的です。 ただし、アプリのメモリ リークの兆候である可能性もあります。
  • ページまたはスワップ ファイルの使用状況。 Windows ページ ファイルを頻繁に使用しているか、または /dev/sdb にある Linux スワップ ファイルを使用しているかどうかを確認します。

高いメモリ使用率を解決するには、次の解決策を検討してください。

  • VM のサイズを増やしてメモリを追加し、監視します。 即時の緩和や過剰なページファイルの使用のため。
  • 問題をさらに調査します。 ボトルネックの原因となっているアプリまたはプロセスを見つけてトラブルシューティングします。 アプリがわかっている場合は、メモリ割り当てを上限にできるかどうかを確認します。

ディスクのボトルネック

ネットワーク パフォーマンスは、VM のストレージ サブシステムにも関連している場合があります。 ポータルで VM のストレージ アカウントを調査できます。 ストレージに関する問題を特定するには、ストレージ アカウントの診断と VM 診断のパフォーマンス メトリックを確認します。 特定の時間範囲内で問題が発生した場合の主な傾向を探します。

  • Azure Storage のタイムアウトを確認するには、 メトリック ClientTimeOutError、 ServerTimeOutError、 AverageE2ELatency、 AverageServerLatency、 TotalRequests を使用します。 TimeOutError メトリックに値が表示される場合、I/O 操作に時間がかかりすぎてタイムアウトしました。AverageServerLatency がTimeOutErrors と同時に増加する場合は、プラットフォームの問題である可能性があります。 Microsoft テクニカル サポートでケースを作成します。
  • Azure Storage の調整を調べるには、ストレージ アカウントのメトリック ThrottlingError を使います。 調整が発生した場合は、アカウントの 1 秒あたりの入出力操作数 (IOPS) の制限に達しています。 この問題は、 メトリック TotalRequests を調べることで確認できます。

高いディスク使用率と待機時間の問題を修復するには:

  • VM I/O を最適化して、仮想ハードディスク (VHD) の制限を超えてスケーリングします。
  • スループットを向上させ、待機時間を短縮します。 待機時間の影響を受けやすいアプリがあり、高スループットが必要な場合は、VHD を Azure Premium Storage に移行します。

トラフィックをブロックする仮想マシンのファイアウォール規則

NSG フローの問題をトラブルシューティングするには、Network Watcher ツールの IP フロー検証と NSG フロー ログを使用して、NSG またはユーザー定義ルーティング (UDR) がトラフィック フローを妨げているかどうかを判断します。

IP フロー検証を実行し、ローカル VM とリモート VM を指定します。 [チェック] を選択すると、Azure は規則に対して論理テストを実行します。 その結果、アクセスが許可される場合は、NSG フロー ログを使用します。

ポータルで NSG に移動します。 フロー ログの設定で、[オン] を選択 します。 ここで、VM にもう一度接続してみてください。 Network Watcher トラフィック分析を使用して、データを視覚化します。 その結果、アクセスが許可された場合、その方法には NSG ルールはありません。

この時点に達しても問題が診断されない場合は、リモート VM に問題がある可能性があります。 リモート VM 上のファイアウォールを無効にしてから、接続を再テストします。 ファイアウォールを無効にしてリモート VM に接続できる場合は、リモート ファイアウォールの設定を確認します。 次に、ファイアウォールを再度有効にします。

フロントエンドとバックエンドのサブネットが通信できない

既定では、すべてのサブネットが Azure で通信できます。 2 つのサブネット上の 2 つの VM が通信できない場合は、通信をブロックしている構成が必要です。 フロー ログを確認する前に、フロントエンド VM からバックエンド VM への IP フロー検証ツールを実行します。 このツールは、ネットワーク上のルールに対して論理テストを実行します。

結果がバックエンド サブネット上の NSG で、すべての通信をブロックしている場合は、その NSG を再構成します。 セキュリティ上の理由から、フロントエンドがパブリック インターネットに公開されているため、フロントエンドとの通信をブロックする必要があります。

バックエンドへの通信をブロックすることで、マルウェアやセキュリティ攻撃が発生した場合の露出の量を制限できます。 ただし、NSG がすべてブロックされている場合、その構成は正しくありません。 必要な特定のプロトコルとポートを有効にします。