Instalação do agente do CloudWatch com o complemento de observabilidade do EKS do Amazon CloudWatch ou com o chart do Helm - Amazon CloudWatch
Opção 1: instalar com permissões do IAM nos nós de processamento Opção 2: instalar usando o perfil da conta de serviço do IAM (aplica-se somente ao uso do complemento)(Opcional) Configuração adicionalSolução de problemas

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 com observabilidade aprimorada para o Amazon EKS e o CloudWatch Application Signals 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 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.

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. No momento, o Application Signals não é compatível com 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.

Opção 1: 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 AWS CloudFormation ou o Terraform.

AWS CLI
Como usar a AWS CLI para instalar o complemento Amazon CloudWatch Observability do EKS

Insira o comando da 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#/clusters.

  2. No painel de navegação à esquerda, escolha Clusters.

  3. Escolha o nome do cluster para o qual você deseja configurar o complemento Amazon CloudWatch Observability do EKS.

  4. Escolha a guia Add-ons (Complementos).

  5. Escolha Obter mais complementos.

  6. 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.

    2. Escolha Próximo.

  7. Na página Definir as configurações dos complementos selecionados:

    1. Selecione a Versão que deseja usar.

    2. Em Selecionar perfil do IAM, selecione Herdar do nó

    3. (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.

    4. Escolha Próximo.

  8. Na página Adicionar tags, escolha Criar. Depois que a instalação do complemento for concluída, você verá o complemento instalado.

AWS CloudFormation
Como usar o AWS 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.

{
    "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.

  2. 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_eks_addon.

resource "aws_eks_addon" "example" {
  addon_name   = "amazon-cloudwatch-observability"
  cluster_name = "my-cluster-name"
}

Opção 2: 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.

  • Você instalou o kubectl e configurou o cluster. Para obter mais informações, consulte Instalar o kubectl 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 no Guia do usuário do Amazon EKS.

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 no Guia do usuário do Amazon EKS.

    eksctl utils associate-iam-oidc-provider --cluster my-cluster-name --approve

  2. 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

  3. 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

(Opcional) Configuração adicional

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.

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

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

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 .

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) .

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.

{
  "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 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, 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.

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

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.


{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Action": [
                "ec2:DescribeVolumes"
            ],
            "Resource": "*",
            "Effect": "Allow"
        }
    ]
}

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.

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