Como monitorar seu aplicativo usando métricas do Envoy

O Envoy classifica suas métricas nas seguintes categorias principais:

• Downstream: métricas relacionadas às conexões e solicitações que chegam ao proxy.

• Upstream: métricas relacionadas às conexões de saída e às solicitações feitas pelo proxy.

• Servidor: métricas que descrevem o estado interno do Envoy. Isso inclui métricas como tempo de atividade ou memória alocada.

No App Mesh, o proxy intercepta o tráfego ascendente e descendente. Por exemplo, as solicitações recebidas de seus clientes, bem como as solicitações feitas pelo seu contêiner de serviço, são classificadas como tráfego downstream pelo Envoy. Para distinguir entre esses diferentes tipos de tráfego upstream e downstream, o App Mesh categoriza ainda mais as métricas do Envoy, dependendo da direção do tráfego em relação ao seu serviço:

• Entrada: métricas e recursos relacionados às conexões e solicitações que fluem para seu contêiner de serviços.

• Saída: métricas e recursos relacionados às conexões e solicitações que fluem do seu contêiner de serviços e, por fim, da sua tarefa do Amazon ECS ou pod do Kubernetes.

A figura a seguir mostra a comunicação entre o proxy e os contêineres de serviço.

Convenções de nomenclatura de recursos

É útil entender como o Envoy vê sua malha e como seus recursos são mapeados de volta aos recursos que você define no App Mesh. Esses são os principais recursos do Envoy que o App Mesh configura:

• Receptores: os endereços e portas em que o proxy recebe as conexões downstream. Na imagem anterior, o App Mesh cria um receptor de entrada para o tráfego que chega à sua tarefa do Amazon ECS ou pod do Kubernetes e um receptor de saída para o tráfego que sai do seu contêiner de serviço.

• Clusters: um grupo nomeado de endpoints upstream aos quais o proxy se conecta e encaminha o tráfego. No App Mesh, seu contêiner de serviço é representado como um cluster, assim como todos os outros nós virtuais aos quais seu serviço pode se conectar.

• Rotas: correspondem às rotas que você define em sua malha. Eles contêm as condições pelas quais o proxy corresponde a uma solicitação, bem como ao cluster de destino para o qual a solicitação é enviada.

• Atribuições de endpoints e carga do cluster: os endereços IP dos clusters upstream. Quando o AWS Cloud Map é usado como mecanismo de descoberta de serviços para nós virtuais, o App Mesh envia instâncias de serviço descobertas como recursos de endpoint para seu proxy.

• Segredos: eles incluem, mas não estão limitados a, suas chaves de criptografia e certificados TLS. Quando AWS Certificate Manager é usado como fonte para certificados de cliente e servidor, o App Mesh envia certificados públicos e privados para seu proxy como recursos secretos.

O App Mesh usa um esquema consistente para nomear recursos do Envoy que você pode usar para relacioná-los à sua malha.

Compreender o esquema de nomenclatura para receptores e clusters é importante para entender as métricas do Envoy no App Mesh.

Nomes de receptores

Os receptores são nomeados usando o seguinte formato:

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

Normalmente, você verá os seguintes receptores configurados no Envoy:

• lds_ingress_0.0.0.0_15000

• lds_egress_0.0.0.0_15001

Usando um plug-in CNI do Kubernetes ou regras de tabelas IP, o tráfego em sua tarefa do Amazon ECS ou pod do Kubernetes é direcionado para as portas 15000 e 15001. O App Mesh configura o Envoy com esses dois receptores para aceitar tráfego de entrada e saída. Se você não tiver um receptor configurado em seu nó virtual, não verá um receptor de entrada.

Nomes do cluster

A maioria dos clusters usa o seguinte formato:

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

Cada um dos nós virtuais com os quais seus serviços se comunicam tem seu próprio cluster. Conforme mencionado anteriormente, o App Mesh cria um cluster para o serviço executado ao lado do Envoy para que o proxy possa enviar tráfego de entrada para ele.

Por exemplo, se você tem um nó virtual chamado my-virtual-node que recebe o tráfego http na porta 8080 e esse nó virtual está em uma malha chamada my-mesh, o App Mesh cria um cluster chamado cds_ingress_my-mesh_my-virtual-node_http_8080. Esse cluster serve como destino para o tráfego no contêiner de serviço do my-virtual-node.

O App Mesh também pode criar os seguintes tipos de clusters especiais adicionais. Esses outros clusters não correspondem necessariamente aos recursos que você define explicitamente em sua malha.

• Clusters usados para alcançar outros serviços da AWS. Esse tipo permite que sua malha alcance a maioria dos serviços da AWS por padrão: cds_egress_<mesh name>_amazonaws.

• Cluster usado para realizar roteamento para gateways virtuais. Isso, em geral, pode ser ignorado com segurança:

  • Para receptores únicos: cds_ingress_<mesh name>_<virtual gateway name>_self_redirect_<protocol>_<port>

  • Para vários receptores: cds_ingress_<mesh name>_<virtual gateway name>_self_redirect_<ingress_listener_port>_<protocol>_<port>

• O cluster que é o endpoint que você pode definir, como TLS, quando você recupera segredos usando o Serviço de descoberta de segredos do Envoy: static_cluster_sds_unix_socket.

Exemplo de métricas de aplicações

