メトリック、アラート、およびリソース正常性を使用した Standard Load Balancer の診断Standard Load Balancer diagnostics with metrics, alerts and resource health

Azure Standard Load Balancer では、次の診断機能が公開されています。Azure Standard Load Balancer exposes the following diagnostic capabilities:

  • 多次元メトリックおよびアラート: Standard Load Balancer 構成用に、Azure Monitor を介して多次元診断機能が提供されています。Multi-dimensional metrics and alerts: Provides multi-dimensional diagnostic capabilities through Azure Monitor for standard load balancer configurations. ご利用の Standard Load Balancer リソースの監視、管理、トラブルシューティングを行うことができます。You can monitor, manage, and troubleshoot your standard load balancer resources.

  • [リソース正常性] :Load Balancer の Resource Health の状態は、[監視] にある [Resource Health] ページで確認できます。Resource health: The Resource Health status of your Load Balancer is available in the Resource Health page under Monitor. この自動チェックによって、Load Balancer リソースの現在の可用性が通知されます。This automatic check informs you of the current availability of your Load Balancer resource. この記事では、これらの機能の概要、および Standard Load Balancer でこれらの機能を使う方法について説明します。This article provides a quick tour of these capabilities, and it offers ways to use them for Standard Load Balancer.

多次元メトリックMulti-dimensional metrics

Azure Load Balancer では Azure portal の Azure メトリックを介して多次元メトリックが提供されており、Load Balancer リソースにリアルタイム診断分析情報を取り込むために役立ちます。Azure Load Balancer provides multi-dimensional metrics via the Azure Metrics in the Azure portal, and it helps you get real-time diagnostic insights into your load balancer resources.

Standard Load Balancer をさまざまに構成することで、次のメトリックを取得できます。The various Standard Load Balancer configurations provide the following metrics:

メトリックMetric リソースの種類Resource type 説明Description 推奨される集計Recommended aggregation
データ パスの可用性Data path availability パブリックおよび内部ロード バランサーPublic and internal load balancer Standard Load Balancer は、リージョン内からロード バランサー フロントエンドを経て、VM をサポートする SDN スタックに至るまでのデータ パスを継続的に学習します。Standard Load Balancer continuously exercises the data path from within a region to the load balancer front end, all the way to the SDN stack that supports your VM. 正常なインスタンスが保持されていれば、測定ではアプリケーションの負荷分散されたトラフィックと同じパスに従います。As long as healthy instances remain, the measurement follows the same path as your application's load-balanced traffic. 顧客が使用しているデータ パスも検証されます。The data path that your customers use is also validated. 測定はアプリケーションには見えないので、他の操作と干渉することはありません。The measurement is invisible to your application and does not interfere with other operations. AverageAverage
正常性プローブの状態Health probe status パブリックおよび内部ロード バランサーPublic and internal load balancer Standard Load Balancer では、構成設定に従ってアプリケーション エンドポイントの正常性を監視する、分散型の正常性プローブ サービスが使われます。Standard Load Balancer uses a distributed health-probing service that monitors your application endpoint's health according to your configuration settings. このメトリックは、ロード バランサー プールのインスタンス エンドポイントの集計ビューまたはエンドポイントごとのフィルター ビューを提供します。This metric provides an aggregate or per-endpoint filtered view of each instance endpoint in the load balancer pool. 正常性プローブ構成で示されているアプリケーションの正常性を、Load Balancer がどのように表示するのかを確認できます。You can see how Load Balancer views the health of your application, as indicated by your health probe configuration. AverageAverage
SYN (同期) 数SYN (synchronize) count パブリックおよび内部ロード バランサーPublic and internal load balancer Standard Load Balancer は、伝送制御プロトコル (TCP) 接続を終了したり、TCP または UDP のパケット フローと対話したりすることはありません。Standard Load Balancer does not terminate Transmission Control Protocol (TCP) connections or interact with TCP or UDP packet flows. フローとハンドシェイクは、常にソースと VM インスタンスの間で発生します。Flows and their handshakes are always between the source and the VM instance. TCP プロトコルのシナリオのトラブルシューティングを適切に行うために、SYN パケット カウンターを使用して TCP 接続試行の数を把握できます。To better troubleshoot your TCP protocol scenarios, you can make use of SYN packets counters to understand how many TCP connection attempts are made. このメトリックは、受信済みの TCP SYN パケットの数を報告します。The metric reports the number of TCP SYN packets that were received. SUMSum
SNAT 接続数SNAT connection count パブリック ロード バランサーPublic load balancer Standard Load Balancer は、パブリック IP アドレス フロントエンドにマスカレードされた送信フローの数を報告します。Standard Load Balancer reports the number of outbound flows that are masqueraded to the Public IP address front end. 送信元ネットワーク アドレス変換 (SNAT) ポートは、有限のリソースです。Source network address translation (SNAT) ports are an exhaustible resource. このメトリックはアプリケーションが送信フローで SNAT にどれくらい依存しているかを示すことができます。This metric can give an indication of how heavily your application is relying on SNAT for outbound originated flows. 成功した送信 SNAT フローと失敗した送信 SNAT フローのカウンターがレポートされるので、送信フローの正常性について、トラブルシューティングしたり、理解したりするのに役立てることができます。Counters for successful and failed outbound SNAT flows are reported and can be used to troubleshoot and understand the health of your outbound flows. SUMSum
割り当てられる SNAT ポートAllocated SNAT ports パブリック ロード バランサーPublic load balancer Standard Load Balancer からは、バックエンド インスタンスごとに割り当てられる SNAT ポートの数が報告されますStandard Load Balancer reports the number of SNAT ports allocated per backend instance AverageAverage.
使用された SNAT ポートUsed SNAT ports パブリック ロード バランサーPublic load balancer Standard Load Balancer からは、バックエンド インスタンスごとに活用されている SNAT ポートの数が報告されますStandard Load Balancer reports the number of SNAT ports that are utilized per backend instance. AverageAverage
バイト数Byte count パブリックおよび内部ロード バランサーPublic and internal load balancer Standard Load Balancer は、フロントエンドごとに処理されたデータ量を報告します。Standard Load Balancer reports the data processed per front end. バックエンド インスタンス間でバイト数が均等に配布されていないことがわかります。You may notice that the bytes are not distributed equally across the backend instances. Azure の Load Balancer アルゴリズムはフローに基づいているため、これは予期されていることです。This is expected as Azure's Load Balancer algorithm is based on flows SUMSum
パケット数Packet count パブリックおよび内部ロード バランサーPublic and internal load balancer Standard Load Balancer は、フロントエンドごとに処理されたパケット数を報告します。Standard Load Balancer reports the packets processed per front end. SUMSum

