翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 # Envoy メトリクスを使用したアプリケーションの監視 **重要** サポート終了通知: 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 ポッドからフローする接続とリクエストに関するメトリクスとリソースです。 次の図は、プロキシコンテナとサービスコンテナ間の通信を示しています。 ![\[Diagram showing proxy and service containers within an Amazon ECS task or Kubernetes Pod with ingress and egress flow.\]](http://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___ ``` 通常、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_____ ``` サービスがそれぞれと通信する仮想ノードには、独自のクラスタがあります。前述のように、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__amazonaws`。 + 仮想ゲートウェイのルーティングを実行するために使用されるクラスタ。これは一般的に無視しても問題ありません: + 単一リスナーの場合: `cds_ingress___self_redirect__` + 複数のリスナーの場合: `cds_ingress___self_redirect___` + Envoy の Secret Discovery Service を使用してシークレットを取得するときに、TLS など、定義できるエンドポイントのクラスタ: `static_cluster_sds_unix_socket` です。 ## アプリケーションメトリクスの例 Envoy で使用可能なメトリクスを説明するために、次のサンプルアプリケーションには 3 つの仮想ノードがあります。メッシュ内の仮想サービス、仮想ルータ、ルートは Envoy のメトリクスに反映されないため、無視できます。この例では、すべてのサービスがポート 8080 で http トラフィックをリッスンします。 ![\[Diagram showing Envoy proxies in product-details, cart, and website services of an online store mesh.\]](http://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..` の形式を使用します。これらのメトリクス名はアプリケーションの例に固有で、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)」を参照してください。 # エクスポートされるメトリクス **重要** サポート終了通知: 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 の統計の詳細については、Envoy のドキュメントの「[統計](https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/observability/statistics)」を参照してください。これらのメトリクスは、プロキシの管理ポート 上の `/stats` エンドポイントを介して利用可能になります (通常は `9901`)。 `stat` プレフィックスは、単一リスナーを使用しているのか、複数のリスナーを使用しているのかによって異なります。その違いを示す例を以下に示します。 **警告** 単一リスナーを複数のリスナー機能に更新すると、以下の表に示す stat プレフィックスが更新され、重大な変更が発生する可能性があります。 Envoy イメージ `1.22.2.1-prod` 以降を使用することをお勧めします。これにより、Prometheus エンドポイントで類似のメトリクス名を確認できます。 | 単一リスナー (SL)/「ingress」リスナープレフィックスが付いた既存の統計情報 | 複数のリスナー (ML)/「ingress..」リスナープレフィックスが付いた新しい統計情報 | | --- | --- | | `http.*ingress*.rds.rds_ingress_http_5555.version_text` | `http.*ingress.http.5555*.rds.rds_ingress_http_5555.version_text` `http.*ingress.http.6666*.rds.rds_ingress_http_6666.version_text` | | `listener.0.0.0.0_15000.http.*ingress*.downstream_rq_2xx` | `listener.0.0.0.0_15000.http.*ingress.http.5555*.downstream_rq_2xx` `listener.0.0.0.0_15000.http.*ingress.http.6666*.downstream_rq_2xx` | | `http.*ingress*.downstream_cx_length_ms` | `http.*ingress.http.5555*.downstream_cx_length_ms` `http.*ingress.http.6666*.downstream_cx_length_ms` | 統計エンドポイントの詳細については、Envoy のドキュメントの「[統計エンドポイント](https://www.envoyproxy.io/docs/envoy/latest/operations/admin#get--stats)」を参照してください。管理者インターフェイスの詳細については、「[Envoy プロキシ管理インターフェイスを有効にする](troubleshooting-best-practices.md#ts-bp-enable-proxy-admin-interface)」を参照してください。 ## Amazon EKS での App Mesh の Prometheus **重要** サポート終了通知: 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)」を参照してください。 Prometheus はオープンソースのシステムモニタリングおよびアラートツールキットです。その機能の 1 つは、他のシステムが使用できるメトリクスを出力するための形式を指定することです。Prometheus の詳細については、Prometheus のドキュメントの「[概要](https://prometheus.io/docs/introduction/overview/)」を参照してください。Envoy は、パラメーター `/stats?format=prometheus` を渡すことで、統計エンドポイントを介してメトリクスを発行できます。 Envoy イメージビルド v1.22.2.1-prod を使用している場合、入力リスナー固有の統計情報を示すために 2 つのディメンションが追加されています。 + `appmesh.listener_protocol` + `appmesh.listener_port` Prometheus の既存の統計情報と新しい統計情報の比較です。 + 「ingress」リスナープレフィックスが付いた既存の統計情報 ``` envoy_http_downstream_rq_xx{appmesh_mesh="multiple-listeners-mesh",appmesh_virtual_node="foodteller-vn",envoy_response_code_class="2",envoy_http_conn_manager_prefix="ingress"} 931433 ``` + 「ingress..」が付いた新しい統計情報、Appmesh Envoy イメージ v1.22.2.1-prod 以降 ``` envoy_http_downstream_rq_xx{appmesh_mesh="multiple-listeners-mesh",appmesh_virtual_node="foodteller-vn",envoy_response_code_class="2",appmesh_listener_protocol="http",appmesh_listener_port="5555",envoy_http_conn_manager_prefix="ingress"} 20 ``` + 「ingress..」が付いた新しい統計情報、カスタム Envoy イメージビルド ``` envoy_http_http_5555_downstream_rq_xx{appmesh_mesh="multiple-listeners-mesh",appmesh_virtual_node="foodteller-vn",envoy_response_code_class="2",envoy_http_conn_manager_prefix="ingress"} 15983 ``` 複数のリスナーの場合、特別なクラスター `cds_ingress___self_redirect___` はリスナー固有になります。 + 「ingress」リスナープレフィックスが付いた既存の統計情報 ``` envoy_cluster_assignment_stale{appmesh_mesh="multiple-listeners-mesh",appmesh_virtual_gateway="tellergateway-vg",Mesh="multiple-listeners-mesh",VirtualGateway="tellergateway-vg",envoy_cluster_name="cds_ingress_multiple-listeners-mesh_tellergateway-vg_self_redirect_http_15001"} 0 ``` + 「ingress..」が付いた新しい統計情報 ``` envoy_cluster_assignment_stale{appmesh_mesh="multiple-listeners-mesh",appmesh_virtual_gateway="tellergateway-vg",envoy_cluster_name="cds_ingress_multiple-listeners-mesh_tellergateway-vg_self_redirect_1111_http_15001"} 0 envoy_cluster_assignment_stale{appmesh_mesh="multiple-listeners-mesh",appmesh_virtual_gateway="tellergateway-vg",envoy_cluster_name="cds_ingress_multiple-listeners-mesh_tellergateway-vg_self_redirect_2222_http_15001"} 0 ``` ### Prometheus のインストール 1. EKS リポジトリを Helm に追加します。 ``` helm repo add eks https://aws.github.io/eks-charts ``` 1. App Mesh Prometheus のインストール ``` helm upgrade -i appmesh-prometheus eks/appmesh-prometheus \ --namespace appmesh-system ``` ### Prometheus の例 次は、Prometheus 永続的ストレージ用に `PersistentVolumeClaim` を作成する例です。 ``` helm upgrade -i appmesh-prometheus eks/appmesh-prometheus \ --namespace appmesh-system \ --set retention=12h \ --set persistentVolumeClaim.claimName=prometheus ``` ### Prometheus の使用方法のチュートリアル + [EKS を使用した App Mesh — 可観測性：Prometheus](https://github.com/aws/aws-app-mesh-examples/blob/main/walkthroughs/eks/o11y-prometheus.md) ### Amazon EKS を使用した Prometheus と Prometheus について詳しく知るには + [Prometheus のドキュメント](https://prometheus.io/docs/introduction/overview/) + **EKS -** [Prometheus を使用したプレーンメトリクスのコントロール](https://docs.aws.amazon.com/eks/latest/userguide/prometheus.html) ## App Mesh の CloudWatch **重要** サポート終了通知: 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)」を参照してください。 **Amazon EKS から CloudWatch に Envoy 統計を出力します。** CloudWatch エージェントをクラスターにインストールし、プロキシからメトリクスのサブセットを収集するように設定できます。Amazon EKS クラスターをまだ作成していない場合は、GitHub の「[チュートリアル：Amazon EKS を使用した App Mesh](https://github.com/aws/aws-app-mesh-examples/tree/main/walkthroughs/eks)」の手順を使用して作成できます。同じチュートリアルに従って、サンプルアプリケーションをクラスターにインストールできます。 クラスターに適切な IAM アクセス許可を設定し、エージェントをインストールするには、「[Prometheus メトリクスコレクションを持つ CloudWatch エージェントをインストールする](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ContainerInsights-Prometheus-Setup.html)」の手順に従います。デフォルトのインストールには、Envoy 統計の有用なサブセットを取得する Prometheus スクレイプ設定が含まれています。詳細については、「[App Mesh の Prometheus メトリクス](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ContainerInsights-Prometheus-metrics.html#ContainerInsights-Prometheus-metrics-appmesh)」を参照してください。。 エージェントが収集するメトリクスを表示するように設定された App Mesh カスタム CloudWatch ダッシュボードを作成するには、「[Prometheus メトリクスの表示](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ContainerInsights-Prometheus-viewmetrics.html)」チュートリアルの手順に従います。トラフィックが App Mesh アプリケーションに入ると、グラフに対応するメトリクスが入力され始めます。 ### CloudWatch のメトリクスのフィルタ処理 App Mesh [メトリクス拡張機能](https://docs.aws.amazon.com/app-mesh/latest/userguide/metrics.html#metrics-extension)には、メッシュで定義したリソースの動作に関するインサイトを提供する便利なメトリクスのサブセットが用意されています。CloudWatch エージェントでは Prometheus メトリクスのスクレイピングがサポートされているため、Envoy からプルして CloudWatch に送信するメトリクスを選択するためのスクレープ設定を提供できます。 Prometheus を使用してメトリクスをスクレイピングする例については、「[メトリクス拡張機能](https://github.com/aws/aws-app-mesh-examples/tree/main/walkthroughs/howto-metrics-extension-ecs)」チュートリアルを参照してください。 ### CloudWatch の例 CloudWatch の設定例は、[AWS サンプルリポジトリ](https://github.com/aws-samples/aws-app-mesh-cloudwatch-agent)にあります。 ### CloudWatch を使用するためのチュートリアル + [App Mesh チュートリアル](https://www.appmeshworkshop.com/introduction/)の[モニタリングおよびログ記録機能の追加](https://www.appmeshworkshop.com/monitoring/)。 + [EKS を使用した App Mesh — 可観測性：CloudWatch](https://github.com/aws/aws-app-mesh-examples/blob/main/walkthroughs/eks/o11y-cloudwatch.md) + [ECS での App Mesh のメトリクス拡張の使用](https://github.com/aws/aws-app-mesh-examples/tree/main/walkthroughs/howto-metrics-extension-ecs) ## App Mesh のメトリクス拡張機能 **重要** サポート終了通知: 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 は、数百のメトリクスをいくつかの異なる次元に分けて生成します。メトリクスは、App Mesh との関連付け方法においては簡単ではありません。仮想サービスの場合、特定の仮想ノードまたは仮想ゲートウェイと通信している仮想サービスを確実に知るメカニズムはありません。 App Mesh メトリクス拡張により、メッシュで実行される Envoy プロキシが強化されます。この機能拡張により、プロキシは、定義したリソースを認識した追加のメトリクスを出力できます。追加のメトリクスのこの小さなサブセットは、App Mesh で定義したリソースの動作をより詳細に把握するのに役立ちます。 App Mesh メトリクス拡張機能を有効にするには、環境変数 `APPMESH_METRIC_EXTENSION_VERSION` を `1` に設定します。 ``` APPMESH_METRIC_EXTENSION_VERSION=1 ``` Envoy 設定変数の詳細については、[Envoy 設定変数](envoy-config.md) を参照してください。 ### インバウンドトラフィックに関連するメトリクス + `ActiveConnectionCount` + `envoy.appmesh.ActiveConnectionCount` — アクティブな TCP 接続の数。 + *ディメンション* — メッシュ、VirtualNode、VirtualGateWay + **`NewConnectionCount`** + `envoy.appmesh.NewConnectionCount` — TCP 接続の合計数。 + *ディメンション* — メッシュ、VirtualNode、VirtualGateWay + **`ProcessedBytes`** + `envoy.appmesh.ProcessedBytes` — ダウンストリームクライアントとの間で送受信された TCP バイトの合計。 + *ディメンション* — メッシュ、VirtualNode、VirtualGateWay + **`RequestCount`** + `envoy.appmesh.RequestCount` – 処理された HTTP リクエストの数。 + *ディメンション* — メッシュ、VirtualNode、VirtualGateWay + **`GrpcRequestCount`** + `envoy.appmesh.GrpcRequestCount` – 処理された gPRC リクエストの数。 + *ディメンション* — メッシュ、VirtualNode、VirtualGateWay ### アウトバウンドトラフィックに関連するメトリクス アウトバウンドメトリクスは、仮想ノードからのものか仮想ゲートウェイからのものかに基づいて、さまざまなディメンションが表示されます。 + `TargetProcessedBytes` + `envoy.appmesh.TargetProcessedBytes` — Envoy のアップストリームターゲットとの間で送受信された TCP バイトの合計。 + *ディメンション*: + 仮想ノードのディメンション — メッシュ、VirtualNode、ターゲット仮想サービス、ターゲット仮想ノード + 仮想ゲートウェイのディメンション — メッシュ、VirtualGateWay、TargetVirtualService、TargetVirtualNode + **`HTTPCode_Target_2XX_Count`** + `envoy.appmesh.HTTPCode_Target_2XX_Count` — 2xx HTTP レスポンスを発生させた、Envoy のアップストリームターゲットへの HTTP リクエストの数。 + *ディメンション*: + 仮想ノードのディメンション — メッシュ、VirtualNode、ターゲット仮想サービス、ターゲット仮想ノード + 仮想ゲートウェイのディメンション — メッシュ、VirtualGateWay、TargetVirtualService、TargetVirtualNode + **`HTTPCode_Target_3XX_Count`** + `envoy.appmesh.HTTPCode_Target_3XX_Count` — 3xx HTTP レスポンスを発生させた、Envoy のアップストリームターゲットへの HTTP リクエストの数。 + *ディメンション*: + 仮想ノードのディメンション — メッシュ、VirtualNode、ターゲット仮想サービス、ターゲット仮想ノード + 仮想ゲートウェイのディメンション — メッシュ、VirtualGateWay、TargetVirtualService、TargetVirtualNode + **`HTTPCode_Target_4XX_Count`** + `envoy.appmesh.HTTPCode_Target_4XX_Count` — 4xx HTTP レスポンスを発生させた、Envoy のアップストリームターゲットへの HTTP リクエストの数。 + *ディメンション*: + 仮想ノードのディメンション — メッシュ、VirtualNode、ターゲット仮想サービス、ターゲット仮想ノード + 仮想ゲートウェイのディメンション — メッシュ、VirtualGateWay、TargetVirtualService、TargetVirtualNode + **`HTTPCode_Target_5XX_Count`** + `envoy.appmesh.HTTPCode_Target_5XX_Count` — 5xx HTTP レスポンスを発生させた、Envoy のアップストリームターゲットへの HTTP リクエストの数。 + *ディメンション*: + 仮想ノードのディメンション — メッシュ、VirtualNode、ターゲット仮想サービス、ターゲット仮想ノード + 仮想ゲートウェイのディメンション — メッシュ、VirtualGateWay、TargetVirtualService、TargetVirtualNode + **`RequestCountPerTarget`** + `envoy.appmesh.RequestCountPerTarget` — Envoy のアップストリームターゲットに送信されたリクエストの数。 + *ディメンション*: + 仮想ノードのディメンション — メッシュ、VirtualNode、ターゲット仮想サービス、ターゲット仮想ノード + 仮想ゲートウェイのディメンション — メッシュ、VirtualGateWay、TargetVirtualService、TargetVirtualNode + **`TargetResponseTime`** + `envoy.appmesh.TargetResponseTime` — Envoy のアップストリームターゲットに対してリクエストが行われた時点から完全なレスポンスが受信されるまでの経過時間。 + *ディメンション*: + 仮想ノードのディメンション — メッシュ、VirtualNode、ターゲット仮想サービス、ターゲット仮想ノード + 仮想ゲートウェイのディメンション — メッシュ、VirtualGateWay、argetVirtualService、TargetVirtualNode ## App Mesh の Datadog **重要** サポート終了通知: 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)」を参照してください。 Datadog は、クラウドアプリケーションのエンドツーエンドの監視、メトリクス、およびログ記録のための監視およびセキュリティアプリケーションです。Datadog は、インフラストラクチャ、アプリケーション、およびサードパーティアプリケーションを完全に監視できるようにします。 ### Datadog のインストール + EKS - EKS で Datadog をセットアップするには、[Datadog のドキュメント](https://docs.datadoghq.com/integrations/amazon_app_mesh/?tab=eks)の手順に従ってください。 + ECS EC2 - ECS EC2 で Datadog をセットアップするには、[Datadog のドキュメント](https://docs.datadoghq.com/integrations/amazon_app_mesh/?tab=ecsec2)の手順に従ってください。 ### Datadog の詳細について + [Datadog のドキュメント](https://docs.datadoghq.com/)