View a markdown version of this page

Risoluzione dei problemi relativi all'installazione di Application Signals - Amazon CloudWatch
Risolvi i conflitti OpenTelemetry di configurazione in Amazon EKS con Application SignalsPrestazioni di avvio a freddo del livello Java di Application SignalsL'applicazione non si avvia dopo l'abilitazione di Application SignalsL'applicazione Python non si avvia dopo l'abilitazione di Application SignalsNessun dato Application Signals per un'applicazione Python che utilizza un server pre-fork (WSGI o ASGI)La mia Node.js applicazione non è strumentata o non genera telemetria di Application SignalsLa mia applicazione.NET non è strumentata o non funziona per AWS Chiamate SDKNessun dato applicativo nel pannello di controllo di Application SignalsI valori delle metriche del servizio o di dipendenza sono sconosciutiGestione di un ConfigurationConflict quando si gestisce il componente aggiuntivo Amazon CloudWatch Observability EKSVoglio filtrare le metriche e le tracce non necessarieChe cosa significa InternalOperation?Come posso abilitare la registrazione per le applicazioni .NET?Come posso risolvere i conflitti tra le versioni dell'assemblaggio nelle applicazioni .NET?Posso disattivare FluentBit?Posso filtrare i log dei contenitori prima di esportarli in Logs? CloudWatchRisoluzione durante l'utilizzo TypeError AWS Distro per OpenTelemetry (ADOT) Lambda Layer JavaScriptTypeError quando si utilizzano i gestori Lambda di Response Streaming con AWS Distro per OpenTelemetry (ADOT) Lambda Layer JavaScriptAggiornamento alle versioni richieste degli agenti o del componente aggiuntivo Amazon EKSEmbedded Metric Format (EMF) disabilitato per Application Signals

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

Risoluzione dei problemi relativi all'installazione di Application Signals

Questa sezione contiene suggerimenti per la risoluzione dei problemi relativi a Application Signals CloudWatch .

Argomenti

Risolvi i conflitti OpenTelemetry di configurazione in Amazon EKS con Application Signals

Se utilizzi OpenTelemetry (Otel) per il monitoraggio delle prestazioni delle applicazioni (APM) con Amazon EKS e configuri endpoint di esportazione OTLP personalizzati diversi dagli CloudWatch endpoint, potresti riscontrare i seguenti comportamenti dopo l'installazione o l'aggiornamento alla versione 5.0.0 o successiva del componente aggiuntivo Observability: CloudWatch

  • Interruzione della telemetria Otel esistente: il componente aggiuntivo Observability può sovrascrivere gli endpoint di esportazione OTLP codificati nell'applicazione. CloudWatch Questa sostituzione non influisce sugli endpoint configurati tramite variabili di ambiente del contenitore o. envFrom ConfigMap Se sovrascritte, le metriche e le tracce potrebbero non raggiungere la destinazione prevista. Per mantenere la configurazione APM esistente dopo l'aggiornamento o successivo, consulta V5.0.0 Disattiva i segnali delle applicazioni

  • Application Signals potrebbe non funzionare se in precedenza hai abilitato Application Signals utilizzando il componente aggiuntivo CloudWatch Observability e hai configurato un endpoint OTLP personalizzato. Per risolvere questo problema, rimuovi gli endpoint OTLP personalizzati o imposta la variabile di ambiente OTEL_AWS_APPLICATION_SIGNALS_ENABLED=true durante l'installazione o l'aggiornamento alla versione 5.0.0 o successiva

Prestazioni di avvio a freddo del livello Java di Application Signals

L'aggiunta del livello Application Signals alle funzioni Java Lambda aumenta la latenza di avvio (tempo di avvio a freddo). I seguenti suggerimenti possono aiutare a ridurre la latenza per le funzioni sensibili al fattore tempo.

Avvio rapido per agente Java: il livello Java Lambda di Application Signals include una funzionalità di avvio rapido che per impostazione predefinita è disattivata, ma che può essere abilitata impostando la variabile OTEL_JAVA_AGENT_FAST_STARTUP_ENABLED su true. Se abilitata, questa funzionalità configura la JVM per utilizzare il compilatore C1 di livello 1 di compilazione a più livelli per generare codice nativo ottimizzato rapido per velocizzare gli avvii a freddo. Il compilatore C1 dà priorità alla velocità a scapito dell'ottimizzazione a lungo termine, mentre il compilatore C2 offre prestazioni complessive superiori profilando i dati nel tempo.

