メトリック、アラート、リソース正常性を使用した Standard Load Balancer の診断

データ パスの可用性メトリックでは、VM が存在するコンピューティング ホストまでの、データ パスのリージョン内の正常性が示されます。 メトリックは、構成とAzure インフラストラクチャに基づいて、ロード バランサーの正常性を反映したものです。 このメトリックは次の目的に使うことができます。

• サービスの外部可用性を監視します。

• サービスがデプロイされているプラットフォームを調査し、正常かどうかを判断します。 ゲスト OS またはアプリケーション インスタンスが正常かどうかを確認します。

• イベントがサービスと基盤のデータ プレーンのどちらに関係するかを切り分けます。 このメトリックと正常性プローブの状態メトリックを混同しないようにしてください。

Load Balancer リソースのデータ パスの可用性を取得するには:

1. 正しいロード バランサー リソースが選ばれていることを確認します。

2. [メトリック] ドロップダウン リストで [Data Path Availability](データ パスの可用性) を選択します。

3. [集計] ドロップダウン リストで [平均] を選択します。

4. さらに、必要なフロントエンド IP アドレスまたはフロントエンド ポートを含むディメンションとしてフロントエンド IP アドレスまたはフロントエンド ポートに対するフィルターを追加します。 次に、選択したディメンションでグループ化します。

メトリックは、トラフィックをシミュレートするリージョン内のプローブ サービスによって生成されます。 プローブ サービスでは、展開のフロントエンドと負荷分散規則に一致するパケットが定期的に生成されます。 パケットはその後、送信元からバックエンドプール内のVMのホストまでリージョンを通過します。 ロード バランサー インフラストラクチャは、他のすべてのトラフィックの場合と同じ負荷分散操作と変換操作を実行します。 バックエンド プール内の VM が存在するホストにプローブが到達した後に、ホストはプローブ サービスへの応答を生成します。 VM はこのトラフィックを認識しません。

データ パスの可用性メトリックは、負荷分散規則を使用するフロントエンド IP 構成でのみ生成されるこので注意してください。

データ パスの可用性メトリックは、次の理由により機能が低下する可能性があります。

• 展開のバックエンド プールに正常な VM が残っていない。

• インフラストラクチャ障害が発生した。

診断の目的で、データ パスの可用性メトリックと共に正常性プローブの状態を使うことができます。

ほとんどのシナリオでは集計として平均を使います。

正常性プローブ状態メトリックでは、ユーザーがロード バランサーの正常性プローブを構成するときにユーザーによって構成されたアプリケーションのデプロイの正常性が示されます。 ロード バランサーは、正常性プローブの状態を使って、新しいフローの送信先を決めます。 正常性プローブは、Azure インフラストラクチャ アドレスから送信され、VM のゲスト OS 内に表示されます。

Load Balancer リソースの正常性プローブの状態を取得するには:

1. Health Probe StatusメトリックをAvg集約タイプで選択します。

2. 必要なフロントエンドの IP アドレスまたはポート (またはその両方) にフィルターを適用します。

正常性プローブは次の理由で失敗します。

• リッスンしていないポート、応答していないポート、または正しくないプロトコルを使用しているポートに対して、正常性プローブを構成している。 サービスが Direct Server Return またはフローティング IP ルールを使っている場合は、サービスが、NIC の IP 構成の IP アドレスとフロントエンド IP アドレスで構成されたループバックでリッスンしていることを確認します。

• ネットワーク セキュリティ グループ、VM のゲスト OS ファイアウォール、またはアプリケーション層フィルターが、正常性プローブのトラフィックを許可していません。

ほとんどのシナリオでは集計として平均を使います。

SNAT接続数指標は 、アウトバウンドフローの成功した接続と失敗した接続の量を表します。

接続容量が0を超える失敗はSNATポートの消耗を示します。 これらの故障の原因を特定するために、さらに調査が必要です。 SNAT ポートの不足は、送信フロー確立の失敗として示されます。 シナリオおよび動作メカニズムを理解し、SNAT ポートの不足を軽減する方法または回避する設計の方法を学習するには、送信接続に関する記事をご覧ください。

アウトバウンド接続が断続的に故障する場合は、SNATポートの消耗が原因かもしれません。 SNATポート利用率と割り当て指標を確認し、SNATポート枯渇ガイダンスを確認してください。 より大きなSNAT容量を使いたい場合は、Azure NAT Gatewayをご利用ください。

SNAT 接続の統計情報を取得するには:

1. トリックの種類として [SNAT Connections](SNAT 接続) を、集計として [合計] を選択します。

