View a markdown version of this page

Supervisión de los entornos de Beanstalk Cluster - AWS Elastic Beanstalk
Métricas, registros y rastreosEnviar datos de observabilidad a un backend de terceros

Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Supervisión de los entornos de Beanstalk Cluster

Un entorno de Beanstalk Cluster informa sobre el estado a nivel del entorno mediante el mismo modelo de estado y las mismas API de Elastic Beanstalk que un entorno de Beanstalk Standard. Puede ver su estado y color en la consola de Elastic Beanstalk, y puede llamarlo DescribeEnvironmentHealth para ver el color actual, el estado y las causas que lo explican. Los colores y estados de salud tienen el mismo significado en ambos modos.

Cuando un entorno de Beanstalk Cluster usa un balanceador de carga de aplicaciones, Elastic Beanstalk determina el estado de la aplicación a partir de las métricas del balanceador de carga del entorno: la tasa de solicitudes, la proporción de solicitudes que devuelven respuestas HTTP 4xx y 5xx y la latencia de respuesta. Un entorno que atiende las solicitudes informa correctamente de que se encuentra en buen estado. A medida que aumenta la proporción de solicitudes fallidas, el estado se agrava progresivamente. Un entorno que recibe demasiado poco tráfico como para que Elastic Beanstalk lo evalúe informa de que la tasa de solicitudes es insuficiente para determinar el estado, lo que se espera en un entorno inactivo. Si configuras el tipo de balanceador de cargas enNone, esta evaluación del balanceador de cargas no se aplica.

A diferencia de un entorno Beanstalk Standard, un entorno de Beanstalk Cluster no informa sobre el estado de cada instancia. Beanstalk Cluster no usa el agente de estado de la instancia y no se aplica la configuración de informes de estado a nivel de instancia que se aplica a los entornos estándar.

Las sondas de contenedores controlan cuándo las réplicas de aplicaciones reciben tráfico y cuándo se reinician: una sonda de preparación elimina del servicio una copia que no está lista, una sonda activa reinicia una copia que no está en buen estado y una sonda de inicio permite inicializar una copia que comienza lentamente. Configure las sondas con los espacios de nombres de las sondas en la parte inferior. aws:elasticbeanstalk:eks:environment Consulte Los espacios de nombres de la sonda del contenedor.

Métricas, registros y rastreos

La observabilidad de las aplicaciones es independiente del estado del entorno. Usted selecciona los backends para las métricas, los registros y los seguimientos de su aplicación con las opciones de configuración del espacio de nombres. aws:elasticbeanstalk:eks:observability De forma predeterminada, Elastic Beanstalk envía las métricas y los registros de la aplicación a Amazon CloudWatch (CloudWatch) y los seguimientos no tienen ningún backend. En su lugar, puede enviar los registros a Amazon S3, enviar las métricas a Amazon Managed Service para Prometheus y enviar los seguimientos a. AWS X-Ray También puede enviar cualquiera de los tres a un servidor externo que acepte OpenTelemetry datos; consulte. Enviar datos de observabilidad a un backend de terceros Para ver las opciones disponibles, consulteaws:elasticbeanstalk:eks:observability.

Elastic Beanstalk aprovisiona y opera los componentes de recopilación y publica las métricas de infraestructura en su nombre. Usted es responsable de instrumentar su aplicación para que emita las métricas, los registros y los seguimientos que desee, y de proporcionar y mantener el acceso a cualquier destino que seleccione.

Tu aplicación tiene que emitir OpenTelemetry datos para que un backend pueda recibir cualquier información. Para hacerlo sin cambiar tu aplicación, configura la language opción del espacio de aws:elasticbeanstalk:eks:environment nombres en el tiempo de ejecución de tu aplicación. Elastic Beanstalk agrega la OpenTelemetry instrumentación automática para ese tiempo de ejecución a su contenedor, lo que se aplica a todos los back-end y a terceros por igual. AWS Auto-instrumentation está disponible para aplicaciones Java, Python y.NET Node.js. En el caso de una aplicación Java, el agente también une Log4j2, Logback yjava.util.logging, de modo que los registros de la aplicación lleguen al backend de los registros sin ningún cambio en la aplicación.

