Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Konfigurieren von Application Signals

Dieser Abschnitt enthält Informationen zur Konfiguration von CloudWatch Application Signals.

Trace-Sampling-Rate

Wenn Sie Application Signals X-Ray aktivieren, ist das zentrale Sampling standardmäßig mit den Standardeinstellungen für die Sampling-Rate von reservoir=1/s und fixed_rate=5% aktiviert. Die Umgebungsvariablen für den SDK Agenten AWS Distro for OpenTelemetry (ADOT) sind wie folgt festgelegt.

Informationen zum Ändern der Sampling-Konfiguration finden Sie unter:

Wenn Sie das zentralisierte X-Ray Sampling deaktivieren und stattdessen das lokale Sampling verwenden möchten, legen Sie die folgenden Werte für den ADOT SDK Java-Agenten wie folgt fest. Im folgenden Beispiel wird die Sampling-Rate auf 5 % festgelegt.

Informationen zu erweiterten Sampling-Einstellungen finden Sie unter OTEL_ TRACES _ SAMPLER.

Aktivieren Sie die Korrelation zwischen Trace und Protokoll

Sie können die Ablaufverfolgung zur Protokollierung der Korrelation in Application Signals aktivieren. Dadurch werden Trace IDs und Span automatisch IDs in die entsprechenden Anwendungsprotokolle eingefügt. Wenn Sie dann in der Application Signals Console eine Trace-Detailseite öffnen, werden die entsprechenden Protokolleinträge (falls vorhanden), die mit dem aktuellen Trace korrelieren, automatisch unten auf der Seite angezeigt.

Nehmen wir zum Beispiel an, Sie bemerken eine Spitze in einem Latenzdiagramm. Sie können den Punkt im Diagramm auswählen, an dem die Diagnoseinformationen für diesen Zeitpunkt geladen werden sollen. Anschließend wählen Sie den entsprechenden Trace aus, um weitere Informationen zu erhalten. Wenn Sie sich die Ablaufverfolgungsinformationen ansehen, können Sie nach unten scrollen, um die mit der Ablaufverfolgung verknüpften Protokolle zu sehen. Diese Protokolle können Muster oder Fehlercodes aufdecken, die mit den Problemen zusammenhängen, die die Latenzspitze verursacht haben.

Um eine Korrelation der Ablaufverfolgungsprotokolle zu erreichen, stützt sich Application Signals auf Folgendes:

All diese Instrumente werden von der Community bereitgestellt. OpenTelemetry Application Signals verwendet sie, um Trace-Kontexte wie Trace-ID und Span-ID in Anwendungsprotokolle einzufügen. Um dies zu aktivieren, müssen Sie Ihre Protokollierungskonfiguration manuell ändern, um die automatische Instrumentierung zu aktivieren.

Abhängig von der Architektur, auf der Ihre Anwendung ausgeführt wird, müssen Sie möglicherweise zusätzlich zu den Schritten in diesem Abschnitt auch eine Umgebungsvariable festlegen, um die Korrelation der Ablaufverfolgungsprotokolle zu aktivieren.

Nachdem Sie die Korrelation der Ablaufverfolgungsprotokolle aktiviert haben,

Beispiele zur Einrichtung der Korrelation von Ablaufverfolgungsprotokollen

Dieser Abschnitt enthält Beispiele für die Einrichtung der Korrelation von Ablaufverfolgungsprotokollen in verschiedenen Umgebungen.

Spring Boot für Java

Angenommen, Sie haben eine Spring Boot-Anwendung in einem Ordner namenscustom-app. Die Anwendungskonfiguration ist normalerweise eine YAML Datei mit dem Namencustom-app/src/main/resources/application.yml, die wie folgt aussehen könnte:

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

Um die Korrelation von Ablaufverfolgungsprotokollen zu aktivieren, fügen Sie die folgende Protokollierungskonfiguration hinzu.

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 für Java