注意

NVA またはファイアウォールを介して内部ロード バランサーからトラフィックの分散を使用する場合、SYN パケット、バイト数、パケット数の各メトリックは使用できず、0 として表示されます。When using distributing traffic from an internal load balancer through an NVA or firewall Syn Packet, Byte Count, and Packet Count metrics are not be available and will show as zero.

注意

SYN 数、パケット数、SNAT 接続数、バイト数のメトリックでは、最大値と最小値を集計できませんMax and min aggregations are not available for the SYN count, packet count, SNAT connection count, and byte count metrics

Azure Portal でロード バランサーのメトリックを表示するView your load balancer metrics in the Azure portal

Azure Portal の [メトリック] ページでは、ロード バランサーのメトリックが公開されます。このページは、特定のリソースのロード バランサー リソース ページと、Azure Monitor のページの両方から表示できます。The Azure portal exposes the load balancer metrics via the Metrics page, which is available on both the load balancer resource page for a particular resource and the Azure Monitor page.

Standard Load Balancer リソースのメトリックを表示するには:To view the metrics for your Standard Load Balancer resources:

  1. [メトリック] ページに移動し、次のいずれかを実行します。Go to the Metrics page and do either of the following:
    • ロード バランサー リソース ページで、ドロップダウン リストからメトリックの種類を選択します。On the load balancer resource page, select the metric type in the drop-down list.
    • Azure Monitor のページで、ロード バランサー リソースを選択します。On the Azure Monitor page, select the load balancer resource.
  2. 適切なメトリック集計の種類を設定します。Set the appropriate metric aggregation type.
  3. 必要に応じて、フィルター処理およびグループ化を構成します。Optionally, configure the required filtering and grouping.
  4. 必要に応じて、時間の範囲と集計を構成します。Optionally, configure the time range and aggregation. 既定では、時刻は UTC で表示されます。By default time is displayed in UTC.

注意

データは 1 分間に 1 回サンプリングされるため、時間の集計は、特定のメトリックを解釈する場合に重要になります。Time aggregation is important when interpreting certain metrics as data is sampled once per minute. 時間の集計が 5 分に設定されていて、メトリック集計の種類である合計 (Sum) が SNAT 割り当てなどのメトリックに使用されている場合、グラフには、割り当て済みの SNAT ポートの合計数が 5 回表示されます。If time aggregation is set to five minutes and metric aggregation type Sum is used for metrics such as SNAT Allocation, your graph will display five times the total allocated SNAT ports.

Standard Load Balancer のメトリック

