View a markdown version of this page

Fehlerbehebung bei der Installation von Application Signals - Amazon CloudWatch
Beheben Sie OpenTelemetry Konfigurationskonflikte in Amazon EKS mit Application SignalsApplication Signals – Kaltstartleistung der Java-SchichtDie Anwendung wird nicht gestartet, nachdem Application Signals aktiviert wurdeDie Python-Anwendung wird nicht gestartet, nachdem Application Signals aktiviert wurdeKeine Anwendungssignaldaten für eine Python-Anwendung, die einen Pre-Fork-Server (WSGI oder ASGI) verwendetMeine Node.js Anwendung ist nicht instrumentiert oder generiert keine Telemetrie für AnwendungssignaleMeine .NET-Anwendung ist nicht instrumentiert oder unterbricht AWS SDK-AufrufeKeine Anwendungsdaten im Application-Signals-DashboardServicemetriken oder Abhängigkeitsmetriken haben unbekannte WerteHandhabung von ConfigurationConflict bei der Verwaltung des Amazon CloudWatch Observability EKS-Add-onsIch möchte unnötige Metriken und Ablaufverfolgungsdaten herausfilternWas bedeutet InternalOperation?Wie aktiviere ich die Protokollierung für .NET-Anwendungen?Wie kann ich Konflikte mit Assembly-Versionen in .NET-Anwendungen lösen?Kann ich deaktivieren FluentBit?Kann ich Container-Logs filtern, bevor ich sie in CloudWatch Logs exportiere?Problemlösung TypeError bei Verwendung AWS Distribution für OpenTelemetry (ADOT) JavaScript Lambda LayerTypeError wenn Sie Response Streaming Lambda-Handler mit verwenden AWS Distribution für OpenTelemetry (ADOT) Lambda Layer JavaScriptAktualisieren Sie auf die erforderlichen Versionen der Agenten oder des Amazon-EKS-Add-onsEmbedded Metric Format (EMF) ist für Application Signals deaktiviert

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.

Fehlerbehebung bei der Installation von Application Signals

Dieser Abschnitt enthält Tipps zur Fehlerbehebung für CloudWatch Application Signals.

Themen

Beheben Sie OpenTelemetry Konfigurationskonflikte in Amazon EKS mit Application Signals

Wenn Sie OpenTelemetry (OTel) für die Überwachung der Anwendungsleistung (APM) mit Amazon EKS verwenden und benutzerdefinierte OTLP-Exporter-Endpunkte konfigurieren, bei denen es sich nicht um Endpunkte handelt, kann es nach der Installation oder dem Upgrade auf die CloudWatch Observability-Add-On-Version 5.0.0 oder höher zu den folgenden Verhaltensweisen kommen: CloudWatch

  • Störung der vorhandenen OTel-Telemetrie — Das CloudWatch Observability-Add-on kann die OTLP-Exporter-Endpunkte außer Kraft setzen, die Sie in Ihrer Anwendung fest codiert haben. Diese Überschreibung wirkt sich nicht auf Endpunkte aus, die über Container-Umgebungsvariablen oder konfiguriert wurden. envFrom ConfigMap Wenn Ihre Metriken und Traces außer Kraft gesetzt werden, erreichen sie möglicherweise nicht ihr beabsichtigtes Ziel. Informationen zur Beibehaltung Ihres bestehenden APM-Setups nach dem Upgrade auf V5.0.0 oder zu einem späteren Zeitpunkt finden Sie unter Melden Sie sich von Application Signals ab

  • Anwendungssignale funktionieren möglicherweise nicht, wenn Sie zuvor Application Signals mit dem CloudWatch Observability-Add-on aktiviert und einen benutzerdefinierten OTLP-Endpunkt konfiguriert haben. Um dieses Problem zu beheben, entfernen Sie entweder benutzerdefinierte OTLP-Endpunkte oder legen Sie die Umgebungsvariable fest, OTEL_AWS_APPLICATION_SIGNALS_ENABLED=true wenn Sie auf Version 5.0.0 oder höher installieren oder ein Upgrade auf Version 5.0.0 oder höher durchführen

Application Signals – Kaltstartleistung der Java-Schicht

Das Hinzufügen der Application-Signals-Schicht zu den Java-Lambda-Funktionen erhöht die Startlatenz (Kaltstartzeit). Die folgenden Tipps können helfen, die Latenz für zeitkritische Funktionen zu reduzieren.