Por separado del backend de los registros, Elastic Beanstalk recopila un registro de implementación para cada operación del entorno. Contiene los registros de los contenedores de los pods y los eventos de Kubernetes de la operación, por lo que es el lugar ideal para consultarlo cuando se produce un error en una operación. Para obtener más información, consulte Registros de implementación.

Puedes encontrar tus registros y métricas en CloudWatch

Con los backends predeterminados, Elastic Beanstalk escribe en cuatro grupos de registros. CloudWatch Los nombres de los grupos de registros son fijos y no se pueden cambiar.

CloudWatch grupos de registros para entornos de Beanstalk Cluster
Grupo de registros Contenido Nombre del flujo de registro Cuando existe

/aws/elasticbeanstalk/application/logs

Salida de los contenedores de su aplicación.

eb-environment-name.pod-name

Cuándo logs-backend es cloudwatch el valor predeterminado.

/aws/elasticbeanstalk/application/metrics

Métricas que emite tu aplicación.

environment-name/pod-name

Cuándo metrics-backend es cloudwatch la predeterminada y su aplicación emite las métricas.

/aws/elasticbeanstalk/infrastructure/logs

El resultado de los componentes que Elastic Beanstalk ejecuta en el clúster en su nombre.

kubernetes-namespace.pod-name

Siempre.

/aws/elasticbeanstalk/infrastructure/metrics

Las métricas que Elastic Beanstalk publica para usted, en formato de métricas integrado.

kubernetes-namespace.pod-name

Siempre.
nota

Estos grupos de registros se comparten. Todos los entornos de Beanstalk Cluster de una AWS cuenta y una región escriben en los mismos cuatro grupos de todos los clústeres. Los datos de su entorno se separan por el nombre del flujo de registros, no por el grupo de registros. Elastic Beanstalk ejecuta cada entorno en un espacio de nombres de Kubernetes denominado eb- seguido del nombre del entorno, por lo que los flujos de registro de la aplicación comienzan por y por un punto. eb-environment-name Los flujos métricos de su aplicación comienzan con el nombre del entorno y una barra, sin prefijos. eb-

Elastic Beanstalk crea estos grupos de registros sin una política de retención, por lo que su contenido nunca caduca. Los nombres de las transmisiones de registros contienen el nombre del pod, por lo que cada implementación crea nuevas transmisiones y las transmisiones de las implementaciones anteriores permanecen. Establezca una política de retención en cada grupo de registros para limitar lo que almacena.

Las métricas que Elastic Beanstalk publica para usted llegan en tres espacios de nombres. CloudWatch Los tres son espacios de nombres personalizados, por los que se paga por métrica. En cambio, los entornos de Beanstalk Standard se publican en el espacio de AWS/ElasticBeanstalk nombres, que se proporciona de forma gratuita. CloudWatch Un entorno de Beanstalk Cluster publica las siguientes métricas de contenedores para cada una de sus réplicas, por lo que la cantidad de métricas personalizadas aumenta con la cantidad de réplicas que ejecute. Para conocer las tarifas actuales, consulta los precios de Amazon. CloudWatch

CloudWatch métricas para los entornos de Beanstalk Cluster
Namespace Métricas Dimensiones

ElasticBeanstalk/Infrastructure

Para los contenedores de su aplicación:container_cpu_usage_seconds_total,, y container_memory_working_set_bytesEnvironmentReplicas, la cantidad de réplicas que están listas.

Las métricas de los dos contenedores se publican con container y namespacepod, de nuevo, namespace solo. EnvironmentReplicasse publica namespace únicamente con.

ElasticBeanstalk/System

Las mismas dos métricas de contenedor son para los componentes que Elastic Beanstalk ejecuta en el clúster en su nombre y no para su aplicación.

namespace,, podcontainer, y nuevamente con solo. namespace

ElasticBeanstalk/Application

Las métricas que emite su aplicación, incluidas las métricas de tiempo de ejecución que produce la autoinstrumentación.

EnvironmentName. La duración de la solicitud también se publica con http.methodhttp.route, yhttp.status_code.

La namespace dimensión es el espacio de nombres de Kubernetes, por lo que su valor va eb- seguido del nombre del entorno. En su lugar, el espacio de ElasticBeanstalk/Application nombres usa una EnvironmentName dimensión cuyo valor es el nombre del entorno en sí mismo. Utilice el valor que coincida con el espacio de nombres que está consultando.

