Fehlerbehebung bei der Installation von Application Signals - Amazon CloudWatch
Behebung von OpenTelemetry Konfigurationskonflikten 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 Application-Signals-Daten für eine Python-Anwendung, die einen WSGI-Server verwendetMeine Node.js-Anwendung ist nicht instrumentiert oder generiert keine Application-Signals-TelemetrieMeine .NET-Anwendung ist nicht instrumentiert oder bricht bei SDK-Aufrufen ab AWSKeine Anwendungsdaten im Application-Signals-DashboardServicemetriken oder Abhängigkeitsmetriken haben unbekannte WerteUmgang mit einem 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-Protokolle filtern, bevor ich sie nach CloudWatch Logs exportiere? Lösung TypeError bei Verwendung von AWS Distro for OpenTelemetry (ADOT) Lambda Layer JavaScript TypeError bei Verwendung von Response Streaming-Lambda-Handlern mit AWS Distro für OpenTelemetry (ADOT) Lambda Layer JavaScript Aktualisieren 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

Behebung von OpenTelemetry Konfigurationskonflikten 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 CloudWatch Observability CloudWatch Add-on Version 5.0.0 oder höher zu den folgenden Verhaltensweisen kommen:

  • Unterbrechung der bestehenden 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 sie überschrieben wird, erreichen Ihre Metriken und Traces möglicherweise nicht ihr beabsichtigtes Ziel. Informationen zur Beibehaltung Ihres bestehenden APM-Setups nach dem Upgrade auf Version 5.0.0 oder höher finden Sie unter Melden Sie sich von Application Signals ab

  • Application Signals funktionieren möglicherweise nicht, wenn Sie Application Signals zuvor mithilfe des CloudWatch Observability-Add-ons 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 Version 5.0.0 oder höher installieren oder aktualisieren

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 und bereit sind, Anfragen sofort zu bearbeiten. 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 ist eine Funktion, die die Startleistung von Lambda-Funktionen optimiert, 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. Weitere 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 Agent-Images von AWS Distro for OpenTelemetery Java oder Python nicht abrufen konnte, liegt möglicherweise ein Netzwerkproblem vor.

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

Es ist bekannt, dass die Erfassung von Laufzeit-Metriken in der Java-SDK-Version v1.32.5 nicht mit Anwendungen funktioniert, die Wildfly verwenden. JBoss Dieses Problem erstreckt sich auf das Amazon CloudWatch Observability EKS-Add-on und betrifft Versionen 2.3.0-eksbuild.1 bis2.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 werden kann. Um dieses Problem zu beheben, 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.

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

Keine Application-Signals-Daten für eine Python-Anwendung, die einen WSGI-Server verwendet

Wenn Sie einen WSGI-Server wie Gunicorn oder uWSGI verwenden, müssen Sie zusätzliche Änderungen vornehmen, damit die automatische ADOT-Python-Instrumentierung funktioniert.

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

  1. Importieren Sie die automatische Instrumentierung in die geteilten Worker-Prozesse.

    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

  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.

Meine Node.js-Anwendung ist nicht instrumentiert oder generiert keine Application-Signals-Telemetrie

Um Application Signals für Node.js zu aktivieren, müssen Sie sicherstellen, dass Ihre Node.js-Anwendung das CommonJS-Modulformat (CJS) verwendet. Die AWS Distribution für OpenTelemetry Node.js unterstützt das ESM-Modulformat nicht, da OpenTelemetry JavaScript die Unterstützung von ESM experimentell ist und noch 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 bricht bei SDK-Aufrufen ab AWS

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

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 sie alle im Running Status sind.

    kubectl -n amazon-cloudwatch get pods.

    Fügen Sie der CloudWatch Agent-Konfigurationsdatei 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 sich Folgendes immer noch in der CloudWatch Agenten-Konfigurationsdatei befindet und der Agent seit dem 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.

  • Prüfen Sie, ob die Berechtigungen für den Export von Daten aus dem Agenten falsch oder unzureichend sind. CloudWatch Wenn Sie Access Denied Nachrichten in den CloudWatch Agentenprotokollen 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 aufgehoben wurden.

  • Achten Sie bei der Generierung von Telemetriedaten auf ein Problem mit AWS Distro for OpenTelemetry (ADOT).

    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 Anwendung OTEL_JAVAAGENT_DEBUG erneut bereitstellen. Suchen Sie dann nach Nachrichten, die mit ERROR io.telemetry beginnen.

  • Der metric/span Exporter 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 Metriken oder Spans an Application Signals sendet. Suchen Sie in den Agentenprotokollen 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 Dashboards von Application Signals UnknownServiceUnknownOperationUnknownRemoteService,, oder UnknownRemoteOperationfü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 Remote-Betrieb mit deren Bereitstellung ü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 unter CloudWatch Anwendungssignale aktivieren.

  • UnknownRemoteOperationbedeutet, dass der Name des Zielvorgangs 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 unter CloudWatch Anwendungssignale aktivieren.