Schneller Start für Java-Agenten – Der Java Lambda Layer von Application Signals enthält eine Schnellstartfunktion, die standardmäßig deaktiviert ist, aber durch Setzen der Variable OTEL_JAVA_AGENT_FAST_STARTUP_ENABLED auf true aktiviert werden kann. Wenn dieses Feature aktiviert ist, wird die JVM so konfiguriert, dass der C1-Compiler der Stufe 1 (Tiered Compilation) verwendet wird, um schnell optimierten nativen Code für schnellere Kaltstarts zu erzeugen. Der C1-Compiler legt den Schwerpunkt auf Geschwindigkeit auf Kosten langfristiger Optimierung, während der C2-Compiler eine bessere Gesamtleistung bietet, indem er ein Profil der Daten im Laufe der Zeit erstellt.

Weitere Informationen unter Schneller Start für den Java-Agenten.

Reduzieren Sie die Kaltstartzeiten mit Provisioned Concurrency — AWS Lambda Provisioned Concurrency weist vorab eine bestimmte Anzahl von Funktionsinstanzen zu, sodass diese initialisiert werden und sofort zur Bearbeitung von Anfragen bereit sind. Dies verkürzt die Kaltstartzeiten, da die Funktionsumgebung während der Ausführung nicht mehr initialisiert werden muss, und sorgt so für eine schnellere und konsistentere Leistung, insbesondere bei latenzempfindlichen Workloads. Weitere Informationen unter Konfigurieren von Provisioned Concurrency für eine Funktion.

Optimieren Sie die Startleistung mithilfe von Lambda SnapStart — AWS Lambda SnapStart diese Funktion optimiert die Startleistung von Lambda-Funktionen, indem nach der Initialisierungsphase der Funktion ein vorinitialisierter Snapshot der Ausführungsumgebung erstellt wird. Dieser Snapshot wird dann wiederverwendet, um neue Instances zu starten, was die Kaltstartzeiten erheblich reduziert, da der Initialisierungsprozess beim Funktionsaufruf übersprungen wird. Informationen finden Sie unter Verbessern der Startleistung mit Lambda SnapStart

Die Anwendung wird nicht gestartet, nachdem Application Signals aktiviert wurde

Wenn Ihre Anwendung auf einem Amazon-EKS-Cluster nicht startet, nachdem Sie Application Signals auf dem Cluster aktiviert haben, überprüfen Sie Folgendes:

  • Prüfen Sie, ob die Anwendung durch eine andere Überwachungslösung instrumentiert wurde. Application Signals unterstützt eventuell nicht die Koexistenz mit anderen Instrumentierungslösungen.

  • Vergewissern Sie sich, dass Ihre Anwendung die Kompatibilitätsanforderungen für die Verwendung von Application Signals erfüllt. Weitere Informationen finden Sie unter Unterstützte Systeme.

  • Wenn Ihre Anwendung die Application Signal-Artefakte wie den Agenten und CloudWatch die Agenten-Images der AWS Distribution for OpenTelemetery Java oder Python nicht abrufen konnte, könnte es sich um ein Netzwerkproblem handeln.

Um das Problem zu beheben, entfernen Sie die Anmerkung instrumentation.opentelemetry.io/inject-java: "true" oder instrumentation.opentelemetry.io/inject-python: "true" aus Ihrem Anwendungs-Bereitstellungsmanifest und stellen Sie Ihre Anwendung erneut bereit. Überprüfen Sie dann, ob die Anwendung funktioniert.

Bekannte Probleme

Die Erfassung von Laufzeit-Metriken in der Java-SDK-Version v1.32.5 funktioniert bekannterweise nicht mit Anwendungen, die JBoss Wildfly verwenden. Dieses Problem erstreckt sich auch auf das Amazon CloudWatch Observability EKS-Add-on und betrifft alle Versionen2.3.0-eksbuild.1. 2.5.0-eksbuild.1

Wenn Sie davon betroffen sind, sollten Sie entweder die Version herabstufen oder die Erfassung von Laufzeitmetriken deaktivieren, indem Sie die Umgebungsvariable OTEL_AWS_APPLICATION_SIGNALS_RUNTIME_ENABLED=false zu Ihrer Anwendung hinzufügen.

Die Python-Anwendung wird nicht gestartet, nachdem Application Signals aktiviert wurde

