Surveillance de votre application à l'aide des métriques Envoy - AWS App Mesh
Exemples de métriques d'application

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Surveillance de votre application à l'aide des métriques Envoy

Important

Avis de fin de support : le 30 septembre 2026, AWS le support de. AWS App Mesh Après le 30 septembre 2026, vous ne pourrez plus accéder à la AWS App Mesh console ni aux AWS App Mesh ressources. Pour plus d'informations, consultez ce billet de blog intitulé Migration from AWS App Mesh to Amazon ECS Service Connect.

Envoy classe ses indicateurs dans les principales catégories suivantes :

  • Downstream : mesures relatives aux connexions et aux demandes qui arrivent dans le proxy.

  • Upstream —Métriques relatives aux connexions sortantes et aux demandes effectuées par le proxy.

  • Serveur : métriques décrivant l'état interne d'Envoy. Il s'agit notamment de mesures telles que le temps de disponibilité ou la mémoire allouée.

Dans App Mesh, le proxy intercepte le trafic en amont et en aval. Par exemple, les demandes reçues de vos clients ainsi que les demandes effectuées par votre conteneur de services sont classées comme du trafic en aval par Envoy. Pour faire la distinction entre ces différents types de trafic en amont et en aval, App Mesh classe davantage les métriques d'Envoy en fonction de la direction du trafic par rapport à votre service :

  • Ingress : mesures et ressources relatives aux connexions et aux demandes acheminées vers votre conteneur de services.

  • Sortie : mesures et ressources relatives aux connexions et aux demandes provenant de votre conteneur de services et, en fin de compte, de votre ECS tâche Amazon ou de votre pod Kubernetes.

L'image suivante montre la communication entre le proxy et les conteneurs de services.

Diagram showing proxy and service containers within an Amazon ECS task or Kubernetes Pod with ingress and egress flow.

Conventions de dénomination des ressources

Il est utile de comprendre comment Envoy visualise votre maillage et comment ses ressources sont associées aux ressources que vous définissez dans App Mesh. Voici les principales ressources Envoy configurées par App Mesh :

  • Écouteurs : adresses et ports sur lesquels le proxy écoute les connexions en aval. Dans l'image précédente, App Mesh crée un écouteur d'entrée pour le trafic entrant dans votre ECS tâche Amazon ou votre pod Kubernetes et un écouteur de sortie pour le trafic sortant de votre conteneur de services.

  • Clusters : groupe nommé de points de terminaison en amont auxquels le proxy se connecte et achemine le trafic. Dans App Mesh, votre conteneur de services est représenté sous la forme d'un cluster, ainsi que tous les autres nœuds virtuels auxquels votre service peut se connecter.

  • Routes —Elles correspondent aux routes que vous définissez dans votre maillage. Ils contiennent les conditions selon lesquelles le proxy correspond à une demande ainsi que le cluster cible auquel une demande est envoyée.

  • Points de terminaison et attributions de charge de cluster : adresses IP des clusters en amont. Lorsque vous l'utilisez AWS Cloud Map comme mécanisme de découverte de services pour les nœuds virtuels, App Mesh envoie les instances de service découvertes en tant que ressources de point de terminaison à votre proxy.

  • Secrets : ils incluent, sans toutefois s'y limiter, vos clés de chiffrement et vos TLS certificats. Lorsque vous l'utilisez AWS Certificate Manager comme source pour les certificats client et serveur, App Mesh envoie des certificats publics et privés à votre proxy en tant que ressources secrètes.

App Mesh utilise un schéma cohérent pour nommer les ressources Envoy que vous pouvez utiliser pour établir un lien avec votre maillage.

Il est important de comprendre le schéma de dénomination des auditeurs et des clusters pour comprendre les métriques d'Envoy dans App Mesh.

Noms des auditeurs

Les écouteurs sont nommés selon le format suivant :

lds_<traffic direction>_<listener IP address>_<listening port>

Vous verrez généralement les écouteurs suivants configurés dans Envoy :

  • lds_ingress_0.0.0.0_15000

  • lds_egress_0.0.0.0_15001