2. SNAT 接続の成功と失敗のカウントを異なる行に表示するには、 [接続の状態] でグループ化します。

[使用された SNAT ポート] メトリックでは、送信フローを保持するために使用されている SNAT ポートの数が追跡されます。 この指標は、インターネットソースとロードバランサーの背後にあるバックエンドのVMや仮想マシンスケールセットとの間で、パブリックIPアドレスを持たないユニークなフローの数を示します。 使用しているSNATポート数と割り当て済みSNATポートの指標を比較することで、サービスがSNAT耗尽やアウトバウンドフロー障害のリスクがあるかどうかを判断できます。

メトリックが送信フロー障害のリスクを示している場合は、サービスの正常性を確保するために、こちらの記事を参照し、この問題を軽減するための手順を実行してください。

SNAT ポートの使用状況と割り当てを確認するには:

1. グラフの時間の集計を 1 分に設定して、目的のデータが表示されるようにします。

2. メトリックの種類として [使用された SNAT ポート] および/または [割り当てられた SNAT ポート] を選択し、集計として [平均] を選択します。

   • 既定では、これらのメトリックは、各バックエンド VM または仮想マシン スケール セットに割り当てられた、またはこれらによって使用されている SNAT ポートの平均数です。 これらは、Load Balancer にマップされているすべてのフロントエンド パブリック IP に対応し、TCP と UDP を介して集計されます。

   • ロード バランサーが使用している、またはロード バランサーに割り当てられた SNAT ポートの合計数を確認するには、メトリック集計の [Sum](合計) を使用します。

3. フィルター処理によって、特定のプロトコルの種類、一連のバックエンド IP、および/またはフロントエンド IP に絞り込みます。

4. バックエンドまたはフロントエンド インスタンスごとに正常性を監視するには、分割を適用します。

   • 分割では、一度に 1 つのメトリックしか表示できないので注意してください。

5. 例えば、マシンごとのTCPフローのSNAT使用状況を監視し、 平均で集約し、 バックエンドIPで分割し、 プロトコルタイプでフィルタリングします。

アウトバウンド接続の詳細については、「アウトバウンド接続に送信元ネットワーク アドレス変換 (SNAT) を使用する」を参照してください。

ほとんどのシナリオでは、集計として Sum を使用します。

バイト カウンターおよびパケット カウンターのメトリックは、フロントエンドごとにサービスによって送信または受信されたバイトおよびパケットの量を示します。

ほとんどのシナリオでは、集計として Sum を使用します。

バイト数またはパケット数の統計情報を取得するには:

1. Bytes CountとPacket Countのメトリクスタイプを選択し、Sumをアグリゲーションとして使います。

2. 以下のいずれかを実行します。

   • 特定のフロントエンド IP、フロントエンド ポート、バックエンド IP、またはバックエンド ポートにフィルターを適用します。

   • フィルターを適用せずにロード バランサー リソースの全体的な統計情報を取得します。

データ パスの可用性メトリックと正常性プローブの状態メトリックを 1 つのグラフに組み合わせて使用すると、問題を探して解決する必要がある場所を特定することができます。 Azureが正しく動作していることを保証し、この知識を使用して、構成またはアプリケーションが根本原因であると確定的に判断できます。

正常性プローブ メトリックを使用して、Azureが指定した構成に従ってデプロイの正常性を表示する方法を理解できます。 正常性プローブを確認することは、常に、原因を監視または特定するのに適した第一歩です。

さらに一歩進み、データ パスの可用性メトリックを使用して、特定のデプロイを担当Azure基になるデータ プレーンの正常性を表示する方法を把握できます。 次の例に示すように、両方のメトリックを組み合わせると、障害の可能性がある場所を分離できます。

図: データ パスの可用性メトリックと正常性プローブの状態メトリックの組み合わせ

このグラフには次の情報が表示されます。

• グラフの先頭では、VM をホストするインフラストラクチャは使用できず、0% でした。 その後、インフラストラクチャは正常で、VM に到達可能になり、複数の VM がバックエンドに配置されていました。 データパスの利用可能性を示す青いトレースは、後に100%に更新され、この情報を示しています。

• 紫色のトレースで示されている正常性プローブの状態は、グラフの先頭では 0% です。 緑色の円で囲んだ領域は正常性プローブ状態が正常になった場所を示し、この時点で、ユーザーのデプロイは新しいフローを受け付けることができるようになりました。

このチャートは、他の問題が起きているかどうかを推測したりサポートに尋ねたりすることなく、デプロイメントのトラブルシューティングに役立ちます。 このサービスは、誤った構成またはアプリケーションの障害によって正常性プローブが失敗したため、利用できませんでした。