図:Standard Load Balancer のデータ パスの可用性メトリックFigure: Data Path Availability metric for Standard Load Balancer

API を使用してプログラムで多次元メトリックを取得するRetrieve multi-dimensional metrics programmatically via APIs

多次元メトリックの定義と値を取得するための API のガイダンスについては、「Azure 監視 REST API のチュートリアル」をご覧ください。For API guidance for retrieving multi-dimensional metric definitions and values, see Azure Monitoring REST API walkthrough. これらのメトリックは、"すべてのメトリック" カテゴリに診断設定を追加することでストレージ アカウントに書き込むことができます。These metrics can be written to a storage account by adding a Diagnostic Setting for the 'All Metrics' category.

データ パスが稼働していて Load Balancer Frontend に使用可能か?Is the data path up and available for my Load Balancer Frontend?

expandExpand

データ パスの可用性メトリックでは、VM が存在するコンピューティング ホストまでの、リージョン内のデータ パスの正常性が示されます。The data path availability metric describes the health of the data path within the region to the compute host where your VMs are located. このメトリックは、Azure インフラストラクチャの正常性を反映します。The metric is a reflection of the health of the Azure infrastructure. このメトリックは次の目的に使うことができます。You can use the metric to:

  • サービスの外部可用性を監視しますMonitor the external availability of your service
  • サービスが展開されているプラットフォームが正常かどうか、またはゲスト OS やアプリケーション インスタンスが正常かどうかを、詳しく調べて把握します。Dig deeper and understand whether the platform on which your service is deployed is healthy or whether your guest OS or application instance is healthy.
  • イベントがサービスと基盤のデータ プレーンのどちらに関係するかを切り分けます。Isolate whether an event is related to your service or the underlying data plane. このメトリックを正常性プローブの状態 ("バックエンド インスタンスの可用性") と間違えないでください。Do not confuse this metric with the health probe status ("Backend Instance availability").

Standard Load Balancer リソースのデータ パスの可用性を取得するには:To get the Data Path Availability for your Standard Load Balancer resources:

  1. 正しいロード バランサー リソースが選ばれていることを確認します。Make sure the correct load balancer resource is selected.
  2. [メトリック] ドロップダウン リストで [Data Path Availability](データ パスの可用性) を選択します。In the Metric drop-down list, select Data Path Availability.
  3. [集計] ドロップダウン リストで [平均] を選択します。In the Aggregation drop-down list, select Avg.
  4. さらに、必要なフロントエンド IP アドレスまたはフロントエンド ポートのディメンションとしてフロントエンド IP アドレスまたはフロントエンド ポートに対するフィルターを追加し、選んだディメンションでグループ化します。Additionally, add a filter on the Frontend IP address or Frontend port as the dimension with the required front-end IP address or front-end port, and then group them by the selected dimension.

VIP のプローブ

図:Load Balancer フロントエンド プローブの詳細Figure: Load Balancer Frontend probing details

アクティブな帯域内測定によってメトリックが生成されます。The metric is generated by an active, in-band measurement. リージョン内のプローブ サービスから測定のためのトラフィックが発生します。A probing service within the region originates traffic for the measurement. このサービスは、パブリック フロント エンドでデプロイが作成されるとすぐにアクティブになり、パブリック フロント エンドが削除されるまで継続します。The service is activated as soon as you create a deployment with a public front end, and it continues until you remove the front end.

デプロイのフロントエンドとルールに一致するパケットが、定期的に生成されます。A packet matching your deployment's front end and rule is generated periodically. パケットは、ソースから、バックエンド プール内の VM が配置されているホストまで、リージョンを移動します。It traverses the region from the source to the host where a VM in the back-end pool is located. ロード バランサー インフラストラクチャは、他のすべてのトラフィックの場合と同じ負荷分散操作と変換操作を実行します。The load balancer infrastructure performs the same load balancing and translation operations as it does for all other traffic. このプローブは負荷分散されるエンドポイントの帯域内です。This probe is in-band on your load-balanced endpoint. バックエンド プール内の正常な VM が存在するコンピューティング ホストにプローブが到達した後に、コンピューティング ホストはプローブ サービスへの応答を生成します。After the probe arrives on the compute host, where a healthy VM in the back-end pool is located, the compute host generates a response to the probing service. VM はこのトラフィックを認識しません。Your VM does not see this traffic.

データ パスの可用性は次の理由で失敗します。Datapath availability fails for the following reasons:

  • デプロイのバックエンド プールに正常な VM が残っていない。Your deployment has no healthy VMs remaining in the back-end pool.
  • インフラストラクチャ障害が発生した。An infrastructure outage has occurred.

