# Container Insights
Use o CloudWatch Container Insights para coletar, agregar e resumir métricas e logs de suas aplicações e seus microsserviços conteinerizados. O Container Insights está disponível para o Amazon Elastic Container Service (Amazon ECS), o Amazon Elastic Kubernetes Service (Amazon EKS), o RedHat OpenShift na AWS (ROSA) e para plataformas do Kubernetes no Amazon EC2. O Container Insights é compatível com a coleta de métricas de clusters implantados no AWS Fargate para o Amazon ECS e Amazon EKS.
O CloudWatch coleta automaticamente métricas de muitos recursos, como CPU, memória, disco e rede. O Container Insights também fornece informações de diagnóstico, como falhas de reinicialização de contêiner, para ajudar a isolar problemas e resolvê-los rapidamente. Também é possível definir alarmes do CloudWatch em métricas que o Container Insights coleta.
O Container Insights coleta dados como *eventos de log de performance* usando [formato de métrica incorporado](CloudWatch_Embedded_Metric_Format.md). Esses eventos de log de performance são entradas que usam um esquema JSON estruturado que permite que dados de alta cardinalidade sejam ingeridos e armazenados em escala. Com base nesses dados, o CloudWatch cria métricas agregadas no nível de cluster, nó, pod, tarefa e serviço como métricas do CloudWatch. As métricas que o Container Insights coleta estão disponíveis nos painéis automáticos do CloudWatch e também podem ser visualizadas na seção **Métricas** do console do CloudWatch. As métricas não estarão visíveis até que as tarefas do contêiner estejam em execução por algum tempo.
Quando você implanta o Container Insights, ele cria automaticamente um grupo de logs para os eventos do log de performance. Você não precisa criar esse grupo de logs sozinho.
Para ajudar você a gerenciar os custos do Container Insights, o CloudWatch não cria automaticamente todas as métricas possíveis dos dados de logs. Porém, é possível visualizar outras métricas e outros níveis de detalhamento usando o CloudWatch Logs Insights para analisar os eventos de log de performance brutos.
Com a versão original do Container Insights, as métricas coletadas e os registros ingeridos são cobrados como métricas personalizadas. Com o Container Insights com observabilidade aprimorada para o Amazon EKS, as métricas e os logs do Container Insights são cobrados por observação em vez de serem cobrados por métrica armazenada ou log ingerido. Para obter mais informações sobre os preços do CloudWatch, consulte [Preço do Amazon CloudWatch](https://aws.amazon.com/cloudwatch/pricing/).
**[Pré-visualização]** Para o Amazon EKS, o Container Insights com OpenTelemetry fornece um modo adicional de métricas que coleta métricas usando o OpenTelemetry Protocol (OTLP), e é compatível com consultas do PromQL. Cada métrica é enriquecida com até 150 rótulos, incluindo atributos de convenção semântica do OpenTelemetry e rótulos de pods e nós do Kubernetes. Para obter mais informações, consulte [Métricas do Container Insights com OpenTelemetry para Amazon EKS](container-insights-otel-metrics.md).
No Amazon EKS, no RedHat Openshift na AWS e no Kubernetes, o Container Insights usa uma versão conteinerizada do agente do CloudWatch para detectar todos os contêineres que estão em execução em um cluster. Depois, ele coleta dados de performance em cada camada da pilha de performance.
O Container Insights é compatível com a criptografia com o AWS KMS key dos registros e métricas que ele coleta. Para habilitar essa criptografia, você deve habilitar manualmente a criptografia do AWS KMS para o grupo de logs que recebe dados do Container Insights. Isso faz com que o Container Insights criptografe esses dados usando a chave do KMS fornecida. Somente chaves simétricas têm suporte. Não use chaves do KMS assimétricas para criptografar seus grupos de logs.
Para obter mais informações, consulte [Criptografar dados de log no CloudWatch Logs usando o AWS KMS](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/encrypt-log-data-kms.html).
## Plataformas compatíveis
O Container Insights está disponível para o Amazon Elastic Container Service, o Amazon Elastic Kubernetes Service, o RedHat OpenShift na AWS e para plataformas do Kubernetes em instâncias do Amazon EC2.
+ Para o Amazon ECS, o Container Insights coleta métricas nos níveis de cluster, tarefa e serviço em instâncias do Linux e do Windows Server. Ele pode coletar métricas no nível de instância apenas em instâncias do Linux. As métricas de rede estão disponíveis para contêineres que usam o modo de rede `bridge` e o modo de rede `awsvpc`, mas não estão disponíveis para contêineres que usam o modo de rede `host`.
+ No Amazon Elastic Kubernetes Service e nas plataformas do Kubernetes em instâncias do Amazon EC2, o Container Insights tem suporte em instâncias do Linux e Windows.
+ **[Pré-visualização]** O Container Insights com métricas do OpenTelemetry está disponível para o Amazon EKS. Para obter mais informações, consulte [Métricas do Container Insights com OpenTelemetry para Amazon EKS](container-insights-otel-metrics.md).
# Container Insights com observabilidade aprimorada para o Amazon ECS
Em 2 de dezembro de 2024, a AWS lançou o Container Insights com observabilidade aprimorada para o Amazon ECS. Essa versão é compatível com a observabilidade aprimorada dos clusters do Amazon ECS usando os tipos de inicialização do Amazon EC2 e do Fargate. Depois de configurar o Container Insights com observabilidade aprimorada no Amazon ECS, o Container Insights coleta automaticamente a telemetria detalhada da infraestrutura do nível do cluster até o nível do contêiner em seu ambiente e exibe esses dados cruciais de performance em painéis selecionados, eliminando o trabalho pesado na configuração da observabilidade. Para obter informações sobre como configurar o Container Insights com observabilidade aprimorada, consulte [Configurar o Container Insights no Amazon ECS](deploy-container-insights-ECS-cluster.md).
O Container Insights com observabilidade aprimorada fornece todas as métricas do Container Insights, além de métricas adicionais de tarefas e contêineres. Para obter mais informações, consulte [Métricas do Container Insights com observabilidade aprimorada para o Amazon ECS](Container-Insights-enhanced-observability-metrics-ECS.md).
O Container Insights com observabilidade aprimorada também é compatível com a observabilidade entre contas do CloudWatch. Você usa uma única conta de monitoramento para monitorar e solucionar problemas relacionados às aplicações que abrangem diversas contas da AWS em uma única região. Para obter mais informações, consulte [Observabilidade entre contas do CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Unified-Cross-Account.html).
# Container Insights com observabilidade aprimorada para o Amazon EKS
Em 6 de novembro de 2023, uma nova versão do Container Insights foi lançada. Essa versão é compatível com a observabilidade aprimorada dos clusters do Amazon EKS em execução no Amazon EC2 e pode coletar métricas mais detalhadas desses clusters. Após a instalação, ela coleta automaticamente a telemetria detalhada da infraestrutura e os registros de contêineres dos clusters do Amazon EKS. Em seguida, é possível usar painéis selecionados e imediatamente utilizáveis para detalhar a telemetria de aplicações e infraestrutura.
O Container Insights com observabilidade aprimorada para o Amazon EKS coleta métricas granulares de integridade, performance e status até o nível do contêiner, além de métricas do ambiente de gerenciamento. Para obter mais informações sobre as métricas e dimensões adicionais coletadas, consulte [Métricas do Container Insights com observabilidade aprimorada para o Amazon EKS e o Kubernetes](Container-Insights-metrics-enhanced-EKS.md).
Se você instalou o Container Insights usando o agente do CloudWatch em um cluster do Amazon EKS no Amazon EC2 após 6 de novembro de 2023, você tem o Container Insights com observabilidade aprimorada para o Amazon EKS. Caso contrário, você pode atualizar um cluster do Amazon EKS para essa nova versão seguindo as instruções em [Atualização para o Container Insights com observabilidade aprimorada para o Amazon EKS no CloudWatch](Container-Insights-upgrade-enhanced.md).
O Container Insights é compatível com a observabilidade entre contas do CloudWatch. Você usa uma única conta de monitoramento para monitorar e solucionar problemas relacionados a aplicações que abrangem diversas contas da AWS em uma única região. Para obter mais informações, consulte [Observabilidade entre contas do CloudWatch](CloudWatch-Unified-Cross-Account.md).
O Container Insights com observabilidade aprimorada para o Amazon EKS também é compatível com nós de processamento do Windows.
O Container Insights com observabilidade aprimorada para o Amazon EKS não é compatível com o Fargate.
**nota**
Você pode descobrir se tem clusters que podem ser atualizados para o Container Insights com observabilidade aprimorada para o Amazon EKS ao navegar até o console do Container Insights. Para fazer isso, selecione **Insights**, **Container Insights** no painel de navegação do console do CloudWatch. No console do Container Insights, um banner informa se você tem clusters do Amazon EKS que podem ser atualizados e links para a página de atualização.
# Métricas do Container Insights com OpenTelemetry para Amazon EKS
**Demonstração**
O Container Insights com métricas do OpenTelemetry fornece visibilidade sobre a integridade operacional da sua infraestrutura de clusters do Amazon EKS. Está disponível em pré-visualização pública sem custo adicional nas regiões Leste dos EUA (Norte da Virgínia), Oeste dos EUA (Oregon), Europa (Irlanda), Ásia-Pacífico (Singapura) e Ásia-Pacífico (Sydney).
O complemento de observabilidade do EKS do Amazon CloudWatch coleta métricas de código aberto de seus clusters do Amazon EKS e as envia para o CloudWatch usando o OpenTelemetry Protocol (OTLP) com granularidade de 30 segundos. Essas métricas usam nomes de métricas de suas fontes originais, incluindo cAdvisor, Prometheus Node Exporter, NVIDIA DCGM, Kube State Metrics e AWS Neuron Monitor. Você pode consultar essas métricas usando o PromQL no CloudWatch Query Studio ou por meio da API de consulta compatível com o Prometheus.
Cada métrica é enriquecida automaticamente com até 150 rótulos, incluindo atributos de convenção semântica do OpenTelemetry e rótulos de pods e nós do Kubernetes. O PromQL lida com a agregação no momento da consulta, então cada métrica é publicada uma vez por recurso, em vez de em vários níveis de agregação. O complemento também correlaciona as métricas do acelerador do AWS Neuron e do AWS Elastic Fabric Adapter com os pods e contêineres específicos que os usam, fornecendo visibilidade que não está disponível apenas nas fontes de métricas.
Para habilitar o OTel Container Insights em um cluster do Amazon EKS, instale o complemento de observabilidade do EKS do Amazon CloudWatch, versão `v6.0.1-eksbuild.1` ou posterior, por meio do console do Amazon EKS ou da infraestrutura como código.
Para obter mais informações sobre a configuração do OTel Container Insights, consulte [Configurar o Container Insights](deploy-container-insights.md).
Para obter mais informações sobre a consulta a essas métricas com o PromQL, consulte [Consultas do PromQL](CloudWatch-PromQL-Querying.md).
## Como o OTel Container Insights se compara ao Container Insights (aprimorado)
A tabela a seguir resume as diferenças entre o Container Insights (aprimorado) e o OTel Container Insights.
| Recurso | Container Insights (aprimorado) | OTel Container Insights |
| --- | --- | --- |
| Nomes de métricas | Métricas no formato do CloudWatch (por exemplo, pod\$1cpu\$1utilization) | Nativo de código aberto (por exemplo, container\$1cpu\$1usage\$1seconds\$1total) |
| Rótulos por métrica | 3 a 6 dimensões predefinidas por métrica | Até 150 rótulos, incluindo todos os rótulos de pods e nós do Kubernetes |
| Agregação | Pré-agregada em vários níveis (cluster, namespace, workload, pod) | Métricas brutas por recurso; agregada no momento da consulta com o PromQL |
| Linguagem da consulta | API do CloudWatch Metrics | PromQL (compatível com o Prometheus) |
| Ingestão de métricas | CloudWatch Logs no formato EMF | Endpoint do OTLP |
## Como as métricas são rotuladas
Cada métrica coletada pelo OTel Container Insights carrega rótulos de três fontes.
Rótulos nativos da fonte de telemetria
Rótulos da fonte original de métricas (por exemplo, o cAdvisor fornece rótulos como `pod`, `namespace` e `container`). Eles são preservados como atributos do ponto de dados.
Atributos de recursos do OpenTelemetry
O complemento anexa atributos de recursos seguindo as convenções semânticas do OpenTelemetry para [Kubernetes](https://opentelemetry.io/docs/specs/semconv/resource/k8s/), [Host](https://opentelemetry.io/docs/specs/semconv/resource/host/) e [Nuvem](https://opentelemetry.io/docs/specs/semconv/resource/cloud/), como `k8s.pod.name`, `k8s.namespace.name`, `k8s.node.name`, `host.name` e `cloud.region`. Esses atributos são consistentes em todas as fontes de métricas.
Rótulos de pods e nós do Kubernetes
Todos os rótulos de pods e de nós descobertos na API do Kubernetes são anexados como atributos de recursos com os prefixos `k8s.pod.label` e `k8s.node.label`.
Para obter mais informações sobre consultar esses atributos usando o PromQL, consulte [Consultas do PromQL](CloudWatch-PromQL-Querying.md).
## Métricas compatíveis
A tabela a seguir lista as fontes e categorias das métricas coletadas pelo OTel Container Insights.
| Origem da métrica | Categoria métrica | Pré-requisitos |
| --- | --- | --- |
| cAdvisor | Métricas de CPU | - |
| cAdvisor | Métricas de memória | - |
| cAdvisor | Métricas de rede | - |
| cAdvisor | Métricas de disco e de sistema de arquivos | - |
| Exportador de nós do Prometheus | Métricas de CPU | - |
| Exportador de nós do Prometheus | Métricas de memória | - |
| Exportador de nós do Prometheus | Métricas de disco | - |
| Exportador de nós do Prometheus | Métricas de sistema de arquivos | - |
| Exportador de nós do Prometheus | Métricas de rede | - |
| Exportador de nós do Prometheus | Métricas do sistema | - |
| Exportador de nós do Prometheus | Métricas do VMStat | - |
| Exportador de nós do Prometheus | Métricas de Netstat e soquetes | - |
| NVIDIA DCGM | Métricas de utilização e desempenho da GPU | O [plug-in de dispositivo NVIDIA](https://github.com/NVIDIA/k8s-device-plugin) e o [kit de ferramentas de contêiner NVIDIA](https://github.com/NVIDIA/nvidia-container-toolkit) devem estar instalados. |
| NVIDIA DCGM | Métricas de memória da GPU | O [plug-in de dispositivo NVIDIA](https://github.com/NVIDIA/k8s-device-plugin) e o [kit de ferramentas de contêiner NVIDIA](https://github.com/NVIDIA/nvidia-container-toolkit) devem estar instalados. |
| NVIDIA DCGM | Métricas térmicas e de energia da GPU | O [plug-in de dispositivo NVIDIA](https://github.com/NVIDIA/k8s-device-plugin) e o [kit de ferramentas de contêiner NVIDIA](https://github.com/NVIDIA/nvidia-container-toolkit) devem estar instalados. |
| NVIDIA DCGM | Métricas de limitação da GPU | O [plug-in de dispositivo NVIDIA](https://github.com/NVIDIA/k8s-device-plugin) e o [kit de ferramentas de contêiner NVIDIA](https://github.com/NVIDIA/nvidia-container-toolkit) devem estar instalados. |
| NVIDIA DCGM | Métricas de erro e confiabilidade da GPU | O [plug-in de dispositivo NVIDIA](https://github.com/NVIDIA/k8s-device-plugin) e o [kit de ferramentas de contêiner NVIDIA](https://github.com/NVIDIA/nvidia-container-toolkit) devem estar instalados. |
| NVIDIA DCGM | Métricas de NVLink da GPU | O [plug-in de dispositivo NVIDIA](https://github.com/NVIDIA/k8s-device-plugin) e o [kit de ferramentas de contêiner NVIDIA](https://github.com/NVIDIA/nvidia-container-toolkit) devem estar instalados. |
| NVIDIA DCGM | Métricas de informações da GPU | O [plug-in de dispositivo NVIDIA](https://github.com/NVIDIA/k8s-device-plugin) e o [kit de ferramentas de contêiner NVIDIA](https://github.com/NVIDIA/nvidia-container-toolkit) devem estar instalados. |
| AWS Neuron Monitor | Métricas do NeuronCore | O [driver Neuron](https://awsdocs-neuron.readthedocs-hosted.com/en/latest/general/setup/neuron-setup/pytorch/neuronx/ubuntu/torch-neuronx-ubuntu22.html) e o [plug-in do dispositivo Neuron](https://awsdocs-neuron.readthedocs-hosted.com/en/latest/containers/kubernetes-getting-started.html) devem estar instalados. |
| AWS Neuron Monitor | Métricas do NeuronDevice | O [driver Neuron](https://awsdocs-neuron.readthedocs-hosted.com/en/latest/general/setup/neuron-setup/pytorch/neuronx/ubuntu/torch-neuronx-ubuntu22.html) e o [plug-in do dispositivo Neuron](https://awsdocs-neuron.readthedocs-hosted.com/en/latest/containers/kubernetes-getting-started.html) devem estar instalados. |
| AWS Neuron Monitor | Métricas do sistema Neuron | O [driver Neuron](https://awsdocs-neuron.readthedocs-hosted.com/en/latest/general/setup/neuron-setup/pytorch/neuronx/ubuntu/torch-neuronx-ubuntu22.html) e o [plug-in do dispositivo Neuron](https://awsdocs-neuron.readthedocs-hosted.com/en/latest/containers/kubernetes-getting-started.html) devem estar instalados. |
| AWS Elastic Fabric Adapter | Métricas do EFA | O [plug-in do dispositivo EFA](https://github.com/aws/eks-charts/tree/master/stable/aws-efa-k8s-device-plugin) deve estar instalado. |
| NVMe | Métricas SMART de NVMe | - |
| Métricas de estado do Kube | Métricas de pods, nós, implantação, DaemonSet, StatefulSet, ReplicaSet, tarefas, CronJob, serviços, namespaces, PersistentVolume, PersistentVolumeClaim | - |
| Servidor da API do Kubernetes | Servidor da API e métricas do etcd | - |
## Imagem de contêiner do atendente do CloudWatch
A Amazon fornece uma imagem de contêiner do atendente do CloudWatch no Amazon Elastic Container Registry. Para obter mais informações, consulte [cloudwatch-agent](https://gallery.ecr.aws/cloudwatch-agent/cloudwatch-agent) no Amazon ECR.
# Configurar o Container Insights
O processo de configuração do Container Insights é diferente para o Amazon ECS e Amazon EKS e o Kubernetes.
+ [Configurar o Container Insights no Amazon EKS e no Kubernetes](deploy-container-insights-EKS.md)
+ [Configurar o Container Insights no Amazon ECS](deploy-container-insights-ECS.md)
**Topics**
+ [Configurar o Container Insights no Amazon ECS](deploy-container-insights-ECS.md)
+ [Configurar o Container Insights no Amazon EKS e no Kubernetes](deploy-container-insights-EKS.md)
+ [Como configurar o Container Insights no RedHat OpenShift na AWS (ROSA)](deploy-container-insights-RedHatOpenShift.md)
# Configurar o Container Insights no Amazon ECS
É possível usar uma ou ambas as opções a seguir para habilitar o Container Insights em clusters do Amazon ECS:
+ Use o Console de gerenciamento da AWS ou a AWS CLI para começar a coletar métricas no nível de cluster, no nível de tarefa e no nível de serviço.
+ Implante o agente do CloudWatch com um serviço daemon para começar a coletar métricas no nível de instância em clusters que são hospedados em instâncias do Amazon EC2.
**Topics**
+ [Configurar o Container Insights no Amazon ECS](deploy-container-insights-ECS-cluster.md)
+ [Configurar o Container Insights no Amazon ECS usando o AWS Distro for OpenTelemetry](deploy-container-insights-ECS-adot.md)
+ [Implantar o atendente do CloudWatch para coletar métricas no nível de instância do EC2 no Amazon ECS](deploy-container-insights-ECS-instancelevel.md)
+ [Implantar o AWS Distro for OpenTelemetry para coletar métricas no nível de instância do EC2 em clusters do Amazon ECS](deploy-container-insights-ECS-OTEL.md)
+ [Configurar o FireLens para enviar logs ao CloudWatch Logs](deploy-container-insights-ECS-logs.md)
# Configurar o Container Insights no Amazon ECS
Você pode configurar o Container Insights com observabilidade aprimorada ou o Container Insights em clusters novos e existentes do Amazon ECS usando o console do Amazon ECS ou a AWS CLI. O Container Insights coleta métricas nos níveis de cluster, de tarefa e de serviço. O Container Insights com observabilidade aprimorada fornece dimensões e métricas adicionais, permitindo que você se aprofunde na visibilidade em nível de contêiner.
Se estiver usando o Amazon ECS em uma instância do Amazon EC2, execute essa instância usando uma AMI que inclua o agente do Amazon ECS versão 1.29 ou posterior. Para obter informações sobre como atualizar a versão do agente, consulte [Atualizar o agente de contêiner do Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-agent-update.html).
**nota**
Se a chave do AWS KMS gerenciada pelo cliente que você usa para as métricas do Amazon ECS Container Insights ainda não estiver configurada para funcionar com o CloudWatch, você deverá atualizar a política de chave para permitir logs criptografados no CloudWatch Logs. Você também deve associar sua própria chave do AWS KMS ao grupo de logs em `/aws/ecs/containerinsights/ClusterName/performance`. Para obter mais informações, consulte [Criptografar dados de logs no CloudWatch Logs usando o AWS Key Management Service](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/encrypt-log-data-kms.html).
Recomendamos que você use o Container Insights com observabilidade aprimorada em vez do Container Insights, pois ele fornece visibilidade detalhada no ambiente de contêiner, reduzindo o tempo médio de resolução.
## Configurar o Container Insights com observabilidade aprimorada
Você pode ativar o Container Insights com observabilidade aprimorada usando o console do Amazon ECS ou a AWS CLI.
------
#### [ AWS CLI ]
Use o comando a seguir para ativar o Container Insights com observabilidade aprimorada.
Definir a configuração da conta `containerInsights` como `enhanced`
```
aws ecs put-account-setting --name containerInsights --value enhanced
```
Exemplo de saída
```
{
"setting": {
"name": "containerInsights",
"value": "enhanced",
"principalArn": "arn:aws:iam::123456789012:johndoe",
"type": user
}
}
```
**nota**
Por padrão, o `put-account-setting` apenas é aplicável ao usuário autenticado no momento. Para habilitar a configuração em nível de conta para todos os usuários e perfis, trabalhe com o usuário-raiz, como no exemplo a seguir.
```
aws ecs put-account-setting --name containerInsights --value enhanced --principal-arn arn:aws:iam::accountID:root
```
Depois de definir essa configuração de conta, todos os novos clusters usarão automaticamente o Container Insights com observabilidade aprimorada. Use o comando `update-cluster-settings` para adicionar o Container Insights com observabilidade aprimorada ao cluster existente, ou para atualizar clusters que atualmente usam o Container Insights para o Container Insights com observabilidade aprimorada.
```
aws ecs update-cluster-settings --cluster cluster-name --settings name=containerInsights,value=enhanced
```
------
#### [ Amazon ECS console ]
1. Abra o console em [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2).
1. Na barra de navegação na parte superior, selecione a região da qual você deseja visualizar as configurações da conta.
1. Na página de navegação, selecione **Account Settings** (Configurações da conta).
1. Selecione **Atualizar**.
1. Para usar o Container Insights com observabilidade aprimorada, escolha **Container Insights com observabilidade aprimorada**.
1. Escolha **Salvar alterações**.
1. Na tela de confirmação, escolha **Confirm (Confirmar)** para salvar a seleção.
Depois de definir isso, todos os novos clusters usarão automaticamente o Container Insights com observabilidade aprimorada. Você pode adicionar o Container Insights com observabilidade aprimorada ao cluster existente, ou pode atualizar clusters que atualmente usam o Container Insights para o Container Insights com observabilidade aprimorada. Para obter mais informações, consulte [Atualização de um cluster do Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/update-cluster-v2.html) no *Guia do desenvolvedor do Amazon Elastic Container Service*.
------
## Configurar o Container Insights
Você pode ativar o Container Insights usando o console do Amazon ECS ou a AWS CLI.
------
#### [ AWS CLI ]
Para usar o Container Insights, defina a configuração da conta `container Insights` como `enabled`. Use o comando a seguir para ativar o Container Insights.
```
aws ecs put-account-setting --name containerInsights --value enabled
```
Exemplo de saída
```
{
"setting": {
"name": "container Insights",
"value": "enabled",
"principalArn": "arn:aws:iam::123456789012:johndoe",
"type": user
}
}
```
Ao definir a configuração da conta `container Insights` como `enabled`, todos os novos clusters terão o Container Insights habilitado por padrão. Use o comando `update-cluster-settings` para adicionar o Container Insights a um cluster existente.
```
aws ecs update-cluster-settings --cluster cluster-name --settings name=containerInsights,value=enabled
```
------
#### [ Amazon ECS console ]
1. Abra o console em [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2).
1. Na barra de navegação na parte superior, selecione a região da qual você deseja visualizar as configurações da conta.
1. Na página de navegação, selecione **Account Settings** (Configurações da conta).
1. Selecione **Atualizar**.
1. Para usar o Container Insights, escolha **Container Insights**.
1. Escolha **Salvar alterações**.
1. Na tela de confirmação, escolha **Confirm (Confirmar)** para salvar a seleção.
Depois de definir isso, todos os novos clusters usarão automaticamente o Container Insights. Atualize os clusters existentes para adicionar o Container Insights. Para obter mais informações, consulte [Atualização de um cluster do Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/update-cluster-v2.html) no *Guia do desenvolvedor do Amazon Elastic Container Service*.
------
# Configurar o Container Insights no Amazon ECS usando o AWS Distro for OpenTelemetry
Consulte esta seção para usar o AWS Distro for OpenTelemetry para configurar o CloudWatch Container Insights em um cluster do Amazon ECS. Para obter mais informações sobre o AWS Distro for OpenTelemetry, consulte [AWS Distro for OpenTelemetry](https://aws.amazon.com/otel/).
Estas etapas presumem que você já tenha um cluster executando o Amazon ECS. Para obter mais informações sobre como usar o AWS Distro for Open Telemetry com o Amazon ECS e configurar um cluster do Amazon ECS para essa finalidade, consulte [Configurar o AWS Distro for Open Telemetry Collector no Amazon Elastic Container Service](https://aws-otel.github.io/docs/setup/ecs).
## Etapa 1: Criar uma função de tarefa
A primeira etapa é criar uma função de tarefa no cluster que o AWS Distro for Open Telemetry Collector usará.
**Para criar uma função de tarefa para o AWS Distro for Open Telemetry**
1. Abra o console do IAM em [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/).
1. No painel de navegação, escolha **Policies (Políticas)** e, em seguida, selecione **Create policy (Criar política)**.
1. Selecione a guia **JSON** e copie a política a seguir:
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"logs:PutLogEvents",
"logs:CreateLogGroup",
"logs:CreateLogStream",
"logs:DescribeLogStreams",
"logs:DescribeLogGroups",
"ssm:GetParameters"
],
"Resource": "*"
}
]
}
```
------
1. Selecione **Revisar política**.
1. Para nome, insira **AWSDistroOpenTelemetryPolicy** e escolha **Create policy** (Criar política).
1. No painel de navegação à esquerda, escolha **Roles** (Funções) e **Create role** (Criar função).
1. Na lista de serviços, escolha **Elastic Container Service**.
1. Na parte inferior da página, escolha **Elastic Container Service** e **Next: Permissions** (Próximo: permissões).
1. Na lista de políticas, procure **AWSDistroOpenTelemetryPolicy**.
1. Marque a caixa de seleção ao lado de **AWSDistroOpenTelemetryPolicy**.
1. Escolha **Next: Tags** (Próximo: etiquetas) e **Next: Review** (Próximo: revisar).
1. Em **Role name** (Nome da função), insira **AWSOpenTelemetryTaskRole** e escolha **Create role** (Criar função).
## Etapa 2: Criar uma função de execução de tarefa
A próxima etapa é criar uma função de execução de tarefas para o AWS OpenTelemetry Collector.
**Para criar uma função de execução de tarefa para o AWS Distro for Open Telemetry**
1. Abra o console do IAM em [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/).
1. No painel de navegação à esquerda, escolha **Roles** (Funções) e **Create role** (Criar função).
1. Na lista de serviços, escolha **Elastic Container Service**.
1. Na parte inferior da página, escolha **Elastic Container Service** e **Next: Permissions** (Próximo: permissões).
1. Na lista de políticas, procure **AmazonECSTaskExecutionRolePolicy** e marque a caixa de seleção ao lado de **AmazonECSTaskExecutionRolePolicy**.
1. Na lista de políticas, procure **CloudWatchLogsFullAccess** e marque a caixa de seleção ao lado de **CloudWatchLogsFullAccess**.
1. Na lista de políticas, procure **AmazonSSMReadOnlyAccess** e marque a caixa de seleção ao lado de **AmazonSSMReadOnlyAccess**.
1. Escolha **Next: Tags** (Próximo: etiquetas) e **Next: Review** (Próximo: revisar).
1. Em **Role name** (Nome da função), insira **AWSOpenTelemetryTaskExecutionRole** e escolha **Create role** (Criar função).
## Etapa 3: Criar uma definição de tarefa
A próxima etapa é criar uma definição de tarefa.
**Para criar uma definição de tarefa para o AWS Distro for Open Telemetry**
1. Abra o console em [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2).
1. No painel de navegação, escolha **Task definitions** (Definições de tarefas)
1. Escolha **Create new task definition** (Criar nova definição de tarefa), **Create new task definition** (Criar nova definição de tarefa).
1. Em **Task definition family** (Família de definição de tarefa), especifique um nome exclusivo para a definição de tarefa.
1. Configure seus contêineres e escolha **Avançar**.
1. Em **Métricas e logs**, selecione **Usar coleção de métricas**.
1. Escolha **Próximo**.
1. Escolha **Criar**.
Para obter mais informações sobre como usar o AWS Open Telemetry Collector com o Amazon ECS, consulte [Configurar o AWS Distro for Open Telemetry Collector no Amazon Elastic Container Service](https://aws-otel.github.io/docs/setup/ecs).
## Etapa 4: Executar a tarefa
A etapa final é executar a tarefa que você criou.
**Para executar a tarefa para AWS Distro for OpenTelemetry**
1. Abra o console em [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2).
1. No painel de navegação à esquerda, escolha **Task Definitions** (Definições de tarefa) e selecione a tarefa que você acabou de criar.
1. Escolha **Ações**, **Implantar**, **Executar tarefa**.
1. Escolha **Deploy** (Implantar), **Run task** (Executar tarefa).
1. Na seção **Opções de computação**, em **Cluster existente**, escolha o cluster.
1. Escolha **Criar**.
1. Em seguida, é possível conferir as novas métricas no console do CloudWatch.
1. Abra o console do CloudWatch, em [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).
1. No painel de navegação à esquerda, escolha **Metrics**.
Você deverá ver um namespace **ECS/ContainerInsights**. Escolha esse namespace e verá oito métricas.
# Implantar o atendente do CloudWatch para coletar métricas no nível de instância do EC2 no Amazon ECS
Para implantar o atendente do CloudWatch para coletar métricas no nível de instância de clusters do Amazon ECS hospedados em uma instância do EC2, use uma configuração de início rápido com uma configuração padrão ou instale o atendente manualmente para poder personalizá-lo.
Ambos os métodos exigem que você já tenha, pelo menos, um cluster do Amazon ECS implantado com um tipo de inicialização do EC2 e que o contêiner do agente do CloudWatch tenha acesso ao Instance Metadata Service (IMDS) do EC2. Para obter mais informações sobre o IMDS, consulte [Metadados da instância e dados de usuário](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-metadata.html).
Esses métodos também presumem que a AWS CLI esteja instalada. Além disso, para executar os comandos nos procedimentos a seguir, é necessário estar conectado em uma conta ou em uma função que tenha as políticas **IAMFullAccess** e **AmazonECS\$1FullAccess**.
**Importante**
Ao definir o contêiner do agente do CloudWatch em sua definição de tarefa, configure `essential: false`. Isso evita que todo o serviço do Amazon ECS seja interrompido se o contêiner do agente do CloudWatch falhar. Outros contêineres de aplicações críticas continuarão em execução mesmo se o agente estiver temporariamente indisponível.
**Topics**
+ [Configuração rápida usando o CloudFormation](#deploy-container-insights-ECS-instancelevel-quickstart)
+ [Configuração manual e personalizada](#deploy-container-insights-ECS-instancelevel-manual)
## Configuração rápida usando o CloudFormation
Para usar a configuração rápida, insira o comando a seguir a fim de usar o CloudFormation para instalar o atendente. Substitua *cluster-name* e *cluster-region* pelo nome e pela região de seu cluster do Amazon ECS.
Esse comando cria as funções do IAM **CWAgentECSTaskRole** e **CWAgentECSExecutionRole**. Se essas funções já existirem em sua conta, use `ParameterKey=CreateIAMRoles,ParameterValue=False` em vez de `ParameterKey=CreateIAMRoles,ParameterValue=True` ao inserir o comando. Caso contrário, o comando falhará.
```
ClusterName=cluster-name
Region=cluster-region
curl -O https://raw.githubusercontent.com/aws-samples/amazon-cloudwatch-container-insights/latest/ecs-task-definition-templates/deployment-mode/daemon-service/cwagent-ecs-instance-metric/cloudformation-quickstart/cwagent-ecs-instance-metric-cfn.json
aws cloudformation create-stack --stack-name CWAgentECS-${ClusterName}-${Region} \
--template-body file://cwagent-ecs-instance-metric-cfn.json \
--parameters ParameterKey=ClusterName,ParameterValue=${ClusterName} \
ParameterKey=CreateIAMRoles,ParameterValue=True \
--capabilities CAPABILITY_NAMED_IAM \
--region ${Region}
```
**(Alternativa) Usar suas próprias funções do IAM**
Se quiser usar suas próprias função de tarefa do ECS e função de execução de tarefa do ECS em vez das funções **CWAgentECSTaskRole** e **CWAgentECSExecutionRole**, primeiro verifique se a função que deve ser usada como a função de tarefa do ECS tem a **CloudWatchAgentServerPolicy** anexada. Além disso, verifique se a função a ser usada como função de execução de tarefa do ECS tem as políticas **CloudWatchAgentServerPolicy** e **AmazonECSTaskExecutionRolePolicy** anexadas. Depois, insira o comando a seguir. No comando, substitua *task-role-arn* pelo ARN da função de tarefa do ECS e substitua *execution-role-arn* pelo ARN da função de execução de tarefa do ECS personalizada.
```
ClusterName=cluster-name
Region=cluster-region
TaskRoleArn=task-role-arn
ExecutionRoleArn=execution-role-arn
curl -O https://raw.githubusercontent.com/aws-samples/amazon-cloudwatch-container-insights/latest/ecs-task-definition-templates/deployment-mode/daemon-service/cwagent-ecs-instance-metric/cloudformation-quickstart/cwagent-ecs-instance-metric-cfn.json
aws cloudformation create-stack --stack-name CWAgentECS-${ClusterName}-${Region} \
--template-body file://cwagent-ecs-instance-metric-cfn.json \
--parameters ParameterKey=ClusterName,ParameterValue=${ClusterName} \
ParameterKey=TaskRoleArn,ParameterValue=${TaskRoleArn} \
ParameterKey=ExecutionRoleArn,ParameterValue=${ExecutionRoleArn} \
--capabilities CAPABILITY_NAMED_IAM \
--region ${Region}
```
**Solucionar problemas da configuração rápida**
Para verificar o status da pilha do CloudFormation, insira o comando a seguir.
```
ClusterName=cluster-name
Region=cluster-region
aws cloudformation describe-stacks --stack-name CWAgentECS-$ClusterName-$Region --region $Region
```
Se o `StackStatus` for diferente de `CREATE_COMPLETE` ou de `CREATE_IN_PROGRESS`, verifique os eventos da pilha para localizar o erro. Insira o comando a seguir.
```
ClusterName=cluster-name
Region=cluster-region
aws cloudformation describe-stack-events --stack-name CWAgentECS-$ClusterName-$Region --region $Region
```
Para conferir o status do serviço daemon `cwagent`, insira o comando a seguir. Na saída, `runningCount` deve ser igual a `desiredCount` na seção `deployment`. Se não for igual, verifique a seção `failures` na saída.
```
ClusterName=cluster-name
Region=cluster-region
aws ecs describe-services --services cwagent-daemon-service --cluster $ClusterName --region $Region
```
Também é possível usar o console do CloudWatch Logs para conferir o log do atendente. Procure o grupo de logs **/ecs/ecs-cwagent-daemon-service**.
**Excluir a pilha do CloudFormation do atendente do CloudWatch**
Se for necessário excluir a pilha do CloudFormation, insira o comando a seguir.
```
ClusterName=cluster-name
Region=cluster-region
aws cloudformation delete-stack --stack-name CWAgentECS-${ClusterName}-${Region} --region ${Region}
```
## Configuração manual e personalizada
Siga as etapas desta seção para implantar manualmente o atendente do CloudWatch a fim de coletar métricas no nível de instância dos clusters do Amazon ECS hospedados em instâncias do EC2.
### Funções e políticas do IAM necessárias
São necessárias duas funções do IAM. É necessário criá-las, caso ainda não existam. Para obter mais informações sobre essas funções, consulte [Funções do IAM para tarefas](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-iam-roles.html) e [Função de execução de tarefa do Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task_execution_IAM_role.html).
+ Uma *função de tarefa do ECS*, que é usada pelo atendente do CloudWatch para publicar métricas. Se essa função já existir, será necessário verificar se ela tem a política `CloudWatchAgentServerPolicy` anexada.
+ Uma *função de execução de tarefa do ECS*, que é usada pelo atendente do Amazon ECS para executar o atendente do CloudWatch. Se essa função já existir, será necessário verificar se ela tem as políticas `AmazonECSTaskExecutionRolePolicy` e `CloudWatchAgentServerPolicy` anexadas.
Se ainda não tiver essas funções, você poderá usar os comandos a seguir para criá-las e anexar as políticas necessárias. Este primeiro comando cria a função de tarefa do ECS.
```
aws iam create-role --role-name CWAgentECSTaskRole \
--assume-role-policy-document "{\"Version\": \"2012-10-17\", \"Statement\": [{\"Sid\": \"\",\"Effect\": \"Allow\",\"Principal\": {\"Service\": \"ecs-tasks.amazonaws.com\"},\"Action\": \"sts:AssumeRole\"}]}"
```
Após inserir o comando anterior, anote o valor de `Arn` da saída do comando como "TaskRoleArn". Você precisará usá-lo posteriormente ao criar a definição de tarefa. Depois, insira o comando a seguir para anexar as políticas necessárias.
```
aws iam attach-role-policy --policy-arn arn:aws:iam::aws:policy/CloudWatchAgentServerPolicy \
--role-name CWAgentECSTaskRole
```
Este próximo comando cria a função de execução de tarefa do ECS.
```
aws iam create-role --role-name CWAgentECSExecutionRole \
--assume-role-policy-document "{\"Version\": \"2012-10-17\", \"Statement\": [{\"Sid\": \"\",\"Effect\": \"Allow\",\"Principal\": {\"Service\": \"ecs-tasks.amazonaws.com\"},\"Action\": \"sts:AssumeRole\"}]}"
```
Após inserir o comando anterior, anote o valor de `Arn` da saída do comando como "ExecutionRoleArn". Você precisará usá-lo posteriormente ao criar a definição de tarefa. Depois, insira os comandos a seguir para anexar as políticas necessárias.
```
aws iam attach-role-policy --policy-arn arn:aws:iam::aws:policy/CloudWatchAgentServerPolicy \
--role-name CWAgentECSExecutionRole
aws iam attach-role-policy --policy-arn arn:aws:iam::aws:policy/service-role/AmazonECSTaskExecutionRolePolicy \
--role-name CWAgentECSExecutionRole
```
### Criar a definição de tarefa e iniciar o serviço daemon
Crie uma definição de tarefa e use-a para executar o atendente do CloudWatch como um serviço daemon. Para criar a definição de tarefa, insira o comando a seguir. Nas primeiras linhas, substitua os espaços reservados pelos valores reais da implantação. *logs-region* é a região onde o CloudWatch Logs está localizado e *cluster-region* é a região onde o cluster está localizado. *task-role-arn* é o ARN do perfil da tarefa do ECS que você está usando e *execution-role-arn* é o ARN do perfil de execução de tarefa do ECS.
```
TaskRoleArn=task-role-arn
ExecutionRoleArn=execution-role-arn
AWSLogsRegion=logs-region
Region=cluster-region
curl https://raw.githubusercontent.com/aws-samples/amazon-cloudwatch-container-insights/latest/ecs-task-definition-templates/deployment-mode/daemon-service/cwagent-ecs-instance-metric/cwagent-ecs-instance-metric.json \
| sed "s|{{task-role-arn}}|${TaskRoleArn}|;s|{{execution-role-arn}}|${ExecutionRoleArn}|;s|{{awslogs-region}}|${AWSLogsRegion}|" \
| xargs -0 aws ecs register-task-definition --region ${Region} --cli-input-json
```
Depois, execute o comando a seguir para executar o serviço daemon. Substitua *cluster-name* e *cluster-region* pelo nome e pela região de seu cluster do Amazon ECS.
**Importante**
Remova todas as estratégias do provedor de capacidade antes de executar o comando. Caso contrário, o comando não funcionará.
```
ClusterName=cluster-name
Region=cluster-region
aws ecs create-service \
--cluster ${ClusterName} \
--service-name cwagent-daemon-service \
--task-definition ecs-cwagent-daemon-service \
--scheduling-strategy DAEMON \
--region ${Region}
```
Se esta mensagem de erro for exibida, `An error occurred (InvalidParameterException) when calling the CreateService operation: Creation of service was not idempotent`, é porque você já criou um serviço daemon chamado `cwagent-daemon-service`. Será necessário excluir esse serviço primeiro, usando o comando a seguir como exemplo.
```
ClusterName=cluster-name
Region=cluster-region
aws ecs delete-service \
--cluster ${ClusterName} \
--service cwagent-daemon-service \
--region ${Region} \
--force
```
### (Opcional) Configuração avançada
Se preferir, você poderá usar o SSM para especificar outras opções de configuração para o atendente do CloudWatch nos clusters do Amazon ECS hospedados nas instâncias do EC2. Essas opções são as seguintes:
+ `metrics_collection_interval`? a frequência, em segundos, com a qual o atendente do CloudWatch coleta as métricas. O padrão é 60. O intervalo é de 1 a 172.000.
+ `endpoint_override`: (opcional) especifica um endpoint diferente para o qual enviar logs. Você pode querer fazer isso se estiver publicando de um cluster em uma VPC e quiser que os dados de logs vão para um VPC endpoint.
O valor de `endpoint_override` deve ser uma string que seja um URL.
+ `force_flush_interval`: especifica em segundos a quantidade máxima de tempo em que os logs permanecem no buffer da memória antes de serem enviados ao servidor. Não importa a configuração para esse campo, se o tamanho dos logs no buffer alcançar 1 MB, os logs serão enviados imediatamente para o servidor. O valor de padrão é 5 segundos.
+ `region`: por padrão, o atendente publica métricas na mesma região onde a instância de contêiner do Amazon ECS está localizada. Para substituir isso, é possível especificar uma região diferente aqui. Por exemplo, `"region" : "us-east-1"`
Veja a seguir um exemplo de uma configuração personalizada:
```
{
"agent": {
"region": "us-east-1"
},
"logs": {
"metrics_collected": {
"ecs": {
"metrics_collection_interval": 30
}
},
"force_flush_interval": 5
}
}
```
**Para personalizar a configuração do atendente do CloudWatch nos contêineres do Amazon ECS**
1. Verifique se a política **AmazonSSMReadOnlyAccess** está anexada à função de execução de tarefa do Amazon ECS. É possível inserir o comando a seguir para fazer isso. Esse exemplo pressupõe que a função de execução de tarefa do Amazon ECS seja CWAgentECSExecutionRole. Se você estiver usando uma função diferente, substitua esse nome da função no comando a seguir.
```
aws iam attach-role-policy --policy-arn arn:aws:iam::aws:policy/AmazonSSMReadOnlyAccess \
--role-name CWAgentECSExecutionRole
```
1. Crie o arquivo de configuração personalizada semelhante ao exemplo anterior. Nomeie esse arquivo como `/tmp/ecs-cwagent-daemon-config.json`.
1. Execute o comando a seguir para colocar essa configuração no Parameter Store. Substitua *cluster-region* pela região do cluster do Amazon ECS. Para executar esse comando, é necessário estar conectado a um usuário ou a uma função que tenha a política **AmazonSSMFullAccess**.
```
Region=cluster-region
aws ssm put-parameter \
--name "ecs-cwagent-daemon-service" \
--type "String" \
--value "`cat /tmp/ecs-cwagent-daemon-config.json`" \
--region $Region
```
1. Faça download do arquivo de definição de tarefa em um arquivo local, como . `/tmp/cwagent-ecs-instance-metric.json`
```
curl https://raw.githubusercontent.com/aws-samples/amazon-cloudwatch-container-insights/latest/ecs-task-definition-templates/deployment-mode/daemon-service/cwagent-ecs-instance-metric/cwagent-ecs-instance-metric.json -o /tmp/cwagent-ecs-instance-metric.json
```
1. Modifique o arquivo de definição de tarefa. Remova a seguinte seção:
```
"environment": [
{
"name": "USE_DEFAULT_CONFIG",
"value": "True"
}
],
```
Substitua essa seção pela seguinte:
```
"secrets": [
{
"name": "CW_CONFIG_CONTENT",
"valueFrom": "ecs-cwagent-daemon-service"
}
],
```
1. Reinicie o atendente como um serviço daemon seguindo estas etapas:
1. Execute o comando a seguir.
```
TaskRoleArn=task-role-arn
ExecutionRoleArn=execution-role-arn
AWSLogsRegion=logs-region
Region=cluster-region
cat /tmp/cwagent-ecs-instance-metric.json \
| sed "s|{{task-role-arn}}|${TaskRoleArn}|;s|{{execution-role-arn}}|${ExecutionRoleArn}|;s|{{awslogs-region}}|${AWSLogsRegion}|" \
| xargs -0 aws ecs register-task-definition --region ${Region} --cli-input-json
```
1. Execute o comando a seguir para executar o serviço daemon. Substitua *cluster-name* e *cluster-region* pelo nome e pela região de seu cluster do Amazon ECS.
```
ClusterName=cluster-name
Region=cluster-region
aws ecs create-service \
--cluster ${ClusterName} \
--service-name cwagent-daemon-service \
--task-definition ecs-cwagent-daemon-service \
--scheduling-strategy DAEMON \
--region ${Region}
```
Se esta mensagem de erro for exibida, `An error occurred (InvalidParameterException) when calling the CreateService operation: Creation of service was not idempotent`, é porque você já criou um serviço daemon chamado `cwagent-daemon-service`. Será necessário excluir esse serviço primeiro, usando o comando a seguir como exemplo.
```
ClusterName=cluster-name
Region=Region
aws ecs delete-service \
--cluster ${ClusterName} \
--service cwagent-daemon-service \
--region ${Region} \
--force
```
# Implantar o AWS Distro for OpenTelemetry para coletar métricas no nível de instância do EC2 em clusters do Amazon ECS
Realize as etapas desta seção para usar o AWS Distro for OpenTelemetry para coletar métricas no nível de instância do EC2 em clusters do Amazon ECS. Para obter mais informações sobre o AWS Distro for OpenTelemetry, consulte [AWS Distro for OpenTelemetry](https://aws.amazon.com/otel/).
Estas etapas presumem que você já tenha um cluster executando o Amazon ECS. Esse cluster deve ser implantado com o tipo de inicialização EC2. Para obter mais informações sobre como usar o AWS Distro for Open Telemetry com o Amazon ECS e configurar um cluster do Amazon ECS para essa finalidade, consulte [Configurar o AWS Distro for Open Telemetry Collector no Amazon Elastic Container Service para métricas no nível da instância do EC2 no ECS](https://aws-otel.github.io/docs/setup/ecs#3-setup-the-aws-otel-collector-for-ecs-ec2-instance-metrics).
**Topics**
+ [Configuração rápida usando o CloudFormation](#container-insights-ECS-OTEL-quicksetup)
+ [Configuração manual e personalizada](#container-insights-ECS-OTEL-custom)
## Configuração rápida usando o CloudFormation
Baixe o arquivo de modelo do CloudFormation para instalar o AWS Distro for OpenTelemetry Colector para o Amazon ECS no EC2. Execute o comando curl a seguir.
```
curl -O https://raw.githubusercontent.com/aws-observability/aws-otel-collector/main/deployment-template/ecs/aws-otel-ec2-instance-metrics-daemon-deployment-cfn.yaml
```
Depois de baixar o arquivo de modelo, abra-o e substitua *PATH\$1TO\$1CloudFormation\$1TEMPLATE* pelo caminho onde você salvou o arquivo de modelo. Em seguida, exporte os seguintes parâmetros e execute o comando CloudFormation, conforme mostrado no comando a seguir.
+ **Cluster\$1Name**: o nome do cluster do Amazon ECS
+ **AWS\$1Region**: a região para onde os dados serão enviados
+ **PATH\$1TO\$1CloudFormation\$1TEMPLATE**: o caminho onde você salvou o arquivo de modelo do CloudFormation.
+ **command**: para habilitar o AWS Distro for OpenTelemetry Collector para coletar as métricas no nível de instância do Amazon ECS no Amazon EC2, é necessário especificar `--config=/etc/ecs/otel-instance-metrics-config.yaml` para este parâmetro.
```
ClusterName=Cluster_Name
Region=AWS_Region
command=--config=/etc/ecs/otel-instance-metrics-config.yaml
aws cloudformation create-stack --stack-name AOCECS-${ClusterName}-${Region} \
--template-body file://PATH_TO_CloudFormation_TEMPLATE \
--parameters ParameterKey=ClusterName,ParameterValue=${ClusterName} \
ParameterKey=CreateIAMRoles,ParameterValue=True \
ParameterKey=command,ParameterValue=${command} \
--capabilities CAPABILITY_NAMED_IAM \
--region ${Region}
```
Depois de executar este comando, use o console do Amazon ECS para ver se a tarefa está em execução.
### Solucionar problemas da configuração rápida
Para verificar o status da pilha do CloudFormation, insira o comando a seguir.
```
ClusterName=cluster-name
Region=cluster-region
aws cloudformation describe-stack --stack-name AOCECS-$ClusterName-$Region --region $Region
```
Se o valor de `StackStatus` for diferente de `CREATE_COMPLETE` ou de `CREATE_IN_PROGRESS`, verifique os eventos da pilha para localizar o erro. Insira o comando a seguir.
```
ClusterName=cluster-name
Region=cluster-region
aws cloudformation describe-stack-events --stack-name AOCECS-$ClusterName-$Region --region $Region
```
Para conferir o status do serviço daemon `AOCECS`, insira o comando a seguir. Na saída, é necessário verificar se `runningCount` é igual a `desiredCount` na seção de implantação. Se não for igual, confira a seção de falhas na saída.
```
ClusterName=cluster-name
Region=cluster-region
aws ecs describe-services --services AOCECS-daemon-service --cluster $ClusterName --region $Region
```
Também é possível usar o console do CloudWatch Logs para conferir o log do atendente. Procure o grupo de logs **/aws/ecs/containerinsights/\$1ClusterName\$1/performance**.
## Configuração manual e personalizada
Siga as etapas desta seção para implantar manualmente o AWS Distro for OpenTelemetry a fim de coletar métricas no nível de instância dos clusters do Amazon ECS hospedados em instâncias do Amazon EC2.
### Etapa 1: Funções e políticas do IAM necessárias
São necessárias duas funções do IAM. É necessário criá-las, caso ainda não existam. Para obter mais informações sobre essas funções, consulte [Criar política do IAM](https://aws-otel.github.io/docs/setup/ecs/create-iam-policy) e [Criar função do IAM](https://aws-otel.github.io/docs/setup/ecs/create-iam-role).
### Etapa 2: Criar uma definição de tarefa
Crie uma definição de tarefa e use-a para iniciar o atendente do AWS Distro for OpenTelemetry como um serviço daemon.
Para usar o modelo de definição de tarefa para criar a definição de tarefa, siga as instruções em [Criar definição de tarefa do ECS EC2 para instância do EC2 com AWS OTel Collector](https://aws-otel.github.io/docs/setup/ecs/task-definition-for-ecs-ec2-instance).
Para usar o console do Amazon ECS para criar a definição de tarefa, siga as instruções em [Instalar AWS OTel Collector criando definição de rarefas pelo Console AWS para métricas de instância do EC2 no Amazon ECS](https://aws-otel.github.io/docs/setup/ecs/create-task-definition-instance-console).
### Etapa 3: Iniciar o serviço daemon
Para iniciar o AWS Distro para OpenTeemetry como um serviço daemon, siga as instruções em [Executar tarefa no Amazon Elastic Container Service (Amazon ECS) usando o serviço daemon](https://aws-otel.github.io/docs/setup/ecs/run-daemon-service).
### (Opcional) Configuração avançada
Se preferir, você poderá usar o SSM para especificar outras opções de configuração para o AWS Distro for OpenTelemetry nos clusters do Amazon ECS hospedados nas instâncias do Amazon EC2. Para obter mais informações sobre como criar um arquivo de configuração, consulte [Configuração personalizada do OpenTelemetry](https://aws-otel.github.io/docs/setup/ecs#5-custom-opentelemetry-configuration). Para obter mais informações sobre as opções que você pode usar no arquivo de configuração, consulte [Receptor do AWS Container Insights](https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/receiver/awscontainerinsightreceiver/README.md).
# Configurar o FireLens para enviar logs ao CloudWatch Logs
O FireLens para Amazon ECS permite usar parâmetros de definição de tarefa para rotear logs para o Amazon CloudWatch Logs para armazenamento e analytics de logs. O FireLens funciona com [Fluent Bit](https://fluentbit.io/) e [Fluentd](https://www.fluentd.org/). Fornecemos a imagem da AWS for Fluent Bit ou é possível usar sua própria imagem do Fluent Bit ou Fluentd. Criar definições de tarefa do Amazon ECS com uma configuração do FireLens tem suporte usando os AWS SDKs, AWS CLI e Console de gerenciamento da AWS. Para obter mais informações sobre o CloudWatch Logs, consulte [O que é o Amazon CloudWatch Logs?](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html).
Há considerações importantes ao usar o FireLens for Amazon ECS. Para obter mais informações, consulte [Considerações](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/using_firelens.html#firelens-considerations).
Para encontrar imagens da AWS for Fluent Bit, consulte[ Usar a imagem da AWS for Fluent Bit](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/firelens-using-fluentbit.html).
Para criar uma definição de tarefa que usa uma configuração do FireLens, consulte [Como criar uma definição de tarefa que usa uma configuração do FireLens](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/firelens-taskdef.html).
**Exemplo**
O exemplo de definição de tarefa a seguir mostra como especificar uma configuração de log que encaminha logs a um grupo de logs do CloudWatch Logs. Para obter mais informações, consulte [O que é o Amazon CloudWatch Logs?](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html) no *Guia do usuário do Amazon CloudWatch Logs*.
Nas opções de configuração de log, especifique o nome do grupo de logs e a região em que ele existe. Para que o Fluent Bit crie o grupo de logs em seu nome, especifique `"auto_create_group":"true"`. Também é possível especificar o ID da tarefa como o prefixo de fluxo de log que auxilia na filtragem. Para obter mais informações, consulte [Plugin do Fluent Bit para CloudWatch Logs](https://github.com/aws/amazon-cloudwatch-logs-for-fluent-bit/blob/mainline/README.md).
```
{
"family": "firelens-example-cloudwatch",
"taskRoleArn": "arn:aws:iam::123456789012:role/ecs_task_iam_role",
"containerDefinitions": [
{
"essential": true,
"image": "906394416424.dkr.ecr.us-west-2.amazonaws.com/aws-for-fluent-bit:latest",
"name": "log_router",
"firelensConfiguration": {
"type": "fluentbit"
},
"logConfiguration": {
"logDriver": "awslogs",
"options": {
"awslogs-group": "firelens-container",
"awslogs-region": "us-west-2",
"awslogs-create-group": "true",
"awslogs-stream-prefix": "firelens"
}
},
"memoryReservation": 50
},
{
"essential": true,
"image": "nginx",
"name": "app",
"logConfiguration": {
"logDriver":"awsfirelens",
"options": {
"Name": "cloudwatch_logs",
"region": "us-west-2",
"log_key": "log",
"log_group_name": "/aws/ecs/containerinsights/my-cluster/application",
"auto_create_group": "true",
"log_stream_name": "my-task-id"
}
},
"memoryReservation": 100
}
]
}
```
# Configurar o Container Insights no Amazon EKS e no Kubernetes
Há suporte para o Container Insights nas versões 1.23 e posteriores do Amazon EKS. Há suporte para o método de início rápido da instalação somente nas versões 1.24 e posteriores.
O processo geral para configurar o Container Insights no Amazon EKS ou no Kubernetes é o seguinte:
1. Verifique se você tem os pré-requisitos necessários.
1. Configure o complemento de observabilidade do EKS do Amazon CloudWatch, o agente do CloudWatch ou o AWS Distro para OpenTelemetry em seu cluster para enviar métricas ao CloudWatch.
**nota**
Para usar o Container Insights com observabilidade aprimorada para o Amazon EKS, você deve usar o complemento de observabilidade do EKS do Amazon CloudWatch ou o agente do CloudWatch. Para obter mais informações sobre esta versão do Container Insights, consulte [Container Insights com observabilidade aprimorada para o Amazon EKS](container-insights-detailed-metrics.md).
Para usar o Container Insights com o Fargate, você deve usar o AWS Distro para OpenTelemetry. O Container Insights com observabilidade aprimorada para o Amazon EKS não é compatível com o Fargate.
**nota**
Agora, o Container Insights é compatível com nós de processamento do Windows em um cluster do Amazon EKS. Além disso, o Container Insights com observabilidade aprimorada para o Amazon EKS é compatível com o sistema Windows. Para obter informações sobre como habilitar o Container Insights no Windows, consulte [Como usar o agente do CloudWatch com observabilidade aprimorada do Container Insights ativada](Container-Insights-EKS-agent.md).
Para usar o Container Insights com as métricas do OpenTelemetry, instale o complemento de observabilidade do EKS do Amazon CloudWatch, versão `v6.0.1-eksbuild.1` ou posterior. Para obter mais informações, consulte [Métricas do Container Insights com OpenTelemetry para Amazon EKS](container-insights-otel-metrics.md).
Configure o Fluent Bit ou o Fluentd para enviar logs ao CloudWatch Logs. (Isso ficará ativado por padrão se você instalar o complemento de observabilidade do EKS do Amazon CloudWatch.)
Você pode executar essas etapas de uma só vez como parte da configuração de início rápido, se estiver usando o atendente do CloudWatch, ou executá-las de forma separada.
1. (Opcional) Configure o registro do ambiente de gerenciamento do Amazon EKS.
1. (Opcional) Configure o atendente do CloudWatch como um endpoint do StatsD no cluster para enviar métricas do StatsD ao CloudWatch.
1. (Opcional) Habilite logs de acesso do App Mesh Envoy.
Com a versão original do Container Insights, as métricas coletadas e os registros ingeridos são cobrados como métricas personalizadas. Com o Container Insights com observabilidade aprimorada para o Amazon EKS, as métricas e os logs do Container Insights são cobrados por observação em vez de serem cobrados por métrica armazenada ou log ingerido. Para obter mais informações sobre os preços do CloudWatch, consulte [Preço do Amazon CloudWatch](https://aws.amazon.com/cloudwatch/pricing/).
**Topics**
+ [Verificação dos pré-requisitos para o Container Insights no CloudWatch](Container-Insights-prerequisites.md)
+ [Como usar o agente do CloudWatch com observabilidade aprimorada do Container Insights ativada](Container-Insights-EKS-agent.md)
+ [Usar o AWS Distro for OpenTelemetry](Container-Insights-EKS-otel.md)
+ [Enviar logs ao CloudWatch Logs](Container-Insights-EKS-logs.md)
+ [Atualizar ou excluir o Container Insights no Amazon EKS e no Kubernetes](ContainerInsights-update-delete.md)
# Verificação dos pré-requisitos para o Container Insights no CloudWatch
Antes de instalar o Container Insights no Amazon EKS ou no Kubernetes, verifique os pré-requisitos a seguir. Esses pré-requisitos se aplicam tanto se você usar o atendente do CloudWatch ou o AWS Distro for OpenTelemetry para configurar o Container Insights em clusters do Amazon EKS.
+ Você tem um cluster funcional do Amazon EKS ou do Kubernetes com nós anexados em uma das regiões que oferecem suporte ao Container Insights ao Amazon EKS e ao Kubernetes. Para obter a lista de regiões compatíveis, consulte [Container Insights](ContainerInsights.md).
+ Você tem `kubectl` instalado e em execução. Para obter mais informações, consulte [Instalar o `kubectl`](https://docs.aws.amazon.com/eks/latest/userguide/install-kubectl.html) no *Manual do usuário do Amazon EKS*.
+ Se você estiver usando o Kubernetes em execução na AWS, em vez de usar o Amazon EKS, os seguintes pré-requisitos também serão necessários:
+ Certifique-se de que o cluster do Kubernetes habilitou o controle de acesso baseado em funções (RBAC). Para obter mais informações, consulte [Usar a autorização de RBAC](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) (em inglês) na Referência do Kubernetes.
+ Seu kubelet habilitou o modo de autorização Webhook. Para obter mais informações, consulte [Autenticação/autorização do Kubelet](https://kubernetes.io/docs/reference/access-authn-authz/kubelet-authn-authz/) (em inglês) na Referência do Kubernetes.
Você também deve conceder permissões do IAM para permitir que seus nós de processamento do Amazon EKS enviem métricas e logs ao CloudWatch. Há duas maneiras de fazer isso:
+ Anexe uma política à função do IAM dos nós de processamento. Isso funciona tanto para clusters do Amazon EKS quanto para outros clusters do Kubernetes.
+ Utilize uma função do IAM para contas de serviço para o cluster e anexe a política a essa função. Funciona somente para clusters do Amazon EKS.
A primeira opção concede permissões ao CloudWatch para o nó inteiro, enquanto o uso de uma função do IAM para a conta de serviço dá acesso ao CloudWatch somente aos pods do daemonset apropriados.
**Anexar uma política à função do IAM de seus nós de processamento**
Siga estas etapas para anexar a política à função do IAM dos nós de processamento. Isso funciona tanto para clusters do Amazon EKS como para clusters do Kubernetes fora do Amazon EKS.
**Como adicionar a política necessária à função do IAM para os nós de processamento**
1. Abra o console do Amazon EC2 em [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/).
1. Selecione uma das instâncias do nó de processamento e escolha a função do IAM na descrição.
1. Na página da função do IAM, selecione **Attach policies** (Anexar políticas).
1. Na lista de políticas, marque a caixa de seleção ao lado de **CloudWatchAgentServerPolicy**. Se necessário, use a caixa de pesquisa para encontrar essa política.
1. Escolha **Anexar políticas**.
Se você estiver executando um cluster do Kubernetes fora do Amazon EKS, talvez você não tenha uma função do IAM anexada a seus nós de processamento. Caso contrário, primeiro anexe uma função do IAM à instância e adicione a política conforme explicado nas etapas anteriores. Para obter mais informações sobre como anexar um perfil a uma instância, consulte [Anexar um perfil do IAM a uma instância](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/iam-roles-for-amazon-ec2.html#attach-iam-role) no *Guia do usuário do Amazon EC2*.
Se estiver executando um cluster do Kubernetes fora do Amazon EKS e quiser coletar IDs de volumes do EBS nas métricas. você deverá adicionar outra política à função do IAM anexada à instância. Adicione o seguinte como uma política em linha. Para obter mais informações, consulte [Adicionar e remover permissões de identidade do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-attach-detach.html) no *Manual do usuário do IAM*.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": [
"ec2:DescribeVolumes"
],
"Resource": "*",
"Effect": "Allow"
}
]
}
```
------
**Usar uma função de conta de serviço do IAM**
Esse método funciona somente em clusters do Amazon EKS.
**Para conceder permissão para o CloudWatch usar uma função de conta de serviço do IAM**
1. Caso ainda não tenha feito isso, habilite as funções do IAM para contas de serviço no cluster. Para obter mais informações, consulte [Habilitar funções do IAM para contas de serviço em seu cluster ](https://docs.aws.amazon.com/eks/latest/userguide/enable-iam-roles-for-service-accounts.html).
1. Caso ainda não tenha configurado, configure a conta de serviço para usar o perfil do IAM. Para obter mais informações, consulte [Configuração de uma conta de serviço do Kubernetes para assumir um perfil do IAM](https://docs.aws.amazon.com/eks/latest/userguide/associate-service-account-role.html).
Ao criar a função, anexe a política do IAM **CloudWatchAgentServerPolicy** à função, além da política que você criar para a função. Além disso, a conta de serviço do Kubernetes associada que está vinculada a essa função deve ser criada no namespace do `amazon-cloudwatch`, no qual os daemonsets do CloudWatch e do Fluent Bit serão implantados nas próximas etapas.
1. Associe a função do IAM a uma conta de serviço no cluster, se ainda não tiver feito isso. Para obter mais informações, consulte [Configuração de uma conta de serviço do Kubernetes para assumir um perfil do IAM](https://docs.aws.amazon.com/eks/latest/userguide/associate-service-account-role.html).
# Como usar o agente do CloudWatch com observabilidade aprimorada do Container Insights ativada
Use as instruções em uma das seções a seguir para configurar o Container Insights em um cluster do Amazon EKS ou do Kubernetes usando o agente do CloudWatch. Há suporte para as instruções de início rápido somente nas versões 1.24 e posteriores do Amazon EKS.
**nota**
Você pode instalar o Container Insights seguindo as instruções em qualquer uma das seções a seguir. Não é necessário seguir todos os três conjuntos de instruções.
**Topics**
+ [Introdução ao complemento Amazon CloudWatch Observability do EKS](Container-Insights-setup-EKS-addon.md)
+ [Configuração de início rápido para o Container Insights no Amazon EKS e no Kubernetes](Container-Insights-setup-EKS-quickstart.md)
+ [Configuração do agente do CloudWatch para a coleta de métricas do cluster](Container-Insights-setup-metrics.md)
# Introdução ao complemento Amazon CloudWatch Observability do EKS
Você pode usar o complemento do EKS da Amazon para instalar o Container Insights com observabilidade aprimorada para o Amazon EKS. O complemento instala o agente do CloudWatch para enviar as métricas de infraestrutura do cluster, instala o Fluent Bit para enviar os logs de contêiner, e também habilita que o CloudWatch [Application Signals](CloudWatch-Application-Monitoring-Sections.md) envie a telemetria de performance para as aplicações.
Quando você usa o complemento do Amazon EKS na versão 1.5.0 ou em versões posteriores, o Container Insights é habilitado nos nós de processamento do Linux e do Windows no cluster. O Application Signals não é compatível com o sistema Windows no Amazon EKS.
O complemento do Amazon EKS não é compatível com clusters que executam o Kubernetes em vez do Amazon EKS.
Para obter mais informações sobre o complemento de observabilidade do EKS do Amazon CloudWatch, consulte [Instalação do agente do CloudWatch com o complemento de observabilidade do EKS do Amazon CloudWatch ou com o chart do Helm](install-CloudWatch-Observability-EKS-addon.md).
Se você usa a versão 3.1.0 ou posterior do complemento, pode usar a Identidade de Pods do EKS para conceder as permissões necessárias ao complemento. A Identidade de Pods do EKS é a opção recomendada e oferece benefícios como privilégio mínimo, alternância de credenciais e auditabilidade. Além disso, o uso da Identidade de Pods do EKS permite instalar o complemento do EKS como parte da própria criação do cluster.
**Como instalar o complemento Amazon CloudWatch Observability do EKS**
1. Siga as etapas de [Associação da Identidade de Pods do EKS](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-association.html#pod-id-association-create/) para criar o perfil do IAM e configurar o agente da Identidade de Pods do EKS.
1. Anexe uma política do IAM que conceda as permissões necessárias ao seu perfil. Substitua *my-role* pelo nome do seu perfil do IAM da etapa anterior.
```
aws iam attach-role-policy \
--role-name my-role \
--policy-arn=arn:aws:iam::aws:policy/CloudWatchAgentServerPolicy
```
1. Insira o comando a seguir, usando o perfil do IAM que você criou na etapa anterior:
```
aws eks create-addon \
--addon-name amazon-cloudwatch-observability \
--cluster-name my-cluster-name \
--pod-identity-associations serviceAccount=cloudwatch-agent,roleArn=arn:aws:iam::111122223333:role/my-role
```
# Configuração de início rápido para o Container Insights no Amazon EKS e no Kubernetes
**Importante**
Se estiver instalando o Container Insights em um cluster do Amazon EKS, recomendamos que use o complemento de observabilidade do EKS do Amazon CloudWatch para a instalação em vez de usar as instruções desta seção. Além disso, para recuperar redes com computação acelerada, use o complemento Amazon CloudWatch Observability EKS. Para obter mais informações e instruções, consulte [Introdução ao complemento Amazon CloudWatch Observability do EKS](Container-Insights-setup-EKS-addon.md).
Para concluir a configuração do Container Insights, siga as instruções de início rápido nesta seção. Se estiver instalando em um cluster do Amazon EKS e usar as instruções desta seção em ou após 6 de novembro de 2023, você instalará o Container Insights com observabilidade aprimorada para o Amazon EKS no cluster.
**Importante**
Antes de executar as etapas desta seção, você deve ter verificado os pré-requisitos, inclusive as permissões do IAM. Para obter mais informações, consulte [Verificação dos pré-requisitos para o Container Insights no CloudWatch](Container-Insights-prerequisites.md).
Como alternativa, você pode seguir as instruções nas duas seções a seguir, [Configuração do agente do CloudWatch para a coleta de métricas do cluster](Container-Insights-setup-metrics.md) e [Enviar logs ao CloudWatch Logs](Container-Insights-EKS-logs.md). Essas seções fornecem mais detalhes sobre como o atendente do CloudWatch funciona com o Amazon EKS e o Kubernetes, mas necessitam que você execute mais etapas de instalação.
Com a versão original do Container Insights, as métricas coletadas e os registros ingeridos são cobrados como métricas personalizadas. Com o Container Insights com observabilidade aprimorada para o Amazon EKS, as métricas e os logs do Container Insights são cobrados por observação em vez de serem cobrados por métrica armazenada ou log ingerido. Para obter mais informações sobre os preços do CloudWatch, consulte [Preço do Amazon CloudWatch](https://aws.amazon.com/cloudwatch/pricing/).
**nota**
A Amazon agora lançou o Fluent Bit como a solução de log padrão para o Container Insights com ganhos consideráveis de performance. Recomendamos usar o Fluent Bit em vez do Fluentd.
## Início rápido ao usar o operador do agente do CloudWatch e o Fluent Bit
Existem duas configurações para Fluent Bit: uma versão otimizada e uma versão que fornece uma experiência mais semelhante ao Fluentd. A configuração de início rápido usa a versão otimizada. Para obter mais detalhes sobre a configuração compatível com o Fluentd, consulte [Configurar o Fluent Bit como um DaemonSet para enviar logs ao CloudWatch Logs](Container-Insights-setup-logs-FluentBit.md).
O operador do agente do CloudWatch corresponde a um contêiner adicional instalado em um cluster do Amazon EKS. Ele é modelado de acordo com o Operador do OpenTelemetry para Kubernetes. O operador gerencia o ciclo de vida útil dos recursos do Kubernetes em um cluster. Ele instala o agente do CloudWatch, a ferramenta DCGM Exporter (NVIDIA) e o monitor do AWS Neuron em um cluster do Amazon EKS e os gerencia. O Fluent Bit e o agente do CloudWatch para Windows são instalados diretamente em um cluster do Amazon EKS sem a necessidade de que o operador os gerencie.
Para obter uma solução de autoridade de certificação mais segura e repleta de funcionalidades, o operador do agente do CloudWatch requer o cert-manager, uma solução amplamente adotada para o gerenciamento de certificados TLS no Kubernetes. Usar o cert-manager simplifica o processo de obtenção, renovação, gerenciamento e uso desses certificados. Ele garante que os certificados sejam válidos e atualizados, bem como tenta renovar os certificados em um momento configurado antes da expiração. O cert-manager também facilita a emissão de certificados de diversas fontes com suporte, incluindo o AWS Certificate Manager Private Certificate Authority.
**Como implantar o Container Insights usando o início rápido**
1. Instale o cert-manager se ele ainda não estiver instalado no cluster. Para obter mais informações, consulte [cert-manager Installation](https://cert-manager.io/docs/installation/).
1. Instale as definições de recursos personalizados (CRD) ao inserir o comando apresentado a seguir.
```
curl https://raw.githubusercontent.com/aws-samples/amazon-cloudwatch-container-insights/main/k8s-quickstart/cwagent-custom-resource-definitions.yaml | kubectl apply --server-side -f -
```
1. Instale o operador ao inserir o comando apresentado a seguir. Substitua *my-cluster-name* pelo nome do cluster do Amazon EKS ou do Kubernetes e *my-cluster-region* pelo nome da região em que os logs são publicados. Recomendamos usar a mesma região em que o cluster está implantado para reduzir os custos de transferência de dados de saída da AWS.
```
ClusterName=my-cluster-name
RegionName=my-cluster-region
curl https://raw.githubusercontent.com/aws-samples/amazon-cloudwatch-container-insights/main/k8s-quickstart/cwagent-operator-rendered.yaml | sed 's/{{cluster_name}}/'${ClusterName}'/g;s/{{region_name}}/'${RegionName}'/g' | kubectl apply -f -
```
Por exemplo, para implantar o Container Insights no cluster chamado `MyCluster` e publicar os logs e as métricas em Oeste dos EUA (Oregon), insira o comando a seguir.
```
ClusterName='MyCluster'
RegionName='us-west-2'
curl https://raw.githubusercontent.com/aws-samples/amazon-cloudwatch-container-insights/main/k8s-quickstart/cwagent-operator-rendered.yaml | sed 's/{{cluster_name}}/'${ClusterName}'/g;s/{{region_name}}/'${RegionName}'/g' | kubectl apply -f -
```
**Migrar do Container Insights**
Se você já tiver o Container Insights configurado em um cluster do Amazon EKS e desejar realizar a migração para o Container Insights com observabilidade aprimorada para o Amazon EKS, consulte [Atualização para o Container Insights com observabilidade aprimorada para o Amazon EKS no CloudWatch](Container-Insights-upgrade-enhanced.md).
**Excluir o Container Insights**
Se você quiser remover o Container Insights depois de usar a configuração de início rápido, insira os comandos apresentados a seguir.
```
ClusterName=my-cluster-name
RegionName=my-cluster-region
curl https://raw.githubusercontent.com/aws-samples/amazon-cloudwatch-container-insights/main/k8s-quickstart/cwagent-operator-rendered.yaml | sed 's/{{cluster_name}}/'${ClusterName}'/g;s/{{region_name}}/'${RegionName}'/g' | kubectl delete -f -
curl https://raw.githubusercontent.com/aws-samples/amazon-cloudwatch-container-insights/main/k8s-quickstart/cwagent-custom-resource-definitions.yaml | kubectl delete -f -
```
# Configuração do agente do CloudWatch para a coleta de métricas do cluster
**Importante**
Se estiver instalando o Container Insights em um cluster do Amazon EKS, recomendamos que use o complemento de observabilidade do EKS do Amazon CloudWatch para a instalação em vez de usar as instruções desta seção. Para obter mais informações e instruções, consulte [Introdução ao complemento Amazon CloudWatch Observability do EKS](Container-Insights-setup-EKS-addon.md).
Para configurar o Container Insights para coletar métricas, siga as etapas em [Configuração de início rápido para o Container Insights no Amazon EKS e no Kubernetes](Container-Insights-setup-EKS-quickstart.md) ou siga as etapas nesta seção. Nas etapas a seguir, você configura o atendente do CloudWatch para ser capaz de coletar métricas dos clusters.
Se estiver instalando em um cluster do Amazon EKS e usar as instruções desta seção em ou após 6 de novembro de 2023, você instalará o Container Insights com observabilidade aprimorada para o Amazon EKS no cluster.
## Etapa 1: Criar um namespace para o CloudWatch
Use a seguinte etapa para criar um namespace do Kubernetes chamado `amazon-cloudwatch` para o CloudWatch. Ignore essas etapas se você já tiver criado esse namespace.
**Para criar um namespace para o CloudWatch**
+ Insira o comando a seguir.
```
kubectl apply -f https://raw.githubusercontent.com/aws-samples/amazon-cloudwatch-container-insights/latest/k8s-deployment-manifest-templates/deployment-mode/daemonset/container-insights-monitoring/cloudwatch-namespace.yaml
```
## Etapa 2: Criar uma conta de serviço no cluster
Aplique um dos métodos a seguir para criar uma conta de serviço para o agente do CloudWatch, se ainda não tiver uma.
+ Use `kubectl`
+ Usar um arquivo `kubeconfig`
### Usar `kubectl` para autenticação
**Para usar `kubectl` para criar uma conta de serviço para o agente do CloudWatch**
+ Insira o comando a seguir.
```
kubectl apply -f https://raw.githubusercontent.com/aws-samples/amazon-cloudwatch-container-insights/latest/k8s-deployment-manifest-templates/deployment-mode/daemonset/container-insights-monitoring/cwagent/cwagent-serviceaccount.yaml
```
Se você não seguiu as etapas anteriores, mas já tem uma conta de serviço para o atendente do CloudWatch que deseja usar, deve garantir que ela tenha as regras a seguir. Além disso, no restante das etapas da instalação do Container Insights, você deve usar o nome da conta de serviço em vez de `cloudwatch-agent`.
```
rules:
- apiGroups: [""]
resources: ["pods", "nodes", "endpoints"]
verbs: ["list", "watch"]
- apiGroups: [ "" ]
resources: [ "services" ]
verbs: [ "list", "watch" ]
- apiGroups: ["apps"]
resources: ["replicasets", "daemonsets", "deployments", "statefulsets"]
verbs: ["list", "watch"]
- apiGroups: ["batch"]
resources: ["jobs"]
verbs: ["list", "watch"]
- apiGroups: [""]
resources: ["nodes/proxy"]
verbs: ["get"]
- apiGroups: [""]
resources: ["nodes/stats", "configmaps", "events"]
verbs: ["create", "get"]
- apiGroups: [""]
resources: ["configmaps"]
resourceNames: ["cwagent-clusterleader"]
verbs: ["get","update"]
- nonResourceURLs: ["/metrics"]
verbs: ["get", "list", "watch"]
- apiGroups: [ "discovery.k8s.io" ]
resources: [ "endpointslices" ]
verbs: [ "list", "watch", "get" ]
```
### Usar `kubeconfig` para autenticação
Também é possível usar um arquivo `kubeconfig` para autenticação. Esse método permite que você contorne a necessidade de uma conta de serviço ao especificar diretamente o caminho de `kubeconfig` na configuração do seu agente do CloudWatch. Ele também permite que você remova sua dependência da API de ambiente de gerenciamento do Kubernetes para autenticação, simplificando sua configuração e aumentando potencialmente a segurança ao gerenciar a autenticação por meio de seu arquivo kubeconfig.
Para usar esse método, atualize o arquivo de configuração do agente do CloudWatch para especificar o caminho para o arquivo `kubeconfig`, como no exemplo a seguir.
```
{
"logs": {
"metrics_collected": {
"kubernetes": {
"cluster_name": "YOUR_CLUSTER_NAME",
"enhanced_container_insights": false,
"accelerated_compute_metrics": false,
"tag_service": false,
"kube_config_path": "/path/to/your/kubeconfig"
"host_ip": "HOSTIP"
}
}
}
}
```
Para criar um arquivo `kubeconfig`, crie uma Solicitação de Assinatura de Certificado (CSR) para o usuário `admin/{create_your_own_user}` com a função `system:masters` do Kubernetes. Em seguida, assine com a Autoridade Certificadora (CA) do cluster Kubernetes e crie o arquivo `kubeconfig`.
## Etapa 3: Criar um ConfigMap para o atendente do CloudWatch
Siga as etapas a seguir para criar um ConfigMap para o atendente do CloudWatch.
**Para criar um ConfigMap para o atendente do CloudWatch**
1. Faça download do YAML do ConfigMap para o host do cliente `kubectl` executando o seguinte comando:
```
curl -O https://raw.githubusercontent.com/aws-samples/amazon-cloudwatch-container-insights/latest/k8s-deployment-manifest-templates/deployment-mode/daemonset/container-insights-monitoring/cwagent/cwagent-configmap-enhanced.yaml
```
1. Edite o arquivo YAML obtido por download da seguinte forma:
+ **cluster\$1name**: na seção `kubernetes`, substitua `{{cluster_name}}` pelo nome do cluster. Remova os caracteres `{{}}`. Se preferir, caso esteja usando um cluster do Amazon EKS, você poderá excluir o campo `"cluster_name"` e o valor. Se fizer isso, o atendente do CloudWatch detectará o nome do cluster a partir das etiquetas do Amazon EC2.
1. (Opcional) Faça alterações adicionais no ConfigMap com base nos requisitos de monitoramento da seguinte forma:
+ **metrics\$1collection\$1interval**: na seção `kubernetes`, você pode especificar com que frequência o atendente coleta métricas. O padrão é 60 segundos. O intervalo de coleta do cadvisor padrão em kubelet é de 15 segundos, portanto, não defina esse valor para menos de 15 segundos.
+ **endpoint\$1override**: na seção `logs`, você poderá especificar o endpoint do CloudWatch Logs se desejar substituir o endpoint padrão. Você pode querer fazer isso se estiver publicando de um cluster em uma VPC e quiser que os dados vão para um VPC endpoint.
+ **force\$1flush\$1interval**: na seção `logs`, você pode especificar o intervalo para agrupar em lote os eventos de log antes que eles sejam publicados no CloudWatch Logs. O padrão é 5 segundos.
+ **region**: por padrão, o atendente publicou métricas para a Região em que o nó de processamento está localizado. Para substituir isso, você pode adicionar um campo `region` na seção `agent`: por exemplo, `"region":"us-west-2"`.
+ Seção **statsd**: se quiser que o atendente do CloudWatch Logs também execute um StatsD em cada nó de processamento do cluster, você poderá adicionar uma seção `statsd` à seção `metrics`, conforme o exemplo a seguir. Para obter informações sobre outras opções do StatsD para essa seção, consulte [Recuperar métricas personalizadas com o StatsD](CloudWatch-Agent-custom-metrics-statsd.md).
```
"metrics": {
"metrics_collected": {
"statsd": {
"service_address":":8125"
}
}
}
```
Um exemplo completo da seção JSON é o seguinte. Se você estiver usando um arquivo `kubeconfig` para autenticação, adicione o parâmetro `kube_config_path` para especificar o caminho para seu arquivo kubeconfig.
```
{
"agent": {
"region": "us-east-1"
},
"logs": {
"metrics_collected": {
"kubernetes": {
"cluster_name": "MyCluster",
"metrics_collection_interval": 60,
"kube_config_path": "/path/to/your/kubeconfig" //if using kubeconfig for authentication
}
},
"force_flush_interval": 5,
"endpoint_override": "logs.us-east-1.amazonaws.com"
},
"metrics": {
"metrics_collected": {
"statsd": {
"service_address": ":8125"
}
}
}
}
```
1. Crie o ConfigMap no cluster executando o comando a seguir.
```
kubectl apply -f cwagent-configmap-enhanced.yaml
```
## Etapa 4: Implantar o atendente do CloudWatch como um DaemonSet
Para concluir a instalação do atendente do CloudWatch e começar a coletar métricas de contêiner, siga as etapas a seguir.
**Para implantar o atendente do CloudWatch como um DaemonSet**
1.
+ Para não usar o StatsD no cluster, insira o comando a seguir.
```
kubectl apply -f https://raw.githubusercontent.com/aws-samples/amazon-cloudwatch-container-insights/latest/k8s-deployment-manifest-templates/deployment-mode/daemonset/container-insights-monitoring/cwagent/cwagent-daemonset.yaml
```
+ Para usar o StatsD, siga estas etapas:
1. Faça download do YAML do DaemonSet para o host do cliente `kubectl` executando o comando a seguir.
```
curl -O https://raw.githubusercontent.com/aws-samples/amazon-cloudwatch-container-insights/latest/k8s-deployment-manifest-templates/deployment-mode/daemonset/container-insights-monitoring/cwagent/cwagent-daemonset.yaml
```
1. Remova o comentário da seção `port` no arquivo `cwagent-daemonset.yaml` da seguinte forma:
```
ports:
- containerPort: 8125
hostPort: 8125
protocol: UDP
```
1. Implante o atendente do CloudWatch no cluster executando o comando a seguir.
```
kubectl apply -f cwagent-daemonset.yaml
```
1. Implante o agente do CloudWatch nos nós do Windows em seu cluster ao executar o comando apresentado a seguir. O receptor StatsD não é compatível com o agente do CloudWatch no Windows.
```
kubectl apply -f cwagent-daemonset-windows.yaml
```
1. Confirme se o atendente está implantado executando o comando a seguir.
```
kubectl get pods -n amazon-cloudwatch
```
Quando for concluído, o atendente do CloudWatch criará um grupo de logs chamado `/aws/containerinsights/Cluster_Name/performance` e enviará os eventos de log de performance a esse grupo de logs. Se você também configurar o atendente como um listener do StatsD, o atendente também escutará as métricas do StatsD na porta 8125 com o endereço IP do nó no qual o pod do aplicativo está programado.
### Solução de problemas
Se o atendente não for implantado corretamente, tente o seguinte:
+ Execute o comando a seguir para obter a lista de pods.
```
kubectl get pods -n amazon-cloudwatch
```
+ Execute o comando a seguir e verifique os eventos na parte inferior da saída.
```
kubectl describe pod pod-name -n amazon-cloudwatch
```
+ Execute o comando a seguir para verificar os logs.
```
kubectl logs pod-name -n amazon-cloudwatch
```
# Usar o AWS Distro for OpenTelemetry
Você pode configurar o Container Insights para coletar métricas dos clusters do Amazon EKS usando o coletor AWS Distro for OpenTelemetry. Para obter mais informações sobre o AWS Distro for OpenTelemetry, consulte [AWS Distro for OpenTelemetry](https://aws.amazon.com/otel/).
**Importante**
Se você instalar usando o AWS Distro para OpenTelemetry, você instala o Container Insights, mas não terá acesso ao Container Insights com observabilidade aprimorada para o Amazon EKS. Você não coletará as métricas detalhadas compatíveis com o Container Insights com observabilidade aprimorada para o Amazon EKS.
A forma de configuração do Container Insights depende se o cluster está hospedado em instâncias do Amazon EC2 ou em AWS Fargate.
## Clusters do Amazon EKS hospedados no Amazon EC2
Se você ainda não tiver feito isso, verifique se cumpriu os pré-requisitos, inclusive as funções do IAM necessárias. Para obter mais informações, consulte [Verificação dos pré-requisitos para o Container Insights no CloudWatch](Container-Insights-prerequisites.md).
A Amazon fornece um chart do Helm que pode ser usado para configurar o monitoramento do Amazon Elastic Kubernetes Service no Amazon EC2. Esse monitoramento usa coletor AWS Distro for OpenEleetry (ADOT) para métricas e Fluent Bit para logs. Portanto, o chart do Helm é útil para clientes que usam o Amazon EKS no Amazon EC2 e desejam coletar métricas e logs para enviar ao CloudWatch Container Insights. Para obter mais informações sobre o chart do Helm, consulte [Gráfico ADOT Helm para EKS em métricas e logs do EC2 para o Amazon CloudWatch Container Insights](https://github.com/aws-observability/aws-otel-helm-charts/tree/main/charts/adot-exporter-for-eks-on-ec2).
Como alternativa, você também pode usar as instruções no restante desta seção.
Primeiro, implante o coletor do AWS Distro for OpenTelemetry como um DaemonSet inserindo o comando a seguir.
```
curl https://raw.githubusercontent.com/aws-observability/aws-otel-collector/main/deployment-template/eks/otel-container-insights-infra.yaml |
kubectl apply -f -
```
Insira o comando a seguir para confirmar se o coletor está em execução.
```
kubectl get pods -l name=aws-otel-eks-ci -n aws-otel-eks
```
Se a saída desse comando incluir vários pods no estado `Running`, o coletor está em execução e coletando métricas do cluster. O coletor cria um grupo de logs chamado `aws/containerinsights/cluster-name/performance` e envia os eventos de log de performance para ele.
Para obter informações sobre como visualizar as métricas do Container Insights no CloudWatch, consulte [Visualizar métricas do Container Insights](Container-Insights-view-metrics.md).
AWSA também forneceu documentação sobre o GitHub para esse cenário. Se quiser personalizar as métricas e os logs publicados pelo Container Insights, consulte [https://aws-otel.github.io/docs/getting-started/container-insights/eks-infra](https://aws-otel.github.io/docs/getting-started/container-insights/eks-infra).
## Clusters do Amazon EKS hospedados no Fargate
Para obter instruções sobre como configurar e implantar um ADOT Collector para coletar métricas do sistema de cargas de trabalho implantadas em um cluster do Amazon EKS no Fargate e enviá-las para o CloudWatch Container Insights, consulte [Container Insights EKS Fargate](https://aws-otel.github.io/docs/getting-started/container-insights/eks-fargate) na documentação do AWS Distro for OpenTelemetry.
# Enviar logs ao CloudWatch Logs
Para enviar logs de seus contêineres para o Amazon CloudWatch Logs, você pode usar o Fluent Bit. Para obter mais informações, consulte [Fluent Bit](https://fluentbit.io/).
**nota**
A partir de 10 de fevereiro de 2025, a AWS descontinuou o suporte ao FluentD como um encaminhador de logs para o CloudWatch Logs. Recomendamos usar o Fluent Bit, que é uma alternativa compacta e eficiente em termos de recursos. As implantações existentes do FluentD continuarão funcionando. Migre seu pipeline de logs para o Fluent Bit para garantir suporte contínuo e performance ideal.
Anteriormente, o Container Insights também era compatível com o uso do FluentD para enviar logs dos contêineres. O FluentD foi descontinuado e agora não é mais compatível com o Container Insights. Use o Fluent Bit em vez disso.
**Topics**
+ [Configurar o Fluent Bit como um DaemonSet para enviar logs ao CloudWatch Logs](Container-Insights-setup-logs-FluentBit.md)
+ [(Opcional) Configurar o registro do ambiente de gerenciamento do Amazon EKS](Container-Insights-setup-control-plane-logging.md)
+ [(Opcional) Habilite o recurso Use\$1Kubelet para clusters grandes](ContainerInsights-use-kubelet.md)
# Configurar o Fluent Bit como um DaemonSet para enviar logs ao CloudWatch Logs
As seções a seguir ajudam a implantar o Fluent Bit para enviar logs de contêineres ao CloudWatch Logs.
**Topics**
+ [Configurar o Fluent Bit](#Container-Insights-FluentBit-setup)
+ [Suporte a logs de várias linhas](#ContainerInsights-fluentbit-multiline)
+ [(Opcional) Reduzir o volume de log do Fluent Bit](#ContainerInsights-fluentbit-volume)
+ [Solução de problemas](#Container-Insights-FluentBit-troubleshoot)
+ [Painel](#Container-Insights-FluentBit-dashboard)
## Configurar o Fluent Bit
Para configurar o Fluent Bit para coletar logs de seus contêineres, siga as etapas em [Configuração de início rápido para o Container Insights no Amazon EKS e no Kubernetes](Container-Insights-setup-EKS-quickstart.md) ou siga as etapas nesta seção.
Com qualquer dos dois métodos, a função do IAM que está anexada aos nós do cluster deve ter permissões suficientes. Para obter mais informações sobre as permissões necessárias para executar um cluster do Amazon EKS, consulte[Políticas, funções, e permissões do Amazon EKS IAM](https://docs.aws.amazon.com/eks/latest/userguide/IAM_policies.html) no *Manual do usuário do Amazon EKS*.
Nas etapas a seguir, você configura o Fluent Bit como um daemonSet para enviar logs ao CloudWatch Logs. Ao concluir esta etapa, o Fluent Bit criará os grupos de log a seguir, caso eles ainda não existam.
**Importante**
Se você já tiver o Fluentd configurado no Container Insights e o daemonSet do Fluentd não estiver sendo executado conforme o esperado (isso poderá acontecer se você usar o runtime `containerd`), desinstale-o antes de instalar o Fluent Bit para evitar que o Fluent Bit processe as mensagens de log de erros do Fluentd. Caso contrário, você deverá desinstalar o Fluentd imediatamente após ter instalado o Fluent Bit com êxito. A desinstalação do Fluentd após a instalação do Fluent Bit garante a continuidade do registro em logs durante esse processo de migração. Apenas um dentre o Fluent Bit e o Fluentd é necessário para enviar logs ao CloudWatch Logs.
| Nome do grupo de logs | Origem do log |
| --- | --- |
| `/aws/containerinsights/Cluster_Name/application` | Todos os arquivos de log em `/var/log/containers` |
| `/aws/containerinsights/Cluster_Name/host` | Logs de `/var/log/dmesg`, `/var/log/secure` e `/var/log/messages` |
| `/aws/containerinsights/Cluster_Name/dataplane` | Os logs no `/var/log/journal` para `kubelet.service`, `kubeproxy.service` e `docker.service`. |
**Para instalar o Fluent Bit para enviar logs de contêineres ao CloudWatch Logs**
1. Se você ainda não tem um namespace chamado `amazon-cloudwatch`, crie um inserindo este comando:
```
kubectl apply -f https://raw.githubusercontent.com/aws-samples/amazon-cloudwatch-container-insights/latest/k8s-deployment-manifest-templates/deployment-mode/daemonset/container-insights-monitoring/cloudwatch-namespace.yaml
```
1. Execute o comando a seguir para criar um ConfigMap chamado `cluster-info` com o nome do cluster e a região para enviar logs. Substitua *cluster-name* e *cluster-region* pelo nome e pela região de seu cluster.
```
ClusterName=cluster-name
RegionName=cluster-region
FluentBitHttpPort='2020'
FluentBitReadFromHead='Off'
[[ ${FluentBitReadFromHead} = 'On' ]] && FluentBitReadFromTail='Off'|| FluentBitReadFromTail='On'
[[ -z ${FluentBitHttpPort} ]] && FluentBitHttpServer='Off' || FluentBitHttpServer='On'
kubectl create configmap fluent-bit-cluster-info \
--from-literal=cluster.name=${ClusterName} \
--from-literal=http.server=${FluentBitHttpServer} \
--from-literal=http.port=${FluentBitHttpPort} \
--from-literal=read.head=${FluentBitReadFromHead} \
--from-literal=read.tail=${FluentBitReadFromTail} \
--from-literal=logs.region=${RegionName} -n amazon-cloudwatch
```
Neste comando, o `FluentBitHttpServer` para monitorar métricas de plugin é ativado por padrão. Para desativá-lo, altere a terceira linha no comando para `FluentBitHttpPort=''` (string vazia) no comando.
Também por padrão, o Fluent Bit lê arquivos de log a partir do final e capturará somente novos logs depois de implantado. Caso queira o oposto, defina `FluentBitReadFromHead='On'`, e ele coletará todos os logs no sistema de arquivos.
1. Baixe e implante o DaemonSet do Fluent Bit no cluster executando os comandos a seguir.
+ Se você quiser obter a configuração otimizada do Fluent Bit para computadores com o sistema Linux, execute o comando apresentado a seguir.
```
kubectl apply -f https://raw.githubusercontent.com/aws-samples/amazon-cloudwatch-container-insights/latest/k8s-deployment-manifest-templates/deployment-mode/daemonset/container-insights-monitoring/fluent-bit/fluent-bit.yaml
```
+ Se você quiser obter a configuração otimizada do Fluent Bit para computadores com o sistema Windows, execute o comando apresentado a seguir.
```
kubectl apply -f https://raw.githubusercontent.com/aws-samples/amazon-cloudwatch-container-insights/latest/k8s-deployment-manifest-templates/deployment-mode/daemonset/container-insights-monitoring/fluent-bit/fluent-bit-windows.yaml
```
+ Se você estiver usando computadores com o sistema Linux e desejar uma configuração do Fluent Bit mais semelhante ao Fluentd, execute o comando apresentado a seguir.
```
kubectl apply -f https://raw.githubusercontent.com/aws-samples/amazon-cloudwatch-container-insights/latest/k8s-deployment-manifest-templates/deployment-mode/daemonset/container-insights-monitoring/fluent-bit/fluent-bit-compatible.yaml
```
**Importante**
Por padrão, a configuração do daemonset do Fluent Bit define o nível de log como INFO, o que pode resultar em maiores custos de ingestão do CloudWatch Logs. Se você quiser reduzir o volume e os custos de ingestão de logs, altere o nível de log para ERROR.
Para obter mais informações sobre como reduzir o volume de log, consulte [(Opcional) Reduzir o volume de log do Fluent Bit](#ContainerInsights-fluentbit-volume).
1. Valide a implantação inserindo o comando a seguir. Cada nó deve ter um pod chamado **fluent-bit-\$1**.
```
kubectl get pods -n amazon-cloudwatch
```
As etapas acima criarão os seguintes recursos no cluster:
+ Uma conta de serviço chamada `Fluent-Bit` no namespace `amazon-cloudwatch`. Essa conta de serviço é usada para executar o DaemonSet do Fluent Bit. Para obter mais informações, consulte [Gerenciar contas de serviço](https://kubernetes.io/docs/reference/access-authn-authz/service-accounts-admin/) (em inglês) na Referência do Kubernetes.
+ Uma função do cluster chamada `Fluent-Bit-role` no namespace `amazon-cloudwatch`. Essa função do cluster concede permissões `get`, `list` e `watch` em logs de pod para a conta de serviço `Fluent-Bit`. Para obter mais informações, consulte [Visão geral da API](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#api-overview/) (em inglês) na Referência do Kubernetes.
+ Um ConfigMap chamado `Fluent-Bit-config` no namespace `amazon-cloudwatch`. Esse ConfigMap contém a configuração a ser usada pelo Fluent Bit. Para obter mais informações, consulte [Configurar um pod para usar um ConfigMap](https://kubernetes.io/docs/tasks/configure-pod-container/configure-pod-configmap/) na documentação do Kubernetes Tasks.
Se pretende verificar a configuração do Fluent Bit, siga estas etapas.
**Verifique a configuração do Fluent Bit**
1. Abra o console do CloudWatch, em [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).
1. No painel de navegação, escolha **Grupos de logs**.
1. Certifique-se de que você está na região na qual implantou o Fluent Bit.
1. Confira a lista de grupos de logs na região. Você deve ver o seguinte:
+ `/aws/containerinsights/Cluster_Name/application`
+ `/aws/containerinsights/Cluster_Name/host`
+ `/aws/containerinsights/Cluster_Name/dataplane`
1. Navegue até um desses grupos de log e marque **Last Event Time** (Hora do último evento) para os fluxos de log. Se for recente em relação à implantação do Fluent Bit, a instalação será verificada.
Pode haver um pequeno atraso na criação do grupo de logs `/dataplane`. Isso é normal, pois esses grupos de log só são criados quando o Fluent Bit começa a enviar logs a esse grupo de logs.
## Suporte a logs de várias linhas
Para obter informações sobre como usar o Fluent Bit com logs de várias linhas, consulte as seções a seguir da documentação do Fluent Bit:
+ [Análise de várias linhas](https://docs.fluentbit.io/manual/administration/configuring-fluent-bit/multiline-parsing)
+ [Várias linhas e contêineres (v1.8)](https://docs.fluentbit.io/manual/pipeline/inputs/tail#multiline-and-containers-v1.8)
+ [Núcleo de várias linhas (v1.8)](https://docs.fluentbit.io/manual/pipeline/inputs/tail#multiline-core-v1.8)
+ [Sempre use várias linhas multilinha na entrada final](https://github.com/aws/aws-for-fluent-bit/blob/mainline/troubleshooting/debugging.md#always-use-multiline-the-tail-input)
## (Opcional) Reduzir o volume de log do Fluent Bit
Por padrão, enviamos logs de aplicação do Fluent Bit e metadados do Kubernetes ao CloudWatch. Para reduzir o volume de dados que estão sendo enviados ao CloudWatch, você pode impedir que uma ou ambas as fontes de dados sejam enviadas ao CloudWatch. Se você seguiu as etapas desta página para configurar o Fluent Bit, faça o download do arquivo YAML do manifesto do Kubernetes do comando `apply` de kubectl que você executou anteriormente e modifique-o com suas alterações, que você poderá então reaplicar ao seu cluster. Como alternativa, se você estiver usando o complemento de observabilidade do EKS do Amazon Cloudwatch ou o chart do Helm, consulte [(Opcional) Configuração adicional](install-CloudWatch-Observability-EKS-addon.md#install-CloudWatch-Observability-EKS-addon-configuration) para obter informações sobre como gerenciar a configuração do Fluent Bit usando a configuração avançada do complemento ou o chart do Helm.
Para interromper os logs de aplicação do Fluent Bit, remova a seção a seguir do arquivo `Fluent Bit configuration`.
```
[INPUT]
Name tail
Tag application.*
Path /var/log/containers/fluent-bit*
Parser docker
DB /fluent-bit/state/flb_log.db
Mem_Buf_Limit 5MB
Skip_Long_Lines On
Refresh_Interval 10
```
Para remover os metadados do Kubernetes, a fim de que não sejam anexados aos eventos de log que são enviados ao CloudWatch, adicione os filtros a seguir à seção `application-log.conf` na configuração do Fluent Bit. Substitua ** e os campos semelhantes pelos identificadores de metadados reais.
```
application-log.conf: |
[FILTER]
Name nest
Match application.*
Operation lift
Nested_under kubernetes
Add_prefix Kube.
[FILTER]
Name modify
Match application.*
Remove Kube.
Remove Kube.
Remove Kube.
[FILTER]
Name nest
Match application.*
Operation nest
Wildcard Kube.*
Nested_under kubernetes
Remove_prefix Kube.
```
## Solução de problemas
Caso não veja esses grupos de log e esteja procurando na região correta, confira os logs para os pods do daemonSet do Fluentd para procurar o erro.
Execute o comando a seguir para certificar-se de que o status seja `Running`.
```
kubectl get pods -n amazon-cloudwatch
```
Se os logs tiverem erros relacionados às permissões do IAM, verifique a função do IAM que está anexada aos nós do cluster. Para obter mais informações sobre as permissões necessárias para executar um cluster do Amazon EKS, consulte[Políticas, funções, e permissões do Amazon EKS IAM](https://docs.aws.amazon.com/eks/latest/userguide/IAM_policies.html) no *Manual do usuário do Amazon EKS*.
Se o status do pod for `CreateContainerConfigError`, obtenha o erro exato executando o comando a seguir.
```
kubectl describe pod pod_name -n amazon-cloudwatch
```
## Painel
É possível criar um painel para monitorar métricas de cada plugin em execução. Você pode visualizar dados para bytes de entrada e saída e para taxas de processamento de registros, bem como erros de saída e taxas de repetição/falha. Para visualizar essas métricas, será necessário instalar o atendente do CloudWatch com a coleção de métricas do Prometheus para clusters do Amazon EKS e do Kubernetes. Consulte para obter mais informações sobre como configurar o painel [Instalar o atendente do CloudWatch com a coleção de métricas do Prometheus em clusters do Amazon EKS e do KubernetesInstalar o atendente do CloudWatch com a coleção de métricas do Prometheus em clusters do Amazon EKS e do Kubernetes](ContainerInsights-Prometheus-Setup.md).
**nota**
Antes de configurar este painel, é necessário configurar as métricas do Container Insights para o Prometheus. Para obter mais informações, consulte [Monitoramento de métricas do Container Insights Prometheus](ContainerInsights-Prometheus.md).
**Para criar um painel para métricas do Prometheus do Fluent Bits**
1. Crie variáveis de ambiente, substituindo os valores à direita nas linhas a seguir para corresponder a sua implantação.
```
DASHBOARD_NAME=your_cw_dashboard_name
REGION_NAME=your_metric_region_such_as_us-west-1
CLUSTER_NAME=your_kubernetes_cluster_name
```
1. Crie o painel executando o comando a seguir.
```
curl https://raw.githubusercontent.com/aws-samples/amazon-cloudwatch-container-insights/latest/k8s-deployment-manifest-templates/deployment-mode/service/cwagent-prometheus/sample_cloudwatch_dashboards/fluent-bit/cw_dashboard_fluent_bit.json \
| sed "s/{{YOUR_AWS_REGION}}/${REGION_NAME}/g" \
| sed "s/{{YOUR_CLUSTER_NAME}}/${CLUSTER_NAME}/g" \
| xargs -0 aws cloudwatch put-dashboard --dashboard-name ${DASHBOARD_NAME} --dashboard-body
```
# (Opcional) Configurar o registro do ambiente de gerenciamento do Amazon EKS
Se estiver usando o Amazon EKS, opcionalmente, você poderá habilitar o registro do ambiente de gerenciamento do Amazon EKS para fornecer logs de diagnóstico e auditoria diretamente do ambiente de gerenciamento do Amazon EKS para o CloudWatch Logs. Para obter mais informações, consulte [Amazon EKS Control Plane Logging](https://docs.aws.amazon.com/eks/latest/userguide/control-plane-logs.html) (Registro em log do plano de controle do Amazon EKS).
# (Opcional) Habilite o recurso Use\$1Kubelet para clusters grandes
Por padrão, o recurso Use\$1Kubelet está desabilitado no plugin FluentBit Kubernetes. A habilitação desse recurso pode reduzir o tráfego para o servidor de API e mitigar o problema de gargalo do servidor de API. Recomendamos a habilitação desse recurso para clusters grandes.
Para habilitar Use\$1Kubelet, primeiro adicione os nós e as permissões de nós/proxy à configuração clusterRole.
```
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: fluent-bit-role
rules:
- nonResourceURLs:
- /metrics
verbs:
- get
- apiGroups: [""]
resources:
- namespaces
- pods
- pods/logs
- nodes
- nodes/proxy
verbs: ["get", "list", "watch"]
```
Na configuração do DaemonSet, esse recurso precisa de acesso à rede host. A versão da imagem para `amazon/aws-for-fluent-bit` deve ser 2.12.0 ou posterior, ou a versão da imagem de bits fluentes deve ser 1.7.2 ou posterior.
```
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: fluent-bit
namespace: amazon-cloudwatch
labels:
k8s-app: fluent-bit
version: v1
kubernetes.io/cluster-service: "true"
spec:
selector:
matchLabels:
k8s-app: fluent-bit
template:
metadata:
labels:
k8s-app: fluent-bit
version: v1
kubernetes.io/cluster-service: "true"
spec:
containers:
- name: fluent-bit
image: amazon/aws-for-fluent-bit:2.19.0
imagePullPolicy: Always
env:
- name: AWS_REGION
valueFrom:
configMapKeyRef:
name: fluent-bit-cluster-info
key: logs.region
- name: CLUSTER_NAME
valueFrom:
configMapKeyRef:
name: fluent-bit-cluster-info
key: cluster.name
- name: HTTP_SERVER
valueFrom:
configMapKeyRef:
name: fluent-bit-cluster-info
key: http.server
- name: HTTP_PORT
valueFrom:
configMapKeyRef:
name: fluent-bit-cluster-info
key: http.port
- name: READ_FROM_HEAD
valueFrom:
configMapKeyRef:
name: fluent-bit-cluster-info
key: read.head
- name: READ_FROM_TAIL
valueFrom:
configMapKeyRef:
name: fluent-bit-cluster-info
key: read.tail
- name: HOST_NAME
valueFrom:
fieldRef:
fieldPath: spec.nodeName
- name: HOSTNAME
valueFrom:
fieldRef:
apiVersion: v1
fieldPath: metadata.name
- name: CI_VERSION
value: "k8s/1.3.8"
resources:
limits:
memory: 200Mi
requests:
cpu: 500m
memory: 100Mi
volumeMounts:
# Please don't change below read-only permissions
- name: fluentbitstate
mountPath: /var/fluent-bit/state
- name: varlog
mountPath: /var/log
readOnly: true
- name: varlibdockercontainers
mountPath: /var/lib/docker/containers
readOnly: true
- name: fluent-bit-config
mountPath: /fluent-bit/etc/
- name: runlogjournal
mountPath: /run/log/journal
readOnly: true
- name: dmesg
mountPath: /var/log/dmesg
readOnly: true
terminationGracePeriodSeconds: 10
hostNetwork: true
dnsPolicy: ClusterFirstWithHostNet
volumes:
- name: fluentbitstate
hostPath:
path: /var/fluent-bit/state
- name: varlog
hostPath:
path: /var/log
- name: varlibdockercontainers
hostPath:
path: /var/lib/docker/containers
- name: fluent-bit-config
configMap:
name: fluent-bit-config
- name: runlogjournal
hostPath:
path: /run/log/journal
- name: dmesg
hostPath:
path: /var/log/dmesg
serviceAccountName: fluent-bit
tolerations:
- key: node-role.kubernetes.io/master
operator: Exists
effect: NoSchedule
- operator: "Exists"
effect: "NoExecute"
- operator: "Exists"
effect: "NoSchedule"
```
A configuração do Kubernetes Plugin deve ser semelhante à seguinte:
```
[FILTER]
Name kubernetes
Match application.*
Kube_URL https://kubernetes.default.svc:443
Kube_Tag_Prefix application.var.log.containers.
Merge_Log On
Merge_Log_Key log_processed
K8S-Logging.Parser On
K8S-Logging.Exclude Off
Labels Off
Annotations Off
Use_Kubelet On
Kubelet_Port 10250
Buffer_Size 0
```
# Atualizar ou excluir o Container Insights no Amazon EKS e no Kubernetes
Siga as etapas destas seções para atualizar a imagem de contêiner do atendente do CloudWatch ou para remover o Container Insights de um cluster do Amazon EKS ou do Kubernetes.
**Topics**
+ [Atualização para o Container Insights com observabilidade aprimorada para o Amazon EKS no CloudWatch](Container-Insights-upgrade-enhanced.md)
+ [Atualizar a imagem do contêiner do atendente do CloudWatch](ContainerInsights-update-image.md)
+ [Exclusão do agente do CloudWatch e do Fluent Bit para o Container Insights](ContainerInsights-delete-agent.md)
# Atualização para o Container Insights com observabilidade aprimorada para o Amazon EKS no CloudWatch
**Importante**
Se você estiver atualizando ou instalando o Container Insights em um cluster do Amazon EKS, recomendamos usar o complemento Observability do Amazon CloudWatch para o EKS para a instalação, em vez de usar as instruções apresentadas nesta seção. Além disso, para recuperar as métricas de computação acelerada, é necessário usar o complemento Observability do Amazon CloudWatch para o EKS. Para obter mais informações e instruções, consulte [Introdução ao complemento Amazon CloudWatch Observability do EKS](Container-Insights-setup-EKS-addon.md).
O Container Insights com observabilidade aprimorada para o Amazon EKS é a versão mais recente do Container Insights. Ele coleta métricas detalhadas de clusters que executam o Amazon EKS e oferece painéis de controle selecionados e imediatamente utilizáveis para detalhar a telemetria de aplicações e infraestrutura. Para obter mais informações sobre esta versão do Container Insights, consulte [Container Insights com observabilidade aprimorada para o Amazon EKS](container-insights-detailed-metrics.md).
Se você tiver instalado a versão original do Container Insights em um cluster do Amazon EKS e quiser atualizá-lo para a versão mais recente com observabilidade aprimorada, siga as instruções desta seção.
**Importante**
Antes de executar as etapas desta seção, você deve ter verificado os pré-requisitos, incluindo o cert-manager. Para obter mais informações, consulte [Início rápido ao usar o operador do agente do CloudWatch e o Fluent Bit](Container-Insights-setup-EKS-quickstart.md#Container-Insights-setup-EKS-quickstart-FluentBit).
**Atualizar um cluster do Amazon EKS para o Container Insights com observabilidade aprimorada para o Amazon EKS**
1. Instale o operador do agente do CloudWatch ao inserir o comando apresentado a seguir. Substitua *my-cluster-name* pelo nome do cluster do Amazon EKS ou do Kubernetes e *my-cluster-region* pelo nome da região em que os logs são publicados. Recomendamos usar a mesma região em que o cluster está implantado para reduzir os custos de transferência de dados de saída da AWS.
```
ClusterName=my-cluster-name
RegionName=my-cluster-region
curl https://raw.githubusercontent.com/aws-samples/amazon-cloudwatch-container-insights/main/k8s-quickstart/cwagent-operator-rendered.yaml | sed 's/{{cluster_name}}/'${ClusterName}'/g;s/{{region_name}}/'${RegionName}'/g' | kubectl apply -f -
```
Se você notar uma falha causada por recursos conflitantes, é provável que já tenha o agente do CloudWatch e o Fluent Bit com os componentes associados, como o ServiceAccount, o ClusterRole e o ClusterRoleBinding instalados no cluster. Quando o operador do agente do CloudWatch tenta instalar o agente do CloudWatch e os componentes associados, se detectar quaisquer alterações no conteúdo, por padrão, apresentará falhas na instalação ou na atualização para evitar a substituição do estado dos recursos no cluster. Recomendamos excluir qualquer agente do CloudWatch existente com a configuração para o Container Insights que tenha sido instalado anteriormente no cluster e, em seguida, instalar o operador do agente do CloudWatch.
1. (Opcional) Para aplicar uma configuração personalizada do Fluent Bit existente, é necessário atualizar o configmap associado ao daemonset do Fluent Bit. O operador do agente do CloudWatch fornece uma configuração padrão para o Fluent Bit, e é possível substituir ou modificar essa configuração conforme necessário. Para aplicar uma configuração personalizada, siga as etapas apresentadas a seguir.
1. Abra a configuração existente ao inserir o comando apresentado a seguir.
```
kubectl edit cm fluent-bit-config -n amazon-cloudwatch
```
1. Faça as alterações no arquivo e, em seguida, insira `:wq` para salvar o arquivo e sair do modo de edição.
1. Reinicie o Fluent Bit ao inserir o comando apresentado a seguir.
```
kubectl rollout restart ds fluent-bit -n amazon-cloudwatch
```
# Atualizar a imagem do contêiner do atendente do CloudWatch
**Importante**
Se você estiver atualizando ou instalando o Container Insights em um cluster do Amazon EKS, recomendamos usar o complemento Observability do Amazon CloudWatch para o EKS para a instalação, em vez de usar as instruções apresentadas nesta seção. Além disso, para recuperar métricas de computação acelerada, é necessário usar o complemento Observability do Amazon CloudWatch para o EKS ou o operador do agente do CloudWatch. Para obter mais informações e instruções, consulte [Introdução ao complemento Amazon CloudWatch Observability do EKS](Container-Insights-setup-EKS-addon.md).
Se você precisar atualizar a imagem do contêiner para a versão mais recente, use as etapas nesta seção.
**Para atualizar a imagem de contêiner**
1. Verifique se a Definição de Recursos do Cliente (CRD) `amazoncloudwatchagent` já existe ao inserir o comando apresentado a seguir.
```
kubectl get crds amazoncloudwatchagents.cloudwatch.aws.amazon.com -n amazon-cloudwatch
```
Se esse comando retornar um erro informando que o CRD está ausente, o cluster não tem o Container Insights com observabilidade aprimorada para o Amazon EKS configurado com o operador do agente do CloudWatch. Nesse caso, consulte [Atualização para o Container Insights com observabilidade aprimorada para o Amazon EKS no CloudWatch](Container-Insights-upgrade-enhanced.md).
1. Aplique o arquivo `cwagent-version.yaml` mais recente inserindo o comando a seguir.
```
curl https://raw.githubusercontent.com/aws-samples/amazon-cloudwatch-container-insights/main/k8s-quickstart/cwagent-version.yaml | kubectl apply -f -
```
# Exclusão do agente do CloudWatch e do Fluent Bit para o Container Insights
Se você instalou o Container Insights usando a instalação do complemento de observabilidade do EKS para o Amazon CloudWatch, você pode excluir o Container Insights e o agente do CloudWatch inserindo o seguinte comando:
**nota**
Agora, o complemento do Amazon EKS é compatível com o Container Insights em nós de processamento do Windows. Se você excluir o complemento do Amazon EKS, o Container Insights para Windows também será excluído.
```
aws eks delete-addon —cluster-name my-cluster —addon-name amazon-cloudwatch-observability
```
Caso contrário, para excluir todos os recursos relacionados ao agente do CloudWatch e ao Fluent Bit, insira o comando apresentado a seguir. Neste comando, *My\$1Cluster\$1Name* corresponde ao nome do cluster do Amazon EKS ou do Kubernetes, e *My\$1Region* corresponde ao nome da região na qual os logs são publicados.
```
ClusterName=My_Cluster_Name
RegionName=My-Region
curl https://raw.githubusercontent.com/aws-samples/amazon-cloudwatch-container-insights/main/k8s-quickstart/cwagent-operator-rendered.yaml | sed 's/{{cluster_name}}/'${ClusterName}'/g;s/{{region_name}}/'${RegionName}'/g' | kubectl delete -f -
curl https://raw.githubusercontent.com/aws-samples/amazon-cloudwatch-container-insights/main/k8s-quickstart/cwagent-custom-resource-definitions.yaml | kubectl delete -f -
```
# Como configurar o Container Insights no RedHat OpenShift na AWS (ROSA)
O CloudWatch Container Insights com observabilidade aprimorada é compatível com o RedHat OpenShift na AWS (ROSA). Essa versão oferece suporte à observabilidade aprimorada para clusters do ROSA. Depois de instalar o chart do Helm do operador do agente do CloudWatch, o Container Insights coleta automaticamente a telemetria detalhada da infraestrutura desde o nível do cluster até o nível do contêiner no seu ambiente. Em seguida, ele exibe esses dados de performance em painéis selecionados, eliminando o trabalho pesado na configuração de observabilidade.
**nota**
Para o RedHat OpenShift na AWS (ROSA), quando você instala o operador do agente do CloudWatch usando charts do Helm, por padrão, o agente do CloudWatch também é habilitado para receber métricas e rastreamentos das aplicações que são instrumentadas para o Application Signals. Se você desejar, opcionalmente, passar regras de configuração personalizadas, poderá fazê-lo passando uma configuração de agente personalizada usando o chart do Helm, conforme descrito em (Opcional) [Configuração adicional], como indicado em [(Opcional) Configuração adicional](install-CloudWatch-Observability-EKS-addon.md#install-CloudWatch-Observability-EKS-addon-configuration).
**Para instalar o Container Insights com observabilidade aprimorada em um cluster do RedHat OpenShift na AWS (ROSA)**
1. Se necessário, instale o Helm. Para obter mais informações, consulte [Guia de início rápido](https://helm.sh/docs/intro/quickstart/) na documentação do Helm.
1. Instale o operador do agente do CloudWatch ao inserir os comandos a seguir. Substitua *my-cluster-name* pelo nome do seu cluster e *my-cluster-region* pela região em que o cluster é executado.
```
helm repo add aws-observability https://aws-observability.github.io/helm-charts
helm repo update aws-observability
helm install --wait --create-namespace \
--namespace amazon-cloudwatch amazon-cloudwatch-observability \
aws-observability/amazon-cloudwatch-observability \
--set clusterName=my-cluster-name \
--set region=my-cluster-region \
--set k8sMode=ROSA
```
1. Configure a autorização para o operador do agente ao seguir as etapas na Opção 1, Opção 2 ou Opção 3 em [Instalação do agente do CloudWatch com o complemento de observabilidade do EKS do Amazon CloudWatch ou com o chart do Helm](install-CloudWatch-Observability-EKS-addon.md).
# Visualizar métricas do Container Insights
Depois que o Container Insights for configurado e estiver coletando métricas, você poderá visualizar essas métricas no console do CloudWatch.
Para que as métricas do Container Insights sejam exibidas no seu painel, você deve concluir a configuração do Container Insights. Para obter mais informações, consulte [Configurar o Container Insights](deploy-container-insights.md).
Esse procedimento explica como visualizar as métricas que o Container Insights gera automaticamente a partir dos dados de log coletados. O restante desta seção explica como analisar seus dados mais profundamente e usar o CloudWatch Logs Insights para ver mais métricas em mais níveis de detalhamento.
**Para visualizar métricas do Container Insights**
1. Abra o console do CloudWatch, em [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).
1. No painel de navegação, escolha **Insights**, **Container Insights**.
1. Use as caixas suspensas perto do canto superior para selecionar o tipo de recurso a ser exibido, bem como o recurso específico.
Você pode definir um alarme do CloudWatch em qualquer métrica que o Container Insights coletar. Para obter mais informações, consulte . [Usar alarmes do Amazon CloudWatch](CloudWatch_Alarms.md)
**nota**
Se você já configurou o CloudWatch Application Insights para monitorar suas aplicações em contêiner, o painel do Application Insights aparecerá abaixo do painel do Container Insights. Se você ainda não ativou o Application Insights, poderá fazê-lo escolhendo **Auto-configure Application Insights** (Configurar automaticamente o Application Insights abaixo da visualização de performance no painel Container Insights.
Para obter mais informações sobre o Application Insights e aplicações em contêiner, consulte [Habilitar o Application Insights para monitoramento de recursos do Amazon ECS e do Amazon EKS](appinsights-setting-up-console.md#appinsights-container-insights).
## Visualizar os principais colaboradores
Para algumas das exibições no monitoramento de performance do Container Insights, também é possível ver os principais colaboradores por memória ou CPU, ou os recursos ativos mais recentes. Essa informação está disponível quando você seleciona, na caixa suspensa próxima ao alto da página, um dos seguintes painéis:
+ Serviços do ECS
+ Tarefas do ECS
+ Namespaces do EKS
+ Serviços do EKS
+ Pods do EKS
Quando você estiver visualizando um desses tipos de recursos, a parte inferior da página exibirá uma tabela classificada inicialmente por uso da CPU. É possível alterá-la para classificar por uso de memória ou atividade recente. Para ver mais sobre uma das linhas na tabela, é possível marcar a caixa de seleção ao lado dessa linha e escolher **Actions** (Ações) e uma das opções do menu **Actions**.
## Usar o CloudWatch Logs Insights para visualizar dados do Container Insights
O Container Insights coleta métricas com eventos de log de performance usando [formato de métrica incorporado](CloudWatch_Embedded_Metric_Format.md). Os logs são armazenados no CloudWatch Logs. O CloudWatch gera várias métricas automaticamente a partir dos logs. Você pode visualizá-las no console do CloudWatch. Também é possível fazer uma análise mais profunda dos dados de performance coletados usando consultas do CloudWatch Logs Insights.
Para obter mais informações sobre o CloudWatch Logs Insights, consulte [Analisar dados de log com o CloudWatch Logs Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AnalyzingLogData.html). Para obter mais informações sobre os campos de log que podem ser usados em consultas, consulte [Eventos do log de performance do Container Insights para Amazon EKS e Kubernetes](Container-Insights-reference-performance-logs-EKS.md).
**Para usar o CloudWatch Logs Insights para consultar os dados de métricas de contêiner**
1. Abra o console do CloudWatch, em [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).
1. No painel de navegação, escolha **Logs**, **Logs Insights**.
Próximo da parte superior da tela está o editor de consultas. Quando você abre o CloudWatch Logs Insights pela primeira vez, essa caixa contém uma consulta padrão que retorna os 20 eventos de log mais recentes.
1. Na caixa acima do editor de consultas, selecione um dos grupos de log do Container Insights para consultar. Para o que o exemplo de consultas a seguir funcione, o nome do grupo de logs deve terminar com **performance**.
Quando você seleciona um grupo de logs, o CloudWatch Logs Insights automaticamente detecta campos nos dados no grupo de logs e os exibe em **Discovered fields** (Campos detectados) no painel á direta. Ele também exibe um gráfico de barras de eventos de log neste grupo de logs com o passar do tempo. Esse gráfico de barras mostra a distribuição de eventos no grupo de logs correspondente à consulta e ao intervalo de tempo, e não apenas os eventos exibidos na tabela.
1. No editor de consultas, substitua a consulta padrão pela consulta a seguir e selecione **Run query (Executar consulta)**.
```
STATS avg(node_cpu_utilization) as avg_node_cpu_utilization by NodeName
| SORT avg_node_cpu_utilization DESC
```
Essa consulta mostra uma lista de nós, classificados por utilização média da CPU do nó.
1. Para tentar outro exemplo, substitua essa consulta por outra consulta e selecione **Run query (Executar consulta)**. Mais consultas de exemplo são listadas posteriormente nesta página.
```
STATS avg(number_of_container_restarts) as avg_number_of_container_restarts by PodName
| SORT avg_number_of_container_restarts DESC
```
Essa consulta exibe uma lista dos pods classificados pelo número médio de reinicializações do contêiner.
1. Se você quiser tentar outra consulta, poderá usar campos de inclusão na lista à direita da tela. Para obter mais informações sobre a sintaxe de consulta, leia [Sintaxe de consulta do CloudWatch Logs Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_QuerySyntax.html).
**Como visualizar as listas de seus recursos**
1. Abra o console do CloudWatch, em [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).
1. No painel de navegação, escolha **Resources (Recursos)**.
1. A exibição padrão é uma lista dos recursos que estão sendo monitorados pelo Container Insights e os alarmes definidos nesses recursos. Para visualizar um mapa visual dos recursos, escolha **Map view (Visualização do mapa)**.
1. Na visualização do mapa, deixe o cursor sobre qualquer recurso no mapa para visualizar métricas básicas sobre esse recurso. Você pode escolher qualquer recurso para visualizar gráficos mais detalhados sobre o recurso.
## Caso de uso: visualizar métricas em nível de tarefa em contêineres do Amazon ECS
O exemplo a seguir ilustra como usar o CloudWatch Logs Insights para aprofundar os logs do Container Insights. Para obter mais exemplos, consulte o blog [Introducing Amazon CloudWatch Container Insights for Amazon ECS](https://aws.amazon.com/blogs/mt/introducing-container-insights-for-amazon-ecs/).
O Container Insights não gera automaticamente métricas no nível de detalhamento da tarefa. A consulta a seguir exibe métricas no nível da tarefa para uso da CPU e da memória.
```
stats avg(CpuUtilized) as CPU, avg(MemoryUtilized) as Mem by TaskId, ContainerName
| sort Mem, CPU desc
```
## Outros exemplos de consultas do Container Insights
**Lista de seus pods, classificados por número médio de reinicializações de contêiner**
```
STATS avg(number_of_container_restarts) as avg_number_of_container_restarts by PodName
| SORT avg_number_of_container_restarts DESC
```
**Pods solicitados versus pods em execução**
```
fields @timestamp, @message
| sort @timestamp desc
| filter Type="Pod"
| stats min(pod_number_of_containers) as requested, min(pod_number_of_running_containers) as running, ceil(avg(pod_number_of_containers-pod_number_of_running_containers)) as pods_missing by kubernetes.pod_name
| sort pods_missing desc
```
**Contagem de falhas no nó do cluster**
```
stats avg(cluster_failed_node_count) as CountOfNodeFailures
| filter Type="Cluster"
| sort @timestamp desc
```
**Erros de log do aplicativo por nome do contêiner**
```
stats count() as countoferrors by kubernetes.container_name
| filter stream="stderr"
| sort countoferrors desc
```
# Métricas coletadas pelo Container Insights
O Container Insights coleta um conjunto de métricas para o Amazon ECS e para o AWS Fargate no Amazon ECS e outro conjunto para o Amazon EKS, para o AWS Fargate no Amazon EKS, para o RedHat OpenShift na AWS (ROSA) e para o Kubernetes.
As métricas não estarão visíveis até que as tarefas do contêiner estejam em execução por algum tempo.
**Topics**
+ [Métricas do Container Insights com observabilidade aprimorada para o Amazon ECS](Container-Insights-enhanced-observability-metrics-ECS.md)
+ [Métricas Amazon ECS Container Insights](Container-Insights-metrics-ECS.md)
+ [Métricas do Container Insights com observabilidade aprimorada para o Amazon EKS e o Kubernetes](Container-Insights-metrics-enhanced-EKS.md)
+ [Métricas do Container Insights do Amazon EKS e do Kubernetes](Container-Insights-metrics-EKS.md)
+ [Referência do log de performance do Container Insights](Container-Insights-reference.md)
+ [Monitoramento de métricas do Container Insights Prometheus](ContainerInsights-Prometheus.md)
+ [Integração ao Application Insights](container-insights-appinsights.md)
+ [Visualização dos eventos do ciclo de vida do Amazon ECS no Container Insights](container-insights-ECS-lifecycle-events.md)
+ [Solução de problemas do Container Insights](ContainerInsights-troubleshooting.md)
+ [Criar sua própria imagem do Docker do atendente do CloudWatch](ContainerInsights-build-docker-image.md)
+ [Implantar outros recursos do atendente do CloudWatch nos contêineres](ContainerInsights-other-agent-features.md)
# Métricas do Container Insights com observabilidade aprimorada para o Amazon ECS
O Container Insights com observabilidade aprimorada fornece uma visibilidade mais profunda das workloads em contêineres, oferecendo:
+ Maior granularidade de métricas nos níveis de tarefa e contêiner
+ Recursos aprimorados de monitoramento e solução de problemas
+ Integração com o CloudWatch Logs para:
+ Correlacionar anomalias de métricas com entradas de logs
+ Realizar uma análise mais rápida da causa raiz
+ Reduzir o tempo de resolução de problemas complexos de contêineres
**Casos de uso**
O Container Insights com observabilidade aprimorada amplia os recursos do Container Insights padrão. Ele possibilita os seguintes casos de uso:
+ **Solução de problemas em nível de tarefa**: identifique gargalos de performance no nível de tarefa. Analise as métricas no nível de tarefa e compare-as com os recursos reservados para determinar se as tarefas têm capacidade de processamento suficiente
+ **Otimização de recursos em nível de contêiner**: rastreie a utilização em relação aos níveis de reserva para identificar contêineres com restrição de recursos ou superprovisionados
+ **Avaliação da integridade de contêineres**: monitore as contagens de reinicialização e as transições de estado para detectar contêineres instáveis que requerem intervenção
+ **Monitoramento da performance de aplicações**: rastreie como as aplicações se comunicam entre si, monitore os padrões de uso de recursos e otimize a performance do armazenamento de dados
+ **Monitoramento operacional**: monitore implantações, rastreie conjuntos de tarefas para implantações azul/verde e mantenha a integridade da plataforma por meio de métricas de serviço
Para obter informações sobre as métricas do Amazon ECS, consulte [Casos de uso de métricas de utilização do serviço do Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service_utilization-metrics-explanation.html), e para obter informações sobre insights de contêineres com observabilidade aprimorada, consulte [Métricas do Container Insights com observabilidade aprimorada para o Amazon ECS](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Container-Insights-enhanced-observability-metrics-ECS.html).
O Container Insights também mostra estatísticas do cluster, do serviço e de todo o daemon calculando a média dos dados em todas as tarefas. Isso fornece uma visão de alto nível da integridade do seu serviço e daemon, auxiliando no monitoramento do ambiente e no planejamento da capacidade.
**nota**
As métricas do daemon gerenciado do Amazon ECS usam o mesmo namespace `ECS/ContainerInsights` e a mesma dimensão `ServiceName` das métricas de serviço. Para métricas do daemon, o valor da dimensão `ServiceName` usa o formato `daemon:daemon-name`. Por exemplo, um daemon denominado `my-daemon` tem um valor de dimensão `ServiceName` de `daemon:my-daemon`. Todas as métricas na tabela abaixo que incluem a dimensão `ServiceName` também se aplicam aos daemons gerenciados.
A tabela a seguir lista as métricas e as dimensões que o Container Insights com observabilidade aprimorada coleta para o Amazon ECS. Essas métricas estão no namespace `ECS/ContainerInsights`. Para obter mais informações, consulte [Métricas](cloudwatch_concepts.md#Metric).
Se você não vir as métricas do Container Insights no console, certifique-se de que você concluiu a configuração do Container Insights com observabilidade aprimorada. As métricas não serão exibidas até que o Container Insights com observabilidade aprimorada tenha sido configurado completamente. Para obter mais informações, consulte [Configurar o Container Insights com observabilidade aprimorada](deploy-container-insights-ECS-cluster.md#set-container-insights-ECS-cluster-enhanced).
As métricas a seguir estão disponíveis para todos os tipos de inicialização.
| Nome da métrica | Dimensões | Descrição |
| --- | --- | --- |
| `ContainerInstanceCount` | `ClusterName` | O número de instâncias do EC2 que executam o atendente do Amazon ECS registrado com um cluster. Essa métrica é coletada apenas para instâncias de contêineres que estão executando tarefas do Amazon ECS no cluster. Ela não é coletada para instâncias de contêineres vazios que não têm nenhuma tarefa do Amazon ECS. Unidade: Contagem |
| `ContainerCpuUtilized` | `ClusterName` `ContainerName`, `TaskId`, `ServiceName`, `ClusterName` `ContainerName`, `TaskDefinitionFamily`, `ClusterName`, `TaskId` `TaskDefinitionFamily`, `ClusterName`, `ContainerName` `ServiceName`, `ClusterName`, `ContainerName` | As unidades de CPU usadas por contêineres no recurso especificado pela definição de dimensão que você está usando. Também se aplica aos daemons gerenciados. Unidade: nenhuma |
| `ContainerCpuReserved` | `ClusterName` `ContainerName`, `TaskId`, `ServiceName`, `ClusterName` `ContainerName`, `TaskDefinitionFamily`, `ClusterName`, `TaskId` `TaskDefinitionFamily`, `ClusterName`, `ContainerName` `ServiceName`, `ClusterName`, `ContainerName` | As unidades de CPU reservadas por contêineres no recurso especificado pelo conjunto de dimensões que você está usando. Essa métrica é coletada com base na reserva de CPU especificada na definição da tarefa, podendo ser aplicada, por exemplo, no nível da tarefa ou de todos os contêineres. Se isso não estiver especificado na definição da tarefa, a reserva de CPU da instância será usada. Também se aplica aos daemons gerenciados. Unidade: nenhuma |
| `ContainerCpuUtilization` | `TaskDefinitionFamily`, `ClusterName` `ServiceName`, `ClusterName` `ClusterName` `ClusterName`, `ServiceName`, `TaskId` `ClusterName`, `TaskDefinitionFamily`, `TaskId` | A porcentagem total de unidades de CPU usadas por contêineres no recurso especificado pela definição de dimensão que você está usando. Unidade: percentual |
| `ContainerMemoryUtilized` | `ClusterName` `ContainerName`, `TaskId`, `ServiceName`, `ClusterName` `ContainerName`, `TaskDefinitionFamily`, `ClusterName`, `TaskId` `TaskDefinitionFamily`, `ClusterName`, `ContainerName` `ServiceName`, `ClusterName`, `ContainerName` | A memória que está sendo usada por contêineres no recurso especificado pela definição de dimensões que você está usando. Também se aplica aos daemons gerenciados. Unidade: megabytes |
| `ContainerMemoryReserved` | `ClusterName` `ContainerName`, `TaskId`, `ServiceName`, `ClusterName` `ContainerName`, `TaskDefinitionFamily`, `ClusterName`, `TaskId` `TaskDefinitionFamily`, `ClusterName`, `ContainerName` `ServiceName`, `ClusterName`, `ContainerName` | A memória reservada por contêineres no recurso especificado pelo conjunto de dimensões que você está usando. Essa métrica é coletada com base na reserva de memória especificada na definição da tarefa, podendo ser aplicada, por exemplo, no nível da tarefa ou de todos os contêineres. Se isso não estiver especificado na definição da tarefa, a reserva de memória da instância será usada. Também se aplica aos daemons gerenciados. Unidade: megabytes |
| `ContainerMemoryUtilization` | `ClusterName` `ContainerName`, `TaskId`, `ServiceName`, `ClusterName` `ContainerName`, `TaskDefinitionFamily`, `ClusterName`, `TaskId` `TaskDefinitionFamily`, `ClusterName`, `ContainerName` `ServiceName`, `ClusterName`, `ContainerName` | A porcentagem total da memória que está sendo usada por contêineres no recurso especificado pela definição de dimensões que você está usando. Também se aplica aos daemons gerenciados. Unidade: percentual |
| `ContainerNetworkRxBytes` | `TaskDefinitionFamily`, `ClusterName` `ServiceName`, `ClusterName` `ClusterName` `ClusterName`, `ServiceName`, `TaskId` `ClusterName`, `TaskDefinitionFamily`, `TaskId` | O número de bytes recebidos pelo contêiner especificado pelas dimensões que você está usando. Essa métrica é obtida com o runtime do Docker. Essa métrica está disponível apenas para contêineres em tarefas que usam os modos de rede `awsvpc` ou `bridge`. Também se aplica aos daemons gerenciados. Unidade: bytes/segundo |
| `ContainerNetworkTxBytes` | `TaskDefinitionFamily`, `ClusterName` `ServiceName`, `ClusterName` `ClusterName` `ClusterName`, `ServiceName`, `TaskId` `ClusterName`, `TaskDefinitionFamily`, `TaskId` | O número de bytes enviados pelo contêiner especificado pelas dimensões que você está usando. Essa métrica é obtida com o runtime do Docker. Essa métrica está disponível apenas para contêineres em tarefas que usam os modos de rede `awsvpc` ou `bridge`. Também se aplica aos daemons gerenciados. Unidade: bytes/segundo |
| `ContainerStorageReadBytes` | `ClusterName` `ClusterName`, `ServiceName`, `ContainerName` `ClusterName`, `TaskDefinitionFamily`, `ContainerName` `ClusterName`, `ServiceName`, `TaskId`, `ContainerName` `ClusterName`, `TaskDefinitionFamily`, `TaskId`, `ContainerName` | O número de bytes lidos do armazenamento no contêiner do recurso que é especificado pelas dimensões que você está usando. Isso não inclui bytes de leitura para seus dispositivos de armazenamento. Essa métrica é obtida com o runtime do Docker. Também se aplica aos daemons gerenciados. Unidade: bytes |
| `ContainerStorageWriteBytes` | `ClusterName` `ClusterName`, `ServiceName`, `ContainerName` `ClusterName`, `TaskDefinitionFamily`, `ContainerName` `ClusterName`, `ServiceName`, `TaskId`, `ContainerName` `ClusterName`, `TaskDefinitionFamily`, `TaskId`, `ContainerName` | O número de bytes gravados para armazenamento no contêiner especificado pelas dimensões que você está usando. Essa métrica é obtida com o runtime do Docker. Também se aplica aos daemons gerenciados. Unidade: bytes |
| `CpuUtilized` | `TaskDefinitionFamily`, `ClusterName` `ServiceName`, `ClusterName` `ClusterName` `ClusterName`, `ServiceName`, `TaskId` `ClusterName`, `TaskDefinitionFamily`, `TaskId` | As unidades de CPU utilizadas por tarefas no recurso especificado pela definição de dimensão que você está usando. Também se aplica aos daemons gerenciados. Unidade: nenhuma |
| `CpuReserved` | `TaskDefinitionFamily`, `ClusterName` `ServiceName`, `ClusterName` `ClusterName` `ClusterName`, `ServiceName`, `TaskId` `ClusterName`, `TaskDefinitionFamily`, `TaskId` | As unidades de CPU reservadas por tarefas no recurso especificado pelo conjunto de dimensões que você está usando. Essa métrica é coletada com base na reserva de CPU especificada na definição da tarefa, podendo ser aplicada, por exemplo, no nível da tarefa ou de todos os contêineres. Se isso não estiver especificado na definição da tarefa, a reserva de CPU da instância será usada. Também se aplica aos daemons gerenciados. Unidade: nenhuma |
| `DeploymentCount` | `ServiceName`, `ClusterName` | O número de implantações em um serviço do Amazon ECS. Unidade: Contagem |
| `DesiredTaskCount` | `ServiceName`, `ClusterName` | O número de tarefas desejadas para um serviço do Amazon ECS. Unidade: Contagem |
| `EBSFilesystemSize` | `ClusterName` ,`TaskDefinitionFamily`, `VolumeName` `TaskDefinitionFamily`, `ClusterName` `ServiceName`, `ClusterName` | A quantidade total, em gigabytes (GB), do armazenamento do sistema de arquivos do Amazon EBS alocada aos recursos especificados pelas dimensões que você está usando. Esta métrica só está disponível para tarefas executadas na infraestrutura do Amazon ECS executadas no Fargate usando a versão da plataforma `1.4.0` ou instâncias do Amazon EC2 usando a versão do agente de contêiner `1.79.0` ou posterior. Também se aplica aos daemons gerenciados. Unidade: gigabytes (GB) |
| `EBSFilesystemUtilized` | `ClusterName` ,`TaskDefinitionFamily`, `VolumeName` `TaskDefinitionFamily`, `ClusterName` `ServiceName`, `ClusterName` | A quantidade total, em gigabytes (GB), do armazenamento do sistema de arquivos do Amazon EBS usada pelos recursos especificados pelas dimensões que você está usando. Esta métrica só está disponível para tarefas executadas na infraestrutura do Amazon ECS executadas no Fargate usando a versão da plataforma `1.4.0` ou instâncias do Amazon EC2 usando a versão do agente de contêiner `1.79.0` ou posterior. Para tarefas executadas no Fargate, o Fargate reserva espaço no disco que é usado somente pelo Fargate. Não há custo associado ao espaço que Fargate usa, mas você verá esse armazenamento adicional usando ferramentas como `df`. Também se aplica aos daemons gerenciados. Unidade: gigabytes (GB) |
| `TaskEBSFilesystemUtilization` | `TaskDefinitionFamily`, `ClusterName` `ClusterName`, `ServiceName` `ClusterName` `ClusterName`, `ServiceName`, `TaskId` `TaskDefinitionFamily`, `ClusterName`, `TaskId` | A porcentagem do armazenamento do sistema de arquivos do Amazon EBS que está sendo usada pela tarefa especificada pelas dimensões que você está usando. Esta métrica só está disponível para tarefas executadas na infraestrutura do Amazon ECS executadas no Fargate usando a versão da plataforma `1.4.0` ou instâncias do Amazon EC2 usando a versão do agente de contêiner `1.79.0` ou posterior. Também se aplica aos daemons gerenciados. Unidade: percentual |
| EphemeralStorageReserved [1](#ci-enhanced-metrics-ecs-storage-fargate-note) | `TaskDefinitionFamily`, `ClusterName` `ServiceName`, `ClusterName` `ClusterName` `ClusterName`, `ServiceName`, `TaskId` `ClusterName`, `TaskDefinitionFamily`, `TaskId` | O número de bytes reservados no armazenamento efêmero do recurso, especificado pelas dimensões que você está usando. O armazenamento efêmero é usado para o sistema de arquivos raiz do contêiner e para qualquer volume de host de montagem por associação definido na imagem do contêiner e na definição da tarefa. A quantidade de armazenamento efêmero não pode ser alterada em uma tarefa em execução. Essa métrica só está disponível para tarefas executadas na plataforma Fargate Linux versão 1.4.0 ou posterior. Também se aplica aos daemons gerenciados. Unidade: gigabytes (GB) |
| EphemeralStorageUtilized [1](Container-Insights-metrics-ECS.md#ci-metrics-ecs-storage-fargate-note) | `ClusterName` `ClusterName`, `TaskDefinitionFamily` `ClusterName`, `ServiceName` `ClusterName`, `ServiceName`, `TaskId` `ClusterName`, `TaskDefinitionFamily`, `TaskId` | O número de bytes usados no armazenamento efêmero do recurso, especificado pelas dimensões que você está usando. O armazenamento efêmero é usado para o sistema de arquivos raiz do contêiner e para qualquer volume de host de montagem por associação definido na imagem do contêiner e na definição da tarefa. A quantidade de armazenamento efêmero não pode ser alterada em uma tarefa em execução. Essa métrica só está disponível para tarefas executadas na plataforma Fargate Linux versão 1.4.0 ou posterior. Também se aplica aos daemons gerenciados. Unidade: gigabytes (GB) |
| `MemoryUtilized` | `TaskDefinitionFamily`, `ClusterName` `ServiceName`, `ClusterName` `ClusterName` `ClusterName`, `ServiceName`, `TaskId` `ClusterName`, `TaskDefinitionFamily`, `TaskId` | A memória que está sendo usada pelas tarefas no recurso especificado pela definição de dimensões que você está usando. Também se aplica aos daemons gerenciados. Unidade: megabytes |
| `MemoryReserved` | `TaskDefinitionFamily`, `ClusterName` `ServiceName`, `ClusterName` `ClusterName` `ClusterName`, `ServiceName`, `TaskId` `ClusterName`, `TaskDefinitionFamily`, `TaskId` | A memória reservada por tarefas no recurso especificado pelo conjunto de dimensões que você está usando. Essa métrica é coletada com base na reserva de memória especificada na definição da tarefa, podendo ser aplicada, por exemplo, no nível da tarefa ou de todos os contêineres. Se isso não estiver especificado na definição da tarefa, a reserva de memória da instância será usada. Também se aplica aos daemons gerenciados. Unidade: megabytes |
| `NetworkRxBytes` | `TaskDefinitionFamily`, `ClusterName` `ServiceName`, `ClusterName` `ClusterName` `ClusterName`, `ServiceName`, `TaskId` `ClusterName`, `TaskDefinitionFamily`, `TaskId` | O número de bytes recebidos pelo recurso especificado por dimensões que você está usando. Essa métrica é obtida com o runtime do Docker. Essa métrica está disponível apenas para contêineres em tarefas que usam os modos de rede `awsvpc` ou `bridge`. Também se aplica aos daemons gerenciados. Unidade: bytes/segundo |
| `NetworkTxBytes` | `TaskDefinitionFamily`, `ClusterName` `ServiceName`, `ClusterName` `ClusterName` `ClusterName`, `ServiceName`, `TaskId` `ClusterName`, `TaskDefinitionFamily`, `TaskId` | O número de bytes enviados pelo recurso especificado pelas dimensões que você está usando. Essa métrica é obtida com o runtime do Docker. Essa métrica está disponível apenas para contêineres em tarefas que usam os modos de rede `awsvpc` ou `bridge`. Também se aplica aos daemons gerenciados. Unidade: bytes/segundo |
| `PendingTaskCount` | `ServiceName`, `ClusterName` | O número de tarefas que estão atualmente no estado `PENDING`. Unidade: Contagem |
| `RunningTaskCount` | `ServiceName`, `ClusterName` | O número de tarefas que estão atualmente no estado `RUNNING`. Unidade: Contagem |
| `RestartCount` | `ClusterName` `ClusterName`, `ServiceName` `ClusterName`, `TaskDefinitionFamily` `ClusterName`, `ServiceName`, `TaskId` `ClusterName`, `TaskDefinitionFamily`, `TaskId` `ClusterName`, `ServiceName`, `ContainerName` `ClusterName`, `ServiceName`, `TaskId`, `ContainerName` `TaskDefinitionFamily`, `ClusterName`, `ContainerName` `TaskDefinitionFamily`, `ClusterName`, `TaskId`, `ContainerName` | O número de vezes que um contêiner em uma tarefa do Amazon ECS foi reiniciado. Essa métrica é coletada apenas para contêineres com política de reinicialização habilitada. Também se aplica aos daemons gerenciados. Unidade: Contagem |
| `UnHealthyContainerHealthStatus` | `ClusterName` `ClusterName`, `ServiceName`, `ContainerName` `ClusterName`, `TaskDefinitionFamily`, `ContainerName` `ClusterName`, `ServiceName`, `TaskId`, `ContainerName` `ClusterName`, `TaskDefinitionFamily`, `TaskId`, `ContainerName` | O número de contêineres não íntegros com base no status da verificação de integridade do contêiner. Um contêiner é considerado não íntegro quando sua verificação de integridade retorna um status não íntegro. Essa métrica é coletada apenas para contêineres que tenham uma verificação de integridade configurada na definição da tarefa. O valor da métrica é 1 quando o status de integridade do contêiner é `UNHEALTHY`, e 0 quando o status de integridade é `HEALTHY`. Unidade: Contagem |
| `ServiceCount` | `ClusterName` | O número de serviços no cluster. Unidade: Contagem |
| `StorageReadBytes` | `TaskDefinitionFamily`, `ClusterName` `ServiceName`, `ClusterName` `ClusterName` `ClusterName`, `ServiceName`, `TaskId` `ClusterName`, `TaskDefinitionFamily`, `TaskId` | O número de bytes lidos do armazenamento na instância do recurso que é especificado pelas dimensões que você está usando. Isso não inclui bytes de leitura para seus dispositivos de armazenamento. Essa métrica é obtida com o runtime do Docker. Também se aplica aos daemons gerenciados. Unidade: bytes |
| `StorageWriteBytes` | `TaskDefinitionFamily`, `ClusterName` `ServiceName`, `ClusterName` `ClusterName` `ClusterName`, `ServiceName`, `TaskId` `ClusterName`, `TaskDefinitionFamily`, `TaskId` | O número de bytes gravados para armazenamento no recurso especificado pelas dimensões que você está usando. Essa métrica é obtida com o runtime do Docker. Também se aplica aos daemons gerenciados. Unidade: bytes |
| `TaskCount` | `ClusterName` | O número de tarefas em execução no cluster. Unidade: Contagem |
| `TaskCpuUtilization` | `TaskDefinitionFamily`, `ClusterName` `ServiceName`, `ClusterName` `ClusterName` `ClusterName`, `ServiceName`, `TaskId` `ClusterName`, `TaskDefinitionFamily`, `TaskId` | A porcentagem total de unidades de CPU que estão sendo usadas pela tarefa. Também se aplica aos daemons gerenciados. Unidade: percentual |
| `TaskEphemeralStorageUtilization` | `TaskDefinitionFamily`, `ClusterName` `ServiceName`, `ClusterName` `ClusterName` `ClusterName`, `ServiceName`, `TaskId` `ClusterName`, `TaskDefinitionFamily`, `TaskId` | A porcentagem total de armazenamento temporário utilizado por uma tarefa. Também se aplica aos daemons gerenciados. Unidade: percentual |
| `TaskMemoryUtilization` | `TaskDefinitionFamily`, `ClusterName` `ServiceName`, `ClusterName` `ClusterName` `ClusterName`, `ServiceName`, `TaskId` `ClusterName`, `TaskDefinitionFamily`, `TaskId` | A porcentagem total de memória sendo utilizada por uma tarefa. Também se aplica aos daemons gerenciados. Unidade: percentual |
| `TaskSetCount` | `ServiceName`, `ClusterName` | O número de conjuntos de tarefas no serviço. Unidade: Contagem |
**nota**
As métricas `EphemeralStorageReserved` e `EphemeralStorageUtilized` só estão disponíveis para tarefas que são executadas na plataforma Fargate Linux versão 1.4.0 ou posterior.
O Fargate reserva espaço no disco. Esse espaço é usado apenas pelo Fargate. Você não é cobrado por isso. Ele não é mostrado nessas métricas. Porém, você pode ver esse armazenamento adicional em outras ferramentas, como o `df`.
As métricas a seguir estarão disponíveis após concluir as etapas em [Implantar o atendente do CloudWatch para coletar métricas no nível de instância do EC2 no Amazon ECS](deploy-container-insights-ECS-instancelevel.md) e usar o tipo de inicialização do EC2.
| Nome da métrica | Dimensões | Descrição |
| --- | --- | --- |
| `instance_cpu_limit` | `ClusterName` | O número máximo de unidades de CPU que podem ser atribuídas a uma única instância do EC2 no cluster. Unidade: nenhuma |
| `instance_cpu_reserved_capacity` | `ClusterName` `InstanceId`, `ContainerInstanceId`, `ClusterName` | A porcentagem de CPU que está sendo reservada em uma única instância do EC2 no cluster. Unidade: percentual |
| `instance_cpu_usage_total` | `ClusterName` | O número de unidades de CPU que está sendo usada em uma única instância do EC2 no cluster. Unidade: nenhuma |
| `instance_cpu_utilization` | `ClusterName` `InstanceId`, `ContainerInstanceId`, `ClusterName` | A porcentagem total de unidades de CPU que estão sendo usadas em uma única instância do EC2 no cluster. Unidade: percentual |
| `instance_filesystem_utilization` | `ClusterName` `InstanceId`, `ContainerInstanceId`, `ClusterName` | A porcentagem total da capacidade do sistema de arquivos de que está sendo usada em uma única instância do EC2 no cluster. Unidade: percentual |
| `instance_memory_limit` | `ClusterName` | A quantidade máxima de memória, em bytes, que pode ser atribuída a uma única instância do EC2 no cluster. Unidade: bytes |
| `instance_memory_reserved_capacity` | `ClusterName` `InstanceId`, `ContainerInstanceId`, `ClusterName` | A porcentagem de memória que está atualmente sendo reservada em uma única instância do EC2 no cluster. Unidade: percentual |
| `instance_memory_utilization` | `ClusterName` `InstanceId`, `ContainerInstanceId`, `ClusterName` | A porcentagem total de memória que está sendo usada em uma única instância do EC2 no cluster. Se você estiver usando o coletor de resíduos Java ZGC para sua aplicação, essa métrica poderá ser imprecisa. Unidade: percentual |
| `instance_memory_working_set` | `ClusterName` | A quantidade de memória, em bytes, que está sendo usada em uma única instância do EC2 no cluster. Se você estiver usando o coletor de resíduos Java ZGC para sua aplicação, essa métrica poderá ser imprecisa. Unidade: bytes |
| `instance_network_total_bytes` | `ClusterName` | O número total de bytes por segundo transmitidos e recebidos pela rede um uma única instância do EC2 no cluster. Unidade: bytes/segundo |
| `instance_number_of_running_tasks` | `ClusterName` | O número de tarefas em execução em uma única instância do EC2 no cluster. Unidade: Contagem |
# Métricas Amazon ECS Container Insights
As métricas do Container Insights fornecem métricas adicionais de rede, armazenamento e armazenamento temporário. Essas métricas fornecem mais informações do que as métricas padrão do Amazon ECS. O Container Insights se integra ao CloudWatch Logs. Você pode correlacionar as alterações de métricas com as entradas de logs para facilitar a solução de problemas. O Container Insights também mostra estatísticas do cluster, do serviço e de todo o daemon calculando a média dos dados em todas as tarefas. Isso fornece uma visão de alto nível da integridade do seu serviço e daemon, auxiliando no monitoramento do ambiente e no planejamento da capacidade.
**Casos de uso**
+ **Identificação e solução de problemas**: rastreie as implantações com falha analisando os padrões de transição do estado da tarefa, o que possibilita a identificação rápida dos pontos de falha. Diagnostique problemas de configuração por meio de um exame abrangente das sequências de inicialização de tarefas e dos comportamentos de inicialização
+ **Avaliação da integridade de clusters e do nível de serviço**: mostra a performance média das tarefas em todo o cluster. Essa abordagem modera as discrepâncias para oferecer uma visão mais estável da integridade do cluster e do serviço. Use esses insights para monitoramento geral de serviços, em que valores extremos podem ser enganosos
+ **Problemas de disponibilidade de serviço**: detecte falhas de implantação monitorando as métricas de contagem de tarefas em execução. Correlacione logs de eventos de serviço com métricas de performance para entender os impactos na infraestrutura. Rastreie os padrões de reinicialização de tarefas para identificar serviços instáveis ou problemas de infraestrutura
+ **Planejamento de capacidade para carga média**: ajuda a determinar os requisitos de recursos com base em padrões típicos de comportamento de tarefas, fornece métricas consistentes que apoiam um planejamento eficaz de longo prazo e reduz o impacto de picos de curta duração nas decisões de capacidade
+ **Fornece métricas adicionais**: coleta métricas adicionais de rede, armazenamento e armazenamento efêmero não disponíveis nas métricas fornecidas
Para obter informações sobre as métricas do Amazon ECS, consulte [Casos de uso de métricas de utilização do serviço do Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service_utilization-metrics-explanation.html), e para obter informações sobre insights de contêineres com observabilidade aprimorada, consulte [Métricas do Container Insights com observabilidade aprimorada para o Amazon ECS](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Container-Insights-enhanced-observability-metrics-ECS.html).
**nota**
As métricas do daemon gerenciado do Amazon ECS usam o mesmo namespace `ECS/ContainerInsights` e a mesma dimensão `ServiceName` das métricas de serviço. Para métricas do daemon, o valor da dimensão `ServiceName` usa o formato `daemon:daemon-name`. Por exemplo, um daemon denominado `my-daemon` tem um valor de dimensão `ServiceName` de `daemon:my-daemon`. Todas as métricas na tabela abaixo que incluem a dimensão `ServiceName` também se aplicam aos daemons gerenciados.
A tabela a seguir lista as métricas e as dimensões que o Container Insights coleta para Amazon ECS. Essas métricas estão no namespace `ECS/ContainerInsights`. Para obter mais informações, consulte [Métricas](cloudwatch_concepts.md#Metric).
Se você não vir as métricas do Container Insights no seu console, certifique-se de que você tenha concluído a configuração do Container Insights. As métricas não serão exibidas até que o Container Insights tenha sido configurado completamente. Para obter mais informações, consulte [Configurar o Container Insights](deploy-container-insights.md).
As métricas a seguir estarão disponíveis após a conclusão das etapas em [Configurar o Container Insights no Amazon ECS](deploy-container-insights-ECS-cluster.md).
| Nome da métrica | Dimensões | Descrição |
| --- | --- | --- |
| `ContainerInstanceCount` | `ClusterName` | O número de instâncias do EC2 que executam o atendente do Amazon ECS registrado com um cluster. Essa métrica é coletada apenas para instâncias de contêineres que estão executando tarefas do Amazon ECS no cluster. Ela não é coletada para instâncias de contêineres vazios que não têm nenhuma tarefa do Amazon ECS. Unidade: Contagem |
| `CpuUtilized` | `TaskDefinitionFamily`, `ClusterName` `ServiceName`, `ClusterName` `ClusterName` | As unidades de CPU utilizadas por tarefas no recurso especificado pela definição de dimensão que você está usando. Também se aplica aos daemons gerenciados. Unidade: nenhuma |
| `CpuReserved` | `TaskDefinitionFamily`, `ClusterName` `ServiceName`, `ClusterName` `ClusterName` | As unidades de CPU reservadas por tarefas no recurso especificado pelo conjunto de dimensões que você está usando. Essa métrica é coletada com base na reserva de CPU especificada na definição da tarefa, podendo ser aplicada, por exemplo, no nível da tarefa ou de todos os contêineres. Se isso não estiver especificado na definição da tarefa, a reserva de CPU da instância será usada. Também se aplica aos daemons gerenciados. Unidade: nenhuma |
| `DeploymentCount` | `ServiceName`, `ClusterName` | O número de implantações em um serviço do Amazon ECS. Unidade: Contagem |
| `DesiredTaskCount` | `ServiceName`, `ClusterName` | O número de tarefas desejadas para um serviço do Amazon ECS. Unidade: Contagem |
| `EBSFilesystemSize` | `VolumeName`, `TaskDefinitionFamily`, `ClusterName` `TaskDefinitionFamily`, `ClusterName` `ServiceName`, `ClusterName` | A quantidade total, em gigabytes (GB), do armazenamento do sistema de arquivos do Amazon EBS alocada aos recursos especificados pelas dimensões que você está usando. Esta métrica só está disponível para tarefas executadas na infraestrutura do Amazon ECS executadas no Fargate usando a versão da plataforma `1.4.0` ou instâncias do Amazon EC2 usando a versão do agente de contêiner `1.79.0` ou posterior. Também se aplica aos daemons gerenciados. Unidade: gigabytes (GB) |
| `EBSFilesystemUtilized` | `VolumeName`, `TaskDefinitionFamily`, `ClusterName` `TaskDefinitionFamily`, `ClusterName` `ServiceName`, `ClusterName` | A quantidade total, em gigabytes (GB), do armazenamento do sistema de arquivos do Amazon EBS usada pelos recursos especificados pelas dimensões que você está usando. Esta métrica só está disponível para tarefas executadas na infraestrutura do Amazon ECS executadas no Fargate usando a versão da plataforma `1.4.0` ou instâncias do Amazon EC2 usando a versão do agente de contêiner `1.79.0` ou posterior. Para tarefas executadas no Fargate, o Fargate reserva espaço no disco que é usado somente pelo Fargate. Não há custo associado ao espaço que Fargate usa, mas você verá esse armazenamento adicional usando ferramentas como `df`. Também se aplica aos daemons gerenciados. Unidade: gigabytes (GB) |
| EphemeralStorageReserved [1](#ci-metrics-ecs-storage-fargate-note) | `TaskDefinitionFamily`, `ClusterName` `ServiceName`, `ClusterName` `ClusterName` | O número de bytes reservados no armazenamento efêmero do recurso, especificado pelas dimensões que você está usando. O armazenamento efêmero é usado para o sistema de arquivos raiz do contêiner e para qualquer volume de host de montagem por associação definido na imagem do contêiner e na definição da tarefa. A quantidade de armazenamento efêmero não pode ser alterada em uma tarefa em execução. Essa métrica só está disponível para tarefas executadas na plataforma Fargate Linux versão 1.4.0 ou posterior. Também se aplica aos daemons gerenciados. Unidade: gigabytes (GB) |
| EphemeralStorageUtilized [1](#ci-metrics-ecs-storage-fargate-note) | `TaskDefinitionFamily`, `ClusterName` `ServiceName`, `ClusterName` `ClusterName` | O número de bytes usados no armazenamento efêmero do recurso, especificado pelas dimensões que você está usando. O armazenamento efêmero é usado para o sistema de arquivos raiz do contêiner e para qualquer volume de host de montagem por associação definido na imagem do contêiner e na definição da tarefa. A quantidade de armazenamento efêmero não pode ser alterada em uma tarefa em execução. Essa métrica só está disponível para tarefas executadas na plataforma Fargate Linux versão 1.4.0 ou posterior. Também se aplica aos daemons gerenciados. Unidade: gigabytes (GB) |
| `InstanceOSFilesystemUtilization` | `CapacityProviderName`, `ClusterName`, `ContainerInstanceId`, `EC2InstanceId` `ClusterName` | A porcentagem do total de espaço em disco que é usado para volume do sistema operacional. |
| `InstanceDataFilesystemUtilization` | `CapacityProviderName`, `ClusterName`, `ContainerInstanceId`, `EC2InstanceId` `ClusterName` | A porcentagem do total de espaço em disco que é usado para volume de dados. |
| `MemoryUtilized` | `TaskDefinitionFamily`, `ClusterName` `ServiceName`, `ClusterName` `ClusterName` | A memória que está sendo usada pelas tarefas no recurso especificado pela definição de dimensões que você está usando. Se você estiver usando o coletor de resíduos Java ZGC para sua aplicação, essa métrica poderá ser imprecisa. Apesar de `MemoryUtilized` e `MemoryReserved` estarem com marcações de “Megabytes”, as unidades usadas são, na verdade, MiB (Mebibytes). Também se aplica aos daemons gerenciados. Unidade: megabytes |
| `MemoryReserved` | `TaskDefinitionFamily`, `ClusterName` `ServiceName`, `ClusterName` `ClusterName` | A memória reservada por tarefas no recurso especificado pelo conjunto de dimensões que você está usando. Essa métrica é coletada com base na reserva de memória especificada na definição da tarefa, podendo ser aplicada, por exemplo, no nível da tarefa ou de todos os contêineres. Se isso não estiver especificado na definição da tarefa, a reserva de memória da instância será usada. Também se aplica aos daemons gerenciados. Unidade: megabytes Apesar de `MemoryUtilized` e `MemoryReserved` estarem com marcações de “Megabytes”, as unidades usadas são, na verdade, MiB (Mebibytes). |
| `NetworkRxBytes` | `TaskDefinitionFamily`, `ClusterName` `ServiceName`, `ClusterName` `ClusterName` | O número de bytes recebidos pelo recurso especificado por dimensões que você está usando. Essa métrica é obtida com o runtime do Docker. Essa métrica está disponível apenas para contêineres em tarefas que usam os modos de rede `awsvpc` ou `bridge`. Também se aplica aos daemons gerenciados. Unidade: bytes/segundo |
| `NetworkTxBytes` | `TaskDefinitionFamily`, `ClusterName` `ServiceName`, `ClusterName` `ClusterName` | O número de bytes enviados pelo recurso especificado pelas dimensões que você está usando. Essa métrica é obtida com o runtime do Docker. Essa métrica está disponível apenas para contêineres em tarefas que usam os modos de rede `awsvpc` ou `bridge`. Também se aplica aos daemons gerenciados. Unidade: bytes/segundo |
| `PendingTaskCount` | `ServiceName`, `ClusterName` | O número de tarefas que estão atualmente no estado `PENDING`. Unidade: Contagem |
| `RunningTaskCount` | `ServiceName`, `ClusterName` | O número de tarefas que estão atualmente no estado `RUNNING`. Unidade: Contagem |
| `RestartCount` | `ClusterName` `ClusterName`, `ServiceName` `ClusterName`, `TaskDefinitionFamily` | O número de vezes que um contêiner em uma tarefa do Amazon ECS foi reiniciado. Essa métrica é coletada apenas para contêineres com política de reinicialização habilitada. Também se aplica aos daemons gerenciados. Unidade: Contagem |
| `ServiceCount` | `ClusterName` | O número de serviços no cluster. Unidade: Contagem |
| `StorageReadBytes` | `TaskDefinitionFamily`, `ClusterName` `ServiceName`, `ClusterName` `ClusterName` | O número de bytes lidos do armazenamento na instância do recurso que é especificado pelas dimensões que você está usando. Isso não inclui bytes de leitura para seus dispositivos de armazenamento. Essa métrica é obtida com o runtime do Docker. Também se aplica aos daemons gerenciados. Unidade: bytes |
| `StorageWriteBytes` | `TaskDefinitionFamily`, `ClusterName` `ServiceName`, `ClusterName` `ClusterName` | O número de bytes gravados para armazenamento no recurso especificado pelas dimensões que você está usando. Essa métrica é obtida com o runtime do Docker. Também se aplica aos daemons gerenciados. Unidade: bytes |
| `TaskCount` | `ClusterName` | O número de tarefas em execução no cluster. Unidade: Contagem |
| `TaskSetCount` | `ServiceName`, `ClusterName` | O número de conjuntos de tarefas no serviço. Unidade: Contagem |
**nota**
As métricas `EphemeralStorageReserved` e `EphemeralStorageUtilized` só estão disponíveis para tarefas que são executadas na plataforma Fargate Linux versão 1.4.0 ou posterior.
O Fargate reserva espaço no disco. Esse espaço é usado apenas pelo Fargate. Você não é cobrado por isso. Ele não é mostrado nessas métricas. Porém, você pode ver esse armazenamento adicional em outras ferramentas, como o `df`.
As métricas a seguir estarão disponíveis após a conclusão das etapas em [Implantar o atendente do CloudWatch para coletar métricas no nível de instância do EC2 no Amazon ECS](deploy-container-insights-ECS-instancelevel.md)
| Nome da métrica | Dimensões | Descrição |
| --- | --- | --- |
| `instance_cpu_limit` | `ClusterName` | O número máximo de unidades de CPU que podem ser atribuídas a uma única instância do EC2 no cluster. Unidade: nenhuma |
| `instance_cpu_reserved_capacity` | `ClusterName` `InstanceId`, `ContainerInstanceId`, `ClusterName` | A porcentagem de CPU que está sendo reservada em uma única instância do EC2 no cluster. Unidade: percentual |
| `instance_cpu_usage_total` | `ClusterName` | O número de unidades de CPU que está sendo usada em uma única instância do EC2 no cluster. Unidade: nenhuma |
| `instance_cpu_utilization` | `ClusterName` `InstanceId`, `ContainerInstanceId`, `ClusterName` | A porcentagem total de unidades de CPU que estão sendo usadas em uma única instância do EC2 no cluster. Unidade: percentual |
| `instance_filesystem_utilization` | `ClusterName` `InstanceId`, `ContainerInstanceId`, `ClusterName` | A porcentagem total da capacidade do sistema de arquivos de que está sendo usada em uma única instância do EC2 no cluster. Unidade: percentual |
| `instance_memory_limit` | `ClusterName` | A quantidade máxima de memória, em bytes, que pode ser atribuída a uma única instância do EC2 nesse cluster. Unidade: bytes |
| `instance_memory_reserved_capacity` | `ClusterName` `InstanceId`, `ContainerInstanceId`, `ClusterName` | A porcentagem de memória que está sendo reservada em uma única instância do EC2 no cluster. Unidade: percentual |
| `instance_memory_utilization` | `ClusterName` `InstanceId`, `ContainerInstanceId`, `ClusterName` | A porcentagem total de memória que está sendo usada em uma única instância do EC2 no cluster. Se você estiver usando o coletor de resíduos Java ZGC para sua aplicação, essa métrica poderá ser imprecisa. Unidade: percentual |
| `instance_memory_working_set` | `ClusterName` | A quantidade de memória, em bytes, que está sendo usada em uma única instância do EC2 no cluster. Se você estiver usando o coletor de resíduos Java ZGC para sua aplicação, essa métrica poderá ser imprecisa. Unidade: bytes |
| `instance_network_total_bytes` | `ClusterName` | O número total de bytes por segundo transmitidos e recebidos pela rede um uma única instância do EC2 no cluster. Unidade: bytes/segundo |
| `instance_number_of_running_tasks` | `ClusterName` | O número de tarefas em execução em uma única instância do EC2 no cluster. Unidade: Contagem |
# Métricas do Container Insights com observabilidade aprimorada para o Amazon EKS e o Kubernetes
As tabelas a seguir listam as métricas e as dimensões que o Container Insights com observabilidade aprimorada coleta para o Amazon EKS e o Kubernetes. Essas métricas estão no namespace `ContainerInsights`. Para obter mais informações, consulte [Métricas](cloudwatch_concepts.md#Metric).
Se você não vir as métricas do Container Insights com observabilidade aprimorada no console, certifique-se de que você concluiu a configuração do Container Insights com observabilidade aprimorada. As métricas não serão exibidas até que o Container Insights com observabilidade aprimorada tenha sido configurado completamente. Para obter mais informações, consulte [Configurar o Container Insights](deploy-container-insights.md).
Se você estiver usando a versão 1.5.0 ou versões posteriores do complemento do Amazon EKS ou a versão 1.300035.0 do agente do CloudWatch, a maioria das métricas listadas na tabela a seguir será coletada para nós nos sistemas Linux e Windows. Consulte a coluna **Nome da métrica** da tabela para visualizar quais métricas não são coletadas para o Windows.
Com a versão anterior do Container Insights, que fornece métricas agregadas no nível de cluster e de serviço, as métricas são cobradas como métricas personalizadas. Com o Container Insights com capacidade de observabilidade aprimorada para o Amazon EKS, as métricas do Container Insights são cobradas por observação, em vez de serem cobradas por métrica armazenada ou log ingerido. Para obter mais informações sobre os preços do CloudWatch, consulte [Preço do Amazon CloudWatch](https://aws.amazon.com/cloudwatch/pricing/).
**nota**
No Windows, métricas de rede, como `pod_network_rx_bytes` e `pod_network_tx_bytes`, não são coletadas para a hospedagem de contêineres de processos.
Em clusters do RedHat OpenShift na AWS (ROSA), métricas de diskio, como `node_diskio_io_serviced_total` e `node_diskio_io_service_bytes_total`, não são coletadas.
| Nome da métrica | Dimensões | Descrição |
| --- | --- | --- |
| `cluster_failed_node_count` | `ClusterName` | O número de nós do operador com falha no cluster. Um nó é considerado com falha quando apresenta qualquer *condição de nó*. Para obter mais informações, consulte [Condições](https://kubernetes.io/docs/concepts/architecture/nodes/#condition) na documentação do Kubernetes. |
| `cluster_node_count` | `ClusterName` | O número total de nós do operador no cluster. |
| `namespace_number_of_running_pods` | `Namespace` `ClusterName` `ClusterName` | O número de pods em execução por namespace no recurso especificado pelas dimensões que você está usando. |
| `node_cpu_limit` | `ClusterName` `ClusterName`, `InstanceId`, `NodeName` | O número máximo de unidades de CPU que pode ser atribuído a um único nó neste cluster. |
| `node_cpu_reserved_capacity` | `NodeName`, `ClusterName`, `InstanceId` `ClusterName` | A porcentagem de unidades de CPU reservadas para componentes do nó, como kubelet, kube-proxy e Docker. Fórmula: `node_cpu_request / node_cpu_limit` `node_cpu_request` não é relatado diretamente como uma métrica, mas é um campo em eventos de log de performance. Para obter mais informações, consulte [Campos relevantes nos eventos de log de performance para Amazon EKS e Kubernetes](Container-Insights-reference-performance-entries-EKS.md). |
| `node_cpu_usage_total` | `ClusterName` `ClusterName`, `InstanceId`, `NodeName` | O número de unidades da CPU que está sendo usado nos nós do cluster. |
| `node_cpu_utilization` | `NodeName`, `ClusterName`, `InstanceId` `ClusterName` | A porcentagem total de unidades de CPU que está sendo usada nos nós do cluster. Fórmula: `node_cpu_usage_total / node_cpu_limit` |
| `node_filesystem_utilization` | `NodeName`, `ClusterName`, `InstanceId` `ClusterName` | A porcentagem total da capacidade do sistema de arquivos que está sendo usado nos nós do cluster. Fórmula: `node_filesystem_usage / node_filesystem_capacity` `node_filesystem_usage` e `node_filesystem_capacity` não são relatados diretamente como métricas, mas são campos em eventos de log de performance. Para obter mais informações, consulte [Campos relevantes nos eventos de log de performance para Amazon EKS e Kubernetes](Container-Insights-reference-performance-entries-EKS.md). |
| `node_memory_limit` | `ClusterName` `ClusterName`, `InstanceId`, `NodeName` | A quantidade máxima de memória, em bytes, que pode ser atribuída a um único nó neste cluster. |
| `node_filesystem_inodes` Não está disponível no Windows. | `ClusterName` `ClusterName`, `InstanceId`, `NodeName` | O número total de inodes (usados e não usados) em um nó. |
| `node_filesystem_inodes_free` Não está disponível no Windows. | `ClusterName` `ClusterName`, `InstanceId`, `NodeName` | O número de inodes não utilizados em um nó. |
| `node_gpu_limit` | `ClusterName` `ClusterName`, `InstanceId`, `NodeName` | O número total de GPUs disponíveis no nó. |
| `node_gpu_usage_total` | `ClusterName` `ClusterName`, `InstanceId`, `NodeName` | O número de GPUs em uso pelos pods em execução no nó. |
| `node_gpu_reserved_capacity` | `ClusterName` `ClusterName`, `InstanceId`, `NodeName` |
| `node_memory_reserved_capacity` | `NodeName`, `ClusterName`, `InstanceId` `ClusterName` | A porcentagem de memória que está sendo usada no momento nos nós do cluster. Fórmula: `node_memory_request / node_memory_limit` `node_memory_request` não é relatado diretamente como uma métrica, mas é um campo em eventos de log de performance. Para obter mais informações, consulte [Campos relevantes nos eventos de log de performance para Amazon EKS e Kubernetes](Container-Insights-reference-performance-entries-EKS.md). |
| `node_memory_utilization` | `NodeName`, `ClusterName`, `InstanceId` `ClusterName` | A porcentagem de memória que está sendo usada no momento pelo nó ou nós. É o percentual de uso de memória de nó dividido pela limitação de memória de nó. Fórmula: `node_memory_working_set / node_memory_limit`. |
| `node_memory_working_set` | `ClusterName` `ClusterName`, `InstanceId`, `NodeName` | A quantidade de memória, em bytes, sendo usada no conjunto de trabalho dos nós no cluster. |
| `node_network_total_bytes` | `NodeName`, `ClusterName`, `InstanceId` `ClusterName` | O número total de bytes transmitidos e recebidos por segundo pela rede por nó em um cluster. Fórmula: `node_network_rx_bytes + node_network_tx_bytes` `node_network_rx_bytes` e `node_network_tx_bytes` não são relatados diretamente como métricas, mas são campos em eventos de log de performance. Para obter mais informações, consulte [Campos relevantes nos eventos de log de performance para Amazon EKS e Kubernetes](Container-Insights-reference-performance-entries-EKS.md). |
| `node_number_of_running_containers` | `NodeName`, `ClusterName`, `InstanceId` `ClusterName` | O número de contêineres em execução por nó em um cluster. |
| `node_number_of_running_pods` | `NodeName`, `ClusterName`, `InstanceId` `ClusterName` | O número de pods em execução por nó em um cluster. |
| `node_status_allocatable_pods` | `ClusterName` `ClusterName`, `InstanceId`, `NodeName` | O número de pods que podem ser atribuídos a um nó com base em seus recursos alocáveis, que é definido como o restante da capacidade de um nó depois de contabilizar as reservas de daemons do sistema e os limites de remoção rígidos. |
| `node_status_capacity_pods` | `ClusterName` `ClusterName`, `InstanceId`, `NodeName` | O número de pods que podem ser atribuídos a um nó com base em sua capacidade. |
| `node_status_condition_ready` | `ClusterName` `ClusterName`, `InstanceId`, `NodeName` | Indica se a condição de status do nó `Ready` é verdadeira para nós do Amazon EC2. |
| `node_status_condition_memory_pressure` | `ClusterName` `ClusterName`, `InstanceId`, `NodeName` | Indica se a condição de status do nó `MemoryPressure` é verdadeira. |
| `node_status_condition_pid_pressure` | `ClusterName` `ClusterName`, `InstanceId`, `NodeName` | Indica se a condição de status do nó `PIDPressure` é verdadeira. |
| `node_status_condition_disk_pressure` | `ClusterName` `ClusterName`, `InstanceId`, `NodeName` | Indica se a condição de status do nó `OutOfDisk` é verdadeira. |
| `node_status_condition_unknown` | `ClusterName` `ClusterName`, `InstanceId`, `NodeName` | Indica se alguma das condições de status do nó é Desconhecida. |
| `node_interface_network_rx_dropped` | `ClusterName` `ClusterName`, `InstanceId`, `NodeName` | O número de pacotes que foram recebidos e posteriormente descartados por uma interface de rede no nó. |
| `node_interface_network_tx_dropped` | `ClusterName` `ClusterName`, `InstanceId`, `NodeName` | O número de pacotes que deveriam ser transmitidos, mas foram descartados por uma interface de rede no nó. |
| `node_diskio_io_service_bytes_total` Não está disponível em clusters do Windows nem do ROSA. | `ClusterName` `ClusterName`, `InstanceId`, `NodeName` | O número total de bytes transferidos por todas as operações de E/S no nó. |
| `node_diskio_io_serviced_total` Não está disponível em clusters do Windows nem do ROSA. | `ClusterName` `ClusterName`, `InstanceId`, `NodeName` | O número total de operações de E/S no nó. |
| `pod_cpu_reserved_capacity` | `PodName`, `Namespace`, `ClusterName` `ClusterName` `ClusterName`, `Namespace`, `PodName`, `FullPodName` `ClusterName`, `Namespace`, `Service` | A capacidade da CPU reservada por pod em um cluster. Fórmula: `pod_cpu_request / node_cpu_limit` `pod_cpu_request` não é relatado diretamente como uma métrica, mas é um campo em eventos de log de performance. Para obter mais informações, consulte [Campos relevantes nos eventos de log de performance para Amazon EKS e Kubernetes](Container-Insights-reference-performance-entries-EKS.md). |
| `pod_cpu_utilization` | `PodName`, `Namespace`, `ClusterName` `Namespace`, `ClusterName` `Service`, `Namespace`, `ClusterName` `ClusterName` `ClusterName`, `Namespace`, `PodName`, `FullPodName` | A porcentagem de unidades de CPU que estão sendo usadas por pods. Fórmula: `pod_cpu_usage_total / node_cpu_limit` |
| `pod_cpu_utilization_over_pod_limit` | `PodName`, `Namespace`, `ClusterName` `Namespace`, `ClusterName` `Service`, `Namespace`, `ClusterName` `ClusterName` `ClusterName`, `Namespace`, `PodName`, `FullPodName` | O percentual das unidades de CPU que estão sendo usadas por pods com relação ao limite de pods. Fórmula: `pod_cpu_usage_total / pod_cpu_limit` |
| `pod_memory_reserved_capacity` | `PodName`, `Namespace`, `ClusterName` `ClusterName` `ClusterName`, `Namespace`, `PodName`, `FullPodName` `ClusterName`, `Namespace`, `Service` | A porcentagem de memória reservada para pods. Fórmula: `pod_memory_request / node_memory_limit` `pod_memory_request` não é relatado diretamente como uma métrica, mas é um campo em eventos de log de performance. Para obter mais informações, consulte [Campos relevantes nos eventos de log de performance para Amazon EKS e Kubernetes](Container-Insights-reference-performance-entries-EKS.md). |
| `pod_memory_utilization` | `PodName`, `Namespace`, `ClusterName` `Namespace`, `ClusterName` `Service`, `Namespace`, `ClusterName` `ClusterName` `ClusterName`, `Namespace`, `PodName`, `FullPodName` | A porcentagem de memória que está sendo usada atualmente pelo pod ou pods. Fórmula: `pod_memory_working_set / node_memory_limit` |
| `pod_memory_utilization_over_pod_limit` | `PodName`, `Namespace`, `ClusterName` `Namespace`, `ClusterName` `Service`, `Namespace`, `ClusterName` `ClusterName` `ClusterName`, `Namespace`, `PodName`, `FullPodName` | O percentual de memória que está sendo usada por pods com relação ao limite de pods. Se qualquer contêiner no pod não tiver um limite de memória definido, essa métrica não aparecerá. Fórmula: `pod_memory_working_set / pod_memory_limit` |
| `pod_network_rx_bytes` | `PodName`, `Namespace`, `ClusterName` `Namespace`, `ClusterName` `Service`, `Namespace`, `ClusterName` `ClusterName` `ClusterName`, `Namespace`, `PodName`, `FullPodName` | O número de bytes que estão sendo recebidos por segundo na rede pelo pod. Fórmula: `sum(pod_interface_network_rx_bytes)` `pod_interface_network_rx_bytes` não é relatado diretamente como uma métrica, mas é um campo em eventos de log de performance. Para obter mais informações, consulte [Campos relevantes nos eventos de log de performance para Amazon EKS e Kubernetes](Container-Insights-reference-performance-entries-EKS.md). |
| `pod_network_tx_bytes` | `PodName`, `Namespace`, `ClusterName` `Namespace,` `ClusterName` `Service`, `Namespace`, `ClusterName` `ClusterName` `ClusterName`, `Namespace`, `PodName`, `FullPodName` | O número de bytes que estão sendo transmitidos por segundo na rede pelo pod. Fórmula: `sum(pod_interface_network_tx_bytes)` `pod_interface_network_tx_bytes` não é relatado diretamente como uma métrica, mas é um campo em eventos de log de performance. Para obter mais informações, consulte [Campos relevantes nos eventos de log de performance para Amazon EKS e Kubernetes](Container-Insights-reference-performance-entries-EKS.md). |
| `pod_cpu_request` | `ClusterName` `PodName`, `Namespace`, `ClusterName` `Namespace`, `ClusterName`, `Service` `ClusterName`, `Namespace`, `PodName`, `FullPodName` | As solicitações da CPU para o pod. Fórmula: `sum(container_cpu_request)` `pod_cpu_request` não é relatado diretamente como uma métrica, mas é um campo em eventos de log de performance. Para obter mais informações, consulte [Campos relevantes nos eventos de log de performance para Amazon EKS e Kubernetes](Container-Insights-reference-performance-entries-EKS.md). |
| `pod_memory_request` | `ClusterName` `PodName`, `Namespace`, `ClusterName` `Namespace`, `ClusterName`, `Service` `ClusterName`, `Namespace`, `PodName`, `FullPodName` | As solicitações de memória para o pod. Fórmula: `sum(container_memory_request)` `pod_memory_request` não é relatado diretamente como uma métrica, mas é um campo em eventos de log de performance. Para obter mais informações, consulte [Campos relevantes nos eventos de log de performance para Amazon EKS e Kubernetes](Container-Insights-reference-performance-entries-EKS.md). |
| `pod_cpu_limit` | `ClusterName` `PodName`, `Namespace`, `ClusterName` `Namespace`, `ClusterName`, `Service` `ClusterName`, `Namespace`, `PodName`, `FullPodName` | O limite de CPU definido para os contêineres no pod. Se algum contêiner no pod não tiver um limite de CPU definido, essa métrica não será exibida. Fórmula: `sum(container_cpu_limit)` `pod_cpu_limit` não é relatado diretamente como uma métrica, mas é um campo em eventos de log de performance. Para obter mais informações, consulte [Campos relevantes nos eventos de log de performance para Amazon EKS e Kubernetes](Container-Insights-reference-performance-entries-EKS.md). |
| `pod_memory_limit` | `ClusterName` `PodName`, `Namespace`, `ClusterName` `Namespace`, `ClusterName`, `Service` `ClusterName`, `Namespace`, `PodName`, `FullPodName` | O limite de memória definido para os contêineres no pod. Se qualquer contêiner no pod não tiver um limite de memória definido, essa métrica não aparecerá. Fórmula: `sum(container_memory_limit)` `pod_cpu_limit` não é relatado diretamente como uma métrica, mas é um campo em eventos de log de performance. Para obter mais informações, consulte [Campos relevantes nos eventos de log de performance para Amazon EKS e Kubernetes](Container-Insights-reference-performance-entries-EKS.md). |
| `pod_status_failed` | `ClusterName` `PodName`, `Namespace`, `ClusterName` `Namespace`, `ClusterName`, `Service` `ClusterName`, `Namespace`, `PodName`, `FullPodName` | Indica que todos os contêineres no pod foram encerrados, e pelo menos um contêiner foi encerrado com um status diferente de zero ou foi encerrado pelo sistema. |
| `pod_status_ready` | `ClusterName` `PodName`, `Namespace`, `ClusterName` `Namespace`, `ClusterName`, `Service` `ClusterName`, `Namespace`, `PodName`, `FullPodName` | Indica que todos os contêineres no pod estão prontos, tendo atingido a condição `ContainerReady`. |
| `pod_status_running` | `ClusterName` `PodName`, `Namespace`, `ClusterName` `Namespace`, `ClusterName`, `Service` `ClusterName`, `Namespace`, `PodName`, `FullPodName` | Indica que todos os contêineres no pod estão em execução. |
| `pod_status_scheduled` | `ClusterName` `PodName`, `Namespace`, `ClusterName` `Namespace`, `ClusterName`, `Service` `ClusterName`, `Namespace`, `PodName`, `FullPodName` | Indica que o pod foi agendado para um nó. |
| `pod_status_unknown` | `ClusterName` `PodName`, `Namespace`, `ClusterName` `Namespace`, `ClusterName`, `Service` `ClusterName`, `Namespace`, `PodName`, `FullPodName` | Indica que o status do pod não pode ser obtido. |
| `pod_status_pending` | `ClusterName` `PodName`, `Namespace`, `ClusterName` `Namespace`, `ClusterName`, `Service` `ClusterName`, `Namespace`, `PodName`, `FullPodName` | Indica que o pod foi aceito pelo cluster, mas um ou mais contêineres ainda não estão prontos. |
| `pod_status_succeeded` | `ClusterName` `PodName`, `Namespace`, `ClusterName` `Namespace`, `ClusterName`, `Service` `ClusterName`, `Namespace`, `PodName`, `FullPodName` | Indica que todos os contêineres no pod foram encerrados com êxito e não serão reiniciados. |
| `pod_number_of_containers` | `ClusterName` `PodName`, `Namespace`, `ClusterName` `Namespace`, `ClusterName`, `Service` `ClusterName`, `Namespace`, `PodName`, `FullPodName` | Relata o número de contêineres definidos na especificação do pod. |
| `pod_number_of_running_containers` | `ClusterName` `PodName`, `Namespace`, `ClusterName` `Namespace`, `ClusterName`, `Service` `ClusterName`, `Namespace`, `PodName`, `FullPodName` | Relata o número de contêineres no pod que estão atualmente no estado `Running`. |
| `pod_container_status_terminated` | `ClusterName` `PodName`, `Namespace`, `ClusterName` `Namespace`, `ClusterName`, `Service` `ClusterName`, `Namespace`, `PodName`, `FullPodName` | Relata o número de contêineres no pod que estão no estado `Terminated`. |
| `pod_container_status_running` | `ClusterName` `PodName`, `Namespace`, `ClusterName` `Namespace`, `ClusterName`, `Service` `ClusterName`, `Namespace`, `PodName`, `FullPodName` | Relata o número de contêineres no pod que estão no estado `Running`. |
| `pod_container_status_waiting` | `ClusterName` `PodName`, `Namespace`, `ClusterName` `Namespace`, `ClusterName`, `Service` `ClusterName`, `Namespace`, `PodName`, `FullPodName` | Relata o número de contêineres no pod que estão no estado `Waiting`. |
| `pod_container_status_waiting_reason_crash_loop_back_off` | `ClusterName` `PodName`, `Namespace`, `ClusterName` `Namespace`, `ClusterName`, `Service` `ClusterName`, `Namespace`, `PodName`, `FullPodName` | Relata o número de contêineres no pod que estão pendentes devido a um erro `CrashLoopBackOff`, em que um contêiner falha repetidamente ao iniciar. |
| `pod_container_status_waiting_reason_create_container_config_error` | `ClusterName` `PodName`, `Namespace`, `ClusterName` `Namespace`, `ClusterName`, `Service` `ClusterName`, `Namespace`, `PodName`, `FullPodName` | Relata o número de contêineres no pod que estão pendentes com o motivo `CreateContainerConfigError`. Isso ocorre devido a um erro ao criar a configuração do contêiner. |
| `pod_container_status_waiting_reason_create_container_error` | `ClusterName` `PodName`, `Namespace`, `ClusterName` `Namespace`, `ClusterName`, `Service` `ClusterName`, `Namespace`, `PodName`, `FullPodName` | Relata o número de contêineres no pod que estão pendentes com o motivo `CreateContainerError` devido a um erro ao criar o contêiner. |
| `pod_container_status_waiting_reason_image_pull_error` | `ClusterName` `PodName`, `Namespace`, `ClusterName` `Namespace`, `ClusterName`, `Service` `ClusterName`, `Namespace`, `PodName`, `FullPodName` | Relata o número de contêineres no pod que estão pendentes devido a `ErrImagePull`, `ImagePullBackOff` ou `InvalidImageName`. Essas situações ocorrem devido a um erro ao extrair a imagem do contêiner. |
| `pod_container_status_waiting_reason_start_error` | `ClusterName` `PodName`, `Namespace`, `ClusterName` `Namespace`, `ClusterName`, `Service` `ClusterName`, `Namespace`, `PodName`, `FullPodName` | Relata o número de contêineres no pod que estão pendentes com o motivo `StartError` devido a um erro ao iniciar o contêiner. |
| `pod_container_status_terminated_reason_oom_killed` | `ContainerName`, `FullPodName`, `PodName`, `Namespace`, `ClusterName` `ContainerName`, `PodName`, `Namespace`, `ClusterName` `ClusterName` | Indica que um pod foi encerrado porque excede o limite de memória. Essa métrica apenas é exibida quando esse problema ocorre. |
| `pod_interface_network_rx_dropped` | `ClusterName` `PodName`, `Namespace`, `ClusterName` `Namespace`, `ClusterName`, `Service` `ClusterName`, `Namespace`, `PodName`, `FullPodName` | O número de pacotes que foram recebidos e posteriormente descartados em uma interface de rede para o pod. |
| `pod_interface_network_tx_dropped` | `ClusterName` `PodName`, `Namespace`, `ClusterName` `Namespace`, `ClusterName`, `Service` `ClusterName`, `Namespace`, `PodName`, `FullPodName` | O número de pacotes que deveriam ser transmitidos, mas foram descartados para o pod. |
| `pod_memory_working_set` | `ClusterName` `ClusterName`, `Namespace`, `PodName` `ClusterName`, `Namespace`, `Service` `ClusterName`, `Namespace`, `PodName`, `FullPodName` | A memória em bytes que está sendo usada por um pod. |
| `pod_cpu_usage_total` | `ClusterName` `ClusterName`, `Namespace`, `PodName` `ClusterName`, `Namespace`, `Service` `ClusterName`, `Namespace`, `PodName`, `FullPodName` | O número de unidades de CPU usadas por um pod. |
| `container_cpu_utilization` | `ClusterName` `PodName`, `Namespace`, `ClusterName`, `ContainerName` `PodName`, `Namespace`, `ClusterName`, `ContainerName`, `FullPodName` | A porcentagem de unidades de CPU que estão sendo usadas pelo contêiner. Fórmula: `container_cpu_usage_total / node_cpu_limit` `container_cpu_utilization` não é relatado diretamente como uma métrica, mas é um campo em eventos de log de performance. Para obter mais informações, consulte [Campos relevantes nos eventos de log de performance para Amazon EKS e Kubernetes](Container-Insights-reference-performance-entries-EKS.md). |
| `container_cpu_utilization_over_container_limit` | `ClusterName` `PodName`, `Namespace`, `ClusterName`, `ContainerName` `PodName`, `Namespace`, `ClusterName`, `ContainerName`, `FullPodName` | A porcentagem de unidades de CPU que estão sendo usadas pelo contêiner em relação ao limite do contêiner. Se o contêiner não tiver um limite de CPU definido, essa métrica não será exibida. Fórmula: `container_cpu_usage_total / container_cpu_limit` `container_cpu_utilization_over_container_limit` não é relatado diretamente como uma métrica, mas é um campo em eventos de log de performance. Para obter mais informações, consulte [Campos relevantes nos eventos de log de performance para Amazon EKS e Kubernetes](Container-Insights-reference-performance-entries-EKS.md). |
| `container_memory_utilization` | `ClusterName` `PodName`, `Namespace`, `ClusterName`, `ContainerName` `PodName`, `Namespace`, `ClusterName`, `ContainerName`, `FullPodName` | A porcentagem de unidades de memória que está sendo usada pelo contêiner. Fórmula: `container_memory_working_set / node_memory_limit` `container_memory_utilization` não é relatado diretamente como uma métrica, mas é um campo em eventos de log de performance. Para obter mais informações, consulte [Campos relevantes nos eventos de log de performance para Amazon EKS e Kubernetes](Container-Insights-reference-performance-entries-EKS.md). |
| `container_memory_utilization_over_container_limit` | `ClusterName` `PodName`, `Namespace`, `ClusterName`, `ContainerName` `PodName`, `Namespace`, `ClusterName`, `ContainerName`, `FullPodName` | A porcentagem de unidades de memória que está sendo usada pelo contêiner em relação ao limite do contêiner. Se o contêiner não tiver um limite de memória definido, essa métrica não será exibida. Fórmula: `container_memory_working_set / container_memory_limit` `container_memory_utilization_over_container_limit` não é relatado diretamente como uma métrica, mas é um campo em eventos de log de performance. Para obter mais informações, consulte [Campos relevantes nos eventos de log de performance para Amazon EKS e Kubernetes](Container-Insights-reference-performance-entries-EKS.md). |
| `container_memory_failures_total` Não está disponível no Windows. | `ClusterName` `PodName`, `Namespace`, `ClusterName`, `ContainerName` `PodName`, `Namespace`, `ClusterName`, `ContainerName`, `FullPodName` | O número de falhas de alocação de memória que ocorreram no contêiner. |
| `pod_number_of_container_restarts` | PodName, `Namespace`, `ClusterName` | O número total de reinicializações de contêineres em um pod. |
| `service_number_of_running_pods` | Serviço, `Namespace`, `ClusterName` `ClusterName` | O número de pods que executam o serviço ou os serviços no cluster. |
| `replicas_desired` | `ClusterName` `PodName`, `Namespace`, `ClusterName` | O número de pods desejados para uma workload, conforme definido na especificação da workload. |
| `replicas_ready` | `ClusterName` `PodName`, `Namespace`, `ClusterName` | O número de pods de uma workload que atingiram o status de “prontos”. |
| `status_replicas_available` | `ClusterName` `PodName`, `Namespace`, `ClusterName` | O número de pods para uma workload que estão disponíveis. Um pod está disponível quando estiver pronto para o `minReadySeconds` definido na especificação da workload. |
| `status_replicas_unavailable` | `ClusterName` `PodName`, `Namespace`, `ClusterName` | O número de pods para uma workload que não estão disponíveis. Um pod está disponível quando estiver pronto para o `minReadySeconds` definido na especificação da workload. Os pods não estarão disponíveis se não atenderem a esse critério. |
| `apiserver_storage_objects` | `ClusterName` `ClusterName`, `resource` | O número de objetos armazenados no etcd no momento da última verificação. |
| `apiserver_storage_db_total_size_in_bytes` | `ClusterName` `ClusterName`, `endpoint` | Tamanho total do arquivo de banco de dados de armazenamento alocado fisicamente em bytes. Essa métrica é experimental e pode mudar em versões futuras do Kubernetes. Unidade: bytes Estatísticas significativas: Soma, Média, Mínimo, Máximo |
| `apiserver_request_total` | `ClusterName` `ClusterName`, `code`, `verb` | O número total de solicitações de API para o servidor de API do Kubernetes. |
| `apiserver_request_duration_seconds` | `ClusterName` `ClusterName`, `verb` | Latência de resposta para solicitações de API para o servidor de API do Kubernetes. |
| `apiserver_admission_controller_admission_duration_seconds` | `ClusterName` `ClusterName`, `operation` | Latência do controlador de admissão em segundos. Um controlador de admissão é um código que intercepta solicitações para o servidor de API do Kubernetes. |
| `rest_client_request_duration_seconds` | `ClusterName` `ClusterName`, `operation` | Latência de resposta observada pelos clientes que chamam o servidor da API do Kubernetes. Essa métrica é experimental e pode mudar em versões futuras do Kubernetes. |
| `rest_client_requests_total` | `ClusterName` `ClusterName`, `code`, `method` | O número total de solicitações de API para o servidor de API do Kubernetes feitas por clientes. Essa métrica é experimental e pode mudar em versões futuras do Kubernetes. |
| `etcd_request_duration_seconds` | `ClusterName` `ClusterName`, `operation` | Latência de resposta das chamadas de API para o Etcd. Essa métrica é experimental e pode mudar em versões futuras do Kubernetes. |
| `apiserver_storage_size_bytes` | `ClusterName` `ClusterName`, `endpoint` | Tamanho do arquivo de banco de dados de armazenamento alocado fisicamente em bytes. Essa métrica é experimental e pode mudar em versões futuras do Kubernetes. |
| `apiserver_longrunning_requests` | `ClusterName` `ClusterName`, `resource` | O número de solicitações ativas de longa duração para o servidor de API do Kubernetes. |
| `apiserver_current_inflight_requests` | `ClusterName` `ClusterName`, `request_kind` | O número de solicitações que estão sendo processadas pelo servidor de API do Kubernetes. |
| `apiserver_admission_webhook_admission_duration_seconds` | `ClusterName` `ClusterName`, `name` | Latência do webhook de admissão em segundos. Os webhooks de admissão são retornos de chamada HTTP que recebem solicitações de admissão e realizam alguma ação com elas. |
| `apiserver_admission_step_admission_duration_seconds` | `ClusterName` `ClusterName`, `operation` | Latência da subetapa de admissão em segundos. |
| `apiserver_requested_deprecated_apis` | `ClusterName` `ClusterName`, `group` | Número de solicitações para APIs obsoletas no servidor de API do Kubernetes. |
| `apiserver_request_total_5xx` | `ClusterName` `ClusterName`, `code`, `verb` | Número de solicitações ao servidor de API do Kubernetes que foram respondidas com um código de resposta HTTP 5XX. |
| `apiserver_storage_list_duration_seconds` | `ClusterName` `ClusterName`, `resource` | Latência de resposta da listagem de objetos do Etc. Essa métrica é experimental e pode mudar em versões futuras do Kubernetes. |
| `apiserver_flowcontrol_request_concurrency_limit` | `ClusterName` `ClusterName`, `priority_level` | O número de threads usados pelas solicitações em execução no subsistema de Prioridade e equidade de APIs. |
| `apiserver_flowcontrol_rejected_requests_total` | `ClusterName` `ClusterName`, `reason` | Número de solicitações rejeitadas pelo subsistema API Priority and Fairness. Essa métrica é experimental e pode mudar em versões futuras do Kubernetes. |
| `apiserver_current_inqueue_requests` | `ClusterName` `ClusterName`, `request_kind` | O número de solicitações em fila enfileiradas pelo servidor de API do Kubernetes. Essa métrica é experimental e pode mudar em versões futuras do Kubernetes. |
## Métricas da GPU NVIDIA
A partir da versão `1.300034.0` do agente do CloudWatch, o Container Insights com observabilidade aprimorada para o Amazon EKS coleta métricas da GPU NVIDIA de workloads do EKS por padrão. O agente do CloudWatch deve ser instalado usando o complemento Observability do CloudWatch para o EKS na versão `v1.3.0-eksbuild.1` ou em versões posteriores. Para obter mais informações, consulte [Instalação do agente do CloudWatch com o complemento de observabilidade do EKS do Amazon CloudWatch ou com o chart do Helm](install-CloudWatch-Observability-EKS-addon.md). Essas métricas de GPU NVIDIA coletadas estão listadas na tabela desta seção.
Para que o Container Insights colete métricas de GPU NVIDIA, você deve atender aos seguintes pré-requisitos:
+ Você deve usar o Container Insights com observabilidade aprimorada para o Amazon EKS, com o complemento Observability do Amazon CloudWatch para o EKS na versão `v1.3.0-eksbuild.1` ou em versões posteriores.
+ [O plug-in de dispositivo NVIDIA para Kubernetes](https://github.com/NVIDIA/k8s-device-plugin) deve estar instalado no cluster.
+ [O kit de ferramentas de contêiner NVIDIA](https://github.com/NVIDIA/nvidia-container-toolkit) deve ser instalado nos nós do cluster. Por exemplo, as AMIs aceleradas otimizadas do Amazon EKS são criadas com os componentes necessários.
Você pode optar por não coletar métricas de GPU NVIDIA definindo a opção `accelerated_compute_metrics` no arquivo de configuração do agente CloudWatch como `false`. Para obter mais informações e um exemplo de configuração de exclusão, consulte [(Opcional) Configuração adicional](install-CloudWatch-Observability-EKS-addon.md#install-CloudWatch-Observability-EKS-addon-configuration).
| Nome da métrica | Dimensões | Descrição |
| --- | --- | --- |
| `container_gpu_memory_total` | `ClusterName` `ClusterName`, `Namespace`, `PodName`, `ContainerName` `ClusterName`, `Namespace`, `PodName`, `FullPodName`, `ContainerName` `ClusterName`, `Namespace`, `PodName`, `FullPodName`, `ContainerName`, `GpuDevice` | O tamanho total do buffer de quadros, em bytes, nas GPUs alocadas ao contêiner. |
| `container_gpu_memory_used` | `ClusterName` `ClusterName`, `Namespace`, `PodName`, `ContainerName` `ClusterName`, `Namespace`, `PodName`, `FullPodName`, `ContainerName` `ClusterName`, `Namespace`, `PodName`, `FullPodName`, `ContainerName`, `GpuDevice` | O bytes do buffer de quadros usados nas GPUs alocadas ao contêiner. |
| `container_gpu_memory_utilization` | `ClusterName` `ClusterName`, `Namespace`, `PodName`, `ContainerName` `ClusterName`, `Namespace`, `PodName`, `FullPodName`, `ContainerName` `ClusterName`, `Namespace`, `PodName`, `FullPodName`, `ContainerName`, `GpuDevice` | A porcentagem do buffer de quadros usada das GPUs alocadas ao contêiner. |
| `container_gpu_power_draw` | `ClusterName` `ClusterName`, `Namespace`, `PodName`, `ContainerName` `ClusterName`, `Namespace`, `PodName`, `FullPodName`, `ContainerName` `ClusterName`, `Namespace`, `PodName`, `FullPodName`, `ContainerName`, `GpuDevice` | O uso de energia em watts das GPUs alocadas ao contêiner. |
| `container_gpu_temperature` | `ClusterName` `ClusterName`, `Namespace`, `PodName`, `ContainerName` `ClusterName`, `Namespace`, `PodName`, `FullPodName`, `ContainerName` `ClusterName`, `Namespace`, `PodName`, `FullPodName`, `ContainerName`, `GpuDevice` | A temperatura em graus Celsius das GPUs alocadas ao contêiner. |
| `container_gpu_utilization` | `ClusterName` `ClusterName`, `Namespace`, `PodName`, `ContainerName` `ClusterName`, `Namespace`, `PodName`, `FullPodName`, `ContainerName` `ClusterName`, `Namespace`, `PodName`, `FullPodName`, `ContainerName`, `GpuDevice` | A porcentagem de utilização das GPUs alocadas ao contêiner. |
| `container_gpu_tensor_core_utilization` | `ClusterName` `ClusterName`, `Namespace`, `PodName`, `ContainerName` `ClusterName`, `Namespace`, `PodName`, `FullPodName`, `ContainerName` `ClusterName`, `Namespace`, `PodName`, `FullPodName`, `ContainerName`, `GpuDevice` | A porcentagem de utilização de núcleos tensoriais das GPUs alocadas ao contêiner. |
| `node_gpu_memory_total` | `ClusterName` `ClusterName`, `InstanceId`, `NodeName` `ClusterName`, `InstanceId`, `InstanceType`, `NodeName`, `GpuDevice` | O tamanho total do buffer de quadros, em bytes, nas GPUs alocadas ao nó. |
| `node_gpu_memory_used` | `ClusterName` `ClusterName`, `InstanceId`, `NodeName` `ClusterName`, `InstanceId`, `InstanceType`, `NodeName`, `GpuDevice` | Os bytes do buffer de quadros usados nas GPUs alocadas ao nó. |
| `node_gpu_memory_utilization` | `ClusterName` `ClusterName`, `InstanceId`, `NodeName` `ClusterName`, `InstanceId`, `InstanceType`, `NodeName`, `GpuDevice` | A porcentagem de buffer de quadros usado nas GPUs alocadas ao nó. |
| `node_gpu_power_draw` | `ClusterName` `ClusterName`, `InstanceId`, `NodeName` `ClusterName`, `InstanceId`, `InstanceType`, `NodeName`, `GpuDevice` | O uso de energia em watts das GPUs alocadas ao nó. |
| `node_gpu_temperature` | `ClusterName` `ClusterName`, `InstanceId`, `NodeName` `ClusterName`, `InstanceId`, `InstanceType`, `NodeName`, `GpuDevice` | A temperatura em graus Celsius das GPUs alocadas ao nó. |
| `node_gpu_utilization` | `ClusterName` `ClusterName`, `InstanceId`, `NodeName` `ClusterName`, `InstanceId`, `InstanceType`, `NodeName`, `GpuDevice` | A porcentagem de utilização das GPUs alocadas ao nó. |
| `node_gpu_tensor_core_utilization` | `ClusterName` `ClusterName`, `InstanceId`, `NodeName` `ClusterName`, `InstanceId`, `InstanceType`, `NodeName`, `GpuDevice` | A porcentagem de utilização de núcleos tensoriais das GPUs alocadas ao nó. |
| `pod_gpu_memory_total` | `ClusterName` `ClusterName`, `Namespace` `ClusterName`, `Namespace`, `Service` `ClusterName`, `Namespace`, `PodName` `ClusterName`, `Namespace`, `PodName`, `FullPodName` `ClusterName`, `Namespace`, `PodName`, `FullPodName`. `GpuDevice` | O tamanho total do buffer de quadros, em bytes, nas GPUs alocadas ao pod. |
| `pod_gpu_memory_used` | `ClusterName` `ClusterName`, `Namespace` `ClusterName`, `Namespace`, `Service` `ClusterName`, `Namespace`, `PodName` `ClusterName`, `Namespace`, `PodName`, `FullPodName` `ClusterName`, `Namespace`, `PodName`, `FullPodName`. `GpuDevice` | Os bytes do buffer de quadros usados nas GPUs alocadas ao pod. |
| `pod_gpu_memory_utilization` | `ClusterName` `ClusterName`, `Namespace` `ClusterName`, `Namespace`, `Service` `ClusterName`, `Namespace`, `PodName` `ClusterName`, `Namespace`, `PodName`, `FullPodName` `ClusterName`, `Namespace`, `PodName`, `FullPodName`. `GpuDevice` | A porcentagem de buffer de quadros usada das GPUs alocadas ao pod. |
| `pod_gpu_power_draw` | `ClusterName` `ClusterName`, `Namespace` `ClusterName`, `Namespace`, `Service` `ClusterName`, `Namespace`, `PodName` `ClusterName`, `Namespace`, `PodName`, `FullPodName` `ClusterName`, `Namespace`, `PodName`, `FullPodName`. `GpuDevice` | O uso de energia em watts das GPUs alocadas ao pod. |
| `pod_gpu_temperature` | `ClusterName` `ClusterName`, `Namespace` `ClusterName`, `Namespace`, `Service` `ClusterName`, `Namespace`, `PodName` `ClusterName`, `Namespace`, `PodName`, `FullPodName` `ClusterName`, `Namespace`, `PodName`, `FullPodName`. `GpuDevice` | A temperatura em graus Celsius das GPUs alocadas ao pod. |
| `pod_gpu_utilization` | `ClusterName` `ClusterName`, `Namespace`, `PodName`, `ContainerName` `ClusterName`, `Namespace`, `PodName`, `FullPodName`, `ContainerName` `ClusterName`, `Namespace`, `PodName`, `FullPodName`, `ContainerName`, `GpuDevice` | A porcentagem de utilização das GPUs alocadas ao pod. |
| `pod_gpu_tensor_core_utilization` | `ClusterName` `ClusterName`, `Namespace`, `PodName`, `ContainerName` `ClusterName`, `Namespace`, `PodName`, `FullPodName`, `ContainerName` `ClusterName`, `Namespace`, `PodName`, `FullPodName`, `ContainerName`, `GpuDevice` | A porcentagem de utilização de núcleos tensoriais das GPUs alocadas ao pod. |
### Monitoramento detalhado da GPU
A partir da versão `1.300062.0` do agente CloudWatch, o Container Insights com observabilidade aprimorada para o Amazon EKS é compatível com o monitoramento detalhado da GPU com intervalos de coleta de menos de um minuto. Isso resolve as lacunas de monitoramento para workloads de inferência de machine learning de curta duração que podem ser completamente ignoradas pelos intervalos de coleta padrão. O agente do CloudWatch deve ser instalado usando o complemento Observability do CloudWatch para o EKS na versão `v4.7.0-eksbuild.1` ou em versões posteriores. Para obter mais informações, consulte [Instalação do agente do CloudWatch com o complemento de observabilidade do EKS do Amazon CloudWatch ou com o chart do Helm](install-CloudWatch-Observability-EKS-addon.md).
Por padrão, as métricas da GPU são coletadas e ingeridas a intervalos de 60 segundos. Com o monitoramento detalhado habilitado, o agente do CloudWatch coleta métricas da GPU a intervalos de menos de um minuto (mínimo de 1 segundo), mas as métricas ainda são ingeridas no CloudWatch a intervalos de 1 minuto. Porém, você pode consultar agregações estatísticas (como mínimo, máximo e percentis, como p90) dos pontos de dados coletados a intervalos abaixo de 1 minuto dentro um período de 1 minuto, fornecendo dados precisos de utilização da GPU e melhor otimização de recursos.
#### Configuração
Para habilitar o monitoramento detalhado da GPU, atualize a configuração do agente do CloudWatch para incluir o parâmetro `accelerated_compute_gpu_metrics_collection_interval`na seção `kubernetes`, como no exemplo a seguir.
```
{
"logs": {
"metrics_collected": {
"kubernetes": {
"cluster_name": "MyCluster",
"enhanced_container_insights": true,
"accelerated_compute_metrics": true,
"accelerated_compute_gpu_metrics_collection_interval": 1
}
}
}
}
```
O parâmetro `accelerated_compute_gpu_metrics_collection_interval` aceita valores em segundos, com um valor mínimo de 1 segundo. Configurá-lo como `1` habilita intervalos de coleta de 1 segundo. Se esse parâmetro não for especificado, será usado o intervalo padrão de 60 segundos.
Para obter instruções de configuração, consulte [Configuração do agente do CloudWatch para a coleta de métricas do cluster](Container-Insights-setup-metrics.md).
## Métricas do AWS Neuron para o AWS Trainium e para o AWS Inferentia
A partir da versão `1.300036.0` do agente do CloudWatch, o Container Insights com observabilidade aprimorada para o Amazon EKS coleta métricas de computação acelerada dos aceleradores AWS Trainium e AWS Inferentia por padrão. O agente do CloudWatch deve ser instalado usando o complemento Observability do CloudWatch para o EKS na versão `v1.5.0-eksbuild.1` ou em versões posteriores. Para obter mais informações sobre o complemento, consulte [Instalação do agente do CloudWatch com o complemento de observabilidade do EKS do Amazon CloudWatch ou com o chart do Helm](install-CloudWatch-Observability-EKS-addon.md). Para obter mais informações sobre o AWS Trainium, consulte [AWS Trainium](https://aws.amazon.com/machine-learning/trainium/). Para obter mais informações sobre o AWS Inferentia, consulte [AWS Inferentia](https://aws.amazon.com/machine-learning/inferentia/).
Para que o Container Insights colete métricas do AWS Neuron, você deve atender aos seguintes pré-requisitos:
+ Você deve usar o Container Insights com observabilidade aprimorada para o Amazon EKS, com o complemento Observability do Amazon CloudWatch para o EKS na versão `v1.5.0-eksbuild.1` ou em versões posteriores.
+ O [driver Neuron](https://awsdocs-neuron.readthedocs-hosted.com/en/latest/general/setup/neuron-setup/pytorch/neuronx/ubuntu/torch-neuronx-ubuntu22.html#setup-torch-neuronx-ubuntu22) deve estar instalado nos nós do cluster.
+ O [plug-in do dispositivo Neuron](https://awsdocs-neuron.readthedocs-hosted.com/en/latest/containers/kubernetes-getting-started.html) deve estar instalado no cluster. Por exemplo, as AMIs aceleradas otimizadas do Amazon EKS são criadas com os componentes necessários.
As métricas que são coletadas estão listadas na tabela desta seção. As métricas são coletadas para o AWS Trainium, o AWS Inferentia e o AWS Inferentia2.
O agente do CloudWatch coleta essas métricas do [monitor do Neuron](https://awsdocs-neuron.readthedocs-hosted.com/en/latest/tools/neuron-sys-tools/neuron-monitor-user-guide.html) e realiza a correlação necessária de recursos do Kubernetes para fornecer métricas nos níveis de pod e de contêiner
| Nome da métrica | Dimensões | Descrição |
| --- | --- | --- |
| `container_neuroncore_utilization` | `ClusterName` `ClusterName`, `Namespace`, `PodName`, `ContainerName` `ClusterName`, `Namespace`, `PodName`, `FullPodName`, `ContainerName` `ClusterName`, `Namespace`, `PodName`, `FullPodName`, `ContainerName`, `NeuronDevice`, `NeuronCore` | Utilização do NeuronCore, durante o período de captura do NeuronCore que está alocado para o contêiner. Unidade: percentual |
| `container_neuroncore_memory_usage_constants` | `ClusterName` `ClusterName`, `Namespace`, `PodName`, `ContainerName` `ClusterName`, `Namespace`, `PodName`, `FullPodName`, `ContainerName` `ClusterName`, `Namespace`, `PodName`, `FullPodName`, `ContainerName`, `NeuronDevice`, `NeuronCore` | A quantidade de memória do dispositivo usada para constantes durante o treinamento pelo NeuronCore que está alocado para o contêiner (ou ponderações durante a inferência). Unidade: bytes |
| `container_neuroncore_memory_usage_model_code` | `ClusterName` `ClusterName`, `Namespace`, `PodName`, `ContainerName` `ClusterName`, `Namespace`, `PodName`, `FullPodName`, `ContainerName` `ClusterName`, `Namespace`, `PodName`, `FullPodName`, `ContainerName`, `NeuronDevice`, `NeuronCore` | A quantidade de memória do dispositivo usada para o código executável dos modelos pelo NeuronCore que está alocado para o contêiner. Unidade: bytes |
| `container_neuroncore_memory_usage_model_shared_scratchpad` | `ClusterName` `ClusterName`, `Namespace`, `PodName`, `ContainerName` `ClusterName`, `Namespace`, `PodName`, `FullPodName`, `ContainerName` `ClusterName`, `Namespace`, `PodName`, `FullPodName`, `ContainerName`, `NeuronDevice`, `NeuronCore` | A quantidade de memória do dispositivo usada para o rascunho compartilhado dos modelos pelo NeuronCore que está alocado para o contêiner. Esta região de memória está reservada para os modelos. Unidade: bytes |
| `container_neuroncore_memory_usage_runtime_memory` | `ClusterName` `ClusterName`, `Namespace`, `PodName`, `ContainerName` `ClusterName`, `Namespace`, `PodName`, `FullPodName`, `ContainerName` `ClusterName`, `Namespace`, `PodName`, `FullPodName`, `ContainerName`, `NeuronDevice`, `NeuronCore` | A quantidade de memória do dispositivo usada para o runtime do Neuron pelo NeuronCore que está alocado para o contêiner. Unidade: bytes |
| `container_neuroncore_memory_usage_tensors` | `ClusterName` `ClusterName`, `Namespace`, `PodName`, `ContainerName` `ClusterName`, `Namespace`, `PodName`, `FullPodName`, `ContainerName` `ClusterName`, `Namespace`, `PodName`, `FullPodName`, `ContainerName`, `NeuronDevice`, `NeuronCore` | A quantidade de memória do dispositivo usada para tensores pelo NeuronCore que está alocado para o contêiner. Unidade: bytes |
| `container_neuroncore_memory_usage_total` | `ClusterName` `ClusterName`, `Namespace`, `PodName`, `ContainerName` `ClusterName`, `Namespace`, `PodName`, `FullPodName`, `ContainerName` `ClusterName`, `Namespace`, `PodName`, `FullPodName`, `ContainerName`, `NeuronDevice`, `NeuronCore` | A quantidade total de memória usada pelo NeuronCore que está alocado para o contêiner. Unidade: bytes |
| `container_neurondevice_hw_ecc_events_total` | `ClusterName` `ClusterName`, `Namespace`, `PodName`, `ContainerName` `ClusterName`, `Namespace`, `PodName`, `FullPodName`, `ContainerName` `ClusterName`, `Namespace`, `PodName`, `FullPodName`, `ContainerName`, `NeuronDevice` | O número de eventos do sistema ECC corrigidos e não corrigidos para a SRAM no chip e para a memória do dispositivo Neuron no nó. Unidade: Contagem |
| `pod_neuroncore_utilization` | `ClusterName` `ClusterName`, `Namespace` `ClusterName`, `Namespace`, `Service` `ClusterName`, `Namespace`, `PodName`, `FullPodName` `ClusterName`, `Namespace`, `PodName`, `FullPodName`, `NeuronDevice`, `NeuronCore` | A utilização do NeuronCore durante o período capturado do NeuronCore que está alocado para o pod. Unidade: percentual |
| `pod_neuroncore_memory_usage_constants` | `ClusterName` `ClusterName`, `Namespace` `ClusterName`, `Namespace`, `Service` `ClusterName`, `Namespace`, `PodName`, `FullPodName` `ClusterName`, `Namespace`, `PodName`, `FullPodName`, `NeuronDevice`, `NeuronCore` | A quantidade de memória do dispositivo usada para constantes durante o treinamento pelo NeuronCore que está alocado para o pod (ou ponderações durante a inferência). Unidade: bytes |
| `pod_neuroncore_memory_usage_model_code` | `ClusterName` `ClusterName`, `Namespace` `ClusterName`, `Namespace`, `Service` `ClusterName`, `Namespace`, `PodName`, `FullPodName` `ClusterName`, `Namespace`, `PodName`, `FullPodName`, `NeuronDevice`, `NeuronCore` | A quantidade de memória do dispositivo usada para o código executável dos modelos pelo NeuronCore que está alocado para o pod. Unidade: bytes |
| `pod_neuroncore_memory_usage_model_shared_scratchpad` | `ClusterName` `ClusterName`, `Namespace` `ClusterName`, `Namespace`, `Service` `ClusterName`, `Namespace`, `PodName`, `FullPodName` `ClusterName`, `Namespace`, `PodName`, `FullPodName`, `NeuronDevice`, `NeuronCore` | A quantidade de memória do dispositivo usada para o rascunho compartilhado dos modelos pelo NeuronCore que está alocado para o pod. Esta região de memória está reservada para os modelos. Unidade: bytes |
| `pod_neuroncore_memory_usage_runtime_memory` | `ClusterName` `ClusterName`, `Namespace` `ClusterName`, `Namespace`, `Service` `ClusterName`, `Namespace`, `PodName`, `FullPodName` `ClusterName`, `Namespace`, `PodName`, `FullPodName`, `NeuronDevice`, `NeuronCore` | A quantidade de memória do dispositivo usada para o runtime do Neuron pelo NeuronCore que está alocado para o pod. Unidade: bytes |
| `pod_neuroncore_memory_usage_tensors` | `ClusterName` `ClusterName`, `Namespace` `ClusterName`, `Namespace`, `Service` `ClusterName`, `Namespace`, `PodName`, `FullPodName` `ClusterName`, `Namespace`, `PodName`, `FullPodName`, `NeuronDevice`, `NeuronCore` | A quantidade de memória do dispositivo usada para tensores pelo NeuronCore que está alocado para o pod. Unidade: bytes |
| `pod_neuroncore_memory_usage_total` | `ClusterName` `ClusterName`, `Namespace` `ClusterName`, `Namespace`, `Service` `ClusterName`, `Namespace`, `PodName`, `FullPodName` `ClusterName`, `Namespace`, `PodName`, `FullPodName`, `NeuronDevice`, `NeuronCore` | A quantidade total de memória usada pelo NeuronCore que está alocado para o pod. Unidade: bytes |
| `pod_neurondevice_hw_ecc_events_total` | `ClusterName` `ClusterName`, `Namespace` `ClusterName`, `Namespace`, `Service` `ClusterName`, `Namespace`, `PodName` `ClusterName`, `Namespace`, `PodName`, `FullPodName` `ClusterName`, `Namespace`, `PodName`, `FullPodName`, `NeuronDevice` | O número de eventos do sistema ECC corrigidos e não corrigidos para a SRAM no chip e para a memória do dispositivo Neuron que está alocado para um pod. Unidade: bytes |
| `node_neuroncore_utilization` | `ClusterName` `ClusterName`, `UltraServer` `ClusterName`, `InstanceId`, `NodeName` `ClusterName`, `InstanceType`, `InstanceId`, `NodeName`, `NeuronDevice`, `NeuronCore` | A utilização do NeuronCore durante o período capturado do NeuronCore que está alocado para o nó. Unidade: percentual |
| `node_neuroncore_memory_usage_constants` | `ClusterName` `ClusterName`, `UltraServer` `ClusterName`, `InstanceId`, `NodeName` `ClusterName`, `InstanceType`, `InstanceId`, `NodeName`, `NeuronDevice`, `NeuronCore` | A quantidade de memória do dispositivo usada para constantes durante o treinamento pelo NeuronCore que está alocado para o nó (ou ponderações durante a inferência). Unidade: bytes |
| `node_neuroncore_memory_usage_model_code` | `ClusterName` `ClusterName`, `UltraServer` `ClusterName`, `InstanceId`, `NodeName` `ClusterName`, `InstanceType`, `InstanceId`, `NodeName`, `NeuronDevice`, `NeuronCore` | A quantidade de memória do dispositivo usada para o código executável dos modelos pelo NeuronCore que está alocado para o nó. Unidade: bytes |
| `node_neuroncore_memory_usage_model_shared_scratchpad` | `ClusterName` `ClusterName`, `UltraServer` `ClusterName`, `InstanceId`, `NodeName` `ClusterName`, `InstanceType`, `InstanceId`, `NodeName`, `NeuronDevice`, `NeuronCore` | A quantidade de memória do dispositivo usada para o rascunho compartilhado dos modelos pelo NeuronCore que está alocado para o nó. Esta é uma região de memória reservada para os modelos. Unidade: bytes |
| `node_neuroncore_memory_usage_runtime_memory` | `ClusterName` `ClusterName`, `UltraServer` `ClusterName`, `InstanceId`, `NodeName` `ClusterName`, `InstanceType`, `InstanceId`, `NodeName`, `NeuronDevice`, `NeuronCore` | A quantidade de memória do dispositivo usada para o runtime do Neuron pelo NeuronCore que está alocado para o nó. Unidade: bytes |
| `node_neuroncore_memory_usage_tensors` | `ClusterName` `ClusterName`, `UltraServer` `ClusterName`, `InstanceId`, `NodeName` `ClusterName`, `InstanceType`, `InstanceId`, `NodeName`, `NeuronDevice`, `NeuronCore` | A quantidade de memória do dispositivo usada para tensores pelo NeuronCore que está alocado para o nó. Unidade: bytes |
| `node_neuroncore_memory_usage_total` | `ClusterName` `ClusterName`, `UltraServer` `ClusterName`, `InstanceId`, `NodeName` `ClusterName`, `InstanceType`, `InstanceId`, `NodeName`, `NeuronDevice`, `NeuronCore` | A quantidade total de memória usada pelo NeuronCore que está alocado para o nó. Unidade: bytes |
| `node_neuron_execution_errors_total` | `ClusterName` `ClusterName`, `UltraServer` `ClusterName`, `InstanceId`, `NodeName` | O número total de erros de execução no nó. Isso é calculado pelo agente do CloudWatch ao agregar os erros dos seguintes tipos: `generic`, `numerical`, `transient`, `model`, `runtime` e `hardware`. Unidade: Contagem |
| `node_neurondevice_runtime_memory_used_bytes` | `ClusterName` `ClusterName`, `UltraServer` `ClusterName`, `InstanceId`, `NodeName` | O uso total de memória do dispositivo Neuron em bytes no nó. Unidade: bytes |
| `node_neuron_execution_latency` | `ClusterName` `ClusterName`, `UltraServer` `ClusterName`, `InstanceId`, `NodeName` | Em segundos, a latência para uma execução no nó medida pelo runtime do Neuron. Unidade: segundos |
| `node_neurondevice_hw_ecc_events_total` | `ClusterName` `ClusterName`, `UltraServer` `ClusterName`, `InstanceId`, `NodeName` `ClusterName`, `InstanceId`, `NodeName`, `NeuronDevice` | O número de eventos do sistema ECC corrigidos e não corrigidos para a SRAM no chip e para a memória do dispositivo Neuron no nó. Unidade: Contagem |
## Métricas do AWS Elastic Fabric Adapter (EFA)
A partir da versão `1.300037.0` do agente do CloudWatch, o Container Insights com observabilidade aprimorada para o Amazon EKS coleta métricas do AWS Elastic Fabric Adapter (EFA) de clusters do Amazon EKS em instâncias do Linux. O agente do CloudWatch deve ser instalado usando o complemento Observability do CloudWatch para o EKS na versão `v1.5.2-eksbuild.1` ou em versões posteriores. Para obter mais informações sobre o complemento, consulte [Instalação do agente do CloudWatch com o complemento de observabilidade do EKS do Amazon CloudWatch ou com o chart do Helm](install-CloudWatch-Observability-EKS-addon.md). Para obter mais informações sobre o AWS Elastic Fabric Adapter, consulte [Elastic Fabric Adapter](https://aws.amazon.com/hpc/efa/).
Para que o Container Insights colete métricas do AWS Elastic Fabric Adapter, você deve atender aos seguintes pré-requisitos:
+ Você deve usar o Container Insights com observabilidade aprimorada para o Amazon EKS, com o complemento Observability do Amazon CloudWatch para o EKS na versão `v1.5.2-eksbuild.1` ou em versões posteriores.
+ O plug-in do dispositivo EFA deve estar instalado no cluster. Para obter mais informações, consulte [aws-efa-k8s-device-plugin](https://github.com/aws/eks-charts/tree/master/stable/aws-efa-k8s-device-plugin) no GitHub.
As métricas que são coletadas estão listadas na tabela apresentada a seguir.
| Nome da métrica | Dimensões | Descrição |
| --- | --- | --- |
| `container_efa_rx_bytes` | `ClusterName` `ClusterName`, `Namespace`, `PodName`, `ContainerName` `ClusterName`, `Namespace`, `PodName`, `FullPodName`, `ContainerName` `ClusterName`, `Namespace`, `PodName`, `FullPodName`, `ContainerName`, `NetworkInterfaceId` | O número de bytes por segundo que são recebidos pelos dispositivos EFA que estão alocados para o contêiner. Unidade: bytes/segundo |
| `container_efa_tx_bytes` | `ClusterName` `ClusterName`, `Namespace`, `PodName`, `ContainerName` `ClusterName`, `Namespace`, `PodName`, `FullPodName`, `ContainerName` `ClusterName`, `Namespace`, `PodName`, `FullPodName`, `ContainerName`, `NetworkInterfaceId` | O número de bytes por segundo que são transmitidos pelos dispositivos EFA que estão alocados para o contêiner. Unidade: bytes/segundo |
| `container_efa_rx_dropped` | `ClusterName` `ClusterName`, `Namespace`, `PodName`, `ContainerName` `ClusterName`, `Namespace`, `PodName`, `FullPodName`, `ContainerName` `ClusterName`, `Namespace`, `PodName`, `FullPodName`, `ContainerName`, `NetworkInterfaceId` | O número de pacotes que foram recebidos e, em seguida, descartados pelos dispositivos EFA que estão alocados para o contêiner. Unidade: contagem/segundo |
| `container_efa_rdma_read_bytes` | `ClusterName` `ClusterName`, `Namespace`, `PodName`, `ContainerName` `ClusterName`, `Namespace`, `PodName`, `FullPodName`, `ContainerName` `ClusterName`, `Namespace`, `PodName`, `FullPodName`, `ContainerName`, `NetworkInterfaceId` | O número de bytes por segundo recebidos usando operações de leitura de acesso remoto direto à memória pelos dispositivos EFA que estão alocados para o contêiner. Unidade: bytes/segundo |
| `container_efa_rdma_write_bytes` | `ClusterName` `ClusterName`, `Namespace`, `PodName`, `ContainerName` `ClusterName`, `Namespace`, `PodName`, `FullPodName`, `ContainerName` `ClusterName`, `Namespace`, `PodName`, `FullPodName`, `ContainerName`, `NetworkInterfaceId` | O número de bytes por segundo transmitidos usando operações de leitura de acesso remoto direto à memória pelos dispositivos EFA que estão alocados para o contêiner. Unidade: bytes/segundo |
| `container_efa_rdma_write_recv_bytes` | `ClusterName` `ClusterName`, `Namespace`, `PodName`, `ContainerName` `ClusterName`, `Namespace`, `PodName`, `FullPodName`, `ContainerName` `ClusterName`, `Namespace`, `PodName`, `FullPodName`, `ContainerName`, `NetworkInterfaceId` | O número de bytes por segundo recebidos durante operações de gravação de acesso remoto direto à memória pelos dispositivos EFA que estão alocados para o contêiner. Unidade: bytes/segundo |
| `pod_efa_rx_bytes` | `ClusterName` `ClusterName`, `Namespace` `ClusterName`, `Namespace`, `Service` `ClusterName`, `Namespace`, `PodName` `ClusterName`, `Namespace`, `PodName`, `FullPodName` `ClusterName`, `Namespace`, `PodName`, `FullPodName`, `NetworkInterfaceId` | O número de bytes por segundo que são recebidos pelos dispositivos EFA que estão alocados para o pod. Unidade: bytes/segundo |
| `pod_efa_tx_bytes` | `ClusterName` `ClusterName`, `Namespace` `ClusterName`, `Namespace`, `Service` `ClusterName`, `Namespace`, `PodName` `ClusterName`, `Namespace`, `PodName`, `FullPodName` `ClusterName`, `Namespace`, `PodName`, `FullPodName`, `NetworkInterfaceId` | O número de bytes por segundo que são transmitidos pelos dispositivos EFA que estão alocados para o pod. Unidade: bytes/segundo |
| `pod_efa_rx_dropped` | `ClusterName` `ClusterName`, `Namespace` `ClusterName`, `Namespace`, `Service` `ClusterName`, `Namespace`, `PodName` `ClusterName`, `Namespace`, `PodName`, `FullPodName` `ClusterName`, `Namespace`, `PodName`, `FullPodName`, `NetworkInterfaceId` | O número de pacotes que foram recebidos e, em seguida, descartados pelos dispositivos EFA alocados para o pod. Unidade: contagem/segundo |
| `pod_efa_rdma_read_bytes` | `ClusterName` `ClusterName`, `Namespace` `ClusterName`, `Namespace`, `Service` `ClusterName`, `Namespace`, `PodName` `ClusterName`, `Namespace`, `PodName`, `FullPodName` `ClusterName`, `Namespace`, `PodName`, `FullPodName`, `NetworkInterfaceId` | O número de bytes por segundo recebidos usando operações de leitura de acesso remoto direto à memória pelos dispositivos EFA que estão alocados para o pod. Unidade: bytes/segundo |
| `pod_efa_rdma_write_bytes` | `ClusterName` `ClusterName`, `Namespace` `ClusterName`, `Namespace`, `Service` `ClusterName`, `Namespace`, `PodName` `ClusterName`, `Namespace`, `PodName`, `FullPodName` `ClusterName`, `Namespace`, `PodName`, `FullPodName`, `NetworkInterfaceId` | O número de bytes por segundo transmitidos usando operações de leitura de acesso remoto direto à memória pelos dispositivos EFA que estão alocados para o pod. Unidade: bytes/segundo |
| `pod_efa_rdma_write_recv_bytes` | `ClusterName` `ClusterName`, `Namespace` `ClusterName`, `Namespace`, `Service` `ClusterName`, `Namespace`, `PodName` `ClusterName`, `Namespace`, `PodName`, `FullPodName` `ClusterName`, `Namespace`, `PodName`, `FullPodName`, `NetworkInterfaceId` | O número de bytes por segundo recebidos durante operações de gravação de acesso remoto direto à memória pelos dispositivos EFA que estão alocados para o pod. Unidade: bytes/segundo |
| `node_efa_rx_bytes` | `ClusterName` `ClusterName`, `InstanceId`, `NodeName` `ClusterName`, `InstanceId`, `InstanceType`, `NodeName`, `NetworkInterfaceId` | O número de bytes por segundo que são recebidos pelos dispositivos EFA que estão alocados para o nó. Unidade: bytes/segundo |
| `node_efa_tx_bytes` | `ClusterName` `ClusterName`, `InstanceId`, `NodeName` `ClusterName`, `InstanceId`, `InstanceType`, `NodeName`, `NetworkInterfaceId` | O número de bytes por segundo que são transmitidos pelos dispositivos EFA que estão alocados para o nó. Unidade: bytes/segundo |
| `node_efa_rx_dropped` | `ClusterName` `ClusterName`, `InstanceId`, `NodeName` `ClusterName`, `InstanceId`, `InstanceType`, `NodeName`, `NetworkInterfaceId` | O número de pacotes que foram recebidos e, em seguida, descartados pelos dispositivos EFA que estão alocados para o nó. Unidade: contagem/segundo |
| `node_efa_rdma_read_bytes` | `ClusterName` `ClusterName`, `InstanceId`, `NodeName` `ClusterName`, `InstanceId`, `InstanceType`, `NodeName`, `NetworkInterfaceId` | O número de bytes por segundo recebidos usando operações de leitura de acesso remoto direto à memória pelos dispositivos EFA que estão alocados para o nó. Unidade: bytes/segundo |
| `node_efa_rdma_write_bytes` | `ClusterName` `ClusterName`, `InstanceId`, `NodeName` `ClusterName`, `InstanceId`, `InstanceType`, `NodeName`, `NetworkInterfaceId` | O número de bytes por segundo transmitidos usando operações de leitura de acesso remoto direto à memória pelos dispositivos EFA que estão alocados para o pod. Unidade: bytes/segundo |
| `node_efa_rdma_write_recv_bytes` | `ClusterName` `ClusterName`, `InstanceId`, `NodeName` `ClusterName`, `InstanceId`, `InstanceType`, `NodeName`, `NetworkInterfaceId` | O número de bytes por segundo recebidos durante operações de gravação de acesso remoto direto à memória pelos dispositivos EFA que estão alocados para o nó. Unidade: bytes/segundo |
## Métricas do Amazon SageMaker AI HyperPod
A partir da versão `v2.0.1-eksbuild.1` do complemento CloudWatch Observability do EKS, o Container Insights com observabilidade aprimorada para o Amazon EKS coleta automaticamente as métricas do Amazon SageMaker AI HyperPod de clusters do Amazon EKS. Para obter mais informações sobre o complemento, consulte [Instalação do agente do CloudWatch com o complemento de observabilidade do EKS do Amazon CloudWatch ou com o chart do Helm](install-CloudWatch-Observability-EKS-addon.md). Para obter mais informações sobre o Amazon SageMaker AI HyperPod, consulte [Amazon SageMaker AI HyperPod](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-hyperpod-eks.html).
As métricas que são coletadas estão listadas na tabela apresentada a seguir.
| Nome da métrica | Dimensões | Descrição |
| --- | --- | --- |
| `hyperpod_node_health_status_unschedulable` | `ClusterName` `ClusterName`, `InstanceId`, `NodeName` | Indica se um nó está rotulado como `Unschedulable` pelo Amazon SageMaker AI HyperPod. Isso significa que o nó está executando verificações de integridade aprofundadas e não está disponível para executar workloads. Unidade: Contagem |
| `hyperpod_node_health_status_schedulable` | `ClusterName` `ClusterName`, `InstanceId`, `NodeName` | Indica se um nó está rotulado como `Schedulable` pelo Amazon SageMaker AI HyperPod. Isso significa que o nó foi aprovado em verificações de integridade básicas ou em verificações de integridade aprofundadas e está disponível para executar workloads. Unidade: Contagem |
| `hyperpod_node_health_status_unschedulable_pending_replacement` | `ClusterName` `ClusterName`, `InstanceId`, `NodeName` | Indica se um nó está rotulado como `UnschedulablePendingReplacement` pelo HyperPod. Isso significa que o nó não foi aprovado em verificações de integridade aprofundadas ou em verificações do agente de monitoramento de integridade e precisa ser substituído. Se a recuperação automática de nó estiver habilitada, o nó será automaticamente substituído pelo Amazon SageMaker AI HyperPod. Unidade: Contagem |
| `hyperpod_node_health_status_unschedulable_pending_reboot` | `ClusterName` `ClusterName`, `InstanceId`, `NodeName` | Indica se um nó está rotulado como `UnschedulablePendingReboot` pelo Amazon SageMaker AI HyperPod. Isso significa que o nó está passando por verificações de integridade aprofundadas e precisa ser reiniciado. Se a recuperação automática de nó estiver habilitada, o nó será automaticamente reinicializado pelo Amazon SageMaker AI HyperPod. Unidade: Contagem |
## Métricas do driver do Amazon EBS NVMe
A partir da versão ` 1.300056.0` do agente do CloudWatch, o Container Insights com observabilidade aprimorada para o Amazon EKS coleta automaticamente métricas do driver do Amazon EBS NVMe de clusters do Amazon EKS em instâncias do Linux. O agente do CloudWatch deve ser instalado por meio do complemento CloudWatch Observability para Amazon EKS na versão `4.1.0` ou em versões posteriores. Para obter mais informações sobre o complemento, consulte [Instalação do agente do CloudWatch com o complemento de observabilidade do EKS do Amazon CloudWatch ou com o chart do Helm](install-CloudWatch-Observability-EKS-addon.md). Para obter mais informações sobre o Amazon EBS, consulte [Estatísticas de performance detalhadas do Amazon EBS](https://docs.aws.amazon.com/ebs/latest/userguide/nvme-detailed-performance-stats.html).
Para que o Container Insights colete métricas do driver do Amazon EBS NVMe, é necessário atender aos seguintes pré-requisitos:
+ Você deve usar o Container Insights com observabilidade aprimorada para o Amazon EKS e o complemento CloudWatch Observability para Amazon EKS na versão `4.1.0` ou posterior.
+ O complemento `1.42.0` do driver do EBS CSI ou o chart do Helm devem ser instalados no cluster com as métricas habilitadas.
+ Para habilitar as métricas ao usar o complemento do driver do Amazon EBS CSI, use a opção a seguir ao criar ou atualizar o complemento. `--configuration-values '{ "node": { "enableMetrics": true } }'`
+ Para habilitar as métricas, caso esteja usando o chart do Helm, use a opção a seguir ao criar ou atualizar o complemento. `--set node.enableMetrics=true`
As métricas que são coletadas estão listadas na tabela apresentada a seguir.
| Nome da métrica | Dimensões | Descrição |
| --- | --- | --- |
| `node_diskio_ebs_total_read_ops` | `ClusterName` `ClusterName`, `NodeName`, `InstanceId` `ClusterName`, `NodeName`, `InstanceId` `VolumeId` | O número total de operações de leitura concluídas. |
| `node_diskio_ebs_total_write_ops` | `ClusterName` `ClusterName`, `NodeName`, `InstanceId` `ClusterName`, `NodeName`, `InstanceId` `VolumeId` | O número total de operações de gravação concluídas. |
| `node_diskio_ebs_total_read_bytes` | `ClusterName` `ClusterName`, `NodeName`, `InstanceId` `ClusterName`, `NodeName`, `InstanceId` `VolumeId` | O número total de bytes de leitura transferidos. |
| `node_diskio_ebs_total_write_bytes` | `ClusterName` `ClusterName`, `NodeName`, `InstanceId` `ClusterName`, `NodeName`, `InstanceId` `VolumeId` | O número total de bytes de gravação transferidos. |
| `node_diskio_ebs_total_read_time` | `ClusterName` `ClusterName`, `NodeName`, `InstanceId` `ClusterName`, `NodeName`, `InstanceId` `VolumeId` | O tempo total gasto, em microssegundos, por todas as operações de leitura concluídas. |
| `node_diskio_ebs_total_write_time` | `ClusterName` `ClusterName`, `NodeName`, `InstanceId` `ClusterName`, `NodeName`, `InstanceId` `VolumeId` | O tempo total gasto, em microssegundos, por todas as operações de gravação concluídas. |
| `node_diskio_ebs_volume_performance_exceeded_iops` | `ClusterName` `ClusterName`, `NodeName`, `InstanceId` `ClusterName`, `NodeName`, `InstanceId` `VolumeId` | O tempo total, em microssegundos, em que a demanda de IOPS excedeu a performance das IOPS provisionadas do volume. |
| `node_diskio_ebs_volume_performance_exceeded_tp` | `ClusterName` `ClusterName`, `NodeName`, `InstanceId` `ClusterName`, `NodeName`, `InstanceId` `VolumeId` | O tempo total, em microssegundos, em que a demanda de throughput excedeu a performance do throughput provisionado. |
| `node_diskio_ebs_ec2_instance_performance_exceeded_iops` | `ClusterName` `ClusterName`, `NodeName`, `InstanceId` `ClusterName`, `NodeName`, `InstanceId` `VolumeId` | O tempo total, em microssegundos, em que o volume do EBS excedeu a performance máxima de IOPS da instância do Amazon EC2 conectada. |
| `node_diskio_ebs_ec2_instance_performance_exceeded_tp` | `ClusterName` `ClusterName`, `NodeName`, `InstanceId` `ClusterName`, `NodeName`, `InstanceId` `VolumeId` | O tempo total, em microssegundos, em que o volume do EBS excedeu a performance máxima de throughput da instância do Amazon EC2 conectada. |
| `node_diskio_ebs_volume_queue_length` | `ClusterName` `ClusterName`, `NodeName`, `InstanceId` `ClusterName`, `NodeName`, `InstanceId` `VolumeId` | O número de solicitações de operação de leitura e gravação aguardando conclusão. |
# Métricas do Container Insights do Amazon EKS e do Kubernetes
As tabelas a seguir listam as métricas e as dimensões que o Container Insights coleta para o Amazon EKS e Kubernetes. Essas métricas estão no namespace `ContainerInsights`. Para obter mais informações, consulte [Métricas](cloudwatch_concepts.md#Metric).
Se você não vir as métricas do Container Insights no seu console, certifique-se de que você tenha concluído a configuração do Container Insights. As métricas não serão exibidas até que o Container Insights tenha sido configurado completamente. Para obter mais informações, consulte [Configurar o Container Insights](deploy-container-insights.md).
| Nome da métrica | Dimensões | Descrição |
| --- | --- | --- |
| `cluster_failed_node_count` | `ClusterName` | O número de nós do operador com falha no cluster. Um nó é considerado com falha quando apresenta qualquer *condição de nó*. Para obter mais informações, consulte [Condições](https://kubernetes.io/docs/concepts/architecture/nodes/#condition) na documentação do Kubernetes. |
| `cluster_node_count` | `ClusterName` | O número total de nós do operador no cluster. |
| `namespace_number_of_running_pods` | `Namespace` `ClusterName` `ClusterName` | O número de pods em execução por namespace no recurso especificado pelas dimensões que você está usando. |
| `node_cpu_limit` | `ClusterName` | O número máximo de unidades de CPU que pode ser atribuído a um único nó neste cluster. |
| `node_cpu_reserved_capacity` | `NodeName`, `ClusterName`, `InstanceId` `ClusterName` | A porcentagem de unidades de CPU reservadas para componentes do nó, como kubelet, kube-proxy e Docker. Fórmula: `node_cpu_request / node_cpu_limit` `node_cpu_request` não é relatado diretamente como uma métrica, mas é um campo em eventos de log de performance. Para obter mais informações, consulte [Campos relevantes nos eventos de log de performance para Amazon EKS e Kubernetes](Container-Insights-reference-performance-entries-EKS.md). |
| `node_cpu_usage_total` | `ClusterName` | O número de unidades da CPU que está sendo usado nos nós do cluster. |
| `node_cpu_utilization` | `NodeName`, `ClusterName`, `InstanceId` `ClusterName` | A porcentagem total de unidades de CPU que está sendo usada nos nós do cluster. Fórmula: `node_cpu_usage_total / node_cpu_limit` |
| `node_gpu_limit` | `ClusterName` `ClusterName`, `InstanceId`, `NodeName` | O número total de GPUs disponíveis no nó. |
| `node_gpu_usage_total` | `ClusterName` `ClusterName`, `InstanceId`, `NodeName` | O número de GPUs em uso pelos pods em execução no nó. |
| `node_gpu_reserved_capacity` | `ClusterName` `ClusterName`, `InstanceId`, `NodeName` | A porcentagem de GPU atualmente em reserva no nó. A fórmula é `node_gpu_request / node_gpu_limit`. `node_gpu_request` não é relatado diretamente como uma métrica, mas é um campo em eventos de log de performance. Para obter mais informações, consulte [Campos relevantes nos eventos de log de performance para Amazon EKS e Kubernetes](Container-Insights-reference-performance-entries-EKS.md). |
| `node_filesystem_utilization` | `NodeName`, `ClusterName`, `InstanceId` `ClusterName` | A porcentagem total da capacidade do sistema de arquivos que está sendo usado nos nós do cluster. Fórmula: `node_filesystem_usage / node_filesystem_capacity` `node_filesystem_usage` e `node_filesystem_capacity` não são relatados diretamente como métricas, mas são campos em eventos de log de performance. Para obter mais informações, consulte [Campos relevantes nos eventos de log de performance para Amazon EKS e Kubernetes](Container-Insights-reference-performance-entries-EKS.md). |
| `node_memory_limit` | `ClusterName` | A quantidade máxima de memória, em bytes, que pode ser atribuída a um único nó neste cluster. |
| `node_memory_reserved_capacity` | `NodeName`, `ClusterName`, `InstanceId` `ClusterName` | A porcentagem de memória que está sendo usada no momento nos nós do cluster. Fórmula: `node_memory_request / node_memory_limit` `node_memory_request` não é relatado diretamente como uma métrica, mas é um campo em eventos de log de performance. Para obter mais informações, consulte [Campos relevantes nos eventos de log de performance para Amazon EKS e Kubernetes](Container-Insights-reference-performance-entries-EKS.md). |
| `node_memory_utilization` | `NodeName`, `ClusterName`, `InstanceId` `ClusterName` | A porcentagem de memória que está sendo usada no momento pelo nó ou nós. É o percentual de uso de memória de nó dividido pela limitação de memória de nó. Fórmula: `node_memory_working_set / node_memory_limit`. |
| `node_memory_working_set` | `ClusterName` | A quantidade de memória, em bytes, sendo usada no conjunto de trabalho dos nós no cluster. |
| `node_network_total_bytes` | `NodeName`, `ClusterName`, `InstanceId` `ClusterName` | O número total de bytes transmitidos e recebidos por segundo pela rede por nó em um cluster. Fórmula: `node_network_rx_bytes + node_network_tx_bytes` `node_network_rx_bytes` e `node_network_tx_bytes` não são relatados diretamente como métricas, mas são campos em eventos de log de performance. Para obter mais informações, consulte [Campos relevantes nos eventos de log de performance para Amazon EKS e Kubernetes](Container-Insights-reference-performance-entries-EKS.md). |
| `node_number_of_running_containers` | `NodeName`, `ClusterName`, `InstanceId` `ClusterName` | O número de contêineres em execução por nó em um cluster. |
| `node_number_of_running_pods` | `NodeName`, `ClusterName`, `InstanceId` `ClusterName` | O número de pods em execução por nó em um cluster. |
| `pod_cpu_reserved_capacity` | `PodName`, `Namespace`, `ClusterName` `ClusterName` | A capacidade da CPU reservada por pod em um cluster. Fórmula: `pod_cpu_request / node_cpu_limit` `pod_cpu_request` não é relatado diretamente como uma métrica, mas é um campo em eventos de log de performance. Para obter mais informações, consulte [Campos relevantes nos eventos de log de performance para Amazon EKS e Kubernetes](Container-Insights-reference-performance-entries-EKS.md). |
| `pod_cpu_utilization` | `PodName`, `Namespace`, `ClusterName` `Namespace`, `ClusterName` `Service`, `Namespace`, `ClusterName` `ClusterName` | A porcentagem de unidades de CPU que estão sendo usadas por pods. Fórmula: `pod_cpu_usage_total / node_cpu_limit` |
| `pod_cpu_utilization_over_pod_limit` | `PodName`, `Namespace`, `ClusterName` `Namespace`, `ClusterName` `Service`, `Namespace`, `ClusterName` `ClusterName` | O percentual das unidades de CPU que estão sendo usadas por pods com relação ao limite de pods. Fórmula: `pod_cpu_usage_total / pod_cpu_limit` |
| `pod_gpu_request` | `ClusterName` `ClusterName`, `Namespace`, `PodName` `ClusterName`, `FullPodName`, `Namespace`, `PodName` | As solicitações de GPU para o pod. Esse valor deve ser sempre igual a `pod_gpu_limit`. |
| `pod_gpu_limit` | `ClusterName` `ClusterName`, `Namespace`, `PodName` `ClusterName`, `FullPodName`, `Namespace`, `PodName` | O número máximo de GPUs que podem ser atribuídas ao pod em um nó. |
| `pod_gpu_usage_total` | `ClusterName` `ClusterName`, `Namespace`, `PodName` `ClusterName`, `FullPodName`, `Namespace`, `PodName` | O número de GPUs que estão sendo alocadas no pod. |
| `pod_gpu_reserved_capacity` | `ClusterName` `ClusterName`, `Namespace`, `PodName` `ClusterName`, `FullPodName`, `Namespace`, `PodName` | A porcentagem de GPU atualmente em reserva para o pod. A fórmula é - pod\$1gpu\$1request / node\$1gpu\$1reserved\$1capacity. |
| `pod_memory_reserved_capacity` | `PodName`, `Namespace`, `ClusterName` `ClusterName` | A porcentagem de memória reservada para pods. Fórmula: `pod_memory_request / node_memory_limit` `pod_memory_request` não é relatado diretamente como uma métrica, mas é um campo em eventos de log de performance. Para obter mais informações, consulte [Campos relevantes nos eventos de log de performance para Amazon EKS e Kubernetes](Container-Insights-reference-performance-entries-EKS.md). |
| `pod_memory_utilization` | `PodName`, `Namespace`, `ClusterName` `Namespace`, `ClusterName` `Service`, `Namespace`, `ClusterName` `ClusterName` | A porcentagem de memória que está sendo usada atualmente pelo pod ou pods. Fórmula: `pod_memory_working_set / node_memory_limit` |
| `pod_memory_utilization_over_pod_limit` | `PodName`, `Namespace`, `ClusterName` `Namespace`, `ClusterName` `Service`, `Namespace`, `ClusterName` `ClusterName` | O percentual de memória que está sendo usada por pods com relação ao limite de pods. Se qualquer contêiner no pod não tiver um limite de memória definido, essa métrica não aparecerá. Fórmula: `pod_memory_working_set / pod_memory_limit` |
| `pod_network_rx_bytes` | `PodName`, `Namespace`, `ClusterName` `Namespace`, `ClusterName` `Service`, `Namespace`, `ClusterName` `ClusterName` | O número de bytes que estão sendo recebidos por segundo na rede pelo pod. Fórmula: `sum(pod_interface_network_rx_bytes)` `pod_interface_network_rx_bytes` não é relatado diretamente como uma métrica, mas é um campo em eventos de log de performance. Para obter mais informações, consulte [Campos relevantes nos eventos de log de performance para Amazon EKS e Kubernetes](Container-Insights-reference-performance-entries-EKS.md). |
| `pod_network_tx_bytes` | `PodName`, `Namespace`, `ClusterName` `Namespace`, `ClusterName` `Service`, `Namespace`, `ClusterName` `ClusterName` | O número de bytes que estão sendo transmitidos por segundo na rede pelo pod. Fórmula: `sum(pod_interface_network_tx_bytes)` `pod_interface_network_tx_bytes` não é relatado diretamente como uma métrica, mas é um campo em eventos de log de performance. Para obter mais informações, consulte [Campos relevantes nos eventos de log de performance para Amazon EKS e Kubernetes](Container-Insights-reference-performance-entries-EKS.md). |
| `pod_number_of_container_restarts` | `PodName`, `Namespace`, `ClusterName` | O número total de reinicializações de contêineres em um pod. |
| `service_number_of_running_pods` | `Service`, `Namespace`, `ClusterName` `ClusterName` | O número de pods que executam o serviço ou os serviços no cluster. |
## Métricas do Kueue
A partir da versão `v2.4.0-eksbuild.1` do complemento CloudWatch Observability EKS, o Container Insights para Amazon EKS coleta automaticamente as métricas do Kueue de clusters do Amazon EKS. Para obter mais informações sobre o complemento, consulte [Instalação do agente do CloudWatch com o complemento de observabilidade do EKS do Amazon CloudWatch ou com o chart do Helm](install-CloudWatch-Observability-EKS-addon.md).
Para obter informações sobre como habilitar as métricas, consulte [Habilitar métricas do Kueue](install-CloudWatch-Observability-EKS-addon.md#enable-Kueue-metrics) para habilitá-las.
As métricas do Kueue que são coletadas estão listadas na tabela apresentada a seguir. Essas métricas são publicadas no namespace `ContainerInsights/Prometheus` do CloudWatch. Para filtrar essas métricas, use as seguintes dimensões:
+ `ClusterQueue` é o nome do ClusterQueue
+ Os valores possíveis de `Status` são `active` e `inadmissible`
+ Os valores possíveis de `Reason` são `Preempted`, `PodsReadyTimeout`, `AdmissionCheck`, `ClusterQueueStopped` e `InactiveWorkload`
+ `Flavor` é o qualificador referenciado.
+ `Resource` refere-se aos recursos do computador do cluster, como `cpu`, `memory`, `gpu` etc.
| Nome da métrica | Dimensões | Descrição |
| --- | --- | --- |
| `kueue_pending_workloads` | `ClusterName`, `ClusterQueue`, `Status` `ClusterName`, `ClusterQueue` `ClusterName`, `Status` `ClusterName` | O número de workloads pendentes. |
| `kueue_evicted_workloads_total` | `ClusterName`, `ClusterQueue`, `Reason` `ClusterName`, `ClusterQueue` `ClusterName`, `Reason` `ClusterName` | O número total de workloads removidas. |
| `kueue_admitted_active_workloads` | `ClusterName`, `ClusterQueue` `ClusterName` | O número de workloads admitidas que estão ativas (não suspensas e não concluídas). |
| `kueue_cluster_queue_resource_usage` | `ClusterName`, `ClusterQueue`, `Resource`, `Flavor` `ClusterName`, `ClusterQueue`, `Resource` `ClusterName`, `ClusterQueue`, `Flavor` `ClusterName`, `ClusterQueue` `ClusterName` | Relata o uso total de recursos do ClusterQueue. |
| `kueue_cluster_queue_nominal_quota` | `ClusterName`, `ClusterQueue`, `Resource`, `Flavor` `ClusterName`, `ClusterQueue`, `Resource` `ClusterName`, `ClusterQueue`, `Flavor` `ClusterName`, `ClusterQueue` `ClusterName` | Relata a cota de recursos do ClusterQueue. |
# Referência do log de performance do Container Insights
Esta seção contém informações de referência sobre como o Container Insights usa eventos de log de performance para coletar métricas. Quando você implanta o Container Insights, ele cria automaticamente um grupo de logs para os eventos do log de performance. Você não precisa criar esse grupo de logs sozinho.
**Topics**
+ [Eventos de log de performance do Container Insights para Amazon ECS](Container-Insights-reference-performance-logs-ECS.md)
+ [Eventos do log de performance do Container Insights para Amazon EKS e Kubernetes](Container-Insights-reference-performance-logs-EKS.md)
+ [Campos relevantes nos eventos de log de performance para Amazon EKS e Kubernetes](Container-Insights-reference-performance-entries-EKS.md)
# Eventos de log de performance do Container Insights para Amazon ECS
Veja a seguir exemplos dos eventos de log de performance que o Container Insights coleta do Amazon ECS.
Esses logs estão no CloudWatch Logs, em um grupo de logs chamado `/aws/ecs/containerinsights/CLUSTER_NAME/performance`. Dentro desse grupo de logs, cada instância de contêiner terá um fluxo de logs chamado `AgentTelemetry-CONTAINER_INSTANCE_ID`.
É possível consultar esses logs usando consultas como `{ $.Type = "Container" }` para visualizar todos os eventos do log de contêiner.
**Tipo: Container**
```
{
"Version":"0",
"Type":"Container",
"ContainerName":"sleep",
"TaskId":"7ac4dfba69214411b4783a3b8189c9ba",
"TaskDefinitionFamily":"sleep360",
"TaskDefinitionRevision":"1",
"ContainerInstanceId":"0d7650e6dec34c1a9200f72098071e8f",
"EC2InstanceId":"i-0c470579dbcdbd2f3",
"ClusterName":"MyCluster",
"Image":"busybox",
"ContainerKnownStatus":"RUNNING",
"Timestamp":1623963900000,
"CpuUtilized":0.0,
"CpuReserved":10.0,
"MemoryUtilized":0,
"MemoryReserved":10,
"StorageReadBytes":0,
"StorageWriteBytes":0,
"NetworkRxBytes":0,
"NetworkRxDropped":0,
"NetworkRxErrors":0,
"NetworkRxPackets":14,
"NetworkTxBytes":0,
"NetworkTxDropped":0,
"NetworkTxErrors":0,
"NetworkTxPackets":0
}
```
**Tipo: tarefa**
Embora as unidades para `StorageReadBytes` e `StorageWriteBytes` sejam expressas em Bytes por segundo, os valores representam, respectivamente, o valor total acumulado de bytes lidos e gravados no armazenamento.
```
{
"Version": "0",
"Type": "Task",
"TaskId": "7ac4dfba69214411b4783a3b8189c9ba",
"TaskDefinitionFamily": "sleep360",
"TaskDefinitionRevision": "1",
"ContainerInstanceId": "0d7650e6dec34c1a9200f72098071e8f",
"EC2InstanceId": "i-0c470579dbcdbd2f3",
"ClusterName": "MyCluster",
"AccountID": "637146863587",
"Region": "us-west-2",
"AvailabilityZone": "us-west-2b",
"KnownStatus": "RUNNING",
"LaunchType": "EC2",
"PullStartedAt": 1623963608201,
"PullStoppedAt": 1623963610065,
"CreatedAt": 1623963607094,
"StartedAt": 1623963610382,
"Timestamp": 1623963900000,
"CpuUtilized": 0.0,
"CpuReserved": 10.0,
"MemoryUtilized": 0,
"MemoryReserved": 10,
"StorageReadBytes": 0,
"StorageWriteBytes": 0,
"NetworkRxBytes": 0,
"NetworkRxDropped": 0,
"NetworkRxErrors": 0,
"NetworkRxPackets": 14,
"NetworkTxBytes": 0,
"NetworkTxDropped": 0,
"NetworkTxErrors": 0,
"NetworkTxPackets": 0,
"EBSFilesystemUtilized": 10,
"EBSFilesystemSize": 20,
"CloudWatchMetrics": [
{
"Namespace": "ECS/ContainerInsights",
"Metrics": [
{
"Name": "CpuUtilized",
"Unit": "None"
},
{
"Name": "CpuReserved",
"Unit": "None"
},
{
"Name": "MemoryUtilized",
"Unit": "Megabytes"
},
{
"Name": "MemoryReserved",
"Unit": "Megabytes"
},
{
"Name": "StorageReadBytes",
"Unit": "Bytes/Second"
},
{
"Name": "StorageWriteBytes",
"Unit": "Bytes/Second"
},
{
"Name": "NetworkRxBytes",
"Unit": "Bytes/Second"
},
{
"Name": "NetworkTxBytes",
"Unit": "Bytes/Second"
},
{
"Name": "EBSFilesystemSize",
"Unit": "Gigabytes"
},
{
"Name": "EBSFilesystemUtilzed",
"Unit": "Gigabytes"
}
],
"Dimensions": [
["ClusterName"],
[
"ClusterName",
"TaskDefinitionFamily"
]
]
}
]
}
```
**Tipo: Service**
```
{
"Version": "0",
"Type": "Service",
"ServiceName": "myCIService",
"ClusterName": "myCICluster",
"Timestamp": 1561586460000,
"DesiredTaskCount": 2,
"RunningTaskCount": 2,
"PendingTaskCount": 0,
"DeploymentCount": 1,
"TaskSetCount": 0,
"CloudWatchMetrics": [
{
"Namespace": "ECS/ContainerInsights",
"Metrics": [
{
"Name": "DesiredTaskCount",
"Unit": "Count"
},
{
"Name": "RunningTaskCount",
"Unit": "Count"
},
{
"Name": "PendingTaskCount",
"Unit": "Count"
},
{
"Name": "DeploymentCount",
"Unit": "Count"
},
{
"Name": "TaskSetCount",
"Unit": "Count"
}
],
"Dimensions": [
[
"ServiceName",
"ClusterName"
]
]
}
]
}
```
**Tipo: volume**
```
{
"Version": "0",
"Type": "Volume",
"TaskDefinitionFamily": "myCITaskDef",
"TaskId": "7ac4dfba69214411b4783a3b8189c9ba",
"ClusterName": "myCICluster",
"ServiceName": "myCIService",
"VolumeId": "vol-1233436545ff708cb",
"InstanceId": "i-0c470579dbcdbd2f3",
"LaunchType": "EC2",
"VolumeName": "MyVolumeName",
"EBSFilesystemUtilized": 10,
"EBSFilesystemSize": 20,
"CloudWatchMetrics": [
{
"Namespace": "ECS/ContainerInsights",
"Metrics": [
{
"Name": "EBSFilesystemSize",
"Unit": "Gigabytes"
},
{
"Name": "EBSFilesystemUtilzed",
"Unit": "Gigabytes"
}
],
"Dimensions": [
["ClusterName"],
[
"VolumeName",
"TaskDefinitionFamily",
"ClusterName"
],
[
"ServiceName",
"ClusterName"
]
]
}
]
}
```
**Tipo: Cluster**
```
{
"Version": "0",
"Type": "Cluster",
"ClusterName": "myCICluster",
"Timestamp": 1561587300000,
"TaskCount": 5,
"ContainerInstanceCount": 5,
"ServiceCount": 2,
"CloudWatchMetrics": [
{
"Namespace": "ECS/ContainerInsights",
"Metrics": [
{
"Name": "TaskCount",
"Unit": "Count"
},
{
"Name": "ContainerInstanceCount",
"Unit": "Count"
},
{
"Name": "ServiceCount",
"Unit": "Count"
}
],
"Dimensions": [
[
"ClusterName"
]
]
}
]
}
```
# Eventos do log de performance do Container Insights para Amazon EKS e Kubernetes
Veja a seguir exemplos dos eventos de log de performance que o Container Insights coleta dos clusters do Amazon EKS e do Kubernetes.
**Tipo: Node**
```
{
"AutoScalingGroupName": "eksctl-myCICluster-nodegroup-standard-workers-NodeGroup-1174PV2WHZAYU",
"CloudWatchMetrics": [
{
"Metrics": [
{
"Unit": "Percent",
"Name": "node_cpu_utilization"
},
{
"Unit": "Percent",
"Name": "node_memory_utilization"
},
{
"Unit": "Bytes/Second",
"Name": "node_network_total_bytes"
},
{
"Unit": "Percent",
"Name": "node_cpu_reserved_capacity"
},
{
"Unit": "Percent",
"Name": "node_memory_reserved_capacity"
},
{
"Unit": "Count",
"Name": "node_number_of_running_pods"
},
{
"Unit": "Count",
"Name": "node_number_of_running_containers"
}
],
"Dimensions": [
[
"NodeName",
"InstanceId",
"ClusterName"
]
],
"Namespace": "ContainerInsights"
},
{
"Metrics": [
{
"Unit": "Percent",
"Name": "node_cpu_utilization"
},
{
"Unit": "Percent",
"Name": "node_memory_utilization"
},
{
"Unit": "Bytes/Second",
"Name": "node_network_total_bytes"
},
{
"Unit": "Percent",
"Name": "node_cpu_reserved_capacity"
},
{
"Unit": "Percent",
"Name": "node_memory_reserved_capacity"
},
{
"Unit": "Count",
"Name": "node_number_of_running_pods"
},
{
"Unit": "Count",
"Name": "node_number_of_running_containers"
},
{
"Name": "node_cpu_usage_total"
},
{
"Name": "node_cpu_limit"
},
{
"Unit": "Bytes",
"Name": "node_memory_working_set"
},
{
"Unit": "Bytes",
"Name": "node_memory_limit"
}
],
"Dimensions": [
[
"ClusterName"
]
],
"Namespace": "ContainerInsights"
}
],
"ClusterName": "myCICluster",
"InstanceId": "i-1234567890123456",
"InstanceType": "t3.xlarge",
"NodeName": "ip-192-0-2-0.us-west-2.compute.internal",
"Sources": [
"cadvisor",
"/proc",
"pod",
"calculated"
],
"Timestamp": "1567096682364",
"Type": "Node",
"Version": "0",
"kubernetes": {
"host": "ip-192-168-75-26.us-west-2.compute.internal"
},
"node_cpu_limit": 4000,
"node_cpu_request": 1130,
"node_cpu_reserved_capacity": 28.249999999999996,
"node_cpu_usage_system": 33.794636630852764,
"node_cpu_usage_total": 136.47852169244098,
"node_cpu_usage_user": 71.67075111567326,
"node_cpu_utilization": 3.4119630423110245,
"node_memory_cache": 3103297536,
"node_memory_failcnt": 0,
"node_memory_hierarchical_pgfault": 0,
"node_memory_hierarchical_pgmajfault": 0,
"node_memory_limit": 16624865280,
"node_memory_mapped_file": 406646784,
"node_memory_max_usage": 4230746112,
"node_memory_pgfault": 0,
"node_memory_pgmajfault": 0,
"node_memory_request": 1115684864,
"node_memory_reserved_capacity": 6.7109407818311055,
"node_memory_rss": 798146560,
"node_memory_swap": 0,
"node_memory_usage": 3901444096,
"node_memory_utilization": 6.601302600149552,
"node_memory_working_set": 1097457664,
"node_network_rx_bytes": 35918.392817386324,
"node_network_rx_dropped": 0,
"node_network_rx_errors": 0,
"node_network_rx_packets": 157.67565245448117,
"node_network_total_bytes": 68264.20276554905,
"node_network_tx_bytes": 32345.80994816272,
"node_network_tx_dropped": 0,
"node_network_tx_errors": 0,
"node_network_tx_packets": 154.21455923431654,
"node_number_of_running_containers": 16,
"node_number_of_running_pods": 13
}
```
**Tipo: NodeFS**
```
{
"AutoScalingGroupName": "eksctl-myCICluster-nodegroup-standard-workers-NodeGroup-1174PV2WHZAYU",
"CloudWatchMetrics": [
{
"Metrics": [
{
"Unit": "Percent",
"Name": "node_filesystem_utilization"
}
],
"Dimensions": [
[
"NodeName",
"InstanceId",
"ClusterName"
],
[
"ClusterName"
]
],
"Namespace": "ContainerInsights"
}
],
"ClusterName": "myCICluster",
"EBSVolumeId": "aws://us-west-2b/vol-0a53108976d4a2fda",
"InstanceId": "i-1234567890123456",
"InstanceType": "t3.xlarge",
"NodeName": "ip-192-0-2-0.us-west-2.compute.internal",
"Sources": [
"cadvisor",
"calculated"
],
"Timestamp": "1567097939726",
"Type": "NodeFS",
"Version": "0",
"device": "/dev/nvme0n1p1",
"fstype": "vfs",
"kubernetes": {
"host": "ip-192-168-75-26.us-west-2.compute.internal"
},
"node_filesystem_available": 17298395136,
"node_filesystem_capacity": 21462233088,
"node_filesystem_inodes": 10484720,
"node_filesystem_inodes_free": 10367158,
"node_filesystem_usage": 4163837952,
"node_filesystem_utilization": 19.400767547940255
}
```
**Tipo: NodeDiskIO**
```
{
"AutoScalingGroupName": "eksctl-myCICluster-nodegroup-standard-workers-NodeGroup-1174PV2WHZAYU",
"ClusterName": "myCICluster",
"EBSVolumeId": "aws://us-west-2b/vol-0a53108976d4a2fda",
"InstanceId": "i-1234567890123456",
"InstanceType": "t3.xlarge",
"NodeName": "ip-192-0-2-0.us-west-2.compute.internal",
"Sources": [
"cadvisor"
],
"Timestamp": "1567096928131",
"Type": "NodeDiskIO",
"Version": "0",
"device": "/dev/nvme0n1",
"kubernetes": {
"host": "ip-192-168-75-26.us-west-2.compute.internal"
},
"node_diskio_io_service_bytes_async": 9750.505814277016,
"node_diskio_io_service_bytes_read": 0,
"node_diskio_io_service_bytes_sync": 230.6174506688036,
"node_diskio_io_service_bytes_total": 9981.123264945818,
"node_diskio_io_service_bytes_write": 9981.123264945818,
"node_diskio_io_serviced_async": 1.153087253344018,
"node_diskio_io_serviced_read": 0,
"node_diskio_io_serviced_sync": 0.03603397666700056,
"node_diskio_io_serviced_total": 1.1891212300110185,
"node_diskio_io_serviced_write": 1.1891212300110185
}
```
**Tipo: NodeNet**
```
{
"AutoScalingGroupName": "eksctl-myCICluster-nodegroup-standard-workers-NodeGroup-1174PV2WHZAYU",
"ClusterName": "myCICluster",
"InstanceId": "i-1234567890123456",
"InstanceType": "t3.xlarge",
"NodeName": "ip-192-0-2-0.us-west-2.compute.internal",
"Sources": [
"cadvisor",
"calculated"
],
"Timestamp": "1567096928131",
"Type": "NodeNet",
"Version": "0",
"interface": "eni972f6bfa9a0",
"kubernetes": {
"host": "ip-192-168-75-26.us-west-2.compute.internal"
},
"node_interface_network_rx_bytes": 3163.008420864309,
"node_interface_network_rx_dropped": 0,
"node_interface_network_rx_errors": 0,
"node_interface_network_rx_packets": 16.575629266820258,
"node_interface_network_total_bytes": 3518.3935157426017,
"node_interface_network_tx_bytes": 355.385094878293,
"node_interface_network_tx_dropped": 0,
"node_interface_network_tx_errors": 0,
"node_interface_network_tx_packets": 3.9997714100370625
}
```
**Tipo: Pod**
```
{
"AutoScalingGroupName": "eksctl-myCICluster-nodegroup-standard-workers-NodeGroup-1174PV2WHZAYU",
"CloudWatchMetrics": [
{
"Metrics": [
{
"Unit": "Percent",
"Name": "pod_cpu_utilization"
},
{
"Unit": "Percent",
"Name": "pod_memory_utilization"
},
{
"Unit": "Bytes/Second",
"Name": "pod_network_rx_bytes"
},
{
"Unit": "Bytes/Second",
"Name": "pod_network_tx_bytes"
},
{
"Unit": "Percent",
"Name": "pod_cpu_utilization_over_pod_limit"
},
{
"Unit": "Percent",
"Name": "pod_memory_utilization_over_pod_limit"
}
],
"Dimensions": [
[
"PodName",
"Namespace",
"ClusterName"
],
[
"Service",
"Namespace",
"ClusterName"
],
[
"Namespace",
"ClusterName"
],
[
"ClusterName"
]
],
"Namespace": "ContainerInsights"
},
{
"Metrics": [
{
"Unit": "Percent",
"Name": "pod_cpu_reserved_capacity"
},
{
"Unit": "Percent",
"Name": "pod_memory_reserved_capacity"
}
],
"Dimensions": [
[
"PodName",
"Namespace",
"ClusterName"
],
[
"ClusterName"
]
],
"Namespace": "ContainerInsights"
},
{
"Metrics": [
{
"Unit": "Count",
"Name": "pod_number_of_container_restarts"
}
],
"Dimensions": [
[
"PodName",
"Namespace",
"ClusterName"
]
],
"Namespace": "ContainerInsights"
}
],
"ClusterName": "myCICluster",
"InstanceId": "i-1234567890123456",
"InstanceType": "t3.xlarge",
"Namespace": "amazon-cloudwatch",
"NodeName": "ip-192-0-2-0.us-west-2.compute.internal",
"PodName": "cloudwatch-agent-statsd",
"Service": "cloudwatch-agent-statsd",
"Sources": [
"cadvisor",
"pod",
"calculated"
],
"Timestamp": "1567097351092",
"Type": "Pod",
"Version": "0",
"kubernetes": {
"host": "ip-192-168-75-26.us-west-2.compute.internal",
"labels": {
"app": "cloudwatch-agent-statsd",
"pod-template-hash": "df44f855f"
},
"namespace_name": "amazon-cloudwatch",
"pod_id": "2f4ff5ac-c813-11e9-a31d-06e9dde32928",
"pod_name": "cloudwatch-agent-statsd-df44f855f-ts4q2",
"pod_owners": [
{
"owner_kind": "Deployment",
"owner_name": "cloudwatch-agent-statsd"
}
],
"service_name": "cloudwatch-agent-statsd"
},
"pod_cpu_limit": 200,
"pod_cpu_request": 200,
"pod_cpu_reserved_capacity": 5,
"pod_cpu_usage_system": 1.4504841104992765,
"pod_cpu_usage_total": 5.817016867430125,
"pod_cpu_usage_user": 1.1281543081661038,
"pod_cpu_utilization": 0.14542542168575312,
"pod_cpu_utilization_over_pod_limit": 2.9085084337150624,
"pod_memory_cache": 8192,
"pod_memory_failcnt": 0,
"pod_memory_hierarchical_pgfault": 0,
"pod_memory_hierarchical_pgmajfault": 0,
"pod_memory_limit": 104857600,
"pod_memory_mapped_file": 0,
"pod_memory_max_usage": 25268224,
"pod_memory_pgfault": 0,
"pod_memory_pgmajfault": 0,
"pod_memory_request": 104857600,
"pod_memory_reserved_capacity": 0.6307275170893897,
"pod_memory_rss": 22777856,
"pod_memory_swap": 0,
"pod_memory_usage": 25141248,
"pod_memory_utilization": 0.10988455961791709,
"pod_memory_utilization_over_pod_limit": 17.421875,
"pod_memory_working_set": 18268160,
"pod_network_rx_bytes": 9880.697124714186,
"pod_network_rx_dropped": 0,
"pod_network_rx_errors": 0,
"pod_network_rx_packets": 107.80005532263283,
"pod_network_total_bytes": 10158.829201483635,
"pod_network_tx_bytes": 278.13207676944796,
"pod_network_tx_dropped": 0,
"pod_network_tx_errors": 0,
"pod_network_tx_packets": 1.146027574644318,
"pod_number_of_container_restarts": 0,
"pod_number_of_containers": 1,
"pod_number_of_running_containers": 1,
"pod_status": "Running"
}
```
**Tipo: PodNet**
```
{
"AutoScalingGroupName": "eksctl-myCICluster-nodegroup-standard-workers-NodeGroup-1174PV2WHZAYU",
"ClusterName": "myCICluster",
"InstanceId": "i-1234567890123456",
"InstanceType": "t3.xlarge",
"Namespace": "amazon-cloudwatch",
"NodeName": "ip-192-0-2-0.us-west-2.compute.internal",
"PodName": "cloudwatch-agent-statsd",
"Service": "cloudwatch-agent-statsd",
"Sources": [
"cadvisor",
"calculated"
],
"Timestamp": "1567097351092",
"Type": "PodNet",
"Version": "0",
"interface": "eth0",
"kubernetes": {
"host": "ip-192-168-75-26.us-west-2.compute.internal",
"labels": {
"app": "cloudwatch-agent-statsd",
"pod-template-hash": "df44f855f"
},
"namespace_name": "amazon-cloudwatch",
"pod_id": "2f4ff5ac-c813-11e9-a31d-06e9dde32928",
"pod_name": "cloudwatch-agent-statsd-df44f855f-ts4q2",
"pod_owners": [
{
"owner_kind": "Deployment",
"owner_name": "cloudwatch-agent-statsd"
}
],
"service_name": "cloudwatch-agent-statsd"
},
"pod_interface_network_rx_bytes": 9880.697124714186,
"pod_interface_network_rx_dropped": 0,
"pod_interface_network_rx_errors": 0,
"pod_interface_network_rx_packets": 107.80005532263283,
"pod_interface_network_total_bytes": 10158.829201483635,
"pod_interface_network_tx_bytes": 278.13207676944796,
"pod_interface_network_tx_dropped": 0,
"pod_interface_network_tx_errors": 0,
"pod_interface_network_tx_packets": 1.146027574644318
}
```
**Tipo: Container**
```
{
"AutoScalingGroupName": "eksctl-myCICluster-nodegroup-standard-workers-NodeGroup-sample",
"ClusterName": "myCICluster",
"InstanceId": "i-1234567890123456",
"InstanceType": "t3.xlarge",
"Namespace": "amazon-cloudwatch",
"NodeName": "ip-192-0-2-0.us-west-2.compute.internal",
"PodName": "cloudwatch-agent-statsd",
"Service": "cloudwatch-agent-statsd",
"Sources": [
"cadvisor",
"pod",
"calculated"
],
"Timestamp": "1567097399912",
"Type": "Container",
"Version": "0",
"container_cpu_limit": 200,
"container_cpu_request": 200,
"container_cpu_usage_system": 1.87958283771964,
"container_cpu_usage_total": 6.159993652997942,
"container_cpu_usage_user": 1.6707403001952357,
"container_cpu_utilization": 0.15399984132494854,
"container_memory_cache": 8192,
"container_memory_failcnt": 0,
"container_memory_hierarchical_pgfault": 0,
"container_memory_hierarchical_pgmajfault": 0,
"container_memory_limit": 104857600,
"container_memory_mapped_file": 0,
"container_memory_max_usage": 24580096,
"container_memory_pgfault": 0,
"container_memory_pgmajfault": 0,
"container_memory_request": 104857600,
"container_memory_rss": 22736896,
"container_memory_swap": 0,
"container_memory_usage": 24453120,
"container_memory_utilization": 0.10574541028701798,
"container_memory_working_set": 17580032,
"container_status": "Running",
"kubernetes": {
"container_name": "cloudwatch-agent",
"docker": {
"container_id": "8967b6b37da239dfad197c9fdea3e5dfd35a8a759ec86e2e4c3f7b401e232706"
},
"host": "ip-192-168-75-26.us-west-2.compute.internal",
"labels": {
"app": "cloudwatch-agent-statsd",
"pod-template-hash": "df44f855f"
},
"namespace_name": "amazon-cloudwatch",
"pod_id": "2f4ff5ac-c813-11e9-a31d-06e9dde32928",
"pod_name": "cloudwatch-agent-statsd-df44f855f-ts4q2",
"pod_owners": [
{
"owner_kind": "Deployment",
"owner_name": "cloudwatch-agent-statsd"
}
],
"service_name": "cloudwatch-agent-statsd"
},
"number_of_container_restarts": 0
}
```
**Tipo: ContainerFS**
```
{
"AutoScalingGroupName": "eksctl-myCICluster-nodegroup-standard-workers-NodeGroup-1174PV2WHZAYU",
"ClusterName": "myCICluster",
"EBSVolumeId": "aws://us-west-2b/vol-0a53108976d4a2fda",
"InstanceId": "i-1234567890123456",
"InstanceType": "t3.xlarge",
"Namespace": "amazon-cloudwatch",
"NodeName": "ip-192-0-2-0.us-west-2.compute.internal",
"PodName": "cloudwatch-agent-statsd",
"Service": "cloudwatch-agent-statsd",
"Sources": [
"cadvisor",
"calculated"
],
"Timestamp": "1567097399912",
"Type": "ContainerFS",
"Version": "0",
"device": "/dev/nvme0n1p1",
"fstype": "vfs",
"kubernetes": {
"container_name": "cloudwatch-agent",
"docker": {
"container_id": "8967b6b37da239dfad197c9fdea3e5dfd35a8a759ec86e2e4c3f7b401e232706"
},
"host": "ip-192-168-75-26.us-west-2.compute.internal",
"labels": {
"app": "cloudwatch-agent-statsd",
"pod-template-hash": "df44f855f"
},
"namespace_name": "amazon-cloudwatch",
"pod_id": "2f4ff5ac-c813-11e9-a31d-06e9dde32928",
"pod_name": "cloudwatch-agent-statsd-df44f855f-ts4q2",
"pod_owners": [
{
"owner_kind": "Deployment",
"owner_name": "cloudwatch-agent-statsd"
}
],
"service_name": "cloudwatch-agent-statsd"
}
}
```
**Tipo: Cluster**
```
{
"CloudWatchMetrics": [
{
"Metrics": [
{
"Unit": "Count",
"Name": "cluster_node_count"
},
{
"Unit": "Count",
"Name": "cluster_failed_node_count"
}
],
"Dimensions": [
[
"ClusterName"
]
],
"Namespace": "ContainerInsights"
}
],
"ClusterName": "myCICluster",
"Sources": [
"apiserver"
],
"Timestamp": "1567097534160",
"Type": "Cluster",
"Version": "0",
"cluster_failed_node_count": 0,
"cluster_node_count": 3
}
```
**Tipo: ClusterService**
```
{
"CloudWatchMetrics": [
{
"Metrics": [
{
"Unit": "Count",
"Name": "service_number_of_running_pods"
}
],
"Dimensions": [
[
"Service",
"Namespace",
"ClusterName"
],
[
"ClusterName"
]
],
"Namespace": "ContainerInsights"
}
],
"ClusterName": "myCICluster",
"Namespace": "amazon-cloudwatch",
"Service": "cloudwatch-agent-statsd",
"Sources": [
"apiserver"
],
"Timestamp": "1567097534160",
"Type": "ClusterService",
"Version": "0",
"kubernetes": {
"namespace_name": "amazon-cloudwatch",
"service_name": "cloudwatch-agent-statsd"
},
"service_number_of_running_pods": 1
}
```
**Tipo: ClusterNamespace**
```
{
"CloudWatchMetrics": [
{
"Metrics": [
{
"Unit": "Count",
"Name": "namespace_number_of_running_pods"
}
],
"Dimensions": [
[
"Namespace",
"ClusterName"
],
[
"ClusterName"
]
],
"Namespace": "ContainerInsights"
}
],
"ClusterName": "myCICluster",
"Namespace": "amazon-cloudwatch",
"Sources": [
"apiserver"
],
"Timestamp": "1567097594160",
"Type": "ClusterNamespace",
"Version": "0",
"kubernetes": {
"namespace_name": "amazon-cloudwatch"
},
"namespace_number_of_running_pods": 7
}
```
# Campos relevantes nos eventos de log de performance para Amazon EKS e Kubernetes
Para Amazon EKS e Kubernetes, o atendente do CloudWatch armazenado em contêineres emite dados como eventos de log de performance. Isso permite ao CloudWatch ingerir e armazenar dados de alta cardinalidade. O CloudWatch usa os dados nos eventos de log de performance para criar métricas agregadas do CloudWatch no nível do cluster, do nó e do pod, sem a necessidade de perder detalhes refinados.
A tabela a seguir lista os campos nesses eventos de log de performance que são relevantes à coleção de dados de métrica do Container Insights. Você pode usar o CloudWatch Logs Insights para consultar qualquer um desses campos para coletar dados ou investigar problemas. Para obter mais informações, consulte [Analisar dados de log com o CloudWatch Logs Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AnalyzingLogData.html).
| Tipo | Campo de log | Origem | Fórmula ou observações |
| --- | --- | --- | --- |
| Pod | `pod_cpu_utilization` | Calculado | Fórmula: `pod_cpu_usage_total / node_cpu_limit` |
| Pod | `pod_cpu_usage_total` `pod_cpu_usage_total`O é informado em milinúcleos. | cadvisor | |
| Pod | `pod_cpu_limit` | Calculado | Fórmula: `sum(container_cpu_limit)` `sum(container_cpu_limit)` inclui pods já concluídos. Se qualquer contêiner no pod não tiver um limite de CPU definido, esse campo não aparecerá no evento de log. Isso inclui [ contêineres de inicialização](https://kubernetes.io/docs/concepts/workloads/pods/init-containers/#resources). |
| Pod | `pod_cpu_request` | Calculado | Fórmula: `sum(container_cpu_request)` `container_cpu_request`Não é garantido que esteja definido. Somente os que estão definidos são incluídos na soma. |
| Pod | `pod_cpu_utilization_over_pod_limit` | Calculado | Fórmula: `pod_cpu_usage_total / pod_cpu_limit` |
| Pod | `pod_cpu_reserved_capacity` | Calculado | Fórmula: `pod_cpu_request / node_cpu_limit` |
| Pod | `pod_memory_utilization` | Calculado | Fórmula: `pod_memory_working_set / node_memory_limit` É a porcentagem de uso de memória do pod sobre a limitação de memória do nó. |
| Pod | `pod_memory_working_set` | cadvisor | |
| Pod | `pod_memory_limit` | Calculado | Fórmula: `sum(container_memory_limit)` Se qualquer contêiner no pod não tiver um limite de memória definido, esse campo não aparecerá no evento de log. Isso inclui [ contêineres de inicialização](https://kubernetes.io/docs/concepts/workloads/pods/init-containers/#resources). |
| Pod | `pod_memory_request` | Calculado | Fórmula: `sum(container_memory_request)` `container_memory_request`Não é garantido que esteja definido. Somente os que estão definidos são incluídos na soma. |
| Pod | `pod_memory_utilization_over_pod_limit` | Calculado | Fórmula: `pod_memory_working_set / pod_memory_limit` Se qualquer contêiner no pod não tiver um limite de memória definido, esse campo não aparecerá no evento de log. Isso inclui [ contêineres de inicialização](https://kubernetes.io/docs/concepts/workloads/pods/init-containers/#resources). |
| Pod | `pod_memory_reserved_capacity` | Calculado | Fórmula: `pod_memory_request / node_memory_limit` |
| Pod | `pod_network_tx_bytes` | Calculado | Fórmula: `sum(pod_interface_network_tx_bytes)` Esses dados estão disponíveis para todas as interfaces de rede por pod. O atendente do CloudWatch calcula o total e adiciona regras de extração de métrica. |
| Pod | `pod_network_rx_bytes` | Calculado | Fórmula: `sum(pod_interface_network_rx_bytes)` |
| Pod | `pod_network_total_bytes` | Calculado | Fórmula: `pod_network_rx_bytes + pod_network_tx_bytes` |
| PodNet | `pod_interface_network_rx_bytes` | cadvisor | Esses dados são bytes de rx de rede por segundo de uma interface de rede de pod. |
| PodNet | `pod_interface_network_tx_bytes` | cadvisor | Esses dados são bytes de tx de rede por segundo de uma interface de rede de pod. |
| Contêiner | `container_cpu_usage_total` | cadvisor | |
| Contêiner | `container_cpu_limit` | cadvisor | Não há garantia de estar definido. Não é emitido se não está definido. |
| Contêiner | `container_cpu_request` | cadvisor | Não há garantia de estar definido. Não é emitido se não está definido. |
| Contêiner | `container_memory_working_set` | cadvisor | |
| Contêiner | `container_memory_limit` | pod | Não há garantia de estar definido. Não é emitido se não está definido. |
| Contêiner | `container_memory_request` | pod | Não há garantia de estar definido. Não é emitido se não está definido. |
| Nó | `node_cpu_utilization` | Calculado | Fórmula: `node_cpu_usage_total / node_cpu_limit` |
| Nó | `node_cpu_usage_total` | cadvisor | |
| Nó | `node_cpu_limit` | /proc | |
| Nó | `node_cpu_request` | Calculado | Fórmula: `sum(pod_cpu_request)` Para cronjobs, `node_cpu_request` também inclui solicitações de pods concluídos. Isso pode levar a um alto valor para `node_cpu_reserved_capacity`. |
| Nó | `node_cpu_reserved_capacity` | Calculado | Fórmula: `node_cpu_request / node_cpu_limit` |
| Nó | `node_memory_utilization` | Calculado | Fórmula: `node_memory_working_set / node_memory_limit` |
| Nó | `node_memory_working_set` | cadvisor | |
| Nó | `node_memory_limit` | /proc | |
| Nó | `node_memory_request` | Calculado | Fórmula: `sum(pod_memory_request)` |
| Nó | `node_memory_reserved_capacity` | Calculado | Fórmula: `node_memory_request / node_memory_limit` |
| Nó | `node_network_rx_bytes` | Calculado | Fórmula: `sum(node_interface_network_rx_bytes)` |
| Nó | `node_network_tx_bytes` | Calculado | Fórmula: `sum(node_interface_network_tx_bytes)` |
| Nó | `node_network_total_bytes` | Calculado | Fórmula: `node_network_rx_bytes + node_network_tx_bytes` |
| Nó | `node_number_of_running_pods` | Lista de pods | |
| Nó | `node_number_of_running_containers` | Lista de pods | |
| NodeNet | `node_interface_network_rx_bytes` | cadvisor | Esses dados são bytes de tx de rede por segundo de uma interface de rede do nó de processamento. |
| NodeNet | `node_interface_network_tx_bytes` | cadvisor | Esses dados são bytes de tx de rede por segundo de uma interface de rede do nó de processamento. |
| NodeFS | `node_filesystem_capacity` | cadvisor | |
| NodeFS | `node_filesystem_usage` | cadvisor | |
| NodeFS | `node_filesystem_utilization` | Calculado | Fórmula: `node_filesystem_usage / node_filesystem_capacity` Esses dados estão disponíveis por nome do dispositivo. |
| Cluster | `cluster_failed_node_count` | Servidor da API | |
| Cluster | `cluster_node_count` | Servidor da API | |
| Serviço | `service_number_of_running_pods` | Servidor da API | |
| `Namespace` | `namespace_number_of_running_pods` | Servidor da API | |
## Exemplos de cálculo de métricas
Esta seção inclui exemplos que mostram como alguns dos valores na tabela anterior são calculados.
Suponha que você tenha um cluster no estado a seguir.
```
Node1
node_cpu_limit = 4
node_cpu_usage_total = 3
Pod1
pod_cpu_usage_total = 2
Container1
container_cpu_limit = 1
container_cpu_request = 1
container_cpu_usage_total = 0.8
Container2
container_cpu_limit = null
container_cpu_request = null
container_cpu_usage_total = 1.2
Pod2
pod_cpu_usage_total = 0.4
Container3
container_cpu_limit = 1
container_cpu_request = 0.5
container_cpu_usage_total = 0.4
Node2
node_cpu_limit = 8
node_cpu_usage_total = 1.5
Pod3
pod_cpu_usage_total = 1
Container4
container_cpu_limit = 2
container_cpu_request = 2
container_cpu_usage_total = 1
```
A tabela a seguir mostra como as métricas de CPU do pod são calculadas usando esses dados.
| Métrica | Fórmula | Pod1 | Pod2 | Pod3 |
| --- | --- | --- | --- | --- |
| `pod_cpu_utilization` | `pod_cpu_usage_total / node_cpu_limit` | 2/4 = 50% | 0,4/4 = 10% | 1/8 = 12,5% |
| `pod_cpu_utilization_over_pod_limit` | `pod_cpu_usage_total / sum(container_cpu_limit)` | N/D, pois o limite de CPU para `Container2` não está definido | 0,4/1 = 40% | 1/2 = 50% |
| `pod_cpu_reserved_capacity` | `sum(container_cpu_request) / node_cpu_limit` | (1 \$1 0)/4 = 25% | 0,5/4 = 12,5% | 2/8 = 25% |
A tabela a seguir mostra como as métricas de CPU do nó são calculadas usando esses dados.
| Métrica | Fórmula | Node1 | Node2 |
| --- | --- | --- | --- |
| `node_cpu_utilization` | `node_cpu_usage_total / node_cpu_limit` | 3/4 = 75% | 1,5/8 = 18,75% |
| `node_cpu_reserved_capacity` | `sum(pod_cpu_request) / node_cpu_limit` | 1,5/4 = 37,5% | 2/8 = 25% |
# Monitoramento de métricas do Container Insights Prometheus
O monitoramento do CloudWatch Container Insights para Prometheus automatiza a detecção de métricas do Prometheus de sistemas e workloads em contêineres. O Prometheus é um toolkit de código aberto para alertas e monitoramento de sistemas. Para obter mais informações, consulte [What is Prometheus?](https://prometheus.io/docs/introduction/overview/) na documentação do Prometheus.
A detecção de métricas do Prometheus é compatível com clusters do [Amazon Elastic Container Service](https://aws.amazon.com/ecs/), [Amazon Elastic Kubernetes Service](https://aws.amazon.com/eks/) e [Kubernetes](https://aws.amazon.com/kubernetes/) em execução em instâncias do Amazon EC2. São coletados os tipos de métrica contador, medidor e resumo do Prometheus.
Para clusters do Amazon ECS e do Amazon EKS, há suporte para os tipos de inicialização do EC2 e do Fargate. O Container Insights coleta automaticamente métricas de várias workloads, e é possível configurá-lo de modo a coletar métricas de qualquer workload.
Você pode adotar o Prometheus como um método de código aberto e padrão aberto para ingerir métricas personalizadas no CloudWatch. O atendente do CloudWatch com suporte ao Prometheus detecta e coleta métricas do Prometheus para monitorar, solucionar problemas e criar alarmes sobre a degradação na performance e falhas das aplicações mais rapidamente. Isso também reduz o número de ferramentas de monitoramento necessárias para melhorar a observabilidade.
O suporte do Container Insights Prometheus envolve o pagamento de métricas e logs conforme o uso, incluindo coleta, armazenamento e análise. Para obter mais informações, consulte [Preços do Amazon CloudWatch](https://aws.amazon.com/cloudwatch/pricing/).
**Painéis pré-criados para algumas workloads**
A solução Container Insights Prometheus contém painéis pré-criados para as workloads bastante utilizadas listadas nesta seção. Para obter exemplos de configurações dessas workloads, consulte [(Opcional) Configurar amostra de workloads do Amazon ECS em contêineres para teste de métrica do Prometheus](ContainerInsights-Prometheus-Sample-Workloads-ECS.md)e [(Opcional) Configurar workloads de exemplo do Amazon EKS em contêineres para teste de métrica do Prometheus](ContainerInsights-Prometheus-Sample-Workloads.md).
Também é possível configurar o Container Insights para coletar métricas do Prometheus de outros serviços e aplicações em contêineres, editando o arquivo de configuração do atendente.
Workloads com painéis pré-criados para clusters do Amazon EKS e do Kubernetes em execução em instâncias do Amazon EC2:
+ AWS App Mesh
+ NGINX
+ Memcached
+ Java/JMX
+ HAProxy
Workloads com painéis pré-criados para clusters do Amazon ECS:
+ AWS App Mesh
+ Java/JMX
+ NGINX
+ NGINX Plus
# Instalar e configurar a coleta de métricas do Prometheus em cluster do Amazon ECS
Para coletar métricas do Prometheus de clusters do Amazon ECS, é possível usar o atendente do CloudWatch como coletor ou usar o coletor do AWS Distro for OpenTelemetry. Para obter informações sobre como usar o coletor do AWS Distro for OpenTelemetry, consulte [https://aws-otel.github.io/docs/getting-started/container-insights/ecs-prometheus](https://aws-otel.github.io/docs/getting-started/container-insights/ecs-prometheus).
As seções a seguir explicam como usar o atendente do CloudWatch como coletor para recuperar métricas do Prometheus. Você instala o atendente do CloudWatch com o monitoramento Prometheus em clusters que executam o Amazon ECS e, opcionalmente, pode configurar o atendente para extrair outros destinos. Estas seções também fornecem tutoriais opcionais para configurar workloads de amostra para usar testes com monitoramento Prometheus.
O Container Insights no Amazon ECS oferece suporte às seguintes combinações de tipo de inicialização e modo de rede para métricas do Prometheus:
| Tipo de inicialização do Amazon ECS | Modos de rede compatíveis |
| --- | --- |
| EC2 (Linux) | bridge, host e awsvpc |
| Fargate | awsvpc |
**Requisitos para grupo de segurança de VPC**
As regras de entrada dos grupos de segurança para as workloads do Prometheus devem abrir as portas do Prometheus para o atendente do CloudWatch para extrair as métricas Prometheus pelo IP privado.
As regras de saída do grupo de segurança do atendente do CloudWatch devem permitir que o atendente do CloudWatch se conecte à porta das workloads do Prometheus por IP privado.
**Topics**
+ [Instalar o atendente do CloudWatch com a coleção de métricas do Prometheus em clusters do Amazon ECS](ContainerInsights-Prometheus-install-ECS.md)
+ [Extrair outras fontes do Prometheus e importar essas métricas](ContainerInsights-Prometheus-Setup-configure-ECS.md)
+ [(Opcional) Configurar amostra de workloads do Amazon ECS em contêineres para teste de métrica do Prometheus](ContainerInsights-Prometheus-Sample-Workloads-ECS.md)
# Instalar o atendente do CloudWatch com a coleção de métricas do Prometheus em clusters do Amazon ECS
Esta seção explica como configurar o atendente do CloudWatch com monitoramento do Prometheus em um cluster que está executando o Amazon ECS. Depois que você fizer isso, o atendente automaticamente extrairá e importará métricas para as seguintes workloads em execução nesse cluster.
+ AWS App Mesh
+ Java/JMX
Também é possível configurar o atendente para extrair e importar métricas de outras workloads e origens do Prometheus.
## Configurar funções do IAM
Você precisa de duas funções do IAM para a definição de tarefa do atendente do CloudWatch. Se você especificar **CreateIAMRoles=True** na pilha CloudFormation para que o Container Insights crie essas funções para você, as funções serão criadas com as permissões corretas. Caso queira criá-las ou usar funções existentes, as funções e permissões a seguir são necessárias.
+ **Função de tarefa do ECS do atendente do CloudWatch**: o contêiner do atendente do CloudWatch usa essa função. Ela deve incluir a política **CloudWatchAgentServerPolicy** e uma política gerenciada pelo cliente que contenha as seguintes permissões somente para leitura:
+ `ec2:DescribeInstances`
+ `ecs:ListTasks`
+ `ecs:ListServices`
+ `ecs:DescribeContainerInstances`
+ `ecs:DescribeServices`
+ `ecs:DescribeTasks`
+ `ecs:DescribeTaskDefinition`
+ **Função de execução de tarefa do ECS do atendente do CloudWatch**: essa é a função necessária para o Amazon ECS iniciar e executar os contêineres. Verifique se sua função de execução de tarefa tem as políticas **AmazonSSMReadOnlyAccess**, **AmazonECSTaskExecutionRolePolicy** e **CloudWatchAgentServerPolicy** anexadas. Se precisar armazenar dados mais sigilosos para uso do Amazon ECS, consulte [Especificar dados sigilosos](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/specifying-sensitive-data.html).
## Instale o atendente do CloudWatch com o monitoramento do Prometheus usando CloudFormation
Você pode usar AWS CloudFormation para instalar o atendente do CloudWatch com o monitoramento do Prometheus para clusters do Amazon ECS. A lista a seguir exibe os parâmetros que você usará no modelo CloudFormation.
+ **ECSClusterName**: especifica o cluster do Amazon ECS de destino.
+ **CreateIAMRoles**: especifique **True** para criar novas funções para a função de tarefa do Amazon ECS e para a função de execução de tarefas do Amazon ECS. Especifique **False** para reutilizar funções existentes.
+ **TaskRoleName**: se você especificou **True** em **CreateIAMRoles**, isso especifica o nome a ser usado para a função de tarefa do Amazon ECS. Se você especificou **False** em **CreateIAMRoles**, isso especifica a função existente a ser usada para a função de tarefa do Amazon ECS.
+ **ExecutionRoleName**: se você especificou **True** em **CreateIAMRoles**, isso especifica o nome a ser usado para a função de execução de tarefa do Amazon ECS. Se você especificou **False** em **CreateIAMRoles**, isso especifica a função existente a ser usada para a função de execução de tarefa do Amazon ECS.
+ **ECSNetworkMode**: se estiver usando o tipo de inicialização do EC2, especifique o modo de rede aqui. Deve ser **bridge** ou **host**.
+ **ECSLaunchType**: especifique **fargate** ou **EC2**.
+ **SecurityGroupID**: se o **ECSNetworkMode** for **awsvpc**, especifique o ID do grupo de segurança aqui.
+ **SubnetID**: se o **ECSNetworkMode** for **awsvpc**, especifique o ID da sub-rede aqui.
### Exemplos de comando
Esta seção contém exemplos de comando do CloudFormation para instalar o Container Insights com o monitoramento do Prometheus em vários cenários.
**Criar uma pilha do CloudFormation para um cluster do Amazon ECS no modo de rede de ponte**
```
export AWS_PROFILE=your_aws_config_profile_eg_default
export AWS_DEFAULT_REGION=your_aws_region_eg_ap-southeast-1
export ECS_CLUSTER_NAME=your_ec2_ecs_cluster_name
export ECS_NETWORK_MODE=bridge
export CREATE_IAM_ROLES=True
export ECS_TASK_ROLE_NAME=your_selected_ecs_task_role_name
export ECS_EXECUTION_ROLE_NAME=your_selected_ecs_execution_role_name
curl -O https://raw.githubusercontent.com/aws-samples/amazon-cloudwatch-container-insights/latest/ecs-task-definition-templates/deployment-mode/replica-service/cwagent-prometheus/cloudformation-quickstart/cwagent-ecs-prometheus-metric-for-bridge-host.yaml
aws cloudformation create-stack --stack-name CWAgent-Prometheus-ECS-${ECS_CLUSTER_NAME}-EC2-${ECS_NETWORK_MODE} \
--template-body file://cwagent-ecs-prometheus-metric-for-bridge-host.yaml \
--parameters ParameterKey=ECSClusterName,ParameterValue=${ECS_CLUSTER_NAME} \
ParameterKey=CreateIAMRoles,ParameterValue=${CREATE_IAM_ROLES} \
ParameterKey=ECSNetworkMode,ParameterValue=${ECS_NETWORK_MODE} \
ParameterKey=TaskRoleName,ParameterValue=${ECS_TASK_ROLE_NAME} \
ParameterKey=ExecutionRoleName,ParameterValue=${ECS_EXECUTION_ROLE_NAME} \
--capabilities CAPABILITY_NAMED_IAM \
--region ${AWS_DEFAULT_REGION} \
--profile ${AWS_PROFILE}
```
**Criar uma pilha do CloudFormation para um cluster do Amazon ECS no modo de rede de host**
```
export AWS_PROFILE=your_aws_config_profile_eg_default
export AWS_DEFAULT_REGION=your_aws_region_eg_ap-southeast-1
export ECS_CLUSTER_NAME=your_ec2_ecs_cluster_name
export ECS_NETWORK_MODE=host
export CREATE_IAM_ROLES=True
export ECS_TASK_ROLE_NAME=your_selected_ecs_task_role_name
export ECS_EXECUTION_ROLE_NAME=your_selected_ecs_execution_role_name
curl -O https://raw.githubusercontent.com/aws-samples/amazon-cloudwatch-container-insights/latest/ecs-task-definition-templates/deployment-mode/replica-service/cwagent-prometheus/cloudformation-quickstart/cwagent-ecs-prometheus-metric-for-bridge-host.yaml
aws cloudformation create-stack --stack-name CWAgent-Prometheus-ECS-${ECS_CLUSTER_NAME}-EC2-${ECS_NETWORK_MODE} \
--template-body file://cwagent-ecs-prometheus-metric-for-bridge-host.yaml \
--parameters ParameterKey=ECSClusterName,ParameterValue=${ECS_CLUSTER_NAME} \
ParameterKey=CreateIAMRoles,ParameterValue=${CREATE_IAM_ROLES} \
ParameterKey=ECSNetworkMode,ParameterValue=${ECS_NETWORK_MODE} \
ParameterKey=TaskRoleName,ParameterValue=${ECS_TASK_ROLE_NAME} \
ParameterKey=ExecutionRoleName,ParameterValue=${ECS_EXECUTION_ROLE_NAME} \
--capabilities CAPABILITY_NAMED_IAM \
--region ${AWS_DEFAULT_REGION} \
--profile ${AWS_PROFILE}
```
**Criar uma pilha do CloudFormation para um cluster do Amazon ECS no modo de rede awsvpc**
```
export AWS_PROFILE=your_aws_config_profile_eg_default
export AWS_DEFAULT_REGION=your_aws_region_eg_ap-southeast-1
export ECS_CLUSTER_NAME=your_ec2_ecs_cluster_name
export ECS_LAUNCH_TYPE=EC2
export CREATE_IAM_ROLES=True
export ECS_CLUSTER_SECURITY_GROUP=your_security_group_eg_sg-xxxxxxxxxx
export ECS_CLUSTER_SUBNET=your_subnet_eg_subnet-xxxxxxxxxx
export ECS_TASK_ROLE_NAME=your_selected_ecs_task_role_name
export ECS_EXECUTION_ROLE_NAME=your_selected_ecs_execution_role_name
curl -O https://raw.githubusercontent.com/aws-samples/amazon-cloudwatch-container-insights/latest/ecs-task-definition-templates/deployment-mode/replica-service/cwagent-prometheus/cloudformation-quickstart/cwagent-ecs-prometheus-metric-for-awsvpc.yaml
aws cloudformation create-stack --stack-name CWAgent-Prometheus-ECS-${ECS_CLUSTER_NAME}-${ECS_LAUNCH_TYPE}-awsvpc \
--template-body file://cwagent-ecs-prometheus-metric-for-awsvpc.yaml \
--parameters ParameterKey=ECSClusterName,ParameterValue=${ECS_CLUSTER_NAME} \
ParameterKey=CreateIAMRoles,ParameterValue=${CREATE_IAM_ROLES} \
ParameterKey=ECSLaunchType,ParameterValue=${ECS_LAUNCH_TYPE} \
ParameterKey=SecurityGroupID,ParameterValue=${ECS_CLUSTER_SECURITY_GROUP} \
ParameterKey=SubnetID,ParameterValue=${ECS_CLUSTER_SUBNET} \
ParameterKey=TaskRoleName,ParameterValue=${ECS_TASK_ROLE_NAME} \
ParameterKey=ExecutionRoleName,ParameterValue=${ECS_EXECUTION_ROLE_NAME} \
--capabilities CAPABILITY_NAMED_IAM \
--region ${AWS_DEFAULT_REGION} \
--profile ${AWS_PROFILE}
```
**Criar uma pilha do CloudFormation para um cluster do Fargate no modo de rede awsvpc**
```
export AWS_PROFILE=your_aws_config_profile_eg_default
export AWS_DEFAULT_REGION=your_aws_region_eg_ap-southeast-1
export ECS_CLUSTER_NAME=your_ec2_ecs_cluster_name
export ECS_LAUNCH_TYPE=FARGATE
export CREATE_IAM_ROLES=True
export ECS_CLUSTER_SECURITY_GROUP=your_security_group_eg_sg-xxxxxxxxxx
export ECS_CLUSTER_SUBNET=your_subnet_eg_subnet-xxxxxxxxxx
export ECS_TASK_ROLE_NAME=your_selected_ecs_task_role_name
export ECS_EXECUTION_ROLE_NAME=your_selected_ecs_execution_role_name
curl -O https://raw.githubusercontent.com/aws-samples/amazon-cloudwatch-container-insights/latest/ecs-task-definition-templates/deployment-mode/replica-service/cwagent-prometheus/cloudformation-quickstart/cwagent-ecs-prometheus-metric-for-awsvpc.yaml
aws cloudformation create-stack --stack-name CWAgent-Prometheus-ECS-${ECS_CLUSTER_NAME}-${ECS_LAUNCH_TYPE}-awsvpc \
--template-body file://cwagent-ecs-prometheus-metric-for-awsvpc.yaml \
--parameters ParameterKey=ECSClusterName,ParameterValue=${ECS_CLUSTER_NAME} \
ParameterKey=CreateIAMRoles,ParameterValue=${CREATE_IAM_ROLES} \
ParameterKey=ECSLaunchType,ParameterValue=${ECS_LAUNCH_TYPE} \
ParameterKey=SecurityGroupID,ParameterValue=${ECS_CLUSTER_SECURITY_GROUP} \
ParameterKey=SubnetID,ParameterValue=${ECS_CLUSTER_SUBNET} \
ParameterKey=TaskRoleName,ParameterValue=${ECS_TASK_ROLE_NAME} \
ParameterKey=ExecutionRoleName,ParameterValue=${ECS_EXECUTION_ROLE_NAME} \
--capabilities CAPABILITY_NAMED_IAM \
--region ${AWS_DEFAULT_REGION} \
--profile ${AWS_PROFILE}
```
### Recursos da AWS criados pela pilha do CloudFormation
A tabela a seguir lista os recursos da AWS que são criados quando você usa o CloudFormation para configurar o Container Insights com o monitoramentodo Prometheus em um cluster do Amazon ECS.
| Tipo de recurso | Nome do recurso | Comentários |
| --- | --- | --- |
| AWS::SSM::Parameter | AmazonCloudWatch-CWAgentConfig-\$1*ECS\$1CLUSTER\$1NAME*-\$1*ECS\$1LAUNCH\$1TYPE*-\$1*ECS\$1NETWORK\$1MODE* | Este é o atendente do CloudWatch com a definição padrão do formato de métrica incorporado de App Mesh e Java/JMX. |
| AWS::SSM::Parameter | AmazonCloudWatch-PrometheusConfigName-\$1*ECS\$1CLUSTER\$1NAME*-\$1*ECS\$1LAUNCH\$1TYPE*-\$1*ECS\$1NETWORK\$1MODE* | Esta é a configuração de extração do Prometheus. |
| AWS::IAM::Role | **\$1ECS\$1TASK\$1ROLE\$1NAME**. | A função de tarefa do Amazon ECS. Isso somente é criado se você especificou **True** em `CREATE_IAM_ROLES`. |
| AWS::IAM::Role | **\$1\$1ECS\$1EXECUTION\$1ROLE\$1NAME\$1** | A função de execução de tarefa do Amazon ECS. Isso somente é criado se você especificou **True** em `CREATE_IAM_ROLES`. |
| AWS::ECS::TaskDefinition | cwagent-prometheus-\$1*ECS\$1CLUSTER\$1NAME*-\$1*ECS\$1LAUNCH\$1TYPE*-\$1*ECS\$1NETWORK\$1MODE* | |
| AWS::ECS::Service | cwagent-prometheus-replica-service-\$1*ECS\$1LAUNCH\$1TYPE*-\$1*ECS\$1NETWORK\$1MODE* | |
### Excluir a pilha do CloudFormation para o atendente do CloudWatch com monitoramento do Prometheus
Para excluir o atendente do CloudWatch de um cluster do Amazon ECS, insira estes comandos.
```
export AWS_PROFILE=your_aws_config_profile_eg_default
export AWS_DEFAULT_REGION=your_aws_region_eg_ap-southeast-1
export CLOUDFORMATION_STACK_NAME=your_cloudformation_stack_name
aws cloudformation delete-stack \
--stack-name ${CLOUDFORMATION_STACK_NAME} \
--region ${AWS_DEFAULT_REGION} \
--profile ${AWS_PROFILE}
```
# Extrair outras fontes do Prometheus e importar essas métricas
O atendente do CloudWatch com monitoramento Prometheus precisa de duas configurações para extrair as métricas do Prometheus. Uma serve para as configurações padrão do Prometheus, conforme documentado em [](https://prometheus.io/docs/prometheus/latest/configuration/configuration/#scrape_config) na documentação do Prometheus. A outra é para a configuração do atendente do CloudWatch.
Para clusters do Amazon ECS, as configurações são integradas ao Parameter Store do AWS Systems Manager pelos segredos na definição da tarefa do Amazon ECS:
+ O segredo `PROMETHEUS_CONFIG_CONTENT` é para a configuração de extração do Prometheus.
+ O segredo `CW_CONFIG_CONTENT` é para a configuração do atendente do CloudWatch.
Para extrair outras origens de métricas do Prometheus e importar essas métricas para o CloudWatch, modifique a configuração de extração do Prometheus e a configuração do atendente do CloudWatch e implante novamente o atendente com a configuração atualizada.
**Requisitos para grupo de segurança de VPC**
As regras de entrada dos grupos de segurança para as workloads do Prometheus devem abrir as portas do Prometheus para o atendente do CloudWatch para extrair as métricas Prometheus pelo IP privado.
As regras de saída do grupo de segurança do atendente do CloudWatch devem permitir que o atendente do CloudWatch se conecte à porta das workloads do Prometheus por IP privado.
## Configuração de extração do Prometheus
O atendente do CloudWatch oferece suporte às configurações de extração padrão do Prometheus, conforme documentado em [ ](https://prometheus.io/docs/prometheus/latest/configuration/configuration/#scrape_config) na documentação do Prometheus. É possível editar essa seção para atualizar as configurações que já estão nesse arquivo e adicionar outros destinos de extração do Prometheus. Por padrão, um exemplo de arquivo de configuração contém as seguintes linhas de configuração global:
```
global:
scrape_interval: 1m
scrape_timeout: 10s
```
+ **scrape\$1interval**: define a frequência da adição de destinos de extração de conteúdo.
+ **scrape\$1timeout**: define quanto tempo aguardar até a expiração de uma solicitação de extração de conteúdo.
Também é possível definir valores diferentes para essas configurações no nível do trabalho, a fim de substituir as configurações globais.
### Trabalhos de extração do Prometheus
Os arquivos YAML do atendente do CloudWatch já têm alguns trabalhos padrão de extração configurados. Por exemplo, nos arquivos YAML para o Amazon ECS, como `cwagent-ecs-prometheus-metric-for-bridge-host.yaml`, os trabalhos de extração padrão são configurados na seção `ecs_service_discovery`.
```
"ecs_service_discovery": {
"sd_frequency": "1m",
"sd_result_file": "/tmp/cwagent_ecs_auto_sd.yaml",
"docker_label": {
},
"task_definition_list": [
{
"sd_job_name": "ecs-appmesh-colors",
"sd_metrics_ports": "9901",
"sd_task_definition_arn_pattern": ".*:task-definition\/.*-ColorTeller-(white):[0-9]+",
"sd_metrics_path": "/stats/prometheus"
},
{
"sd_job_name": "ecs-appmesh-gateway",
"sd_metrics_ports": "9901",
"sd_task_definition_arn_pattern": ".*:task-definition/.*-ColorGateway:[0-9]+",
"sd_metrics_path": "/stats/prometheus"
}
]
}
```
Cada um desses destinos padrão é extraído e as métricas são enviadas ao CloudWatch em eventos de log usando o formato de métricas incorporado. Para obter mais informações, consulte [Incorporação de métricas em logs](CloudWatch_Embedded_Metric_Format.md).
Os eventos de log dos clusters do Amazon ECS são armazenados no grupo de logs **/aws/ecs/containerinsights/*cluster\$1name*/prometheus**.
Cada trabalho de extração está contido em um fluxo de logs diferente nesse grupo de logs.
Para adicionar um novo destino de extração, adicione uma nova entrada à seção `task_definition_list` na seção `ecs_service_discovery` do arquivo YAML e reinicie o atendente. Para obter um exemplo desse processo, consulte [Tutorial para adicionar um novo destino de extração do Prometheus: métricas do servidor de API do Prometheus](ContainerInsights-Prometheus-Setup-configure.md#ContainerInsights-Prometheus-Setup-new-exporters).
## Configuração do atendente do CloudWatch para o Prometheus
O arquivo de configuração do atendente do CloudWatch tem uma seção `prometheus` na seção `metrics_collected` para a configuração de extração do Prometheus. Contém as seguintes opções de configuração:
+ **cluster\$1name**: especifica o nome do cluster a ser adicionado como um rótulo no evento de log. Esse campo é opcional. Se você omitir, o atendente poderá detectar o nome do cluster do Amazon ECS.
+ **log\$1group\$1name**: especifica o nome do grupo de log para as métricas do Prometheus extraídas. Esse campo é opcional. Se você omitir, o CloudWatch usará **/aws/ecs/containerinsights/*cluster\$1name*/prometheus** para logs de clusters do Amazon ECS.
+ **prometheus\$1config\$1path**: especifica o caminho do arquivo de configuração de extração do Prometheus. Se o valor desse campo começar com `env:`, o conteúdo do arquivo de configuração de extração do Prometheus será recuperado da variável de ambiente do contêiner. Não altere esse campo.
+ **ecs\$1service\$1discovery**: é a seção para especificar as configurações das funções de detecção automática de destino do Amazon ECS Prometheus. Dois modos são compatíveis para detectar os destinos do Prometheus: detecção baseada no rótulo do docker do contêiner ou detecção baseada na expressão regular do ARN da definição de tarefa do Amazon ECS. Você pode usar os dois modos junto, e o atendente do CloudWatch eliminará a duplicação dos destinos detectados com base em: *\$1private\$1ip\$1:\$1port\$1/\$1metrics\$1path\$1*.
A seção `ecs_service_discovery` pode conter os seguintes campos:
+ `sd_frequency` é a frequência para detectar os exportadores Prometheus. Especifique um número e um sufixo de unidade. Por exemplo, `1m` uma vez por minuto ou `30s` uma vez a cada 30 segundos. Os sufixos de unidade válidos são: `ns`, `us`, `ms`, `s`, `m` e `h`.
Esse campo é opcional. O padrão é 60 segundos (1 minuto).
+ `sd_target_cluster` é o nome do cluster do Amazon ECS de destino para detecção automática. Esse campo é opcional. O padrão é o nome do cluster do Amazon ECS em que o atendente do CloudWatch está instalado.
+ `sd_cluster_region` é a região do cluster do Amazon ECS de destino. Esse campo é opcional. O padrão é a região do cluster do Amazon ECS em que o atendente do CloudWatch está instalado.
+ `sd_result_file` é o caminho do arquivo YAML para os resultados de destino do Prometheus. A configuração de extração do Prometheus referenciará esse arquivo.
+ `docker_label` é uma seção opcional que você pode usar para especificar a configuração para detecção de serviço baseada em rótulos do docker. Se você omitir essa seção, a detecção baseada em rótulos do docker não será usada. A seção pode conter os seguintes campos:
+ `sd_port_label` é o nome do rótulo do docker do contêiner que especifica a porta do contêiner para métricas do Prometheus. O valor padrão é `ECS_PROMETHEUS_EXPORTER_PORT`. Se o contêiner não tiver esse rótulo do docker, o atendente do CloudWatch o ignorará.
+ `sd_metrics_path_label` é o nome do rótulo do docker do contêiner que especifica o caminho das métricas do Prometheus. O valor padrão é `ECS_PROMETHEUS_METRICS_PATH`. Se o contêiner não tiver esse rótulo do docker, o agente assumirá o caminho padrão `/metrics`.
+ `sd_job_name_label` é o nome do rótulo do docker do contêiner que especifica o nome do trabalho de extração do Prometheus. O valor padrão é `job`. Se o contêiner não tiver esse rótulo do docker, o atendente do CloudWatch usará o nome do trabalho na configuração de extração do Prometheus.
+ `task_definition_list` é uma seção opcional que você pode usar para especificar a configuração para detectção de serviço baseada em definição de tarefa. Se você omitir essa seção, a detecção baseada em definição de tarefa não será usada. A seção pode conter os seguintes campos:
+ `sd_task_definition_arn_pattern` é o padrão a ser usado para especificar as definições de tarefa do Amazon ECS a serem detectadas. Essa é uma expressão regular.
+ `sd_metrics_ports` lista a containerPort para as métricas do Prometheus. Separe as containerPorts com ponto e vírgula.
+ `sd_container_name_pattern` especifica os nomes de contêiner de tarefas do Amazon ECS. Essa é uma expressão regular.
+ `sd_metrics_path` especifica o caminho da métrica do Prometheus. Se você omitir isso, o atendente assumirá o caminho padrão `/metrics`
+ `sd_job_name` especifica o nome do trabalho de extração do Prometheus. Se você omitir esse campo, o atendente do CloudWatch usará o nome do trabalho na configuração de extração do Prometheus.
+ `service_name_list_for_tasks` é uma seção opcional que você pode usar para especificar a configuração para detecção de serviço baseada em definição de tarefa. Ao omitir esta seção, a detecção baseada em nome de serviço não será utilizada. A seção pode conter os seguintes campos:
+ `sd_service_name_pattern` é o padrão a ser usado para especificar o serviço do Amazon ECS em que as tarefas serão detectadas. Essa é uma expressão regular.
+ `sd_metrics_ports` lista a `containerPort` para as métricas do Prometheus. Separar múltiplas `containerPorts` com ponto e vírgula.
+ `sd_container_name_pattern` especifica os nomes de contêiner de tarefas do Amazon ECS. Essa é uma expressão regular.
+ `sd_metrics_path` especifica o caminho das métricas do Prometheus. Se você omitir isso, o atendente entenderá que o caminho padrão é `/metrics`.
+ `sd_job_name` especifica o nome do trabalho de extração do Prometheus. Se você omitir esse campo, o atendente do CloudWatch usará o nome do trabalho na configuração de extração do Prometheus.
+ **metric\$1declaration**: são seções que especificam a matriz de logs com formato de métrica incorporado a ser gerada. Há seções `metric_declaration` para cada destino do Prometheus do qual o atendente do CloudWatch importa por padrão. Essas seções incluem os seguintes campos:
+ `label_matcher` é uma expressão regular que confere o valor dos rótulos listados em `source_labels`. As métricas correspondentes são disponibilizadas para inclusão no formato de métrica incorporado enviado ao CloudWatch.
Se você tiver vários rótulos especificados em `source_labels`, recomendamos não utilizar os caracteres `^` ou `$` na expressão regular para `label_matcher`.
+ `source_labels` especifica o valor dos rótulos verificados pela linha `label_matcher`.
+ `label_separator` especifica o separador a ser usado na linha ` label_matcher` se vários `source_labels` forem especificados. O padrão é `;`. É possível ver esse padrão usado na linha `label_matcher` no exemplo a seguir.
+ `metric_selectors` é uma expressão regular que especifica as métricas a serem coletadas e enviadas ao CloudWatch.
+ `dimensions` é a lista de rótulos a serem usados como dimensões do CloudWatch para cada métrica selecionada.
Veja o exemplo de `metric_declaration` a seguir.
```
"metric_declaration": [
{
"source_labels":[ "Service", "Namespace"],
"label_matcher":"(.*node-exporter.*|.*kube-dns.*);kube-system$",
"dimensions":[
["Service", "Namespace"]
],
"metric_selectors":[
"^coredns_dns_request_type_count_total$"
]
}
]
```
Esse exemplo configura uma seção de formato de métrica incorporada a ser enviada como um evento de log se as seguintes condições forem atendidas:
+ O valor de `Service` contém `node-exporter` ou `kube-dns`.
+ O valor de `Namespace` é `kube-system`.
+ A métrica do Prometheus `coredns_dns_request_type_count_total` contém rótulos `Service` e `Namespace`.
O evento de log enviado inclui a seguinte seção destacada:
```
{
"CloudWatchMetrics":[
{
"Metrics":[
{
"Name":"coredns_dns_request_type_count_total"
}
],
"Dimensions":[
[
"Namespace",
"Service"
]
],
"Namespace":"ContainerInsights/Prometheus"
}
],
"Namespace":"kube-system",
"Service":"kube-dns",
"coredns_dns_request_type_count_total":2562,
"eks_amazonaws_com_component":"kube-dns",
"instance":"192.168.61.254:9153",
"job":"kubernetes-service-endpoints",
...
}
```
# Guia detalhado para detecção automática em clusters do Amazon ECS
O Prometheus fornece dezenas de mecanismos dinâmicos de detecção de serviços, conforme descrito em [](https://prometheus.io/docs/prometheus/latest/configuration/configuration/#scrape_config). Porém, não há detecção de serviço integrada para o Amazon ECS. O atendente do CloudWatch adiciona esse mecanismo.
Quando a detecção de serviço do Amazon ECS Prometheus é habilitada, o atendente do CloudWatch faz periodicamente as seguintes chamadas de API aos frontends do Amazon ECS e do Amazon EC2 para recuperar os metadados das tarefas do ECS em execução no cluster do ECS de destino.
```
EC2:DescribeInstances
ECS:ListTasks
ECS:ListServices
ECS:DescribeContainerInstances
ECS:DescribeServices
ECS:DescribeTasks
ECS:DescribeTaskDefinition
```
Os metadados são usados pelo atendente do CloudWatch para verificar os destinos do Prometheus dentro do cluster do ECS. O atendente do CloudWatch é compatível com três modos de detecção de serviço:
+ Detecção de serviço baseada em rótulos do docker
+ Detecção de serviço baseado em expressão regular do ARN da definição de tarefa do ECS
+ Detecção de serviço baseada em expressão regular do nome do serviço do ECS
Todos os modos podem ser usados conjuntamente. O atendente do CloudWatch elimina a duplicação dos destinos detectados com base em: `{private_ip}:{port}/{metrics_path}`.
Todos os destinos detectados são gravados em um arquivo de resultado especificado pela confiiguração `sd_result_file` dentro do contêiner do atendente do CloudWatch. Veja a seguir um exemplo de arquivo de resultado:
```
- targets:
- 10.6.1.95:32785
labels:
__metrics_path__: /metrics
ECS_PROMETHEUS_EXPORTER_PORT: "9406"
ECS_PROMETHEUS_JOB_NAME: demo-jar-ec2-bridge-dynamic
ECS_PROMETHEUS_METRICS_PATH: /metrics
InstanceType: t3.medium
LaunchType: EC2
SubnetId: subnet-123456789012
TaskDefinitionFamily: demo-jar-ec2-bridge-dynamic-port
TaskGroup: family:demo-jar-ec2-bridge-dynamic-port
TaskRevision: "7"
VpcId: vpc-01234567890
container_name: demo-jar-ec2-bridge-dynamic-port
job: demo-jar-ec2-bridge-dynamic
- targets:
- 10.6.3.193:9404
labels:
__metrics_path__: /metrics
ECS_PROMETHEUS_EXPORTER_PORT_SUBSET_B: "9404"
ECS_PROMETHEUS_JOB_NAME: demo-tomcat-ec2-bridge-mapped-port
ECS_PROMETHEUS_METRICS_PATH: /metrics
InstanceType: t3.medium
LaunchType: EC2
SubnetId: subnet-123456789012
TaskDefinitionFamily: demo-tomcat-ec2-bridge-mapped-port
TaskGroup: family:demo-jar-tomcat-bridge-mapped-port
TaskRevision: "12"
VpcId: vpc-01234567890
container_name: demo-tomcat-ec2-bridge-mapped-port
job: demo-tomcat-ec2-bridge-mapped-port
```
É possível integrar diretamente esse arquivo de resultados à detecção de serviços baseada em arquivo do Prometheus. Para obter mais informações sobre a detecção de serviços baseada em arquivos do Prometheus, consulte [](https://prometheus.io/docs/prometheus/latest/configuration/configuration/#file_sd_config).
Suponha que o arquivo resultante seja gravado em `/tmp/cwagent_ecs_auto_sd.yaml`. A seguinte configuração de extração do Prometheus o consumirá.
```
global:
scrape_interval: 1m
scrape_timeout: 10s
scrape_configs:
- job_name: cwagent-ecs-file-sd-config
sample_limit: 10000
file_sd_configs:
- files: [ "/tmp/cwagent_ecs_auto_sd.yaml" ]
```
O atendente do CloudWatch também acrescenta os seguintes rótulos adicionais aos destinos descobertos.
+ `container_name`
+ `TaskDefinitionFamily`
+ `TaskRevision`
+ `TaskGroup`
+ `StartedBy`
+ `LaunchType`
+ `job`
+ `__metrics_path__`
+ Rótulos do Docker
Quando o cluster tiver o tipo de inicialização do EC2, os três rótulos a seguir serão adicionados.
+ `InstanceType`
+ `VpcId`
+ `SubnetId`
**nota**
Os rótulos do Docker que não correspondem à expressão regular `[a-zA-Z_][a-zA-Z0-9_]*` são filtrados. Isso corresponde às convenções do Prometheus listadas em `label_name`em [Arquivo de configuração](https://prometheus.io/docs/prometheus/latest/configuration/configuration/#labelname) na documentação do Prometheus.
## Exemplos de configuração de detecção de serviços do ECS
Esta seção contém exemplos que demonstram a detecção de serviços do ECS.
**Exemplo 1**
```
"ecs_service_discovery": {
"sd_frequency": "1m",
"sd_result_file": "/tmp/cwagent_ecs_auto_sd.yaml",
"docker_label": {
}
}
```
Este exemplo habilita a detecção de serviços baseada em rótulos do docker. O atendente do CloudWatch consultará os metadados das tarefas do ECS uma vez por minuto e gravará os destinos detectados no arquivo `/tmp/cwagent_ecs_auto_sd.yaml` dentro do contêiner do atendente do CloudWatch.
O valor padrão de `sd_port_label` na seção `docker_label` é `ECS_PROMETHEUS_EXPORTER_PORT`. Se qualquer contêiner em execução nas tarefas do ECS tiver um rótulo do docker `ECS_PROMETHEUS_EXPORTER_PORT`, o atendente do CloudWatch usará seu valor como `container port` para verificar todas as portas expostas do contêiner. Se houver uma correspondência, a porta do host mapeada mais o IP privado do contêiner serão usados para construir o destino do exportador do Prometheus neste formato: `private_ip:host_port`.
O valor padrão de `sd_metrics_path_label` na seção `docker_label` é `ECS_PROMETHEUS_METRICS_PATH`. Se o contêiner tiver esse rótulo do docker, seu valor será usado como `__metrics_path__` . Se o contêiner não tiver esse rótulo, será usado o valor padrão `/metrics`.
O valor padrão de `sd_job_name_label` na seção `docker_label` é `job`. Se o contêiner tiver esse rótulo do docker, seu valor será anexado como um dos rótulos do destino para substituir o nome do trabalho padrão especificado na configuração do Prometheus. O valor desse rótulo do docker será usado como o nome do fluxo de logs no grupo de logs do CloudWatch Logs.
**Exemplo 2**
```
"ecs_service_discovery": {
"sd_frequency": "15s",
"sd_result_file": "/tmp/cwagent_ecs_auto_sd.yaml",
"docker_label": {
"sd_port_label": "ECS_PROMETHEUS_EXPORTER_PORT_SUBSET_A",
"sd_job_name_label": "ECS_PROMETHEUS_JOB_NAME"
}
}
```
Este exemplo habilita a detecção de serviços baseada em rótulos do docker. O atendente do CloudWatch consultará os metadados das tarefas do ECS a cada 15 segundos e gravará os destinos detectados no arquivo `/tmp/cwagent_ecs_auto_sd.yaml` dentro do contêiner do atendente do CloudWatch. Os contêineres com o rótulo do docker `ECS_PROMETHEUS_EXPORTER_PORT_SUBSET_A` serão verificados. O valor do rótulo do docker `ECS_PROMETHEUS_JOB_NAME` é usado como nome do trabalho.
**Exemplo 3**
```
"ecs_service_discovery": {
"sd_frequency": "5m",
"sd_result_file": "/tmp/cwagent_ecs_auto_sd.yaml",
"task_definition_list": [
{
"sd_job_name": "java-prometheus",
"sd_metrics_path": "/metrics",
"sd_metrics_ports": "9404; 9406",
"sd_task_definition_arn_pattern": ".*:task-definition/.*javajmx.*:[0-9]+"
},
{
"sd_job_name": "envoy-prometheus",
"sd_metrics_path": "/stats/prometheus",
"sd_container_name_pattern": "^envoy$",
"sd_metrics_ports": "9901",
"sd_task_definition_arn_pattern": ".*:task-definition/.*appmesh.*:23"
}
]
}
```
Este exemplo habilita a detecção de serviço baseado em expressão regular do ARN da definição de tarefa do ECS. O atendente do CloudWatch consultará os metadados das tarefas do ECS a cada cinco minutos e gravará os destinos detectados no arquivo `/tmp/cwagent_ecs_auto_sd.yaml` dentro do contêiner do atendente do CloudWatch.
São definidas duas seções de expressão regular do ARN da definição de tarefa:
+ Na primeira seção, as tarefas do ECS com `javajmx` no ARN da definição de tarefa do ECS são filtradas para a verificação da porta do contêiner. Se os contêineres dentro dessas tarefas do ECS expuserem a porta do contêiner em 9404 ou 9406, a porta do host mapeada juntamente com o IP privado do contêiner serão usados para criar os destinos do exportador do Prometheus. O valor de `sd_metrics_path` define `__metrics_path__` como `/metrics`. Assim, o atendente do CloudWatch extrairá as métricas do Prometheus de `private_ip:host_port/metrics`, e as métricas extraídas serão enviadas ao fluxo de logs `java-prometheus` no CloudWatch Logs no grupo de logs `/aws/ecs/containerinsights/cluster_name/prometheus`.
+ Na segunda seção, as tarefas do ECS com `appmesh` no ARN da definição de tarefa do ECS e com `version` de `:23` são filtradas para a verificação da porta do contêiner. Para contêineres com um nome de `envoy` que expõem a porta do contêiner em `9901`, a porta de host mapeada e o IP privado do contêiner são usados para criar os destinos do exportador do Prometheus. Se o valor dentro dessas tarefas do ECS expuser a porta do contêiner em 9404 ou 9406, a porta do host mapeada e o IP privado do contêiner serão usados para criar os destinos do exportador do Prometheus. O valor de `sd_metrics_path` define `__metrics_path__` como `/stats/prometheus`. Assim, o atendente do CloudWatch extrairá as métricas do Prometheus de `private_ip:host_port/stats/prometheus` e enviará as métricas extraídas ao fluxo de logs `envoy-prometheus` no CloudWatch Logs no grupo de logs `/aws/ecs/containerinsights/cluster_name/prometheus`.
**Exemplo 4**
```
"ecs_service_discovery": {
"sd_frequency": "5m",
"sd_result_file": "/tmp/cwagent_ecs_auto_sd.yaml",
"service_name_list_for_tasks": [
{
"sd_job_name": "nginx-prometheus",
"sd_metrics_path": "/metrics",
"sd_metrics_ports": "9113",
"sd_service_name_pattern": "^nginx-.*"
},
{
"sd_job_name": "haproxy-prometheus",
"sd_metrics_path": "/stats/metrics",
"sd_container_name_pattern": "^haproxy$",
"sd_metrics_ports": "8404",
"sd_service_name_pattern": ".*haproxy-service.*"
}
]
}
```
Este exemplo habilita a detecção de serviço baseado em expressão regular do nome do serviço do ECS. O atendente do CloudWatch consultará os metadados dos serviços do ECS a cada cinco minutos e gravará os destinos detectados no arquivo `/tmp/cwagent_ecs_auto_sd.yaml` dentro do contêiner do atendente do CloudWatch.
São definidas duas seções de expressão regular de nome de serviço:
+ Na primeira seção, as tarefas do ECS associadas aos serviços do ECS que têm nomes correspondentes à expressão regular `^nginx-.*`são filtrados para a verificação da porta do contêiner. Se os contêineres dentro dessas tarefas do ECS expuserem a porta do contêiner em 9113, a porta do host mapeada e o IP privado do contêiner serão usados para criar os destinos do exportador do Prometheus. O valor de `sd_metrics_path` define `__metrics_path__` como `/metrics`. Assim, o atendente do CloudWatch extrairá as métricas do Prometheus de `private_ip:host_port/metrics`, e as métricas extraídas serão enviadas ao fluxo de logs `nginx-prometheus` no CloudWatch Logs no grupo de logs `/aws/ecs/containerinsights/cluster_name/prometheus`.
+ Na segunda seção, as tarefas do ECS associadas aos serviços do ECS que têm nomes correspondentes à expressão regular `.*haproxy-service.*`são filtrados para a verificação da porta do contêiner. Para contêineres com um nome de `haproxy` que expõem a porta do contêiner em 8404, a porta de host mapeada e o IP privado do contêiner são usados para criar os destinos do exportador do Prometheus. O valor de `sd_metrics_path` define `__metrics_path__` como `/stats/metrics`. Assim, o atendente do CloudWatch extrairá as métricas do Prometheus de `private_ip:host_port/stats/metrics`, e as métricas extraídas serão enviadas ao fluxo de logs `haproxy-prometheus` no CloudWatch Logs no grupo de logs `/aws/ecs/containerinsights/cluster_name/prometheus`.
**Exemplo 5**
```
"ecs_service_discovery": {
"sd_frequency": "1m30s",
"sd_result_file": "/tmp/cwagent_ecs_auto_sd.yaml",
"docker_label": {
"sd_port_label": "MY_PROMETHEUS_EXPORTER_PORT_LABEL",
"sd_metrics_path_label": "MY_PROMETHEUS_METRICS_PATH_LABEL",
"sd_job_name_label": "MY_PROMETHEUS_METRICS_NAME_LABEL"
}
"task_definition_list": [
{
"sd_metrics_ports": "9150",
"sd_task_definition_arn_pattern": "*memcached.*"
}
]
}
```
Este exemplo habilita os dois modos de detecção de serviços do ECS. O atendente do CloudWatch consultará os metadados das tarefas do ECS a cada 90 segundos e gravará os destinos detectados no arquivo `/tmp/cwagent_ecs_auto_sd.yaml` dentro do contêiner do atendente do CloudWatch.
Para a configuração de detecção de serviços baseada em docker:
+ As tarefas do ECS com rótulo do docker `MY_PROMETHEUS_EXPORTER_PORT_LABEL` serão filtradas para a verificação de porta do Prometheus. A porta do contêiner do Prometheus de destino é especificada pelo valor do rótulo `MY_PROMETHEUS_EXPORTER_PORT_LABEL`.
+ Utiliza-se o valor do rótulo do docker `MY_PROMETHEUS_EXPORTER_PORT_LABEL` para `__metrics_path__`. Se o contêiner não tiver esse rótulo do docker, será usado o valor padrão `/metrics`.
+ O valor do rótulo do docker `MY_PROMETHEUS_EXPORTER_PORT_LABEL` é usado como rótulo do trabalho. Se o contêiner não tiver esse rótulo do docker, será usado o nome do trabalho definido na configuração do Prometheus.
Para configuração da detecção de serviço baseado em expressão regular do ARN da definição de tarefa do ECS:
+ As tarefas do ECS com `memcached` no ARN da definição de tarefa do ECS são filtradas para verificação da porta do contêiner. A porta de contêiner do Prometheus de destino é 9150, conforme definido por `sd_metrics_ports`. É usado o caminho padrão das métricas `/metrics`. É usado o nome do trabalho definido na configuração do Prometheus.
# (Opcional) Configurar amostra de workloads do Amazon ECS em contêineres para teste de métrica do Prometheus
Para testar o suporte para métricas do Prometheus no CloudWatch Container Insights, você pode configurar uma ou mais das seguintes workloads em contêineres. O atendente do CloudWatch com suporte ao Prometheus coleta automaticamente métricas de cada uma dessas workloads. Para visualizar as métricas coletadas por padrão, consulte [Métricas do Prometheus coletadas pelo atendente do CloudWatch](ContainerInsights-Prometheus-metrics.md).
**Topics**
+ [Exemplo de workload do App Mesh para clusters do Amazon ECS](ContainerInsights-Prometheus-Sample-Workloads-ECS-appmesh.md)
+ [Exemplo de workload do Java/JMX para clusters do Amazon ECS](ContainerInsights-Prometheus-Sample-Workloads-ECS-javajmx.md)
+ [Exemplo de workload do NGINX para clusters do Amazon ECS](ContainerInsights-Prometheus-Setup-nginx-ecs.md)
+ [Exemplo de workload do NGINX Plus para clusters do Amazon ECS](ContainerInsights-Prometheus-Setup-nginx-plus-ecs.md)
+ [Tutorial para adicionar um novo destino de extração do Prometheus: Memcached no Amazon ECS](ContainerInsights-Prometheus-Setup-memcached-ecs.md)
+ [Tutorial para extração de métricas do Prometheus no Redis OSS no Amazon ECS Fargate](ContainerInsights-Prometheus-Setup-redis-ecs.md)
# Exemplo de workload do App Mesh para clusters do Amazon ECS
Para coletar métricas de uma amostra de workload do Prometheus para o Amazon ECS, é necessário estar executando o Container Insights no cluster. Para obter informações sobre como instalar o Container Insights, consulte [Configurar o Container Insights no Amazon ECS](deploy-container-insights-ECS.md).
Primeiro, siga esta [demonstração](https://github.com/aws/aws-app-mesh-examples/tree/main/examples/apps/colorapp#app-mesh-walkthrough-deploy-the-color-app-on-ecs) para implantar a amostra de aplicação de cores em seu cluster do Amazon ECS. Ao terminar, você terá métricas do App Mesh Prometheus expostas na porta 9901.
Em seguida, siga estas etapas para instalar o atendente do CloudWatch com o monitoramento Prometheus no mesmo cluster do Amazon ECS em que você instalou a aplicação de cores. As etapas desta seção instalam o atendente do CloudWatch no modo de rede de ponte.
As variáveis de ambiente `ENVIRONMENT_NAME`, `AWS_PROFILE` e `AWS_DEFAULT_REGION`que você definir na demonstração também serão usadas nas etapas a seguir.
**Para instalar o atendente do CloudWatch com monitoramento do Prometheus para teste**
1. Baixe o modelo do CloudFormation inserindo o comando a seguir.
```
curl -O https://raw.githubusercontent.com/aws-samples/amazon-cloudwatch-container-insights/latest/ecs-task-definition-templates/deployment-mode/replica-service/cwagent-prometheus/cloudformation-quickstart/cwagent-ecs-prometheus-metric-for-bridge-host.yaml
```
1. Defina o modo de rede inserindo os comandos a seguir.
```
export ECS_CLUSTER_NAME=${ENVIRONMENT_NAME}
export ECS_NETWORK_MODE=bridge
```
1. Crie a pilha do CloudFormation inserindo os comandos abaixo.
```
aws cloudformation create-stack --stack-name CWAgent-Prometheus-ECS-${ECS_CLUSTER_NAME}-EC2-${ECS_NETWORK_MODE} \
--template-body file://cwagent-ecs-prometheus-metric-for-bridge-host.yaml \
--parameters ParameterKey=ECSClusterName,ParameterValue=${ECS_CLUSTER_NAME} \
ParameterKey=CreateIAMRoles,ParameterValue=True \
ParameterKey=ECSNetworkMode,ParameterValue=${ECS_NETWORK_MODE} \
ParameterKey=TaskRoleName,ParameterValue=CWAgent-Prometheus-TaskRole-${ECS_CLUSTER_NAME} \
ParameterKey=ExecutionRoleName,ParameterValue=CWAgent-Prometheus-ExecutionRole-${ECS_CLUSTER_NAME} \
--capabilities CAPABILITY_NAMED_IAM \
--region ${AWS_DEFAULT_REGION} \
--profile ${AWS_PROFILE}
```
1. (Opcional) Quando a pilha do CloudFormation for criada, você verá a mensagem `CREATE_COMPLETE`. Se conferir o status antes de visualizar essa mensagem, insira o comando a seguir.
```
aws cloudformation describe-stacks \
--stack-name CWAgent-Prometheus-ECS-${ECS_CLUSTER_NAME}-EC2-${ECS_NETWORK_MODE} \
--query 'Stacks[0].StackStatus' \
--region ${AWS_DEFAULT_REGION} \
--profile ${AWS_PROFILE}
```
**Solução de problemas do**
As etapas da demonstração usam jq para analisar o resultado de saída da AWS CLI. Para obter mais informações sobre como instalar o jq, consulte [jq](https://stedolan.github.io/jq/). Use o comando a seguir para definir o formato de saída padrão da AWS CLI para JSON, de modo que o jq possa analisá-lo corretamente.
```
$ aws configure
```
Quando a resposta chegar a `Default output format`, insira **json**.
## Instalar o atendente do CloudWatch com monitoramento do Prometheus
Quando terminar de testar, insira o comando a seguir para desinstalar o atendente do CloudWatch excluindo a pilha do CloudFormation.
```
aws cloudformation delete-stack \
--stack-name CWAgent-Prometheus-ECS-${ECS_CLUSTER_NAME}-EC2-${ECS_NETWORK_MODE} \
--region ${AWS_DEFAULT_REGION} \
--profile ${AWS_PROFILE}
```
# Exemplo de workload do Java/JMX para clusters do Amazon ECS
O JMX Exporter é um exportador oficial do Prometheus que pode extrair conteúdo e expor mBeans da JMX como métricas do Prometheus. Para obter mais informações, consulte [prometheus/jmx\$1exporter](https://github.com/prometheus/jmx_exporter).
O atendente do CloudWatch com suporte ao Prometheus extrai as métricas do Java/JMX Prometheus com base na configuração de detecção de serviço no cluster do Amazon ECS. Você pode configurar o JMX Exporter de modo a expor as métricas em uma porta ou metrics\$1path diferente. Se alterar a porta ou o caminho, atualize a seção `ecs_service_discovery` padrão na configuração do atendente do CloudWatch.
Para coletar métricas de uma amostra de workload do Prometheus para o Amazon ECS, é necessário estar executando o Container Insights no cluster. Para obter informações sobre como instalar o Container Insights, consulte [Configurar o Container Insights no Amazon ECS](deploy-container-insights-ECS.md).
**Para instalar o exemplo de workload do Java/JMX para clusters do Amazon ECS**
1. Siga as etapas destas seções para criar suas imagens do Docker.
+ [Exemplo: imagem do Docker da aplicação Java Jar com métricas do Prometheus](ContainerInsights-Prometheus-Sample-Workloads-javajmx.md#ContainerInsights-Prometheus-Sample-Workloads-javajmx-jar)
+ [Exemplo: imagem do Docker do Apache Tomcat com métricas do Prometheus](ContainerInsights-Prometheus-Sample-Workloads-javajmx.md#ContainerInsights-Prometheus-Sample-Workloads-javajmx-tomcat)
1. Especifique os dois rótulos do docker a seguir no arquivo de definição de tarefa do Amazon ECS. Em seguida, é possível executar a definição da tarefa como um serviço do Amazon ECS ou uma tarefa do Amazon ECS no cluster.
+ Defina `ECS_PROMETHEUS_EXPORTER_PORT` para apontar para a containerPort onde as métricas do Prometheus estão expostas.
+ Defina `Java_EMF_Metrics` como `true`. O atendente do CloudWatch usa esse sinalizador para gerar o formato de métrica incorporado no evento de log.
Este é um exemplo:
```
{
"family": "workload-java-ec2-bridge",
"taskRoleArn": "{{task-role-arn}}",
"executionRoleArn": "{{execution-role-arn}}",
"networkMode": "bridge",
"containerDefinitions": [
{
"name": "tomcat-prometheus-workload-java-ec2-bridge-dynamic-port",
"image": "your_docker_image_tag_for_tomcat_with_prometheus_metrics",
"portMappings": [
{
"hostPort": 0,
"protocol": "tcp",
"containerPort": 9404
}
],
"dockerLabels": {
"ECS_PROMETHEUS_EXPORTER_PORT": "9404",
"Java_EMF_Metrics": "true"
}
}
],
"requiresCompatibilities": [
"EC2" ],
"cpu": "256",
"memory": "512"
}
```
A configuração padrão do atendente do CloudWatch no modelo CloudFormation permite a detecção de serviços baseada em rótulos do docker e a detecção de serviços baseada no ARN da definição de tarefa. Para exibir essas configurações padrão, consulte a linha 65 do [arquivo de configurações YAML do atendente do CloudWatch](https://github.com/aws-samples/amazon-cloudwatch-container-insights/blob/latest/ecs-task-definition-templates/deployment-mode/replica-service/cwagent-prometheus/cloudformation-quickstart/cwagent-ecs-prometheus-metric-for-bridge-host.yaml#L65). Os contêineres com o rótulo `ECS_PROMETHEUS_EXPORTER_PORT` serão descobertos automaticamente com base na porta de contêiner especificada para extração do Prometheus.
A configuração padrão do atendente do CloudWatch também tem a configuração `metric_declaration` para Java/JMX na linha 112 do mesmo arquivo. Todos os rótulos do docker dos contêineres de destino serão acrescentados como rótulos adicionais nas métricas do Prometheus e enviados ao CloudWatch Logs. Para os contêineres Java/JMX com rótulo do docker `Java_EMF_Metrics=“true”`, será gerado o formato de métrica incorporado.
# Exemplo de workload do NGINX para clusters do Amazon ECS
O exportador do NGINX Prometheus pode extrair e expor dados do NGINX como métricas do Prometheus. Este exemplo usa o exportador com o serviço de proxy reverso do NGINX para o Amazon ECS.
Para obter mais informações sobre o exportador do NGINX Prometheus, consulte [nginx-prometheus-exporter](https://github.com/nginxinc/nginx-prometheus-exporter) no Github. Para obter mais informações sobre o proxy reverso do NGINX, consulte [ecs-nginx-reverse-proxy](https://github.com/awslabs/ecs-nginx-reverse-proxy) no Github.
O atendente do CloudWatch com suporte ao Prometheus extrai as métricas do NGINX Prometheus com base na configuração de detecção de serviço no cluster do Amazon ECS. Você pode configurar o NGINX Prometheus Exporter de modo a expor as métricas em uma porta ou um caminho diferente. Se alterar a porta ou o caminho, atualize a seção `ecs_service_discovery` no arquivo de configuração do atendente do CloudWatch.
## Instalar o exemplo de workload de proxy reverso do NGINX para clusters do Amazon ECS
Siga estas etapas para instalar o exemplo de workload de proxy reverso do NGINX.
### Criar as imagens do Docker
**Para criar as imagens do Docker para o exemplo de workload de proxy reverso do NGINX**
1. Baixe esta pasta do repositório de proxy reverso do NGINX:[ https://github.com/awslabs/ecs-nginx-reverse-proxy/tree/master/reverse-proxy](https://github.com/awslabs/ecs-nginx-reverse-proxy/tree/master/reverse-proxy/).
1. Encontre o diretório `app` e crie uma imagem a partir desse diretório:
```
docker build -t web-server-app ./path-to-app-directory
```
1. Crie uma imagem personalizada para o NGINX. Primeiro, crie um diretório com estes dois arquivos:
+ Um exemplo de Dockerfile:
```
FROM nginx
COPY nginx.conf /etc/nginx/nginx.conf
```
+ Um arquivo `nginx.conf`, modificado a partir de [https://github.com/awslabs/ecs-nginx-reverse-proxy/tree/master/reverse-proxy](https://github.com/awslabs/ecs-nginx-reverse-proxy/tree/master/reverse-proxy/):
```
events {
worker_connections 768;
}
http {
# Nginx will handle gzip compression of responses from the app server
gzip on;
gzip_proxied any;
gzip_types text/plain application/json;
gzip_min_length 1000;
server{
listen 8080;
location /stub_status {
stub_status on;
}
}
server {
listen 80;
# Nginx will reject anything not matching /api
location /api {
# Reject requests with unsupported HTTP method
if ($request_method !~ ^(GET|POST|HEAD|OPTIONS|PUT|DELETE)$) {
return 405;
}
# Only requests matching the whitelist expectations will
# get sent to the application server
proxy_pass http://app:3000;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection 'upgrade';
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_cache_bypass $http_upgrade;
}
}
}
```
**nota**
`stub_status` deve estar habilitado na mesma porta de onde `nginx-prometheus-exporter` está configurado para extrair métricas. Em nosso exemplo de definição de tarefa, `nginx-prometheus-exporter` está configurado para extrar métricas da porta 8080.
1. Crie uma imagem a partir de arquivos em seu novo diretório:
```
docker build -t nginx-reverse-proxy ./path-to-your-directory
```
1. Carregue as novas imagens para um repositório de imagens para uso posterior.
### Crie a definição de tarefa para executar o NGINX e a aplicação de servidor da Web no Amazon ECS
Em seguida, configure a definição de tarefa.
Essa definição de tarefa permite a coleta e exportação de métricas do NGINX Prometheus. O contêiner do NGINX rastreia a entrada da aplicação e expõe esses dados à porta 8080, conforme definido em `nginx.conf`. O contêiner do exportador do NGINX Prometheus extrai essas métricas e as publica na porta 9113, para serem usadas no CloudWatch.
**Para configurar a definição de tarefa para o exemplo de workload do NGINX no Amazon ECS**
1. Crie um arquivo JSON de definição de tarefa com o seguinte conteúdo. Substitua *your-customized-nginx-iamge* pelo URI de imagem para sua imagem do NGINX personalizada e substitua *your-web-server-app-image* pelo URI de imagem de sua imagem de aplicação do servidor da Web.
```
{
"containerDefinitions": [
{
"name": "nginx",
"image": "your-customized-nginx-image",
"memory": 256,
"cpu": 256,
"essential": true,
"portMappings": [
{
"containerPort": 80,
"protocol": "tcp"
}
],
"links": [
"app"
]
},
{
"name": "app",
"image": "your-web-server-app-image",
"memory": 256,
"cpu": 256,
"essential": true
},
{
"name": "nginx-prometheus-exporter",
"image": "docker.io/nginx/nginx-prometheus-exporter:0.8.0",
"memory": 256,
"cpu": 256,
"essential": true,
"command": [
"-nginx.scrape-uri",
"http://nginx:8080/stub_status"
],
"links":[
"nginx"
],
"portMappings":[
{
"containerPort": 9113,
"protocol": "tcp"
}
]
}
],
"networkMode": "bridge",
"placementConstraints": [],
"family": "nginx-sample-stack"
}
```
1. Insira o comando a seguir para registrar a definição de tarefa.
```
aws ecs register-task-definition --cli-input-json file://path-to-your-task-definition-json
```
1. Crie um serviço para executar a tarefa inserindo o comando a seguir:
Não altere o nome do serviço. Executaremos um serviço de atendente do CloudWatch usando uma configuração que procura tarefas usando os padrões de nome dos serviços que os iniciaram. Por exemplo, para que o atendente do CloudWatch localize a tarefa iniciada por este comando, é possível especificar o valor de `sd_service_name_pattern` como `^nginx-service$`. A próxima seção oferece mais detalhes.
```
aws ecs create-service \
--cluster your-cluster-name \
--service-name nginx-service \
--task-definition nginx-sample-stack:1 \
--desired-count 1
```
### Configurar o atendente do CloudWatch para extrair métricas do NGINX Prometheus
A etapa final é configurar o atendente do CloudWatch para extrair as métricas do NGINX. Neste exemplo, o atendente do CloudWatch detecta a tarefa por meio do padrão de nome de serviço e da porta 9113, onde o exportador expõe as métricas prometheus para o NGINX. Com a tarefa detectada e as métricas disponíveis, o atendente do CloudWatch começa a publicar as métricas coletadas no fluxo de logs **nginx-prometheus-exporter**.
**Para configurar o atendente do CloudWatch para extrair métricas do NGINX**
1. Baixe a versão mais recente do arquivo YAML necessário inserindo um dos comandos a seguir.
```
curl -O https://raw.githubusercontent.com/aws-samples/amazon-cloudwatch-container-insights/latest/ecs-task-definition-templates/deployment-mode/replica-service/cwagent-prometheus/cloudformation-quickstart/cwagent-ecs-prometheus-metric-for-bridge-host.yaml
```
1. Abra o arquivo com um editor de textos e encontre a confguração completa do atendente do CloudWatch na chave `value` da seção `resource:CWAgentConfigSSMParameter`. Depois, na seção `ecs_service_discovery`, adicione a seção `service_name_list_for_tasks` a seguir.
```
"service_name_list_for_tasks": [
{
"sd_job_name": "nginx-prometheus-exporter",
"sd_metrics_path": "/metrics",
"sd_metrics_ports": "9113",
"sd_service_name_pattern": "^nginx-service$"
}
],
```
1. No mesmo arquivo, insira a seguinte seção na seção `metric_declaration` para permitir métricas do NGINX. Siga o padrão de recuo existente.
```
{
"source_labels": ["job"],
"label_matcher": ".*nginx.*",
"dimensions": [["ClusterName", "TaskDefinitionFamily", "ServiceName"]],
"metric_selectors": [
"^nginx_.*$"
]
},
```
1. Se você ainda não tiver o atendente do CloudWatch implantado nesse cluster, pule para a etapa 8.
Se já tiver o atendente do CloudWatch implantado no cluster do Amazon ECS usando o AWS CloudFormation, é possível criar um conjunto de alterações inserindo os seguintes comandos:
```
ECS_CLUSTER_NAME=your_cluster_name
AWS_REGION=your_aws_region
ECS_NETWORK_MODE=bridge
CREATE_IAM_ROLES=True
ECS_TASK_ROLE_NAME=your_selected_ecs_task_role_name
ECS_EXECUTION_ROLE_NAME=your_selected_ecs_execution_role_name
aws cloudformation create-change-set --stack-name CWAgent-Prometheus-ECS-${ECS_CLUSTER_NAME}-EC2-${ECS_NETWORK_MODE} \
--template-body file://cwagent-ecs-prometheus-metric-for-bridge-host.yaml \
--parameters ParameterKey=ECSClusterName,ParameterValue=$ECS_CLUSTER_NAME \
ParameterKey=CreateIAMRoles,ParameterValue=$CREATE_IAM_ROLES \
ParameterKey=ECSNetworkMode,ParameterValue=$ECS_NETWORK_MODE \
ParameterKey=TaskRoleName,ParameterValue=$ECS_TASK_ROLE_NAME \
ParameterKey=ExecutionRoleName,ParameterValue=$ECS_EXECUTION_ROLE_NAME \
--capabilities CAPABILITY_NAMED_IAM \
--region $AWS_REGION \
--change-set-name nginx-scraping-support
```
1. Abra o console do CloudFormation em [https://console.aws.amazon.com/cloudformation](https://console.aws.amazon.com/cloudformation/).
1. Revisar o changeset recém-criado **nginx-scraping-support**. Você deverá ver uma alteração aplicada ao recurso **CWAgentConfigSSMParameter**. Execute o changeset e reinicie a tarefa do atendente do CloudWatch inserindo este comando:
```
aws ecs update-service --cluster $ECS_CLUSTER_NAME \
--desired-count 0 \
--service cwagent-prometheus-replica-service-EC2-$ECS_NETWORK_MODE \
--region $AWS_REGION
```
1. Aguarde cerca de 10 segundos e insira este comando.
```
aws ecs update-service --cluster $ECS_CLUSTER_NAME \
--desired-count 1 \
--service cwagent-prometheus-replica-service-EC2-$ECS_NETWORK_MODE \
--region $AWS_REGION
```
1. Se você estiver instalando o atendente do CloudWatch com coleta de métricas do Prometheus no cluster pela primeira vez, insira estes comandos.
```
ECS_CLUSTER_NAME=your_cluster_name
AWS_REGION=your_aws_region
ECS_NETWORK_MODE=bridge
CREATE_IAM_ROLES=True
ECS_TASK_ROLE_NAME=your_selected_ecs_task_role_name
ECS_EXECUTION_ROLE_NAME=your_selected_ecs_execution_role_name
aws cloudformation create-stack --stack-name CWAgent-Prometheus-ECS-${ECS_CLUSTER_NAME}-EC2-${ECS_NETWORK_MODE} \
--template-body file://cwagent-ecs-prometheus-metric-for-bridge-host.yaml \
--parameters ParameterKey=ECSClusterName,ParameterValue=$ECS_CLUSTER_NAME \
ParameterKey=CreateIAMRoles,ParameterValue=$CREATE_IAM_ROLES \
ParameterKey=ECSNetworkMode,ParameterValue=$ECS_NETWORK_MODE \
ParameterKey=TaskRoleName,ParameterValue=$ECS_TASK_ROLE_NAME \
ParameterKey=ExecutionRoleName,ParameterValue=$ECS_EXECUTION_ROLE_NAME \
--capabilities CAPABILITY_NAMED_IAM \
--region $AWS_REGION
```
## Visualizar métricas e logs do NGINX
Agora é possível visualizar as métricas do NGINX que estão sendo coletadas.
**Para visualizar as métricas do exemplo de workload do NGINX**
1. Abra o console do CloudWatch, em [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).
1. Na região da em que o cluster está em execução, escolha **Metrics** (Métricas) no painel de navegação à esquerda. Encontre o namespace **ContainerInsights/Prometheus** para ver as métricas.
1. Para visualizar os eventos do CloudWatch Logs, escolha **Log Groups** (Grupos de logs) no painel de navegação. Os eventos estão no grupo de logs **/aws/containerinsights/*your\$1cluster\$1name*/prometheus**, no fluxo de logs *nginx-prometheus-exporter*.
# Exemplo de workload do NGINX Plus para clusters do Amazon ECS
O NGINX Plus é a versão comercial do NGINX. É necessário ter uma licença para usá-lo. Para obter mais informações, consulte [NGINX Plus](https://www.nginx.com/products/nginx/).
O exportador do NGINX Prometheus pode extrair e expor dados do NGINX como métricas do Prometheus. Este exemplo usa o exportador com o serviço de proxy reverso do NGINX Plus para o Amazon ECS.
Para obter mais informações sobre o exportador do NGINX Prometheus, consulte [nginx-prometheus-exporter](https://github.com/nginxinc/nginx-prometheus-exporter) no Github. Para obter mais informações sobre o proxy reverso do NGINX, consulte [ecs-nginx-reverse-proxy](https://github.com/awslabs/ecs-nginx-reverse-proxy) no Github.
O atendente do CloudWatch com suporte ao Prometheus extrai as métricas do NGINX Plus Prometheus com base na configuração de detecção de serviço no cluster do Amazon ECS. Você pode configurar o NGINX Prometheus Exporter de modo a expor as métricas em uma porta ou um caminho diferente. Se alterar a porta ou o caminho, atualize a seção `ecs_service_discovery` no arquivo de configuração do atendente do CloudWatch.
## Instalar o exemplo de workload de proxy reverso do NGINX Plus para clusters do Amazon ECS
Siga estas etapas para instalar o exemplo de workload de proxy reverso do NGINX.
### Criar as imagens do Docker
**Para criar as imagens do Docker para o exemplo de workload de proxy reverso do NGINX Plus**
1. Baixe esta pasta do repositório de proxy reverso do NGINX:[ https://github.com/awslabs/ecs-nginx-reverse-proxy/tree/master/reverse-proxy](https://github.com/awslabs/ecs-nginx-reverse-proxy/tree/master/reverse-proxy/).
1. Encontre o diretório `app` e crie uma imagem a partir desse diretório:
```
docker build -t web-server-app ./path-to-app-directory
```
1. Crie uma imagem personalizada para o NGINX Plus. Para poder criar a imagem para o NGINX Plus, é necessário obter a chave chamada `nginx-repo.key` e o certificado SSL `nginx-repo.crt` para seu NGINX Plus licenciado. Crie um diretório e armazene em seus arquivos `nginx-repo.key` e `nginx-repo.crt`.
No diretório que você acabou de criar, crie estes dois arquivos:
+ Um exemplo de Dockerfile com o conteúdo a seguir. Este arquivo do docker é adotado a partir de um arquivo de exemplo disponível em [https://docs.nginx.com/nginx/admin-guide/installing-nginx/installing-nginx-docker/\$1docker\$1plus\$1image](https://docs.nginx.com/nginx/admin-guide/installing-nginx/installing-nginx-docker/#docker_plus_image). A mudança importante que fazemos é carregar um arquivo separado, chamado `nginx.conf`, que será criado na próxima etapa.
```
FROM debian:buster-slim
LABEL maintainer="NGINX Docker Maintainers “
# Define NGINX versions for NGINX Plus and NGINX Plus modules
# Uncomment this block and the versioned nginxPackages block in the main RUN
# instruction to install a specific release
# ENV NGINX_VERSION 21
# ENV NJS_VERSION 0.3.9
# ENV PKG_RELEASE 1~buster
# Download certificate and key from the customer portal (https://cs.nginx.com (https://cs.nginx.com/))
# and copy to the build context
COPY nginx-repo.crt /etc/ssl/nginx/
COPY nginx-repo.key /etc/ssl/nginx/
# COPY nginx.conf /etc/ssl/nginx/nginx.conf
RUN set -x \
# Create nginx user/group first, to be consistent throughout Docker variants
&& addgroup --system --gid 101 nginx \
&& adduser --system --disabled-login --ingroup nginx --no-create-home --home /nonexistent --gecos "nginx user" --shell /bin/false --uid 101 nginx \
&& apt-get update \
&& apt-get install --no-install-recommends --no-install-suggests -y ca-certificates gnupg1 \
&& \
NGINX_GPGKEY=573BFD6B3D8FBC641079A6ABABF5BD827BD9BF62; \
found=''; \
for server in \
ha.pool.sks-keyservers.net (http://ha.pool.sks-keyservers.net/) \
hkp://keyserver.ubuntu.com:80 \
hkp://p80.pool.sks-keyservers.net:80 \
pgp.mit.edu (http://pgp.mit.edu/) \
; do \
echo "Fetching GPG key $NGINX_GPGKEY from $server"; \
apt-key adv --keyserver "$server" --keyserver-options timeout=10 --recv-keys "$NGINX_GPGKEY" && found=yes && break; \
done; \
test -z "$found" && echo >&2 "error: failed to fetch GPG key $NGINX_GPGKEY" && exit 1; \
apt-get remove --purge --auto-remove -y gnupg1 && rm -rf /var/lib/apt/lists/* \
# Install the latest release of NGINX Plus and/or NGINX Plus modules
# Uncomment individual modules if necessary
# Use versioned packages over defaults to specify a release
&& nginxPackages=" \
nginx-plus \
# nginx-plus=${NGINX_VERSION}-${PKG_RELEASE} \
# nginx-plus-module-xslt \
# nginx-plus-module-xslt=${NGINX_VERSION}-${PKG_RELEASE} \
# nginx-plus-module-geoip \
# nginx-plus-module-geoip=${NGINX_VERSION}-${PKG_RELEASE} \
# nginx-plus-module-image-filter \
# nginx-plus-module-image-filter=${NGINX_VERSION}-${PKG_RELEASE} \
# nginx-plus-module-perl \
# nginx-plus-module-perl=${NGINX_VERSION}-${PKG_RELEASE} \
# nginx-plus-module-njs \
# nginx-plus-module-njs=${NGINX_VERSION}+${NJS_VERSION}-${PKG_RELEASE} \
" \
&& echo "Acquire::https::plus-pkgs.nginx.com::Verify-Peer \"true\";" >> /etc/apt/apt.conf.d/90nginx \
&& echo "Acquire::https::plus-pkgs.nginx.com::Verify-Host \"true\";" >> /etc/apt/apt.conf.d/90nginx \
&& echo "Acquire::https::plus-pkgs.nginx.com::SslCert \"/etc/ssl/nginx/nginx-repo.crt\";" >> /etc/apt/apt.conf.d/90nginx \
&& echo "Acquire::https::plus-pkgs.nginx.com::SslKey \"/etc/ssl/nginx/nginx-repo.key\";" >> /etc/apt/apt.conf.d/90nginx \
&& printf "deb https://plus-pkgs.nginx.com/debian buster nginx-plus\n" > /etc/apt/sources.list.d/nginx-plus.list \
&& apt-get update \
&& apt-get install --no-install-recommends --no-install-suggests -y \
$nginxPackages \
gettext-base \
curl \
&& apt-get remove --purge --auto-remove -y && rm -rf /var/lib/apt/lists/* /etc/apt/sources.list.d/nginx-plus.list \
&& rm -rf /etc/apt/apt.conf.d/90nginx /etc/ssl/nginx
# Forward request logs to Docker log collector
RUN ln -sf /dev/stdout /var/log/nginx/access.log \
&& ln -sf /dev/stderr /var/log/nginx/error.log
COPY nginx.conf /etc/nginx/nginx.conf
EXPOSE 80
STOPSIGNAL SIGTERM
CMD ["nginx", "-g", "daemon off;"]
```
+ Um arquivo `nginx.conf`, modificado a partir de [https://github.com/awslabs/ecs-nginx-reverse-proxy/tree/master/reverse-proxy/nginx](https://github.com/awslabs/ecs-nginx-reverse-proxy/tree/master/reverse-proxy/nginx).
```
events {
worker_connections 768;
}
http {
# Nginx will handle gzip compression of responses from the app server
gzip on;
gzip_proxied any;
gzip_types text/plain application/json;
gzip_min_length 1000;
upstream backend {
zone name 10m;
server app:3000 weight=2;
server app2:3000 weight=1;
}
server{
listen 8080;
location /api {
api write=on;
}
}
match server_ok {
status 100-599;
}
server {
listen 80;
status_zone zone;
# Nginx will reject anything not matching /api
location /api {
# Reject requests with unsupported HTTP method
if ($request_method !~ ^(GET|POST|HEAD|OPTIONS|PUT|DELETE)$) {
return 405;
}
# Only requests matching the whitelist expectations will
# get sent to the application server
proxy_pass http://backend;
health_check uri=/lorem-ipsum match=server_ok;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection 'upgrade';
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_cache_bypass $http_upgrade;
}
}
}
```
1. Crie uma imagem a partir de arquivos em seu novo diretório:
```
docker build -t nginx-plus-reverse-proxy ./path-to-your-directory
```
1. Carregue as novas imagens para um repositório de imagens para uso posterior.
### Crie a definição de tarefa para executar o NGINX Plus e a aplicação de servidor da Web no Amazon ECS
Em seguida, configure a definição de tarefa.
Essa definição de tarefa permite a coleta e exportação de métricas do NGINX Plus Prometheus. O contêiner do NGINX rastreia a entrada da aplicação e expõe esses dados à porta 8080, conforme definido em `nginx.conf`. O contêiner do exportador do NGINX Prometheus extrai essas métricas e as publica na porta 9113, para serem usadas no CloudWatch.
**Para configurar a definição de tarefa para o exemplo de workload do NGINX no Amazon ECS**
1. Crie um arquivo JSON de definição de tarefa com o seguinte conteúdo. Substitua *your-customized-nginx-plus-image* pelo URI de imagem para sua imagem do NGINX Plus personalizada e substitua *your-web-server-app-image* pelo URI de imagem de sua imagem de aplicação do servidor da Web.
```
{
"containerDefinitions": [
{
"name": "nginx",
"image": "your-customized-nginx-plus-image",
"memory": 256,
"cpu": 256,
"essential": true,
"portMappings": [
{
"containerPort": 80,
"protocol": "tcp"
}
],
"links": [
"app",
"app2"
]
},
{
"name": "app",
"image": "your-web-server-app-image",
"memory": 256,
"cpu": 128,
"essential": true
},
{
"name": "app2",
"image": "your-web-server-app-image",
"memory": 256,
"cpu": 128,
"essential": true
},
{
"name": "nginx-prometheus-exporter",
"image": "docker.io/nginx/nginx-prometheus-exporter:0.8.0",
"memory": 256,
"cpu": 256,
"essential": true,
"command": [
"-nginx.plus",
"-nginx.scrape-uri",
"http://nginx:8080/api"
],
"links":[
"nginx"
],
"portMappings":[
{
"containerPort": 9113,
"protocol": "tcp"
}
]
}
],
"networkMode": "bridge",
"placementConstraints": [],
"family": "nginx-plus-sample-stack"
}
```
1. Registre a definição de tarefa:
```
aws ecs register-task-definition --cli-input-json file://path-to-your-task-definition-json
```
1. Crie um serviço para executar a tarefa inserindo o comando a seguir:
```
aws ecs create-service \
--cluster your-cluster-name \
--service-name nginx-plus-service \
--task-definition nginx-plus-sample-stack:1 \
--desired-count 1
```
Não altere o nome do serviço. Executaremos um serviço de atendente do CloudWatch usando uma configuração que procura tarefas usando os padrões de nome dos serviços que os iniciaram. Por exemplo, para que o atendente do CloudWatch localize a tarefa iniciada por este comando, é possível especificar o valor de `sd_service_name_pattern` como `^nginx-plus-service$`. A próxima seção oferece mais detalhes.
### Configurar o atendente do CloudWatch para extrair métricas do NGINX Plus Prometheus
A etapa final é configurar o atendente do CloudWatch para extrair as métricas do NGINX. Neste exemplo, o atendente do CloudWatch detecta a tarefa por meio do padrão de nome de serviço e da porta 9113, onde o exportador expõe as métricas prometheus para o NGINX. Com a tarefa detectada e as métricas disponíveis, o atendente do CloudWatch começa a publicar as métricas coletadas no fluxo de logs **nginx-prometheus-exporter**.
**Para configurar o atendente do CloudWatch para extrair métricas do NGINX**
1. Baixe a versão mais recente do arquivo YAML necessário inserindo um dos comandos a seguir.
```
curl -O https://raw.githubusercontent.com/aws-samples/amazon-cloudwatch-container-insights/latest/ecs-task-definition-templates/deployment-mode/replica-service/cwagent-prometheus/cloudformation-quickstart/cwagent-ecs-prometheus-metric-for-bridge-host.yaml
```
1. Abra o arquivo com um editor de textos e encontre a confguração completa do atendente do CloudWatch na chave `value` da seção `resource:CWAgentConfigSSMParameter`. Depois, na seção `ecs_service_discovery`, adicione a seção `service_name_list_for_tasks` a seguir.
```
"service_name_list_for_tasks": [
{
"sd_job_name": "nginx-plus-prometheus-exporter",
"sd_metrics_path": "/metrics",
"sd_metrics_ports": "9113",
"sd_service_name_pattern": "^nginx-plus.*"
}
],
```
1. No mesmo arquivo, insira a seguinte seção na seção `metric_declaration` para permitir métricas do NGINX Plus. Siga o padrão de recuo existente.
```
{
"source_labels": ["job"],
"label_matcher": "^nginx-plus.*",
"dimensions": [["ClusterName", "TaskDefinitionFamily", "ServiceName"]],
"metric_selectors": [
"^nginxplus_connections_accepted$",
"^nginxplus_connections_active$",
"^nginxplus_connections_dropped$",
"^nginxplus_connections_idle$",
"^nginxplus_http_requests_total$",
"^nginxplus_ssl_handshakes$",
"^nginxplus_ssl_handshakes_failed$",
"^nginxplus_up$",
"^nginxplus_upstream_server_health_checks_fails$"
]
},
{
"source_labels": ["job"],
"label_matcher": "^nginx-plus.*",
"dimensions": [["ClusterName", "TaskDefinitionFamily", "ServiceName", "upstream"]],
"metric_selectors": [
"^nginxplus_upstream_server_response_time$"
]
},
{
"source_labels": ["job"],
"label_matcher": "^nginx-plus.*",
"dimensions": [["ClusterName", "TaskDefinitionFamily", "ServiceName", "code"]],
"metric_selectors": [
"^nginxplus_upstream_server_responses$",
"^nginxplus_server_zone_responses$"
]
},
```
1. Se você ainda não tiver o atendente do CloudWatch implantado nesse cluster, pule para a etapa 8.
Se já tiver o atendente do CloudWatch implantado no cluster do Amazon ECS usando o AWS CloudFormation, é possível criar um conjunto de alterações inserindo os seguintes comandos:
```
ECS_CLUSTER_NAME=your_cluster_name
AWS_REGION=your_aws_region
ECS_NETWORK_MODE=bridge
CREATE_IAM_ROLES=True
ECS_TASK_ROLE_NAME=your_selected_ecs_task_role_name
ECS_EXECUTION_ROLE_NAME=your_selected_ecs_execution_role_name
aws cloudformation create-change-set --stack-name CWAgent-Prometheus-ECS-${ECS_CLUSTER_NAME}-EC2-${ECS_NETWORK_MODE} \
--template-body file://cwagent-ecs-prometheus-metric-for-bridge-host.yaml \
--parameters ParameterKey=ECSClusterName,ParameterValue=$ECS_CLUSTER_NAME \
ParameterKey=CreateIAMRoles,ParameterValue=$CREATE_IAM_ROLES \
ParameterKey=ECSNetworkMode,ParameterValue=$ECS_NETWORK_MODE \
ParameterKey=TaskRoleName,ParameterValue=$ECS_TASK_ROLE_NAME \
ParameterKey=ExecutionRoleName,ParameterValue=$ECS_EXECUTION_ROLE_NAME \
--capabilities CAPABILITY_NAMED_IAM \
--region $AWS_REGION \
--change-set-name nginx-plus-scraping-support
```
1. Abra o console do CloudFormation em [https://console.aws.amazon.com/cloudformation](https://console.aws.amazon.com/cloudformation/).
1. Revisar o changeset recém-criado **nginx-plus-scraping-support**. Você deverá ver uma alteração aplicada ao recurso **CWAgentConfigSSMParameter**. Execute o changeset e reinicie a tarefa do atendente do CloudWatch inserindo este comando:
```
aws ecs update-service --cluster $ECS_CLUSTER_NAME \
--desired-count 0 \
--service cwagent-prometheus-replica-service-EC2-$ECS_NETWORK_MODE \
--region $AWS_REGION
```
1. Aguarde cerca de 10 segundos e insira este comando.
```
aws ecs update-service --cluster $ECS_CLUSTER_NAME \
--desired-count 1 \
--service cwagent-prometheus-replica-service-EC2-$ECS_NETWORK_MODE \
--region $AWS_REGION
```
1. Se você estiver instalando o atendente do CloudWatch com coleta de métricas do Prometheus no cluster pela primeira vez, insira estes comandos.
```
ECS_CLUSTER_NAME=your_cluster_name
AWS_REGION=your_aws_region
ECS_NETWORK_MODE=bridge
CREATE_IAM_ROLES=True
ECS_TASK_ROLE_NAME=your_selected_ecs_task_role_name
ECS_EXECUTION_ROLE_NAME=your_selected_ecs_execution_role_name
aws cloudformation create-stack --stack-name CWAgent-Prometheus-ECS-${ECS_CLUSTER_NAME}-EC2-${ECS_NETWORK_MODE} \
--template-body file://cwagent-ecs-prometheus-metric-for-bridge-host.yaml \
--parameters ParameterKey=ECSClusterName,ParameterValue=$ECS_CLUSTER_NAME \
ParameterKey=CreateIAMRoles,ParameterValue=$CREATE_IAM_ROLES \
ParameterKey=ECSNetworkMode,ParameterValue=$ECS_NETWORK_MODE \
ParameterKey=TaskRoleName,ParameterValue=$ECS_TASK_ROLE_NAME \
ParameterKey=ExecutionRoleName,ParameterValue=$ECS_EXECUTION_ROLE_NAME \
--capabilities CAPABILITY_NAMED_IAM \
--region $AWS_REGION
```
## Visualizar métricas e logs do NGINX Plus
Agora é possível visualizar as métricas do NGINX Plus que estão sendo coletadas.
**Para visualizar as métricas do exemplo de workload do NGINX**
1. Abra o console do CloudWatch, em [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).
1. Na região da em que o cluster está em execução, escolha **Metrics** (Métricas) no painel de navegação à esquerda. Encontre o namespace **ContainerInsights/Prometheus** para ver as métricas.
1. Para visualizar os eventos do CloudWatch Logs, escolha **Log Groups** (Grupos de logs) no painel de navegação. Os eventos estão no grupo de logs **/aws/containerinsights/*your\$1cluster\$1name*/prometheus**, no fluxo de logs *nginx-plus-prometheus-exporter*.
# Tutorial para adicionar um novo destino de extração do Prometheus: Memcached no Amazon ECS
Este tutorial fornece uma introdução prática para extrair as métricas do Prometheus de uma amostra de aplicação do Memcached em um cluster do Amazon ECS com o tipo de inicialização do EC2. O destino do exportador do Memcached Prometheus será detectado automaticamente pelo atendente do CloudWatch pela detecção de serviços baseada na definição de tarefa do ECS.
O Memcached é um sistema de cache de memória distribuída de uso geral. Geralmente é usado para acelerar sites dinâmicos orientados por banco de dados, armazenando em cache dados e objetos na RAM, a fim de reduzir o número de vezes que uma origem dos dados externa (como um banco de dados ou uma API) precisa ser lida. Para obter mais informações, consulte [O que é Memcached?](https://www.memcached.org/)
O [memchached\$1exporter](https://github.com/prometheus/memcached_exporter) (Licença Apache 2.0) é um dos exportadores oficiais do Prometheus. Por padrão, o memcache\$1exporter serve na porta 0.0.0.0:9150 em `/metrics.`
As imagens do Docker dos dois repositórios do Docker Hub a seguir são usadas neste tutorial:
+ [ Memcached](https://hub.docker.com/_/memcached?tab=description)
+ [ prom/memcached-exporter](https://hub.docker.com/r/prom/memcached-exporter/)
**Pré-requisito**
Para coletar métricas de uma amostra de workload do Prometheus para o Amazon ECS, é necessário estar executando o Container Insights no cluster. Para obter informações sobre como instalar o Container Insights, consulte [Configurar o Container Insights no Amazon ECS](deploy-container-insights-ECS.md).
**Topics**
+ [Definir as variáveis de ambiente de cluster do Amazon ECS EC2](#ContainerInsights-Prometheus-Setup-memcached-ecs-environment)
+ [Instale a amostra de workload do Memcached](#ContainerInsights-Prometheus-Setup-memcached-ecs-install-workload)
+ [Configurar o atendente do CloudWatch para extrair métricas do Memcached Prometheus](#ContainerInsights-Prometheus-Setup-memcached-ecs-agent)
+ [VIsualizar suas métricas do Memcached](#ContainerInsights-Prometheus-ECS-memcached-view)
## Definir as variáveis de ambiente de cluster do Amazon ECS EC2
**Para definir as variáveis de ambiente de cluster do Amazon ECS EC2**
1. Instale a CLI do Amazon ECS, caso ainda não tenha instalado. Para obter mais informações, consulte: [Instalar a CLI do Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ECS_CLI_installation.html).
1. Defina o novo nome do cluster do Amazon ECS e a região. Por exemplo:
```
ECS_CLUSTER_NAME=ecs-ec2-memcached-tutorial
AWS_DEFAULT_REGION=ca-central-1
```
1. (Opcional) Se ainda não tiver um cluster do Amazon ECS com o tipo de inicialização do EC2 no qual deseja instalar a amostra de workload do Memcached e o atendente do CloudWatch, você pode criar um inserindo o comando a seguir.
```
ecs-cli up --capability-iam --size 1 \
--instance-type t3.medium \
--cluster $ECS_CLUSTER_NAME \
--region $AWS_REGION
```
O resultado esperado desse comando é o seguinte:
```
WARN[0000] You will not be able to SSH into your EC2 instances without a key pair.
INFO[0000] Using recommended Amazon Linux 2 AMI with ECS Agent 1.44.4 and Docker version 19.03.6-ce
INFO[0001] Created cluster cluster=ecs-ec2-memcached-tutorial region=ca-central-1
INFO[0002] Waiting for your cluster resources to be created...
INFO[0002] Cloudformation stack status stackStatus=CREATE_IN_PROGRESS
INFO[0063] Cloudformation stack status stackStatus=CREATE_IN_PROGRESS
INFO[0124] Cloudformation stack status stackStatus=CREATE_IN_PROGRESS
VPC created: vpc-xxxxxxxxxxxxxxxxx
Security Group created: sg-xxxxxxxxxxxxxxxxx
Subnet created: subnet-xxxxxxxxxxxxxxxxx
Subnet created: subnet-xxxxxxxxxxxxxxxxx
Cluster creation succeeded.
```
## Instale a amostra de workload do Memcached
**Para instalar a amostra de workload do Memcached que expõe as métricas do Prometheus**
1. Baixe o modelo do CloudFormation do Memcached inserindo o comando a seguir.
```
curl -O https://raw.githubusercontent.com/aws-samples/amazon-cloudwatch-container-insights/latest/ecs-task-definition-templates/deployment-mode/replica-service/cwagent-prometheus/sample_traffic/memcached/memcached-traffic-sample.yaml
```
1. Defina os nomes da função do IAM a ser criada para o Memcached inserindo os seguintes comandos.
```
MEMCACHED_ECS_TASK_ROLE_NAME=memcached-prometheus-demo-ecs-task-role-name
MEMCACHED_ECS_EXECUTION_ROLE_NAME=memcached-prometheus-demo-ecs-execution-role-name
```
1. Instale a amostra de workload do Memcached inserindo o comando a seguir. Este exemplo instala a workload no modo de rede `host`.
```
MEMCACHED_ECS_NETWORK_MODE=host
aws cloudformation create-stack --stack-name Memcached-Prometheus-Demo-ECS-$ECS_CLUSTER_NAME-EC2-$MEMCACHED_ECS_NETWORK_MODE \
--template-body file://memcached-traffic-sample.yaml \
--parameters ParameterKey=ECSClusterName,ParameterValue=$ECS_CLUSTER_NAME \
ParameterKey=ECSNetworkMode,ParameterValue=$MEMCACHED_ECS_NETWORK_MODE \
ParameterKey=TaskRoleName,ParameterValue=$MEMCACHED_ECS_TASK_ROLE_NAME \
ParameterKey=ExecutionRoleName,ParameterValue=$MEMCACHED_ECS_EXECUTION_ROLE_NAME \
--capabilities CAPABILITY_NAMED_IAM \
--region $AWS_REGION
```
A pilha do CloudFormation cria quatro recursos:
+ Uma função de tarefa do ECS
+ Uma função de execução de tarefa do ECS
+ Uma definição de tarefa do Memcached
+ Um serviço do Memcached
Na definição de tarefa do Memcached, são definidos dois contêineres:
+ O contêiner primário executa uma aplicação do Memcached simples e abre a porta 11211 para acesso.
+ O outro contêiner executa o processo do exportador do Redis OSS para expor as métricas do Prometheus na porta 9150. É o contêiner a ser detectado e extraído pelo atendente do CloudWatch.
## Configurar o atendente do CloudWatch para extrair métricas do Memcached Prometheus
**Para configurar o atendente do CloudWatch para extrair métricas do Memcached Prometheus**
1. Baixe a versão mais recente do arquivo `cwagent-ecs-prometheus-metric-for-awsvpc.yaml` inserindo o comando a seguir.
```
curl -O https://raw.githubusercontent.com/aws-samples/amazon-cloudwatch-container-insights/latest/ecs-task-definition-templates/deployment-mode/replica-service/cwagent-prometheus/cloudformation-quickstart/cwagent-ecs-prometheus-metric-for-awsvpc.yaml
```
1. Abra o arquivo com um editor de textos e encontre a confguração completa do atendente do CloudWatch atrás da chave `value` da seção `resource:CWAgentConfigSSMParameter`.
Em seguida, na seção `ecs_service_discovery`, adicione a seguinte configuração na seção `task_definition_list`.
```
{
"sd_job_name": "ecs-memcached",
"sd_metrics_ports": "9150",
"sd_task_definition_arn_pattern": ".*:task-definition/memcached-prometheus-demo.*:[0-9]+"
},
```
Para a seção `metric_declaration`, a configuração padrão não permite nenhuma métrica do Memcached. Adicione a seção a seguir para permitir métricas do Memcached. Siga o padrão de recuo existente.
```
{
"source_labels": ["container_name"],
"label_matcher": "memcached-exporter-.*",
"dimensions": [["ClusterName", "TaskDefinitionFamily"]],
"metric_selectors": [
"^memcached_current_(bytes|items|connections)$",
"^memcached_items_(reclaimed|evicted)_total$",
"^memcached_(written|read)_bytes_total$",
"^memcached_limit_bytes$",
"^memcached_commands_total$"
]
},
{
"source_labels": ["container_name"],
"label_matcher": "memcached-exporter-.*",
"dimensions": [["ClusterName", "TaskDefinitionFamily","status","command"], ["ClusterName", "TaskDefinitionFamily","command"]],
"metric_selectors": [
"^memcached_commands_total$"
]
},
```
1. Se já tiver o atendente do CloudWatch implantado no cluster do Amazon ECS com o CloudFormation, é possível criar um conjunto de alterações inserindo os comandos a seguir.
```
ECS_NETWORK_MODE=bridge
CREATE_IAM_ROLES=True
ECS_TASK_ROLE_NAME=your_selected_ecs_task_role_name
ECS_EXECUTION_ROLE_NAME=your_selected_ecs_execution_role_name
aws cloudformation create-change-set --stack-name CWAgent-Prometheus-ECS-${ECS_CLUSTER_NAME}-EC2-${ECS_NETWORK_MODE} \
--template-body file://cwagent-ecs-prometheus-metric-for-bridge-host.yaml \
--parameters ParameterKey=ECSClusterName,ParameterValue=$ECS_CLUSTER_NAME \
ParameterKey=CreateIAMRoles,ParameterValue=$CREATE_IAM_ROLES \
ParameterKey=ECSNetworkMode,ParameterValue=$ECS_NETWORK_MODE \
ParameterKey=TaskRoleName,ParameterValue=$ECS_TASK_ROLE_NAME \
ParameterKey=ExecutionRoleName,ParameterValue=$ECS_EXECUTION_ROLE_NAME \
--capabilities CAPABILITY_NAMED_IAM \
--region $AWS_REGION \
--change-set-name memcached-scraping-support
```
1. Abra o console do CloudFormation em [https://console.aws.amazon.com/cloudformation](https://console.aws.amazon.com/cloudformation/).
1. Revise o changeset recém-criado `memcached-scraping-support`. Você deverá ver uma alteração aplicada ao recurso `CWAgentConfigSSMParameter`. Execute o changeset e reinicie a tarefa do atendente do CloudWatch inserindo os comandos a seguir.
```
aws ecs update-service --cluster $ECS_CLUSTER_NAME \
--desired-count 0 \
--service cwagent-prometheus-replica-service-EC2-$ECS_NETWORK_MODE \
--region $AWS_REGION
```
1. Aguarde cerca de 10 segundos e insira este comando.
```
aws ecs update-service --cluster $ECS_CLUSTER_NAME \
--desired-count 1 \
--service cwagent-prometheus-replica-service-EC2-$ECS_NETWORK_MODE \
--region $AWS_REGION
```
1. Se estiver instalando o atendente do CloudWatch com coleta de métricas do Prometheus no cluster pela primeira vez, insira estes comandos:
```
ECS_NETWORK_MODEE=bridge
CREATE_IAM_ROLES=True
ECS_TASK_ROLE_NAME=your_selected_ecs_task_role_name
ECS_EXECUTION_ROLE_NAME=your_selected_ecs_execution_role_name
aws cloudformation create-stack --stack-name CWAgent-Prometheus-ECS-${ECS_CLUSTER_NAME}-EC2-${ECS_NETWORK_MODE} \
--template-body file://cwagent-ecs-prometheus-metric-for-bridge-host.yaml \
--parameters ParameterKey=ECSClusterName,ParameterValue=$ECS_CLUSTER_NAME \
ParameterKey=CreateIAMRoles,ParameterValue=$CREATE_IAM_ROLES \
ParameterKey=ECSNetworkMode,ParameterValue=$ECS_NETWORK_MODE \
ParameterKey=TaskRoleName,ParameterValue=$ECS_TASK_ROLE_NAME \
ParameterKey=ExecutionRoleName,ParameterValue=$ECS_EXECUTION_ROLE_NAME \
--capabilities CAPABILITY_NAMED_IAM \
--region $AWS_REGION
```
## VIsualizar suas métricas do Memcached
Este tutorial envia as seguintes métricas ao namespace **ECS/ContainerInsights/Prometheus** no CloudWatch. É possível usar o console do CloudWatch para ver as métricas nesse namespace.
| Nome da métrica | Dimensões |
| --- | --- |
| `memcached_current_items` | `ClusterName`, `TaskDefinitionFamily` |
| `memcached_current_connections` | `ClusterName`, `TaskDefinitionFamily` |
| `memcached_limit_bytes` | `ClusterName`, `TaskDefinitionFamily` |
| `memcached_current_bytes` | `ClusterName`, `TaskDefinitionFamily` |
| `memcached_written_bytes_total` | `ClusterName`, `TaskDefinitionFamily` |
| `memcached_read_bytes_total` | `ClusterName`, `TaskDefinitionFamily` |
| `memcached_items_evicted_total` | `ClusterName`, `TaskDefinitionFamily` |
| `memcached_items_reclaimed_total` | `ClusterName`, `TaskDefinitionFamily` |
| `memcached_commands_total` | `ClusterName`, `TaskDefinitionFamily` `ClusterName`, TaskDefinitionFamily, comando `ClusterName`, TaskDefinitionFamily, status, comando |
**nota**
O valor da dimensão **command** pode ser: `delete`, `get`, `cas`, `set`, `decr`, `touch`, `incr` ou `flush`.
O valor da dimensão **status** pode ser `hit`, `miss` ou `badval`.
Também é possível criar um painel do CloudWatch para suas métricas do Memcached Prometheus.
**Para criar um painel para métricas do Memcached Prometheus**
1. Crie variáveis de ambiente, substituindo os valores abaixo para corresponder a sua implantação.
```
DASHBOARD_NAME=your_memcached_cw_dashboard_name
ECS_TASK_DEF_FAMILY=memcached-prometheus-demo-$ECS_CLUSTER_NAME-EC2-$MEMCACHED_ECS_NETWORK_MOD
```
1. Use o comando a seguir para criar o painel.
```
curl https://raw.githubusercontent.com/aws-samples/amazon-cloudwatch-container-insights/latest/ecs-task-definition-templates/deployment-mode/replica-service/cwagent-prometheus/sample_cloudwatch_dashboards/memcached/cw_dashboard_memcached.json \
| sed "s/{{YOUR_AWS_REGION}}/$AWS_REGION/g" \
| sed "s/{{YOUR_CLUSTER_NAME}}/$ECS_CLUSTER_NAME/g" \
| sed "s/{{YOUR_TASK_DEF_FAMILY}}/$ECS_TASK_DEF_FAMILY/g" \
| xargs -0 aws cloudwatch put-dashboard --dashboard-name ${DASHBOARD_NAME} --region $AWS_REGION --dashboard-body
```
# Tutorial para extração de métricas do Prometheus no Redis OSS no Amazon ECS Fargate
Este tutorial apresenta uma introdução prática para extrair as métricas do Prometheus de um exemplo de aplicação do Redis OSS em um cluster do Amazon ECS Fargate. O destino do exportador do Prometheus no Redis OSS será detectado automaticamente pelo agente do CloudWatch com suporte à métrica do Prometheus com base nos rótulos do Docker do contêiner.
O Redis OSS (https://redis.io/) é um armazenamento de estrutura de dados em memória com código aberto (licença BSD), usado como banco de dados, cache e agente de mensagens. Para obter mais informações, consulte [ redis](https://redis.io/).
O redis\$1exporter (licença MIT) é usado para expor as métricas do Prometheus no Redis OSS na porta especificada (padrão: 0.0.0.0:9121). Para obter mais informações, consulte [redis\$1exporter](https://github.com/oliver006/redis_exporter).
As imagens do Docker dos dois repositórios do Docker Hub a seguir são usadas neste tutorial:
+ [ redis](https://hub.docker.com/_/redis?tab=description)
+ [ redis\$1exporter](https://hub.docker.com/r/oliver006/redis_exporter)
**Pré-requisito**
Para coletar métricas de uma amostra de workload do Prometheus para o Amazon ECS, é necessário estar executando o Container Insights no cluster. Para obter informações sobre como instalar o Container Insights, consulte [Configurar o Container Insights no Amazon ECS](deploy-container-insights-ECS.md).
**Topics**
+ [Definir as variáveis de ambiente de cluster do Amazon ECS Fargate](#ContainerInsights-Prometheus-Setup-redis-ecs-variable)
+ [Definir as variáveis de ambiente de rede para o cluster do Amazon ECS Fargate](#ContainerInsights-Prometheus-Setup-redis-ecs-variable2)
+ [Instalar o exemplo de workload do Redis OSS](#ContainerInsights-Prometheus-Setup-redis-ecs-install-workload)
+ [Configurar o agente do CloudWatch para extrair métricas do Prometheus no Redis OSS](#ContainerInsights-Prometheus-Setup-redis-ecs-agent)
+ [Visualizar suas métricas do Redis OSS](#ContainerInsights-Prometheus-Setup-redis-view)
## Definir as variáveis de ambiente de cluster do Amazon ECS Fargate
**Para definir as variáveis de ambiente de cluster do Amazon ECS Fargate**
1. Instale a CLI do Amazon ECS, caso ainda não tenha instalado. Para obter mais informações, consulte: [Instalar a CLI do Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ECS_CLI_installation.html).
1. Defina o novo nome do cluster do Amazon ECS e a região. Por exemplo:
```
ECS_CLUSTER_NAME=ecs-fargate-redis-tutorial
AWS_DEFAULT_REGION=ca-central-1
```
1. (Opcional) Se ainda não tiver um cluster do Amazon ECS Fargate no qual deseja instalar o exemplo de workload do Redis OSS e o agente do CloudWatch, você pode criar um reproduzindo o comando a seguir.
```
ecs-cli up --capability-iam \
--cluster $ECS_CLUSTER_NAME \
--launch-type FARGATE \
--region $AWS_DEFAULT_REGION
```
O resultado esperado desse comando é o seguinte:
```
INFO[0000] Created cluster cluster=ecs-fargate-redis-tutorial region=ca-central-1
INFO[0001] Waiting for your cluster resources to be created...
INFO[0001] Cloudformation stack status stackStatus=CREATE_IN_PROGRESS
VPC created: vpc-xxxxxxxxxxxxxxxxx
Subnet created: subnet-xxxxxxxxxxxxxxxxx
Subnet created: subnet-xxxxxxxxxxxxxxxxx
Cluster creation succeeded.
```
## Definir as variáveis de ambiente de rede para o cluster do Amazon ECS Fargate
**Para definir as variáveis de ambiente de rede para o cluster do Amazon ECS Fargate**
1. Defina a VPC e o ID de sub-rede do cluster do Amazon ECS. Se criou um novo cluster no procedimento anterior, você verá esses valores no resultado do comando final. Senão, use os IDs do cluster existente que você usará com o Redis.
```
ECS_CLUSTER_VPC=vpc-xxxxxxxxxxxxxxxxx
ECS_CLUSTER_SUBNET_1=subnet-xxxxxxxxxxxxxxxxx
ECS_CLUSTER_SUBNET_2=subnet-xxxxxxxxxxxxxxxxx
```
1. Neste tutorial, instalaremos a aplicação Redis OSS e o agente do CloudWatch no grupo de segurança padrão da VPC do cluster do Amazon ECS. O grupo de segurança padrão permite qualquer conexão de rede no mesmo grupo de segurança para que o agente do CloudWatch possa extrair as métricas do Prometheus expostas nos contêineres do Redis OSS. Em um ambiente de produção real, convém criar grupos de segurança dedicados para a aplicação do Redis OSS e o agente do CloudWatch, além de definir permissões personalizadas para eles.
Para obter o ID do grupo de segurança padrão, insira o comando a seguir.
```
aws ec2 describe-security-groups \
--filters Name=vpc-id,Values=$ECS_CLUSTER_VPC \
--region $AWS_DEFAULT_REGION
```
Em seguida, defina a variável do grupo de segurança padrão do cluster Fargate inserindo o seguinte comando, substituindo *my-default-security-group* pelo valor que você encontrou no comando anterior.
```
ECS_CLUSTER_SECURITY_GROUP=my-default-security-group
```
## Instalar o exemplo de workload do Redis OSS
**Para instalar o exemplo de workload do Redis OSS que expõe as métricas do Prometheus**
1. Baixe o modelo do CloudFormation para Redis OSS inserindo o comando a seguir.
```
curl -O https://raw.githubusercontent.com/aws-samples/amazon-cloudwatch-container-insights/latest/ecs-task-definition-templates/deployment-mode/replica-service/cwagent-prometheus/sample_traffic/redis/redis-traffic-sample.yaml
```
1. Defina os nomes de perfil do IAM que serão criados para o Redis OSS inserindo os seguintes comandos.
```
REDIS_ECS_TASK_ROLE_NAME=redis-prometheus-demo-ecs-task-role-name
REDIS_ECS_EXECUTION_ROLE_NAME=redis-prometheus-demo-ecs-execution-role-name
```
1. Instale o exemplo de workload do Redis OSS inserindo o comando a seguir.
```
aws cloudformation create-stack --stack-name Redis-Prometheus-Demo-ECS-$ECS_CLUSTER_NAME-fargate-awsvpc \
--template-body file://redis-traffic-sample.yaml \
--parameters ParameterKey=ECSClusterName,ParameterValue=$ECS_CLUSTER_NAME \
ParameterKey=SecurityGroupID,ParameterValue=$ECS_CLUSTER_SECURITY_GROUP \
ParameterKey=SubnetID,ParameterValue=$ECS_CLUSTER_SUBNET_1 \
ParameterKey=TaskRoleName,ParameterValue=$REDIS_ECS_TASK_ROLE_NAME \
ParameterKey=ExecutionRoleName,ParameterValue=$REDIS_ECS_EXECUTION_ROLE_NAME \
--capabilities CAPABILITY_NAMED_IAM \
--region $AWS_DEFAULT_REGION
```
A pilha do CloudFormation cria quatro recursos:
+ Uma função de tarefa do ECS
+ Uma função de execução de tarefa do ECS
+ Uma definição de tarefa do Redis OSS
+ Um serviço do Redis OSS
A definição de tarefa do Redis OSS define dois contêineres:
+ O contêiner primário executa uma aplicação simples do Redis OSS e abre a porta 6379 para acesso.
+ O outro contêiner executa o processo do exportador do Redis OSS para expor as métricas do Prometheus na porta 9121. É o contêiner a ser detectado e extraído pelo atendente do CloudWatch. O rótulo do docker a seguir é definido para que o atendente do CloudWatch possa detectar esse contêiner com base nele.
```
ECS_PROMETHEUS_EXPORTER_PORT: 9121
```
## Configurar o agente do CloudWatch para extrair métricas do Prometheus no Redis OSS
**Para configurar o agente do CloudWatch para extrair métricas do Prometheus no Redis OSS**
1. Baixe a versão mais recente do arquivo `cwagent-ecs-prometheus-metric-for-awsvpc.yaml` inserindo o comando a seguir.
```
curl -O https://raw.githubusercontent.com/aws-samples/amazon-cloudwatch-container-insights/latest/ecs-task-definition-templates/deployment-mode/replica-service/cwagent-prometheus/cloudformation-quickstart/cwagent-ecs-prometheus-metric-for-awsvpc.yaml
```
1. Abra o arquivo com um editor de textos e encontre a confguração completa do atendente do CloudWatch atrás da chave `value` da seção `resource:CWAgentConfigSSMParameter`.
Em seguida, na seção `ecs_service_discovery` apresentada aqui, a descoberta de serviços baseada em `docker_label` está habilitada com as configurações padrão que são baseadas em `ECS_PROMETHEUS_EXPORTER_PORT`, que corresponde ao rótulo do Docker estabelecido na definição de tarefa do ECS para Redis OSS. Portanto, não precisamos fazer alterações nesta seção:
```
ecs_service_discovery": {
"sd_frequency": "1m",
"sd_result_file": "/tmp/cwagent_ecs_auto_sd.yaml",
* "docker_label": {
},*
...
```
Para a seção `metric_declaration`, a configuração padrão não permite nenhuma métrica do Redis OSS. Adicione a seção a seguir para permitir métricas do Redis OSS. Siga o padrão de recuo existente.
```
{
"source_labels": ["container_name"],
"label_matcher": "^redis-exporter-.*$",
"dimensions": [["ClusterName","TaskDefinitionFamily"]],
"metric_selectors": [
"^redis_net_(in|out)put_bytes_total$",
"^redis_(expired|evicted)_keys_total$",
"^redis_keyspace_(hits|misses)_total$",
"^redis_memory_used_bytes$",
"^redis_connected_clients$"
]
},
{
"source_labels": ["container_name"],
"label_matcher": "^redis-exporter-.*$",
"dimensions": [["ClusterName","TaskDefinitionFamily","cmd"]],
"metric_selectors": [
"^redis_commands_total$"
]
},
{
"source_labels": ["container_name"],
"label_matcher": "^redis-exporter-.*$",
"dimensions": [["ClusterName","TaskDefinitionFamily","db"]],
"metric_selectors": [
"^redis_db_keys$"
]
},
```
1. Se já tiver o atendente do CloudWatch implantado no cluster do Amazon ECS com o CloudFormation, é possível criar um conjunto de alterações inserindo os comandos a seguir.
```
ECS_LAUNCH_TYPE=FARGATE
CREATE_IAM_ROLES=True
ECS_CLUSTER_SUBNET=$ECS_CLUSTER_SUBNET_1
ECS_TASK_ROLE_NAME=your_selected_ecs_task_role_name
ECS_EXECUTION_ROLE_NAME=your_selected_ecs_execution_role_name
aws cloudformation create-change-set --stack-name CWAgent-Prometheus-ECS-$ECS_CLUSTER_NAME-$ECS_LAUNCH_TYPE-awsvpc \
--template-body file://cwagent-ecs-prometheus-metric-for-awsvpc.yaml \
--parameters ParameterKey=ECSClusterName,ParameterValue=$ECS_CLUSTER_NAME \
ParameterKey=CreateIAMRoles,ParameterValue=$CREATE_IAM_ROLES \
ParameterKey=ECSLaunchType,ParameterValue=$ECS_LAUNCH_TYPE \
ParameterKey=SecurityGroupID,ParameterValue=$ECS_CLUSTER_SECURITY_GROUP \
ParameterKey=SubnetID,ParameterValue=$ECS_CLUSTER_SUBNET \
ParameterKey=TaskRoleName,ParameterValue=$ECS_TASK_ROLE_NAME \
ParameterKey=ExecutionRoleName,ParameterValue=$ECS_EXECUTION_ROLE_NAME \
--capabilities CAPABILITY_NAMED_IAM \
--region ${AWS_DEFAULT_REGION} \
--change-set-name redis-scraping-support
```
1. Abra o console do CloudFormation em [https://console.aws.amazon.com/cloudformation](https://console.aws.amazon.com/cloudformation/).
1. Revise o changeset recém-criado `redis-scraping-support`. Você deverá ver uma alteração aplicada ao recurso `CWAgentConfigSSMParameter`. Execute o changeset e reinicie a tarefa do atendente do CloudWatch inserindo os comandos a seguir.
```
aws ecs update-service --cluster $ECS_CLUSTER_NAME \
--desired-count 0 \
--service cwagent-prometheus-replica-service-$ECS_LAUNCH_TYPE-awsvpc \
--region ${AWS_DEFAULT_REGION}
```
1. Aguarde cerca de 10 segundos e insira este comando.
```
aws ecs update-service --cluster $ECS_CLUSTER_NAME \
--desired-count 1 \
--service cwagent-prometheus-replica-service-$ECS_LAUNCH_TYPE-awsvpc \
--region ${AWS_DEFAULT_REGION}
```
1. Se estiver instalando o atendente do CloudWatch com coleta de métricas do Prometheus no cluster pela primeira vez, insira estes comandos:
```
ECS_LAUNCH_TYPE=FARGATE
CREATE_IAM_ROLES=True
ECS_CLUSTER_SUBNET=$ECS_CLUSTER_SUBNET_1
ECS_TASK_ROLE_NAME=your_selected_ecs_task_role_name
ECS_EXECUTION_ROLE_NAME=your_selected_ecs_execution_role_name
aws cloudformation create-stack --stack-name CWAgent-Prometheus-ECS-$ECS_CLUSTER_NAME-$ECS_LAUNCH_TYPE-awsvpc \
--template-body file://cwagent-ecs-prometheus-metric-for-awsvpc.yaml \
--parameters ParameterKey=ECSClusterName,ParameterValue=$ECS_CLUSTER_NAME \
ParameterKey=CreateIAMRoles,ParameterValue=$CREATE_IAM_ROLES \
ParameterKey=ECSLaunchType,ParameterValue=$ECS_LAUNCH_TYPE \
ParameterKey=SecurityGroupID,ParameterValue=$ECS_CLUSTER_SECURITY_GROUP \
ParameterKey=SubnetID,ParameterValue=$ECS_CLUSTER_SUBNET \
ParameterKey=TaskRoleName,ParameterValue=$ECS_TASK_ROLE_NAME \
ParameterKey=ExecutionRoleName,ParameterValue=$ECS_EXECUTION_ROLE_NAME \
--capabilities CAPABILITY_NAMED_IAM \
--region ${AWS_DEFAULT_REGION}
```
## Visualizar suas métricas do Redis OSS
Este tutorial envia as seguintes métricas ao namespace **ECS/ContainerInsights/Prometheus** no CloudWatch. É possível usar o console do CloudWatch para ver as métricas nesse namespace.
| Nome da métrica | Dimensões |
| --- | --- |
| `redis_net_input_bytes_total` | ClusterName, `TaskDefinitionFamily` |
| `redis_net_output_bytes_total` | ClusterName, `TaskDefinitionFamily` |
| `redis_expired_keys_total` | ClusterName, `TaskDefinitionFamily` |
| `redis_evicted_keys_total` | ClusterName, `TaskDefinitionFamily` |
| `redis_keyspace_hits_total` | ClusterName, `TaskDefinitionFamily` |
| `redis_keyspace_misses_total` | ClusterName, `TaskDefinitionFamily` |
| `redis_memory_used_bytes` | ClusterName, `TaskDefinitionFamily` |
| `redis_connected_clients` | ClusterName, `TaskDefinitionFamily` |
| `redis_commands_total` | ` ClusterName`, `TaskDefinitionFamily`, `cmd` |
| `redis_db_keys` | `ClusterName`, `TaskDefinitionFamily`, `db` |
**nota**
O valor da dimensão **cmd** pode ser: `append`, `client`, `command`, `config`, `dbsize`, `flushall`, `get`, `incr`, `info`, `latency` ou `slowlog`.
Os valores da dimensão **db** podem ser `db0` ou `db15`.
Também é possível criar um painel do CloudWatch para suas métricas do Prometheus no Redis OSS.
**Para criar um painel para métricas do Prometheus no Redis OSS**
1. Crie variáveis de ambiente, substituindo os valores abaixo para corresponder a sua implantação.
```
DASHBOARD_NAME=your_cw_dashboard_name
ECS_TASK_DEF_FAMILY=redis-prometheus-demo-$ECS_CLUSTER_NAME-fargate-awsvpc
```
1. Use o comando a seguir para criar o painel.
```
curl https://raw.githubusercontent.com/aws-samples/amazon-cloudwatch-container-insights/latest/k8s-deployment-manifest-templates/deployment-mode/service/cwagent-prometheus/sample_cloudwatch_dashboards/redis/cw_dashboard_redis.json \
| sed "s/{{YOUR_AWS_REGION}}/${REGION_NAME}/g" \
| sed "s/{{YOUR_CLUSTER_NAME}}/${CLUSTER_NAME}/g" \
| sed "s/{{YOUR_NAMESPACE}}/${NAMESPACE}/g" \
```
# Instalar e configurar a coleta de métricas do Prometheus em clusters do Amazon EKS e do Kubernetes
Para coletar métricas do Prometheus de clusters que executam o Amazon EKS ou Kubernetes, é possível usar o atendente do CloudWatch como coletor ou usar o coletor do AWS Distro for OpenTelemetry. Para obter informações sobre como usar o coletor do AWS Distro for OpenTelemetry, consulte [https://aws-otel.github.io/docs/getting-started/container-insights/eks-prometheus](https://aws-otel.github.io/docs/getting-started/container-insights/eks-prometheus).
As seções a seguir explicam como coletar métricas do Prometheus usando o atendente do CloudWatch. Elas explicam como instalar o atendente do CloudWatch com o monitoramento do Prometheus em clusters que executam o Amazon EKS e o Kubernetes e como configurar o atendente para extrair outros destinos. Estas seções também fornecem tutoriais opcionais para configurar amostras de workloads para usar testes com monitoramento do Prometheus.
**Topics**
+ [Instalar o atendente do CloudWatch com a coleção de métricas do Prometheus em clusters do Amazon EKS e do Kubernetes](ContainerInsights-Prometheus-Setup.md)
# Instalar o atendente do CloudWatch com a coleção de métricas do Prometheus em clusters do Amazon EKS e do Kubernetes
Esta seção explica como configurar o atendente do CloudWatch com monitoramento do Prometheus em um cluster que está executando o Amazon EKS ou o Kubernetes. Depois que você fizer isso, o atendente automaticamente extrairá e importará métricas para as seguintes workloads em execução nesse cluster.
+ AWS App Mesh
+ NGINX
+ Memcached
+ Java/JMX
+ HAProxy
+ Fluent Bit
Também é possível configurar o atendente para extrair e importar outras workloads e origens do Prometheus.
Antes de seguir estas etapas de instalação do atendente do CloudWatch para coleta de métricas do Prometheus, você deve ter um cluster em execução no Amazon EKS ou um cluster do Kubernetes em execução em uma instância do Amazon EC2.
**Requisitos para grupo de segurança de VPC**
As regras de entrada dos grupos de segurança para as workloads do Prometheus devem abrir as portas do Prometheus para o atendente do CloudWatch para extrair as métricas Prometheus pelo IP privado.
As regras de saída do grupo de segurança do atendente do CloudWatch devem permitir que o atendente do CloudWatch se conecte à porta das workloads do Prometheus por IP privado.
**Topics**
+ [Instalar o atendente do CloudWatch com a coleção de métricas do Prometheus em clusters do Amazon EKS e do Kubernetes](#ContainerInsights-Prometheus-Setup-roles)
+ [Extrair outras fontes do Prometheus e importar essas métricas](ContainerInsights-Prometheus-Setup-configure.md)
+ [(Opcional) Configurar workloads de exemplo do Amazon EKS em contêineres para teste de métrica do Prometheus](ContainerInsights-Prometheus-Sample-Workloads.md)
## Instalar o atendente do CloudWatch com a coleção de métricas do Prometheus em clusters do Amazon EKS e do Kubernetes
Esta seção explica como configurar o atendente do CloudWatch com monitoramento do Prometheus em um cluster que está executando o Amazon EKS ou o Kubernetes. Depois que você fizer isso, o atendente automaticamente extrairá e importará métricas para as seguintes workloads em execução nesse cluster.
+ AWS App Mesh
+ NGINX
+ Memcached
+ Java/JMX
+ HAProxy
+ Fluent Bit
Também é possível configurar o atendente para extrair e importar outras workloads e origens do Prometheus.
Antes de seguir estas etapas de instalação do atendente do CloudWatch para coleta de métricas do Prometheus, você deve ter um cluster em execução no Amazon EKS ou um cluster do Kubernetes em execução em uma instância do Amazon EC2.
**Requisitos para grupo de segurança de VPC**
As regras de entrada dos grupos de segurança para as workloads do Prometheus devem abrir as portas do Prometheus para o atendente do CloudWatch para extrair as métricas Prometheus pelo IP privado.
As regras de saída do grupo de segurança do atendente do CloudWatch devem permitir que o atendente do CloudWatch se conecte à porta das workloads do Prometheus por IP privado.
**Topics**
+ [Configurar funções do IAM](#ContainerInsights-Prometheus-Setup-roles)
+ [Instalar o atendente do CloudWatch para coletar métricas do Prometheus](#ContainerInsights-Prometheus-Setup-install-agent)
### Configurar funções do IAM
A primeira etapa é configurar a função do IAM necessária no cluster. Há dois métodos:
+ Configurar uma função do IAM para uma conta de serviço, também conhecida como *função de serviço*. Esse método funciona tanto para o tipo de inicialização do EC2 como para o tipo de inicialização do Fargate.
+ Adicione uma política do IAM à função do IAM usada para o cluster. Isso funciona apenas para o tipo de inicialização do EC2.
**Configurar uma função de serviço (tipo de inicialização do EC2 e tipo de inicialização do Fargate)**
Para configurar uma função de serviço, insira o comando a seguir. Substitua *MyCluster* pelo nome do cluster.
```
eksctl create iamserviceaccount \
--name cwagent-prometheus \
--namespace amazon-cloudwatch \
--cluster MyCluster \
--attach-policy-arn arn:aws:iam::aws:policy/CloudWatchAgentServerPolicy \
--approve \
--override-existing-serviceaccounts
```
**Adicionar uma política ao perfil do IAM do grupo de nós (apenas o tipo de inicialização do EC2)**
**Para configurar a política do IAM em um grupo de nós para compatibilidade com o Prometheus**
1. Abra o console do Amazon EC2 em [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/).
1. No painel de navegação, escolha **Instances (Instâncias)**.
1. Você precisa encontrar o prefixo do nome da função do IAM para o cluster. Para fazer isso, marque a caixa de seleção ao lado do nome de uma instância que está no cluster e escolha **Ações**, **Segurança**, **Modificar perfil do IAM**. Copie o prefixo da função do IAM, como `eksctl-dev303-workshop-nodegroup`.
1. Abra o console do IAM em [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/).
1. No painel de navegação, escolha **Perfis**.
1. Use a caixa de pesquisa para localizar o prefixo copiado anteriormente neste procedimento e escolha a função.
1. Escolha **Anexar políticas**.
1. Use a caixa de pesquisa para localizar o **CloudWatchAgentServerPolicy**. Marque a caixa de seleção ao lado de **CloudWatchAgentServerPolicy** e escolha **Attach policy (Anexar política)**.
### Instalar o atendente do CloudWatch para coletar métricas do Prometheus
Você deve instalar o atendente do CloudWatch no cluster para coletar as métricas. O método de instalação do atendente é diferente para clusters do Amazon EKS e clusters do Kubernetes.
**Excluir versões anteriores do atendente do CloudWatch compatíveis com Prometheus**
Se você já instalou em seu cluster uma versão do atendente do CloudWatch com suporte ao Prometheus, exclua essa versão inserindo o comando a seguir. Isso é necessário apenas para versões anteriores do atendente com suporte ao Prometheus. Não é necessário excluir o atendente do CloudWatch que habilita o Container Insights sem suporte ao Prometheus.
```
kubectl delete deployment cwagent-prometheus -n amazon-cloudwatch
```
#### Instalar o atendente CloudWatch em clusters do Amazon EKS com o tipo de inicialização do EC2
Para instalar o atendente do CloudWatch com suporte ao Prometheus em um cluster do Amazon EKS, siga estas etapas.
**Para instalar o atendente do CloudWatch com suporte ao Prometheus em um cluster do Amazon EKS**
1. Insira o comando a seguir para verificar se o namespace `amazon-cloudwatch` já foi criado:
```
kubectl get namespace
```
1. Se `amazon-cloudwatch` não for exibido nos resultados, crie-o inserindo o comando a seguir:
```
kubectl create namespace amazon-cloudwatch
```
1. Para implantar o atendente com a configuração padrão e fazer com que ele envie dados para a região da AWS em que está instalado, insira o comando a seguir:
```
kubectl apply -f https://raw.githubusercontent.com/aws-samples/amazon-cloudwatch-container-insights/latest/k8s-deployment-manifest-templates/deployment-mode/service/cwagent-prometheus/prometheus-eks.yaml
```
Em vez disso, para que o atendente envie dados para uma região diferente, siga estas etapas:
1. Faça download do arquivo YAML para o atendente inserindo o comando a seguir:
```
curl -O https://raw.githubusercontent.com/aws-samples/amazon-cloudwatch-container-insights/latest/k8s-deployment-manifest-templates/deployment-mode/service/cwagent-prometheus/prometheus-eks.yaml
```
1. Abra o arquivo com um editor de textos e procure o bloco `cwagentconfig.json` do arquivo.
1. Adicione as linhas realçadas, especificando a região desejada:
```
cwagentconfig.json: |
{
"agent": {
"region": "us-east-2"
},
"logs": { ...
```
1. Salve o arquivo e implante o atendente usando o arquivo atualizado.
```
kubectl apply -f prometheus-eks.yaml
```
#### Instalar o atendente CloudWatch em clusters do Amazon EKS com o tipo de inicialização do Fargate
Para instalar o atendente do CloudWatch com suporte ao Prometheus em um cluster do Amazon EKS com tipo de inicialização do Fargate, siga estas etapas.
**Para instalar o atendente do CloudWatch com suporte ao Prometheus em um cluster do Amazon EKS com tipo de inicialização do Fargate**
1. Insira o comando a seguir para criar um perfil Fargate para o atendente do CloudWatch de modo que ele possa ser executado dentro do cluster. Substitua *MyCluster* pelo nome do cluster.
```
eksctl create fargateprofile --cluster MyCluster \
--name amazon-cloudwatch \
--namespace amazon-cloudwatch
```
1. Para instalar o atendente do CloudWatch, insira o comando a seguir. Substitua *MyCluster* pelo nome do cluster. Esse nome é usado no nome do grupo de logs que armazena os eventos de log coletados pelo atendente, além de ser usado como uma dimensão para as métricas coletadas pelo atendente.
Substitua a *region* pelo nome da região para onde você deseja que as métricas sejam enviadas. Por exemplo, `us-west-1`.
```
curl https://raw.githubusercontent.com/aws-samples/amazon-cloudwatch-container-insights/latest/k8s-deployment-manifest-templates/deployment-mode/service/cwagent-prometheus/prometheus-eks-fargate.yaml |
sed "s/{{cluster_name}}/MyCluster/;s/{{region_name}}/region/" |
kubectl apply -f -
```
#### Instalar o atendente do CloudWatch em um cluster do Kubernetes
Para instalar o atendente do CloudWatch com suporte ao Prometheus em um cluster do Kubernetes em execução, insira o comando a seguir:
```
curl https://raw.githubusercontent.com/aws-samples/amazon-cloudwatch-container-insights/latest/k8s-deployment-manifest-templates/deployment-mode/service/cwagent-prometheus/prometheus-k8s.yaml |
sed "s/{{cluster_name}}/MyCluster/;s/{{region_name}}/region/" |
kubectl apply -f -
```
Substitua *MyCluster* pelo nome do cluster. Esse nome é usado no nome do grupo de logs que armazena os eventos de log coletados pelo atendente, além de ser usado como uma dimensão para as métricas coletadas pelo atendente.
Substitua a *região* pelo nome da região da AWS para onde você deseja que as métricas sejam enviadas. Por exemplo, **us-west-1**.
#### Verificar se o atendente está em execução
Nos clusters do Amazon EKS e do Kubernetes, você pode inserir o seguinte comando para confirmar se o atendente está em execução.
```
kubectl get pod -l "app=cwagent-prometheus" -n amazon-cloudwatch
```
Se os resultados incluírem um único pod de atendente do CloudWatch no estado `Running`, o atendente está em execução e coletando métricas do Prometheus. Por padrão, o atendente do CloudWatch coleta métricas para App Mesh, NGINX, Memcached, Java/JMX e HAProxy a cada minuto. Para obter mais informações sobre essas métricas, consulte [Métricas do Prometheus coletadas pelo atendente do CloudWatch](ContainerInsights-Prometheus-metrics.md). Para obter instruções sobre como ver as métricas do Prometheus no CloudWatch, consulte [Visualizar as métricas do Prometheus](ContainerInsights-Prometheus-viewmetrics.md)
Você também pode configurar o atendente do CloudWatch para coletar métricas de outros exportadores do Prometheus. Para obter mais informações, consulte [Extrair outras fontes do Prometheus e importar essas métricas](ContainerInsights-Prometheus-Setup-configure.md).
# Extrair outras fontes do Prometheus e importar essas métricas
O atendente do CloudWatch com monitoramento Prometheus precisa de duas configurações para extrair as métricas do Prometheus. Uma serve para as configurações padrão do Prometheus, conforme documentado em [](https://prometheus.io/docs/prometheus/latest/configuration/configuration/#scrape_config) na documentação do Prometheus. A outra é para a configuração do atendente do CloudWatch.
Para clusters do Amazon EKS, as configurações são definidas em`prometheus-eks.yaml` (para o tipo de inicialização EC2) ou `prometheus-eks-fargate.yaml` (para o tipo de inicialização do Fargate) como dois mapas de configuração:
+ A seção `name: prometheus-config` contém as configurações para extração de conteúdo do Prometheus.
+ A seção `name: prometheus-cwagentconfig` contém a configuração para o atendente do CloudWatch. Você pode usar esta seção para configurar como as métricas do Prometheus são coletadas pelo CloudWatch. Por exemplo, você pode especificar quais métricas devem ser importadas ao CloudWatch e definir suas dimensões.
Para clusters do Kubernetes em execução em instâncias do Amazon EC2, as configurações são definidas no arquivo YAML `prometheus-k8s.yaml` como dois mapas de configuração:
+ A seção `name: prometheus-config` contém as configurações para extração de conteúdo do Prometheus.
+ A seção `name: prometheus-cwagentconfig` contém a configuração para o atendente do CloudWatch.
Para extrair outras origens de métricas do Prometheus e importar essas métricas para o CloudWatch, modifique a configuração de extração do Prometheus e a configuração do atendente do CloudWatch e implante novamente o atendente com a configuração atualizada.
**Requisitos para grupo de segurança de VPC**
As regras de entrada dos grupos de segurança para as workloads do Prometheus devem abrir as portas do Prometheus para o atendente do CloudWatch para extrair as métricas Prometheus pelo IP privado.
As regras de saída do grupo de segurança do atendente do CloudWatch devem permitir que o atendente do CloudWatch se conecte à porta das workloads do Prometheus por IP privado.
## Configuração de extração do Prometheus
O atendente do CloudWatch oferece suporte às configurações de extração padrão do Prometheus, conforme documentado em [ ](https://prometheus.io/docs/prometheus/latest/configuration/configuration/#scrape_config) na documentação do Prometheus. É possível editar essa seção para atualizar as configurações que já estão nesse arquivo e adicionar outros destinos de extração do Prometheus. Por padrão, um exemplo de arquivo de configuração contém as seguintes linhas de configuração global:
```
global:
scrape_interval: 1m
scrape_timeout: 10s
```
+ **scrape\$1interval**: define a frequência da adição de destinos de extração de conteúdo.
+ **scrape\$1timeout**: define quanto tempo aguardar até a expiração de uma solicitação de extração de conteúdo.
Também é possível definir valores diferentes para essas configurações no nível do trabalho, a fim de substituir as configurações globais.
### Trabalhos de extração do Prometheus
Os arquivos YAML do atendente do CloudWatch já têm alguns trabalhos padrão de extração configurados. Por exemplo, em `prometheus-eks.yaml`, os trabalhos de extração padrão são configurados nas linhas `job_name` da seção `scrape_configs`. Nesse arquivo, a seguinte seção padrão `kubernetes-pod-jmx` extrai métricas do JMX Exporter.
```
- job_name: 'kubernetes-pod-jmx'
sample_limit: 10000
metrics_path: /metrics
kubernetes_sd_configs:
- role: pod
relabel_configs:
- source_labels: [__address__]
action: keep
regex: '.*:9404$'
- action: labelmap
regex: __meta_kubernetes_pod_label_(.+)
- action: replace
source_labels:
- __meta_kubernetes_namespace
target_label: Namespace
- source_labels: [__meta_kubernetes_pod_name]
action: replace
target_label: pod_name
- action: replace
source_labels:
- __meta_kubernetes_pod_container_name
target_label: container_name
- action: replace
source_labels:
- __meta_kubernetes_pod_controller_name
target_label: pod_controller_name
- action: replace
source_labels:
- __meta_kubernetes_pod_controller_kind
target_label: pod_controller_kind
- action: replace
source_labels:
- __meta_kubernetes_pod_phase
target_label: pod_phase
```
Cada um desses destinos padrão é extraído e as métricas são enviadas ao CloudWatch em eventos de log usando o formato de métricas incorporado. Para obter mais informações, consulte [Incorporação de métricas em logs](CloudWatch_Embedded_Metric_Format.md).
Os eventos de log dos clusters do Amazon EKS e do Kubernetes são armazenados no grupo de logs **/aws/containerinsights/*cluster\$1name*/prometheus** no CloudWatch Logs. Os eventos de log dos clusters do Amazon ECS são armazenados no grupo de logs **/aws/ecs/containerinsights/*cluster\$1name*/prometheus**.
Cada trabalho de extração está contido em um fluxo de logs diferente nesse grupo de logs. Por exemplo, o trabalho de extração do Prometheus `kubernetes-pod-appmesh-envoy` é definido para o App Mesh. Todas as métricas do App Mesh Prometheus de clusters do Amazon EKS e do Kubernetes são enviadas ao fluxo de logs chamado **/aws/containerinsights/*cluster\$1name*>prometheus/kubernetes-pod-appmesh-envoy/**.
Para adicionar um novo destino de extração, adicione uma nova seção `job_name` à seção `scrape_configs` do arquivo YAML e reinicie o atendente. Para obter um exemplo desse processo, consulte [Tutorial para adicionar um novo destino de extração do Prometheus: métricas do servidor de API do Prometheus](#ContainerInsights-Prometheus-Setup-new-exporters).
## Configuração do atendente do CloudWatch para o Prometheus
O arquivo de configuração do atendente do CloudWatch tem uma seção `prometheus` na seção `metrics_collected` para a configuração de extração do Prometheus. Contém as seguintes opções de configuração:
+ **cluster\$1name**: especifica o nome do cluster a ser adicionado como um rótulo no evento de log. Esse campo é opcional. Se você omitir, o atendente poderá detectar o nome do cluster do Amazon EKS ou do Kubernetes.
+ **log\$1group\$1name**: especifica o nome do grupo de log para as métricas do Prometheus extraídas. Esse campo é opcional. Se você omitir, o CloudWatch usará **/aws/containerinsights/*cluster\$1name*/prometheus** para logs de clusters do Amazon EKS e do Kubernetes.
+ **prometheus\$1config\$1path**: especifica o caminho do arquivo de configuração de extração do Prometheus. Se o valor desse campo começar com `env:`, o conteúdo do arquivo de configuração de extração do Prometheus será recuperado da variável de ambiente do contêiner. Não altere esse campo.
+ **ecs\$1service\$1discovery**: é a seção para especificar a configuração da detecção de serviço do Amazon ECS Prometheus. Para obter mais informações, consulte [Guia detalhado para detecção automática em clusters do Amazon ECS](ContainerInsights-Prometheus-Setup-autodiscovery-ecs.md).
A seção `ecs_service_discovery` pode conter os seguintes campos:
+ `sd_frequency` é a frequência para detectar os exportadores Prometheus. Especifique um número e um sufixo de unidade. Por exemplo, `1m` uma vez por minuto ou `30s` uma vez a cada 30 segundos. Os sufixos de unidade válidos são: `ns`, `us`, `ms`, `s`, `m` e `h`.
Esse campo é opcional. O padrão é 60 segundos (1 minuto).
+ `sd_target_cluster` é o nome do cluster do Amazon ECS de destino para detecção automática. Esse campo é opcional. O padrão é o nome do cluster do Amazon ECS em que o atendente do CloudWatch está instalado.
+ `sd_cluster_region` é a região do cluster do Amazon ECS de destino. Esse campo é opcional. O padrão é a região do cluster do Amazon ECS em que o atendente do CloudWatch está instalado.
+ `sd_result_file` é o caminho do arquivo YAML para os resultados de destino do Prometheus. A configuração de extração do Prometheus referenciará esse arquivo.
+ `docker_label` é uma seção opcional que você pode usar para especificar a configuração para detecção de serviço baseada em rótulos do docker. Se você omitir essa seção, a detecção baseada em rótulos do docker não será usada. A seção pode conter os seguintes campos:
+ `sd_port_label` é o nome do rótulo do docker do contêiner que especifica a porta do contêiner para métricas do Prometheus. O valor padrão é `ECS_PROMETHEUS_EXPORTER_PORT`. Se o contêiner não tiver esse rótulo do docker, o atendente do CloudWatch o ignorará.
+ `sd_metrics_path_label` é o nome do rótulo do docker do contêiner que especifica o caminho das métricas do Prometheus. O valor padrão é `ECS_PROMETHEUS_METRICS_PATH`. Se o contêiner não tiver esse rótulo do docker, o agente assumirá o caminho padrão `/metrics`.
+ `sd_job_name_label` é o nome do rótulo do docker do contêiner que especifica o nome do trabalho de extração do Prometheus. O valor padrão é `job`. Se o contêiner não tiver esse rótulo do docker, o atendente do CloudWatch usará o nome do trabalho na configuração de extração do Prometheus.
+ `task_definition_list` é uma seção opcional que você pode usar para especificar a configuração para detectção de serviço baseada em definição de tarefa. Se você omitir essa seção, a detecção baseada em definição de tarefa não será usada. A seção pode conter os seguintes campos:
+ `sd_task_definition_arn_pattern` é o padrão a ser usado para especificar as definições de tarefa do Amazon ECS a serem detectadas. Essa é uma expressão regular.
+ `sd_metrics_ports` lista a containerPort para as métricas do Prometheus. Separe as containerPorts com ponto e vírgula.
+ `sd_container_name_pattern` especifica os nomes de contêiner de tarefas do Amazon ECS. Essa é uma expressão regular.
+ `sd_metrics_path` especifica o caminho da métrica do Prometheus. Se você omitir isso, o atendente assumirá o caminho padrão `/metrics`
+ `sd_job_name` especifica o nome do trabalho de extração do Prometheus. Se você omitir esse campo, o atendente do CloudWatch usará o nome do trabalho na configuração de extração do Prometheus.
+ **metric\$1declaration**: são seções que especificam a matriz de logs com formato de métrica incorporado a ser gerada. Há seções `metric_declaration` para cada destino do Prometheus do qual o atendente do CloudWatch importa por padrão. Essas seções incluem os seguintes campos:
+ `label_matcher` é uma expressão regular que confere o valor dos rótulos listados em `source_labels`. As métricas correspondentes são disponibilizadas para inclusão no formato de métrica incorporado enviado ao CloudWatch.
Se você tiver vários rótulos especificados em `source_labels`, recomendamos não utilizar os caracteres `^` ou `$` na expressão regular para `label_matcher`.
+ `source_labels` especifica o valor dos rótulos verificados pela linha `label_matcher`.
+ `label_separator` especifica o separador a ser usado na linha ` label_matcher` se vários `source_labels` forem especificados. O padrão é `;`. É possível ver esse padrão usado na linha `label_matcher` no exemplo a seguir.
+ `metric_selectors` é uma expressão regular que especifica as métricas a serem coletadas e enviadas ao CloudWatch.
+ `dimensions` é a lista de rótulos a serem usados como dimensões do CloudWatch para cada métrica selecionada.
Veja o exemplo de `metric_declaration` a seguir.
```
"metric_declaration": [
{
"source_labels":[ "Service", "Namespace"],
"label_matcher":"(.*node-exporter.*|.*kube-dns.*);kube-system",
"dimensions":[
["Service", "Namespace"]
],
"metric_selectors":[
"^coredns_dns_request_type_count_total$"
]
}
]
```
Esse exemplo configura uma seção de formato de métrica incorporada a ser enviada como um evento de log se as seguintes condições forem atendidas:
+ O valor de `Service` contém `node-exporter` ou `kube-dns`.
+ O valor de `Namespace` é `kube-system`.
+ A métrica do Prometheus `coredns_dns_request_type_count_total` contém rótulos `Service` e `Namespace`.
O evento de log enviado inclui a seguinte seção destacada:
```
{
"CloudWatchMetrics":[
{
"Metrics":[
{
"Name":"coredns_dns_request_type_count_total"
}
],
"Dimensions":[
[
"Namespace",
"Service"
]
],
"Namespace":"ContainerInsights/Prometheus"
}
],
"Namespace":"kube-system",
"Service":"kube-dns",
"coredns_dns_request_type_count_total":2562,
"eks_amazonaws_com_component":"kube-dns",
"instance":"192.168.61.254:9153",
"job":"kubernetes-service-endpoints",
...
}
```
## Tutorial para adicionar um novo destino de extração do Prometheus: métricas do servidor de API do Prometheus
O servidor de API do Kubernetes expõe métricas do Prometheus em endpoints por padrão. O exemplo oficial da configuração de extração do servidor de API do Kubernetes está disponível no [Github](https://github.com/prometheus/prometheus/blob/main/documentation/examples/prometheus-kubernetes.yml).
O tutorial a seguir mostra como executar as seguintes etapas para começar a importar métricas do servidor de API do Kubernetes para o CloudWatch:
+ Como adicionar a configuração de extração do Prometheus para o servidor de API do Kubernetes ao arquivo YAML do atendente do CloudWatch.
+ Como configurar as definições de métricas em formato de métrica incorporada no arquivo YAML do atendente do CloudWatch.
+ (Opcional) Como criar um painel do CloudWatch para as métricas do servidor de API do Kubernetes.
**nota**
O servidor de API do Kubernetes expõe métricas de indicador, contador, histograma e resumo. Nesta versão do suporte a métricas do Prometheus, o CloudWatch importa apenas as métricas com tipos de indicador e contador.
**Como começar a coletar métricas do servidor de API do Kubernetes do Prometheus no CloudWatch**
1. Baixe a versão mais recente do arquivo `prometheus-eks.yaml`, `prometheus-eks-fargate.yaml` ou `prometheus-k8s.yaml` inserindo um dos comandos a seguir.
Para um cluster do Amazon EKS com o tipo de inicialização do EC2, insira o comando a seguir:
```
curl -O https://raw.githubusercontent.com/aws-samples/amazon-cloudwatch-container-insights/latest/k8s-deployment-manifest-templates/deployment-mode/service/cwagent-prometheus/prometheus-eks.yaml
```
Para um cluster do Amazon EKS com o tipo de inicialização do Fargate, insira o comando a seguir:
```
curl -O https://raw.githubusercontent.com/aws-samples/amazon-cloudwatch-container-insights/latest/k8s-deployment-manifest-templates/deployment-mode/service/cwagent-prometheus/prometheus-eks-fargate.yaml
```
Para um cluster do Kubernetes em execução em uma instância do Amazon EC2, insira o comando a seguir:
```
curl -O https://raw.githubusercontent.com/aws-samples/amazon-cloudwatch-container-insights/latest/k8s-deployment-manifest-templates/deployment-mode/service/cwagent-prometheus/prometheus-k8s.yaml
```
1. Abra o arquivo com um editor de texto, localize a seção `prometheus-config` e adicione a seção a seguir nela. Salve as alterações:
```
# Scrape config for API servers
- job_name: 'kubernetes-apiservers'
kubernetes_sd_configs:
- role: endpoints
namespaces:
names:
- default
scheme: https
tls_config:
ca_file: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt
insecure_skip_verify: true
bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token
relabel_configs:
- source_labels: [__meta_kubernetes_service_name, __meta_kubernetes_endpoint_port_name]
action: keep
regex: kubernetes;https
- action: replace
source_labels:
- __meta_kubernetes_namespace
target_label: Namespace
- action: replace
source_labels:
- __meta_kubernetes_service_name
target_label: Service
```
1. Enquanto o arquivo YAML ainda está aberto no editor de texto, encontre a seção `cwagentconfig.json`. Adicione a seguinte subseção e salve as alterações. Esta seção coloca as métricas do servidor de API na lista de permissões do atendente do CloudWatch. Três tipos de métricas do servidor de API são adicionados à lista de permissões:
+ contagens de objetos etcd
+ Métricas do controlador de registro do servidor de API
+ Métricas de solicitação do servidor de API
```
{"source_labels": ["job", "resource"],
"label_matcher": "^kubernetes-apiservers;(services|daemonsets.apps|deployments.apps|configmaps|endpoints|secrets|serviceaccounts|replicasets.apps)",
"dimensions": [["ClusterName","Service","resource"]],
"metric_selectors": [
"^etcd_object_counts$"
]
},
{"source_labels": ["job", "name"],
"label_matcher": "^kubernetes-apiservers;APIServiceRegistrationController$",
"dimensions": [["ClusterName","Service","name"]],
"metric_selectors": [
"^workqueue_depth$",
"^workqueue_adds_total$",
"^workqueue_retries_total$"
]
},
{"source_labels": ["job","code"],
"label_matcher": "^kubernetes-apiservers;2[0-9]{2}$",
"dimensions": [["ClusterName","Service","code"]],
"metric_selectors": [
"^apiserver_request_total$"
]
},
{"source_labels": ["job"],
"label_matcher": "^kubernetes-apiservers",
"dimensions": [["ClusterName","Service"]],
"metric_selectors": [
"^apiserver_request_total$"
]
},
```
1. Se você já tem o atendente do CloudWatch com suporte ao Prometheus implantado no cluster, exclua-o inserindo o comando a seguir:
```
kubectl delete deployment cwagent-prometheus -n amazon-cloudwatch
```
1. Implante o atendente do CloudWatch com a configuração atualizada inserindo um dos comandos a seguir. Para um cluster do Amazon EKS com o tipo de inicialização do EC2, insira:
```
kubectl apply -f prometheus-eks.yaml
```
Para um cluster do Amazon EKS com o tipo de inicialização do Fargate, insira o comando a seguir. Substitua *MyCluster* e *region* com valores para corresponder a sua implantação.
```
cat prometheus-eks-fargate.yaml \
| sed "s/{{cluster_name}}/MyCluster/;s/{{region_name}}/region/" \
| kubectl apply -f -
```
Para um cluster do Kubernetes, insira o comando a seguir. Substitua *MyCluster* e *region* com valores para corresponder a sua implantação.
```
cat prometheus-k8s.yaml \
| sed "s/{{cluster_name}}/MyCluster/;s/{{region_name}}/region/" \
| kubectl apply -f -
```
Uma vez feito isso, será necessário ver um novo stream de log chamado ** kubernetes-apiservers ** no grupo de log **/aws/containerinsights/*cluster\$1name*/prometheus**. Esse fluxo de logs deve incluir eventos de log com uma definição de formato de métrica incorporada como a seguinte:
```
{
"CloudWatchMetrics":[
{
"Metrics":[
{
"Name":"apiserver_request_total"
}
],
"Dimensions":[
[
"ClusterName",
"Service"
]
],
"Namespace":"ContainerInsights/Prometheus"
}
],
"ClusterName":"my-cluster-name",
"Namespace":"default",
"Service":"kubernetes",
"Timestamp":"1592267020339",
"Version":"0",
"apiserver_request_count":0,
"apiserver_request_total":0,
"code":"0",
"component":"apiserver",
"contentType":"application/json",
"instance":"192.0.2.0:443",
"job":"kubernetes-apiservers",
"prom_metric_type":"counter",
"resource":"pods",
"scope":"namespace",
"verb":"WATCH",
"version":"v1"
}
```
Você pode visualizar suas métricas no console do CloudWatch no namespace **ContainerInsights/Prometheus**. Também é possível criar um painel do CloudWatch para as métricas do servidor de API do Kubernetes do Prometheus.
### (Opcional) Criar um painel para as métricas do servidor de API do Kubernetes
Para ver as métricas do servidor de API do Kubernetes em seu painel, é necessário ter concluído primeiro as etapas nas seções anteriores para começar a coletar essas métricas no CloudWatch.
**Como criar um painel para métricas do servidor de API do Kubernetes**
1. Abra o console do CloudWatch, em [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).
1. Verifique se você selecionou a região da AWS correta.
1. No painel de navegação, escolha **Painéis**.
1. Escolha **Create dashboard (Criar painel)**. Insira um nome para o novo painel e escolha **Create dashboard (Criar painel)**.
1. Em **Add to this dashboard (Adicionar a este painel)**, escolha **Cancel (Cancelar)**.
1. Escolha **Actions (Ações)**, **View/edit source (Exibir/editar origem)**.
1. Faça o download do seguinte arquivo JSON: [Origem do painel da API do Kubernetes](https://raw.githubusercontent.com/aws-samples/amazon-cloudwatch-container-insights/latest/k8s-deployment-manifest-templates/deployment-mode/service/cwagent-prometheus/sample_cloudwatch_dashboards/kubernetes_api_server/cw_dashboard_kubernetes_api_server.json).
1. Abra o arquivo JSON obtido por download com um editor de textos e faça as seguintes alterações:
+ Substitua todas as strings `{{YOUR_CLUSTER_NAME}}` pelo nome exato do cluster. Não adicione espaços em branco antes ou depois do texto.
+ Substitua todas as strings `{{YOUR_AWS_REGION}}` pelo nome da região onde as métricas são coletadas. Por exemplo, `us-west-2`. Não adicione espaços em branco antes ou depois do texto.
1. Copie todo o blob JSON e cole-o na caixa de texto no console do CloudWatch, substituindo o que já está na caixa.
1. Escolha **Update (Atualizar)**, **Save dashboard (Salvar painel)**.
# (Opcional) Configurar workloads de exemplo do Amazon EKS em contêineres para teste de métrica do Prometheus
Para testar o suporte para métricas do Prometheus no CloudWatch Container Insights, você pode configurar uma ou mais das seguintes workloads em contêineres. O atendente do CloudWatch com suporte ao Prometheus coleta automaticamente métricas de cada uma dessas workloads. Para visualizar as métricas coletadas por padrão, consulte [Métricas do Prometheus coletadas pelo atendente do CloudWatch](ContainerInsights-Prometheus-metrics.md).
Antes de instalar qualquer uma dessas cargas de trabalho, instale o Helm 3.x inserindo os comandos a seguir:
```
brew install helm
```
Para obter mais informações, consulte [Helm](https://helm.sh).
**Topics**
+ [Configurar amostra de workload AWS App Mesh para o Amazon EKS e o Kubernetes](ContainerInsights-Prometheus-Sample-Workloads-appmesh.md)
+ [Configurar o NGINX com tráfego de amostra no Amazon EKS e no Kubernetes](ContainerInsights-Prometheus-Sample-Workloads-nginx.md)
+ [Configurar memcached com um exportador de métricas no Amazon EKS e no Kubernetes](ContainerInsights-Prometheus-Sample-Workloads-memcached.md)
+ [Configurar amostra de workload do Java/JMX para o Amazon EKS e o Kubernetes](ContainerInsights-Prometheus-Sample-Workloads-javajmx.md)
+ [Configurar HAProxycom um exportador de métricas no Amazon EKS e no Kubernetes](ContainerInsights-Prometheus-Sample-Workloads-haproxy.md)
+ [Tutorial para adicionar um novo destino de extração do Prometheus: Redis OSS em clusters do Amazon EKS e do Kubernetes](ContainerInsights-Prometheus-Setup-redis-eks.md)
# Configurar amostra de workload AWS App Mesh para o Amazon EKS e o Kubernetes
O suporte do Prometheus no CloudWatch Container Insights oferece suporte a AWS App Mesh. As seções a seguir explicam como configurar o App Mesh.
**Topics**
+ [Configurar a amostra de workload AWS App Mesh em um cluster do Amazon EKS com o tipo de inicialização do EC2 ou um cluster do Kubernetes](ContainerInsights-Prometheus-Sample-Workloads-appmesh-EKS.md)
+ [Configurar a amostra de workload AWS App Mesh em um cluster do Amazon EKS com o tipo de inicialização do Fargate](ContainerInsights-Prometheus-Sample-Workloads-appmesh-Fargate.md)
# Configurar a amostra de workload AWS App Mesh em um cluster do Amazon EKS com o tipo de inicialização do EC2 ou um cluster do Kubernetes
Use estas instruções ao configurar o App Mesh em um cluster que executa o Amazon EKS com o tipo de inicialização do EC2 ou em um cluster do Kubernetes.
## Configurar permissões do IAM
É necessário adicionar a política **AWSAppMeshFullAccess** à função do IAM para seu grupo de nós do Amazon EKS ou do Kubernetes. No Amazon EKS, esse nome de grupo de nós é semelhante a `eksctl-integ-test-eks-prometheus-NodeInstanceRole-ABCDEFHIJKL`. No Kubernetes, ele pode ser semelhante a `nodes.integ-test-kops-prometheus.k8s.local`.
## Instalar o App Mesh
Para instalar o controlador do App Mesh Kubernetes, siga as instruções em [Controlador do App Mesh](https://github.com/aws/eks-charts/tree/master/stable/appmesh-controller#app-mesh-controller).
## Instalar uma amostra de aplicação
[aws-app-mesh-examples](https://github.com/aws/aws-app-mesh-examples) contém várias demonstrações do Kubernetes App Mesh. Com este tutorial, você instala uma amostra de aplicação de cor que mostra como as rotas http podem usar cabeçalhos para correspondência de solicitações recebidas.
**Para usar uma amostra de aplicação do App Mesh amostra para testar Insights de contêiner**
1. Instale a aplicação usando estas instruções: [https://github.com/aws/aws-app-mesh-examples/tree/main/walkthroughs/howto-k8s-http-headers](https://github.com/aws/aws-app-mesh-examples/tree/main/walkthroughs/howto-k8s-http-headers).
1. Inicie um pod de curler para gerar tráfego:
```
kubectl -n default run -it curler --image=tutum/curl /bin/bash
```
1. Execute curl em diferentes endpoints alterando cabeçalhos HTTP. Execute o comando curl várias vezes, conforme mostrado:
```
curl -H "color_header: blue" front.howto-k8s-http-headers.svc.cluster.local:8080/; echo;
curl -H "color_header: red" front.howto-k8s-http-headers.svc.cluster.local:8080/; echo;
curl -H "color_header: yellow" front.howto-k8s-http-headers.svc.cluster.local:8080/; echo;
```
1. Abra o console do CloudWatch, em [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).
1. Na região da AWS em que o cluster está em execução, escolha **Metrics** (Métricas) no painel de navegação. A métrica está no namespace **ContainerInsights/Prometheus**.
1. Para visualizar os eventos do CloudWatch Logs, escolha **Log Groups** (Grupos de logs) no painel de navegação. Os eventos estão no grupo de logs ` /aws/containerinsights/your_cluster_name/prometheus ` no fluxo de logs `kubernetes-pod-appmesh-envoy`.
## Excluir o ambiente de teste do App Mesh
Ao terminar de usar o App Mesh e a aplicação de exemplo, use os comandos a seguir para excluir os recursos desnecessários. Excluir a aplicação de exemplo inserindo o comando a seguir:
```
cd aws-app-mesh-examples/walkthroughs/howto-k8s-http-headers/
kubectl delete -f _output/manifest.yaml
```
Excluir o controlador do App Mesh inserindo o comando a seguir:
```
helm delete appmesh-controller -n appmesh-system
```
# Configurar a amostra de workload AWS App Mesh em um cluster do Amazon EKS com o tipo de inicialização do Fargate
Use estas instruções ao configurar o App Mesh em um cluster que executa o Amazon EKS com o tipo de inicialização do Fargate.
## Configurar permissões do IAM
Insira o seguinte comando para definir as permissões do IAM. Substitua *MyCluster* pelo nome do cluster.
```
eksctl create iamserviceaccount --cluster MyCluster \
--namespace howto-k8s-fargate \
--name appmesh-pod \
--attach-policy-arn arn:aws:iam::aws:policy/AWSAppMeshEnvoyAccess \
--attach-policy-arn arn:aws:iam::aws:policy/AWSCloudMapDiscoverInstanceAccess \
--attach-policy-arn arn:aws:iam::aws:policy/AWSXRayDaemonWriteAccess \
--attach-policy-arn arn:aws:iam::aws:policy/CloudWatchLogsFullAccess \
--attach-policy-arn arn:aws:iam::aws:policy/AWSAppMeshFullAccess \
--attach-policy-arn arn:aws:iam::aws:policy/AWSCloudMapFullAccess \
--override-existing-serviceaccounts \
--approve
```
## Instalar o App Mesh
Para instalar o controlador do App Mesh Kubernetes, siga as instruções em [Controlador do App Mesh](https://github.com/aws/eks-charts/tree/master/stable/appmesh-controller#app-mesh-controller). Siga as instruções para o Amazon EKS com o tipo de inicialização do Fargate.
## Instalar uma amostra de aplicação
[aws-app-mesh-examples](https://github.com/aws/aws-app-mesh-examples) contém várias demonstrações do Kubernetes App Mesh. Neste tutorial, você instala uma amostra de aplicaçao de cor que funciona para clusters do Amazon EKS com o tipo de inicialização do Fargate.
**Para usar uma amostra de aplicação do App Mesh amostra para testar Insights de contêiner**
1. Instale a aplicação usando estas instruções: [https://github.com/aws/aws-app-mesh-examples/tree/main/walkthroughs/howto-k8s-fargate](https://github.com/aws/aws-app-mesh-examples/tree/main/walkthroughs/howto-k8s-fargate).
Essas instruções pressupõem que você esteja criando um novo cluster com o perfil correto do Fargate. Caso queira usar um cluster do Amazon EKS que você já configurou, use os seguintes comandos para configurar o cluster para esta demonstração. Substitua *MyCluster* pelo nome do cluster.
```
eksctl create iamserviceaccount --cluster MyCluster \
--namespace howto-k8s-fargate \
--name appmesh-pod \
--attach-policy-arn arn:aws:iam::aws:policy/AWSAppMeshEnvoyAccess \
--attach-policy-arn arn:aws:iam::aws:policy/AWSCloudMapDiscoverInstanceAccess \
--attach-policy-arn arn:aws:iam::aws:policy/AWSXRayDaemonWriteAccess \
--attach-policy-arn arn:aws:iam::aws:policy/CloudWatchLogsFullAccess \
--attach-policy-arn arn:aws:iam::aws:policy/AWSAppMeshFullAccess \
--attach-policy-arn arn:aws:iam::aws:policy/AWSCloudMapFullAccess \
--override-existing-serviceaccounts \
--approve
```
```
eksctl create fargateprofile --cluster MyCluster \
--namespace howto-k8s-fargate --name howto-k8s-fargate
```
1. Encaminhe pela porta a implantação frontal da aplicação:
```
kubectl -n howto-k8s-fargate port-forward deployment/front 8080:8080
```
1. Execute curl na aplicação frontal:
```
while true; do curl -s http://localhost:8080/color; sleep 0.1; echo ; done
```
1. Abra o console do CloudWatch, em [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).
1. Na região da AWS em que o cluster está em execução, escolha **Metrics** (Métricas) no painel de navegação. A métrica está no namespace **ContainerInsights/Prometheus**.
1. Para visualizar os eventos do CloudWatch Logs, escolha **Log Groups** (Grupos de logs) no painel de navegação. Os eventos estão no grupo de logs ` /aws/containerinsights/your_cluster_name/prometheus ` no fluxo de logs `kubernetes-pod-appmesh-envoy`.
## Excluir o ambiente de teste do App Mesh
Ao terminar de usar o App Mesh e a aplicação de exemplo, use os comandos a seguir para excluir os recursos desnecessários. Excluir a aplicação de exemplo inserindo o comando a seguir:
```
cd aws-app-mesh-examples/walkthroughs/howto-k8s-fargate/
kubectl delete -f _output/manifest.yaml
```
Excluir o controlador do App Mesh inserindo o comando a seguir:
```
helm delete appmesh-controller -n appmesh-system
```
# Configurar o NGINX com tráfego de amostra no Amazon EKS e no Kubernetes
O NGINX é um servidor web que também pode ser usado como load balancer e proxy reverso. Para obter mais informações sobre como o Kubernetes usa o NGINX para entrada, consulte [kubernetes/ingress-nginx](https://github.com/kubernetes/ingress-nginx).
**Como instalar o Ingress-NGINX com uma amostra de serviço de tráfego para testar o suporte ao Container Insights Prometheus**
1. Insira comando a seguir para adicionar o repositório ingress-nginx do Helm:
```
helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx
```
1. Insira os comandos a seguir:
```
kubectl create namespace nginx-ingress-sample
helm install my-nginx ingress-nginx/ingress-nginx \
--namespace nginx-ingress-sample \
--set controller.metrics.enabled=true \
--set-string controller.metrics.service.annotations."prometheus\.io/port"="10254" \
--set-string controller.metrics.service.annotations."prometheus\.io/scrape"="true"
```
1. Verifique se os serviços foram iniciados corretamente inserindo o comando a seguir:
```
kubectl get service -n nginx-ingress-sample
```
A saída deste comando deve exibir várias colunas, incluindo uma coluna `EXTERNAL-IP`.
1. Defina uma variável `EXTERNAL-IP` para o valor da coluna `EXTERNAL-IP` na linha do controlador de entrada do NGINX.
```
EXTERNAL_IP=your-nginx-controller-external-ip
```
1. Inicie alguns exemplos de tráfego do NGINX inserindo o comando a seguir.
```
SAMPLE_TRAFFIC_NAMESPACE=nginx-sample-traffic
curl https://raw.githubusercontent.com/aws-samples/amazon-cloudwatch-container-insights/latest/k8s-deployment-manifest-templates/deployment-mode/service/cwagent-prometheus/sample_traffic/nginx-traffic/nginx-traffic-sample.yaml |
sed "s/{{external_ip}}/$EXTERNAL_IP/g" |
sed "s/{{namespace}}/$SAMPLE_TRAFFIC_NAMESPACE/g" |
kubectl apply -f -
```
1. Insira o comando a seguir para confirmar se todos os três pods estão no status `Running`.
```
kubectl get pod -n $SAMPLE_TRAFFIC_NAMESPACE
```
Se eles estiverem em execução, logo você verá as métricas no namespace **ContainerInsights/Prometheus** .
**Como desinstalar o NGINX e o aplicativo de tráfego de exemplo**
1. Exclua o serviço de tráfego de exemplo inserindo o comando a seguir:
```
kubectl delete namespace $SAMPLE_TRAFFIC_NAMESPACE
```
1. Exclua a saída do NGINX pelo nome da versão do Helm.
```
helm uninstall my-nginx --namespace nginx-ingress-sample
kubectl delete namespace nginx-ingress-sample
```
# Configurar memcached com um exportador de métricas no Amazon EKS e no Kubernetes
memcached é um sistema de armazenamento em cache de objetos na memória de código aberto. Para obter mais informações, consulte [O que é Memcached](https://www.memcached.org)?
Se você estiver executando o memcached em um cluster com o tipo de inicialização do Fargate, precisará configurar um perfil do Fargate antes de executar as etapas deste procedimento. Para configurar o perfil, insira o comando a seguir. Substitua *MyCluster* pelo nome do cluster.
```
eksctl create fargateprofile --cluster MyCluster \
--namespace memcached-sample --name memcached-sample
```
**Como instalar memcached com um exportador de métricas para testar o suporte do Container Insights Prometheus**
1. Insira comando a seguir para adicionar o repositório:
```
helm repo add bitnami https://charts.bitnami.com/bitnami
```
1. Insira o comando a seguir para criar um novo namespace:
```
kubectl create namespace memcached-sample
```
1. Insira o comando a seguir para instalar o Memcached
```
helm install my-memcached bitnami/memcached --namespace memcached-sample \
--set metrics.enabled=true \
--set-string serviceAnnotations.prometheus\\.io/port="9150" \
--set-string serviceAnnotations.prometheus\\.io/scrape="true"
```
1. Insira o comando a seguir para confirmar a anotação do serviço em execução:
```
kubectl describe service my-memcached-metrics -n memcached-sample
```
Você verá as duas anotações a seguir:
```
Annotations: prometheus.io/port: 9150
prometheus.io/scrape: true
```
**Como desinstalar o memcached**
+ Insira os comandos a seguir:
```
helm uninstall my-memcached --namespace memcached-sample
kubectl delete namespace memcached-sample
```
# Configurar amostra de workload do Java/JMX para o Amazon EKS e o Kubernetes
O JMX Exporter é um exportador oficial do Prometheus que pode extrair conteúdo e expor mBeans da JMX como métricas do Prometheus. Para obter mais informações, consulte [prometheus/jmx\$1exporter](https://github.com/prometheus/jmx_exporter).
O Container Insights pode coletar métricas predefinidas do Prometheus a partir da Java Virtual Machine (JVM), Java e Tomcat (Catalina) usando o JMX Exporter.
## Configuração padrão de extração do Prometheus
Por padrão, o atendente do CloudWatch com suporte ao Prometheus extrai as métricas do Java/JMX do Prometheus de `http://CLUSTER_IP:9404/metrics` em cada pod em um cluster do Amazon EKS ou do Kubernetes. Isso é feito pela detecção `role: pod` do Prometheus `kubernetes_sd_config`. 9404 é a porta padrão alocada para o JMX Exporter pelo Prometheus. Para obter mais informações sobre a detecção `role: pod`, consulte [pod](https://prometheus.io/docs/prometheus/latest/configuration/configuration/#pod). Você pode configurar o JMX Exporter de modo a expor as métricas em uma porta ou metrics\$1path diferente. Se você alterar a porta ou o caminho, atualize o jmx scrape\$1config padrão no mapa de configuração do atendente do CloudWatch. Execute o comando a seguir para obter a configuração do Prometheus atual do atendente do CloudWatch:
```
kubectl describe cm prometheus-config -n amazon-cloudwatch
```
Os campos a serem alterados são os campos `/metrics` e `regex: '.*:9404$'`, conforme destacado no exemplo a seguir.
```
job_name: 'kubernetes-jmx-pod'
sample_limit: 10000
metrics_path: /metrics
kubernetes_sd_configs:
- role: pod
relabel_configs:
- source_labels: [__address__]
action: keep
regex: '.*:9404$'
- action: replace
regex: (.+)
source_labels:
```
## Outra configuração de extração do Prometheus
Se você expuser sua aplicação em execução em um conjunto de pods com exportadores Java/JMX Prometheus por um Kubernetes Service, também será possível alternar para usar detecção `role: service` ou detecção `role: endpoint` do Prometheus `kubernetes_sd_config`. Para obter mais informações sobre esses métodos de detecção, consulte [serviço](https://prometheus.io/docs/prometheus/latest/configuration/configuration/#service), [endpoints](https://prometheus.io/docs/prometheus/latest/configuration/configuration/#endpoints) e[.](https://prometheus.io/docs/prometheus/latest/configuration/configuration/#kubernetes_sd_config).
Mais meta rótulos são fornecidos por esses dois modos de detecção de serviço que podem ser úteis para você criar as dimensões de métricas do CloudWatch. Por exemplo, é possível rotular `__meta_kubernetes_service_name` como `Service` e incluí-lo na dimensão de suas métricas. Para obter mais informações sobre como personalizar suas métricas do CloudWatch e suas dimensões, consulte [Configuração do atendente do CloudWatch para o Prometheus](ContainerInsights-Prometheus-Setup-configure-ECS.md#ContainerInsights-Prometheus-Setup-cw-agent-config).
## Imagem do docker com o JMX Exporter
Crie uma imagem do Docker. As seções a seguir fornecem dois exemplos de Dockerfiles.
Quando você tiver compilado a imagem, carregue-a no Amazon EKS ou no Kubernetes e execute o comando a seguir para verificar se as métricas do Prometheus são expostas por `JMX_EXPORTER` na porta 9404. Substitua *\$1JAR\$1SAMPLE\$1TRAFFIC\$1POD* pelo nome do pod em execução e substitua *\$1JAR\$1SAMPLE\$1TRAFFIC\$1NAMESPACE* pelo namespace do aplicativo.
Se você estiver executando o JMX Exporter em um cluster com o tipo de inicialização do Fargate, precisará configurar um perfil do Fargate antes de executar as etapas deste procedimento. Para configurar o perfil, insira o comando a seguir. Substitua *MyCluster* pelo nome do cluster.
```
eksctl create fargateprofile --cluster MyCluster \
--namespace $JAR_SAMPLE_TRAFFIC_NAMESPACE\
--name $JAR_SAMPLE_TRAFFIC_NAMESPACE
```
```
kubectl exec $JAR_SAMPLE_TRAFFIC_POD -n $JARCAT_SAMPLE_TRAFFIC_NAMESPACE -- curl http://localhost:9404
```
## Exemplo: imagem do Docker do Apache Tomcat com métricas do Prometheus
O servidor Apache Tomcat expõe mBeans da JMX por padrão. Você pode integrar o JMX Exporter ao Tomcat para expor o mBeans da JMX como métricas do Prometheus. O exemplo de dockerfile a seguir mostra as etapas para criação de uma imagem de teste:
```
# From Tomcat 9.0 JDK8 OpenJDK
FROM tomcat:9.0-jdk8-openjdk
RUN mkdir -p /opt/jmx_exporter
COPY ./jmx_prometheus_javaagent-0.12.0.jar /opt/jmx_exporter
COPY ./config.yaml /opt/jmx_exporter
COPY ./setenv.sh /usr/local/tomcat/bin
COPY your web application.war /usr/local/tomcat/webapps/
RUN chmod o+x /usr/local/tomcat/bin/setenv.sh
ENTRYPOINT ["catalina.sh", "run"]
```
A lista a seguir explica as quatro linhas `COPY` deste dockerfile.
+ Faça download do arquivo jar mais recente do JMX Exporter em [https://github.com/prometheus/jmx\$1exporter](https://github.com/prometheus/jmx_exporter).
+ `config.yaml` é o arquivo de configuração do JMX Exporter. Para obter mais informações, consulte [https://github.com/prometheus/jmx\$1exporter\$1Configuration](https://github.com/prometheus/jmx_exporter#Configuration ).
Veja a seguir um arquivo de configuração de exemplo para Java e Tomcat:
```
lowercaseOutputName: true
lowercaseOutputLabelNames: true
rules:
- pattern: 'java.lang<>(FreePhysicalMemorySize|TotalPhysicalMemorySize|FreeSwapSpaceSize|TotalSwapSpaceSize|SystemCpuLoad|ProcessCpuLoad|OpenFileDescriptorCount|AvailableProcessors)'
name: java_lang_OperatingSystem_$1
type: GAUGE
- pattern: 'java.lang<>(TotalStartedThreadCount|ThreadCount)'
name: java_lang_threading_$1
type: GAUGE
- pattern: 'Catalina<>(\w+)'
name: catalina_globalrequestprocessor_$3_total
labels:
port: "$2"
protocol: "$1"
help: Catalina global $3
type: COUNTER
- pattern: 'Catalina<>(requestCount|maxTime|processingTime|errorCount)'
name: catalina_servlet_$3_total
labels:
module: "$1"
servlet: "$2"
help: Catalina servlet $3 total
type: COUNTER
- pattern: 'Catalina<>(currentThreadCount|currentThreadsBusy|keepAliveCount|pollerThreadCount|connectionCount)'
name: catalina_threadpool_$3
labels:
port: "$2"
protocol: "$1"
help: Catalina threadpool $3
type: GAUGE
- pattern: 'Catalina<>(processingTime|sessionCounter|rejectedSessions|expiredSessions)'
name: catalina_session_$3_total
labels:
context: "$2"
host: "$1"
help: Catalina session $3 total
type: COUNTER
- pattern: ".*"
```
+ `setenv.sh` é um script de inicialização do Tomcat para iniciar o JMX exporter com o Tomcat e expor métricas do Prometheus na porta 9404 do localhost. Ele também fornece ao JMX Exporter o caminho do arquivo `config.yaml`.
```
$ cat setenv.sh
export JAVA_OPTS="-javaagent:/opt/jmx_exporter/jmx_prometheus_javaagent-0.12.0.jar=9404:/opt/jmx_exporter/config.yaml $JAVA_OPTS"
```
+ o aplicativo web .war é o arquivo de aplicativo web `war` a ser carregado pelo Tomcat.
Crie uma imagem do Docker com essa configuração e carregue para um repositório de imagens.
## Exemplo: imagem do Docker da aplicação Java Jar com métricas do Prometheus
O exemplo de dockerfile a seguir mostra as etapas para criação de uma imagem de teste:
```
# Alpine Linux with OpenJDK JRE
FROM openjdk:8-jre-alpine
RUN mkdir -p /opt/jmx_exporter
COPY ./jmx_prometheus_javaagent-0.12.0.jar /opt/jmx_exporter
COPY ./SampleJavaApplication-1.0-SNAPSHOT.jar /opt/jmx_exporter
COPY ./start_exporter_example.sh /opt/jmx_exporter
COPY ./config.yaml /opt/jmx_exporter
RUN chmod -R o+x /opt/jmx_exporter
RUN apk add curl
ENTRYPOINT exec /opt/jmx_exporter/start_exporter_example.sh
```
A lista a seguir explica as quatro linhas `COPY` deste dockerfile.
+ Faça download do arquivo jar mais recente do JMX Exporter em [https://github.com/prometheus/jmx\$1exporter](https://github.com/prometheus/jmx_exporter).
+ `config.yaml` é o arquivo de configuração do JMX Exporter. Para obter mais informações, consulte [https://github.com/prometheus/jmx\$1exporter\$1Configuration](https://github.com/prometheus/jmx_exporter#Configuration ).
Veja a seguir um arquivo de configuração de exemplo para Java e Tomcat:
```
lowercaseOutputName: true
lowercaseOutputLabelNames: true
rules:
- pattern: 'java.lang<>(FreePhysicalMemorySize|TotalPhysicalMemorySize|FreeSwapSpaceSize|TotalSwapSpaceSize|SystemCpuLoad|ProcessCpuLoad|OpenFileDescriptorCount|AvailableProcessors)'
name: java_lang_OperatingSystem_$1
type: GAUGE
- pattern: 'java.lang<>(TotalStartedThreadCount|ThreadCount)'
name: java_lang_threading_$1
type: GAUGE
- pattern: 'Catalina<>(\w+)'
name: catalina_globalrequestprocessor_$3_total
labels:
port: "$2"
protocol: "$1"
help: Catalina global $3
type: COUNTER
- pattern: 'Catalina<>(requestCount|maxTime|processingTime|errorCount)'
name: catalina_servlet_$3_total
labels:
module: "$1"
servlet: "$2"
help: Catalina servlet $3 total
type: COUNTER
- pattern: 'Catalina<>(currentThreadCount|currentThreadsBusy|keepAliveCount|pollerThreadCount|connectionCount)'
name: catalina_threadpool_$3
labels:
port: "$2"
protocol: "$1"
help: Catalina threadpool $3
type: GAUGE
- pattern: 'Catalina<>(processingTime|sessionCounter|rejectedSessions|expiredSessions)'
name: catalina_session_$3_total
labels:
context: "$2"
host: "$1"
help: Catalina session $3 total
type: COUNTER
- pattern: ".*"
```
+ `start_exporter_example.sh` é o script para iniciar o aplicativo JAR com as métricas exportadas do Prometheus. Ele também fornece ao JMX Exporter o caminho do arquivo `config.yaml`.
```
$ cat start_exporter_example.sh
java -javaagent:/opt/jmx_exporter/jmx_prometheus_javaagent-0.12.0.jar=9404:/opt/jmx_exporter/config.yaml -cp /opt/jmx_exporter/SampleJavaApplication-1.0-SNAPSHOT.jar com.gubupt.sample.app.App
```
+ SampleJavaApplication-1.0-SNAPSHOT.jar é o arquivo jar do aplicativo Java de amostra. Substitua-o pelo aplicativo Java que você deseja monitorar.
Crie uma imagem do Docker com essa configuração e carregue para um repositório de imagens.
# Configurar HAProxycom um exportador de métricas no Amazon EKS e no Kubernetes
HAProxy é um aplicativo proxy de código aberto. Para obter mais informações, consulte [HAProxy](https://www.haproxy.org).
Se você estiver executando o HAProxyem um cluster com o tipo de inicialização do Fargate, precisará configurar um perfil do Fargate antes de executar as etapas deste procedimento. Para configurar o perfil, insira o comando a seguir. Substitua *MyCluster* pelo nome do cluster.
```
eksctl create fargateprofile --cluster MyCluster \
--namespace haproxy-ingress-sample --name haproxy-ingress-sample
```
**Como instalar o HAProxy com um exportador de métricas para testar o suporte do Container Insights Prometheus**
1. Insira o comando a seguir para adicionar o repositório da incubadora do Helm:
```
helm repo add haproxy-ingress https://haproxy-ingress.github.io/charts
```
1. Insira o comando a seguir para criar um novo namespace:
```
kubectl create namespace haproxy-ingress-sample
```
1. Insira os comandos a seguir para instalar o HAProxy:
```
helm install haproxy haproxy-ingress/haproxy-ingress \
--namespace haproxy-ingress-sample \
--set defaultBackend.enabled=true \
--set controller.stats.enabled=true \
--set controller.metrics.enabled=true \
--set-string controller.metrics.service.annotations."prometheus\.io/port"="9101" \
--set-string controller.metrics.service.annotations."prometheus\.io/scrape"="true"
```
1. Insira o comando a seguir para confirmar a anotação do serviço:
```
kubectl describe service haproxy-haproxy-ingress-metrics -n haproxy-ingress-sample
```
Você verá as anotações a seguir.
```
Annotations: prometheus.io/port: 9101
prometheus.io/scrape: true
```
**Como desinstalar o HAProxy**
+ Insira os comandos a seguir:
```
helm uninstall haproxy --namespace haproxy-ingress-sample
kubectl delete namespace haproxy-ingress-sample
```
# Tutorial para adicionar um novo destino de extração do Prometheus: Redis OSS em clusters do Amazon EKS e do Kubernetes
Este tutorial apresenta uma introdução prática para extrair as métricas do Prometheus de um exemplo de aplicação do Redis em um cluster do Amazon EKS e do Kubernetes. O Redis OSS (https://redis.io/) é um armazenamento de estrutura de dados em memória com código aberto (licença BSD), usado como banco de dados, cache e agente de mensagens. Para obter mais informações, consulte [ redis](https://redis.io/).
O redis\$1exporter (licença MIT) é usado para expor as métricas do Prometheus no Redis OSS na porta especificada (padrão: 0.0.0.0:9121). Para obter mais informações, consulte [redis\$1exporter](https://github.com/oliver006/redis_exporter).
As imagens do Docker dos dois repositórios do Docker Hub a seguir são usadas neste tutorial:
+ [ redis](https://hub.docker.com/_/redis?tab=description)
+ [ redis\$1exporter](https://hub.docker.com/r/oliver006/redis_exporter)
**Para instalar um exemplo de workload do Redis OSS que expõe as métricas do Prometheus**
1. Defina o namespace para a workload de exemplo do Redis OSS.
```
REDIS_NAMESPACE=redis-sample
```
1. Se você estiver executando o Redis OSS em um cluster com o tipo de inicialização do Fargate, precisará configurar um perfil do Fargate. Para configurar o perfil, insira o comando a seguir. Substitua *MyCluster* pelo nome do cluster.
```
eksctl create fargateprofile --cluster MyCluster \
--namespace $REDIS_NAMESPACE --name $REDIS_NAMESPACE
```
1. Instale a workload de exemplo do Redis inserindo o comando a seguir.
```
curl https://raw.githubusercontent.com/aws-samples/amazon-cloudwatch-container-insights/latest/k8s-deployment-manifest-templates/deployment-mode/service/cwagent-prometheus/sample_traffic/redis/redis-traffic-sample.yaml \
| sed "s/{{namespace}}/$REDIS_NAMESPACE/g" \
| kubectl apply -f -
```
1. A instalação inclui um serviço chamado `my-redis-metrics` que expõe a métrica do Prometheus no Redis OSS na porta 9121. Insira o seguinte comando para obter os detalhes do serviço:
```
kubectl describe service/my-redis-metrics -n $REDIS_NAMESPACE
```
Na seção `Annotations` dos resultados, você verá duas anotações que correspondem à configuração de extração do Prometheus do atendente do CloudWatch, para que ele possa detectar as workloads automaticamente:
```
prometheus.io/port: 9121
prometheus.io/scrape: true
```
A configuração de extração do Prometheus relacionada pode ser encontrada na seção `- job_name: kubernetes-service-endpoints` de`kubernetes-eks.yaml` ou `kubernetes-k8s.yaml`.
**Para começar a coletar métricas do Prometheus no Redis OSS no CloudWatch**
1. Baixe a versão mais recente do arquivo `kubernetes-eks.yaml` ou `kubernetes-k8s.yaml` inserindo um dos comandos a seguir. Para um cluster do Amazon EKS com o tipo de inicialização do EC2, insira este comando.
```
curl -O https://raw.githubusercontent.com/aws-samples/amazon-cloudwatch-container-insights/latest/k8s-deployment-manifest-templates/deployment-mode/service/cwagent-prometheus/prometheus-eks.yaml
```
Para um cluster do Amazon EKS com o tipo de inicialização do Fargate, insira este comando.
```
curl -O https://raw.githubusercontent.com/aws-samples/amazon-cloudwatch-container-insights/latest/k8s-deployment-manifest-templates/deployment-mode/service/cwagent-prometheus/prometheus-eks-fargate.yaml
```
Para um cluster do Kubernetes em execução em uma instância do Amazon EC2, insira este comando.
```
curl -O https://raw.githubusercontent.com/aws-samples/amazon-cloudwatch-container-insights/latest/k8s-deployment-manifest-templates/deployment-mode/service/cwagent-prometheus/prometheus-k8s.yaml
```
1. Abra o arquivo com um editor de textos e localize a seção `cwagentconfig.json`. Adicione a seguinte subseção e salve as alterações. Verifique se o recuo segue o padrão existente.
```
{
"source_labels": ["pod_name"],
"label_matcher": "^redis-instance$",
"dimensions": [["Namespace","ClusterName"]],
"metric_selectors": [
"^redis_net_(in|out)put_bytes_total$",
"^redis_(expired|evicted)_keys_total$",
"^redis_keyspace_(hits|misses)_total$",
"^redis_memory_used_bytes$",
"^redis_connected_clients$"
]
},
{
"source_labels": ["pod_name"],
"label_matcher": "^redis-instance$",
"dimensions": [["Namespace","ClusterName","cmd"]],
"metric_selectors": [
"^redis_commands_total$"
]
},
{
"source_labels": ["pod_name"],
"label_matcher": "^redis-instance$",
"dimensions": [["Namespace","ClusterName","db"]],
"metric_selectors": [
"^redis_db_keys$"
]
},
```
A seção que você adicionou coloca as métricas do Redis OSS na lista de permissões do agente do CloudWatch. Para obter a lista dessas métricas, consulte a seção a seguir.
1. Se você já tem o atendente do CloudWatch com suporte ao Prometheus implantado nesse cluster, exclua-o inserindo o comando a seguir.
```
kubectl delete deployment cwagent-prometheus -n amazon-cloudwatch
```
1. Implante o atendente do CloudWatch com a configuração atualizada inserindo um dos comandos a seguir. Substitua *MyCluster* e *region* para corresponder a suas configurações.
Para um cluster do Amazon EKS com o tipo de inicialização do EC2, insira este comando.
```
kubectl apply -f prometheus-eks.yaml
```
Para um cluster do Amazon EKS com o tipo de inicialização do Fargate, insira este comando.
```
cat prometheus-eks-fargate.yaml \
| sed "s/{{cluster_name}}/MyCluster/;s/{{region_name}}/region/" \
| kubectl apply -f -
```
Para um cluster do Kubernetes, insira este comando.
```
cat prometheus-k8s.yaml \
| sed "s/{{cluster_name}}/MyCluster/;s/{{region_name}}/region/" \
| kubectl apply -f -
```
## Visualizar suas métricas do Prometheus no Redis OSS
Este tutorial envia as seguintes métricas ao namespace **ContainerInsights/Prometheus** no CloudWatch. É possível usar o console do CloudWatch para ver as métricas nesse namespace.
| Nome da métrica | Dimensões |
| --- | --- |
| `redis_net_input_bytes_total` | ClusterName, `Namespace` |
| `redis_net_output_bytes_total` | ClusterName, `Namespace` |
| `redis_expired_keys_total` | ClusterName, `Namespace` |
| `redis_evicted_keys_total` | ClusterName, `Namespace` |
| `redis_keyspace_hits_total` | ClusterName, `Namespace` |
| `redis_keyspace_misses_total` | ClusterName, `Namespace` |
| `redis_memory_used_bytes` | ClusterName, `Namespace` |
| `redis_connected_clients` | ClusterName, `Namespace` |
| `redis_commands_total` | ClusterName, `Namespace`, cmd |
| `redis_db_keys` | ClusterName, `Namespace`, db |
**nota**
O valor da dimensão **cmd** pode ser: `append`, `client`, `command`, `config`, `dbsize`, `flushall`, `get`, `incr`, `info`, `latency` ou `slowlog`.
Os valores da dimensão **db** podem ser `db0` ou `db15`.
Também é possível criar um painel do CloudWatch para suas métricas do Prometheus no Redis OSS.
**Para criar um painel para métricas do Prometheus no Redis OSS**
1. Crie variáveis de ambiente, substituindo os valores abaixo para corresponder a sua implantação.
```
DASHBOARD_NAME=your_cw_dashboard_name
REGION_NAME=your_metric_region_such_as_us-east-1
CLUSTER_NAME=your_k8s_cluster_name_here
NAMESPACE=your_redis_service_namespace_here
```
1. Use o comando a seguir para criar o painel.
```
curl https://raw.githubusercontent.com/aws-samples/amazon-cloudwatch-container-insights/latest/k8s-deployment-manifest-templates/deployment-mode/service/cwagent-prometheus/sample_cloudwatch_dashboards/redis/cw_dashboard_redis.json \
| sed "s/{{YOUR_AWS_REGION}}/${REGION_NAME}/g" \
| sed "s/{{YOUR_CLUSTER_NAME}}/${CLUSTER_NAME}/g" \
| sed "s/{{YOUR_NAMESPACE}}/${NAMESPACE}/g" \
```
# Conversão de tipo de métrica do Prometheus pelo CloudWatch Agent
As bibliotecas cliente Prometheus oferecem quatro tipos de métricas principais:
+ Contador
+ Medidor
+ Resumo
+ Histograma
O atendente do CloudWatch oferece suporte aos tipos de métricas de contador, medidor e resumo.
As métricas do Prometheus com o tipo de métrica de histograma não compatível são descartadas pelo atendente do CloudWatch. Para obter mais informações, consulte [Registrar as métricas descartadas do Prometheus](ContainerInsights-Prometheus-troubleshooting-EKS.md#ContainerInsights-Prometheus-troubleshooting-droppedmetrics).
**Métricas de medidor**
Uma métrica de medidor Prometheus é uma métrica que representa um único valor numérico que pode aumentar e diminuir arbitrariamente. O atendente do CloudWatch extrai métricas de medidor e envia esses valores diretamente.
**Métricas de contador**
Uma métrica de contador Prometheus é uma métrica cumulativa que representa um único contador que aumenta de forma monotônica cujo valor só pode aumentar ou ser redefinido para zero. O atendente do CloudWatch calcula um delta da extração anterior e envia o valor delta como o valor da métrica no evento de log. Assim, o atendente do CloudWatch começará a produzir um evento de log a partir da segunda extração e continuará com as extrações subsequentes, se houver.
**Métricas de resumo**
Uma métrica de resumo do Prometheus é um tipo de métrica complexa que é representada por vários pontos de dados. Ela fornece uma contagem total de observações e uma soma de todos os valores observados. Calcula quantis configuráveis sobre uma janela de tempo deslizante.
A soma e a contagem de uma métrica resumida são cumulativas, mas os quantis não são. O exemplo a seguir mostra a variância dos quantis.
```
# TYPE go_gc_duration_seconds summary
go_gc_duration_seconds{quantile="0"} 7.123e-06
go_gc_duration_seconds{quantile="0.25"} 9.204e-06
go_gc_duration_seconds{quantile="0.5"} 1.1065e-05
go_gc_duration_seconds{quantile="0.75"} 2.8731e-05
go_gc_duration_seconds{quantile="1"} 0.003841496
go_gc_duration_seconds_sum 0.37630427
go_gc_duration_seconds_count 9774
```
O atendente do CloudWatch lida com a soma e a contagem de uma métrica resumida da mesma forma que lida com métricas de contador, conforme descrito na seção anterior. O atendente do CloudWatch preserva os valores dos quantis conforme eles são originalmente informados.
# Métricas do Prometheus coletadas pelo atendente do CloudWatch
O atendente do CloudWatch com suporte ao Prometheus coleta automaticamente métricas de vários serviços e workloads. As métricas que são coletadas por padrão estão listadas nas seções a seguir. Você também pode configurar o atendente para coletar mais métricas desses serviços e coletar métricas do Prometheus de outras aplicações e serviços. Para obter mais informações sobre coletar outras métricas, consulte [Configuração do atendente do CloudWatch para o Prometheus](ContainerInsights-Prometheus-Setup-configure-ECS.md#ContainerInsights-Prometheus-Setup-cw-agent-config).
As métricas da Prometheus coletadas de clusters do Amazon EKS e do Kubernetes estão no namespace **ContainerInsights/Prometheus**. As métricas da Prometheus coletadas de clusters do Amazon ECS estão no namespace **ECS/ContainerInsights/Prometheus**.
**Topics**
+ [Métricas do Prometheus para o App Mesh](#ContainerInsights-Prometheus-metrics-appmesh)
+ [Métricas do Prometheus para NGINX](#ContainerInsights-Prometheus-metrics-nginx)
+ [Métricas do Prometheus para Memcached](#ContainerInsights-Prometheus-metrics-memcached)
+ [Métricas do Prometheus para Java/JMX](#ContainerInsights-Prometheus-metrics-jmx)
+ [Métricas do Prometheus para HAProxy](#ContainerInsights-Prometheus-metrics-haproxy)
## Métricas do Prometheus para o App Mesh
As métricas a seguir são coletadas automaticamente do App Mesh.
**Métricas do Prometheus para App Mesh em clusters do Amazon EKS e do Kubernetes**
| Nome da métrica | Dimensões |
| --- | --- |
| `envoy_http_downstream_rq_total` | ClusterName, `Namespace` |
| `envoy_http_downstream_rq_xx` | ClusterName, `Namespace` ClusterName, `Namespace`, envoy\$1http\$1conn\$1manager\$1prefix, envoy\$1response\$1code\$1class |
| `envoy_cluster_upstream_cx_rx_bytes_total` | ClusterName, `Namespace` |
| `envoy_cluster_upstream_cx_tx_bytes_total` | ClusterName, `Namespace` |
| `envoy_cluster_membership_healthy` | ClusterName, `Namespace` |
| `envoy_cluster_membership_total` | ClusterName, `Namespace` |
| `envoy_server_memory_heap_size` | ClusterName, `Namespace` |
| `envoy_server_memory_allocated` | ClusterName, `Namespace` |
| `envoy_cluster_upstream_cx_connect_timeout` | ClusterName, `Namespace` |
| `envoy_cluster_upstream_rq_pending_failure_eject` | ClusterName, `Namespace` |
| `envoy_cluster_upstream_rq_pending_overflow` | ClusterName, `Namespace` |
| `envoy_cluster_upstream_rq_timeout` | ClusterName, `Namespace` |
| `envoy_cluster_upstream_rq_try_per_timeout` | ClusterName, `Namespace` |
| `envoy_cluster_upstream_rq_rx_reset` | ClusterName, `Namespace` |
| `envoy_cluster_upstream_cx_destroy_local_with_active_rq` | ClusterName, `Namespace` |
| `envoy_cluster_upstream_cx_destroy_remote_active_rq` | ClusterName, `Namespace` |
| `envoy_cluster_upstream_rq_maintenance_mode` | ClusterName, `Namespace` |
| `envoy_cluster_upstream_flow_control_paused_reading_total` | ClusterName, `Namespace` |
| `envoy_cluster_upstream_flow_control_resumed_reading_total` | ClusterName, `Namespace` |
| `envoy_cluster_upstream_flow_control_backed_up_total` | ClusterName, `Namespace` |
| `envoy_cluster_upstream_flow_control_drained_total` | ClusterName, `Namespace` |
| `envoy_cluster_upstream_rq_retry` | ClusterName, `Namespace` |
| `envoy_cluster_upstream_rq_retry_success` | ClusterName, `Namespace` |
| `envoy_cluster_upstream_rq_retry_overflow` | ClusterName, `Namespace` |
| `envoy_server_live` | ClusterName, `Namespace` |
| `envoy_server_uptime` | ClusterName, `Namespace` |
**Métricas do Prometheus para App Mesh em clusters do Amazon ECS**
| Nome da métrica | Dimensões |
| --- | --- |
| `envoy_http_downstream_rq_total` | ClusterName, `TaskDefinitionFamily` |
| `envoy_http_downstream_rq_xx` | ClusterName, `TaskDefinitionFamily` |
| `envoy_cluster_upstream_cx_rx_bytes_total` | ClusterName, `TaskDefinitionFamily` |
| `envoy_cluster_upstream_cx_tx_bytes_total` | ClusterName, `TaskDefinitionFamily` |
| `envoy_cluster_membership_healthy` | ClusterName, `TaskDefinitionFamily` |
| `envoy_cluster_membership_total` | ClusterName, `TaskDefinitionFamily` |
| `envoy_server_memory_heap_size` | ClusterName, `TaskDefinitionFamily` |
| `envoy_server_memory_allocated` | ClusterName, `TaskDefinitionFamily` |
| `envoy_cluster_upstream_cx_connect_timeout` | ClusterName, `TaskDefinitionFamily` |
| `envoy_cluster_upstream_rq_pending_failure_eject` | ClusterName, `TaskDefinitionFamily` |
| `envoy_cluster_upstream_rq_pending_overflow` | ClusterName, `TaskDefinitionFamily` |
| `envoy_cluster_upstream_rq_timeout` | ClusterName, `TaskDefinitionFamily` |
| `envoy_cluster_upstream_rq_try_per_timeout` | ClusterName, `TaskDefinitionFamily` |
| `envoy_cluster_upstream_rq_rx_reset` | ClusterName, `TaskDefinitionFamily` |
| `envoy_cluster_upstream_cx_destroy_local_with_active_rq` | ClusterName, `TaskDefinitionFamily` |
| `envoy_cluster_upstream_cx_destroy_remote_active_rq` | ClusterName, `TaskDefinitionFamily` |
| `envoy_cluster_upstream_rq_maintenance_mode` | ClusterName, `TaskDefinitionFamily` |
| `envoy_cluster_upstream_flow_control_paused_reading_total` | ClusterName, `TaskDefinitionFamily` |
| `envoy_cluster_upstream_flow_control_resumed_reading_total` | ClusterName, `TaskDefinitionFamily` |
| `envoy_cluster_upstream_flow_control_backed_up_total` | ClusterName, `TaskDefinitionFamily` |
| `envoy_cluster_upstream_flow_control_drained_total` | ClusterName, `TaskDefinitionFamily` |
| `envoy_cluster_upstream_rq_retry` | ClusterName, `TaskDefinitionFamily` |
| `envoy_cluster_upstream_rq_retry_success` | ClusterName, `TaskDefinitionFamily` |
| `envoy_cluster_upstream_rq_retry_overflow` | ClusterName, `TaskDefinitionFamily` |
| `envoy_server_live` | ClusterName, `TaskDefinitionFamily` |
| `envoy_server_uptime` | ClusterName, `TaskDefinitionFamily` |
| `envoy_http_downstream_rq_xx` | ClusterName, TaskDefinitionFamily, envoy\$1http\$1conn\$1manager\$1prefix, envoy\$1response\$1code\$1class ClusterName, TaskDefinitionFamily, envoy\$1response\$1code\$1class |
**nota**
`TaskDefinitionFamily` é o namespace do Kubernetes da malha.
O valor de `envoy_http_conn_manager_prefix` pode ser `ingress`, `egress` ou `admin`.
O valor de `envoy_response_code_class` pode ser `1` (significa `1xx`) , `2` (significa `2xx`) ,`3`significa `3xx`), `4` (significa `4xx`) ou `5` (significa`5xx`).
## Métricas do Prometheus para NGINX
As métricas a seguir são coletadas automaticamente do NGINX em clusters do Amazon EKS e do Kubernetes.
| Nome da métrica | Dimensões |
| --- | --- |
| `nginx_ingress_controller_nginx_process_cpu_seconds_total` | ClusterName, `Namespace`, serviço |
| `nginx_ingress_controller_success` | ClusterName, `Namespace`, serviço |
| `nginx_ingress_controller_requests` | ClusterName, `Namespace`, serviço |
| `nginx_ingress_controller_nginx_process_connections` | ClusterName, `Namespace`, serviço |
| `nginx_ingress_controller_nginx_process_connections_total` | ClusterName, `Namespace`, serviço |
| `nginx_ingress_controller_nginx_process_resident_memory_bytes` | ClusterName, `Namespace`, serviço |
| `nginx_ingress_controller_config_last_reload_successful` | ClusterName, `Namespace`, serviço |
| `nginx_ingress_controller_requests` | ClusterName, `Namespace`, serviço, status |
## Métricas do Prometheus para Memcached
As métricas a seguir são coletadas automaticamente do Memcached em clusters do Amazon EKS e do Kubernetes.
| Nome da métrica | Dimensões |
| --- | --- |
| `memcached_current_items` | ClusterName, `Namespace`, serviço |
| `memcached_current_connections` | ClusterName, `Namespace`, serviço |
| `memcached_limit_bytes` | ClusterName, `Namespace`, serviço |
| `memcached_current_bytes` | ClusterName, `Namespace`, serviço |
| `memcached_written_bytes_total` | ClusterName, `Namespace`, serviço |
| `memcached_read_bytes_total` | ClusterName, `Namespace`, serviço |
| `memcached_items_evicted_total` | ClusterName, `Namespace`, serviço |
| `memcached_items_reclaimed_total` | ClusterName, `Namespace`, serviço |
| `memcached_commands_total` | ClusterName, `Namespace`, serviço ClusterName, `Namespace`, serviço, comando ClusterName, `Namespace`, serviço, status, comando |
## Métricas do Prometheus para Java/JMX
**Métricas coletadas em clusters do Amazon EKS e do Kubernetes**
Em clusters do Amazon EKS e do Kubernetes, o Container Insights pode coletar as seguintes métricas predefinidas do Prometheus do Java Virtual Machine (JVM), Java e Tomcat (Catalina) usando o JMX Exporter. Para obter mais informações, consulte [ prometheus/jmx\$1exporter](https://github.com/prometheus/jmx_exporter) no Github.
**Java/JMX em clusters do Amazon EKS e do Kubernetes**
| Nome da métrica | Dimensões |
| --- | --- |
| `jvm_classes_loaded` | `ClusterName`, `Namespace` |
| `jvm_threads_current` | `ClusterName`, `Namespace` |
| `jvm_threads_daemon` | `ClusterName`, `Namespace` |
| `java_lang_operatingsystem_totalswapspacesize` | `ClusterName`, `Namespace` |
| `java_lang_operatingsystem_systemcpuload` | `ClusterName`, `Namespace` |
| `java_lang_operatingsystem_processcpuload` | `ClusterName`, `Namespace` |
| `java_lang_operatingsystem_freeswapspacesize` | `ClusterName`, `Namespace` |
| `java_lang_operatingsystem_totalphysicalmemorysize` | `ClusterName`, `Namespace` |
| `java_lang_operatingsystem_freephysicalmemorysize` | `ClusterName`, `Namespace` |
| `java_lang_operatingsystem_openfiledescriptorcount` | `ClusterName`, `Namespace` |
| `java_lang_operatingsystem_availableprocessors` | `ClusterName`, `Namespace` |
| `jvm_memory_bytes_used` | `ClusterName`, `Namespace`, área |
| `jvm_memory_pool_bytes_used` | `ClusterName`, `Namespace`, grupo |
**nota**
Os valores da dimensão `area` podem ser `heap` ou `nonheap`.
Os valores da dimensão `pool` podem ser `Tenured Gen`, `Compress Class Space`, `Survivor Space`, `Eden Space`, `Code Cache` ou `Metaspace`.
**Tomcat/JMX em clusters do Amazon EKS e do Kubernetes**
Além das métricas Java/JMX na tabela anterior, as métricas a seguir também são coletadas para a workload do Tomcat.
| Nome da métrica | Dimensões |
| --- | --- |
| `catalina_manager_activesessions` | `ClusterName`, `Namespace` |
| `catalina_manager_rejectedsessions` | `ClusterName`, `Namespace` |
| `catalina_globalrequestprocessor_bytesreceived` | `ClusterName`, `Namespace` |
| `catalina_globalrequestprocessor_bytessent` | `ClusterName`, `Namespace` |
| `catalina_globalrequestprocessor_requestcount` | `ClusterName`, `Namespace` |
| `catalina_globalrequestprocessor_errorcount` | `ClusterName`, `Namespace` |
| `catalina_globalrequestprocessor_processingtime` | `ClusterName`, `Namespace` |
**Java/JMX em clusters do Amazon ECS**
| Nome da métrica | Dimensões |
| --- | --- |
| `jvm_classes_loaded` | `ClusterName`, `TaskDefinitionFamily` |
| `jvm_threads_current` | `ClusterName`, `TaskDefinitionFamily` |
| `jvm_threads_daemon` | `ClusterName`, `TaskDefinitionFamily` |
| `java_lang_operatingsystem_totalswapspacesize` | `ClusterName`, `TaskDefinitionFamily` |
| `java_lang_operatingsystem_systemcpuload` | `ClusterName`, `TaskDefinitionFamily` |
| `java_lang_operatingsystem_processcpuload` | `ClusterName`, `TaskDefinitionFamily` |
| `java_lang_operatingsystem_freeswapspacesize` | `ClusterName`, `TaskDefinitionFamily` |
| `java_lang_operatingsystem_totalphysicalmemorysize` | `ClusterName`, `TaskDefinitionFamily` |
| `java_lang_operatingsystem_freephysicalmemorysize` | `ClusterName`, `TaskDefinitionFamily` |
| `java_lang_operatingsystem_openfiledescriptorcount` | `ClusterName`, `TaskDefinitionFamily` |
| `java_lang_operatingsystem_availableprocessors` | `ClusterName`, `TaskDefinitionFamily` |
| `jvm_memory_bytes_used` | `ClusterName`, TaskDefinitionFamily, área |
| `jvm_memory_pool_bytes_used` | `ClusterName`, TaskDefinitionFamily, grupo |
**nota**
Os valores da dimensão `area` podem ser `heap` ou `nonheap`.
Os valores da dimensão `pool` podem ser `Tenured Gen`, `Compress Class Space`, `Survivor Space`, `Eden Space`, `Code Cache` ou `Metaspace`.
**Tomcat/JMX em clusters do Amazon ECS**
Além das métricas Java/JMX na tabela anterior, as métricas a seguir também são coletadas para a workload do Tomcat em clusters do Amazon ECS.
| Nome da métrica | Dimensões |
| --- | --- |
| `catalina_manager_activesessions` | `ClusterName`, `TaskDefinitionFamily` |
| `catalina_manager_rejectedsessions` | `ClusterName`, `TaskDefinitionFamily` |
| `catalina_globalrequestprocessor_bytesreceived` | `ClusterName`, `TaskDefinitionFamily` |
| `catalina_globalrequestprocessor_bytessent` | `ClusterName`, `TaskDefinitionFamily` |
| `catalina_globalrequestprocessor_requestcount` | `ClusterName`, `TaskDefinitionFamily` |
| `catalina_globalrequestprocessor_errorcount` | `ClusterName`, `TaskDefinitionFamily` |
| `catalina_globalrequestprocessor_processingtime` | `ClusterName`, `TaskDefinitionFamily` |
## Métricas do Prometheus para HAProxy
As métricas a seguir são coletadas automaticamente do HAProxy em clusters do Amazon EKS e do Kubernetes.
As métricas coletadas dependem da versão do HAProxy Ingress que você está usando. Para obter mais informações sobre o HAProxy Ingress e suas versões, consulte [haproxy-ingress](https://artifacthub.io/packages/helm/haproxy-ingress/haproxy-ingress).
| Nome da métrica | Dimensões | Disponibilidade |
| --- | --- | --- |
| `haproxy_backend_bytes_in_total` | `ClusterName`, `Namespace`, serviço | Todas as versões do HAProxy Ingress |
| `haproxy_backend_bytes_out_total` | `ClusterName`, `Namespace`, serviço | Todas as versões do HAProxy Ingress |
| `haproxy_backend_connection_errors_total` | `ClusterName`, `Namespace`, serviço | Todas as versões do HAProxy Ingress |
| `haproxy_backend_connections_total` | `ClusterName`, `Namespace`, serviço | Todas as versões do HAProxy Ingress |
| `haproxy_backend_current_sessions` | `ClusterName`, `Namespace`, serviço | Todas as versões do HAProxy Ingress |
| `haproxy_backend_http_responses_total` | `ClusterName`, `Namespace`, Serviço, código, backend | Todas as versões do HAProxy Ingress |
| `haproxy_backend_status` | `ClusterName`, `Namespace`, serviço | Somente nas versões 0.10 ou posteriores do HAProxy Ingress |
| `haproxy_backend_up` | `ClusterName`, `Namespace`, serviço | Somente nas versões do HAProxy Ingress anteriores à 0.10 |
| `haproxy_frontend_bytes_in_total` | `ClusterName`, `Namespace`, serviço | Todas as versões do HAProxy Ingress |
| `haproxy_frontend_bytes_out_total` | `ClusterName`, `Namespace`, serviço | Todas as versões do HAProxy Ingress |
| `haproxy_frontend_connections_total` | `ClusterName`, `Namespace`, serviço | Todas as versões do HAProxy Ingress |
| `haproxy_frontend_current_sessions` | `ClusterName`, `Namespace`, serviço | Todas as versões do HAProxy Ingress |
| `haproxy_frontend_http_requests_total` | `ClusterName`, `Namespace`, serviço | Todas as versões do HAProxy Ingress |
| `haproxy_frontend_http_responses_total` | `ClusterName`, `Namespace`, Serviço, código, frontend | Todas as versões do HAProxy Ingress |
| `haproxy_frontend_request_errors_total` | `ClusterName`, `Namespace`, serviço | Todas as versões do HAProxy Ingress |
| `haproxy_frontend_requests_denied_total` | `ClusterName`, `Namespace`, serviço | Todas as versões do HAProxy Ingress |
**nota**
Os valores da dimensão `code` podem ser `1xx`, `2xx`, `3xx`, `4xx`, `5xx` ou `other`.
Os valores da dimensão `backend` podem ser:
`http-default-backend`, `http-shared-backend` ou `httpsback-shared-backend` para HAProxy Ingress versão 0.0.27 ou anteriores.
`_default_backend` para versões HAProxy Ingress posteriores a 0.0.27.
Os valores da dimensão `frontend` podem ser:
`httpfront-default-backend`, `httpfront-shared-frontend` ou `httpfronts` para HAProxy Ingress versão 0.0.27 ou anteriores.
`_front_http` ou `_front_https` para versões HAProxy Ingress posteriores a 0.0.27.
# Visualizar as métricas do Prometheus
Você pode monitorar e utilizar alarmes com todas as métricas do Prometheus, incluindo as métricas selecionadas e pré-agregadas do App Mesh, NGINX, Java/JMX, Memcached e HAProxy, e qualquer outro exportador do Prometheus, configurado manualmente, que você possa ter adicionado. Para obter mais informações sobre como coletar métricas de outros exportadores do Prometheus, consulte [Tutorial para adicionar um novo destino de extração do Prometheus: métricas do servidor de API do Prometheus](ContainerInsights-Prometheus-Setup-configure.md#ContainerInsights-Prometheus-Setup-new-exporters).
No console do CloudWatch, o Container Insights fornece os seguintes relatórios pré-criados:
+ Para clusters do Amazon EKS e do Kubernetes, há relatórios pré-criados para App Mesh, NGINX, HAPROXY, Memcached e Java/JMX.
+ Para clusters do Amazon ECS, há relatórios pré-compilados para App Mesh e Java/JMX.
O Container Insights também fornece painéis personalizados para cada uma das workloads das quais o Container Insights coleta métricas selecionadas. É possível baixar esses painéis no GitHub
**Como visualizar todas as métricas do Prometheus**
1. Abra o console do CloudWatch em [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).
1. No painel de navegação, selecione **Métricas**.
1. Na lista de namespaces, escolha **ContainerInsights/Prometheus** or **ECS/ContainerInsights/Prometheus**.
1. Escolha um dos conjuntos de dimensões na lista a seguir. Marque a caixa de seleção ao lado das métricas que você deseja visualizar.
**Como visualizar relatórios pré-compilados sobre as métricas do Prometheus**
1. Abra o console do CloudWatch, em [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).
1. No painel de navegação, selecione **Performance Monitoring (Monitoramento de performance)**.
1. Na caixa suspensa perto da parte superior da página, escolha qualquer uma das opções do Prometheus.
Na outra caixa suspensa, escolha um cluster a ser visualizado
Também fornecemos painéis personalizados para NGINX, App Mesh, Memcached, HAProxy e Java/JMX.
**Como usar um painel personalizado fornecido pela Amazon**
1. Abra o console do CloudWatch, em [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).
1. No painel de navegação, escolha **Painéis**.
1. Escolha **Create dashboard (Criar painel)**. Insira um nome para o novo painel e escolha **Create dashboard (Criar painel)**.
1. Em **Add to this dashboard (Adicionar a este painel)**, escolha **Cancel (Cancelar)**.
1. Escolha **Actions (Ações)**, **View/edit source (Exibir/editar origem)**.
1. Faça download de um dos arquivos JSON a seguir:
+ [ Origem do painel personalizado NGINX no Github](https://raw.githubusercontent.com/aws-samples/amazon-cloudwatch-container-insights/latest/k8s-deployment-manifest-templates/deployment-mode/service/cwagent-prometheus/sample_cloudwatch_dashboards/nginx-ingress/cw_dashboard_nginx_ingress_controller.json).
+ [ Origem do painel personalizado App Mesh no Github](https://raw.githubusercontent.com/aws-samples/amazon-cloudwatch-container-insights/latest/k8s-deployment-manifest-templates/deployment-mode/service/cwagent-prometheus/sample_cloudwatch_dashboards/appmesh/cw_dashboard_awsappmesh.json).
+ [ Origem do painel personalizado Memcached no Github](https://raw.githubusercontent.com/aws-samples/amazon-cloudwatch-container-insights/latest/k8s-deployment-manifest-templates/deployment-mode/service/cwagent-prometheus/sample_cloudwatch_dashboards/memcached/cw_dashboard_memcached.json)
+ [ Origem do painel personalizado HAProxy-Ingress no Github](https://raw.githubusercontent.com/aws-samples/amazon-cloudwatch-container-insights/latest/k8s-deployment-manifest-templates/deployment-mode/service/cwagent-prometheus/sample_cloudwatch_dashboards/haproxy-ingress/cw_dashboard_haproxy_ingress.json)
+ [ Origem do painel personalizado Java/JMX no Github](https://raw.githubusercontent.com/aws-samples/amazon-cloudwatch-container-insights/latest/k8s-deployment-manifest-templates/deployment-mode/service/cwagent-prometheus/sample_cloudwatch_dashboards/javajmx/cw_dashboard_javajmx.json).
1. Abra o arquivo JSON obtido por download com um editor de textos e faça as seguintes alterações:
+ Substitua todas as strings `{{YOUR_CLUSTER_NAME}}` pelo nome exato do cluster. Não adicione espaços em branco antes ou depois do texto.
+ Substitua todos as strings `{{YOUR_REGION}}` pela região da AWS em que o cluster está em execução. Por exemplo, **us-west-1** Não adicione espaços em branco antes ou depois do texto.
+ Substitua todas as strings `{{YOUR_NAMESPACE}}` pelo namespace exato da workload.
+ Substitua todas as strings `{{YOUR_SERVICE_NAME}}` pelo nome de serviço exato da workload. Por exemplo, **haproxy-haproxy-ingress-controller-metrics**
1. Copie todo o blob JSON e cole-o na caixa de texto no console do CloudWatch, substituindo o que já está na caixa.
1. Escolha **Update (Atualizar)**, **Save dashboard (Salvar painel)**.
# Solucionar problemas de métricas do Prometheus
Esta seção fornece ajuda para solucionar problemas de configuração de métricas do Prometheus.
**Topics**
+ [Solucionar problemas de métricas do Prometheus no Amazon ECS](ContainerInsights-Prometheus-troubleshooting-ECS.md)
+ [Solucionar problemas de métricas do Prometheus em clusters do Amazon EKS e do Kubernetes](ContainerInsights-Prometheus-troubleshooting-EKS.md)
# Solucionar problemas de métricas do Prometheus no Amazon ECS
Esta seção fornece ajuda para solucionar problemas de configuração de métricas do Prometheus em clusters do Amazon ECS.
## Não visualizo as métricas do Prometheus enviadas ao CloudWatch Logs
As métricas do Prometheus devem ser ingeridas como eventos de log no grupo de logs **/aws/ecs/containerinsights/cluster-name/Prometheus**. Se o grupo de logs não estiver criado ou se as métricas do Prometheus não forem enviadas ao grupo de logs, primeiro você precisará conferir se os destinos do Prometheus foram detectados corretamente pelo atendente do CloudWatch. Em seguida, confira o grupo de segurança e as configurações de permissão do atendente do CloudWatch. As etapas a seguir orientam a fazer a depuração.
**Etapa 1: habilitar o modo de depuração do atendente do CloudWatch**
Primeiro, altere o atendente do CloudWatch para o modo de depuração adicionando as seguintes linhas em negrito ao modelo de arquivo do CloudFormation: `cwagent-ecs-prometheus-metric-for-bridge-host.yaml` ou `cwagent-ecs-prometheus-metric-for-awsvpc.yaml`. Salve o arquivo.
```
cwagentconfig.json: |
{
"agent": {
"debug": true
},
"logs": {
"metrics_collected": {
```
Criar um novo changeset do CloudFormation em relação à pilha existente. Defina outros parâmetros do changeset para os mesmos valores de sua pilha do CloudFormation existente. O exemplo a seguir é de um atendente do CloudWatch instalado em um cluster do Amazon ECS usando o tipo de inicialização do EC2 e o modo de rede de ponte.
```
ECS_NETWORK_MODE=bridge
CREATE_IAM_ROLES=True
ECS_TASK_ROLE_NAME=your_selected_ecs_task_role_name
ECS_EXECUTION_ROLE_NAME=your_selected_ecs_execution_role_name
NEW_CHANGESET_NAME=your_selected_ecs_execution_role_name
aws cloudformation create-change-set --stack-name CWAgent-Prometheus-ECS-${ECS_CLUSTER_NAME}-EC2-${ECS_NETWORK_MODE} \
--template-body file://cwagent-ecs-prometheus-metric-for-bridge-host.yaml \
--parameters ParameterKey=ECSClusterName,ParameterValue=$ECS_CLUSTER_NAME \
ParameterKey=CreateIAMRoles,ParameterValue=$CREATE_IAM_ROLES \
ParameterKey=ECSNetworkMode,ParameterValue=$ECS_NETWORK_MODE \
ParameterKey=TaskRoleName,ParameterValue=$ECS_TASK_ROLE_NAME \
ParameterKey=ExecutionRoleName,ParameterValue=$ECS_EXECUTION_ROLE_NAME \
--capabilities CAPABILITY_NAMED_IAM \
--region $AWS_REGION \
--change-set-name $NEW_CHANGESET_NAME
```
Acesse o console do CloudFormation para revisar o novo changeset, `$NEW_CHANGESET_NAME`. Deve haver uma alteração aplicada ao recurso **CWAgentConfigSSMParameter**. Execute o changeset e reinicie a tarefa do atendente do CloudWatch inserindo os comandos a seguir.
```
aws ecs update-service --cluster $ECS_CLUSTER_NAME \
--desired-count 0 \
--service your_service_name_here \
--region $AWS_REGION
```
Aguarde cerca de 10 segundos e insira o comando a seguir.
```
aws ecs update-service --cluster $ECS_CLUSTER_NAME \
--desired-count 1 \
--service your_service_name_here \
--region $AWS_REGION
```
**Etapa 2: verificar os logs de detecção de serviço do ECS**
Por padrão, a definição de tarefa do ECS do atendente do CloudWatch habilita os logs na seção abaixo. Os logs são enviados ao CloudWatch Logs no grupo de logs **/ecs/ecs-cwagent-prometheus**.
```
LogConfiguration:
LogDriver: awslogs
Options:
awslogs-create-group: 'True'
awslogs-group: "/ecs/ecs-cwagent-prometheus"
awslogs-region: !Ref AWS::Region
awslogs-stream-prefix: !Sub 'ecs-${ECSLaunchType}-awsvpc'
```
Filtrar os logs pela string `ECS_SD_Stats` para obter as métricas relacionadas à detecção de serviços do ECS, conforme mostrado no exemplo a seguir.
```
2020-09-1T01:53:14Z D! ECS_SD_Stats: AWSCLI_DescribeContainerInstances: 1
2020-09-1T01:53:14Z D! ECS_SD_Stats: AWSCLI_DescribeInstancesRequest: 1
2020-09-1T01:53:14Z D! ECS_SD_Stats: AWSCLI_DescribeTaskDefinition: 2
2020-09-1T01:53:14Z D! ECS_SD_Stats: AWSCLI_DescribeTasks: 1
2020-09-1T01:53:14Z D! ECS_SD_Stats: AWSCLI_ListTasks: 1
2020-09-1T01:53:14Z D! ECS_SD_Stats: Exporter_DiscoveredTargetCount: 1
2020-09-1T01:53:14Z D! ECS_SD_Stats: LRUCache_Get_EC2MetaData: 1
2020-09-1T01:53:14Z D! ECS_SD_Stats: LRUCache_Get_TaskDefinition: 2
2020-09-1T01:53:14Z D! ECS_SD_Stats: LRUCache_Size_ContainerInstance: 1
2020-09-1T01:53:14Z D! ECS_SD_Stats: LRUCache_Size_TaskDefinition: 2
2020-09-1T01:53:14Z D! ECS_SD_Stats: Latency: 43.399783ms
```
O significado de cada métrica para determinado ciclo de detecção de serviços do ECS é o seguinte:
+ **AWSCLI\$1DescribeContainerInstances**: o número de chamadas de API `ECS::DescribeContainerInstances` realizadas.
+ **AWSCLI\$1DescribeInstancesRequest**: o número de chamadas de API `ECS::DescribeInstancesRequest` realizadas.
+ **AWSCLI\$1DescribeTaskDefinition**: o número de chamadas de API `ECS::DescribeTaskDefinition` realizadas.
+ **AWSCLI\$1DescribeTasks**: o número de chamadas de API `ECS::DescribeTasks` realizadas.
+ **AWSCLI\$1ListTasks**: o número de chamadas de API `ECS::ListTasks` realizadas.
+ **ExporterDiscoveredTargetCount**: o número de destinos do Prometheus que foram detectados e exportados corretamente para o arquivo de resultados de destino dentro do contêiner.
+ **LRUCache\$1Get\$1EC2MetaData**: o número de vezes em que os metadados de instâncias de contêiner foram recuperados do cache.
+ **LRUCache\$1Get\$1TaskDefinition**: o número de vezes que os metadados de definição de tarefa do ECS foram recuperados do cache.
+ **LRUCache\$1Size\$1ContainerInstance**: o número de metadados da instância de contêiner exclusiva armazenados em cache na memória.
+ **LRUCache\$1Size\$1TaskDefinition**: o número de definições de tarefa de ECS exclusivas armazenadas em cache na memória.
+ **Latency**: quanto tempo demora o ciclo de detecção de serviços.
Confira o valor de `ExporterDiscoveredTargetCount` para ver se os destinos detectados do Prometheus correspondem a suas expectativas. Caso contrário, os possíveis motivos são:
+ A configuração da detecção de serviços do ECS pode não corresponder à configuração de sua aplicação. Para a detecção de serviços baseada em rótulos do docker, seus contêineres de destino talvez não tenham o rótulo do docker necessário configurado no atendente do CloudWatch para detectá-los automaticamente. Para a detecção de serviços baseada em expressão regular do ARN da definição de tarefa do ECS, a configuração regex no atendente do CloudWatch pode não corresponder à definição de tarefa da aplicação.
+ A função da tarefa do ECS do atendente do CloudWatch pode não ter permissão para recuperar os metadados das tarefas do ECS. Verifique se o atendente do CloudWatch recebeu as seguintes permissões somente para leitura:
+ `ec2:DescribeInstances`
+ `ecs:ListTasks`
+ `ecs:DescribeContainerInstances`
+ `ecs:DescribeTasks`
+ `ecs:DescribeTaskDefinition`
**Etapa 3: verificar a conexão de rede e a política de função de tarefa do ECS**
Se ainda não houver eventos de log enviados ao grupo de logs do CloudWatch Logs de destino, mesmo que o valor de `Exporter_DiscoveredTargetCount` indique que há destinos do Prometheus detectados, isso pode ser causado por uma destas situações:
+ O atendente do CloudWatch talvez não consiga se conectar às portas de destino do Prometheus. Verifique a configuração do grupo de segurança por trás do atendente do CloudWatch. O IP privado deve permitir que o atendente do CloudWatch se conecte às portas do exportador do Prometheus.
+ A função da tarefa do ECS do atendente do CloudWatch talvez não tenha a política gerenciada **CloudWatchAgentServerPolicy**. A função da tarefa do ECS do atendente do CloudWatch precisa ter essa política para poder enviar as métricas do Prometheus como eventos de log. Se você usou o modelo do CloudFormation para criar as funções do IAM automaticamente, tanto a função da tarefa do ECS como a função de execução do ECS são concedidas com o menor privilégio para executar o monitoramento do Prometheus.
# Solucionar problemas de métricas do Prometheus em clusters do Amazon EKS e do Kubernetes
Esta seção fornece ajuda para solucionar problemas de configuração de métricas do Prometheus em clusters do Amazon EKS e do Kubernetes.
## Etapas gerais de solução de problemas no Amazon EKS
Insira o comando a seguir para confirmar se o atendente do CloudWatch está em execução.
```
kubectl get pod -n amazon-cloudwatch
```
A saída deve incluir uma linha com `cwagent-prometheus-id` na coluna `NAME`, e `Running` no campo `STATUS column.`
Para exibir detalhes sobre o pod em execução, insira o comando a seguir. Substitua o *pod-name* pelo nome completo do pod que tem o nome que começa com `cw-agent-prometheus`.
```
kubectl describe pod pod-name -n amazon-cloudwatch
```
Se você tiver o CloudWatch Container Insights instalado, poderá usar o CloudWatch Logs Insights para consultar os logs do atendente do CloudWatch que coleta as métricas do Prometheus.
**Como consultar os logs do aplicativo**
1. Abra o console do CloudWatch, em [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).
1. No painel de navegação, em Logs, escolha **CloudWatch Logs Insights**.
1. Selecione o grupo de logs para os logs do aplicativo, **/aws/containerinsights/*cluster-name*/application**
1. Substitua a expressão de consulta de pesquisa pela seguinte consulta e escolha **Run query (Executar consulta)**
```
fields ispresent(kubernetes.pod_name) as haskubernetes_pod_name, stream, kubernetes.pod_name, log |
filter haskubernetes_pod_name and kubernetes.pod_name like /cwagent-prometheus
```
Você também pode confirmar se as métricas e os metadados do Prometheus estão sendo ingeridos como eventos do CloudWatch Logs.
**Como confirmar se os dados do Prometheus estão sendo ingeridos**
1. Abra o console do CloudWatch, em [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).
1. No painel de navegação, em Logs, escolha **CloudWatch Logs Insights**.
1. Selecione **/aws/containerinsights/*cluster-name*/prometheus**
1. Substitua a expressão de consulta de pesquisa pela seguinte consulta e escolha **Run query (Executar consulta)**
```
fields @timestamp, @message | sort @timestamp desc | limit 20
```
## Registrar as métricas descartadas do Prometheus
Essa versão não coleta métricas do Prometheus do tipo histograma. Você pode usar o atendente do CloudWatch para verificar se alguma métrica do Prometheus está sendo descartada por ser de uma métrica de histograma. Também é possível registrar em log uma lista das primeiras 500 métricas do Prometheus que forem descartadas e não enviadas ao CloudWatch por serem métricas de histograma.
Para ver se alguma métrica está sendo descartada, insira o comando a seguir:
```
kubectl logs -l "app=cwagent-prometheus" -n amazon-cloudwatch --tail=-1
```
Se alguma métrica estiver sendo descartada, você verá as seguintes linhas no arquivo `/opt/aws/amazon-cloudwatch-agent/logs/amazon-cloudwatch-agent.log`.
```
I! Drop Prometheus metrics with unsupported types. Only Gauge, Counter and Summary are supported.
I! Please enable CWAgent debug mode to view the first 500 dropped metrics
```
Se você vir essas linhas e quiser saber quais métricas estão sendo descartadas, siga as etapas a seguir.
**Como registrar em log uma lista de métricas descartadas do Prometheus**
1. Altere o atendente do CloudWatch para o modo de depuração adicionando as seguintes linhas em negrito ao arquivo `prometheus-eks.yaml` ou `prometheus-k8s.yaml` e salve o arquivo.
```
{
"agent": {
"debug": true
},
```
Esta seção do arquivo deve ser semelhante ao seguinte:
```
cwagentconfig.json: |
{
"agent": {
"debug": true
},
"logs": {
"metrics_collected": {
```
1. Reinstale o atendente do CloudWatch para habilitar o modo de depuração inserindo os comandos a seguir:
```
kubectl delete deployment cwagent-prometheus -n amazon-cloudwatch
kubectl apply -f prometheus.yaml
```
As métricas descartadas são registradas no pod do atendente do CloudWatch.
1. Para recuperar os logs do pod do atendente do CloudWatch, insira o comando a seguir:
```
kubectl logs -l "app=cwagent-prometheus" -n amazon-cloudwatch --tail=-1
```
Ou, se você tiver a geração de logs do Fluentd do Container Insights instalada, os logs também serão salvos no grupo de logs do CloudWatch Logs **/aws/containerinsights/*cluster\$1name*/application**.
Para consultar esses logs, você pode seguir as etapas para consultar os logs do aplicativo em [Etapas gerais de solução de problemas no Amazon EKS](#ContainerInsights-Prometheus-troubleshooting-general).
## Onde estão as métricas do Prometheus ingeridas como eventos de log do CloudWatch Logs?
O atendente do CloudWatch cria um fluxo de logs para cada configuração do trabalho de extração do Prometheus. Por exemplo, nos arquivos `prometheus-eks.yaml` e `prometheus-k8s.yaml`, a linha `job_name: 'kubernetes-pod-appmesh-envoy'` extrai conteúdo de métricas do App Mesh. O alvo do Prometheus é definido como `kubernetes-pod-appmesh-envoy`. Portanto, todas as métricas do App Mesh Prometheus são ingeridas como eventos do CloudWatch Logs no fluxo de logs **kubernetes-pod-appmesh-envoy** no grupo de logs chamado **/aws/containerinsights/cluster-name/Prometheus**.
## Não visualizo métricas do Amazon EKS ou do Kubernetes Prometheus nas métricas do CloudWatch
Primeiro, verifique se as métricas do Prometheus são ingeridas como eventos de log no grupo de logs **/aws/containerinsights/cluster-name/Prometheus**. Use as informações em [Onde estão as métricas do Prometheus ingeridas como eventos de log do CloudWatch Logs?](#ContainerInsights-Prometheus-troubleshooting-metrics_ingested) para ajudar a verificar o fluxo de logs de destino. Se o fluxo de logs não foi criado ou não houver novos eventos de log no fluxo de logs, confira o seguinte:
+ Verifique se os endpoints do exportador de métricas do Prometheus estão configurados corretamente
+ Verifique se as configurações de extração de conteúdo do Prometheus na seção `config map: cwagent-prometheus` do arquivo YAML do atendente do CloudWatch estão corretas. A configuração deve ser a mesma de um arquivo de configuração do Prometheus. Para obter mais informações, consulte [](https://prometheus.io/docs/prometheus/latest/configuration/configuration/#scrape_config) na documentação do Prometheus.
Se as métricas do Prometheus foram corretamente ingeridas como eventos de log, verifique se as configurações de formato de métrica incorporadas foram adicionadas aos eventos de log para gerar as métricas do CloudWatch.
```
"CloudWatchMetrics":[
{
"Metrics":[
{
"Name":"envoy_http_downstream_cx_destroy_remote_active_rq"
}
],
"Dimensions":[
[
"ClusterName",
"Namespace"
]
],
"Namespace":"ContainerInsights/Prometheus"
}
],
```
Para obter mais informações sobre o formato de métrica incorporado, consulte [Especificação: formato de métricas incorporadas](CloudWatch_Embedded_Metric_Format_Specification.md).
Se não houver nenhum formato de métrica incorporado nos eventos de log, verifique se a seção `metric_declaration` está configurada corretamente na seção `config map: prometheus-cwagentconfig` do arquivo YAML de instalação do atendente do CloudWatch. Para obter mais informações, consulte [Tutorial para adicionar um novo destino de extração do Prometheus: métricas do servidor de API do Prometheus](ContainerInsights-Prometheus-Setup-configure.md#ContainerInsights-Prometheus-Setup-new-exporters).
# Integração ao Application Insights
O Amazon CloudWatch Application Insights ajuda a monitorar suas aplicações, além de identificar e configurar as principais métricas, logs e alarmes nos recursos da aplicação e pilha de tecnologia. Para obter mais informações, consulte [Detectar problemas comuns de aplicações com o CloudWatch Application Insights](cloudwatch-application-insights.md).
Você pode habilitar o Application Insights para coletar dados adicionais de suas aplicações e microsserviços conteinerizados. Se ainda não fez isso, poderá habilitá-lo escolhendo **Auto-configure Application Insights** (Configurar automaticamente o Application Insights) abaixo da visualização de performance no painel Container Insights.
Se você já configurou o CloudWatch Application Insights para monitorar suas aplicações em contêiner, o painel do Application Insights aparecerá abaixo do painel do Container Insights.
Para obter mais informações sobre o Application Insights e aplicações em contêiner, consulte [Habilitar o Application Insights para monitoramento de recursos do Amazon ECS e do Amazon EKS](appinsights-setting-up-console.md#appinsights-container-insights).
# Visualização dos eventos do ciclo de vida do Amazon ECS no Container Insights
É possível visualizar os eventos do ciclo de vida do Amazon ECS no console do Container Insights. Isso ajuda a correlacionar suas métricas, logs e eventos de contêiner em uma única visualização para oferecer uma visibilidade operacional mais completa.
Os eventos incluem eventos de alteração de estado da instância de contêiner, eventos de alteração de estado de tarefas e eventos de ação de serviços. São enviados automaticamente pelo Amazon ECS ao Amazon EventBridge e também são coletados no CloudWatch no formato de log de eventos. Para obter mais informações sobre esses eventos, consulte [Eventos do Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs_cwe_events.html).
Os preços padrão do Container Insights se aplicam a eventos de ciclo de vida do Amazon ECS. Para obter mais informações, consulte [Preços do Amazon CloudWatch](https://aws.amazon.com/cloudwatch/pricing/).
Para configurar a tabela de eventos do ciclo de vida e criar regras para um cluster, é necessário ter as permissões `events:PutRule`, `events:PutTargets` e `logs:CreateLogGroup`. Você também deve se certificar de que há uma política de recursos que permite que o EventBridge crie o fluxo de logs e envie os logs para o CloudWatch Logs. Se essa política de recursos não existir, você pode digitar o seguinte comando para criá-la:
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"logs:CreateLogStream",
"logs:PutLogEvents"
],
"Principal": {
"Service": ["events.amazonaws.com", "delivery.logs.amazonaws.com"]
},
"Resource": "arn:aws:logs:us-east-1:111122223333:log-group:/aws/events/ecs/containerinsights/*:*",
"Condition": {
"StringEquals": {
"aws:SourceAccount": "111122223333"
},
"ArnLike": {
"aws:SourceArn": "arn:aws:events:us-east-1:111122223333:rule/eventsToLog*"
}
},
"Sid": "TrustEventBridgeToStoreECSLifecycleLogEvents"
}
]
}
```
------
Você pode usar o comando a seguir para verificar se você já possui essa política e para confirmar se a anexação funcionou corretamente.
```
aws logs describe-resource-policies --region region --output json
```
Para visualizar a tabela de eventos do ciclo de vida, é necessário ter as permissões `events:DescribeRule`, `events:ListTargetsByRule` e `logs:DescribeLogGroups`.
**Como visualizar os eventos do ciclo de vida do Amazon ECS no console do CloudWatch Container Insights**
1. Abra o console do CloudWatch, em [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).
1. Escolha **Insights**, **Container Insights**.
1. Escolha **Exibir painéis de desempenho**.
1. No próximo menu suspenso, escolha entre **ECS Clusters** (Clusters do ECS), **ECS Services** (Serviços do ECS) ou **ECS Tasks** (Tarefas do ECS).
1. Se você escolheu **ECS Services** (Serviços do ECS) ou **ECS Tasks** (Tarefas do ECS) na etapa anterior, escolha a guia **Lifecycle events** (Eventos do ciclo de vida).
1. Na parte inferior da página, se você visualizar **Configure lifecycle events** (Configurar eventos do ciclo de vida), escolha essa opção para criar regras do EventBridge para o cluster.
Os eventos são exibidos abaixo dos painéis do Container Insights e acima da seção Application Insights. Para executar mais analytics e criar outras visualizações sobre esses eventos, escolha **Exibir no Logs Insights** na tabela Eventos do ciclo de vida.
# Solução de problemas do Container Insights
As seções a seguir podem ajudar se você estiver tendo problemas com o Container Insights.
## Falha na implantação no Amazon EKS ou no Kubernetes
Se o atendente não for implantado corretamente em um cluster do Kubernetes, tente o seguinte:
+ Execute o comando a seguir para obter a lista de pods.
```
kubectl get pods -n amazon-cloudwatch
```
+ Execute o comando a seguir e verifique os eventos na parte inferior da saída.
```
kubectl describe pod pod-name -n amazon-cloudwatch
```
+ Execute o comando a seguir para verificar os logs.
```
kubectl logs pod-name -n amazon-cloudwatch
```
## Pânico não autorizado: não é possível recuperar dados cadvisor do kubelet
Se a implantação falhar com o erro `Unauthorized panic: Cannot retrieve cadvisor data from kubelet`, o kubelet talvez não tenha o modo de autorização Webhook habilitado. Esse modo é necessário para o Container Insights. Para obter mais informações, consulte [Verificação dos pré-requisitos para o Container Insights no CloudWatch](Container-Insights-prerequisites.md).
## Implantar o Container Insights em um cluster excluído e recriado no Amazon ECS
Se você excluir um cluster existente do Amazon ECS que não tenha o Container Insights habilitado e recriá-lo com o mesmo nome, não será possível habilitar o Container Insights nesse novo cluster ao recriá-lo. Você pode habilitá-lo recriando-o e inserindo o seguinte comando:
```
aws ecs update-cluster-settings --cluster myCICluster --settings name=container Insights,value=enabled
```
## Erro de endpoint inválido
Se você vir uma mensagem de erro semelhante à seguinte, verifique se você substituiu todos os espaços reservados, como *cluster-name* e *region-name* nos comandos que você está usando pelas informações corretas para sua implantação.
```
"log": "2020-04-02T08:36:16Z E! cloudwatchlogs: code: InvalidEndpointURL, message: invalid endpoint uri, original error: &url.Error{Op:\"parse\", URL:\"https://logs.{{region_name}}.amazonaws.com/\", Err:\"{\"}, &awserr.baseError{code:\"InvalidEndpointURL\", message:\"invalid endpoint uri\", errs:[]error{(*url.Error)(0xc0008723c0)}}\n",
```
## As métricas não são exibidas no console
Se você não vir nenhuma métrica do Container Insights no Console de gerenciamento da AWS, certifique-se de que você tenha concluído a configuração do Container Insights. As métricas não serão exibidas antes de o Container Insights ser configurado completamente. Para obter mais informações, consulte [Configurar o Container Insights](deploy-container-insights.md).
## Métricas de pod ausentes no Amazon EKS ou no Kubernetes após a atualização do cluster
Esta seção pode ser útil se todas ou algumas métricas de pods estiverem ausentes depois de você implantar o agente do CloudWatch como daemonset em um cluster novo ou atualizado, ou se você vir um log de erros com a mensagem `W! No pod metric collected`.
Esses erros podem ser causados por alterações no runtime do contêiner, como containerd ou o driver cgroup systemd do docker. Normalmente, você pode resolver isso atualizando seu manifesto de implantação para que o soquete containerd do host seja montado no contêiner. Veja o exemplo a seguir:
```
# For full example see https://github.com/aws-samples/amazon-cloudwatch-container-insights/blob/latest/k8s-deployment-manifest-templates/deployment-mode/daemonset/container-insights-monitoring/cwagent/cwagent-daemonset.yaml
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: cloudwatch-agent
namespace: amazon-cloudwatch
spec:
template:
spec:
containers:
- name: cloudwatch-agent
# ...
# Don't change the mountPath
volumeMounts:
# ...
- name: dockersock
mountPath: /var/run/docker.sock
readOnly: true
- name: varlibdocker
mountPath: /var/lib/docker
readOnly: true
- name: containerdsock # NEW mount
mountPath: /run/containerd/containerd.sock
readOnly: true
# ...
volumes:
# ...
- name: dockersock
hostPath:
path: /var/run/docker.sock
- name: varlibdocker
hostPath:
path: /var/lib/docker
- name: containerdsock # NEW volume
hostPath:
path: /run/containerd/containerd.sock
```
## Nenhuma métrica de pod ao usar Bottlerocket para o Amazon EKS
O Bottlerocket é um sistema operacional de código aberto baseado em Linux que foi criado especificamente pela AWS para executar contêineres.
O Bottlerocket usa um caminho de `containerd` diferente no host, então é necessário alterar os volumes para o local dele. Se não fizer isso, você verá um erro nos logs que inclui `W! No pod metric collected`. Veja o exemplo a seguir.
```
volumes:
# ...
- name: containerdsock
hostPath:
# path: /run/containerd/containerd.sock
# bottlerocket does not mount containerd sock at normal place
# https://github.com/bottlerocket-os/bottlerocket/commit/91810c85b83ff4c3660b496e243ef8b55df0973b
path: /run/dockershim.sock
```
## Nenhuma métrica do filesystem de contêiner ao usar o runtime do containerd para Amazon EKS ou Kubernetes
Esse é um problema conhecido, e colaboradores da comunidade estão trabalhando nele. Para obter mais informações, consulte [Métrica de uso de disco para conteinerd](https://github.com/google/cadvisor/issues/2785) e [métricas do sistema de arquivos de contêiner não são compatíves com o cadvisor para containerd](https://github.com/aws/amazon-cloudwatch-agent/issues/192) no GitHub.
## Aumento inesperado do volume de log do atendente do CloudWatch ao coletar métricas do Prometheus
Essa foi uma regressão introduzida na versão 1.247347.6b250880 do atendente do CloudWatch. Essa regressão já foi corrigida em versões mais recentes do atendente. Seu impacto foi limitado a cenários em que os clientes coletavam os logs do próprio atendente do CloudWatch e estavam usando o Prometheus. Para obter mais informações, consulte [atendente [do prometheus] está imprimindo todas as métricas extraídas no log](https://github.com/aws/amazon-cloudwatch-agent/issues/209) no GitHub.
## A imagem do Docker mais recente mencionada nas notas de release não foi encontrada no Dockerhub
Atualizamos a nota de release e a etiqueta no Github antes de iniciarmos a versão real internamente. Normalmente, leva de 1 a 2 semanas para ver a imagem do Docker mais recente nos registros depois de bater o número da versão no Github. Não há versão noturna para a imagem do contêiner do atendente do CloudWatch. É possível criar a imagem diretamente da origem no seguinte local: [https://github.com/aws/amazon-cloudwatch-agent/tree/main/amazon-cloudwatch-container-insights/cloudwatch-agent-dockerfile](https://github.com/aws/amazon-cloudwatch-agent/tree/main/amazon-cloudwatch-container-insights/cloudwatch-agent-dockerfile)
## Erro CrashLoopBackoff no atendente do CloudWatch
Ao ver um erro `CrashLoopBackOff` do atendente do CloudWatch, verifique se suas permissões do IAM estão definidas corretamente. Para obter mais informações, consulte [Verificação dos pré-requisitos para o Container Insights no CloudWatch](Container-Insights-prerequisites.md).
## Agente do CloudWatch ou pod do Fluentd travado em pendente
Se você tiver um agente do CloudWatch ou pod do Fluentd travado em `Pending` ou com um erro `FailedScheduling`, determine se seus nós têm recursos de computação suficientes com base no número de núcleos e na quantidade de RAM exigida pelos agentes. Use o comando a seguir para descrever o pod:
```
kubectl describe pod cloudwatch-agent-85ppg -n amazon-cloudwatch
```
# Criar sua própria imagem do Docker do atendente do CloudWatch
Você pode criar sua própria imagem do Docker do atendente do CloudWatch fazendo referência ao Dockerfile localizado em [ https://github.com/aws-samples/amazon-cloudwatch-container-insights/blob/latest/cloudwatch-agent-dockerfile/Dockerfile](https://github.com/aws-samples/amazon-cloudwatch-container-insights/blob/latest/cloudwatch-agent-dockerfile/Dockerfile).
O Dockerfile oferece suporte para criar imagens multiarquitetura diretamente usando `docker buildx`.
# Implantar outros recursos do atendente do CloudWatch nos contêineres
Você pode implantar recursos de monitoramento adicionais em seus contêineres usando o atendente do CloudWatch. Esses recursos incluem o seguinte:
+ **Formato de métrica incorporado**: para obter mais informações, consulte [Incorporação de métricas em logs](CloudWatch_Embedded_Metric_Format.md).
+ **StatsD**: para obter mais informações, consulte [Recuperar métricas personalizadas com o StatsD](CloudWatch-Agent-custom-metrics-statsd.md).
Instruções e arquivos necessários estão localizados nos seguintes locais do GitHub:
+ Para contêineres do Amazon ECS, consulte [Exemplo de definições de tarefas do Amazon ECS com base nos modos de implantação](https://github.com/aws-samples/amazon-cloudwatch-container-insights/tree/latest/ecs-task-definition-templates/deployment-mode).
+ Para contêineres do Amazon EKS e do Kubernetes, consulte [ Exemplo de arquivos YAML do Kubernetes com base nos modos de implantação](https://github.com/aws-samples/amazon-cloudwatch-container-insights/tree/latest/k8s-deployment-manifest-templates/deployment-mode).