Monitorización de su aplicación mediante métricas de Envoy

Envoy clasifica sus métricas en las siguientes categorías principales:

• Descendentes: métricas relacionadas con las conexiones y solicitudes que entrar en el proxy.

• Ascendentes: métricas relacionadas con las conexiones salientes y las solicitudes realizadas por el proxy.

• Servidor: métricas que describen el estado interno de Envoy. Incluyen métricas como el tiempo de actividad o la memoria asignada.

En App Mesh, el proxy intercepta el tráfico ascendente y descendente. Por ejemplo, las solicitudes recibidas de sus clientes, así como las solicitudes realizadas por su contenedor de servicios, Envoy las clasifica como tráfico descendente. Para distinguir entre estos diferentes tipos de tráfico ascendente y descendente, App Mesh clasifica aún más las métricas de Envoy en función de la dirección del tráfico relacionadas con su servicio:

• Entrada: métricas y recursos relacionados con las conexiones y solicitudes que fluyen a su contenedor de servicios.

• Salida: métricas y recursos relacionados con las conexiones y solicitudes que fluyen desde su contenedor de servicios y, en última instancia, desde su tarea de Amazon ECS o su pod de Kubernetes.

La siguiente imagen muestra la comunicación entre el proxy y los contenedores de servicios.

Convenciones de nomenclatura para los recursos

Resulta útil entender cómo Envoy ve su malla y cómo sus recursos se corresponden con los recursos que usted define en App Mesh. Estos son los recursos principales de Envoy que App Mesh configura:

• Oyentes: las direcciones y puertos en los que el proxy escucha las conexiones descendentes. En la imagen anterior, App Mesh crea un oyente de entrada para el tráfico que entra en su tarea de Amazon ECS o su pod de Kubernetes y un oyente de salida para el tráfico que sale de su contenedor de servicios.

• Clústeres: un grupo de puntos de conexión ascendentes con nombre a los que el proxy se conecta y dirige el tráfico. En App Mesh, su contenedor de servicios se representa como un clúster, así como todos los demás nodos virtuales a los que se puede conectar su servicio.

• Rutas: corresponden a las rutas que defina en la malla. Contienen las condiciones según las cuales el proxy corresponde a una solicitud, así como el clúster de destino al que se envía la solicitud.

• Asignaciones de carga de clústeres y puntos de conexión: las direcciones IP de los clústeres ascendentes. Cuando se utiliza AWS Cloud Map como mecanismo de detección de servicios para nodos virtuales, App Mesh envía las instancias de servicio detectadas como recursos de punto de conexión a su proxy.

• Secretos: incluyen, entre otros, las claves de cifrado y los certificados TLS. Cuando se usa AWS Certificate Manager como el origen de los certificados de cliente y servidor, App Mesh envía certificados públicos y privados a su proxy como recursos secretos.

App Mesh usa un esquema coherente para nombrar los recursos de Envoy que puede usar para relacionarlos con su malla.

Comprender el esquema de nomenclatura de los oyentes y clústeres es importante para entender las métricas de Envoy en App Mesh.

Nombres de los oyentes

Los oyentes se nombran con el siguiente formato:

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

Normalmente, verá los siguientes oyentes configurados en Envoy:

• lds_ingress_0.0.0.0_15000

• lds_egress_0.0.0.0_15001

Mediante un complemento CNI de Kubernetes o reglas de tablas IP, el tráfico de la tarea de Amazon ECS o del pod de Kubernetes se dirige a los puertos 15000 y 15001. App Mesh configura Envoy con estos dos oyentes para aceptar el tráfico de entrada (entrante) y de salida (saliente). Si no tiene configurado un oyente en su nodo virtual, no debería ver ningún oyente de entrada.

Nombres de clúster

La mayoría de los clústeres utilizan el siguiente formato:

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

Cada uno de los nodos virtuales con los que se comunican sus servicios tiene su propio clúster. Como se mencionó anteriormente, App Mesh crea un clúster para el servicio que se ejecuta junto a Envoy para que el proxy pueda enviarle el tráfico de entrada.

Por ejemplo, si tiene un nodo virtual con el nombre my-virtual-node que escucha el tráfico http en el puerto 8080 y dicho nodo virtual está en una malla denominada my-mesh, App Mesh crea un clúster con el nombre cds_ingress_my-mesh_my-virtual-node_http_8080. Este clúster sirve como destino del tráfico hacia el contenedor de servicios de my-virtual-node.

App Mesh también puede crear los siguientes tipos de clústeres especiales adicionales. Estos otros clústeres no se corresponden necesariamente con los recursos que defina de forma explícita en su malla.

• Los clústeres se utilizan para comunicar con otros servicios de AWS. Este tipo permite que su malla comunique con la mayoría de los servicios de AWS de forma predeterminada: cds_egress_<mesh name>_amazonaws.

• Clúster utilizado para realizar el enrutamiento de las puertas de enlace virtuales. En general se puede ignorar con toda tranquilidad.

  • Para oyentes individuales: cds_ingress_<mesh name>_<virtual gateway name>_self_redirect_<protocol>_<port>

  • Para oyentes múltiples: cds_ingress_<mesh name>_<virtual gateway name>_self_redirect_<ingress_listener_port>_<protocol>_<port>

• El clúster cuyo punto de conexión puede definir, por ejemplo TLS, cuando recupera secretos mediante Secret Discovery Service de Envoy: static_cluster_sds_unix_socket.