Per ulteriori informazioni, consulta Fast startup for Java agent.

Riduci i tempi di avvio a freddo con Provisioned Concurrency: la concorrenza con AWS Lambda provisioning prealloca un numero specificato di istanze di funzione, mantenendole inizializzate e pronte a gestire immediatamente le richieste. Ciò riduce i tempi di avvio a freddo eliminando la necessità di inizializzare l'ambiente della funzione durante l'esecuzione e garantendo prestazioni più rapide e coerenti, in particolare per i carichi di lavoro sensibili alla latenza. Per ulteriori informazioni, consulta Configuring provisioned concurrency for a function.

Ottimizza le prestazioni di avvio utilizzando Lambda SnapStart: AWS Lambda SnapStart è una funzionalità che ottimizza le prestazioni di avvio delle funzioni Lambda creando un'istantanea preinizializzata dell'ambiente di esecuzione dopo la fase di inizializzazione della funzione. Questo snapshot viene quindi riutilizzato per avviare nuove istanze, riducendo in modo significativo i tempi di avvio a freddo saltando il processo di inizializzazione durante l'invocazione della funzione. Per informazioni, consulta Miglioramento delle prestazioni di avvio con Lambda SnapStart

L'applicazione non si avvia dopo l'abilitazione di Application Signals

Se l'applicazione su un cluster Amazon EKS non si avvia dopo aver abilitato Application Signals sul cluster, verifica quanto segue:

  • Verifica se l'applicazione è stata strumentata da un'altra soluzione di monitoraggio. Application Signals potrebbe non supportare la coesistenza con altre soluzioni di instrumentazione.

  • Verifica che l'applicazione soddisfi i requisiti di compatibilità per utilizzare Application Signals. Per ulteriori informazioni, consulta Sistemi supportati.

  • Se l'applicazione non è riuscita a recuperare gli artefatti di Application Signals come l' CloudWatch agente e le immagini degli agenti di AWS Distro for OpenTelemetery Java o Python, potrebbe trattarsi di un problema di rete.

Per mitigare il problema, rimuovi l'annotazione instrumentation.opentelemetry.io/inject-java: "true" o instrumentation.opentelemetry.io/inject-python: "true" dal manifesto di implementazione dell'applicazione e implementa nuovamente l'applicazione. Quindi controlla se l'applicazione funziona.

Problemi noti

È noto che la raccolta delle metriche di runtime nella versione dell'SDK Java v1.32.5 non funziona con le applicazioni che utilizzano JBoss Wildfly. Questo problema si estende al componente aggiuntivo Amazon CloudWatch Observability EKS e riguarda le versioni successive. 2.3.0-eksbuild.1 2.5.0-eksbuild.1

Se riscontri problemi, esegui il downgrade della versione o disabilita la raccolta delle metriche di runtime aggiungendo la variabile di ambiente OTEL_AWS_APPLICATION_SIGNALS_RUNTIME_ENABLED=false all'applicazione.

L'applicazione Python non si avvia dopo l'abilitazione di Application Signals

È un problema noto della OpenTelemetry strumentazione automatica che a volte una variabile di PYTHONPATH ambiente mancante può causare il mancato avvio dell'applicazione. Per risolvere questo problema, assicuratevi di impostare la variabile di PYTHONPATH ambiente sulla posizione della directory di lavoro dell'applicazione. Per ulteriori informazioni su questo problema, consulta Python autoinstrumentation setting of PYTHONPATH is not compliant with Python's module resolution behavior, breaking Django applications.

Per le applicazioni Django, sono richieste configurazioni aggiuntive, descritte nella documentazione di Python. OpenTelemetry

  • Usa il flag --noreload per impedire il ricaricamento automatico.

  • Imposta la variabile di DJANGO_SETTINGS_MODULE ambiente nella posizione del file dell'applicazione Django. settings.py Ciò garantisce che OpenTelemetry possa accedere e integrarsi correttamente con le impostazioni di Django.

