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

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

• En aval : mesures relatives aux connexions et aux demandes qui entrent dans le proxy.

• En amont : mesures relatives aux connexions sortantes et aux demandes effectuées par le proxy.

• Serveur : mesures qui décrivent l'état interne d'Envoy. Il s'agit notamment de mesures telles que la 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 distinguer ces différents types de trafic en amont et en aval, App Mesh classe davantage les métriques Envoy en fonction de la direction du trafic par rapport à votre service :

• Entrée : 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 qui proviennent de votre conteneur de services et, en fin de compte, de votre tâche Amazon ECS ou de votre pod Kubernetes.

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

Conventions de dénomination des ressources

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

• Récepteurs : 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 tâche Amazon ECS 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 de tous les autres nœuds virtuels auxquels votre service peut se connecter.

• Itinéraires : ils correspondent aux itinéraires 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 affectations de charge des clusters : adresses IP des clusters en amont. Lorsque vous l'utilisezAWS Cloud Map comme mécanisme de découverte de services pour des 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 certificats TLS. Lorsque vous l'utilisezAWS 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 plugin CNI Kubernetes ou de règles de tables IP, le trafic de votre tâche Amazon ECS ou de votre pod Kubernetes est dirigé vers les ports15000 et15001. 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 lui envoyer du trafic entrant.

Par exemple, si vous avez nommé un nœud virtuelmy-virtual-node qui écoute le trafic HTTP sur le port8080 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 conteneurmy-virtual-node de service.

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

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

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

  • Pour les auditeurs célibataires :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, tel que TLS, lorsque vous récupérez des secrets à l'aide du service Secret Discovery d'Envoy :static_cluster_sds_unix_socket.

Exemples de métriques d'application

Pour illustrer les mesures 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.

Nous vous recommandons d'ajouter la variableENABLE_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 afin de permettre le filtrage des mesures à l'aide des noms des ressources de votre maillage.

Noms des ressources

Le proxy du nœud virtuel du site Web possède les 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 deux nœuds principaux 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 d'écoute

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

• listener.0.0.0.0_15001.downstream_cx_active—Nombre de connexions réseau de sortie actives vers Envoy. Les connexions effectuées 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 entrantes vers Envoy.

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

Pour obtenir l'ensemble complet des mesures relatives aux auditeurs, consultez la section Statistiques de la documentation Envoy.

Exemples de mesures 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 informations sur le 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 informations sur le produit.

• cluster.cds_egress_online-store_product-details_http_8080.health_check.failure—Nombre total de vérifications de santé infructueuses 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 informations sur le produit.

• cluster.cds_egress_online-store_product-details_http_8080.upstream_rq_time—Temps écoulé entre les demandes effectuées sur 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 sur le produit.

Pour accéder à l'ensemble complet des métriques HTTP, consultez la section Statistiques de la documentation 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 de nouvelles configurations depuis App Mesh, y compris des modifications de maillage effectuées via les API App Mesh.

• control_plane.connected_state—Cette métrique est définie sur 1 lorsque le proxy est connecté à App Mesh, sinon elle est égale à 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 certificat TLS à 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 Listener est rejetée, les statistiques serontlistener_manager.lds.update_rejected.

  • Si la mise à jour du cluster est refusée, 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.

  • Pour que la mise à jour de Listener soit réussie, les statistiques serontlistener_manager.lds.update_success.

  • Pour que la mise à jour du cluster soit réussie, les statistiques serontcluster_manager.cds.update_success.

Pour l'ensemble des mesures du serveur de gestion, consultez Management Server dans la documentation Envoy.