Para ilustrar as métricas disponíveis no Envoy, o aplicativo de exemplo a seguir tem três nós virtuais. Os serviços virtuais, roteadores virtuais e rotas na malha podem ser ignorados, pois não são refletidos nas métricas do Envoy. Neste exemplo, todos os serviços recebem o tráfego http na porta 8080.

Recomendamos adicionar a variável de ambiente ENABLE_ENVOY_STATS_TAGS=1 aos contêineres proxy do Envoy em execução na sua malha. Isso adiciona as seguintes dimensões de métricas a todas as métricas emitidas pelo proxy:

• appmesh.mesh

• appmesh.virtual_node

• appmesh.virtual_gateway

Essas tags são definidas com o nome de malha, nó virtual ou gateway virtual para permitir a filtragem de métricas usando os nomes dos recursos em sua malha.

Nomes de recurso

O proxy do nó virtual do site tem os seguintes recursos:

• Dois receptores para tráfego de entrada e saída:

  • lds_ingress_0.0.0.0_15000

  • lds_egress_0.0.0.0_15001

• Dois clusters de saída, representando os dois back-ends de nós virtuais:

  • cds_egress_online-store_product-details_http_8080

  • cds_egress_online-store_cart_http_8080

• Um cluster de entrada para o contêiner de serviços do site:

  • cds_ingress_online-store_website_http_8080

Exemplo de métricas de receptor

• listener.0.0.0.0_15000.downstream_cx_active: número de conexões de rede de entrada ativas com o Envoy.

• listener.0.0.0.0_15001.downstream_cx_active: número de conexões de rede de saída ativas com o Envoy. As conexões feitas pelo seu aplicativo com serviços externos estão incluídas nessa contagem.

• listener.0.0.0.0_15000.downstream_cx_total: número total de conexões de rede de entrada com o Envoy.

• listener.0.0.0.0_15001.downstream_cx_total: número total de conexões de rede de saída com o Envoy.

Para ver o conjunto completo de métricas do receptor, consulte Estatísticas na documentação do Envoy.

Exemplos de métricas de cluster

• cluster_manager.active_clusters: o número total de clusters com os quais o Envoy estabeleceu pelo menos uma conexão.

• cluster_manager.warming_clusters: o número total de clusters aos quais o Envoy ainda não se conectou.

As métricas de cluster a seguir usam o formato de cluster.<cluster name>.<metric name>. Esses nomes de métricas são exclusivos do exemplo do aplicativo e são emitidos pelo contêiner Envoy do site:

• cluster.cds_egress_online-store_product-details_http_8080.upstream_cx_total: número total de conexões entre o site e os detalhes do produto.

• cluster.cds_egress_online-store_product-details_http_8080.upstream_cx_connect_fail: número total de conexões com falha entre o site e os detalhes do produto.

• cluster.cds_egress_online-store_product-details_http_8080.health_check.failure: número total de falhas nas verificações de integridade entre o site e os detalhes do produto.

• cluster.cds_egress_online-store_product-details_http_8080.upstream_rq_total: número total de solicitações feitas entre o site e os detalhes do produto.

• cluster.cds_egress_online-store_product-details_http_8080.upstream_rq_time: tempo gasto pelas solicitações feitas entre o site e os detalhes do produto.

• cluster.cds_egress_online-store_product-details_http_8080.upstream_rq_2xx: número de respostas HTTP 2xx recebidas pelo site a partir dos detalhes do produto.

Para ver o conjunto completo de métricas HTTP, consulte Estatísticas na documentação do Envoy.

Métricas do servidor de gerenciamento

O Envoy também emite métricas relacionadas à sua conexão com o ambiente de gerenciamento do App Mesh, que atua como servidor de gerenciamento do Envoy. Recomendamos monitorar algumas dessas métricas como forma de notificá-lo quando seus proxies forem dessincronizados do ambiente de gerenciamento por longos períodos de tempo. A perda de conectividade com o ambiente de gerenciamento ou falhas nas atualizações impedem que seus proxies recebam novas configurações do App Mesh, incluindo alterações de malha feitas por meio das APIs do App Mesh.

• control_plane.connected_state: essa métrica é definida como 1 quando o proxy está conectado ao App Mesh, caso contrário, é 0.

• *.update_rejected: número total de atualizações de configuração que são rejeitadas pelo Envoy. Geralmente, isso ocorre devido à configuração incorreta do usuário. Por exemplo, se você configurar o App Mesh para ler um certificado TLS de um arquivo que não pode ser lido pelo Envoy, a atualização contendo o caminho para esse certificado será rejeitada.

  • Para o receptor atualizado rejeitado, as estatísticas serão listener_manager.lds.update_rejected.

  • Para o cluster atualizado rejeitado, as estatísticas serão cluster_manager.cds.update_rejected.

• *.update_success: número de atualizações de configuração bem-sucedidas feitas pelo App Mesh em seu proxy. Isso inclui a carga de configuração inicial enviada quando um novo contêiner Envoy é iniciado.

  • Para o sucesso da atualização do receptor, as estatísticas serão listener_manager.lds.update_success.

  • Para o sucesso da atualização do cluster, as estatísticas serão cluster_manager.cds.update_success.

Para obter o conjunto de métricas do servidor de gerenciamento, consulte Servidor de gerenciamento na documentação do Envoy.