診断の目的で、データ パスの可用性メトリックと共に正常性プローブの状態を使うことができます。For diagnostic purposes, you can use the Data Path Availability metric together with the health probe status.

ほとんどのシナリオでは集計として 平均 を使います。Use Average as the aggregation for most scenarios.

Load Balancer のバックエンド インスタンスはプローブに応答しているか?Are the Backend Instances for my Load Balancer responding to probes?

expandExpand 正常性プローブ状態メトリックでは、ユーザーがロード バランサーの正常性プローブを構成するときにユーザーによって構成されたアプリケーションのデプロイの正常性が示されます。The health probe status metric describes the health of your application deployment as configured by you when you configure the health probe of your load balancer. ロード バランサーは、正常性プローブの状態を使って、新しいフローの送信先を決めます。The load balancer uses the status of the health probe to determine where to send new flows. 正常性プローブは、Azure インフラストラクチャのアドレスから送信され、VM のゲスト OS 内で認識されます。Health probes originate from an Azure infrastructure address and are visible within the guest OS of the VM.

Standard Load Balancer リソースの正常性プローブの状態を取得するには:To get the health probe status for your Standard Load Balancer resources:

  1. [正常性プローブの状態] メトリックと、集計の種類として [平均] を選択します。Select the Health Probe Status metric with Avg aggregation type.
  2. 必要なフロントエンドの IP アドレスまたはポート (またはその両方) にフィルターを適用します。Apply a filter on the required Frontend IP address or port (or both).

正常性プローブは次の理由で失敗します。Health probes fail for the following reasons:

  • リッスンしていないポート、応答していないポート、または正しくないプロトコルを使用しているポートに対して、正常性プローブを構成している。You configure a health probe to a port that is not listening or not responding or is using the wrong protocol. サービスが Direct Server Return (DSR、またはフローティング IP) ルールを使っている場合は、サービスが、フロントエンド IP アドレスで構成されたループバックだけでなく、NIC の IP 構成の IP アドレスでリッスンしていることを確認します。If your service is using direct server return (DSR, or floating IP) rules, make sure that the service is listening on the IP address of the NIC's IP configuration and not just on the loopback that's configured with the front-end IP address.
  • プローブが、ネットワーク セキュリティ グループ、VM のゲスト OS のファイアウォール、またはアプリケーション レイヤーのフィルターによって許可されていない。Your probe is not permitted by the Network Security Group, the VM's guest OS firewall, or the application layer filters.

ほとんどのシナリオでは集計として 平均 を使います。Use Average as the aggregation for most scenarios.

送信接続の統計情報を確認する方法How do I check my outbound connection statistics?

expandExpand SNAT 接続メトリックは、([送信フロー](./load-balancer-outbound-connections.md)の) 接続の成功と失敗の量を示します。The SNAT connections metric describes the volume of successful and failed connections for [outbound flows](./load-balancer-outbound-connections.md).

失敗した接続の量が 0 より大きい場合は、SNAT ポートが不足していることを示します。A failed connections volume of greater than zero indicates SNAT port exhaustion. さらに詳しく調査し、このようなエラーの原因を特定する必要があります。You must investigate further to determine what may be causing these failures. SNAT ポートの不足は、送信フロー確立の失敗として示されます。SNAT port exhaustion manifests as a failure to establish an outbound flow. シナリオおよび動作メカニズムを理解し、SNAT ポートの不足を軽減する方法または回避する設計の方法を学習するには、送信接続に関する記事をご覧ください。Review the article about outbound connections to understand the scenarios and mechanisms at work, and to learn how to mitigate and design to avoid SNAT port exhaustion.

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

  1. トリックの種類として [SNAT Connections](SNAT 接続) を、集計として [合計] を選択します。Select SNAT Connections metric type and Sum as aggregation.
  2. SNAT 接続の成功と失敗のカウントを異なる行に表示するには、 [接続の状態] でグループ化します。Group by Connection State for successful and failed SNAT connection counts to be represented by different lines.

SNAT 接続

図:Load Balancer の SNAT 接続の数

*Figure: Load Balancer SNAT connection count*

SNAT ポートの使用状況と割り当てを確認する方法How do I check my SNAT port usage and allocation?

