View a markdown version of this page

Monitorando ambientes do Beanstalk Cluster - AWS Elastic Beanstalk
Métricas, registros e rastreamentosEnvio de dados de observabilidade para um back-end de terceiros

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

Monitorando ambientes do Beanstalk Cluster

Um ambiente Beanstalk Cluster relata a integridade em nível de ambiente por meio do mesmo modelo de integridade e APIs do Elastic Beanstalk de um ambiente Beanstalk Standard. Você visualiza sua saúde, cor e status no console do Elastic Beanstalk e pode ligar DescribeEnvironmentHealth para ler a cor atual, o status e as causas que o explicam. As cores e os status de saúde têm os mesmos significados nos dois modos.

Quando um ambiente Beanstalk Cluster usa um Application Load Balancer, o Elastic Beanstalk determina a integridade do aplicativo a partir das métricas do balanceador de carga do ambiente: a taxa de solicitações, a proporção de solicitações que retornam respostas HTTP 4xx e 5xx e a latência da resposta. Um ambiente que atende às solicitações relata com êxito um status saudável. À medida que a proporção de solicitações com falha aumenta, o status se torna progressivamente mais severo. Um ambiente que recebe muito pouco tráfego para o Elastic Beanstalk avaliar relata que a taxa de solicitação é insuficiente para determinar a integridade, o que é esperado em um ambiente ocioso. Se você definir o tipo de balanceador de carga comoNone, essa avaliação do balanceador de carga não se aplica.

Ao contrário de um ambiente Beanstalk Standard, um ambiente Beanstalk Cluster não relata a integridade por instância. O Beanstalk Cluster não usa o agente de integridade na instância, e as configurações de relatórios de integridade no nível da instância que se aplicam aos ambientes padrão não se aplicam.

As sondas de contêiner controlam quando as réplicas de aplicativos recebem tráfego e quando são reinicializadas: uma sonda de prontidão remove uma cópia não pronta do serviço, uma sonda de atividade reinicia uma cópia que permanece iníntegra e uma sonda de inicialização permite que a cópia seja inicializada lentamente. Configure as sondas com os namespaces da sonda abaixo. aws:elasticbeanstalk:eks:environment Consulte Os namespaces da sonda de contêiner.

Métricas, registros e rastreamentos

A observabilidade do aplicativo é separada da saúde do ambiente. Você seleciona os back-ends para as métricas, registros e rastreamentos do seu aplicativo com as opções de configuração no aws:elasticbeanstalk:eks:observability namespace. Por padrão, o Elastic Beanstalk envia as métricas e os logs do seu aplicativo para a Amazon CloudWatch (CloudWatch), e os rastreamentos não têm back-end. Em vez disso, você pode enviar logs para o Amazon S3, enviar métricas para o Amazon Managed Service for Prometheus e enviar rastreamentos para o. AWS X-Ray Você também pode enviar qualquer um dos três para um back-end de terceiros que aceite OpenTelemetry dados; consulteEnvio de dados de observabilidade para um back-end de terceiros. Para ver as opções disponíveis, consulteaws: elasticbeanstalk: eks: observabilidade.

O Elastic Beanstalk provisiona e opera os componentes de coleta e publica métricas de infraestrutura em seu nome. Você é responsável por instrumentar seu aplicativo para que ele emita as métricas, os registros e os rastreamentos desejados e por fornecer e manter o acesso a qualquer destino selecionado.

Seu aplicativo precisa emitir OpenTelemetry dados para que um back-end receba qualquer coisa. Para fazer isso sem alterar seu aplicativo, defina a language opção no aws:elasticbeanstalk:eks:environment namespace para o tempo de execução do seu aplicativo. O Elastic Beanstalk adiciona OpenTelemetry instrumentação automática para esse tempo de execução ao seu contêiner, o que se aplica tanto a todos os back-ends quanto a terceiros. AWS Auto-instrumentation está disponível para aplicativos Java Node.js, Python e.NET. Para um aplicativo Java, o agente também conecta Log4j2, Logback ejava.util.logging, para que os registros do seu aplicativo cheguem ao back-end de registros sem nenhuma alteração no aplicativo.

Separadamente do back-end de logs, o Elastic Beanstalk coleta um log de implantação para cada operação do ambiente. Ele contém os registros do contêiner de seus pods e os eventos Kubernetes da operação, o que o torna o local ideal para verificar quando uma operação falha. Para obter mais informações, consulte Logs de implantação.

Encontrando seus registros e métricas em CloudWatch

Com os back-ends padrão, o Elastic Beanstalk grava em quatro grupos de logs. CloudWatch Os nomes dos grupos de registros são fixos e você não pode alterá-los.

CloudWatch grupos de log para ambientes Beanstalk Cluster
Grupo de registros Índice Nome do fluxo de logs Quando existe

/aws/elasticbeanstalk/application/logs