Fügen Sie in der Logging-Konfiguration (z. B. logback.xml) den Trace-Kontext trace_id=%mdc{trace_id} span_id=%mdc{span_id} trace_flags=%mdc{trace_flags} %5p in pattern of Encoder ein. In der folgenden Konfiguration wird beispielsweise der Trace-Kontext der Protokollnachricht vorangestellt.

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

Weitere Informationen zu Encodern in Logback finden Sie unter Encoders in der Logback-Dokumentation.

Log4j2 für Java

Fügen Sie in der Logging-Konfiguration (z. B. log4j2.xml) den Trace-Kontext in ein. trace_id=%mdc{trace_id} span_id=%mdc{span_id} trace_flags=%mdc{trace_flags} %5p PatternLayout In der folgenden Konfiguration wird beispielsweise der Trace-Kontext der Protokollnachricht vorangestellt.

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

Weitere Informationen zu Musterlayouts in Log4j2 finden Sie unter Pattern Layout in der Log4j2-Dokumentation.

Log4j für Java

Fügen Sie in der Logging-Konfiguration (z. B. log4j.xml) den Trace-Kontext trace_id=%mdc{trace_id} span_id=%mdc{span_id} trace_flags=%mdc{trace_flags} %5p in ein. PatternLayout In der folgenden Konfiguration wird beispielsweise der Trace-Kontext der Protokollnachricht vorangestellt.

<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>;

Weitere Informationen zu Muster-Layouts in Log4j finden Sie unter Class Pattern Layout in der Log4j-Dokumentation.

Python

Stellen Sie die Umgebungsvariable auf einOTEL_PYTHON_LOG_CORRELATION, true während Ihre Anwendung ausgeführt wird. Weitere Informationen finden Sie unter Trace-Context-Injection aktivieren in der OpenTelemetry Python-Dokumentation.

Node.js

Weitere Informationen zur Aktivierung der Trace-Kontext-Injection in Node.js für die Logging-Bibliotheken, die dies unterstützen, finden Sie in den NPM Verwendungsdokumentationen der automatischen Instrumentationen Pino, Winston oder Bunyan für Node.js.

Korrelation zwischen Metrik und Protokollierung aktivieren

Wenn Sie CloudWatch Anwendungsprotokolle in Protokollgruppen unter Logs veröffentlichen, können Sie die Korrelation zwischen Metrik und Anwendungsprotokoll in Application Signals aktivieren. Bei der Korrelation von Metrik-Logs zeigt die Application Signals-Konsole automatisch die relevanten Protokollgruppen an, die einer Metrik zugeordnet sind.

Nehmen wir zum Beispiel an, Sie bemerken einen Anstieg in einem Latenzdiagramm. Sie können einen Punkt im Diagramm auswählen, um die Diagnoseinformationen für diesen Zeitpunkt zu laden. In den Diagnoseinformationen werden die relevanten Anwendungsprotokollgruppen angezeigt, die dem aktuellen Dienst und der aktuellen Metrik zugeordnet sind. Anschließend können Sie eine Schaltfläche auswählen, um eine CloudWatch Logs Insights-Abfrage für diese Protokollgruppen auszuführen. Je nach den in den Anwendungsprotokollen enthaltenen Informationen kann Ihnen dies dabei helfen, die Ursache für den Latenzanstieg zu untersuchen.

Abhängig von der Architektur, auf der Ihre Anwendung ausgeführt wird, müssen Sie möglicherweise auch eine Umgebungsvariable festlegen, um die Korrelation zwischen Metrik und Anwendungsprotokoll zu aktivieren.

Operationen mit hoher Kardinalität verwalten

Application Signals enthält Einstellungen im CloudWatch Agenten, mit denen Sie die Kardinalität Ihrer Operationen und den Export von Kennzahlen verwalten können, um die Kosten zu optimieren. Standardmäßig wird die Metrikbegrenzungsfunktion aktiv, wenn die Anzahl der einzelnen Operationen für einen Service im Laufe der Zeit den Standardschwellenwert von 500 überschreitet. Sie können das Verhalten anpassen, indem Sie die Konfigurationseinstellungen anpassen.