expandExpand [使用された SNAT ポート] メトリックでは、送信フローを保持するために使用されている SNAT ポートの数が追跡されます。The Used SNAT Ports metric tracks how many SNAT ports are being consumed to maintain outbound flows. これは、インターネット ソースと、ロード バランサーの背後にあり、パブリック IP アドレスを持たないバックエンド VM または仮想マシン スケール セットの間で確立された一意のフローの数を示します。This indicates how many unique flows are established between an internet source and a backend VM or virtual machine scale set that is behind a load balancer and does not have a public IP address. 使用している SNAT の数と割り当てられた SNAT ポート メトリックを比較すると、サービスで SNAT 不足が発生しているか、またはそのリスクがあるか、および結果の送信フローで障害が発生しているかどうかを判断できます。By comparing the number of SNAT ports you are using with the Allocated SNAT Ports metric, you can determine if your service is experiencing or at risk of SNAT exhaustion and resulting outbound flow failure.

メトリックが送信フロー障害のリスクを示している場合は、サービスの正常性を確保するために、こちらの記事を参照し、この問題を軽減するための手順を実行してください。If your metrics indicate risk of outbound flow failure, reference the article and take steps to mitigate this to ensure service health.

SNAT ポートの使用状況と割り当てを確認するには:To view SNAT port usage and allocation:

  1. グラフの時間の集計を 1 分に設定して、目的のデータが表示されるようにします。Set the time aggregation of the graph to 1 minute to ensure desired data is displayed.
  2. メトリックの種類として [使用された SNAT ポート] および/または [割り当てられた SNAT ポート] を選択し、集計として [平均] を選択します。Select Used SNAT Ports and/or Allocated SNAT Ports as the metric type and Average as the aggregation
    • 既定では、これらのメトリックは、各バックエンド VM または VMSS に割り当てられた、またはこれらが使用している SNAT ポートの平均数です。これは、ロード バランサーにマップされたすべてのフロントエンド パブリック IP に対応し、TCP と UDP で集計されます。By default these metrics are the average number of SNAT ports allocated to or used by each backend VM or VMSS, corresponding to all frontend public IPs mapped to the Load Balancer, aggregated over TCP and UDP.
    • ロード バランサーが使用している、またはロード バランサーに割り当てられた SNAT ポートの合計数を確認するには、メトリック集計の [Sum](合計) を使用します。To view total SNAT ports used by or allocated for the load balancer use metric aggregation Sum
  3. フィルター処理によって、特定の プロトコルの種類、一連の バックエンド IP、および/または フロントエンド IP に絞り込みます。Filter to a specific Protocol Type, a set of Backend IPs, and/or Frontend IPs.
  4. バックエンドまたはフロントエンド インスタンスごとに正常性を監視するには、分割を適用します。To monitor health per backend or frontend instance, apply splitting.
    • 分割では、一度に 1 つのメトリックしか表示できないので注意してください。Note splitting only allows for a single metric to be displayed at a time.
  5. たとえば、コンピューターごとに TCP フローの SNAT 使用状況を監視するには、 [平均] で集計し、 [Backend IPs](バックエンド IP) で分割し、 [プロトコルの種類] でフィルター処理します。For example, to monitor SNAT usage for TCP flows per machine, aggregate by Average, split by Backend IPs and filter by Protocol Type.

SNAT の割り当てと使用状況

図:一連のバックエンド VM の平均 TCP SNAT ポート割り当てと使用状況Figure: Average TCP SNAT port allocation and usage for a set of backend VMs

バックエンド インスタンスによる SNAT 使用

図:バックエンド インスタンスごとの TCP SNAT ポートの使用状況

*Figure: TCP SNAT port usage per backend instance*

サービスに対する受信/送信接続の試行を確認する方法How do I check inbound/outbound connection attempts for my service?

expandExpand SYN パケット メトリックは、特定のフロントエンドに関連付けられている、到着した TCP SYN パケットまたは送信された TCP SYN パケット ([送信フロー](./load-balancer-outbound-connections.md)の場合) の量を示します。A SYN packets metric describes the volume of TCP SYN packets, which have arrived or were sent (for [outbound flows](./load-balancer-outbound-connections.md)) that are associated with a specific front end. このメトリックを使用して、サービスへの TCP 接続の試行を把握できます。You can use this metric to understand TCP connection attempts to your service.

ほとんどのシナリオでは、集計として Sum を使用します。Use Sum as the aggregation for most scenarios.

SYN 接続

図:Load Balancer の SYN の数

*Figure: Load Balancer SYN count*

ネットワーク帯域幅の消費量を確認する方法How do I check my network bandwidth consumption?

expandExpand バイト カウンターおよびパケット カウンターのメトリックは、フロントエンドごとにサービスによって送信または受信されたバイトおよびパケットの量を示します。The bytes and packet counters metric describes the volume of bytes and packets that are sent or received by your service on a per-front-end basis.

ほとんどのシナリオでは、集計として Sum を使用します。Use Sum as the aggregation for most scenarios.

