

As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

# Como monitorar seu aplicativo usando métricas do Envoy
<a name="envoy-metrics"></a>

**Importante**  
Aviso de fim do suporte: em 30 de setembro de 2026, AWS o suporte para o. AWS App Mesh Depois de 30 de setembro de 2026, você não poderá mais acessar o AWS App Mesh console ou os AWS App Mesh recursos. Para obter mais informações, visite esta postagem no blog [Migrando do AWS App Mesh Amazon ECS Service Connect.](https://aws.amazon.com/blogs/containers/migrating-from-aws-app-mesh-to-amazon-ecs-service-connect) 

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.

![\[Diagram showing proxy and service containers within an Amazon ECS task or Kubernetes Pod with ingress and egress flow.\]](http://docs.aws.amazon.com/pt_br/app-mesh/latest/userguide/images/task-proxy-container.png)


**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. Ao AWS Certificate Manager ser 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 AWS serviços. Esse tipo permite que sua malha alcance a maioria dos AWS serviços 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
<a name="envoy-metrics-examples"></a>

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.

![\[Diagram showing Envoy proxies in product-details, cart, and website services of an online store mesh.\]](http://docs.aws.amazon.com/pt_br/app-mesh/latest/userguide/images/envoy-metric-example1.png)


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](https://www.envoyproxy.io/docs/envoy/latest/configuration/listeners/stats) 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](https://www.envoyproxy.io/docs/envoy/latest/configuration/http/http_conn_man/stats) 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 plano de controle ou falhas nas atualizações impedem que seus proxies recebam novas configurações do App Mesh, incluindo alterações de malha feitas por meio do App Mesh. APIs
+ `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](https://www.envoyproxy.io/docs/envoy/latest/configuration/overview/mgmt_server) na documentação do Envoy.

# Como exportar métricas
<a name="metrics"></a>

**Importante**  
Aviso de fim do suporte: em 30 de setembro de 2026, AWS o suporte para o. AWS App Mesh Depois de 30 de setembro de 2026, você não poderá mais acessar o AWS App Mesh console ou os AWS App Mesh recursos. Para obter mais informações, visite esta postagem no blog [Migrando do AWS App Mesh Amazon ECS Service Connect.](https://aws.amazon.com/blogs/containers/migrating-from-aws-app-mesh-to-amazon-ecs-service-connect) 

O Envoy emite muitas estatísticas sobre sua própria operação e sobre várias dimensões do tráfego de entrada e saída. Para saber mais sobre as estatísticas do Envoy, consulte [Estatísticas](https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/observability/statistics) na documentação do Envoy. Essas métricas estão disponíveis por meio do endpoint `/stats` na porta de administração do proxy, o que normalmente é `9901`.

O prefixo `stat` será diferente dependendo se você estiver usando um ou vários receptores. Abaixo estão alguns exemplos para ilustrar as diferenças.

**Atenção**  
Se você atualizar seu único receptor para o atributo de vários receptores, poderá enfrentar uma alteração significativa devido ao prefixo estatístico atualizado ilustrado na tabela a seguir.  
 Sugerimos que você use a imagem do Envoy `1.22.2.1-prod` ou posterior. Isso permite que você veja nomes de métricas semelhantes em seu endpoint Prometheus.


| Receptor único (SL)/Estatísticas existentes com o prefixo de receptor "ingress" | Vários receptores (ML)/Novas estatísticas com prefixo do receptor "ingress.<protocol>.<port>" | 
| --- | --- | 
|  `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`  | 

Para mais informações sobre o endpoint de estatísticas, consulte [Estatísticas de endpoint](https://www.envoyproxy.io/docs/envoy/latest/operations/admin#get--stats) na documentação do Envoy. Para mais informações sobre a interface de administração, consulte [Ativar a interface de administração do proxy Envoy](troubleshooting-best-practices.md#ts-bp-enable-proxy-admin-interface).

## Prometheus para o App Mesh com Amazon EKS
<a name="prometheus"></a>

**Importante**  
Aviso de fim do suporte: em 30 de setembro de 2026, AWS o suporte para o. AWS App Mesh Depois de 30 de setembro de 2026, você não poderá mais acessar o AWS App Mesh console ou os AWS App Mesh recursos. Para obter mais informações, visite esta postagem no blog [Migrando do AWS App Mesh Amazon ECS Service Connect.](https://aws.amazon.com/blogs/containers/migrating-from-aws-app-mesh-to-amazon-ecs-service-connect) 

O Prometheus é um toolkit de código aberto para alertas e monitoramento. Um de seus recursos é especificar um formato para emissão de métricas que possam ser consumidas por outros sistemas. Para mais informações sobre o Prometheus, consulte [Visão geral](https://prometheus.io/docs/introduction/overview/) na documentação do Prometheus. O Envoy pode emitir suas métricas por meio de seu endpoint de estatísticas passando pelo parâmetro `/stats?format=prometheus`.

Para clientes que estão usando a imagem do Envoy compilação v1.22.2.1-prod, há duas dimensões adicionais para indicar estatísticas específicas do receptor de entrada:
+ `appmesh.listener_protocol`
+ `appmesh.listener_port`

Abaixo está uma comparação entre as estatísticas existentes do Prometheus e as novas estatísticas.
+ Estatísticas existentes com o prefixo de receptor "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
  ```
+ Novas estatísticas com "ingress.<protocol>.<port>" \$1 Imagem Appmesh Envoy v1.22.2.1-prod ou posterior

  ```
  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
  ```
+ Novas estatísticas com "ingress.<protocol>.<port>" \$1 imagem de compilação personalizada do 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
  ```

Para vários receptores, o cluster especial `cds_ingress_<mesh name>_<virtual gateway name>_self_redirect_<ingress_listener_port>_<protocol>_<port>` será específico do receptor.
+ Estatísticas existentes com o prefixo de receptor "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
  ```
+ Novas estatísticas com "ingress.<protocol>.<port>"

  ```
  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
  ```

### Como instalar o Prometheus
<a name="installing-prometheus"></a>

1. Adicione o repositório do EKS ao Helm:

   ```
   helm repo add eks https://aws.github.io/eks-charts
   ```

1. Instale o App Mesh Prometheus

   ```
   helm upgrade -i appmesh-prometheus eks/appmesh-prometheus \
   --namespace appmesh-system
   ```

### Exemplo de Prometheus
<a name="prometheus-sample"></a>

Veja a seguir um exemplo de criação de uma `PersistentVolumeClaim` para armazenamento persistente do Prometheus.

```
helm upgrade -i appmesh-prometheus eks/appmesh-prometheus \
--namespace appmesh-system \
--set retention=12h \
--set persistentVolumeClaim.claimName=prometheus
```

### Tutorial para usar o Prometheus
<a name="prometheus-walkthrough"></a>
+ [App Mesh com EKS—Observabilidade: Prometheus](https://github.com/aws/aws-app-mesh-examples/blob/main/walkthroughs/eks/o11y-prometheus.md)

### Para saber mais sobre o Prometheus e o Prometheus com o Amazon EKS
<a name="prometheus-eks"></a>
+ [Documentação do Prometheus](https://prometheus.io/docs/introduction/overview/)
+ **EKS:** [métricas do ambiente de gerenciamento com o Prometheus](https://docs.aws.amazon.com/eks/latest/userguide/prometheus.html)

## CloudWatch para App Mesh
<a name="cloudwatch"></a>

**Importante**  
Aviso de fim do suporte: em 30 de setembro de 2026, AWS o suporte para o. AWS App Mesh Depois de 30 de setembro de 2026, você não poderá mais acessar o AWS App Mesh console ou os AWS App Mesh recursos. Para obter mais informações, visite esta postagem no blog [Migrando do AWS App Mesh Amazon ECS Service Connect.](https://aws.amazon.com/blogs/containers/migrating-from-aws-app-mesh-to-amazon-ecs-service-connect) 

**Emitindo estatísticas do Envoy para o Amazon EKS CloudWatch**  
Você pode instalar o CloudWatch Agente em seu cluster e configurá-lo para coletar um subconjunto de métricas de seus proxies. Se você ainda não tem um cluster do Amazon EKS, pode criar um com as etapas em [Passo a passo: App Mesh com o Amazon EKS ativado](https://github.com/aws/aws-app-mesh-examples/tree/main/walkthroughs/eks). GitHub Você pode instalar um aplicativo de amostra no cluster seguindo o mesmo passo a passo.

Para definir as permissões apropriadas do IAM para seu cluster e instalar o agente, siga as etapas em [Instalar o CloudWatch agente com a coleção de métricas do Prometheus](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ContainerInsights-Prometheus-Setup.html). A instalação padrão contém uma configuração de extração do Prometheus que extrai um subconjunto útil das estatísticas do Envoy. Para obter mais informações, consulte [Métricas do Prometheus para o App Mesh](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ContainerInsights-Prometheus-metrics.html#ContainerInsights-Prometheus-metrics-appmesh).

Para criar um CloudWatch painel personalizado do App Mesh configurado para exibir as métricas que o agente está coletando, siga as etapas no tutorial [Visualizando suas métricas do Prometheus](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ContainerInsights-Prometheus-viewmetrics.html). Seus gráficos começarão a ser preenchidos com as métricas correspondentes à medida que o tráfego entrar no aplicativo App Mesh.

### Métricas de filtragem para CloudWatch
<a name="filtering-metrics"></a>

A [extensão de métricas do](https://docs.aws.amazon.com/app-mesh/latest/userguide/metrics.html#metrics-extension) App Mesh fornece um subconjunto de métricas úteis que fornecem informações sobre os comportamentos dos recursos que você define em sua malha. Como o CloudWatch agente suporta a coleta de métricas do Prometheus, você pode fornecer uma configuração de coleta para selecionar as métricas que deseja extrair do Envoy e para as quais enviar. CloudWatch

Você pode encontrar um exemplo de extração de métricas usando o Prometheus em nosso tutorial [Extensão de Métricas](https://github.com/aws/aws-app-mesh-examples/tree/main/walkthroughs/howto-metrics-extension-ecs).

### CloudWatch Exemplo
<a name="cloudwatch-sample"></a>

Você pode encontrar um exemplo de configuração de CloudWatch em nosso [repositório de AWS amostras](https://github.com/aws-samples/aws-app-mesh-cloudwatch-agent).

### Instruções para usar CloudWatch
<a name="cloudwatch-walkthrough"></a>
+ [Adicione recursos de monitoramento e log](https://www.appmeshworkshop.com/monitoring/) em nosso [Workshop do App Mesh](https://www.appmeshworkshop.com/introduction/).
+ [App Mesh com EKS — Observabilidade: CloudWatch](https://github.com/aws/aws-app-mesh-examples/blob/main/walkthroughs/eks/o11y-cloudwatch.md)
+ [Como usar a extensão de métricas do App Mesh no ECS](https://github.com/aws/aws-app-mesh-examples/tree/main/walkthroughs/howto-metrics-extension-ecs)

## Extensão de métricas para o App Mesh
<a name="metrics-extension"></a>

**Importante**  
Aviso de fim do suporte: em 30 de setembro de 2026, AWS o suporte para o. AWS App Mesh Depois de 30 de setembro de 2026, você não poderá mais acessar o AWS App Mesh console ou os AWS App Mesh recursos. Para obter mais informações, visite esta postagem no blog [Migrando do AWS App Mesh Amazon ECS Service Connect.](https://aws.amazon.com/blogs/containers/migrating-from-aws-app-mesh-to-amazon-ecs-service-connect) 

O Envoy gera centenas de métricas divididas em algumas dimensões diferentes. As métricas não são diretas na forma como se relacionam com o App Mesh. No caso de serviços virtuais, não há mecanismo para saber com certeza qual serviço virtual está se comunicando com um determinado nó virtual ou gateway virtual.

A extensão de métricas do App Mesh aprimora os proxies Envoy em execução na sua malha. Esse aprimoramento permite que os proxies emitam métricas adicionais que estejam cientes dos recursos que você define. Esse pequeno subconjunto de métricas adicionais ajudará você a entender melhor o comportamento dos recursos que você definiu no App Mesh.

Para ativar a extensão de métricas do App Mesh, defina a variável de ambiente `APPMESH_METRIC_EXTENSION_VERSION` como `1`.

```
APPMESH_METRIC_EXTENSION_VERSION=1
```

Para mais informações sobre as variáveis de configuração do Envoy, consulte [Variáveis de configuração do Envoy](envoy-config.md).

### Métricas relacionadas ao tráfego de entrada
<a name="inbound-metrics"></a>
+ `ActiveConnectionCount`
  + `envoy.appmesh.ActiveConnectionCount`: número de conexões TCP ativas.
  + *Dimensões* — Malha, VirtualNode, VirtualGateway
+ **`NewConnectionCount`**
  + `envoy.appmesh.NewConnectionCount`: número total de conexões TCP.
  + *Dimensões* — Malha, VirtualNode, VirtualGateway
+ **`ProcessedBytes`**
  + `envoy.appmesh.ProcessedBytes`: total de bytes TCP enviados e recebidos de clientes downstream.
  + *Dimensões* — Malha, VirtualNode, VirtualGateway
+ **`RequestCount`**
  + `envoy.appmesh.RequestCount`: o número de solicitações HTTP processadas.
  + *Dimensões* — Malha, VirtualNode, VirtualGateway
+ **`GrpcRequestCount`**
  + `envoy.appmesh.GrpcRequestCount`: o número de solicitações gPRC processadas.
  + *Dimensões* — Malha, VirtualNode, VirtualGateway

### Métricas relacionadas ao tráfego de saída
<a name="outbound-metrics"></a>

Você verá dimensões diferentes em suas métricas de saída com base no fato de elas virem de um nó virtual ou de um gateway virtual.
+ `TargetProcessedBytes`
  + `envoy.appmesh.TargetProcessedBytes`: total de bytes TCP enviados e recebidos dos destinos upstream do Envoy.
  + 

    *Dimensões*:
    + Dimensões do nó virtual — Mesh, VirtualNode, TargetVirtualService, TargetVirtualNode
    + Dimensões do gateway virtual — Mesh, VirtualGateway, TargetVirtualService, TargetVirtualNode
+ **`HTTPCode_Target_2XX_Count`**
  + `envoy.appmesh.HTTPCode_Target_2XX_Count`: o número de solicitações HTTP para um destino upstream do Envoy que resultaram em uma resposta HTTP 2xx.
  + 

    *Dimensões*:
    + Dimensões do nó virtual — Mesh, VirtualNode, TargetVirtualService, TargetVirtualNode
    + Dimensões do gateway virtual — Mesh, VirtualGateway, TargetVirtualService, TargetVirtualNode
+ **`HTTPCode_Target_3XX_Count`**
  + `envoy.appmesh.HTTPCode_Target_3XX_Count`: o número de solicitações HTTP para um destino upstream do Envoy que resultaram em uma resposta HTTP 3xx.
  + 

    *Dimensões*:
    + Dimensões do nó virtual — Mesh, VirtualNode, TargetVirtualService, TargetVirtualNode
    + Dimensões do gateway virtual — Mesh, VirtualGateway, TargetVirtualService, TargetVirtualNode
+ **`HTTPCode_Target_4XX_Count`**
  + `envoy.appmesh.HTTPCode_Target_4XX_Count`: o número de solicitações HTTP para um destino upstream do Envoy que resultaram em uma resposta HTTP 4xx.
  + 

    *Dimensões*:
    + Dimensões do nó virtual — Mesh, VirtualNode, TargetVirtualService, TargetVirtualNode
    + Dimensões do gateway virtual — Mesh, VirtualGateway, TargetVirtualService, TargetVirtualNode
+ **`HTTPCode_Target_5XX_Count`**
  + `envoy.appmesh.HTTPCode_Target_5XX_Count`: o número de solicitações HTTP para um destino upstream do Envoy que resultaram em uma resposta HTTP 5xx.
  + 

    *Dimensões*:
    + Dimensões do nó virtual — Mesh, VirtualNode, TargetVirtualService, TargetVirtualNode
    + Dimensões do gateway virtual — Mesh, VirtualGateway, TargetVirtualService, TargetVirtualNode
+ **`RequestCountPerTarget`**
  + `envoy.appmesh.RequestCountPerTarget`: o número de solicitações enviadas a um destino upstream do Envoy.
  + 

    *Dimensões*:
    + Dimensões do nó virtual — Mesh, VirtualNode, TargetVirtualService, TargetVirtualNode
    + Dimensões do gateway virtual — Mesh, VirtualGateway, TargetVirtualService, TargetVirtualNode
+ **`TargetResponseTime`**
  + `envoy.appmesh.TargetResponseTime`: o tempo decorrido desde o momento em que uma solicitação é feita a um destino upstream do Envoy até o recebimento da resposta completa.
  + 

    *Dimensões*:
    + Dimensões do nó virtual — Mesh, VirtualNode, TargetVirtualService, TargetVirtualNode
    + Dimensões do gateway virtual — Mesh, VirtualGateway, TargetVirtualService, TargetVirtualNode

## Datadog para o App Mesh
<a name="datadog"></a>

**Importante**  
Aviso de fim do suporte: em 30 de setembro de 2026, AWS o suporte para o. AWS App Mesh Depois de 30 de setembro de 2026, você não poderá mais acessar o AWS App Mesh console ou os AWS App Mesh recursos. Para obter mais informações, visite esta postagem no blog [Migrando do AWS App Mesh Amazon ECS Service Connect.](https://aws.amazon.com/blogs/containers/migrating-from-aws-app-mesh-to-amazon-ecs-service-connect) 

O Datadog é um aplicativo de monitoramento e segurança para monitoramento, métricas e log de ponta a ponta de aplicativos em nuvem. O Datadog torna sua infraestrutura, aplicativos e aplicativos de terceiros completamente observáveis.

### Como instalar o Datadog
<a name="installing-datadog"></a>
+ EKS: para configurar o Datadog com o EKS, siga estas etapas nos documentos do [Datadog](https://docs.datadoghq.com/integrations/amazon_app_mesh/?tab=eks).
+ ECS EC2: para configurar o Datadog com o ECS EC2, siga estas etapas na [documentação do Datadog](https://docs.datadoghq.com/integrations/amazon_app_mesh/?tab=ecsec2).

### Para saber mais a respeito do Datadog
<a name="datadog-learn-more"></a>
+ [Documentação do Datadog](https://docs.datadoghq.com/)