Es ist ein bekanntes Problem bei der OpenTelemetry automatischen Instrumentierung, dass eine fehlende PYTHONPATH Umgebungsvariable manchmal dazu führen kann, dass die Anwendung nicht gestartet wird. Um dieses Problem zu lösen, stellen Sie sicher, dass Sie die PYTHONPATH Umgebungsvariable auf den Speicherort des Arbeitsverzeichnisses Ihrer Anwendung setzen. Weitere Informationen zu diesem Problem finden Sie unter Die Python-Autoinstrumentierungseinstellung von PYTHONPATH ist nicht mit dem Python-Modulauflösungsverhalten konform, wodurch Django-Anwendungen beschädigt werden.

Für Django-Anwendungen sind zusätzliche Konfigurationen erforderlich, die in der OpenTelemetry Python-Dokumentation beschrieben werden.

  • Verwenden Sie das --noreload-Flag, um ein automatisches Neuladen zu verhindern.

  • Setzen Sie die DJANGO_SETTINGS_MODULE Umgebungsvariable auf den Speicherort der Datei Ihrer Django-Anwendung. settings.py Dadurch wird sichergestellt, dass OpenTelemetry Sie korrekt auf Ihre Django-Einstellungen zugreifen und diese integrieren können.

Keine Anwendungssignaldaten für eine Python-Anwendung, die einen Pre-Fork-Server (WSGI oder ASGI) verwendet

Pre-fork Server wie Gunicorn, uWSGI oder Uvicorn mit mehreren Workern trennen Worker-Prozesse von einem Hauptprozess ab. Das OpenTelemetry SDK stützt sich auf Threads im Hintergrund, die einen Fork nicht überleben. Wenn also der Hauptprozess instrumentiert ist, können die Worker keine Traces, Metriken und Logs exportieren.

Weitere Hintergrundinformationen zu diesem OpenTelemetry Verhalten finden Sie unter Pre-fork Serverprobleme in der OpenTelemetry Python-Dokumentation.

Um dieses Problem zu lösen, müssen Sie zuerst die automatische Instrumentierung in jedem Forking-Worker-Prozess und nicht im Hauptprozess initialisieren und dann ADOT Python so konfigurieren, dass der Hauptprozess übersprungen wird.

Anmerkung

Stellen Sie sicher, dass Sie die neueste Version von ADOT Python und das Amazon CloudWatch Observability EKS-Add-on verwenden, bevor Sie fortfahren.

Zusätzliche Schritte zur Aktivierung von Application Signals mit einem Pre-Fork-Server

  1. Initialisieren Sie die automatische Instrumentierung in den Forking-Worker-Prozessen.

    Verwenden Sie für Gunicorn den post_fork-Hook:

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

    Verwenden Sie für uWSGI die import-Direktive.

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

    Bei Uvicorn-, FastAPI- oder anderen ASGI-Anwendungen, die Sie mit mehreren Workern ausführen, initialisieren Sie die Instrumentierung im Worker, indem Sie vor dem Import Ihrer Anwendung einen Aufruf aufrufen. initialize() Platzieren Sie Folgendes oben im Einstiegsmodul Ihrer Anwendung:

    from opentelemetry.instrumentation.auto_instrumentation import initialize

initialize()

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

app = FastAPI()

    Starten Sie dann den Server wie gewohnt, zum Beispiel:

    uvicorn main:app --workers 2

    Wenn Sie eine ASGI-Anwendung unter Gunicorn ausführen, können Sie alternativ Gunicorn's verwenden, wodurch die Hintergrund-Threads auf dem Fork erhalten bleibenUvicornWorker, zusammen mit dem zuvor gezeigten Hook: post_fork

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

  2. Aktivieren Sie die Konfiguration für die automatische ADOT-Python-Instrumentierung, um den Hauptprozess zu überspringen und an Worker zu verlagern, indem Sie die OTEL_AWS_PYTHON_DEFER_TO_WORKERS_ENABLED-Umgebungsvariable auf true festlegen.

    Nachdem beide Schritte angewendet wurden, initialisiert jeder Worker-Prozess nach dem Fork seine eigenen Tracer-, Metrik- und Log-Pipelines, sodass Traces, Metriken und Logs korrekt exportiert werden.

Meine Node.js Anwendung ist nicht instrumentiert oder generiert keine Telemetrie für Anwendungssignale

Um Anwendungssignale für zu aktivieren Node.js, müssen Sie sicherstellen, dass Ihre Node.js Anwendung das CommonJS (CJS) -Modulformat verwendet. Die AWS Distribution für unterstützt das ESM-Modulformat OpenTelemetry Node.js nicht, da OpenTelemetry JavaScript die Unterstützung von ESM experimentell ist und in Arbeit ist.

Um festzustellen, ob Ihre Anwendung CJS und nicht ESM verwendet, stellen Sie sicher, dass Ihre Anwendung die Bedingungen für die Aktivierung von ESM nicht erfüllt.