バイト数またはパケット数の統計情報を取得するには:To get byte or packet count statistics:

  1. メトリックの種類として [Bytes Count](バイト数) および [Packet Count](パケット数) 、またはその両方を、集計として [Sum] を選択します。Select the Bytes Count and/or Packet Count metric type, with Sum as the aggregation.
  2. 以下のいずれかを実行します。Do either of the following:
    • 特定のフロントエンド IP、フロントエンド ポート、バックエンド IP、またはバックエンド ポートにフィルターを適用します。Apply a filter on a specific front-end IP, front-end port, back-end IP, or back-end port.
    • フィルターを適用せずにロード バランサー リソースの全体的な統計情報を取得します。Get overall statistics for your load balancer resource without any filtering.

バイト数

図:Load Balancer のバイト数

*Figure: Load Balancer byte count*

ロード バランサーのデプロイを診断する方法How do I diagnose my load balancer deployment?

expandExpand データ パスの可用性メトリックと正常性プローブの状態メトリックを 1 つのグラフに組み合わせて使用すると、問題を探して解決する必要がある場所を特定することができます。By using a combination of the Data Path Availability and Health Probe Status metrics on a single chart you can identify where to look for the problem and resolve the problem. Azure が正常に動作している保証が得られ、この情報を利用して、構成またはアプリケーションが根本原因であることを確定できます。You can gain assurance that Azure is working correctly and use this knowledge to conclusively determine that the configuration or application is the root cause.

正常性プローブ メトリックを使うと、ユーザーが指定した構成に従って、Azure が展開の正常性を表示する方法を理解できます。You can use health probe metrics to understand how Azure views the health of your deployment as per the configuration you have provided. 正常性プローブを確認することは、常に、原因を監視または特定するのに適した第一歩です。Looking at health probes is always a great first step in monitoring or determining a cause.

その後さらに、データ パスの可用性メトリックを使って、特定のデプロイに関与する基盤データ プレーンの正常性を Azure が表示する方法についての分析情報を得ることができます。You can take it a step further and use Data Path availability metric to gain insight into how Azure views the health of the underlying data plane that's responsible for your specific deployment. 次の例に示すように、両方のメトリックを組み合わせると、障害の可能性がある場所を分離できます。When you combine both metrics, you can isolate where the fault might be, as illustrated in this example:

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

図:データ パスの可用性メトリックと正常性プローブの状態メトリックの組み合わせFigure: Combining Data Path Availability and Health Probe Status metrics

このグラフには次の情報が表示されます。The chart displays the following information:

  • グラフの先頭では、VM をホストするインフラストラクチャは使用できず、0% でした。The infrastructure hosting your VMs was unavailable and at 0 percent at the beginning of the chart. その後、インフラストラクチャは正常で、VM に到達可能になり、複数の VM がバックエンドに配置されていました。Later, the infrastructure was healthy and the VMs were reachable, and more than one VM was placed in the back end. この情報は、データ パスの可用性を表す青いトレースによって示され、後で 100% になっています。This information is indicated by the blue trace for data path availability, which was later at 100 percent.
  • 紫色のトレースで示されている正常性プローブの状態は、グラフの先頭では 0% です。The health probe status, indicated by the purple trace, is at 0 percent at the beginning of the chart. 緑色の円で囲んだ領域は正常性プローブ状態が正常になった場所を示し、この時点で、ユーザーのデプロイは新しいフローを受け付けることができるようになりました。The circled area in green highlights where the health probe status became healthy, and at which point the customer's deployment was able to accept new flows.

このグラフを見ることで、ユーザーは、他の問題が発生していたかどうかを推測したりサポートに問い合わせたりすることなく、独力でデプロイのトラブルシューティングを行うことができます。The chart allows customers to troubleshoot the deployment on their own without having to guess or ask support whether other issues are occurring. このサービスは、誤った構成またはアプリケーションの障害によって正常性プローブが失敗したため、利用できませんでした。The service was unavailable because health probes were failing due to either a misconfiguration or a failed application.

多次元メトリックのアラートを構成するConfigure alerts for multi-dimensional metrics

Azure Standard Load Balancer では、多次元メトリックの簡単に構成できるアラートがサポートされています。Azure Standard Load Balancer supports easily configurable alerts for multi-dimensional metrics. タッチレスのリソース監視エクスペリエンスを強化するには、特定のメトリックのカスタムしきい値を、さまざまなレベルの重大度でアラートをトリガーするように構成します。Configure custom thresholds for specific metrics to trigger alerts with varying levels of severity to empower a touchless resource monitoring experience.