Nessun dato Application Signals per un'applicazione Python che utilizza un server pre-fork (WSGI o ASGI)

Pre-fork server, come Gunicorn, uWSGI o Uvicorn con più worker, separano i processi di lavoro da un processo principale. L' OpenTelemetry SDK si basa su thread in background che non sopravvivono a un fork, quindi quando il processo principale è strumentato, i lavoratori non possono esportare tracce, metriche e registri.

Per ulteriori informazioni su questo OpenTelemetry comportamento, consulta i problemi del Pre-fork server nella documentazione di Python. OpenTelemetry

Per risolvere questo problema, dovete prima inizializzare la strumentazione automatica in ogni processo di lavoro biforcato anziché nel processo principale, quindi configurare ADOT Python per saltare il processo principale.

Nota

Assicurati di utilizzare la versione più recente di ADOT Python e il componente aggiuntivo Amazon Observability EKS prima di procedere. CloudWatch

Passaggi aggiuntivi per abilitare Application Signals con un server pre-fork

  1. Inizializza la strumentazione automatica nei processi di lavoro biforcati.

    Per Gunicorn, usa l'hook post_fork:

    # gunicorn.conf.py
def post_fork(server, worker):
    from opentelemetry.instrumentation.auto_instrumentation import sitecustomize

    Per uWSGI, usa la direttiva import.

    #  uwsgi.ini
[uwsgi]
; required for the instrumentation of worker processes
enable-threads = true
lazy-apps = true
import = opentelemetry.instrumentation.auto_instrumentation.sitecustomize

    Per Uvicorn, FastAPI o altre applicazioni ASGI eseguite con più worker, inizializza la strumentazione all'interno del worker chiamando prima di importare l'applicazione. initialize() Inserisci quanto segue nella parte superiore del modulo entry-point dell'applicazione:

    from opentelemetry.instrumentation.auto_instrumentation import initialize

initialize()

# Import your application AFTER initialize() so that it is instrumented.
from fastapi import FastAPI

app = FastAPI()

    Quindi avvia il server come al solito, ad esempio:

    uvicorn main:app --workers 2

    In alternativa, se esegui un'applicazione ASGI in Gunicorn, puoi usare GunicornUvicornWorker, che conserva i thread di sfondo lungo il fork, insieme all'hook mostrato in precedenza: post_fork

    opentelemetry-instrument gunicorn \
  --workers 4 \
  --worker-class uvicorn.workers.UvicornWorker \
  --bind 0.0.0.0:8000 \
  myapp.main:app

  2. Abilita la configurazione per l'instrumentazione automatica di ADOT Python per saltare il processo principale e rimandarlo ai worker impostando la variabile di ambiente OTEL_AWS_PYTHON_DEFER_TO_WORKERS_ENABLED su true.

    Una volta applicati entrambi i passaggi, ogni processo di lavoro inizializza le proprie pipeline di tracciamento, metrica e log dopo il fork, in modo che tracce, metriche e log vengano esportati correttamente.

La mia Node.js applicazione non è strumentata o non genera telemetria di Application Signals

Per abilitare Application Signals for Node.js, devi assicurarti che l' Node.js applicazione utilizzi il formato del modulo CommonJS (CJS). Il AWS Distro for OpenTelemetry Node.js non supporta il formato del modulo ESM, perché OpenTelemetry JavaScript il supporto di ESM è sperimentale ed è in fase di elaborazione.

Per determinare se la tua applicazione utilizza CJS e non ESM, assicurati che l'applicazione non soddisfi le condizioni per abilitare ESM.

La mia applicazione.NET non è strumentata o non funziona per AWS Chiamate SDK

L'SDK AWS Distro for Open Telemetry (ADOT) per .NET non supporta l'SDK per .NET V4. AWS Usa AWS SDK.NET V3 per il supporto completo di Application Signals.

Nessun dato applicativo nel pannello di controllo di Application Signals