Si lo logs-backend configuras ens3, Elastic Beanstalk escribe los registros de tu aplicación en un bucket con el mismo nombreelasticbeanstalk-logs-account-id-region-an, con una clave creada a partir del espacio de nombres de Kubernetes, el nombre del pod y la fecha, y no pasa nada hasta. /aws/elasticbeanstalk/application/logs Elastic Beanstalk agrupa estas cargas en lotes, por lo que un objeto puede tardar hasta un minuto en aparecer. Si lo configuras logs-backend o metrics-backend lo hacescustom, esos datos van al backend que configuras y no aparecen en ninguno de estos grupos de registros. Consulte Enviar datos de observabilidad a un backend de terceros.

Enviar datos de observabilidad a un backend de terceros

Beanstalk Cluster recopila la telemetría de tu aplicación con el OpenTelemetry recopilador, por lo que puedes enviarla a cualquier backend que acepte OpenTelemetry datos, como Datadog o Splunk, en lugar de enviarla a un destino. AWS Usted proporciona la configuración de la canalización y las credenciales que necesita, y Elastic Beanstalk ejecuta la canalización como un contenedor secundario en el pod de la aplicación.

La configuración de un backend de terceros requiere cuatro pasos:

  1. Configura cada señal a la que quieras redirigircustom. Las señales son independientes, por lo que puedes enviar métricas y registros a un servidor externo mientras se sigue rastreando. AWS X-Ray Usa metrics-backend y logs-backend traces-backend en el espacio de aws:elasticbeanstalk:eks:observability nombres.

  2. custom-configEstablézcalo en la configuración de canalización del recopilador, como JSON. Haga referencia a cada credencial como un ${NAME} marcador de posición en lugar de poner el valor en la configuración.

  3. Guarde las credenciales AWS Secrets Manager y establézcalas custom-credentials en el ARN del secreto. El valor secreto debe ser un objeto JSON cuyas claves coincidan con los nombres de los marcadores de posición de tu configuración.

  4. Configura la application-role opción en el espacio de aws:elasticbeanstalk:eks:environment nombres y concede a ese rol permiso para leer el secreto. El recopilador usa la función de aplicación en tiempo de ejecución, no la función de observabilidad, y obtiene el secreto a través de la identidad del pod, que solo existe cuando application-role está configurada. Sin él, el montaje falla y las réplicas nunca se inician.

En el siguiente ejemplo, se envían métricas y registros a Datadog y se mantiene el seguimiento de esa información. AWS X-Ray En primer lugar, cree el secreto que contiene las credenciales a las que hace referencia su configuración:

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

Conceda permiso al rol de la aplicación para leerla, de modo que el recopilador pueda recuperarla en tiempo de ejecución:

{
  "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"
    }
  ]
}

Elastic Beanstalk actualiza las credenciales montadas según un cronograma y la actualización comprueba la versión actual del secreto, por lo que debe concedérselas además de. secretsmanager:DescribeSecret secretsmanager:GetSecretValue Un entorno comienza GetSecretValue por sí solo, pero cada actualización posterior falla.

A continuación, coloque la configuración de las opciones en un archivo. La configuración de un recopilador contiene comas, que la sintaxis abreviada --option-settings trata como separadores, así que pasa la configuración como JSON en su lugar. Guarda lo siguiente comooptions.json, con la configuración de canalización como una cadena JSON en el valor: custom-config

[
  {
    "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"
  }
]

siteConfigúralo en el sitio de Datadog que usa tu organización. A continuación, aplique el archivo:

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

Defina una canalización para cada señal que establezcacustom. Una señal que se deja en un AWS destino sigue utilizando la colección que gestiona Elastic Beanstalk y no necesita canalización propia.

Los componentes sin configuración toman un objeto vacío, como. "batch": {} El receivers bloque es opcional. Si lo omite, Elastic Beanstalk agrega el receptor OTLP al que envía la aplicación y registra un evento del entorno que informa de la adición. El ejemplo anterior define el receptor de forma explícita.

Mientras lo configuras, agrega un debug exportador a cada canalización e inclúyelo en la exporters lista de canalizaciones. A continuación, el recopilador registra la telemetría que recibe y exporta, lo que te indica si los datos llegan al recopilador y, por separado, si el recopilador puede llegar a tu backend.