Saída dos contêineres do seu aplicativo.

eb-environment-name.pod-name

Quando logs-backend écloudwatch, o padrão.

/aws/elasticbeanstalk/application/metrics

Métricas que seu aplicativo emite.

environment-name/pod-name

Quando metrics-backend écloudwatch, o padrão, e seu aplicativo emite métricas.

/aws/elasticbeanstalk/infrastructure/logs

Saída dos componentes que o Elastic Beanstalk executa no cluster em seu nome.

kubernetes-namespace.pod-name

Sempre.

/aws/elasticbeanstalk/infrastructure/metrics

As métricas que o Elastic Beanstalk publica para você, em formato métrico incorporado.

kubernetes-namespace.pod-name

Sempre.
nota

Esses grupos de registros são compartilhados. Cada ambiente de cluster do Beanstalk em uma AWS conta e região grava nos mesmos quatro grupos, em cada cluster. Os dados do seu ambiente são separados pelo nome do fluxo de log, não pelo grupo de log. O Elastic Beanstalk executa cada ambiente em um namespace Kubernetes nomeado eb- seguido pelo nome do ambiente, então os fluxos de log do seu aplicativo começam com e um ponto final. eb-environment-name Os fluxos de métricas do seu aplicativo começam com o nome do ambiente e uma barra, sem eb- prefixo.

O Elastic Beanstalk cria esses grupos de logs sem uma política de retenção, portanto, seu conteúdo nunca expira. Os nomes dos fluxos de log contêm o nome do pod, portanto, cada implantação cria novos fluxos e os fluxos de implantações anteriores permanecem. Defina uma política de retenção em cada grupo de registros para limitar o que você armazena.

As métricas que o Elastic Beanstalk publica para você chegam em três namespaces. CloudWatch Todos os três são namespaces personalizados, pelos quais você paga por métrica. Em vez disso, os ambientes Beanstalk Standard publicam no AWS/ElasticBeanstalk namespace, que CloudWatch é fornecido gratuitamente. Um ambiente Beanstalk Cluster publica as métricas de contêiner abaixo para cada uma de suas réplicas, então o número de métricas personalizadas cresce com o número de réplicas que você executa. Para as tarifas atuais, consulte os CloudWatch preços da Amazon.

CloudWatch métricas para ambientes Beanstalk Cluster
Namespace Métricas Dimensões

ElasticBeanstalk/Infrastructure

Para os contêineres do seu aplicativo: container_cpu_usage_seconds_totalcontainer_memory_working_set_bytes,EnvironmentReplicas, e o número de réplicas que estão prontas.

As duas métricas do contêiner são publicadas com namespacepod, container e novamente com namespace apenas. EnvironmentReplicasé publicado namespace somente com.

ElasticBeanstalk/System

As mesmas duas métricas de contêiner, para os componentes que o Elastic Beanstalk executa no cluster em seu nome e não em seu aplicativo.

namespace,pod,container, e novamente namespace sozinho.

ElasticBeanstalk/Application

As métricas que seu aplicativo emite, incluindo as métricas de tempo de execução que a instrumentação automática produz.

EnvironmentName. A duração da solicitação também é publicada com http.methodhttp.route, http.status_code e.

A namespace dimensão é o namespace do Kubernetes, portanto, seu valor é eb- seguido pelo nome do seu ambiente. Em vez disso, o ElasticBeanstalk/Application namespace usa uma EnvironmentName dimensão cujo valor é o próprio nome do ambiente. Use o valor que corresponde ao namespace que você está consultando.

Se você logs-backend definir comos3, o Elastic Beanstalk grava os logs do seu aplicativo em um bucket chamado elasticbeanstalk-logs-account-id-region-an em vez disso, sob uma chave criada a partir do namespace Kubernetes, do nome do pod e da data, e nada é usado. /aws/elasticbeanstalk/application/logs O Elastic Beanstalk agrupa esses carregamentos, então um objeto pode levar até um minuto para aparecer. Se você definir logs-backend ou metrics-backend nãocustom, esses dados vão para o back-end que você configura e não aparecem em nenhum desses grupos de log. Consulte Envio de dados de observabilidade para um back-end de terceiros.

Envio de dados de observabilidade para um back-end de terceiros

O Beanstalk Cluster coleta a telemetria do seu aplicativo com o OpenTelemetry coletor, para que você possa enviá-la para qualquer back-end que aceite OpenTelemetry dados, como Datadog ou Splunk, em vez de para um destino. AWS Você fornece a configuração do pipeline e as credenciais necessárias, e o Elastic Beanstalk executa seu pipeline como um contêiner auxiliar no pod do seu aplicativo.

