翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

# Envoy メトリクスを使用したアプリケーションの監視
<a name="envoy-metrics"></a>

**重要**  
サポート終了通知: 2026 年 9 月 30 日、 AWS はサポートを終了します AWS App Mesh。2026 年 9 月 30 日以降、 AWS App Mesh コンソールまたは AWS App Mesh リソースにアクセスできなくなります。詳細については、このブログ記事[「 から Amazon ECS Service Connect AWS App Mesh への移行](https://aws.amazon.com/blogs/containers/migrating-from-aws-app-mesh-to-amazon-ecs-service-connect)」を参照してください。

Envoy は、メトリクスを次の主要なカテゴリに分類します。
+ **ダウンストリーム** — プロキシに入ってくる接続とリクエストに関連するメトリクスです。
+ **アップストリーム** — プロキシによって行われた送信接続とリクエストに関連するメトリクスです。
+ **サーバー** — Envoy の内部状態を説明するメトリクスです。これには、稼働時間や割り当てられたメモリなどのメトリクスが含まれます。

App Mesh では、プロキシがアップストリームとダウンストリームトラフィックをインターセプトします。例えば、クライアントから受信したリクエストと、サービスコンテナによって行われたリクエストは、Envoy によってダウンストリームトラフィックとして分類されます。これらの異なるタイプのアップストリームトラフィックとダウンストリームトラフィックを区別するために、App Mesh は、サービスに関連するトラフィックの方向に応じて、Envoy メトリクスをさらに分類します。
+ **Ingress** — サービスコンテナにフローする接続とリクエストに関連するメトリクスとリソースです。
+ **Egress** — サービスコンテナから、最終的に Amazon ECS タスクまたは Kubernetes ポッドからフローする接続とリクエストに関するメトリクスとリソースです。

次の図は、プロキシコンテナとサービスコンテナ間の通信を示しています。

![プロキシコンテナは、入出力トラフィックを受信し、サービスコンテナと通信します。](https://docs.aws.amazon.com/ja_jp/app-mesh/latest/userguide/images/task-proxy-container.png)


**リソース命名規則**

Envoy がメッシュをどのように表示し、そのリソースが App Mesh で定義したリソースにどのようにマップされるかを理解しておくと便利です。App Mesh が設定する主要な Envoy リソースは次のとおりです。
+ **リスナー** - プロキシがダウンストリーム接続をリッスンするアドレスとポートです。前の図では、App Mesh は Amazon ECS タスクまたは Kubernetes ポッドに入るトラフィックの入力リスナーと、サービスコンテナから出るトラフィックの出力リスナーを作成します。
+ **クラスター** - プロキシが接続してトラフィックをルーティングするアップストリームエンドポイントの名前付きグループです。App Mesh では、サービスコンテナは、サービスが接続できる他のすべての仮想ノードと同様に、クラスターとして表されます。
+ **ルート** - これらは、メッシュで定義するルートに対応します。これには、プロキシがリクエストと一致する条件と、リクエストが送信されるターゲットクラスターが含まれます。
+ **エンドポイントとクラスターの負荷割り当て** - アップストリームクラスタの IP アドレスです。仮想ノードのサービス検出メカニズムとして AWS Cloud Map を使用する場合、App Mesh は、検出されたサービスインスタンスをエンドポイントリソースとしてプロキシに送信します。
+ **シークレット** - これらには、暗号化キーと TLS 証明書が含まれますが、これらに限定されません。クライアント証明書とサーバー証明書のソース AWS Certificate Manager として を使用する場合、App Mesh はパブリック証明書とプライベート証明書をシークレットリソースとしてプロキシに送信します。

App Mesh は Envoy リソースの名前に一貫したスキームを使用し、メッシュとの関連付けに使用できます。

リスナーとクラスターの命名スキームを理解することは、App Mesh で Envoy のメトリクスを理解する上で重要です。

**リスナー名**

リスナーは次の形式を使用して命名されます。

```
lds_{{<traffic direction>}}_{{<listener IP address>}}_{{<listening port>}}
```

通常、Envoy で設定されている次のリスナーが表示されます。
+ `lds_ingress_0.0.0.0_15000`
+ `lds_egress_0.0.0.0_15001`

Kubernetes CNI プラグインまたは IP テーブルルールのいずれかを使用して、Amazon ECS タスクまたは Kubernetes ポッドのトラフィックがポート `15000` と `15001` に送信されます。App Mesh は、入力 (着信) および出力 (発信) トラフィックを受け入れるように、これらの 2 つのリスナーで Envoy を設定します。仮想ノードでリスナーが設定されていない場合、入力リスナーは表示されません。

**クラスター名**

ほとんどのクラスターは、次の形式を使用します。

```
cds_{{<traffic direction>}}_{{<mesh name>}}_{{<virtual node name>}}_{{<protocol>}}_{{<port>}}
```

サービスがそれぞれと通信する仮想ノードには、独自のクラスタがあります。前述のように、App Mesh は Envoy の隣で実行されているサービスのクラスターを作成し、プロキシが入力トラフィックを送信できるようにします。

例えば、ポート `8080` で http トラフィックをリッスンする `my-virtual-node` という名前の仮想ノードがあり、その仮想ノードが `my-mesh` という名前のメッシュ内にある場合、App Mesh は `cds_ingress_my-mesh_my-virtual-node_http_8080` という名前のクラスターを作成します。このクラスタは、`my-virtual-node` のサービスコンテナへのトラフィックの宛先として機能します。

App Mesh は、次のタイプの追加の特別なクラスターを作成することもできます。これらの他のクラスタは、メッシュで明示的に定義したリソースに必ずしも対応しているとは限りません。
+ 他の AWS サービスに到達するために使用するクラスター。このタイプにより、メッシュはデフォルトでほとんどの AWS サービスに到達できます: `cds_egress_{{<mesh name>}}_amazonaws`。
+ 仮想ゲートウェイのルーティングを実行するために使用されるクラスタ。これは一般的に無視しても問題ありません: 
  + 単一リスナーの場合: `cds_ingress_{{<mesh name>}}_{{<virtual gateway name>}}_self_redirect_{{<protocol>}}_{{<port>}}`
  + 複数のリスナーの場合: `cds_ingress_{{<mesh name>}}_{{<virtual gateway name>}}_self_redirect_{{<ingress_listener_port>}}_{{<protocol>}}_{{<port>}}`
+ Envoy の Secret Discovery Service を使用してシークレットを取得するときに、TLS など、定義できるエンドポイントのクラスタ: `static_cluster_sds_unix_socket` です。

## アプリケーションメトリクスの例
<a name="envoy-metrics-examples"></a>

Envoy で使用可能なメトリクスを説明するために、次のサンプルアプリケーションには 3 つの仮想ノードがあります。メッシュ内の仮想サービス、仮想ルータ、ルートは Envoy のメトリクスに反映されないため、無視できます。この例では、すべてのサービスがポート 8080 で http トラフィックをリッスンします。

![Service および Envoy コンポーネントを含む 3 つの仮想ノード: product-details、 cart、および website。](https://docs.aws.amazon.com/ja_jp/app-mesh/latest/userguide/images/envoy-metric-example1.png)


環境変数 `ENABLE_ENVOY_STATS_TAGS=1` をメッシュで実行されている Envoy プロキシコンテナに追加するようお勧めします。これにより、プロキシによって発行されたメトリクスに、次のメトリクスディメンションが追加されます。
+ `appmesh.mesh`
+ `appmesh.virtual_node`
+ `appmesh.virtual_gateway`

これらのタグは、メッシュ、仮想ノード、または仮想ゲートウェイの名前に設定され、メッシュ内のリソース名を使用してメトリクスをフィルタリングできます。

**リソース名**

website 仮想ノードのプロキシには、次のリソースがあります。
+ 入力トラフィックと出力トラフィック用の 2 つのリスナーには、次があります。
  + `lds_ingress_0.0.0.0_15000`
  + `lds_egress_0.0.0.0_15001`
+ 2 つの仮想ノードのバックエンドを表す 2 つの出力クラスター。
  + `cds_egress_online-store_product-details_http_8080`
  + `cds_egress_online-store_cart_http_8080`
+ website サービスコンテナの入力クラスター。
  + `cds_ingress_online-store_website_http_8080`

**リスナーメトリクスの例**
+ `listener.0.0.0.0_15000.downstream_cx_active` — Envoy へのアクティブな入力ネットワーク接続の数。
+ `listener.0.0.0.0_15001.downstream_cx_active` — Envoy へのアクティブな出力ネットワーク接続の数。アプリケーションが外部サービスに対して行った接続は、この数に含まれます。
+ `listener.0.0.0.0_15000.downstream_cx_total` — Envoy への入力ネットワーク接続の総数。
+ `listener.0.0.0.0_15001.downstream_cx_total` — Envoy への出力ネットワーク接続の総数。

リスナーメトリクスの完全なセットについては、Envoy のドキュメントの「[統計](https://www.envoyproxy.io/docs/envoy/latest/configuration/listeners/stats)」を参照してください。

**クラスターメトリクスの例**
+ `cluster_manager.active_clusters` — Envoy が少なくとも 1 つの接続を確立したクラスターの総数。
+ `cluster_manager.warming_clusters` — Envoy がまだ接続していないクラスターの総数。

次のクラスターメトリクスは、`cluster.<cluster name>.<metric name>` の形式を使用します。これらのメトリクス名はアプリケーションの例に固有で、website の Envoy コンテナによって発行されます。
+ `cluster.cds_egress_online-store_product-details_http_8080.upstream_cx_total` — website と product-details 間での接続の総数。
+ `cluster.cds_egress_online-store_product-details_http_8080.upstream_cx_connect_fail` — website と product-details 間での失敗した接続の合計数。
+ `cluster.cds_egress_online-store_product-details_http_8080.health_check.failure` — website と product-details 間での失敗したヘルスチェックの総数。
+ `cluster.cds_egress_online-store_product-details_http_8080.upstream_rq_total` — website と product-details 間で行われたリクエストの総数。
+ `cluster.cds_egress_online-store_product-details_http_8080.upstream_rq_time` — website と product-details 間で行われたリクエストにかかる時間。
+ `cluster.cds_egress_online-store_product-details_http_8080.upstream_rq_2xx` — roduct-details から website が受信した HTTP 2xx レスポンスの数。

HTTP メトリクスの完全なセットについては、Envoy のドキュメントの「[統計](https://www.envoyproxy.io/docs/envoy/latest/configuration/http/http_conn_man/stats)」を参照してください。

**管理サーバーのメトリクス**

Envoy は、Envoy の管理サーバーとして機能する App Mesh コントロールプレーンへの接続に関連するメトリクスも出力します。プロキシがコントロールプレーンから長時間同期解除された場合に通知する手段として、これらのメトリクスのいくつかを監視することをお勧めします。コントロールプレーンへの接続が失われるか、更新に失敗すると、プロキシが App Mesh API を介して行われたメッシュの変更を含めて、App Mesh からの新しい設定を受信できなくなります。
+ `control_plane.connected_state` — プロキシが App Mesh に接続されている場合、このメトリクスは 1 に設定され、それ以外の場合は 0 に設定されます。
+ `*.update_rejected` — Envoy によって拒否された設定更新の総数。これらは通常、ユーザーの設定ミスによるものです。例えば、Envoy が読み取れないファイルから TLS 証明書を読み取るように App Mesh を設定すると、その証明書のへパスを含む更新は拒否されます。
  + リスナーの更新が拒否された場合、統計は `listener_manager.lds.update_rejected` になります。
  + クラスターの更新が拒否された場合、統計は `cluster_manager.cds.update_rejected` になります。
+ `*.update_success` — App Mesh がプロキシに対して正常に行った設定更新の数。これには、新しい Envoy コンテナの起動時に送信される初期設定ペイロードが含まれます。
  + リスナーの更新が成功した場合、統計は `listener_manager.lds.update_success` になります。
  + クラスターの更新が成功した場合、統計は `cluster_manager.cds.update_success` になります。

管理サーバーのメトリクスのセットについては、Envoy のドキュメントの「[管理サーバー](https://www.envoyproxy.io/docs/envoy/latest/configuration/overview/mgmt_server)」を参照してください。