# Instalação do agente do CloudWatch com o complemento de observabilidade do EKS do Amazon CloudWatch ou com o chart do Helm
Você pode usar o complemento de observabilidade do EKS do Amazon CloudWatch ou o chart do Helm de observabilidade do Amazon CloudWatch para instalar o agente do CloudWatch e o do Fluent Bit em um cluster do Amazon EKS. Você também pode usar o chart do Helm para instalar o agente do CloudWatch e o do Fluent-bit em um cluster do Kubernetes que não esteja hospedado no Amazon EKS.
O uso de qualquer um dos métodos em um cluster do Amazon EKS habilita o [Container Insights](ContainerInsights.md) com observabilidade aprimorada para o Amazon EKS e o [CloudWatch Application Signals](CloudWatch-Application-Monitoring-Sections.md) por padrão. Os dois recursos ajudam a coletar métricas de infraestrutura, a telemetria de performance da aplicação e os logs de contêiner do cluster.
Com a versão `v6.0.1-eksbuild.1` ou posterior do complemento, o Container Insights com métricas do OpenTelemetry está habilitado, o que coleta métricas usando o OpenTelemetry Protocol (OTLP) e é compatível com consultas do PromQL. Para obter mais informações, consulte [Métricas do Container Insights com OpenTelemetry para Amazon EKS](container-insights-otel-metrics.md).
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 o Application Signals, o faturamento é baseado nas solicitações de entrada para as aplicações, nas solicitações de saída das aplicações e em cada objetivo de nível de serviço (SLO) configurado. Cada solicitação de entrada recebida gera um sinal de aplicação e cada solicitação de saída realizada gera um sinal de aplicação. Cada SLO cria dois sinais de aplicações por período de medição. Para obter mais informações sobre os preços do CloudWatch, consulte [Preço do Amazon CloudWatch](https://aws.amazon.com/cloudwatch/pricing/).
Os dois métodos habilitam o Container Insights em nós de processamento do Linux e do Windows no cluster do Amazon EKS. Para habilitar o Container Insights no Windows, é necessário usar a versão 1.5.0 ou versões posteriores do chart do Helm ou do complemento do Amazon EKS. O Application Signals não é compatível com o sistema Windows em clusters do Amazon EKS.
O complemento Amazon CloudWatch Observability do EKS é compatível com os clusters do Amazon EKS executados com a versão 1.23 ou com versões posteriores do Kubernetes.
Ao instalar o complemento ou o chart do Helm, também é necessário conceder permissões do IAM para possibilitar que o agente do CloudWatch envie métricas, logs e rastreamentos para o CloudWatch. Há duas maneiras de fazer isso:
+ Anexe uma política à função do IAM dos nós de processamento. Essa opção concede permissões aos nós de processamento para enviar telemetria ao CloudWatch.
+ Use um perfil do IAM para contas de serviço dos pods de agentes e anexe a política a esse perfil. Funciona somente para clusters do Amazon EKS. Essa opção dá ao CloudWatch acesso apenas aos pods de agente adequados.
**Topics**
+ [Opção 1: Instalar usando a Identidade de Pods do EKS](#install-CloudWatch-Observability-EKS-pod-identity)
+ [Opção 2: instalar com permissões do IAM nos nós de processamento](#install-CloudWatch-Observability-EKS-addon-workernodes)
+ [Opção 3: instalar usando o perfil da conta de serviço do IAM (aplica-se somente ao uso do complemento)](#install-CloudWatch-Observability-EKS-addon-serviceaccountrole)
+ [Considerações sobre o Amazon EKS Hybrid Nodes](#install-CloudWatch-Observability-EKS-addon-hybrid)
+ [(Opcional) Configuração adicional](#install-CloudWatch-Observability-EKS-addon-configuration)
+ [Coletar métricas do Java Management Extensions (JMX)](#install-CloudWatch-Observability-EKS-addon-JMX-metrics)
+ [Habilitar métricas do Kueue](#enable-Kueue-metrics)
+ [Anexar arquivos de configuração do coletor do OpenTelemetry](#install-CloudWatch-Observability-EKS-addon-OpenTelemetry)
+ [Habilitar APM usando o Application Signals para o cluster do Amazon EKS](#Container-Insights-setup-EKS-appsignalsconfiguration)
+ [Solução de problemas do complemento de observabilidade do EKS do Amazon CloudWatch ou do chart do Helm](#Container-Insights-setup-EKS-addon-troubleshoot)
+ [Optar por não usar o Application Signals](#Opting-out-App-Signals)
## Opção 1: Instalar usando a Identidade de Pods do EKS
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.
Para usar este método, primeiro 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.
Em seguida, instale o complemento de observabilidade do EKS do Amazon CloudWatch. Para instalar o complemento, você pode usar a AWS CLI, o console do Amazon EKS, o CloudFormation ou o Terraform.
------
#### [ AWS CLI ]
**Como usar a AWS CLI para instalar o complemento Amazon CloudWatch Observability do EKS**
Insira os comandos a seguir: Substitua `my-cluster-name` pelo nome do cluster e *111122223333* pelo ID da conta. Substitua *my-role* pelo perfil do IAM que você criou na etapa de associação da Identidade de Pods do EKS.
```
aws iam attach-role-policy \
--role-name my-role \
--policy-arn arn:aws:iam::aws:policy/CloudWatchAgentServerPolicy
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
```
------
#### [ Amazon EKS console ]
**Como usar o console do Amazon EKS para adicionar o complemento Amazon CloudWatch Observability do EKS**
1. Abra o console do Amazon EKS em [https://console.aws.amazon.com/eks/home\$1/clusters](https://console.aws.amazon.com/eks/home#/clusters).
1. No painel de navegação à esquerda, escolha **Clusters**.
1. Escolha o nome do cluster para o qual você deseja configurar o complemento Amazon CloudWatch Observability do EKS.
1. Escolha a guia **Add-ons** (Complementos).
1. Escolha **Obter mais complementos**.
1. Na página **Selecionar complementos**, faça o seguinte:
1. Na seção **Amazon EKS-addons**, marque a caixa de seleção **Observabilidade do Amazon CloudWatch**.
1. Escolha **Próximo**.
1. Na página **Definir as configurações dos complementos selecionados**:
1. Selecione a **Versão** que deseja usar.
1. Em **Acesso ao complemento**, escolha **Identidade de Pods do EKS**.
1. Se você não tiver um perfil do IAM configurado, escolha **Criar perfil recomendado** e, em seguida, escolha **Avançar** até chegar à **Etapa 3 Nomear, revisar e criar**. Se desejar, você poderá alterar o nome do perfil. Caso contrário, escolha **Criar perfil** e, em seguida, retorne à página do complemento e selecione o perfil do IAM que acabou de criar.
1. (Opcional) Você pode expandir **Definições de configuração opcionais**. Se você selecionar **Substituir** como **Método de resolução de conflitos**, uma ou mais configurações do complemento existente poderão ser substituídas pelas configurações do complemento do Amazon EKS. Se você não habilitar esta opção e houver um conflito com suas configurações existentes, a operação falhará. É possível usar a mensagem de erro resultante para solucionar o conflito. Antes de selecionar essa opção, certifique-se de que o complemento do Amazon EKS não gerencie as configurações que você precisa autogerenciar.
1. Escolha **Próximo**.
1. Na página **Adicionar tags**, escolha **Criar**. Depois que a instalação do complemento for concluída, você verá o complemento instalado.
------
#### [ CloudFormation ]
**Como usar o CloudFormation para instalar o complemento Amazon CloudWatch Observability do EKS**
1. Primeiro, execute o comando da AWS CLI a seguir para anexar a política do IAM necessária ao seu perfil do IAM. Substitua *my-role* pelo perfil que você criou na etapa de associação da Identidade de Pods do EKS.
```
aws iam attach-role-policy \
--role-name my-role \
--policy-arn arn:aws:iam::aws:policy/CloudWatchAgentServerPolicy
```
1. Depois, crie o recurso a seguir. Substitua `my-cluster-name` pelo nome do seu cluster, *111122223333* pelo ID da sua conta e *my-role* pelo perfil do IAM criado na etapa de associação do EKS Pod Identity. Para obter mais informações, consulte [AWS::EKS::Addon](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-eks-addon.html).
```
{
"Resources": {
"EKSAddOn": {
"Type": "AWS::EKS::Addon",
"Properties": {
"AddonName": "amazon-cloudwatch-observability",
"ClusterName": "my-cluster-name",
"PodIdentityAssociations": [
{
"ServiceAccount": "cloudwatch-agent",
"RoleArn": "arn:aws:iam::111122223333:role/my-role"
}
]
}
}
}
}
```
------
#### [ Terraform ]
**Como usar o Terraform para instalar o complemento Amazon CloudWatch Observability do EKS**
1. Siga as instruções abaixo. Substitua `my-cluster-name` pelo nome do seu cluster, *111122223333* pelo ID da sua conta e *my-service-account-role* pelo perfil do IAM criado na etapa de associação do EKS Pod Identity.
Para obter mais informações, consulte [Recurso: aws\$1eks\$1addon](https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/eks_addon) na documentação do Terraform.
1.
```
resource "aws_iam_role_policy_attachment" "CloudWatchAgentServerPolicy" {
policy_arn = "arn:aws:iam::aws:policy/CloudWatchAgentServerPolicy"
role = "my-role"
}
resource "aws_eks_addon" "example" {
cluster_name = "my-cluster-name"
addon_name = "amazon-cloudwatch-observability"
pod_identity_associations {
roleArn = "arn:aws:iam::111122223333:role/my-role"
serviceAccount = "cloudwatch-agent"
}
}
```
------
## Opção 2: instalar com permissões do IAM nos nós de processamento
Para usar esse método, primeiro anexe a política do IAM **CloudWatchAgentServerPolicy** aos nós de processamento, digitando o comando a seguir. Nesse comando, substitua *my-worker-node-role* pelo perfil do IAM usado por seus nós de processamento do Kubernetes.
```
aws iam attach-role-policy \
--role-name my-worker-node-role \
--policy-arn arn:aws:iam::aws:policy/CloudWatchAgentServerPolicy
```
Em seguida, instale o complemento de observabilidade do EKS do Amazon CloudWatch. Para instalar o complemento, você pode usar a AWS CLI, o console, o CloudFormation ou o Terraform.
------
#### [ AWS CLI ]
**Como usar a AWS CLI para instalar o complemento Amazon CloudWatch Observability do EKS**
Insira o comando a seguir. Substitua o `my-cluster-name` pelo nome do cluster.
```
aws eks create-addon --addon-name amazon-cloudwatch-observability --cluster-name my-cluster-name
```
------
#### [ Amazon EKS console ]
**Como usar o console do Amazon EKS para adicionar o complemento Amazon CloudWatch Observability do EKS**
1. Abra o console do Amazon EKS em [https://console.aws.amazon.com/eks/home\$1/clusters](https://console.aws.amazon.com/eks/home#/clusters).
1. No painel de navegação à esquerda, escolha **Clusters**.
1. Escolha o nome do cluster para o qual você deseja configurar o complemento Amazon CloudWatch Observability do EKS.
1. Escolha a guia **Add-ons** (Complementos).
1. Escolha **Obter mais complementos**.
1. Na página **Selecionar complementos**, faça o seguinte:
1. Na seção **Amazon EKS-addons**, marque a caixa de seleção **Observabilidade do Amazon CloudWatch**.
1. Escolha **Próximo**.
1. Na página **Definir as configurações dos complementos selecionados**:
1. Selecione a **Versão** que deseja usar.
1. (Opcional) Você pode expandir **Definições de configuração opcionais**. Se você selecionar **Substituir** como **Método de resolução de conflitos**, uma ou mais configurações do complemento existente poderão ser substituídas pelas configurações do complemento do Amazon EKS. Se você não habilitar esta opção e houver um conflito com suas configurações existentes, a operação falhará. É possível usar a mensagem de erro resultante para solucionar o conflito. Antes de selecionar essa opção, certifique-se de que o complemento do Amazon EKS não gerencie as configurações que você precisa autogerenciar.
1. Escolha **Próximo**.
1. Na página **Adicionar tags**, escolha **Criar**. Depois que a instalação do complemento for concluída, você verá o complemento instalado.
------
#### [ CloudFormation ]
**Como usar o CloudFormation para instalar o complemento Amazon CloudWatch Observability do EKS**
Substitua o `my-cluster-name` pelo nome do cluster. Para obter mais informações, consulte [AWS::EKS::Addon](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-eks-addon.html).
```
{
"Resources": {
"EKSAddOn": {
"Type": "AWS::EKS::Addon",
"Properties": {
"AddonName": "amazon-cloudwatch-observability",
"ClusterName": "my-cluster-name"
}
}
}
}
```
------
#### [ Helm chart ]
**Para usar o chart do Helm `amazon-cloudwatch-observability`**
1. Você deve ter o Helm instalado para usar esse chart. Para obter mais informações sobre como instalar o Helm, consulte a [documentação do Helm](https://helm.sh/docs/).
1. Depois de instalar o Helm, insira 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
```
------
#### [ Terraform ]
**Como usar o Terraform para instalar o complemento Amazon CloudWatch Observability do EKS**
Substitua o `my-cluster-name` pelo nome do cluster. Para obter mais informações, consulte [Recurso: aws\$1eks\$1addon](https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/eks_ad).
```
resource "aws_eks_addon" "example" {
addon_name = "amazon-cloudwatch-observability"
cluster_name = "my-cluster-name"
}
```
------
## Opção 3: instalar usando o perfil da conta de serviço do IAM (aplica-se somente ao uso do complemento)
Este método será válido somente se você estiver usando o complemento de observabilidade do EKS do Amazon CloudWatch. Antes de usar esse método, verifique os seguintes pré-requisitos:
+ Você possui um cluster funcional do Amazon EKS com nós conectados em uma das Regiões da AWS que são compatíveis com o Container Insights. Para obter a lista de regiões compatíveis, consulte [Container Insights](ContainerInsights.md).
+ Você instalou o `kubectl` e configurou o cluster. 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*.
+ Você tem o `eksctl` instalado. Para obter mais informações, consulte [Instalação ou atualização do `eksctl`](https://docs.aws.amazon.com/eks/latest/userguide/eksctl.html) no *Guia do usuário do Amazon EKS*.
------
#### [ AWS CLI ]
**Para usar a AWS CLI para instalar o complemento de observabilidade do EKS do Amazon CloudWatch usando o perfil de conta de serviço do IAM**
1. Insira o comando seguir para criar um provedor do OpenID Connect (OIDC), se o cluster ainda não tiver um. 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) no *Guia do usuário do Amazon EKS*.
```
eksctl utils associate-iam-oidc-provider --cluster my-cluster-name --approve
```
1. Insira o comando a seguir para criar o perfil do IAM com a política **CloudWatchAgentServerPolicy** anexada e configure a conta do serviço de agente para assumir esse perfil usando o OIDC. Substitua *my-cluster-name* pelo nome do seu cluster e substitua *my-service-account-role* pelo nome do perfil ao qual você deseja associar a conta de serviço. Se o perfil ainda não existir, o `eksctl` o criará para você.
```
eksctl create iamserviceaccount \
--name cloudwatch-agent \
--namespace amazon-cloudwatch --cluster my-cluster-name \
--role-name my-service-account-role \
--attach-policy-arn arn:aws:iam::aws:policy/CloudWatchAgentServerPolicy \
--role-only \
--approve
```
1. Instale o complemento inserindo o comando a seguir. Substitua *my-cluster-name* pelo nome do seu cluster, substitua *111122223333* pela ID da sua conta e substitua *my-service-account-role* pelo perfil do IAM criado na etapa anterior.
```
aws eks create-addon --addon-name amazon-cloudwatch-observability --cluster-name my-cluster-name --service-account-role-arn arn:aws:iam::111122223333:role/my-service-account-role
```
------
#### [ Amazon EKS console ]
**Para usar o console para instalar o complemento de observabilidade do EKS do Amazon CloudWatch usando o perfil de conta de serviço do IAM**
1. Abra o console do Amazon EKS em [https://console.aws.amazon.com/eks/home\$1/clusters](https://console.aws.amazon.com/eks/home#/clusters).
1. No painel de navegação à esquerda, escolha **Clusters**.
1. Escolha o nome do cluster para o qual você deseja configurar o complemento Amazon CloudWatch Observability do EKS.
1. Escolha a guia **Add-ons** (Complementos).
1. Escolha **Obter mais complementos**.
1. Na página **Selecionar complementos**, faça o seguinte:
1. Na seção **Amazon EKS-addons**, marque a caixa de seleção **Observabilidade do Amazon CloudWatch**.
1. Escolha **Próximo**.
1. Na página **Definir as configurações dos complementos selecionados**:
1. Selecione a **Versão** que deseja usar.
1. Para **Acesso ao complemento**, selecione **Perfis do IAM para contas de serviço (IRSA)**
1. Selecione o perfil do IAM na caixa **Acesso ao complemento**.
1. (Opcional) Você pode expandir **Definições de configuração opcionais**. Se você selecionar **Substituir** como **Método de resolução de conflitos**, uma ou mais configurações do complemento existente poderão ser substituídas pelas configurações do complemento do Amazon EKS. Se você não habilitar esta opção e houver um conflito com suas configurações existentes, a operação falhará. É possível usar a mensagem de erro resultante para solucionar o conflito. Antes de selecionar essa opção, certifique-se de que o complemento do Amazon EKS não gerencie as configurações que você precisa autogerenciar.
1. Escolha **Próximo**.
1. Na página **Adicionar tags**, escolha **Criar**. Depois que a instalação do complemento for concluída, você verá o complemento instalado.
------
## Considerações sobre o Amazon EKS Hybrid Nodes
As métricas no nível de nós não estão disponíveis para nós híbridos porque o [Container Insights](ContainerInsights.md) depende da disponibilidade do [Serviço de metadados de instância](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-service.html) (IMDS) para métricas no nível de nós. Métricas no nível de cluster, Pod, workload e contêiner estão disponíveis para nós híbridos.
Depois de instalar o complemento seguindo as etapas nas seções anteriores, você deve atualizar o manifesto do complemento para que o agente possa ser executado com êxito em nós híbridos. Edite o recurso `amazoncloudwatchagents` no cluster para adicionar a variável `RUN_WITH_IRSA` de ambiente que corresponda ao abaixo.
```
kubectl edit amazoncloudwatchagents -n amazon-cloudwatch cloudwatch-agent
```
```
apiVersion: v1
items:
- apiVersion: cloudwatch.aws.amazon.com/v1alpha1
kind: AmazonCloudWatchAgent
metadata:
...
name: cloudwatch-agent
namespace: amazon-cloudwatch
...
spec:
...
env:
- name: RUN_WITH_IRSA # <-- Add this
value: "True" # <-- Add this
- name: K8S_NODE_NAME
valueFrom:
fieldRef:
fieldPath: spec.nodeName
...
```
## (Opcional) Configuração adicional
**Topics**
+ [Opte por não coletar logs de contêineres](#CloudWatch-Observability-EKS-addon-OptOutContainerLogs)
+ [Usar uma configuração personalizada do Fluent Bit](#CloudWatch-Observability-EKS-addon-CustomFluentBit)
+ [Gerenciar as tolerações do Kubernetes para as workloads do pod instalado](#CloudWatch-Observability-EKS-addon-Tolerations)
+ [Excluir a coleta acelerada de métricas de computação](#CloudWatch-Observability-EKS-addon-OptOutAccelerated)
+ [Como usar uma configuração personalizada do agente do CloudWatch](#CloudWatch-Observability-EKS-addon-CustomAgentConfig)
+ [Gerenciamento de certificados TLS para o webhook de admissão](#CloudWatch-Observability-EKS-addon-Webhook)
+ [Coletar IDs de volume do Amazon EBS](#CloudWatch-Observability-EKS-addon-VolumeIDs)
### Opte por não coletar logs de contêineres
Por padrão, o complemento usa o Fluent Bit para coletar logs de contêineres de todos os pods e, em seguida, envia os logs para o CloudWatch Logs. Para obter informações sobre quais logs são coletados, consulte [Configurar o Fluent Bit](Container-Insights-setup-logs-FluentBit.md#Container-Insights-FluentBit-setup).
**nota**
Nem o complemento nem o chart do Helm gerenciam os recursos existentes do Fluentd ou do FluentBit em um cluster. Você pode excluir os recursos existentes do Fluentd ou do Fluent Bit antes de instalar o complemento ou o chart do Helm. Como alternativa, para manter sua configuração existente e evitar que o complemento ou o chart do Helm também instalem o Fluent Bit, você pode desabilitá-lo seguindo as instruções nesta seção.
Para desativar a coleta de logs de contêineres, caso esteja usando o complemento de observabilidade do EKS do Amazon CloudWatch, passe a seguinte opção ao criar ou atualizar o complemento:
```
--configuration-values '{ "containerLogs": { "enabled": false } }'
```
Para desativar a coleta de logs de contêineres, caso esteja usando o chart do Helm, passe a seguinte opção ao criar ou atualizar o complemento:
```
--set containerLogs.enabled=false
```
### Usar uma configuração personalizada do Fluent Bit
A partir da versão 1.7.0 do complemento de observabilidade do EKS do Amazon CloudWatch, você pode modificar a configuração do Fluent Bit ao criar ou atualizar o complemento ou o chart do Helm. Você fornece a configuração personalizada do Fluent Bit na seção de nível raiz `containerLogs` da configuração avançada do complemento ou das substituições de valores no chart do Helm. Nesta seção, você fornece a configuração personalizada do Fluent Bit na seção `config` (para Linux) ou na seção `configWindows` (para Windows). A seção `config` ainda é dividida nas seguintes subseções:
+ `service`: esta seção representa a configuração de `SERVICE` para definir o comportamento global do mecanismo do Fluent Bit.
+ `customParsers`: esta seção representa qualquer `PARSER` global que você deseje incluir que seja capaz de pegar entradas de logs não estruturadas e fornecer a elas uma estrutura para facilitar o processamento e a filtragem adicional.
+ `extraFiles`: esta seção pode ser usada para fornecer arquivos adicionais de `conf` do Fluent Bit a serem incluídos. Por padrão, os três arquivos de `conf` abaixo estão incluídos:
+ `application-log.conf`: um arquivo de `conf` para enviar logs de aplicações do seu cluster para o grupo de logs `/aws/containerinsights/my-cluster-name/application` no CloudWatch Logs.
+ `dataplane-log.conf`: um arquivo de `conf` para enviar logs correspondentes aos componentes do plano de dados do seu cluster, incluindo os logs de CRI, logs de kubelet, logs de kube-proxy e logs de CNI da Amazon VPC para o grupo de logs `/aws/containerinsights/my-cluster-name/dataplane` no CloudWatch Logs.
+ `host-log.conf`: um `conf` para enviar logs de `/var/log/dmesg`, `/var/log/messages` e `/var/log/secure` no Linux, e `winlogs` do sistema no Windows, para o grupo de logs `/aws/containerinsights/my-cluster-name/host` no CloudWatch.
**nota**
Forneça a configuração completa para cada uma dessas seções individuais, mesmo se você estiver modificando somente um campo em uma subseção. Recomendamos que você use a configuração padrão fornecida abaixo como linha de base e, então, modifique-a de acordo para não desabilitar a funcionalidade que é habilitada por padrão. Você pode usar a configuração YAML a seguir ao modificar a configuração avançada do complemento do Amazon EKS ou ao fornecer substituições de valores para o chart do Helm.
Para encontrar a seção `config` do seu cluster, consulte [aws-observability / helm-charts](https://github.com/aws-observability/helm-charts/releases) no GitHub e encontre a versão correspondente à versão do complemento ou do chart do Helm que você está instalando. Em seguida, navegue até `/charts/amazon-cloudwatch-observability/values.yaml` para encontrar a seção `config` (para Linux) e a seção `configWindows` (para Windows) na seção `fluentBit` em `containerLogs`.
Como exemplo, a configuração padrão do Fluent Bit para a versão 1.7.0 pode ser encontrada [aqui](https://github.com/aws-observability/helm-charts/blob/v1.7.0/charts/amazon-cloudwatch-observability/values.yaml#L44)).
Recomendamos que você forneça a `config` como YAML ao fornecê-la usando a configuração avançada do complemento do Amazon EKS ou ao fornecê-la como substituições de valor para sua instalação do Helm. Certifique-se de que o YAML esteja em conformidade com a estrutura a seguir.
```
containerLogs:
fluentBit:
config:
service: |
...
customParsers: |
...
extraFiles:
application-log.conf: |
...
dataplane-log.conf: |
...
host-log.conf: |
...
```
O exemplo a seguir de `config` altera a configuração global do intervalo de descarga para 45 segundos. Mesmo que a única modificação seja no campo `Flush`, você ainda deve fornecer a definição completa de `SERVICE` para a subseção do serviço. Como esse exemplo não especificou substituições para as outras subseções, os padrões foram usados para elas.
```
containerLogs:
fluentBit:
config:
service: |
[SERVICE]
Flush 45
Grace 30
Log_Level error
Daemon off
Parsers_File parsers.conf
storage.path /var/fluent-bit/state/flb-storage/
storage.sync normal
storage.checksum off
storage.backlog.mem_limit 5M
```
O exemplo de configuração a seguir inclui um arquivo extra de `conf` do Fluent Bit. Neste exemplo, estamos adicionando um `my-service.conf` personalizado em `extraFiles`, e ele será incluído além dos três `extraFiles` padrão.
```
containerLogs:
fluentBit:
config:
extraFiles:
my-service.conf: |
[INPUT]
Name tail
Tag myservice.*
Path /var/log/containers/*myservice*.log
DB /var/fluent-bit/state/flb_myservice.db
Mem_Buf_Limit 5MB
Skip_Long_Lines On
Ignore_Older 1d
Refresh_Interval 10
[OUTPUT]
Name cloudwatch_logs
Match myservice.*
region ${AWS_REGION}
log_group_name /aws/containerinsights/${CLUSTER_NAME}/myservice
log_stream_prefix ${HOST_NAME}-
auto_create_group true
```
O próximo exemplo remove totalmente um arquivo de `conf` existente de `extraFiles`. Isso exclui `application-log.conf` totalmente, substituindo-o por uma string vazia. Simplesmente omitir `application-log.conf` de `extraFiles` implicaria usar o padrão, o que não é o que estamos tentando alcançar neste exemplo. O mesmo se aplica à remoção de qualquer arquivo personalizado de `conf` que você possa ter adicionado anteriormente a `extraFiles`.
```
containerLogs:
fluentBit:
config:
extraFiles:
application-log.conf: ""
```
### Gerenciar as tolerações do Kubernetes para as workloads do pod instalado
A partir da versão 1.7.0 do complemento de observabilidade do EKS do Amazon CloudWatch, o complemento e o chart do Helm definem, por padrão, as *tolerâncias* do Kubernetes para tolerar todos os taints nas workloads do pod instalados pelo complemento ou pelo chart do Helm. Isso garante que daemonsets, como o agente CloudWatch e o Fluent Bit, possam programar pods em todos os nós do seu cluster por padrão. Para obter mais informações sobre taints e tolerâncias, consulte [Taints e Tolerâncias](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/) na documentação do Kubernetes.
As tolerâncias padrão definidas pelo complemento ou pelo chart do Helm são as seguintes:
```
tolerations:
- operator: Exists
```
Você pode substituir as tolerâncias padrão definindo o campo `tolerations` no nível raiz ao usar a configuração avançada do complemento ou ao instalar ou atualizar o chart do Helm com substituições de valores. Um exemplo pode ser o seguinte:
```
tolerations:
- key: "key1"
operator: "Exists"
effect: "NoSchedule"
```
Para omitir completamente as tolerâncias, você pode usar uma configuração que seja como a seguinte:
```
tolerations: []
```
Todas as alterações nas tolerâncias se aplicam a todas as workloads do pod instaladas pelo complemento ou pelo chart do Helm.
### Excluir a coleta acelerada de métricas de computação
Por padrão, o Container Insights com observabilidade aprimorada coleta métricas para monitoramento acelerado de computação, incluindo métricas de GPU da NVIDIA, métricas do AWS Neuron para AWS Trainium e AWS Inferentia e métricas do AWS Elastic Fabric Adapter (EFA).
As métricas de GPU da NVIDIA das workloads do Amazon EKS são coletadas por padrão, começando com a versão `v1.3.0-eksbuild.1` do complemento do EKS ou do chart do Helm e a versão `1.300034.0` do agente do CloudWatch. Para obter uma lista das métricas coletadas e dos pré-requisitos, consulte [Métricas da GPU NVIDIA](Container-Insights-metrics-enhanced-EKS.md#Container-Insights-metrics-EKS-GPU).
As métricas do AWS Neuron para aceleradores do AWS Trainium e AWS Inferentia são coletadas por padrão, começando com a versão `v1.5.0-eksbuild.1` do complemento EKS ou do chart do Helm e a versão `1.300036.0` do agente do CloudWatch. Para obter uma lista das métricas coletadas e dos pré-requisitos, consulte [Métricas do AWS Neuron para o AWS Trainium e para o AWS Inferentia](Container-Insights-metrics-enhanced-EKS.md#Container-Insights-metrics-EKS-Neuron).
As métricas do AWS Elastic Fabric Adapter (EFA) dos nós do Linux nos clusters do Amazon EKS são coletadas por padrão, começando com a versão `v1.5.2-eksbuild.1` do complemento EKS ou do chart do Helm e a versão `1.300037.0` do agente do CloudWatch. Para obter uma lista das métricas coletadas e dos pré-requisitos, consulte [Métricas do AWS Elastic Fabric Adapter (EFA)](Container-Insights-metrics-enhanced-EKS.md#Container-Insights-metrics-EFA).
Você pode optar por não coletar essas métricas definindo o campo `accelerated_compute_metrics` no arquivo de configuração do agente do CloudWatch como `false`. Esse campo está na seção `kubernetes` da seção `metrics_collected` no arquivo de configuração do CloudWatch. Este é um exemplo de uma configuração de exclusão. Para obter mais informações sobre como usar as configurações personalizadas do agente do CloudWatch, consulte a seção a seguir, [Como usar uma configuração personalizada do agente do CloudWatch](#CloudWatch-Observability-EKS-addon-CustomAgentConfig).
```
{
"logs": {
"metrics_collected": {
"kubernetes": {
"enhanced_container_insights": true,
"accelerated_compute_metrics": false
}
}
}
}
```
### Como usar uma configuração personalizada do agente do CloudWatch
Para coletar métricas, logs ou rastreamentos adicionais usando o agente do CloudWatch, é possível especificar uma configuração personalizada e, ao mesmo tempo, manter o Container Insights e o CloudWatch Application Signals habilitados. Para fazê-lo, incorpore o arquivo de configuração do agente do CloudWatch na chave de configuração em chave do agente da configuração avançada que você pode usar ao criar ou atualizar o chart do Helm ou o complemento do EKS. Veja a seguir uma representação da configuração padrão do agente quando nenhuma configuração adicional é fornecida.
**Importante**
Qualquer configuração personalizada fornecida usando as definições de configurações adicionais substitui a configuração padrão usada pelo agente. Tenha cuidado para não desabilitar acidentalmente as funcionalidades que são habilitadas por padrão, como o Container Insights com uma observabilidade aprimorada e o CloudWatch Application Signals. Diante do cenário em que é necessário fornecer uma configuração do agente personalizada, recomendamos usar a configuração padrão apresentada a seguir como linha de base e, em seguida, modificá-la com base nas suas necessidades.
+ Para usar o complemento de observabilidade do EKS do Amazon CloudWatch
```
--configuration-values '{
"agent": {
"config": {
"logs": {
"metrics_collected": {
"application_signals": {},
"kubernetes": {
"enhanced_container_insights": true
}
}
},
"traces": {
"traces_collected": {
"application_signals": {}
}
}
}
}
}'
```
+ Para usar o chart do Helm
```
--set agent.config='{
"logs": {
"metrics_collected": {
"application_signals": {},
"kubernetes": {
"enhanced_container_insights": true
}
}
},
"traces": {
"traces_collected": {
"application_signals": {}
}
}
}'
```
O exemplo apresentado a seguir mostra a configuração padrão do agente do CloudWatch no Windows. O agente do CloudWatch no Windows não oferece suporte à configuração personalizada.
```
{
"logs": {
"metrics_collected": {
"kubernetes": {
"enhanced_container_insights": true
},
}
}
}
```
### Gerenciamento de certificados TLS para o webhook de admissão
O complemento de observabilidade do EKS do Amazon CloudWatch e o chart do Helm utilizam [webhooks de admissão](https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/) do Kubernetes para validar e alterar solicitações de recursos personalizados (CR) do `AmazonCloudWatchAgent` e de `Instrumentation`, e, opcionalmente, solicitações de pod do Kubernetes no cluster, se o CloudWatch Application Signals estiver habilitado. No Kubernetes, os webhooks requerem um certificado TLS no qual o servidor de API esteja configurado para confiar, a fim de garantir uma comunicação segura.
Por padrão, o complemento de observabilidade do EKS do Amazon CloudWatch e o chart do Helm geram automaticamente uma CA autoassinada e um certificado TLS assinado por essa CA para proteger a comunicação entre o servidor de API e o servidor de webhook. O certificado gerado automaticamente tem uma expiração padrão de dez anos e não é renovado de forma automática após expirar. Além disso, o pacote da CA e o certificado são gerados novamente sempre que o complemento ou o chart do Helm é atualizado ou reinstalado, redefinindo, assim, a expiração. Caso deseje alterar a expiração padrão do certificado gerado automaticamente, você poderá usar as configurações adicionais apresentadas a seguir ao criar ou atualizar o complemento. Substitua *expiry-in-days* pelo período de expiração desejado em dias.
+ Usar para o complemento de observabilidade do EKS do Amazon CloudWatch
```
--configuration-values '{ "admissionWebhooks": { "autoGenerateCert": { "expiryDays": expiry-in-days } } }'
```
+ Usar para o chart do Helm
```
--set admissionWebhooks.autoGenerateCert.expiryDays=expiry-in-days
```
Para obter uma solução mais segura e repleta de recursos da autoridade de certificação, o complemento tem suporte opcional para o [cert-manager](https://cert-manager.io/docs/), uma solução amplamente adotada para o gerenciamento de certificados TLS no Kubernetes que simplifica o processo de obtenção, renovação, gerenciamento e uso desses certificados. A solução garante que os certificados sejam válidos e estejam atualizados, bem como busca renová-los em um momento configurado antes da expiração. Além disso, o cert-manager facilita a emissão de certificados de diversas fontes com suporte, incluindo o [AWS Certificate Manager Private Certificate Authority](https://aws.amazon.com/private-ca/).
Recomendamos analisar as práticas recomendadas para o gerenciamento de certificados TLS em seus clusters e aconselhamos a opção pelo cert-manager para ambientes de produção. Observe que, se você optar por habilitar o cert-manager para gerenciar os certificados TLS para o webhook de admissão, será necessário instalar previamente o cert-manager no cluster do Amazon EKS antes de instalar o complemento de observabilidade do EKS do Amazon CloudWatch ou o chart do Helm. Para obter mais informações sobre as opções de instalação disponíveis, consulte a [documentação do cert-manager](https://cert-manager.io/docs/installation/). Após a instalação, é possível optar por usar o cert-manager para o gerenciamento dos certificados TLS para o webhook de admissão usando a configuração adicional apresentada a seguir.
+ Se estiver usando o complemento de observabilidade do EKS do Amazon CloudWatch
```
--configuration-values '{ "admissionWebhooks": { "certManager": { "enabled": true } } }'
```
+ Se estiver usando o chart do Helm
```
--set admissionWebhooks.certManager.enabled=true
```
```
--configuration-values '{ "admissionWebhooks": { "certManager": { "enabled": true } } }'
```
A configuração avançada debatida nesta seção usará, por padrão, um emissor [SelfSigned](https://cert-manager.io/docs/configuration/selfsigned/).
### Coletar IDs de volume do Amazon EBS
Se quiser coletar IDs de volume do Amazon EBS nos logs de performance, será necessário adicionar outra política ao perfil do IAM que está anexado aos nós de processamento ou à conta de serviço. 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).
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": [
"ec2:DescribeVolumes"
],
"Resource": "*",
"Effect": "Allow"
}
]
}
```
------
## Coletar métricas do Java Management Extensions (JMX)
O agente do CloudWatch é compatível com a coleta de métricas do Java Management Extensions (JMX) no Amazon EKS. Isso permite que você colete métricas adicionais de aplicações Java executadas em clusters do Amazon EKS, possibilitando insights de performance, uso de memória, tráfego e outras métricas cruciais. Para obter mais informações, consulte [Coletar métricas do Java Management Extensions (JMX)](CloudWatch-Agent-JMX-metrics.md).
## Habilitar 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 ter mais informações sobre essas métricas, consulte [Métricas do Kueue](Container-Insights-metrics-EKS.md#Container-Insights-metrics-Kueue).
Se você estiver usando o complemento Amazon SageMaker AI Hyperpod Task Governance EKS, você pode pular as etapas na seção **Pré-requisitos** e apenas seguir as etapas apresentadas em [Habilitar o sinalizador de configuração](#enable-Kueue-metrics-flag).
### Pré-requisitos
Antes de instalar o Kueue no cluster do Amazon EKS, faça as seguintes atualizações no arquivo de manifesto:
1. Habilite as métricas opcionais de recursos de filas de clusters do Kueue. Para fazer isso, modifique o `controller_manager_config.yaml` em linha no ConfigMap `kueue-system`. Na seção `metrics`, adicione ou remova o comentário da linha `enableClusterQueueResources: true`.
```
apiVersion: v1
data:
controller_manager_config.yaml: |
apiVersion: config.kueue.x-k8s.io/v1beta1
kind: Configuration
health:
healthProbeBindAddress: :8081
metrics:
bindAddress: :8080
enableClusterQueueResources: true <-- ADD/UNCOMMENT THIS LINE
```
1. Por padrão, todos os serviços do `k8s` estão disponíveis em todo o cluster. O Kueue cria um serviço `kueue-controller-manager-metrics-service` para expor métricas. Para evitar observações duplicadas para métricas, modifique esse serviço para permitir acesso somente ao serviço de métricas no mesmo nó. Para fazer isso, adicione a linha `internalTrafficPolicy: Local` à definição `kueue-controller-manager-metrics-service`.
```
apiVersion: v1
kind: Service
metadata:
labels:
...
name: kueue-controller-manager-metrics-service
namespace: kueue-system
spec:
ports:
- name: https
port: 8443
protocol: TCP
targetPort: https
internalTrafficPolicy: Local <-- ADD THIS LINE
selector:
control-plane: controller-manager
```
1. Por fim, o pod `kueue-controller-manager` cria um contêiner `kube-rbac-proxy`. Atualmente, esse contêiner tem um alto nível de detalhamento de registro em log, o que faz com que o token portador do cluster seja registrado em log por esse contêiner quando o extrator de métricas acessar o `kueue-controller-manager-metrics-service`. Recomendamos que você diminua o detalhamento do registro em log. O valor padrão no manifesto distribuído pelo Kueue é 10. Recomendamos alterá-lo para 0.
```
apiVersion: apps/v1
kind: Deployment
metadata:
labels:
...
name: kueue-controller-manager
namespace: kueue-system
spec:
...
template:
...
spec:
containers:
...
- args:
- --secure-listen-address=0.0.0.0:8443
- --upstream=http://127.0.0.1:8080/
- --logtostderr=true
- --v=0 <-- CHANGE v=10 TO v=0
image: gcr.io/kubebuilder/kube-rbac-proxy:v0.8.0
name: kube-rbac-proxy
...
```
### Habilitar o sinalizador de configuração
Para habilitar as métricas do Kueue, você deve habilitar `kueue_container_insights` na configuração adicional do complemento. Você pode fazer isso usando a AWS CLI para configurar o complemento EKS Observability, ou usando o console do Amazon EKS.
Depois de instalar com êxito o complemento EKS Observability com um dos métodos a seguir, você pode visualizar as métricas do cluster do Amazon EKS na guia **Painel** do console do HyperPod.
------
#### [ AWS CLI ]
**Para habilitar as métricas do Kueue usando a AWS CLI**
+ Insira o comando da AWS CLI a seguir para instalar o complemento.
```
aws eks create-addon --cluster-name cluster-name --addon-name amazon-cloudwatch-observability --configuration-values "configuration_json_file"
```
Veja abaixo um exemplo do arquivo JSON com os valores de configuração.
```
{
"agent": {
"config": {
"logs": {
"metrics_collected": {
"kubernetes": {
"kueue_container_insights": true,
"enhanced_container_insights": true
},
"application_signals": { }
}
},
"traces": {
"traces_collected": {
"application_signals": { }
}
}
},
},
}
```
------
#### [ Amazon EKS console ]
**Para habilitar as métricas do Kueue usando o console do Amazon EKS**
1. Abra o console do Amazon EKS em [https://console.aws.amazon.com/eks/home\$1/clusters](https://console.aws.amazon.com/eks/home#/clusters).
1. Selecione o nome do seu cluster.
1. Escolha **Complementos**.
1. Encontre o complemento **Amazon CloudWatch Observability** na lista e instale-o. Ao fazer isso, escolha **Configuração opcional** e inclua os valores de configuração JSON a seguir.
```
{
"agent": {
"config": {
"logs": {
"metrics_collected": {
"kubernetes": {
"kueue_container_insights": true,
"enhanced_container_insights": true
},
"application_signals": { }
}
},
"traces": {
"traces_collected": {
"application_signals": { }
}
}
},
},
}
```
------
## Anexar arquivos de configuração do coletor do OpenTelemetry
O agente do CloudWatch é compatível com os arquivos de configuração suplementares do coletor do OpenTelemetry junto com seus próprios arquivos de configuração. Esse recurso permite que você use os recursos do agente do CloudWatch, como o CloudWatch Application Signals ou o Container Insights, por meio da configuração do agente do CloudWatch, e inclua a configuração existente do coletor do OpenTelemetry com um único agente.
Para evitar conflitos de mesclagem com pipelines criados automaticamente pelo agente do CloudWatch, recomendamos que você adicione um sufixo personalizado a cada um dos componentes e pipelines na configuração do coletor do OpenTelemetry. Isso evitará conflitos de atrito e mesclagem.
+ Se estiver usando o complemento de observabilidade do EKS do Amazon CloudWatch
```
--configuration-values file://values.yaml
```
ou
```
--configuration-values '
agent:
otelConfig:
receivers:
otlp/custom-suffix:
protocols:
http: {}
exporters:
awscloudwatchlogs/custom-suffix:
log_group_name: "test-group"
log_stream_name: "test-stream"
service:
pipelines:
logs/custom-suffix:
receivers: [otlp/custom-suffix]
exporters: [awscloudwatchlogs/custom-suffix]
'
```
+ Se estiver usando o chart do Helm
```
--set agent.otelConfig='
receivers:
otlp/custom-suffix:
protocols:
http: {}
exporters:
awscloudwatchlogs/custom-suffix:
log_group_name: "test-group"
log_stream_name: "test-stream"
service:
pipelines:
logs/custom-suffix:
receivers: [otlp/custom-suffix]
exporters: [awscloudwatchlogs/custom-suffix]
'
```
## Habilitar APM usando o Application Signals para o cluster do Amazon EKS
Por padrão, o monitoramento de performance de aplicações (APM) baseado em OpenTelemetry (OTEL) é habilitado usando o Application Signals ao instalar o complemento CloudWatch Observability para o EKS (V5.0.0 ou acima) ou o chart do Helm. É possível personalizar configurações específicas usando a configuração avançada para o complemento do Amazon EKS ou sobrescrevendo valores no chart do Helm.
**nota**
Se você usar alguma solução de APM baseada em OpenTelemetry (OTEL), a habilitação do Application Signals afetará a configuração de observabilidade existente. Revise a implementação atual antes de continuar. Para manter a configuração de APM existente depois de atualizar para a V5.0.0 ou posterior, consulte [Optar por não usar o Application Signals](#Opting-out-App-Signals).
**Monitoramento automático do Application Signals**
A versão 5.0.0 do complemento de observabilidade do Amazon EKS do CloudWatch e do chart do Helm introduz uma nova funcionalidade. Agora, é possível habilitar automaticamente o Application Signals para todas as workloads ou para workloads de serviços específicas em seu cluster do EKS por meio da configuração Monitoramento automático. As configurações de `autoMonitor`, apresentadas a seguir, devem ser especificadas na seção `applicationSignals`, que está dentro da seção `manager` da configuração avançada.
+ *monitorAllServices*: uma sinalização booleana para habilitar (“true”) ou desabilitar (“false”) o monitoramento de todas as workloads de serviços pela funcionalidade Monitoramento automático. O valor padrão é verdadeiro. Habilitar essa sinalização garantirá que todas as workloads do Kubernetes (incluindo Deployments, DaemonSets e StatefulSets) presentes no cluster, que estejam associadas a um serviço do Kubernetes, estejam incluídas no escopo para a habilitação automática do Application Signals quando forem iniciadas pela primeira vez (ou reiniciadas, no caso de workloads existentes). O sistema exclui, por padrão, as workloads presentes nos namespaces `kube-system` e `amazon-cloudwatch`.
+ *languages*: uma lista de strings que especifica o conjunto de linguagens com as quais o Application Signals tentará instrumentar automaticamente seus serviços, quando a configuração `monitorAllServices` estiver habilitada. O valor padrão é todas as [linguagens compatíveis](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Application-Monitoring-Sections.html).
+ *restartPods*: uma sinalização booleana que controla se as workloads serão reiniciadas após as alterações de configuração. O padrão é falso. Habilitar essa sinalização como `true` determina se as workloads do Kubernetes que estão incluídas no escopo do Monitoramento automático serão reiniciadas automaticamente com o salvamento das alterações na configuração. Qualquer configuração presente nas workloads do Kubernetes que influencie a reinicialização dos pods, como `updateStrategy`, será considerada. Tenha em mente que o reinício pode causar tempo de inatividade para o serviço.
+ *customSelector*: configurações para selecionar namespaces ou workloads do Kubernetes que são específicos para o Monitoramento automático.
+ *java*: especifica workloads para instrumentação automática com Java
+ *python*: especifica workloads para instrumentação automática com Python
+ *nodejs*: especifica workloads para instrumentação automática com Node.js
+ *dotnet*: especifica workloads para instrumentação automática com .NET
Para cada uma das linguagens mencionadas acima, os campos apresentados a seguir podem ser configurados.
+ *namespaces*: uma lista de strings que especifica os namespaces a serem selecionados. O valor padrão corresponde a uma lista vazia, representada por [].
+ *deployments*: uma lista de strings que especifica as implantações a serem selecionadas. Especifique usando o formato `namespace/deployment`. O valor padrão corresponde a uma lista vazia, representada por [].
+ *daemonsets*: uma lista de strings que especifica os daemonsets a serem selecionados. Especifique usando o formato `namespace/daemonset`. O valor padrão corresponde a uma lista vazia, representada por [].
+ *statefulsets*: uma lista de strings que especifica os statefulsets a serem selecionados. Especifique usando o formato `namespace/statefulset`. O valor padrão corresponde a uma lista vazia, representada por [].
+ *exclude*: configurações para excluir namespaces ou workloads do Kubernetes que são específicos do Monitoramento automático. A exclusão de uma workload prevalece quando uma workload semelhante está simultaneamente incluída em `monitorAllServices` ou `customSelector`.
+ *java*: especifica workloads que devem ser excluídas da instrumentação automática com Java
+ *python*: especifica workloads que devem ser excluídas da instrumentação automática com Python
+ *nodejs*: especifica workloads que devem ser excluídas da instrumentação automática com Node.js
+ *dotnet*: especifica workloads que devem ser excluídas da instrumentação automática com .NET
Para cada uma das linguagens mencionadas acima, os campos apresentados a seguir podem ser configurados.
+ *namespaces*: uma lista de strings que especifica os namespaces a serem excluídos. O valor padrão corresponde a uma lista vazia, representada por [].
+ *deployments*: uma lista de strings que especifica as implantações a serem excluídas. Especifique usando o formato `namespace/deployment`. O valor padrão corresponde a uma lista vazia, representada por [].
+ *daemonsets*: uma lista de strings que especifica os daemonsets a serem excluídos. Especifique usando o formato `namespace/daemonset`. O valor padrão corresponde a uma lista vazia, representada por [].
+ *statefulsets*: uma lista de strings que especifica os statefulsets a serem excluídos. Especifique usando o formato `namespace/statefulset`. O valor padrão corresponde a uma lista vazia, representada por [].
Confira, a seguir, um exemplo de configuração que habilita automaticamente o Application Signals para todas as workloads de serviços existentes e novas presentes no cluster.
```
manager:
applicationSignals:
autoMonitor:
monitorAllServices: true
restartPods: true
```
Confira, a seguir, um exemplo de configuração que habilita automaticamente o Application Signals para qualquer nova workload de serviço que for iniciada e para qualquer workload de serviço existente que seja explicitamente reiniciada no cluster.
```
manager:
applicationSignals:
autoMonitor:
monitorAllServices: true
```
Confira, a seguir, um exemplo de configuração que habilita automaticamente o Application Signals com a linguagem Java para todos os pods existentes e novos correspondentes a uma workload no namespace `pet-warehouse`.
```
manager:
applicationSignals:
autoMonitor:
restartPods: true
customSelector:
java:
namespaces: ["pet-warehouse"]
```
Confira, a seguir, um exemplo de configuração que habilita automaticamente o Application Signals com a linguagem Python para todas as workloads de serviços existentes e novas presentes no cluster, excluindo a implantação `pet-clinic`.
```
manager:
applicationSignals:
autoMonitor:
monitorAllServices: true
languages: ["python"]
restartPods: true
exclude:
python:
deployments: ["pet-warehouse/pet-clinic"]
```
Confira, a seguir, um exemplo de configuração que habilita automaticamente o Application Signals com a linguagem Java para todas as workloads de serviços presentes no cluster, exceto aquelas no namespace `python-apps`, e que habilita o Application Signals com a linguagem Python especificamente para a implantação `sample-python-app` no namespace `python-apps`.
```
manager:
applicationSignals:
autoMonitor:
monitorAllServices: true
languages: ["java"]
restartPods: true
customSelector:
python:
deployments: ["python-apps/sample-python-app"]
exclude:
java:
namespaces: ["python-apps"]
```
## Solução de problemas do complemento de observabilidade do EKS do Amazon CloudWatch ou do chart do Helm
Use as informações apresentadas a seguir para ajudar a solucionar problemas relacionados ao complemento de observabilidade do EKS do Amazon CloudWatch ou ao chart do Helm.
**Topics**
+ [Atualizar e excluir o complemento de observabilidade do EKS do Amazon CloudWatch ou o chart do Helm](#EKS-addon-troubleshoot-update)
+ [Verificar a versão do agente do CloudWatch usado pelo complemento de observabilidade do EKS do Amazon CloudWatch ou pelo chart do Helm](#EKS-addon-troubleshoot-version)
+ [Tratamento de um ConfigurationConflict ao gereciar o complemento ou o chart do Helm](#EKS-addon-troubleshoot-conflict)
### Atualizar e excluir o complemento de observabilidade do EKS do Amazon CloudWatch ou o chart do Helm
Para obter instruções sobre como atualizar ou excluir o complemento Amazon CloudWatch Observability do EKS, consulte [Gerenciar complementos do Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/managing-add-ons.html). Use `amazon-cloudwatch-observability` como o nome do complemento.
Para excluir o chart do Helm em um cluster, insira o comando a seguir.
```
helm delete amazon-cloudwatch-observability -n amazon-cloudwatch --wait
```
### Verificar a versão do agente do CloudWatch usado pelo complemento de observabilidade do EKS do Amazon CloudWatch ou pelo chart do Helm
O complemento de observabilidade do EKS do Amazon CloudWatch ou o chart do Helm instala um recurso personalizado do tipo `AmazonCloudWatchAgent` que controla o comportamento do daemonset do agente do CloudWatch no cluster, incluindo a versão do agente do CloudWatch que está sendo usada. É possível obter uma lista de todos os recursos personalizados do tipo `AmazonCloudWatchAgent`, que estão instalados em seu cluster, ao inserir o seguinte comando:
```
kubectl get amazoncloudwatchagent -A
```
Na saída desse comando, você poderá verificar a versão do agente do CloudWatch. Como alternativa, também é possível descrever o recurso `amazoncloudwatchagent` ou um dos pods do `cloudwatch-agent-*` em execução no cluster para inspecionar a imagem que está sendo usada.
### Tratamento de um ConfigurationConflict ao gereciar o complemento ou o chart do Helm
Ao instalar ou atualizar o complemento de observabilidade do EKS do Amazon CloudWatch ou o chart do Helm, se você perceber uma falha causada por recursos existentes, é provável que você já tenha o agente do CloudWatch e os componentes associados, como o ServiceAccount, o ClusterRole e o ClusterRoleBinding, instalados no cluster.
O erro exibido pelo complemento incluirá . `Conflicts found when trying to apply. Will not continue due to resolve conflicts mode`,
O erro exibido pelo chart do Helm será semelhante a `Error: INSTALLATION FAILED: Unable to continue with install and invalid ownership metadata.`.
Quando o complemento ou o chart do Helm tentar instalar o agente do CloudWatch e os componentes associados, se ele 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.
Se você estiver tentando realizar a integração do complemento de observabilidade do EKS do Amazon CloudWatch e verificar essa falha, recomendamos excluir uma configuração existente do agente do CloudWatch instalada anteriormente no cluster e, em seguida, instalar o chart do Helm ou o complemento do EKS. Certifique-se de fazer backup de quaisquer personalizações que você possa ter executado na configuração original do agente do CloudWatch, como uma configuração do agente personalizada, e fornecê-las ao complemento ou ao chart do Helm na próxima instalação ou atualização. Se você realizou a instalação do agente do CloudWatch para a integração com o Container Insights, consulte [Exclusão do agente do CloudWatch e do Fluent Bit para o Container Insights](ContainerInsights-delete-agent.md) para obter mais informações.
Como alternativa, o complemento oferece suporte a uma opção de configuração de resolução de conflitos que tem a funcionalidade de especificar `OVERWRITE`. É possível usar essa opção para prosseguir com a instalação ou a atualização do complemento ao substituir os conflitos no cluster. Se você estiver usando o console do Amazon EKS, encontrará o **Método de resolução de conflitos** ao escolher as **Definições de configuração opcionais** na criação ou na atualização do complemento. Caso esteja usando a AWS CLI, você poderá fornecer o comando `--resolve-conflicts OVERWRITE` para criar ou atualizar o complemento.
## Optar por não usar o Application Signals
Ajuste suas preferências de monitoramento de serviços no console do CloudWatch ou com o SDK.
Para versões anteriores à 5.0.0, para desabilitar o monitoramento automático do Application Signals, siga o procedimento abaixo:
**Usando a CLI ou o SDK**
A configuração a seguir pode ser aplicada como uma configuração avançada no complemento EKS ou como uma substituição de valores ao usar o chart do Helm.
```
{
"manager": {
"applicationSignals": {
"autoMonitor": {
"monitorAllServices": false
}
}
}
}
```
Reinicie os serviços para que alterações entrarem em vigor.
**Utilizar o console**
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 **Application Signals (APM)** escolha **Serviços**.
1. Escolha **Habilitar o Application Signals** para visualizar a página de habilitação.
1. Desmarque a caixa de seleção **Monitoramento automático** de cada serviço que você não desejar monitorar.
1. Reinicie os serviços para que alterações entrarem em vigor.