アラートを構成するには、以下の手順に従います。To configure alerts:

  1. ロード バランサーのアラート サブブレードに移動します。Go to the alert sub-blade for the load balancer
  2. 新しいアラート ルールの作成Create new alert rule
    1. アラートの条件を構成します。Configure alert condition
    2. (省略可能) 自動修復のアクション グループを追加します。(Optional) Add action group for automated repair
    3. アラートの重大度、名前、直感的な反応を可能にする説明を割り当てます。Assign alert severity, name and description that enables intuitive reaction

受信可用性のアラートInbound availability alerting

受信の可用性についてアラートを生成する場合は、データ パスの可用性と正常性プローブの状態メトリックを使用して、2 つの異なるアラートを作成できます。To alert for inbound availability, you can create two separate alerts using the data path availability and health probe status metrics. 必要となるアラート ロジックはお客様のシナリオによって変わってきますが、ほとんどの構成では、次の例が役立ちます。Customers may have different scenarios that require specific alerting logic, but the below examples will be helpful for most configurations.

データ パスの可用性を使用すると、特定の負荷分散規則が使用できなくなったときにアラートを発生させることができます。Using data path availability, you can fire alerts whenever a specific load balancing rule becomes unavailable. このアラートを構成するには、データ パスの可用性に関するアラート条件を設定し、フロントエンド ポートとフロントエンド IP アドレスの両方について、すべての現在値と将来値で分割します。You can configure this alert by setting an alert condition for the data path availability and splitting by all current values and future values for both Frontend Port and Frontend IP Address. アラート ロジックを 0 以下に設定すると、いずれかの負荷分散規則が応答しなくなったときに、毎回このアラートが発生します。Setting the alert logic to be less than or equal to 0 will cause this alert to be fired whenever any load balancing rule becomes unresponsive. どのような評価が望ましいかに応じて、集計の粒度と評価の頻度を設定してください。Set the aggregation granularity and frequency of evaluation according to your desired evaluation.

正常性プローブの状態を使用すると、特定のバックエンド インスタンスが正常性プローブに長時間応答しない場合に、アラートを表示できます。With health probe status you can alert when a given backend instance fails to respond to the health probe for a significant amount of time. 正常性プローブの状態メトリックを使用し、バックエンド IP アドレスとバックエンド ポートで分割するようにアラート条件を設定してください。Set up your alert condition to use the health probe status metric and split by Backend IP Address and Backend Port. これにより、個々のバックエンド インスタンスが特定のポートでトラフィックを処理できるかどうかについて、個別にアラートを送信できるようになります。This will ensure that you can alert separately for each individual backend instance’s ability to serve traffic on a specific port. 集計の種類として 平均 を使用し、バックエンド インスタンスのプローブ頻度と、どれくらいのしきい値が健全かを考慮したうえで、しきい値を設定してください。Use the Average aggregation type and set the threshold value according to how frequently your backend instance is probed and what you consider to be your healthy threshold.

ディメンションによる分割を行わず、集計の種類として 平均 を使用して、バックエンド プール レベルでアラートを作成することもできます。You can also alert on a backend pool level by not splitting by any dimensions and using the Average aggregation type. これにより、バックエンド プール メンバーの 50% が異常な場合にアラートを発するなどといったアラート ルールを設定できます。This will allow you to set up alert rules such as alert when 50% of my backend pool members are unhealthy.

送信可用性のアラートOutbound availability alerting

送信の可用性についてアラートを構成する場合は、"SNAT 接続数" メトリックと "使用中の SNAT ポート" メトリックを使用して、2 つの異なるアラートを構成できます。To configure for outbound availability, you can configure two separate alerts using the SNAT Connection Count and Used SNAT Port metrics.

送信接続エラーを検出するには、SNAT 接続数を使用し、接続状態を Failed でフィルター処理してアラートを構成します。To detect outbound connection failures, configure an alert using SNAT Connection Count and filtering to Connection State = Failed. 集計は 合計 を使用します。Use the Total aggregation. また、すべての現在値と将来値に設定されたバックエンド IP アドレスでこれを分割することにより、接続エラーが発生しているバックエンド インスタンスごとに、個別のアラートを生成することもできます。You can then also split this by Backend IP Address set to all current and future values to alert separately for each backend instance experiencing failed connections. 送信接続エラーの発生が予想される場合は、しきい値を 0 以上の数値に設定してください。Set the threshold to be greater than zero or a higher number if you expect to see some outbound connection failures.