Umgang mit einem 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 die 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 alle Anpassungen, die Sie möglicherweise am ursprünglichen CloudWatch Agenten-Setup vorgenommen haben, wie z. B. eine benutzerdefinierte Agentenkonfiguration, sichern und diese dem Amazon CloudWatch Observability EKS-Add-on zur Verfügung stellen, wenn Sie es das nächste Mal installieren oder aktualisieren. Wenn Sie den CloudWatch Agenten für das Onboarding in Container Insights bereits installiert hatten, finden Sie Der CloudWatch Agent und Fluent Bit für Container Insights werden gelöscht 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 den 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 von Samplingregeln für Ablaufverfolgungsdaten finden Sie unter Konfigurieren von Samplingregeln in der X-Ray-Dokumentation.

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 bei jeder Aktualisierung entsprechend. 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 Problemen mit 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 den folgenden Fehler erhalten, finden Sie in der OpenTelemetry Dokumentation unter Versionskonflikte in der Assemblyversion eine Beschreibung der Lösungsschritte.

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-Protokolle filtern, bevor ich sie nach CloudWatch Logs exportiere?

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

Lösung TypeError bei Verwendung von AWS Distro for OpenTelemetry (ADOT) Lambda Layer JavaScript

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

  • Verwenden Sie den ADOT JavaScript Lambda Layer

  • 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 bei Verwendung von Response Streaming-Lambda-Handlern mit AWS Distro 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)

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

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

Die AWS Lambda-Instrumentierung im ADOT JavaScript Lambda Layer unterstützt derzeit kein Response Streaming in verwalteten Laufzeiten von Node.js. 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 wird CloudWatch Application Signals ältere Versionen des Amazon CloudWatch Observability EKS-Add-ons, des Agenten und des CloudWatch Agenten AWS Distro for OpenTelemetry Auto-Instrumentation nicht mehr unterstützen.

  • Für das Amazon CloudWatch Observability EKS-Add-on werden Versionen, die älter sind 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 Node.js werden Versionen vor 0.3.0 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 läuft, 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 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

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

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 Tab Add-ons und anschließend Amazon CloudWatch Observability.

  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 aktuelle Version v1.7.0-eksbuild.1 oder eine neuere Version. 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 unter CloudWatch 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 Services auf anderen Architekturen als Amazon EKS ausgeführt werden, müssen Sie sowohl den CloudWatch Agenten als auch den ADOT-Agent für 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: Kommunizieren Sie Ihre Bewerbung mit dem CloudWatch Agenten folgen.

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

Update auf Amazon EC2 oder anderen Architekturen

Um Ihre Agenten für Dienste zu aktualisieren, die auf Amazon EC2 oder anderen Architekturen ausgeführt werden

  1. Stellen Sie sicher, dass Sie die Version 1.300040.0 oder eine neuere Version der CloudWatch Agentenversion auswählen.

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

    • Verwenden Sie für Java. aws-otel-java-instrumentation

      Wenn Sie ein Upgrade auf eine feste Version durchführen, wählen Sie unbedingt 1.32.2 oder neuer.

    • Verwenden Sie für Python aws-otel-python-instrumentation .

      Wenn Sie ein Upgrade auf eine feste Version durchführen, wählen Sie unbedingt 0.2.0 oder neuer.

    • Verwenden Sie für .NET aws-otel-dotnet-instrumentation.

      Wenn Sie ein Upgrade auf eine feste Version durchführen, wählen Sie unbedingt 1.3.2 oder neuer.

    • Verwenden Sie für Node.js aws-otel-js-instrumentation.

      Wenn Sie ein Upgrade auf eine feste Version durchführen, wählen Sie unbedingt 0.3.0 oder neuer.

  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.