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à. # (Facoltativo) Configurazione di Application Signals Questa sezione contiene informazioni sulla configurazione di CloudWatch Application Signals. **Topics** + [Velocità di campionamento della traccia](Application-Signals-SampleRate.md) + [Abilitazione della correlazione tra traccia e log](Application-Signals-TraceLogCorrelation.md) + [Abilitazione della correlazione tra metrica e log](Application-Signals-MetricLogCorrelation.md) + [Gestione di operazioni ad alta cardinalità](Application-Signals-Cardinality.md) # Velocità di campionamento della traccia Per impostazione predefinita, quando si abilita Application Signals, il campionamento centralizzato X-Ray viene abilitato utilizzando le impostazioni di velocità di campionamento predefinite `reservoir=1/s` e `fixed_rate=5%`. Le variabili di ambiente per l'agente SDK di AWS Distro per OpenTelemetry (ADOT) sono impostate come segue. | Variabile di ambiente | Valore | Nota | | --- | --- | --- | | `OTEL_TRACES_SAMPLER` | `xray` | | | `OTEL_TRACES_SAMPLER_ARG` | `endpoint=http://cloudwatch-agent.amazon-cloudwatch:2000` | Endpoint dell'agente CloudWatch | Per ulteriori informazioni sulla modifica della configurazione di campionamento, consulta: + Per modificare il campionamento X-Ray, consulta [ Configure sampling rules](https://docs.aws.amazon.com/xray/latest/devguide/aws-xray-interface-console.html#xray-console) + Per modificare il campionamento ADOT, consulta [Configurazione di OpenTelemetry Collector per il campionamento remoto X-Ray](https://aws-otel.github.io/docs/getting-started/remote-sampling) Se desideri disabilitare il campionamento centralizzato X-Ray e utilizzare invece il campionamento locale, imposta i seguenti valori per l'agente Java SDK ADOT come indicato di seguito. L'esempio seguente imposta la velocità di campionamento al 5%. | Variabile di ambiente | Valore | | --- | --- | | `OTEL_TRACES_SAMPLER` | `parentbased_traceidratio` | | `OTEL_TRACES_SAMPLER_ARG` | `0.05` | Per informazioni sulle impostazioni di campionamento più avanzate, consulta [ OTEL\$1TRACES\$1SAMPLER](https://opentelemetry.io/docs/concepts/sdk-configuration/general-sdk-configuration/#otel_traces_sampler). # Abilitazione della correlazione tra traccia e log In Application Signals è possibile abilitare la *correlazione tra traccia e log*. Questo inserisce automaticamente gli ID di traccia e gli ID di intervallo nei log delle applicazioni pertinenti. Dopodiché, quando si apre una pagina dei dettagli di traccia nella console Application Signals, le voci di log pertinenti (se presenti) correlate alla traccia corrente vengono visualizzate automaticamente nella parte inferiore della pagina. Ad esempio, se noti un picco in un grafico di latenza, puoi selezionare il punto corrispondente sul grafico per caricare le informazioni di diagnostica relative a quel momento. Quindi puoi scegliere la traccia pertinente per ottenere maggiori informazioni. Quando visualizzi le informazioni relative alla traccia, puoi scorrere verso il basso per vedere i log associati alla traccia. Questi log potrebbero rivelare schemi o codici di errore associati ai problemi che causano il picco di latenza. Per ottenere la correlazione tra traccia e log, Application Signals si basa su quanto segue: + [ Instrumentazione automatica Logger MDC](https://github.com/open-telemetry/opentelemetry-java-instrumentation/blob/main/docs/logger-mdc-instrumentation.md) per Java. + [ Instrumentazione di registrazione OpenTelemetry](https://opentelemetry-python-contrib.readthedocs.io/en/latest/instrumentation/logging/logging.html) per Python. + Le instrumentazioni automatiche [ Pino](https://www.npmjs.com/package/@opentelemetry/instrumentation-pino), [ Winston](https://www.npmjs.com/package/@opentelemetry/instrumentation-winston) o [ Bunyan](https://www.npmjs.com/package/@opentelemetry/instrumentation-bunyan) per Node.js. Tutte queste instrumentazioni sono fornite dalla community OpenTelemetry. Application Signals le utilizza per inserire contesti di traccia come ID di traccia e ID di intervallo nei log delle applicazioni. Per abilitare la correlazione, è necessario modificare manualmente la configurazione di registrazione per abilitare l'instrumentazione automatica. A seconda dell'architettura su cui viene eseguita l'applicazione, potrebbe essere necessario impostare anche una variabile di ambiente per abilitare la correlazione tra traccia e log, oltre a seguire i passaggi descritti in questa sezione. + Su Amazon EKS, non sono necessari ulteriori passaggi. + Su Amazon ECS, non sono necessari ulteriori passaggi. + Su Amazon EC2, consulta il passaggio 4 della procedura riportata in [Passaggio 3: instrumentazione e avvio dell'applicazione](CloudWatch-Application-Signals-Enable-EC2Main.md#CloudWatch-Application-Signals-Enable-Other-instrument). Dopo aver abilitato la correlazione tra traccia e log, ## Esempi di configurazione della correlazione tra traccia e log Questa sezione contiene esempi di impostazione della correlazione tra traccia e log in diversi ambienti. **Spring Boot per Java** Supponiamo di avere un'applicazione Spring Boot in una cartella chiamata `custom-app`. La configurazione dell'applicazione è in genere un file YAML denominato `custom-app/src/main/resources/application.yml` che potrebbe somigliare a questo: ``` spring: application: name: custom-app config: import: optional:configserver:${CONFIG_SERVER_URL:http://localhost:8888/} ... ``` Per abilitare la correlazione tra traccia e log, aggiungi la seguente configurazione di registrazione. ``` spring: application: name: custom-app config: import: optional:configserver:${CONFIG_SERVER_URL:http://localhost:8888/} ... logging: pattern: level: trace_id=%mdc{trace_id} span_id=%mdc{span_id} trace_flags=%mdc{trace_flags} %5p ``` **Logback per Java** Nella configurazione di registrazione (come logback.xml), inserisci il contesto di traccia `trace_id=%mdc{trace_id} span_id=%mdc{span_id} trace_flags=%mdc{trace_flags} %5p` nel `pattern` dell'Encoder. Ad esempio, la seguente configurazione antepone il contesto di traccia al messaggio di log. ``` app.log true trace_id=%mdc{trace_id} span_id=%mdc{span_id} trace_flags=%mdc{trace_flags} %5p - %m%n ``` Per ulteriori informazioni sugli encoder in Logback, consulta [ Encoders](https://logback.qos.ch/manual/encoders.html) nella documentazione di Logback. **Log4j2 per Java** Nella configurazione di registrazione (come log4j2.xml), inserisci il contesto di traccia `trace_id=%mdc{trace_id} span_id=%mdc{span_id} trace_flags=%mdc{trace_flags} %5p` nel `PatternLayout`. Ad esempio, la seguente configurazione antepone il contesto di traccia al messaggio di log. ``` ``` Per ulteriori informazioni sui layout degli schemi in Log4j2, consulta [ Pattern Layout](https://logging.apache.org/log4j/2.x/manual/layouts.html#Pattern_Layout) nella documentazione di Log4j2. **Log4j per Java ** Nella configurazione di registrazione (come log4j.xml), inserisci il contesto di traccia `trace_id=%mdc{trace_id} span_id=%mdc{span_id} trace_flags=%mdc{trace_flags} %5p` nel `PatternLayout`. Ad esempio, la seguente configurazione antepone il contesto di traccia al messaggio di log. ``` ; ; ; ; ; ; ; ``` Per ulteriori informazioni sui layout degli schemi in Log4j, consulta [ Pattern Layout](https://logging.apache.org/log4j/1.x/apidocs/org/apache/log4j/PatternLayout.html) nella documentazione di Log4j. **Python** Imposta la variabile di ambiente `OTEL_PYTHON_LOG_CORRELATION` su `true` durante l'esecuzione dell'applicazione. Per ulteriori informazioni, consulta [ Enable trace context injection](https://opentelemetry-python-contrib.readthedocs.io/en/latest/instrumentation/logging/logging.html#enable-trace-context-injection) nella documentazione di OpenTelemetry relativa a Python. **Node.js** Per ulteriori informazioni sull'abilitazione dell'inserimento del contesto di traccia in Node.js per le librerie di registrazione che lo supportano, consulta la documentazione di NPM sull'utilizzo delle instrumentazioni automatiche [ Pino](https://www.npmjs.com/package/@opentelemetry/instrumentation-pino), [ Winston](https://www.npmjs.com/package/@opentelemetry/instrumentation-winston) o [ Bunyan](https://www.npmjs.com/package/@opentelemetry/instrumentation-bunyan) per Node.js. # Abilitazione della correlazione tra metrica e log Se pubblichi i log delle applicazioni in gruppi di log in CloudWatch Logs, puoi *abilitare la correlazione tra metrica e log dell'applicazione* in Application Signals. Con la correlazione tra metrica e log, la console di Application Signals visualizza automaticamente i gruppi di log pertinenti associati a una metrica. Ad esempio, se noti un picco in un grafico di latenza, puoi scegliere un punto del grafico per caricare le informazioni di diagnostica relative a quel momento. Le informazioni di diagnostica mostreranno i gruppi di log delle applicazioni pertinenti associati al servizio e alla metrica correnti. Quindi puoi scegliere un pulsante per eseguire una query di CloudWatch Logs Insights su tali gruppi di log. A seconda delle informazioni contenute nei log delle applicazioni, questo potrebbe aiutarti a indagare sulla causa del picco di latenza. A seconda dell'architettura su cui viene eseguita l'applicazione, potrebbe essere necessario impostare anche una variabile di ambiente per abilitare la correlazione tra traccia e log dell'applicazione. + Su Amazon EKS, non sono necessari ulteriori passaggi. + Su Amazon ECS, non sono necessari ulteriori passaggi. + Su Amazon EC2, consulta il passaggio 4 della procedura riportata in [Passaggio 3: instrumentazione e avvio dell'applicazione](CloudWatch-Application-Signals-Enable-EC2Main.md#CloudWatch-Application-Signals-Enable-Other-instrument). # Gestione di operazioni ad alta cardinalità Application Signals include impostazioni nell'agente CloudWatch che puoi utilizzare per gestire la cardinalità delle operazioni e l'esportazione delle metriche per ottimizzare i costi. Per impostazione predefinita, la funzione di limitazione delle metriche diventa attiva quando il numero di operazioni distinte per un servizio nel corso del tempo supera la soglia predefinita di 500. È possibile ottimizzare il comportamento modificando le impostazioni di configurazione. ## Determinazione dell'attivazione della limitazione delle metriche Puoi utilizzare i seguenti metodi per verificare se è in corso la limitazione predefinita delle metriche. In tal caso, dovresti valutare l'ottimizzazione del controllo della cardinalità seguendo i passaggi indicati nella sezione successiva. + Nella console CloudWatch, scegli **Application Signals** e poi **Servizi**. Se vedi un'**Operazione** denominata **AllOtherOperations** o una **RemoteOperation** denominata **AllOtherRemoteOperations**, allora è in corso la limitazione delle metriche. + Se sono presenti metriche raccolte da Application Signals che hanno il valore `AllOtherOperations` per la dimensione `Operation`, allora è in corso la limitazione delle metriche. + Se sono presenti metriche raccolte da Application Signals che hanno il valore `AllOtherRemoteOperations` per la dimensione `RemoteOperation`, allora è in corso la limitazione delle metriche. ### Ottimizzazione del controllo della cardinalità Per ottimizzare il controllo della cardinalità, puoi eseguire le seguenti operazioni: + Creare regole personalizzate per aggregare le operazioni. + Configurare la policy di limitazione delle metriche. #### Creazione di regole personalizzate per aggregare le operazioni A volte, le operazioni con elevata cardinalità possono essere causate da valori univoci inappropriati estratti dal contesto. Ad esempio, l'invio di richieste HTTP/S che includono ID utente o ID di sessione nel percorso può generare centinaia di operazioni diverse. Per risolvere questi problemi, si consiglia di configurare l'agente CloudWatch con regole di personalizzazione per riscrivere tali operazioni. Nei casi in cui si verifichi un'impennata nella generazione di numerose metriche diverse tramite chiamate `RemoteOperation` individuali, ad esempio `PUT /api/customer/owners/123`, `PUT /api/customer/owners/456` e richieste simili, consigliamo di consolidare queste operazioni in un'unica `RemoteOperation`. Un approccio consiste nello standardizzare tutte le chiamate `RemoteOperation` che iniziano con `PUT /api/customer/owners/` a un formato uniforme, nello specifico `PUT /api/customer/owners/{ownerId}`. Nell'esempio seguente viene descritto quanto segue. Per informazioni su altre regole di personalizzazione, consulta [Abilita CloudWatch Application Signals](CloudWatch-Agent-Application_Signals.md). ``` { "logs":{ "metrics_collected":{ "application_signals":{ "rules":[ { "selectors":[ { "dimension":"RemoteOperation", "match":"PUT /api/customer/owners/*" } ], "replacements":[ { "target_dimension":"RemoteOperation", "value":"PUT /api/customer/owners/{ownerId}" } ], "action":"replace" } ] } } } } ``` In altri casi, metriche ad alta cardinalità potrebbero essere state aggregate in `AllOtherRemoteOperations` e potrebbe non essere chiaro quali metriche specifiche siano incluse. L'agente CloudWatch è in grado di registrare le operazioni interrotte. Per identificare le operazioni interrotte, utilizza la configurazione nell'esempio seguente per attivare la registrazione fino alla ricomparsa del problema. Quindi ispeziona i log degli agenti CloudWatch (accessibili tramite container `stdout` o file di log EC2) e cerca la parola chiave `drop metric data`. ``` { "agent": { "config": { "agent": { "debug": true }, "traces": { "traces_collected": { "application_signals": { } } }, "logs": { "metrics_collected": { "application_signals": { "limiter": { "log_dropped_metrics": true } } } } } } } ``` #### Creazione di una policy di limitazione delle metriche Se la configurazione di limitazione delle metriche predefinita non riguarda la cardinalità del servizio, puoi personalizzare la configurazione del limitatore di metriche. Per configurarlo, aggiungi una sezione `limiter` in quella `logs/metrics_collected/application_signals` del file di configurazione dell'agente CloudWatch. L'esempio seguente riduce la soglia di limitazione delle metriche da 500 metriche distinte a 100. ``` { "logs": { "metrics_collected": { "application_signals": { "limiter": { "drop_threshold": 100 } } } } } ```