Se nei pannelli di controllo di Application Signals mancano parametri o tracce, le cause potrebbero essere le seguenti. Esamina queste cause solo se hai atteso per 15 minuti che Application Signals raccogliesse e visualizzasse i dati dall'ultimo aggiornamento.

  • Assicurati che la libreria e il framework che stai utilizzando siano supportati dall'agente Java ADOT. Per ulteriori informazioni, consulta Librerie/framework.

  • Assicurati che l' CloudWatch agente sia in esecuzione. Per prima cosa controllate lo stato degli CloudWatch agent pod e assicuratevi che siano tutti in Running stato.

    kubectl -n amazon-cloudwatch get pods.

    Aggiungete quanto segue al file di configurazione CloudWatch dell'agente per abilitare i log di debug, quindi riavviate l'agente.

    "agent": {

  "region": "${REGION}",
  "debug": true
},

    Quindi verifica la presenza di errori nei pod degli CloudWatch agenti.

  • Verifica la presenza di problemi di configurazione con l' CloudWatch agente. Verificate che quanto segue sia ancora presente nel file di configurazione CloudWatch dell'agente e che l'agente sia stato riavviato dopo l'aggiunta.

    "agent": {
  "region": "${REGION}",
  "debug": true
},

    Quindi controlla i log di OpenTelemetry debug per i messaggi di errore come. ERROR io.opentelemetry.exporter.internal.grpc.OkHttpGrpcExporter - Failed to export ... Questi messaggi potrebbero indicare il problema.

    Se questo non risolve il problema, scarica e controlla le variabili di ambiente con nomi che iniziano con OTEL_ descrivendo il pod con il comando kubectl describe pod.

  • Per abilitare la registrazione del debug di OpenTelemetry Python, imposta la variabile di ambiente su e ridistribuisci OTEL_PYTHON_LOG_LEVEL l'debugapplicazione.

  • Verifica le autorizzazioni errate o insufficienti per l'esportazione dei dati dall'agente. CloudWatch Se vedi Access Denied dei messaggi nei log dell' CloudWatch agente, questo potrebbe essere il problema. È possibile che le autorizzazioni applicate al momento dell'installazione dell' CloudWatch agente siano state successivamente modificate o revocate.

  • Verifica la presenza di un problema con AWS Distro for OpenTelemetry (ADOT) durante la generazione di dati di telemetria.

    Assicurati che le annotazioni sulla strumentazione instrumentation.opentelemetry.io/inject-java e sidecar.opentelemetry.io/inject-java vengano applicate alla distribuzione dell'applicazione e che il valore sia true. Senza questi, i pod dell'applicazione non saranno dotati di strumenti anche se il componente aggiuntivo ADOT è installato correttamente.

    Quindi, controlla se il container init è applicato all'applicazione e lo stato di Ready è True. Se il container init non è pronto, verifica lo stato del motivo.

    Se il problema persiste, abilita la registrazione di debug su OpenTelemetry Java SDK impostando la variabile di ambiente su true e ridistribuendo l'applicazione. OTEL_JAVAAGENT_DEBUG Quindi cerca i messaggi che iniziano con ERROR io.telemetry.

  • L'esportatore potrebbe eliminare i dati. metric/span Per scoprirlo, controlla il log dell'applicazione per i messaggi che includono Failed to export...

  • L' CloudWatch agente potrebbe subire limitazioni nell'invio di metriche o intervalli ad Application Signals. Controlla i messaggi che indicano la limitazione nei log dell'agente. CloudWatch

  • Assicurati di aver abilitato la configurazione di rilevamento servizi. È necessario eseguire questa operazione solo una volta nella Regione in uso.

    Per confermarlo, nella CloudWatch console scegli Application Signals, Services. Se il Passaggio 1 non è contrassegnato come Completo, scegli Scoperta dei servizi. I dati dovrebbero iniziare ad arrivare entro cinque minuti.

I valori delle metriche del servizio o di dipendenza sono sconosciuti

