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 CloudWatch Application Signals.
Argomenti
Prestazioni di avvio a freddo del livello Java di Application Signals
L'applicazione non si avvia dopo l'abilitazione di Application Signals
L'applicazione Python non si avvia dopo l'attivazione di Application Signals
Nessun dato di Application Signals per l'applicazione Python che utilizza un server WSGI
La mia applicazione Node.js non è strumentata o non genera telemetria Application Signals
Nessun dato applicativo nella dashboard di Application Signals
Le metriche di servizio o le metriche di dipendenza hanno valori sconosciuti
Come posso abilitare la registrazione per le applicazioni.NET?
Come posso risolvere i conflitti tra le versioni dell'assembly nelle applicazioni.NET?
Posso filtrare i log dei contenitori prima di esportarli in Logs? CloudWatch
Risoluzione TypeError quando si utilizza AWS Distro for OpenTelemetry (ADOT) Lambda Layer JavaScript
Aggiornamento alle versioni richieste degli agenti o del componente aggiuntivo Amazon EKS
Embedded Metric Format (EMF) disabilitato per Application Signals
Prestazioni di avvio a freddo del livello Java di Application Signals
L'aggiunta dell'Application Signals Layer alle funzioni Java Lambda aumenta la latenza di avvio (orario 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 è disattivata per impostazione predefinita 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 avviamenti a freddo più rapidi. 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, vedete Fast startup for Java agent.
Riduci i tempi di avvio a freddo con Provisioned Concurrency: AWS Lambda provisioned Concurrency prealloca un numero specifico 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 funzionale durante l'esecuzione e garantendo prestazioni più rapide e coerenti, in particolare per i carichi di lavoro sensibili alla latenza. Per ulteriori informazioni, vedere Configurazione della concorrenza fornita per una funzione.
Ottimizza le prestazioni di avvio con 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. Questa istantanea viene quindi riutilizzata per avviare nuove istanze, riducendo significativamente i tempi di avvio a freddo saltando il processo di inizializzazione durante l'invocazione della funzione. Per informazioni, consulta Migliorare le 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 strumentazione.
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'agente AWS Distro for Java OpenTelemetery o Python e CloudWatch le immagini degli agenti, potrebbe trattarsi di un problema di rete.
Per mitigare il problema, rimuovete l'annotazione instrumentation.opentelemetry.io/inject-java: "true"
o instrumentation.opentelemetry.io/inject-python: "true"
dal manifesto di distribuzione dell'applicazione e ridistribuite l'applicazione. Quindi controlla se l'applicazione funziona.
Problemi noti
È noto che la raccolta di metriche di runtime nella versione Java SDK v1.32.5 non funziona con le applicazioni che utilizzano Wildfly. JBoss Questo problema si estende al componente aggiuntivo Amazon CloudWatch Observability EKS, interessando le versioni successive2.3.0-eksbuild.1
. 2.5.0-eksbuild.1
In caso di impatto, esegui il downgrade della versione o disabilita la raccolta di parametri di runtime aggiungendo la variabile di ambiente all'applicazione. OTEL_AWS_APPLICATION_SIGNALS_RUNTIME_ENABLED=false
L'applicazione Python non si avvia dopo l'attivazione di Application Signals
È un problema noto nella OpenTelemetry strumentazione automatica che una variabile di PYTHONPATH
ambiente mancante a volte 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, vedere L'impostazione della strumentazione automatica di Python di PYTHONPATH non è conforme al comportamento di risoluzione dei moduli di Python, interrompendo le applicazioni Django
Usa il
--noreload
flag per impedire il ricaricamento automatico.Imposta la variabile di
DJANGO_SETTINGS_MODULE
ambiente sulla posizione del file dell'settings.py
applicazione Django. Ciò garantisce che OpenTelemetry possa accedere e integrarsi correttamente con le impostazioni di Django.
Nessun dato di Application Signals per l'applicazione Python che utilizza un server WSGI
Se si utilizza un server WSGI come Gunicorn o uWSGI, è necessario apportare ulteriori modifiche per far funzionare la strumentazione automatica di ADOT Python.
Nota
Assicurati di utilizzare la versione più recente di ADOT Python e il componente aggiuntivo CloudWatch Amazon Observability EKS prima di procedere.
Passaggi aggiuntivi per abilitare Application Signals con un server WSGI
Importa la strumentazione automatica nei processi di lavoro biforcati.
Per Gunicorn, usa il gancio:
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
Abilita la configurazione per la strumentazione automatica di ADOT Python per saltare il processo principale e rimandarlo ai lavoratori impostando la variabile di ambiente su.
OTEL_AWS_PYTHON_DEFER_TO_WORKERS_ENABLED
true
La mia applicazione Node.js non è strumentata o non genera telemetria Application Signals
Per abilitare Application Signals for Node.js, è necessario assicurarsi che l'applicazione Node.js utilizzi il formato del modulo CommonJS (CJS). Attualmente, AWS Distro for OpenTelemetry Node.js non supporta il formato del modulo ESM, poiché OpenTelemetry JavaScript il supporto di ESM è sperimentale ed è in corso di elaborazione.
Nessun dato applicativo nella dashboard 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 controlla lo stato dei pod degli CloudWatch agenti e assicurati che siano tutti a
Running
posto.kubectl -n amazon-cloudwatch get pods.
Aggiungi quanto segue al file di configurazione dell' CloudWatch agente per abilitare i log di debug, quindi riavvia l'agente.
"agent": { "region": "${REGION}", "debug": true },
Quindi verifica la presenza di errori nei pod dell'agente. CloudWatch
Verifica la presenza di problemi di configurazione con l' CloudWatch agente. Verificate che quanto segue sia ancora presente nel file di configurazione dell' CloudWatch agente e che l'agente sia stato riavviato da quando è stato aggiunto.
"agent": { "region": "${REGION}", "debug": true },
Quindi controlla i registri di OpenTelemetry debug per verificare la presenza di 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 comandokubectl describe pod
.Per abilitare la registrazione di debug in OpenTelemetry Python, imposta la variabile di ambiente su
debug
e ridistribuisci l'OTEL_PYTHON_LOG_LEVEL
applicazione.Verifica la presenza di autorizzazioni errate o insufficienti per l'esportazione dei dati dall'agente. CloudWatch Se vedi
Access Denied
dei messaggi nei registri degli CloudWatch agenti, questo potrebbe essere il problema. È possibile che le autorizzazioni applicate durante l'installazione dell' CloudWatch agente siano state successivamente modificate o revocate.Verifica la presenza di un problema relativo a AWS Distro for OpenTelemetry (ADOT) durante la generazione di dati di telemetria.
Assicurati che le annotazioni sulla strumentazione
instrumentation.opentelemetry.io/inject-java
esidecar.opentelemetry.io/inject-java
vengano applicate alla distribuzione dell'applicazione e che il valore siatrue
. 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 diReady
èTrue
. Se il containerinit
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 conERROR io.telemetry
.È possibile che l'esportatore stia eliminando i dati. metric/span Per scoprirlo, controlla il log dell'applicazione per i messaggi che includono
Failed to export...
L' CloudWatch agente potrebbe subire delle limitazioni durante l'invio di metriche o intervalli ad Application Signals. Verifica la presenza di messaggi che indicano una limitazione nei registri degli agenti. CloudWatch
Assicurati di aver abilitato la configurazione del servizio. È necessario eseguire questa operazione solo una volta nella propria regione.
Per confermare ciò, nella CloudWatch console scegli Application Signals, Services. Se il passaggio 1 non è contrassegnato come Completo, scegli Inizia a scoprire i tuoi servizi. I dati dovrebbero iniziare ad arrivare entro cinque minuti.
Le metriche di servizio o le metriche di dipendenza hanno valori sconosciuti
Se vedi UnknownService, UnknownOperationUnknownRemoteService, o UnknownRemoteOperationper un nome o un'operazione di dipendenza nei dashboard di Application Signals, controlla se la presenza di punti dati per il servizio remoto sconosciuto e il funzionamento remoto sconosciuto coincidono con le relative distribuzioni.
UnknownServicesignifica che il nome di un'applicazione strumentata è sconosciuto. Se la variabile di
OTEL_SERVICE_NAME
ambiente non è definita eservice.name
non è specificata inOTEL_RESOURCE_ATTRIBUTES
, il nome del servizio è impostato su.UnknownService
Per risolvere questo problema, specifica il nome del servizio inOTEL_SERVICE_NAME
oOTEL_RESOURCE_ATTRIBUTES
.UnknownOperationsignifica che il nome di un'operazione richiamata è sconosciuto. Ciò si verifica quando Application Signals non è in grado di scoprire il nome di un'operazione che richiama 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 metrico di.RemoteService
Per ulteriori informazioni sulle personalizzazioni nell' CloudWatch agente, consulta. Abilita CloudWatch Application SignalsUnknownRemoteOperationsignifica 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 metrico di.RemoteOperation
Per ulteriori informazioni sulle personalizzazioni nell' CloudWatch agente, consulta. Abilita CloudWatch Application Signals
Gestione di un ConfigurationConflict durante la gestione del componente aggiuntivo Amazon CloudWatch Observability EKS
Quando installi o aggiorni il componente aggiuntivo Amazon CloudWatch Observability EKS, se noti un errore causato da un Health Issue
di tipo ConfigurationConflict
con una descrizione che inizia conConflicts found when trying to apply. Will not continue due to resolve conflicts mode
, è probabile che l' CloudWatch agente e i relativi componenti associati, come il ServiceAccount, il ClusterRole e il, siano 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 fallisce 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 di CloudWatch agente esistente che avevi precedentemente installato sul cluster e quindi di installare il componente aggiuntivo EKS. Assicurati di eseguire il backup di tutte le personalizzazioni che potresti aver apportato alla configurazione originale dell' CloudWatch agente, ad esempio una configurazione personalizzata dell'agente, e di fornirle al componente aggiuntivo Amazon CloudWatch Observability EKS alla prossima installazione o aggiornamento. Se in precedenza avevi installato l' CloudWatch agente per l'onboarding su Container Insights, consulta per ulteriori informazioni. Eliminazione dell' CloudWatch agente e di Fluent Bit for Container Insights
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 utilizzi il AWS CLI, puoi fornire il comando --resolve-conflicts OVERWRITE
al tuo comando 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 Gestisci operazioni ad alta cardinalità per informazioni sulla configurazione dell' CloudWatch agente con regole personalizzate per ridurre la cardinalità.
Per informazioni sulla personalizzazione delle regole di campionamento delle tracce, vedere Configurare le regole di campionamento nella documentazione di X-Ray.
Cosa significa? InternalOperation
An InternalOperation
è un'operazione che viene attivata dall'applicazione internamente anziché da una chiamata esterna. Vedere InternalOperation
è un comportamento sano.
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 osservare un'operazioneloadDatafromDB
come servizio, la vedrete classificata come.InternalOperation
Esecuzione asincrona in background: l'applicazione si iscrive a una coda di eventi ed elabora i dati in streaming di conseguenza ogni volta che viene effettuato un aggiornamento. Ogni operazione attivata verrà eseguita
InternalOperation
come operazione di servizio.Recupero delle informazioni sull'host da un registro dei servizi: l'applicazione comunica con un registro dei servizi per l'individuazione del servizio. 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
OTEL_LOG_LEVEL
OTEL_DOTNET_AUTO_LOG_DIRECTORY
COREHOST_TRACE
COREHOST_TRACEFILE
Come posso risolvere i conflitti tra le versioni dell'assembly nelle applicazioni.NET?
Se viene visualizzato il seguente errore, consulta Conflitti tra versioni di Assembly
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 disabilitare FluentBit?
Puoi disabilitarlo 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 registri dei contenitori non è ancora supportato.
Risoluzione TypeError quando si utilizza AWS Distro for OpenTelemetry (ADOT) Lambda Layer JavaScript
La tua funzione Lambda potrebbe fallire con questo errore: TypeError - "Cannot redefine property: handler"
quando:
Usa il layer ADOT JavaScript Lambda
Usa per compilare
esbuild
TypeScriptEsporta il tuo gestore con la parola chiave
export
L'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 il gestore immutabile, impedendo queste modifiche.
Esporta la tua funzione di gestione utilizzando invece della parola chiave: module.exports
export
// Before export const handler = (event) => { // Handler Code }
// After const handler = async (event) => { // Handler Code } module.exports = { handler }
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' CloudWatch agente e dell'agente AWS Distro per la strumentazione automatica. OpenTelemetry
Per il componente aggiuntivo Amazon CloudWatch Observability EKS, le versioni precedenti a
v1.7.0-eksbuild.1
non saranno supportate.Per l' CloudWatch agente, le versioni precedenti a
1.300040.0
non saranno supportate.Per l'agente AWS Distro for OpenTelemetry autostrumentation:
Per Java, le versioni precedenti a non
1.32.2
sono supportate.Per Python, le versioni precedenti a
0.2.0
non sono supportate.-
Per .NET, le versioni precedenti a
1.3.2
non sono supportate. -
Per Node.js, le versioni precedenti a
0.3.0
non sono supportate.
Importante
Le versioni più recenti degli agenti includono aggiornamenti allo schema metrico 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 senza interruzioni alla nuova funzionalità, procedi come segue:
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' CloudWatch agente che l'agente di AWS OpenTelemetry strumentazione automatica alle versioni più recenti.
Le istruzioni nelle sezioni seguenti possono aiutarti ad eseguire l'aggiornamento a una versione supportata.
Indice
Aggiorna il componente aggiuntivo Amazon CloudWatch Observability EKS
Per il componente aggiuntivo Amazon CloudWatch Observability EKS, puoi utilizzare AWS Management Console o il. AWS CLI
Utilizzo della console
Per aggiornare il componente aggiuntivo utilizzando la console
Apri la console Amazon EKS a https://console.aws.amazon.com/eks/home#/clusters
. Scegli il nome del cluster Amazon EKS da aggiornare.
Scegli la scheda Componenti aggiuntivi, quindi scegli Amazon CloudWatch Observability.
Scegli Modifica, seleziona la versione a cui desideri eseguire l'aggiornamento, quindi scegli Salva modifiche.
Assicurati di scegliere
v1.7.0-eksbuild.1
o più tardi.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 il AWS CLI
Immettete il seguente comando per trovare la versione più recente.
aws eks describe-addon-versions \ --addon-name amazon-cloudwatch-observability
Immettete il seguente comando per aggiornare il componente aggiuntivo. Sostituiscilo
$VERSION
con una versione precedentev1.7.0-eksbuild.1
o successiva. Sostituisci$AWS_REGION
e$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 utilizzi una configurazione personalizzata per il componente aggiuntivo, puoi trovare un esempio della configurazione da utilizzare
$JSON_CONFIG
inAbilita CloudWatch Application Signals.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
Aggiorna l' CloudWatch agente e l'agente ADOT
Se i tuoi servizi funzionano su architetture diverse da Amazon EKS, dovrai aggiornare sia l'agente che l' CloudWatch agente di strumentazione automatica ADOT per utilizzare le funzionalità di Application Signals più recenti.
Aggiornamento su Amazon ECS
Per aggiornare i tuoi agenti per i servizi in esecuzione su Amazon ECS
Crea una nuova revisione della definizione delle attività. Per ulteriori informazioni, vedere Aggiornamento della definizione di un'attività tramite la console.
Sostituisci il
ecs-cwagent
contenitore con l'ultimo tag$IMAGE
di immagine di cloudwatch-agentsu Amazon ECR. Se esegui l'upgrade a una versione fissa, assicurati di utilizzare una versione uguale o successiva a.
1.300040.0
Sostituisci il tag
$IMAGE
dell'immagine delinit
contenitore con l'ultimo tag di immagine dalle seguenti posizioni:Per Java, usa adot-autoinstrumentation-javaaws-observability/
. Se esegui l'aggiornamento a una versione fissa, assicurati di utilizzare una versione uguale o successiva a.
1.32.2
Per Python, usa aws-observability/. adot-autoinstrumentation-python
Se esegui l'aggiornamento a una versione fissa, assicurati di utilizzare una versione uguale o successiva a.
0.2.0
-
Per .NET, usa adot-autoinstrumentation-dotnetaws-observability/
. Se esegui l'aggiornamento a una versione fissa, assicurati di utilizzare una versione uguale o successiva a.
1.3.2
-
Per Node.js, usa adot-autoinstrumentation-nodeaws-observability/
. Se esegui l'aggiornamento a una versione fissa, assicurati di utilizzare una versione uguale o successiva a.
0.3.0
Aggiorna le variabili di ambiente di Application Signals nel contenitore dell'app seguendo le istruzioni riportate all'indirizzoFase 4: Strumentate la vostra candidatura con l' CloudWatch agente.
Implementa il tuo servizio con la nuova definizione di attività.
Aggiornamento su Amazon EC2 o altre architetture
Per aggiornare i tuoi agenti per i servizi eseguiti su Amazon EC2 o altre architetture
Assicurati di selezionare la versione
1.300040.0
o una versione successiva della versione dell' CloudWatch agente.Scarica l'ultima versione dell'agente AWS Distro for OpenTelemetry Auto Instrumentation da una delle seguenti posizioni:
Per Java, usa. aws-otel-java-instrumentation
Se esegui l'aggiornamento a una versione fissa, assicurati di scegliere
1.32.2
una versione successiva.Per Python, usa. aws-otel-python-instrumentation
Se esegui l'aggiornamento a una versione fissa, assicurati di scegliere
0.2.0
una versione successiva.-
Per .NET, usa aws-otel-dotnet-instrumentation
. Se esegui l'aggiornamento a una versione fissa, assicurati di scegliere
1.3.2
una versione successiva. -
Per Node.js, usa aws-otel-js-instrumentation
. Se esegui l'aggiornamento a una versione fissa, assicurati di scegliere
0.3.0
una versione successiva.
Applica le variabili di ambiente aggiornate di Application Signals all'applicazione, quindi avvia l'applicazione. Per ulteriori informazioni, consulta Fase 3: strumentazione e avvio dell'applicazione.
Embedded Metric Format (EMF) disabilitato per Application Signals
La disabilitazione di EMF per il gruppo di /aws/application-signals/data
log 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 /aws/application-signals/data
log per ripristinare la piena funzionalità. Per ulteriori informazioni, consulta PutAccountPolicy.