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

Configurazione di Application Signals

Questa sezione contiene informazioni sulla configurazione di CloudWatch Application Signals.

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 AWS Distro for OpenTelemetry (ADOT) SDK sono impostate come segue.

Per ulteriori informazioni sulla modifica della configurazione di campionamento, consulta:

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

Per informazioni sulle impostazioni di campionamento più avanzate, consulta OTEL_TRACES_SAMPLER.

Abilita la correlazione tra traccia e registro

È possibile abilitare la correlazione tra traccia e registro in Application Signals. Questo inserisce automaticamente trace IDs and span IDs nei registri delle applicazioni pertinenti. Quindi, quando si apre una pagina dei dettagli di traccia nella console Application Signals, le voci di registro pertinenti (se presenti) correlate alla traccia corrente vengono visualizzate automaticamente nella parte inferiore della pagina.

Ad esempio, supponete di notare un picco in un grafico della latenza. È possibile scegliere il punto sul grafico per caricare le informazioni di diagnostica relative a quel momento. Quindi scegli la traccia pertinente per ottenere maggiori informazioni. Quando visualizzi le informazioni di traccia, puoi scorrere verso il basso per visualizzare i log associati alla traccia. Questi registri potrebbero rivelare schemi o codici di errore associati ai problemi che causano il picco di latenza.

Per ottenere la correlazione dei log di traccia, Application Signals si affida a quanto segue:

Tutti questi strumenti sono forniti dalla community. OpenTelemetry Application Signals li utilizza per inserire contesti di traccia come trace ID e span ID nei log delle applicazioni. Per abilitare ciò, è necessario modificare manualmente la configurazione di registrazione per abilitare la strumentazione automatica.

A seconda dell'architettura su cui viene eseguita l'applicazione, potrebbe essere necessario impostare anche una variabile di ambiente per abilitare la correlazione dei log di traccia, oltre a seguire i passaggi descritti in questa sezione.

Dopo aver abilitato la correlazione dei log di traccia,

Esempi di configurazione della correlazione dei log di traccia

Questa sezione contiene esempi di impostazione della correlazione dei log di traccia in diversi ambienti.

Spring Boot per Java

Supponiamo di avere un'applicazione Spring Boot in una cartella chiamatacustom-app. La configurazione dell'applicazione è in genere un file YAML denominato custom-app/src/main/resources/application.yml che potrebbe assomigliare a questo:

spring:
  application:
    name: custom-app
  config:
    import: optional:configserver:${CONFIG_SERVER_URL:http://localhost:8888/}
    
...   

Per abilitare la correlazione dei log di traccia, aggiungete 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 pattern di traccia trace_id=%mdc{trace_id} span_id=%mdc{span_id} trace_flags=%mdc{trace_flags} %5p in Encoder. Ad esempio, la seguente configurazione precede il contesto di traccia prima del messaggio di registro.

<appender name="FILE" class="ch.qos.logback.core.FileAppender">
  <file>app.log</file>
  <append>true</append>
  <encoder> 
    <pattern>trace_id=%mdc{trace_id} span_id=%mdc{span_id} trace_flags=%mdc{trace_flags} %5p - %m%n</pattern> 
  </encoder>
</appender>

Per ulteriori informazioni sugli encoder in Logback, consulta Encoders nella documentazione di Logback.

Log4j2 per Java

Nella configurazione di registrazione (come log4j2.xml), inserisci il contesto di traccia in. trace_id=%mdc{trace_id} span_id=%mdc{span_id} trace_flags=%mdc{trace_flags} %5p PatternLayout Ad esempio, la configurazione seguente precede il contesto di traccia prima del messaggio di registro.

<Appenders>
  <File name="FILE" fileName="app.log">
    <PatternLayout pattern="trace_id=%mdc{trace_id} span_id=%mdc{span_id} trace_flags=%mdc{trace_flags} %5p - %m%n"/>
  </File>
</Appenders>

Per ulteriori informazioni sui layout dei pattern in Log4j2, vedere Pattern Layout nella documentazione di Log4j2.

Log4j per Java

Nella configurazione di registrazione (come log4j.xml), inserisci il contesto di traccia in. trace_id=%mdc{trace_id} span_id=%mdc{span_id} trace_flags=%mdc{trace_flags} %5p PatternLayout Ad esempio, la configurazione seguente precede il contesto di traccia prima del messaggio di registro.

<appender name="FILE" class="org.apache.log4j.FileAppender">;
  <param name="File" value="app.log"/>;
  <param name="Append" value="true"/>;
  <layout class="org.apache.log4j.PatternLayout">;
    <param name="ConversionPattern" value="trace_id=%mdc{trace_id} span_id=%mdc{span_id} trace_flags=%mdc{trace_flags} %5p - %m%n"/>;
  </layout>;
</appender>;

Per ulteriori informazioni sui layout dei pattern in Log4j, vedete Class Pattern Layout nella documentazione di Log4j.

Python

Imposta la variabile OTEL_PYTHON_LOG_CORRELATION di ambiente su durante l'esecuzione dell'applicazione. true Per maggiori informazioni, consulta Abilita l'iniezione del contesto di traccia nella documentazione di Python OpenTelemetry .

Node.js

Per ulteriori informazioni sull'abilitazione dell'iniezione di contesto di traccia in Node.js per le librerie di registrazione che la supportano, consulta la documentazione sull'utilizzo di NPM delle strumentazioni automatiche Pino, Winston o Bunyan per Node.js.

Abilita la correlazione tra metrica e log

Se pubblicate i log delle applicazioni in gruppi di log in CloudWatch Logs, potete abilitare la correlazione tra metriche e log delle applicazioni in Application Signals. Con la correlazione dei log metrici, la console di Application Signals visualizza automaticamente i gruppi di log pertinenti associati a una metrica.

Ad esempio, supponiamo di notare un picco in un grafico della latenza. È possibile 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 quei gruppi di log. A seconda delle informazioni contenute nei registri dell'applicazione, ciò 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 metrica e log dell'applicazione.

Gestisci le operazioni ad alta cardinalità

Application Signals include impostazioni nell' CloudWatch agente che puoi utilizzare per gestire la cardinalità delle tue operazioni e gestire 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 tempo supera la soglia predefinita di 500. È possibile ottimizzare il comportamento modificando le impostazioni di configurazione.

Determina se la limitazione metrica è attivata

Puoi utilizzare i seguenti metodi per scoprire se è in corso la limitazione metrica predefinita. In tal caso, dovresti prendere in considerazione l'ottimizzazione del controllo della cardinalità seguendo i passaggi nella sezione successiva.

Ottimizza il controllo della cardinalità

Per ottimizzare il controllo della cardinalità, puoi fare quanto segue:

Crea regole personalizzate per aggregare le operazioni

Le operazioni con elevata cardinalità possono a volte essere causate da valori univoci inappropriati estratti dal contesto. Ad esempio, l'invio di richieste HTTP/S che includono utente IDs o sessione IDs nel percorso può portare a centinaia di operazioni diverse. Per risolvere questi problemi, si consiglia di configurare l' CloudWatch agente con regole di personalizzazione per riscrivere queste operazioni.

Nei casi in cui si verifichi un'impennata nella generazione di numerose metriche diverse tramite RemoteOperation chiamate individuali, ad esempioPUT /api/customer/owners/123, e richieste similiPUT /api/customer/owners/456, si consiglia di consolidare queste operazioni in un'unica operazione. RemoteOperation Un approccio consiste nello standardizzare tutte le RemoteOperation chiamate che iniziano con un formato uniforme, PUT /api/customer/owners/ in particolare. PUT /api/customer/owners/{ownerId} Nell'esempio seguente viene descritto quanto segue. Per informazioni su altre regole di personalizzazione, consulta. Abilita CloudWatch Application Signals

{
   "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, potrebbero essere state aggregate metriche ad alta cardinalità e potrebbe non essere chiaro quali metriche specifiche siano incluse. AllOtherRemoteOperations L' CloudWatch agente è in grado di registrare le operazioni interrotte. Per identificare le operazioni interrotte, utilizzate la configurazione nell'esempio seguente per attivare la registrazione fino alla ricomparsa del problema. Quindi ispezionate i log degli CloudWatch agenti (accessibili tramite contenitore stdout o file di EC2 registro) e cercate 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
            }
          }
        }
      }
    }
  }
}

Crea la tua politica di limitazione delle metriche

Se la configurazione di limitazione delle metriche predefinita non riguarda la cardinalità del servizio, puoi personalizzare la configurazione del limitatore metrico. A tale scopo, aggiungi una limiter sezione sotto la logs/metrics_collected/application_signals sezione 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
        }
      }
    }
  }
}