Métricas de la aplicación de ejemplo

Para ilustrar las métricas disponibles en Envoy, la siguiente aplicación de ejemplo tiene tres nodos virtuales. Los servicios virtuales, los enrutadores virtuales y las rutas de la malla se pueden ignorar, porque no se reflejan en las métricas de Envoy. En este ejemplo, todos los servicios escuchan el tráfico http en el puerto 8080.

Recomendamos añadir la variable de entorno ENABLE_ENVOY_STATS_TAGS=1 a los contenedores del proxy de Envoy que se ejecutan en la malla. Esto añade las siguientes dimensiones de métrica a todas las métricas que emite el proxy:

• appmesh.mesh

• appmesh.virtual_node

• appmesh.virtual_gateway

Estas etiquetas se definen para el nombre de la malla, el nodo virtual o la puerta de enlace virtual para permitir filtrar las métricas mediante los nombres de los recursos de la malla.

Nombres de los recursos

El proxy del nodo virtual del sitio web tiene los siguientes recursos:

• Dos oyentes para el tráfico de entrada y salida:

  • lds_ingress_0.0.0.0_15000

  • lds_egress_0.0.0.0_15001

• Dos clústeres de salida, que representan los dos backends del nodo virtual:

  • cds_egress_online-store_product-details_http_8080

  • cds_egress_online-store_cart_http_8080

• Un clúster de entrada para el contenedor de servicios del sitio web:

  • cds_ingress_online-store_website_http_8080

Métricas del oyente de ejemplo

• listener.0.0.0.0_15000.downstream_cx_active: número de conexiones de red de entrada activas a Envoy.

• listener.0.0.0.0_15001.downstream_cx_active: número de conexiones de red de salida activas a Envoy. Las conexiones realizadas por su aplicación con servicios externos se incluyen en este recuento.

• listener.0.0.0.0_15000.downstream_cx_total: número total de conexiones de red de entrada a Envoy.

• listener.0.0.0.0_15001.downstream_cx_total: número total de conexiones de red de salida a Envoy.

Para ver el conjunto completo de métricas del oyente, consulte Estadísticas en la documentación de Envoy.

Métricas del clúster de ejemplo

• cluster_manager.active_clusters: número total de clústeres con los que Envoy ha establecido al menos una conexión.

• cluster_manager.warming_clusters: número total de clústeres a los que Envoy aún no se ha conectado.

Las siguientes métricas de clúster utilizan el formato cluster.<cluster name>.<metric name>. Estos nombres de métricas son exclusivos del ejemplo de aplicación y los emite el contenedor de Envoy del sitio web:

• cluster.cds_egress_online-store_product-details_http_8080.upstream_cx_total: número total de conexiones entre el sitio web y los detalles del producto.

• cluster.cds_egress_online-store_product-details_http_8080.upstream_cx_connect_fail: número total de conexiones con errores entre el sitio web y los detalles del producto.

• cluster.cds_egress_online-store_product-details_http_8080.health_check.failure: número total de comprobaciones de estado con errores entre el sitio web y los detalles del producto.

• cluster.cds_egress_online-store_product-details_http_8080.upstream_rq_total: número total de solicitudes realizadas entre el sitio web y los detalles del producto.

• cluster.cds_egress_online-store_product-details_http_8080.upstream_rq_time: tiempo que tardan las solicitudes realizadas entre el sitio web y los detalles del producto.

• cluster.cds_egress_online-store_product-details_http_8080.upstream_rq_2xx: número de respuestas HTTP 2xx recibidas por el sitio web de los detalles del producto.

Para ver el conjunto completo de métricas HTTP, consulte Estadísticas en la documentación de Envoy.

Métricas del servidor de administración

Envoy también emite métricas relacionadas con su conexión al plano de control de App Mesh, que actúa como servidor de administración de Envoy. Recomendamos monitorizar algunas de estas métricas para avisarlo cuando sus proxies se desincronizan respecto al plano de control durante períodos prolongados. La pérdida de conectividad con el plano de control o las actualizaciones incorrectas impiden que sus proxies reciban una nueva configuración de App Mesh, incluidos los cambios de malla realizados a través de las API de App Mesh.

• control_plane.connected_state: esta métrica se establece en 1 cuando el proxy está conectado a App Mesh; de lo contrario, es 0.

• *.update_rejected: número total de actualizaciones de configuración que rechaza Envoy. Por lo general, se deben a una mala configuración del usuario. Por ejemplo, si configura App Mesh para que lea un certificado TLS de un archivo que Envoy no puede leer, se rechazará la actualización que contenga la ruta a dicho certificado.

  • Para un oyente actualizado rechazado, las estadísticas serán listener_manager.lds.update_rejected.

  • Para un clúster actualizado rechazado, las estadísticas serán cluster_manager.cds.update_rejected.

• *.update_success: número de actualizaciones de configuración correctas realizadas por App Mesh en su proxy. Incluyen la carga útil de configuración inicial que se envía cuando se inicia un nuevo contenedor de Envoy.

  • Para un oyente actualizado correctamente, las estadísticas serán listener_manager.lds.update_success.

  • Para un clúster actualizado correctamente, las estadísticas serán cluster_manager.cds.update_success.

Para ver el conjunto de métricas del servidor de administración, consulte Servidor de administración en la documentación de Envoy.