Se nelle dashboard di UnknownRemoteOperation Application Signals vedi UnknownService UnknownOperation UnknownRemoteService,,, o un nome di dipendenza o un'operazione, controlla se la presenza di punti dati per il servizio remoto sconosciuto e l'operazione remota sconosciuta coincidono con le relative distribuzioni.

  • UnknownServicesignifica che il nome di un'applicazione strumentata è sconosciuto. Se la variabile di ambiente OTEL_SERVICE_NAME non è definita e service.name non è specificato in OTEL_RESOURCE_ATTRIBUTES, il nome del servizio è impostato su UnknownService. Per risolvere questo problema, specifica il nome del servizio in OTEL_SERVICE_NAME o OTEL_RESOURCE_ATTRIBUTES.

  • UnknownOperationsignifica che il nome di un'operazione richiamata è sconosciuto. Ciò si verifica quando Application Signals non è in grado di rilevare il nome di un'operazione che invoca la chiamata remota o quando il nome dell'operazione estratto contiene valori di cardinalità elevati.

  • UnknownRemoteServicesignifica che il nome del servizio di destinazione è sconosciuto. Ciò si verifica quando il sistema non è in grado di estrarre il nome del servizio di destinazione a cui accede la chiamata remota.

    Una soluzione consiste nel creare un intervallo personalizzato attorno alla funzione che invia la richiesta e aggiungere l'attributo aws.remote.service con il valore designato. Un'altra opzione è configurare l' CloudWatch agente per personalizzare il valore della metrica diRemoteService. Per ulteriori informazioni sulle personalizzazioni nell' CloudWatch agente, vedere. Abilita i segnali CloudWatch delle applicazioni

  • UnknownRemoteOperationsignifica che il nome dell'operazione di destinazione è sconosciuto. Ciò si verifica quando il sistema non è in grado di estrarre il nome dell'operazione di destinazione a cui accede la chiamata remota.

    Una soluzione consiste nel creare un intervallo personalizzato attorno alla funzione che invia la richiesta e aggiungere l'attributo aws.remote.operation con il valore designato. Un'altra opzione è configurare l' CloudWatch agente per personalizzare il valore della metrica diRemoteOperation. Per ulteriori informazioni sulle personalizzazioni nell' CloudWatch agente, vedere. Abilita i segnali CloudWatch delle applicazioni

Gestione di un ConfigurationConflict quando si gestisce il componente aggiuntivo Amazon CloudWatch Observability EKS

Quando installi o aggiorni il componente aggiuntivo Amazon CloudWatch Observability EKS, se noti un errore causato da un oggetto Health Issue di tipo ConfigurationConflict la cui descrizione inizia conConflicts found when trying to apply. Will not continue due to resolve conflicts mode, è probabile che l' CloudWatch agente e i suoi componenti associati, ad esempio ServiceAccount,, ClusterRole e siano già ClusterRoleBinding installati nel cluster. Quando il componente aggiuntivo tenta di installare l' CloudWatch agente e i componenti associati, se rileva modifiche nei contenuti, per impostazione predefinita non riesce l'installazione o l'aggiornamento per evitare di sovrascrivere lo stato delle risorse sul cluster.

Se stai tentando di eseguire l'onboarding del componente aggiuntivo Amazon CloudWatch Observability EKS e riscontri questo errore, ti consigliamo di eliminare una configurazione CloudWatch dell'agente esistente che avevi precedentemente installato sul cluster e quindi installare il componente aggiuntivo EKS. Assicurati di eseguire il backup di tutte le personalizzazioni che potresti aver apportato alla configurazione originale dell'agente, ad esempio una configurazione personalizzata CloudWatch dell'agente, e forniscile al componente aggiuntivo Amazon CloudWatch Observability EKS la prossima volta che lo installerai o lo aggiornerai. Se in precedenza hai installato l' CloudWatch agente per l'onboarding in Container Insights, consulta Guida all'installazione (AWS CLI) per ulteriori informazioni.

In alternativa, il componente aggiuntivo supporta un'opzione di configurazione per la risoluzione dei conflitti che può specificare OVERWRITE. È possibile utilizzare questa opzione per procedere con l'installazione o l'aggiornamento del componente aggiuntivo sovrascrivendo i conflitti nel cluster. Se utilizzi la console Amazon EKS, trovi il metodo di risoluzione dei conflitti selezionando le impostazioni di configurazione facoltative quando crei o aggiorni il componente aggiuntivo. Se stai usando il AWS CLI, puoi fornire il comando --resolve-conflicts OVERWRITE per creare o aggiornare il componente aggiuntivo.

Voglio filtrare le metriche e le tracce non necessarie