À l'aide d'un CNI plugin Kubernetes ou de règles de tables IP, le trafic de votre ECS tâche Amazon ou de votre pod Kubernetes est dirigé vers les ports et. 15000 15001 App Mesh configure Envoy avec ces deux écouteurs pour accepter le trafic entrant (entrant) et sortant (sortant). Si aucun écouteur n'est configuré sur votre nœud virtuel, vous ne devriez pas voir d'écouteur d'entrée.

Noms des clusters

La plupart des clusters utilisent le format suivant :

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

Les nœuds virtuels avec lesquels vos services communiquent possèdent chacun leur propre cluster. Comme mentionné précédemment, App Mesh crée un cluster pour le service exécuté à côté d'Envoy afin que le proxy puisse y envoyer du trafic entrant.

Par exemple, si vous avez un nœud virtuel nommé my-virtual-node qui écoute le trafic HTTP sur le port 8080 et que ce nœud virtuel se trouve dans un maillage nommémy-mesh, App Mesh crée un cluster nommécds_ingress_my-mesh_my-virtual-node_http_8080. Ce cluster sert de destination au trafic entrant dans le conteneur my-virtual-node de service.

App Mesh peut également créer les types de clusters spéciaux supplémentaires suivants. Ces autres clusters ne correspondent pas nécessairement aux ressources que vous définissez explicitement dans votre maillage.

  • Clusters utilisés pour accéder à d'autres AWS services. Ce type permet à votre maillage d'atteindre la plupart AWS des services par défaut :cds_egress_<mesh name>_amazonaws.

  • Cluster utilisé pour effectuer le routage des passerelles virtuelles. Cela peut généralement être ignoré en toute sécurité :.

    • Pour les auditeurs individuels : cds_ingress_<mesh name>_<virtual gateway name>_self_redirect_<protocol>_<port>

    • Pour plusieurs auditeurs : cds_ingress_<mesh name>_<virtual gateway name>_self_redirect_<ingress_listener_port>_<protocol>_<port>

  • Le cluster dont vous pouvez définir le point de terminaison, par exemple lorsque vous récupérez des secrets à l'aide du service de découverte secrète d'Envoy :static_cluster_sds_unix_socket. TLS

Exemples de métriques d'application

Pour illustrer les métriques disponibles dans Envoy, l'exemple d'application suivant comporte trois nœuds virtuels. Les services virtuels, les routeurs virtuels et les itinéraires du maillage peuvent être ignorés car ils ne sont pas reflétés dans les métriques d'Envoy. Dans cet exemple, tous les services écoutent le trafic HTTP sur le port 8080.

Diagram showing Envoy proxies in product-details, cart, and website services of an online store mesh.

Nous vous recommandons d'ajouter la variable ENABLE_ENVOY_STATS_TAGS=1 d'environnement aux conteneurs proxy Envoy exécutés dans votre maillage. Cela ajoute les dimensions métriques suivantes à toutes les métriques émises par le proxy :

  • appmesh.mesh

  • appmesh.virtual_node

  • appmesh.virtual_gateway

Ces balises sont définies sur le nom du maillage, du nœud virtuel ou de la passerelle virtuelle pour permettre de filtrer les métriques en utilisant les noms des ressources de votre maillage.

Noms des ressources

Le proxy du nœud virtuel du site Web dispose des ressources suivantes :

  • Deux écouteurs pour le trafic entrant et sortant :

    • lds_ingress_0.0.0.0_15000

    • lds_egress_0.0.0.0_15001

  • Deux clusters de sortie, représentant les dorsaux des deux nœuds virtuels :

    • cds_egress_online-store_product-details_http_8080

    • cds_egress_online-store_cart_http_8080

  • Un cluster d'entrée pour le conteneur de services du site Web :

    • cds_ingress_online-store_website_http_8080