Meine .NET-Anwendung ist nicht instrumentiert oder unterbricht AWS SDK-Aufrufe

Das AWS Distro for Open Telemetry (ADOT) SDK für.NET unterstützt AWS SDK für.NET V4 nicht. Verwenden Sie AWS SDK .NET V3 für die vollständige Unterstützung von Anwendungssignalen.

Keine Anwendungsdaten im Application-Signals-Dashboard

Wenn in den Dashboards von Application Signals Metriken oder Traces fehlen, kann dies folgende Ursachen haben. Untersuchen Sie diese Ursachen nur, wenn Sie seit Ihrer letzten Aktualisierung bereits 15 Minuten darauf gewartet haben, dass Application Signals Daten erfasst und anzeigt.

  • Stellen Sie sicher, dass die Bibliothek und das Framework, die Sie verwenden, vom ADOT-Java-Agenten unterstützt werden. Weitere Informationen finden Sie unter Bibliotheken/Frameworks.

  • Stellen Sie sicher, dass der CloudWatch Agent läuft. Überprüfen Sie zunächst den Status der CloudWatch Agenten-Pods und stellen Sie sicher, dass alle im Running Status sind.

    kubectl -n amazon-cloudwatch get pods.

    Fügen Sie der CloudWatch Agentenkonfigurationsdatei Folgendes hinzu, um Debugging-Protokolle zu aktivieren, und starten Sie den Agenten anschließend neu.

    "agent": {

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

    Suchen Sie dann in den CloudWatch Agent-Pods nach Fehlern.

  • Suchen Sie nach Konfigurationsproblemen mit dem CloudWatch Agenten. Vergewissern Sie sich, dass Folgendes noch in der CloudWatch Agentenkonfigurationsdatei enthalten ist und der Agent seit seinem Hinzufügen neu gestartet wurde.

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

    Überprüfen Sie dann die OpenTelemetry Debugging-Protokolle auf Fehlermeldungen wie. ERROR io.opentelemetry.exporter.internal.grpc.OkHttpGrpcExporter - Failed to export ... Diese Meldungen könnten auf das Problem hinweisen.

    Wenn das Problem dadurch nicht behoben wird, speichern und überprüfen Sie die Umgebungsvariablen, deren Namen mit OTEL_ beginnen, indem Sie den Pod mit dem kubectl describe pod-Befehl beschreiben.

  • Um die OpenTelemetry Python-Debug-Protokollierung zu aktivieren, setzen Sie die Umgebungsvariable OTEL_PYTHON_LOG_LEVEL auf debug und stellen Sie die Anwendung erneut bereit.

  • Suchen Sie nach falschen oder unzureichenden Berechtigungen für den Export von Daten aus dem CloudWatch Agenten. Wenn Sie in den CloudWatch Agentenprotokollen Access Denied Meldungen sehen, könnte dies das Problem sein. Es ist möglich, dass die bei der Installation des CloudWatch Agenten geltenden Berechtigungen später geändert oder widerrufen wurden.

  • Prüfen Sie, ob beim Generieren von Telemetriedaten ein AWS Distro for OpenTelemetry (ADOT) -Problem vorliegt.

    Stellen Sie sicher, dass die Anmerkungen zur Instrumentierung instrumentation.opentelemetry.io/inject-java und sidecar.opentelemetry.io/inject-java auf die Anwendungsbereitstellung angewendet werden, und dass der Wert true lautet. Ohne diese werden die Anwendungs-Pods nicht instrumentiert, selbst wenn das ADOT-Add-On korrekt installiert ist.

    Prüfen Sie als Nächstes, ob der init-Container auf die Anwendung angewendet wurde und ob der Ready-Status True ist. Wenn der init-Container nicht bereit ist, sehen Sie sich den Status an, um den Grund zu erfahren.

    Wenn das Problem weiterhin besteht, aktivieren Sie die Debug-Protokollierung im OpenTelemetry Java SDK, indem Sie die Umgebungsvariable auf true setzen und die OTEL_JAVAAGENT_DEBUG Anwendung erneut bereitstellen. Suchen Sie dann nach Nachrichten, die mit ERROR io.telemetry beginnen.

  • Das metric/span Exportprogramm löscht möglicherweise Daten. Um das herauszufinden, suchen Sie im Anwendungsprotokoll nach Meldungen, die Failed to export... beinhalten.

  • Der CloudWatch Agent wird möglicherweise gedrosselt, wenn er Messwerte oder Spans an Anwendungssignale sendet. Suchen Sie in den Agent-Protokollen nach Meldungen, die auf eine Drosselung hinweisen. CloudWatch

  • Stellen Sie sicher, dass Sie das Serviceerkennungs-Setup aktiviert haben. Sie müssen das in Ihrer Region nur einmal tun.

    Um dies zu bestätigen, wählen Sie in der CloudWatch Konsole Application Signals, Services aus. Wenn Schritt 1 nicht als abgeschlossen markiert ist, wählen Sie Mit der Entdeckung Ihrer Services beginnen aus. Der Datenfluss sollte innerhalb von fünf Minuten beginnen.

Servicemetriken oder Abhängigkeitsmetriken haben unbekannte Werte

Wenn Sie in den Application-Signals-Dashboards UnknownService UnknownOperation UnknownRemoteService,, oder UnknownRemoteOperation für einen Abhängigkeitsnamen oder eine Operation sehen, überprüfen Sie, ob das Auftreten von Datenpunkten für den unbekannten Remote-Service und den unbekannten Fernbetrieb mit ihren Bereitstellungen übereinstimmt.

  • UnknownServicebedeutet, dass der Name einer instrumentierten Anwendung unbekannt ist. Wenn die OTEL_SERVICE_NAME-Umgebungsvariable undefiniert und service.name nicht in OTEL_RESOURCE_ATTRIBUTES angegeben ist, wird der Servicename auf UnknownService gesetzt. Um dieses Problem zu beheben, geben Sie den Servicenamen in OTEL_SERVICE_NAME oder OTEL_RESOURCE_ATTRIBUTES an.

  • UnknownOperationbedeutet, dass der Name einer aufgerufenen Operation unbekannt ist. Das kommt vor, wenn Application Signals nicht in der Lage ist, einen Vorgangsnamen zu ermitteln, der den Remote-Aufruf auslöst, oder wenn der extrahierte Vorgangsname Werte mit hoher Kardinalität enthält.

  • UnknownRemoteServicebedeutet, dass der Name des Zieldienstes unbekannt ist. Das kommt vor, wenn das System den Namen des Zielservices, auf den der Remote-Aufruf zugreift, nicht extrahieren kann.

    Eine Lösung besteht darin, einen benutzerdefinierten Bereich für die Funktion, die die Anforderung sendet, zu erstellen und das Attribut aws.remote.service mit dem angegebenen Wert hinzuzufügen. Eine weitere Option besteht darin, den CloudWatch Agenten so zu konfigurieren, dass der Metrikwert von angepasst wirdRemoteService. Weitere Informationen zu Anpassungen im CloudWatch Agenten finden Sie unterCloudWatch Anwendungssignale aktivieren.

  • UnknownRemoteOperationbedeutet, dass der Name der Zieloperation unbekannt ist. Das kommt vor, wenn das System den Namen des Zielvorgangs, auf den der Remote-Aufruf zugreift, nicht extrahieren kann.

    Eine Lösung besteht darin, einen benutzerdefinierten Bereich für die Funktion, die die Anforderung sendet, zu erstellen und das Attribut aws.remote.operation mit dem angegebenen Wert hinzuzufügen. Eine weitere Option besteht darin, den CloudWatch Agenten so zu konfigurieren, dass der Metrikwert von angepasst wirdRemoteOperation. Weitere Informationen zu Anpassungen im CloudWatch Agenten finden Sie unterCloudWatch Anwendungssignale aktivieren.

Handhabung von ConfigurationConflict bei der Verwaltung des Amazon CloudWatch Observability EKS-Add-ons

Wenn Sie bei der Installation oder Aktualisierung des Amazon CloudWatch Observability EKS-Add-ons einen Fehler feststellen, Health Issue der durch einen Typ ConfigurationConflict mit einer Beschreibung verursacht wird, die mit beginntConflicts found when trying to apply. Will not continue due to resolve conflicts mode, liegt das wahrscheinlich daran, dass Sie den CloudWatch Agenten und die zugehörigen Komponenten wie den ServiceAccount, den ClusterRole und den bereits auf dem Cluster ClusterRoleBinding installiert haben. Wenn das Add-on versucht, den CloudWatch Agenten und die zugehörigen Komponenten zu installieren und eine Änderung des Inhalts feststellt, schlägt es standardmäßig bei der Installation oder Aktualisierung fehl, um zu verhindern, dass der Status der Ressourcen auf dem Cluster überschrieben wird.

Wenn Sie versuchen, das Amazon CloudWatch Observability EKS-Add-on zu integrieren, und dieser Fehler auftritt, empfehlen wir, ein vorhandenes CloudWatch Agenten-Setup zu löschen, das Sie zuvor auf dem Cluster installiert hatten, und dann das EKS-Add-on zu installieren. Stellen Sie sicher, dass Sie eine Sicherungskopie aller Anpassungen erstellen, die Sie möglicherweise an der ursprünglichen CloudWatch Agentenkonfiguration vorgenommen haben, z. B. eine benutzerdefinierte Agentenkonfiguration, und stellen Sie diese dem Amazon CloudWatch Observability EKS-Add-on zur Verfügung, wenn Sie es das nächste Mal installieren oder aktualisieren. Wenn Sie den CloudWatch Agenten für das Onboarding in Container Insights zuvor installiert hatten, finden Sie Anleitung zur Einrichtung (AWS CLI) weitere Informationen unter.

Alternativ unterstützt das Add-On eine Konfigurationsoption zur Konfliktlösung, die OVERWRITE spezifizieren kann. Sie können diese Option verwenden, um mit der Installation oder Aktualisierung des Add-Ons fortzufahren, indem Sie die Konflikte auf dem Cluster überschreiben. Wenn Sie die Amazon-EKS-Konsole verwenden, finden Sie die Methode zur Konfliktlösung, wenn Sie beim Erstellen oder Aktualisieren des Add-Ons die optionalen Konfigurationseinstellungen auswählen. Wenn Sie den verwenden AWS CLI, können Sie dies in Ihren Befehl eingeben, --resolve-conflicts OVERWRITE um das Add-on zu erstellen oder zu aktualisieren.

Ich möchte unnötige Metriken und Ablaufverfolgungsdaten herausfiltern

Wenn Application Signals Traces und Metriken sammelt, die Sie nicht möchten, finden Sie unter Informationen Vorgänge mit hoher Kardinalität verwalten zur Konfiguration des CloudWatch Agenten mit benutzerdefinierten Regeln zur Reduzierung der Kardinalität.

Informationen zum Anpassen der Regeln für das Trace-Sampling finden Sie in der Dokumentation unter Konfigurieren von Sampling-Regeln. X-Ray

Was bedeutet InternalOperation?

Ein InternalOperation ist ein Vorgang, der von der Anwendung intern und nicht durch einen externen Aufruf ausgelöst wird. Die Anzeige von InternalOperation ist erwartetes, gesundes Verhalten.

Zu typischen Beispielen, in denen InternalOperation angezeigt würde, gehören:

  • Beim Start vorab laden – Ihre Anwendung führt einen Vorgang mit dem Namen loadDatafromDB durch, bei dem während der Aufwärmphase Metadaten aus einer Datenbank gelesen werden. Anstatt den Vorgang loadDatafromDB als Service zu betrachten, wird er als InternalOperation kategorisiert angezeigt.

  • Asynchrone Ausführung im Hintergrund — Ihre Anwendung abonniert eine Ereigniswarteschlange und verarbeitet Streaming-Daten entsprechend, wenn ein Update erfolgt. Jeder ausgelöste Vorgang wird unter InternalOperation als Servicevorgang eingestuft.

  • Hostinformationen aus einer Serviceregistrierung abrufen– Ihre Anwendung kommuniziert zur Serviceerkennung mit einer Serviceregistrierung. Alle Interaktionen mit dem Erkennungssystem werden als InternalOperation klassifiziert.

Wie aktiviere ich die Protokollierung für .NET-Anwendungen?

Zur Protokollierung für .NET-Anwendungen konfigurieren Sie die folgenden Umgebungsvariablen. Weitere Informationen zur Konfiguration dieser Umgebungsvariablen finden Sie in der Dokumentation unter Problembehandlung bei der automatischen .NET-Instrumentierung. OpenTelemetry

  • OTEL_LOG_LEVEL

  • OTEL_DOTNET_AUTO_LOG_DIRECTORY

  • COREHOST_TRACE

  • COREHOST_TRACEFILE

Wie kann ich Konflikte mit Assembly-Versionen in .NET-Anwendungen lösen?

Wenn Sie die folgende Fehlermeldung erhalten, finden Sie in der OpenTelemetry Dokumentation unter Assembly-Versionskonflikte die Schritte zur Problembehebung.

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

Kann ich deaktivieren FluentBit?

Sie können es deaktivieren, FluentBit indem Sie das Amazon CloudWatch Observability EKS-Add-on konfigurieren. Weitere Informationen finden Sie unter (Optional) Zusätzliche Konfiguration.

Kann ich Container-Logs filtern, bevor ich sie in CloudWatch Logs exportiere?

Nein, das Filtern von Container-Protokollen wird noch nicht unterstützt.

Problemlösung TypeError bei Verwendung AWS Distribution für OpenTelemetry (ADOT) JavaScript Lambda Layer

Ihre Lambda-Funktion kann in folgenden Fällen diesen Fehler TypeError - "Cannot redefine property: handler" ausgeben:

  • Verwenden Sie den ADOT Lambda Layer JavaScript

  • Zum Kompilieren verwenden esbuild TypeScript

  • Sie exportieren Ihren Handler mit dem Schlüsselwort export

Der ADOT JavaScript Lambda Layer muss Ihren Handler zur Laufzeit ändern. Wenn Sie das export Schlüsselwort with esbuild (direkt oder über AWS CDK) verwenden, wird Ihr Handler unveränderlich, esbuild wodurch diese Änderungen verhindert werden.

Exportieren Sie Ihre Handler-Funktion mit module.exports anstelle des Schlüsselworts export: 

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

TypeError wenn Sie Response Streaming Lambda-Handler mit verwenden AWS Distribution für OpenTelemetry (ADOT) Lambda Layer JavaScript

Ihre Lambda-Funktion kann in folgenden Fällen diesen Fehler TypeError - "responseStream.write is not a function" ausgeben:

  • Verwenden Sie den ADOT JavaScript Lambda Layer mit aktivierter AWS Lambda-Instrumentation (standardmäßig aktiviert)

  • Verwendung der Antwort-Streaming-Funktion in Node.js verwalteten Laufzeiten. Zum Beispiel, wenn Ihr Funktionshandler wie folgt aussieht:

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

Die AWS Lambda-Instrumentation im ADOT JavaScript Lambda Layer unterstützt derzeit kein Response Streaming in Node.js verwalteten Laufzeiten. Sie muss daher deaktiviert werden, um dies zu vermeiden. TypeError

Aktualisieren Sie auf die erforderlichen Versionen der Agenten oder des Amazon-EKS-Add-ons

Nach dem 9. August 2024 unterstützt CloudWatch Application Signals keine älteren Versionen des Amazon CloudWatch Observability EKS-Add-ons, des CloudWatch Agenten und des AWS Distro for OpenTelemetry Auto Instrumentation Agents mehr.

  • Für das Amazon CloudWatch Observability EKS-Add-on werden ältere Versionen als v1.7.0-eksbuild.1 nicht unterstützt.

  • Für den CloudWatch Agenten werden Versionen, die älter sind als, 1.300040.0 nicht unterstützt.

  • Für den Agenten AWS Distro for OpenTelemetry Auto Instrumentation:

    • Für Java werden Versionen vor 1.32.2 nicht unterstützt.

    • Für Python werden Versionen vor 0.2.0 nicht unterstützt.

    • Für .NET werden Versionen vor 1.3.2 nicht unterstützt.

    • Für Versionen Node.js, die älter 0.3.0 sind als, werden nicht unterstützt.

Wichtig

Die neuesten Versionen der Agenten enthalten Aktualisierungen des Application-Signals-Metrikschemas. Diese Updates sind nicht abwärtskompatibel. Das kann zu Datenproblemen führen, wenn inkompatible Versionen verwendet werden. Gehen Sie wie folgt vor, um einen reibungslosen Übergang zu den neuen Funktionen zu gewährleisten:

  • Wenn Ihre Anwendung auf Amazon EKS ausgeführt wird, stellen Sie sicher, dass Sie alle instrumentierten Anwendungen neu starten, nachdem Sie das Amazon CloudWatch Observability-Add-on aktualisiert haben.

  • Achten Sie bei Anwendungen, die auf anderen Plattformen ausgeführt werden, darauf, sowohl den CloudWatch Agenten als auch den Agenten für die AWS OpenTelemetry automatische Instrumentierung auf die neuesten Versionen zu aktualisieren.

Die Anweisungen in den folgenden Abschnitten können Ihnen bei der Aktualisierung auf eine unterstützte Version helfen.

Aktualisieren Sie das Amazon CloudWatch Observability EKS-Add-on

Für das Amazon CloudWatch Observability EKS-Add-on können Sie das AWS-Managementkonsole oder verwenden. AWS CLI

Verwenden der Konsole

So aktualisieren Sie das Add-On mit der Konsole

  1. Öffnen Sie die Amazon EKS-Konsole unter https://console.aws.amazon.com/eks/home #/clusters.

  2. Wählen Sie den Namen des Amazon-EKS-Clusters, das Sie aktualisieren möchten.

  3. Wählen Sie den Add-ons Tab und dann Amazon CloudWatch Observability aus.

  4. Wählen Sie Bearbeiten, wählen Sie die Version aus, auf die Sie aktualisieren möchten, und wählen Sie dann Änderungen speichern.

    Stellen Sie sicher, dass Sie v1.7.0-eksbuild.1 oder neuer wählen.

  5. Geben Sie einen der folgenden AWS CLI Befehle ein, um Ihre Dienste neu zu starten.

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

Verwenden Sie den AWS CLI

Um das Add-on mit dem zu aktualisieren AWS CLI

  1. Geben Sie den folgenden Befehl ein, um die neueste Version zu finden.

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

  2. Geben Sie den folgenden Befehl ein, um das Add-On zu aktualisieren. $VERSIONErsetzen Sie es durch eine Version, die älter v1.7.0-eksbuild.1 oder neuer ist. Ersetzen Sie $AWS_REGION und $CLUSTER durch Ihre Region und Ihren Clusternamen.

    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
    Anmerkung

    Wenn Sie eine benutzerdefinierte Konfiguration für das Add-on verwenden, finden Sie ein Beispiel für die zu verwendende Konfiguration $JSON_CONFIG unterCloudWatch Anwendungssignale aktivieren.

  3. Geben Sie einen der folgenden AWS CLI Befehle ein, um Ihre Dienste neu zu starten.

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

Aktualisieren Sie den CloudWatch Agenten und den ADOT-Agenten

Wenn Ihre Dienste auf anderen Architekturen als Amazon EKS ausgeführt werden, müssen Sie sowohl den Agenten als auch den CloudWatch ADOT-Agenten für die automatische Instrumentierung aktualisieren, um die neuesten Funktionen von Application Signals nutzen zu können.

Update zu Amazon ECS

So aktualisieren Sie Ihre Agenten für Services, die auf Amazon ECS ausgeführt werden

  1. Erstellen einer neuen Aufgabendefinitionsversion. Weitere Informationen finden Sie unter Aktualisieren einer Aufgabendefinition mithilfe der Konsole.

  2. Ersetzen Sie das $IMAGE des ecs-cwagent-Containers durch das neueste Image-Tag von cloudwatch-agent auf Amazon ECR.

    Wenn Sie ein Upgrade auf eine feste Version durchführen, stellen Sie sicher, dass Sie die Version 1.300040.0 oder neuer verwenden.

  3. Ersetzen Sie das $IMAGE des init-Containers durch das neueste Image-Tag aus den folgenden Speicherorten:

  4. Aktualisieren Sie die Umgebungsvariablen von Application Signals in Ihrem App-Container, indem Sie den Anweisungen unter Schritt 4: Instrumentieren Sie Ihre Bewerbung mit dem CloudWatch Agenten folgen.

  5. Stelle Sie den Service mit der neuen Aufgabendefinition bereit.

Führen Sie ein Update auf Amazon EC2 oder anderen Architekturen durch

So aktualisieren Sie Ihre Agenten für Services, die auf Amazon EC2 oder anderen Architekturen ausgeführt werden

  1. Achten Sie darauf, eine Version 1.300040.0 oder eine höhere Version der Agentenversion auszuwählen. CloudWatch

  2. Laden Sie die neueste Version des Agenten AWS Distro for OpenTelemetry Auto Instrumentation von einem der folgenden Standorte herunter:

  3. Wenden Sie die aktualisierten Umgebungsvariablen von Application Signals auf Ihre Anwendung an und starten Sie dann Ihre Anwendung. Weitere Informationen finden Sie unter Schritt 3: Ihre Anwendung instrumentieren und starten.

Embedded Metric Format (EMF) ist für Application Signals deaktiviert

Die Deaktivierung von EMF für die /aws/application-signals/data-Protokollgruppe kann folgende Auswirkungen auf die Funktionalität von Application Signals haben.

  • Die Metriken und Diagramme von Application Signals werden nicht angezeigt

  • Die Funktionalität von Application Signals wird beeinträchtigt

Wie stelle ich Application Signals wieder her?

Wenn Application Signals leere Diagramme oder Metriken anzeigt, müssen Sie EMF für die /aws/application-signals/data-Protokollgruppe aktivieren, um die volle Funktionalität wiederherzustellen. Weitere Informationen finden Sie unter PutAccountPolicy.