Se Application Signals sta raccogliendo tracce e metriche che non desideri, consulta Gestione di operazioni ad alta cardinalità per informazioni sulla configurazione CloudWatch dell'agente con regole personalizzate per ridurre la cardinalità.

Per informazioni sulla personalizzazione delle regole di campionamento delle tracce, vedi Configurare le regole di campionamento nella documentazione. X-Ray

Che cosa significa InternalOperation?

InternalOperation è un'operazione che viene attivata dall'applicazione internamente anziché da un'invocazione esterna. La visualizzazione di InternalOperation è il comportamento previsto ed è indicazione di integrità.

Alcuni esempi tipici in cui potresti vedere InternalOperation includono quanto segue:

  • Precaricamento all'avvio: l'applicazione esegue un'operazione denominata loadDatafromDB che legge i metadati da un database durante la fase di riscaldamento. Invece di vedere loadDatafromDB come operazione di servizio, la vedrai classificata come InternalOperation.

  • Esecuzione asincrona in background: l'applicazione si iscrive a una coda di eventi ed elabora di conseguenza i dati in streaming ogni volta che c'è un aggiornamento. Ogni operazione attivata verrà eseguita sotto InternalOperation come operazione di servizio.

  • Recupero delle informazioni sull'host da un registro dei servizi: l'applicazione comunica con un registro dei servizi per il rilevamento servizi. Tutte le interazioni con il sistema di rilevamento sono classificate come InternalOperation.

Come posso abilitare la registrazione per le applicazioni .NET?

Per abilitare la registrazione per le applicazioni .NET, configura le seguenti variabili di ambiente. Per ulteriori informazioni su come configurare queste variabili di ambiente, vedi Risoluzione dei problemi relativi alla strumentazione automatica .NET nella documentazione. OpenTelemetry

  • OTEL_LOG_LEVEL

  • OTEL_DOTNET_AUTO_LOG_DIRECTORY

  • COREHOST_TRACE

  • COREHOST_TRACEFILE

Come posso risolvere i conflitti tra le versioni dell'assemblaggio nelle applicazioni .NET?

Se viene visualizzato il seguente errore, consultate Conflitti tra le versioni di Assembly nella OpenTelemetry documentazione per le fasi di risoluzione.

Unhandled exception. System.IO.FileNotFoundException: Could not load file or assembly 'Microsoft.Extensions.DependencyInjection.Abstractions, Version=7.0.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60'. The system cannot find the file specified.