Exemples de mesures relatives aux auditeurs

  • listener.0.0.0.0_15000.downstream_cx_active—Nombre de connexions réseau d'entrée actives à Envoy.

  • listener.0.0.0.0_15001.downstream_cx_active—Nombre de connexions réseau de sortie actives à Envoy. Les connexions établies par votre application à des services externes sont incluses dans ce décompte.

  • listener.0.0.0.0_15000.downstream_cx_total—Nombre total de connexions réseau d'entrée à Envoy.

  • listener.0.0.0.0_15001.downstream_cx_total—Nombre total de connexions réseau de sortie vers Envoy.

Pour l'ensemble complet des métriques relatives aux auditeurs, consultez la section Statistiques de la documentation d'Envoy.

Exemples de métriques de cluster

  • cluster_manager.active_clusters: le nombre total de clusters auxquels Envoy a établi au moins une connexion.

  • cluster_manager.warming_clusters: le nombre total de clusters auxquels Envoy ne s'est pas encore connecté.

Les métriques de cluster suivantes utilisent le format decluster.<cluster name>.<metric name>. Ces noms de métriques sont propres à l'exemple d'application et sont émis par le conteneur Envoy du site Web :

  • cluster.cds_egress_online-store_product-details_http_8080.upstream_cx_total—Nombre total de connexions entre le site Web et les détails du produit.

  • cluster.cds_egress_online-store_product-details_http_8080.upstream_cx_connect_fail—Nombre total d'échecs de connexion entre le site Web et les détails du produit.

  • cluster.cds_egress_online-store_product-details_http_8080.health_check.failure—Nombre total de tests de santé échoués entre le site Web et les détails du produit.

  • cluster.cds_egress_online-store_product-details_http_8080.upstream_rq_total—Nombre total de demandes effectuées entre le site Web et les détails du produit.

  • cluster.cds_egress_online-store_product-details_http_8080.upstream_rq_time—Temps pris par les demandes effectuées entre le site Web et les détails du produit.

  • cluster.cds_egress_online-store_product-details_http_8080.upstream_rq_2xx—Nombre de réponses HTTP 2xx reçues par le site Web à partir des informations détaillées sur le produit.

Pour l'ensemble complet des HTTP métriques, voir Statistiques dans la documentation d'Envoy.

Métriques du serveur de gestion

Envoy émet également des métriques liées à sa connexion au plan de contrôle App Mesh, qui fait office de serveur de gestion d'Envoy. Nous vous recommandons de surveiller certaines de ces mesures afin de vous avertir lorsque vos proxys sont désynchronisés du plan de contrôle pendant de longues périodes. La perte de connectivité au plan de contrôle ou l'échec des mises à jour empêchent vos proxys de recevoir les nouvelles configurations d'App Mesh, y compris les modifications de maillage effectuées via App MeshAPIs.

  • control_plane.connected_state—Cette métrique est définie sur 1 lorsque le proxy est connecté à App Mesh, sinon elle est définie sur 0.

  • *.update_rejected—Nombre total de mises à jour de configuration rejetées par Envoy. Elles sont généralement dues à une mauvaise configuration de l'utilisateur. Par exemple, si vous configurez App Mesh pour lire un TLS certificat à partir d'un fichier qui ne peut pas être lu par Envoy, la mise à jour contenant le chemin d'accès à ce certificat est rejetée.

    • Si la mise à jour de l'écouteur est rejetée, les statistiques seront les suivantes. listener_manager.lds.update_rejected

    • En cas de rejet de la mise à jour du cluster, les statistiques serontcluster_manager.cds.update_rejected.

  • *.update_success—Nombre de mises à jour de configuration réussies effectuées par App Mesh sur votre proxy. Il s'agit notamment de la charge utile de configuration initiale envoyée lors du démarrage d'un nouveau conteneur Envoy.

    • En cas de réussite de la mise à jour de Listener, les statistiques seront listener_manager.lds.update_success les suivantes :

    • En cas de réussite de la mise à jour du cluster, les statistiques seront les suivantes cluster_manager.cds.update_success :

Pour l'ensemble des métriques du serveur de gestion, consultez la section Serveur de gestion dans la documentation Envoy.