Configurar um back-end de terceiros exige quatro coisas:

  1. Defina cada sinal para o qual você deseja redirecionarcustom. Os sinais são independentes, então você pode enviar métricas e registros para um back-end de terceiros enquanto os rastreamentos continuam AWS X-Ray sendo enviados. Use metrics-backendlogs-backend, e traces-backend no aws:elasticbeanstalk:eks:observability namespace.

  2. custom-configDefina a configuração do pipeline do coletor, como JSON. Faça referência a cada credencial como um ${NAME} espaço reservado em vez de colocar o valor na configuração.

  3. Armazene as credenciais AWS Secrets Manager e defina-as como custom-credentials o ARN do segredo. O valor secreto deve ser um objeto JSON cujas chaves correspondam aos nomes dos espaços reservados em sua configuração.

  4. Defina a application-role opção no aws:elasticbeanstalk:eks:environment namespace e conceda a essa função permissão para ler o segredo. O coletor usa a função do aplicativo em tempo de execução, não a função de observabilidade, e alcança o segredo por meio da identidade do pod, que existe somente quando application-role está definida. Sem ela, a montagem falha e suas réplicas nunca começam.

O exemplo a seguir envia métricas e registros para o Datadog e mantém os rastreamentos em. AWS X-Ray Primeiro, crie o segredo que contém as credenciais às quais sua configuração faz referência:

$ aws secretsmanager create-secret \
    --name my-app/otel-credentials \
    --secret-string '{"DD_API_KEY":"your-api-key"}'

Conceda permissão à função do aplicativo para lê-la, para que o coletor possa buscá-la em tempo de execução:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "secretsmanager:GetSecretValue",
        "secretsmanager:DescribeSecret"
      ],
      "Resource": "arn:aws:secretsmanager:us-east-1:111122223333:secret:my-app/otel-credentials-AbCdEf"
    }
  ]
}

O Elastic Beanstalk atualiza as credenciais montadas de acordo com um cronograma, e a atualização verifica a versão atual do segredo, portanto, conceda além de. secretsmanager:DescribeSecret secretsmanager:GetSecretValue Um ambiente começa GetSecretValue sozinho, mas cada atualização posterior falha.

Em seguida, coloque as configurações da opção em um arquivo. Uma configuração de coletor contém vírgulas, que a sintaxe abreviada --option-settings trata como separadores. Em vez disso, passe as configurações como JSON. Salve o seguinte comooptions.json, com a configuração do pipeline como uma string JSON no custom-config valor:

[
  {
    "Namespace": "aws:elasticbeanstalk:eks:observability",
    "OptionName": "metrics-backend",
    "Value": "custom"
  },
  {
    "Namespace": "aws:elasticbeanstalk:eks:observability",
    "OptionName": "logs-backend",
    "Value": "custom"
  },
  {
    "Namespace": "aws:elasticbeanstalk:eks:observability",
    "OptionName": "traces-backend",
    "Value": "xray"
  },
  {
    "Namespace": "aws:elasticbeanstalk:eks:observability",
    "OptionName": "custom-config",
    "Value": "{\"receivers\":{\"otlp\":{\"protocols\":{\"grpc\":{\"endpoint\":\"0.0.0.0:4317\"},\"http\":{\"endpoint\":\"0.0.0.0:4318\"}}}},\"processors\":{\"batch\":{}},\"exporters\":{\"datadog\":{\"api\":{\"site\":\"datadoghq.com\",\"key\":\"${DD_API_KEY}\"}}},\"service\":{\"pipelines\":{\"metrics\":{\"receivers\":[\"otlp\"],\"processors\":[\"batch\"],\"exporters\":[\"datadog\"]},\"logs\":{\"receivers\":[\"otlp\"],\"processors\":[\"batch\"],\"exporters\":[\"datadog\"]}}}}"
  },
  {
    "Namespace": "aws:elasticbeanstalk:eks:observability",
    "OptionName": "custom-credentials",
    "Value": "arn:aws:secretsmanager:us-east-1:111122223333:secret:my-app/otel-credentials-AbCdEf"
  }
]

siteDefina como o site Datadog que sua organização usa. Em seguida, aplique o arquivo:

$ aws elasticbeanstalk update-environment \
    --environment-name my-cluster-env \
    --option-settings file://options.json

Defina um pipeline para cada sinal definidocustom. Um sinal que você deixa em um AWS destino continua usando a coleção que o Elastic Beanstalk opera e não precisa de um pipeline próprio.

Componentes sem configurações pegam um objeto vazio, como"batch": {}. O receivers bloco é opcional. Se você omiti-lo, o Elastic Beanstalk adiciona o receptor OTLP para o qual seu aplicativo envia e registra um evento do ambiente que relata a adição. O exemplo anterior define o receptor explicitamente.

Enquanto estiver configurando isso, adicione um debug exportador a cada funil e inclua-o na exporters lista do funil. Em seguida, o coletor registra a telemetria que recebe e exporta, que informa se os dados estão chegando ao coletor e, separadamente, se o coletor pode acessar seu back-end.