File name: 'Microsoft.Extensions.DependencyInjection.Abstractions, Version=7.0.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60'
   at Microsoft.AspNetCore.Builder.WebApplicationBuilder..ctor(WebApplicationOptions options, Action`1 configureDefaults)
   at Microsoft.AspNetCore.Builder.WebApplication.CreateBuilder(String[] args)
   at Program.<Main>$(String[] args) in /Blog.Core/Blog.Core.Api/Program.cs:line 26

Posso disattivare FluentBit?

Puoi disattivare FluentBit configurando il componente aggiuntivo Amazon CloudWatch Observability EKS. Per ulteriori informazioni, consulta (Facoltativo) Configurazione aggiuntiva.

Posso filtrare i log dei contenitori prima di esportarli in Logs? CloudWatch

No, il filtraggio dei log dei container non è ancora supportato.

Risoluzione durante l'utilizzo TypeError AWS Distro per OpenTelemetry (ADOT) Lambda Layer JavaScript

La tua funzione Lambda potrebbe fallire con questo errore: TypeError - "Cannot redefine property: handler" quando:

  • Usa il livello ADOT Lambda JavaScript

  • Usare per compilare esbuild TypeScript

  • Si esporta il gestore con la parola chiave export

ADOT JavaScript Lambda Layer deve modificare il gestore in fase di esecuzione. Quando si utilizza la export parola chiave with esbuild (direttamente o tramite AWS CDK), esbuild rende immutabile il gestore, impedendo queste modifiche.

Esporta la tua funzione di gestione utilizzando module.exports invece della parola chiave export: 

// Before
export const handler = (event) => {
  // Handler Code
}
// After
const handler = async (event) => {
  // Handler Code
}
module.exports = { handler }

TypeError quando si utilizzano i gestori Lambda di Response Streaming con AWS Distro per OpenTelemetry (ADOT) Lambda Layer JavaScript

La tua funzione Lambda potrebbe fallire con questo errore: TypeError - "responseStream.write is not a function" quando:

  • Usa ADOT JavaScript Lambda Layer con AWS Lambda Instrumentation abilitata (abilitata per impostazione predefinita)

  • Utilizzo della funzionalità di streaming delle risposte in runtime gestiti. Node.js Ad esempio, quando il gestore delle funzioni è come:

    * export const handler = awslambda.streamifyResponse(...)

La strumentazione AWS Lambda in ADOT JavaScript Lambda Layer attualmente non supporta il Response Streaming nei runtime Node.js gestiti, quindi deve essere disabilitata per evitare che ciò accada. TypeError

Aggiornamento alle versioni richieste degli agenti o del componente aggiuntivo Amazon EKS

Dopo il 9 agosto 2024, CloudWatch Application Signals non supporterà più le versioni precedenti del componente aggiuntivo Amazon CloudWatch Observability EKS, dell'agente e dell' CloudWatch agente AWS Distro for autoinstrumentation. OpenTelemetry

  • Per il componente aggiuntivo Amazon CloudWatch Observability EKS, le versioni precedenti a questa non saranno supportate. v1.7.0-eksbuild.1

  • Per l' CloudWatch agente, le versioni precedenti alla 1.300040.0 non saranno supportate.

  • Per l'agente AWS Distro for OpenTelemetry Auto Instrumentation:

    • Per Java, le versioni precedenti alla 1.32.2 non sono supportate.

    • Per Python, le versioni precedenti alla 0.2.0 non sono supportate.

    • Per .NET, le versioni precedenti alla 1.3.2 non sono supportate.

    • Per Node.js, le versioni precedenti a non 0.3.0 sono supportate.

Importante

Le versioni più recenti degli agenti includono aggiornamenti allo schema delle metriche di Application Signals. Questi aggiornamenti non sono compatibili con le versioni precedenti e ciò può causare problemi di dati se vengono utilizzate versioni incompatibili. Per garantire una transizione ottimale alla nuova funzionalità, effettua le seguenti operazioni:

  • Se la tua applicazione è in esecuzione su Amazon EKS, assicurati di riavviare tutte le applicazioni strumentate dopo aver aggiornato il componente aggiuntivo Amazon CloudWatch Observability.

  • Per le applicazioni in esecuzione su altre piattaforme, assicurati di aggiornare sia l'agente che l' CloudWatch agente di AWS OpenTelemetry strumentazione automatica alle versioni più recenti.

Le istruzioni nelle sezioni seguenti possono aiutarti a eseguire l'aggiornamento a una versione supportata.

Aggiorna il componente aggiuntivo Amazon Observability EKS CloudWatch

Per il componente aggiuntivo Amazon CloudWatch Observability EKS, puoi utilizzare o. Console di gestione AWS AWS CLI

Eliminare con la console

Per aggiornare il componente aggiuntivo utilizzando la console

  1. Apri la console Amazon EKS all'indirizzo https://console.aws.amazon.com/eks/home #/clusters.

  2. Scegli il nome del cluster Amazon EKS da aggiornare.

  3. Scegli la Add-ons scheda, quindi scegli Amazon Observability. CloudWatch

  4. Scegli Modifica, seleziona la versione a cui desideri eseguire l'aggiornamento, quindi scegli Salva modifiche.

    Assicurati di scegliere v1.7.0-eksbuild.1 o successive.

  5. Inserisci uno dei seguenti AWS CLI comandi per riavviare i servizi.

      # Restart a deployment
  kubectl rollout restart deployment/name
  # Restart a daemonset
  kubectl rollout restart daemonset/name
  # Restart a statefulset
  kubectl rollout restart statefulset/name

Usa il AWS CLI

Per aggiornare il componente aggiuntivo utilizzando AWS CLI

  1. Immetti il seguente comando per trovare la versione più recente.

    aws eks describe-addon-versions \
--addon-name amazon-cloudwatch-observability

  2. Immetti il seguente comando per aggiornare il componente aggiuntivo. Sostituiscilo $VERSION con una versione precedente v1.7.0-eksbuild.1 o successiva. Sostituisci $AWS_REGION and $CLUSTER con la tua regione e il nome del cluster.

    aws eks update-addon \
--region $AWS_REGION \
--cluster-name $CLUSTER \
--addon-name amazon-cloudwatch-observability \
--addon-version $VERSION \
# required only if the advanced configuration is used.
--configuration-values $JSON_CONFIG
    Nota

    Se stai utilizzando una configurazione personalizzata per il componente aggiuntivo, puoi trovare un esempio della configurazione da utilizzare per $JSON_CONFIG inAbilita i segnali CloudWatch delle applicazioni.

  3. Inserisci uno dei seguenti AWS CLI comandi per riavviare i servizi.

      # Restart a deployment
  kubectl rollout restart deployment/name
  # Restart a daemonset
  kubectl rollout restart daemonset/name
  # Restart a statefulset
  kubectl rollout restart statefulset/name

Aggiornare l' CloudWatch agente e l'agente ADOT

Se i tuoi servizi sono in esecuzione su architetture diverse da Amazon EKS, dovrai aggiornare sia l'agente che l' CloudWatch agente di strumentazione automatica ADOT per utilizzare le funzionalità più recenti di Application Signals.

Aggiornamento su Amazon ECS

Per aggiornare gli agenti per i servizi in esecuzione su Amazon ECS

  1. Crea una nuova revisione della definizione delle attività. Per ulteriori informazioni, consulta Updating a task definition using the console.

  2. Sostituisci il valore $IMAGE del container ecs-cwagent con il tag dell'ultima immagine di cloudwatch-agent su Amazon ECR.

    Se esegui l'upgrade a una versione fissa, assicurati di utilizzare una versione pari a 1.300040.0 o successiva.

  3. Sostituisci il valore $IMAGE del container init con il tag dell'ultima immagine dalle seguenti posizioni:

    • Per Java, usa aws- -autoinstrumentation-java. observability/adot

      Se esegui l'upgrade a una versione fissa, assicurati di utilizzare una versione pari a 1.32.2 o successiva.

    • Per Python, usa aws- -autoinstrumentation-python. observability/adot

      Se esegui l'upgrade a una versione fissa, assicurati di utilizzare una versione pari a 0.2.0 o successiva.

    • Per .NET, usa aws- -autoinstrumentation-dotnet. observability/adot

      Se esegui l'upgrade a una versione fissa, assicurati di utilizzare una versione pari a 1.3.2 o successiva.

    • Per, usa aws- -autoinstrumentation-node. Node.js observability/adot

      Se esegui l'upgrade a una versione fissa, assicurati di utilizzare una versione pari a 0.3.0 o successiva.

  4. Aggiorna le variabili di ambiente di Application Signals nel container dell'app seguendo le istruzioni riportate all'indirizzo Fase 4: Configura la tua candidatura con l' CloudWatch agente.

  5. Implementa il servizio con la nuova definizione di attività.

Aggiornamento su Amazon EC2 o su altre architetture

Per aggiornare gli agenti per i servizi in esecuzione su Amazon EC2 o su altre architetture

  1. Assicurati di selezionare la versione 1.300040.0 o una versione successiva della versione dell'agente. CloudWatch

  2. Scaricate l'ultima versione dell'agente AWS Distro for OpenTelemetry Auto-Instrumentation da una delle seguenti posizioni:

  3. Applica le variabili di ambiente aggiornate di Application Signals all'applicazione, quindi avviala. Per ulteriori informazioni, consulta Passaggio 3: instrumentazione e avvio dell'applicazione.

Embedded Metric Format (EMF) disabilitato per Application Signals

La disabilitazione di EMF per il gruppo di log /aws/application-signals/data può avere il seguente impatto sulla funzionalità di Application Signals.

  • Le metriche e i grafici di Application Signals non verranno visualizzati

  • La funzionalità di Application Signals verrà ridotta

Come posso ripristinare Application Signals?

Quando Application Signals visualizza grafici o metriche vuoti, è necessario abilitare EMF per il gruppo di log /aws/application-signals/data per ripristinare la piena funzionalità. Per ulteriori informazioni, consulta PutAccountPolicy.