Stellen Sie fest, ob die metrische Begrenzung aktiviert ist

Sie können die folgenden Methoden verwenden, um herauszufinden, ob die standardmäßige metrische Begrenzung gilt. Ist dies der Fall, sollten Sie erwägen, die Kardinalitätssteuerung zu optimieren, indem Sie die Schritte im nächsten Abschnitt befolgen.

Optimieren Sie die Kardinalitätskontrolle

Um Ihre Kardinalitätskontrolle zu optimieren, können Sie wie folgt vorgehen:

Erstellen Sie benutzerdefinierte Regeln, um Operationen zu aggregieren

Operationen mit hoher Kardinalität können manchmal durch unangemessene Einzelwerte verursacht werden, die aus dem Kontext extrahiert wurden. Beispielsweise kann das Senden von HTTP /S-Anfragen, die einen Benutzer IDs oder eine Sitzung IDs im Pfad enthalten, zu Hunderten von unterschiedlichen Vorgängen führen. Um solche Probleme zu lösen, empfehlen wir, den CloudWatch Agenten mit Anpassungsregeln zu konfigurieren, um diese Operationen neu zu schreiben.

In Fällen, in denen die Generierung zahlreicher verschiedener Messwerte durch einzelne RemoteOperation Aufrufe, wie z. B., und ähnliche Anfragen PUT /api/customer/owners/123PUT /api/customer/owners/456, stark zunimmt, empfehlen wir, diese Vorgänge in einem einzigen RemoteOperation Vorgang zu konsolidieren. Ein Ansatz besteht insbesondere PUT /api/customer/owners/{ownerId} darin, alle RemoteOperation Anrufe, die mit beginnen, PUT /api/customer/owners/ auf ein einheitliches Format zu standardisieren. Das folgende Beispiel illustriert dies. Informationen zu anderen Anpassungsregeln finden Sie unter CloudWatch Anwendungssignale aktivieren.

{
   "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 anderen Fällen wurden Metriken mit hoher Kardinalität möglicherweise zu aggregiertAllOtherRemoteOperations, und es ist möglicherweise unklar, welche spezifischen Metriken enthalten sind. Der CloudWatch Agent kann die unterbrochenen Operationen protokollieren. Um unterbrochene Operationen zu identifizieren, verwenden Sie die Konfiguration im folgenden Beispiel, um die Protokollierung zu aktivieren, bis das Problem erneut auftritt. Untersuchen Sie dann die CloudWatch Agentenprotokolle (auf die über Container stdout - oder EC2 Protokolldateien zugegriffen werden kann) und suchen Sie nach dem Schlüsselwortdrop metric data.

{
  "agent": {
    "config": {
      "agent": {
        "debug": true
      },
      "traces": {
        "traces_collected": {
          "application_signals": {
          }
        }
      },
      "logs": {
        "metrics_collected": {
          "application_signals": {
            "limiter": {
              "log_dropped_metrics": true
            }
          }
        }
      }
    }
  }
}

Erstellen Sie Ihre Richtlinie zur Begrenzung von Metriken

Wenn die Standardkonfiguration für metrische Beschränkungen die Kardinalität für Ihren Service nicht berücksichtigt, können Sie die Konfiguration der metrischen Limitierung anpassen. Fügen Sie dazu unter dem limiter Abschnitt in der CloudWatch Agent-Konfigurationsdatei einen logs/metrics_collected/application_signals Abschnitt hinzu.

Im folgenden Beispiel wird der Schwellenwert für die Metrikbegrenzung von 500 verschiedenen Metriken auf 100 gesenkt.

{
  "logs": {
    "metrics_collected": {
      "application_signals": {
        "limiter": {
          "drop_threshold": 100
        }
      }
    }
  }
}