Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Monitoraggio degli ambienti Beanstalk Cluster

Un ambiente Beanstalk Cluster riporta lo stato di salute a livello di ambiente tramite lo stesso modello di integrità Elastic Beanstalk e le stesse API di un ambiente Beanstalk Standard. Puoi visualizzarne il colore e lo stato di salute nella console Elastic Beanstalk e puoi chiamare per leggere il colore corrente, lo stato e le cause che lo spieganoDescribeEnvironmentHealth. I colori e gli stati di salute hanno lo stesso significato in entrambe le modalità.

Quando un ambiente Beanstalk Cluster utilizza un Application Load Balancer, Elastic Beanstalk determina lo stato dell'applicazione in base alle metriche del load balancer dell'ambiente: la frequenza delle richieste, la percentuale di richieste che restituiscono risposte HTTP 4xx e 5xx e la latenza delle risposte. Un ambiente che soddisfa le richieste riporta con successo uno stato di integrità. Con l'aumentare della percentuale di richieste non riuscite, lo stato diventa progressivamente più grave. Un ambiente che riceve troppo poco traffico per consentire a Elastic Beanstalk di valutare, segnala che la frequenza delle richieste è insufficiente per determinare lo stato di salute, il che è previsto per un ambiente inattivo. Se si imposta il tipo di load balancer suNone, questa valutazione del load balancer non si applica.

A differenza di un ambiente Beanstalk Standard, un ambiente Beanstalk Cluster non riporta lo stato di salute per istanza. Beanstalk Cluster non utilizza l'agente di integrità sull'istanza e le impostazioni di reporting sullo stato a livello di istanza che si applicano agli ambienti Standard non si applicano.

Le sonde container controllano quando le repliche delle applicazioni ricevono traffico e quando vengono riavviate: una sonda di disponibilità rimuove una copia non pronta dal servizio, una sonda liveness riavvia una copia che non è integra e una sonda di avvio fornisce un tempo di avvio lento per l'inizializzazione della copia. Configura aws:elasticbeanstalk:eks:environment le sonde con i namespace delle sonde sotto. Consulta I namespace della sonda contenitore.

Metriche, registri e tracce

L'osservabilità delle applicazioni è separata dalla salute dell'ambiente. Selezionate i backend per le metriche, i log e le tracce dell'applicazione con le opzioni di configurazione nel namespace. aws:elasticbeanstalk:eks:observability Per impostazione predefinita, Elastic Beanstalk invia le metriche e i log dell'applicazione ad Amazon CloudWatch () CloudWatch e le tracce non hanno un backend. Puoi invece inviare log ad Amazon S3, inviare metriche ad Amazon Managed Service for Prometheus e inviare tracce a. AWS X-Ray Puoi anche inviare uno dei tre a un backend di terze parti che accetta dati; vedi. OpenTelemetry Invio di dati di osservabilità a un backend di terze parti Per le opzioni disponibili, consultaaws:elasticbeanstalk:eks:observability.

Elastic Beanstalk fornisce e gestisce i componenti di raccolta e pubblica le metriche dell'infrastruttura per tuo conto. Sei responsabile della strumentazione della tua applicazione in modo che emetta le metriche, i log e le tracce che desideri e di fornire e mantenere l'accesso a qualsiasi destinazione selezionata.

L'applicazione deve emettere OpenTelemetry dati affinché un backend possa ricevere qualsiasi cosa. Per ottenere ciò senza modificare l'applicazione, imposta l'languageopzione nel aws:elasticbeanstalk:eks:environment namespace sul runtime dell'applicazione. Elastic Beanstalk aggiunge la OpenTelemetry strumentazione automatica per quel runtime al contenitore, che si applica a tutti i backend e alle terze parti. AWS Auto-instrumentation è disponibile per applicazioni Java, Python e.NET. Node.js Per un'applicazione Java, l'agente collega anche Log4j2, Logback ejava.util.logging, in modo che i log dell'applicazione raggiungano il backend dei log senza alcuna modifica all'applicazione.

Separatamente dal backend dei log, Elastic Beanstalk raccoglie un registro di distribuzione per ogni operazione dell'ambiente. Contiene i log dei container dei tuoi pod e gli eventi Kubernetes relativi all'operazione, il che lo rende il posto dove cercare quando un'operazione fallisce. Per ulteriori informazioni, consulta Log di distribuzione.

Trova i tuoi log e le tue metriche in CloudWatch

Con i backend predefiniti, Elastic Beanstalk scrive su quattro gruppi di log. CloudWatch I nomi dei gruppi di log sono fissi e non è possibile modificarli.