"使用中の SNAT ポート" を使用すると、SNAT の枯渇や送信接続エラーのリスクが高いことを示すアラートを生成できます。Through Used SNAT Ports you can alert on a higher risk of SNAT exhaustion and outbound connection failure. このアラートを使用する場合は、バックエンド IP アドレスとプロトコルによって分割をし、集計には 平均 を使用するようにしてください。Ensure you are splitting by Backend IP address and Protocol when using this alert and use the Average aggregation. しきい値は、インスタンスごとの割り当て済みポート数に対する割合として、安全でないと思われる水準よりも大きい値に設定します。Set the threshold to be greater than a percentage(s) of the number of ports you have allocated per instance that you deem unsafe. たとえば、バックエンド インスタンスで割り当て済みポートの 75% が使用されている場合には重大度の低いアラートを生成し、90% 以上が使用されている場合には重大度の高いアラートを発するといった構成が可能です。For example, you may configure a low severity alert when a backend instance uses 75% of its allocated ports and a high severity when it uses 90% or 100% of its allocated ports.

リソースの正常性状態Resource health status

Standard Load Balancer リソースの正常性状態は、 [Monitor](監視) > [サービスの正常性] の既存の [リソース正常性] によって表示されます。Health status for the Standard Load Balancer resources is exposed via the existing Resource health under Monitor > Service Health. フロントエンドの負荷分散エンドポイントが利用できるかどうかを判断するデータ パス可用性を見ることで 2 分 おきに評価されます。It is evaluated every two minutes by measuring Data Path Availability which determines whether your Frontend Load Balancing endpoints are available.

リソースの正常性状態Resource health status 説明Description
利用可能Available ご利用の Standard Load Balancer リソースは正常であり、使用可能です。Your standard load balancer resource is healthy and available.
低下していますDegraded Standard Load Balancer のプラットフォームやユーザーが開始したイベントのパフォーマンスが影響を受けます。Your standard load balancer has platform or user initiated events impacting performance. [データパスの可用性] メトリックでは、少なくとも 2 分間に 90% を下回るが、25% を上回る正常性が報告されました。The Datapath Availability metric has reported less than 90% but greater than 25% health for at least two minutes. パフォーマンスは、中から重大までの影響を受けます。You will experience moderate to severe performance impact. ユーザーが開始したイベントによって可用性が影響を受けるかどうかをトラブルシューティング RHC ガイドに従って確認します。Follow the troubleshooting RHC guide to determine whether there are user initiated events causing impacting your availability.
使用不可Unavailable ご利用の Standard Load Balancer リソースは正常ではありません。Your standard load balancer resource is not healthy. [データパスの可用性] メトリックでは、少なくとも 2 分間に 25% を下回る正常性が報告されました。The Datapath Availability metric has reported less the 25% health for at least two minutes. パフォーマンスが大きな影響を受けたり、受信接続の可用性が不足したりします。You will experience significant performance impact or lack of availability for inbound connectivity. ユーザーまたはプラットフォーム イベントによって可用性が失われる可能性もあります。There may be user or platform events causing unavailability. ユーザーが開始したイベントによって可用性が影響を受けるかどうかをトラブルシューティング RHC ガイドに従って確認します。Follow the troubleshooting RHC guide to determine whether there are user initiated events impacting your availability.
UnknownUnknown Standard Load Balancer リソースのリソース正常性状態がまだ更新されていないか、過去 10 分間にデータパスの可用性情報が受信されていません。Resource health status for your standard load balancer resource has not been updated yet or has not received Data Path availability information for the last 10 minutes. これは一時的な状態であり、データが受信されれば、すぐに正しい状態が反映されます。This state should be transient and will reflect correct status as soon as data is received.

パブリック Standard Load Balancer リソースの正常性を表示するには:To view the health of your public Standard Load Balancer resources:

  1. [Monitor](監視) > [サービス正常性] の順に選択します。Select Monitor > Service Health.

    [Monitor](監視) ページ

    図:Azure Monitor のサービス正常性のリンクFigure: The Service Health link on Azure Monitor

  2. [リソース正常性] を選び、 [サブスクリプション ID] が選ばれていることと [リソースの種類] = [ロード バランサー] に設定されていることを確認します。Select Resource Health, and then make sure that Subscription ID and Resource Type = Load Balancer are selected.

    リソースの正常性状態

    図:正常性ビューを表示するリソースの選択Figure: Select resource for health view

  3. 一覧で、正常性状態の履歴を表示するロード バランサー リソースを選択します。In the list, select the Load Balancer resource to view its historical health status.

    Load Balancer の正常性状態

    図:Load Balancer リソースの正常性ビューFigure: Load Balancer resource health view

一般的なリソースの正常性状態については、RHC のドキュメントを参照してください。Generic resource health status description are available in the RHC documentation. Azure Load Balancer の特定の状態については、次の表を参照してください。For specific statuses for the Azure Load Balancer are listed in the below table:

次のステップNext steps