Elastic Beanstalk crea questi gruppi di log senza una politica di conservazione, quindi i loro contenuti non scadono mai. I nomi dei log stream contengono il nome del pod, quindi ogni distribuzione crea nuovi stream e i flussi delle distribuzioni precedenti rimangono invariati. Imposta una politica di conservazione su ogni gruppo di log per limitare ciò che archivi.

Le metriche che Elastic Beanstalk pubblica per te sono disponibili in tre namespace. CloudWatch Tutti e tre sono namespace personalizzati, pagati per metrica. Gli ambienti Beanstalk Standard pubblicano invece nel AWS/ElasticBeanstalk namespace, che fornisce gratuitamente. CloudWatch Un ambiente Beanstalk Cluster pubblica le metriche del contenitore riportate di seguito per ciascuna delle sue repliche, quindi il numero di metriche personalizzate aumenta con il numero di repliche eseguite. Per le tariffe attuali, consulta i prezzi di Amazon. CloudWatch

La namespace dimensione è lo spazio dei nomi Kubernetes, quindi il suo valore è eb- seguito dal nome dell'ambiente. Il ElasticBeanstalk/Application namespace utilizza invece una EnvironmentName dimensione il cui valore è il nome dell'ambiente a sé stante. Usa il valore che corrisponde allo spazio dei nomi su cui stai interrogando.

Se lo logs-backend impostis3, Elastic Beanstalk scrive i log della tua applicazione in un bucket denominato elasticbeanstalk-logs-account-id-region-an instead, con una chiave creata a partire dallo spazio dei nomi Kubernetes, dal nome del pod e dalla data, e non va a nulla. /aws/elasticbeanstalk/application/logs Elastic Beanstalk raggruppa questi caricamenti in batch, quindi la visualizzazione di un oggetto può richiedere fino a un minuto. Se si imposta logs-backend o metrics-backend si attivacustom, i dati vengono trasferiti al backend configurato e non vengono visualizzati in nessuno di questi gruppi di log. Consulta Invio di dati di osservabilità a un backend di terze parti.

Invio di dati di osservabilità a un backend di terze parti

Beanstalk Cluster raccoglie la telemetria dell'applicazione con il OpenTelemetry raccoglitore, quindi puoi inviarla a qualsiasi backend che accetta OpenTelemetry dati, come Datadog o Splunk, anziché a una destinazione. AWS Fornisci la configurazione della pipeline e le credenziali necessarie ed Elastic Beanstalk esegue la pipeline come contenitore sidecar nel pod dell'applicazione.

La configurazione di un backend di terze parti richiede quattro operazioni:

L'esempio seguente invia metriche e log a Datadog e ne conserva le tracce. AWS X-Ray Innanzitutto, crea il segreto che contiene le credenziali a cui fai riferimento la tua configurazione:

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

Concedi al ruolo dell'applicazione il permesso di leggerlo, in modo che il raccoglitore possa recuperarlo in fase di esecuzione:

{
  "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 aggiorna le credenziali montate in base a una pianificazione e l'aggiornamento verifica la versione corrente del segreto, quindi concedi in aggiunta a. secretsmanager:DescribeSecret secretsmanager:GetSecretValue Un ambiente inizia da GetSecretValue solo, ma ogni successivo aggiornamento ha esito negativo.

Quindi, inserisci le impostazioni delle opzioni in un file. Una configurazione di raccolta contiene virgole, che la sintassi abbreviata di --option-settings tratta come separatori, quindi passate invece le impostazioni come JSON. Salvate quanto segue con nomeoptions.json, con la configurazione della pipeline come stringa JSON nel valore: 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"
  }
]

Imposta site il sito Datadog utilizzato dalla tua organizzazione. Quindi applica il file:

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

Definite una pipeline per ogni segnale impostatocustom. Un segnale che lasci su una AWS destinazione continua a utilizzare la raccolta gestita da Elastic Beanstalk e non necessita di una pipeline propria.

I componenti senza impostazioni accettano un oggetto vuoto, ad esempio. "batch": {} Il receivers blocco è opzionale. Se lo ometti, Elastic Beanstalk aggiunge il ricevitore OTLP a cui l'applicazione invia e registra un evento di ambiente che segnala l'aggiunta. L'esempio precedente definisce il destinatario in modo esplicito.

Durante la configurazione, aggiungete un debug esportatore a ciascuna pipeline e includetelo nell'elenco della pipeline. exporters Il raccoglitore registra quindi la telemetria che riceve ed esporta, indicando se i dati stanno arrivando al raccoglitore e separatamente se il raccoglitore può raggiungere il vostro backend.