Fehlerbehebung bei der Installation von Application Signals - Amazon CloudWatch
Die Anwendung signalisiert die Kaltstartleistung der Java-SchichtDie Anwendung wird nicht gestartet, nachdem Application Signals aktiviert wurdeDie Python-Anwendung startet nicht, nachdem Application Signals aktiviert wurdeKeine Anwendungssignaldaten für eine Python-Anwendung, die einen WSGI-Server verwendetMeine Anwendung Node.js ist nicht instrumentiert oder generiert keine Telemetrie mit AnwendungssignalenKeine Anwendungsdaten im Application Signals-DashboardService- 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 Traces herausfilternWas InternalOperation heißt das?Wie aktiviere ich die Protokollierung für .NET-Anwendungen?Wie kann ich Konflikte mit Assemblyversionen 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 Aktualisieren Sie auf die erforderlichen Versionen von Agenten oder Amazon EKS-Add-Ons

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.

Die Anwendung signalisiert die Kaltstartleistung der Java-Schicht

Das Hinzufügen des Application Signals Layer zu den Java-Lambda-Funktionen erhöht die Startlatenz (Kaltstartzeit). Die folgenden Tipps können dazu beitragen, 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 aktiviert werden kann, indem die Variable OTEL_JAVA_AGENT_FAST_STARTUP_ENABLED auf true gesetzt wird. Wenn diese Funktion aktiviert ist, konfiguriert sie die JVM so, dass sie einen C1-Compiler der Stufe 1 für die mehrstufige Kompilierung verwendet, um schnellen, optimierten systemeigenen Code für schnellere Kaltstarts zu generieren. Der C1-Compiler priorisiert Geschwindigkeit auf Kosten der langfristigen Optimierung, wohingegen der C2-Compiler eine überragende Gesamtleistung bietet, indem er Daten im Laufe der Zeit profiliert.

Weitere Informationen finden Sie 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. Dadurch werden die Kaltstartzeiten reduziert, da die Funktionsumgebung während der Ausführung nicht initialisiert werden muss, wodurch eine schnellere und konsistentere Leistung gewährleistet wird, insbesondere bei latenzempfindlichen Workloads. Weitere Informationen finden Sie unter Konfiguration der bereitgestellten Parallelität 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 Instanzen zu starten, wodurch die Kaltstartzeiten erheblich reduziert werden, 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 möglicherweise 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 Anwendungsbereitstellungsmanifest 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 betroffen sind, führen Sie entweder ein Downgrade der Version durch oder deaktivieren Sie die Erfassung Ihrer Laufzeitmetriken, indem Sie Ihrer Anwendung die Umgebungsvariable OTEL_AWS_APPLICATION_SIGNALS_RUNTIME_ENABLED=false hinzufügen.

Die Python-Anwendung startet nicht, 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-Autoinstrumentation-Einstellung von PYTHONPATH entspricht nicht dem Modulauflösungsverhalten von Python, 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 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 Fork-Worker-Prozesse.

    Verwenden Sie für Gunicorn den Hook: post_fork

    # 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 den Workern zu überlassen, indem Sie die OTEL_AWS_PYTHON_DEFER_TO_WORKERS_ENABLED Umgebungsvariable auf setzen. true

Meine Anwendung Node.js ist nicht instrumentiert oder generiert keine Telemetrie mit Anwendungssignalen

Um Application Signals für Node.js zu aktivieren, müssen Sie sicherstellen, dass Ihre Anwendung Node.js das CommonJS-Modulformat (CJS) verwendet. Derzeit unterstützt die AWS Distribution für OpenTelemetry Node.js 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.

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 Service Discovery-Setup aktiviert haben. Sie müssen dies 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 Start discover your services aus. Der Datenfluss sollte innerhalb von fünf Minuten beginnen.

Service- oder Abhängigkeitsmetriken haben unbekannte Werte

Wenn Sie in den Dashboards von Application Signals UnknownServiceUnknownOperationUnknownRemoteService,, oder UnknownRemoteOperationfür einen Abhängigkeitsnamen oder einen Vorgang sehen, überprüfen Sie, ob das Auftreten von Datenpunkten für den unbekannten Remote-Service und den unbekannten Remote-Vorgang 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 angegeben istOTEL_RESOURCE_ATTRIBUTES, wird der Dienstname auf gesetzt. UnknownService Um dieses Problem zu beheben, geben Sie den Dienstnamen in OTEL_SERVICE_NAME oder OTEL_RESOURCE_ATTRIBUTES an.

  • UnknownOperationbedeutet, dass der Name einer aufgerufenen Operation unbekannt ist. Dies tritt auf, wenn Application Signals nicht in der Lage ist, einen Operationsnamen zu ermitteln, der den Fernaufruf aufruft, oder wenn der extrahierte Operationsname hohe Kardinalitätswerte enthält.

  • UnknownRemoteServicebedeutet, dass der Name des Zieldienstes unbekannt ist. Dies tritt auf, wenn das System den Namen des Zieldienstes, auf den der Remoteaufruf 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. Dies tritt auf, wenn das System den Namen des Zielvorgangs, auf den der Fernaufruf 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 Traces herausfiltern

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

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

Was InternalOperation heißt das?

An InternalOperation ist eine Operation, die von der Anwendung intern und nicht durch einen externen Aufruf ausgelöst wird. Sehen InternalOperation ist erwartetes, gesundes Verhalten.

Zu den typischen Beispielen, die Sie sehen würden, InternalOperation gehören die folgenden:

  • Beim Start vorab laden — Ihre Anwendung führt einen Vorgang mit dem Namen durchloadDatafromDB, bei dem während der Aufwärmphase Metadaten aus einer Datenbank gelesen werden. Anstatt den Vorgang loadDatafromDB als Service zu beobachten, 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 InternalOperation als Dienstvorgang eingestuft.

  • Host-Informationen aus einer Service-Registry abrufen — Ihre Anwendung kommuniziert mit einer Service-Registry, um Dienste zu finden. Alle Interaktionen mit dem Discovery-System werden als InternalOperation klassifiziert.

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

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

  • OTEL_LOG_LEVEL

  • OTEL_DOTNET_AUTO_LOG_DIRECTORY

  • COREHOST_TRACE

  • COREHOST_TRACEFILE

Wie kann ich Konflikte mit Assemblyversionen 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-Logs wird noch nicht unterstützt.

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

Ihre Lambda-Funktion kann mit diesem Fehler fehlschlagen: TypeError - "Cannot redefine property: handler" wenn Sie:

  • Verwenden Sie den ADOT JavaScript Lambda Layer

  • Zum Kompilieren verwenden esbuild TypeScript

  • Exportieren Sie Ihren Handler mit dem export Schlüsselwort

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üsselwortsexport: 

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

Aktualisieren Sie auf die erforderlichen Versionen von Agenten oder 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, die älter 1.32.2 sind als, nicht unterstützt.

    • Für Python werden Versionen, die älter 0.2.0 sind als, nicht unterstützt.

    • Für .NET werden Versionen, die älter 1.3.2 sind als, nicht unterstützt.

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

Wichtig

Die neuesten Versionen der Agents enthalten Aktualisierungen des Application Signals-Metrikschemas. Diese Updates sind nicht abwärtskompatibel, und dies 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.

  • Stellen Sie bei Anwendungen, die auf anderen Plattformen ausgeführt werden, sicher, dass Sie sowohl den CloudWatch Agenten als auch den Agenten für AWS OpenTelemetry automatische Instrumentierung auf die neuesten Versionen 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 Management Console oder das AWS CLI verwenden.

Verwenden der Konsole

Um das Add-on mithilfe der Konsole zu aktualisieren

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

  2. Wählen Sie den Namen des zu aktualisierenden Amazon EKS-Clusters aus.

  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 später 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

Um Ihre Agenten für Dienste zu aktualisieren, die auf Amazon ECS ausgeführt werden

  1. Erstellen Sie eine neue Version der Aufgabendefinition. 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 eine Version verwenden, die der Version entspricht oder höher ist als. 1.300040.0

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

    • Verwenden Sie für Java adot-autoinstrumentation-javaaws-observability/.

      Wenn Sie ein Upgrade auf eine feste Version durchführen, stellen Sie sicher, dass Sie eine Version verwenden, die der Version entspricht oder eine neuere Version als ist. 1.32.2

    • Verwenden Sie für Python adot-autoinstrumentation-pythonaws-observability/.

      Wenn Sie ein Upgrade auf eine feste Version durchführen, stellen Sie sicher, dass Sie eine Version verwenden, die mindestens der Version entspricht. 0.2.0

    • Verwenden Sie für .NET adot-autoinstrumentation-dotnetaws-observability/.

      Wenn Sie ein Upgrade auf eine feste Version durchführen, stellen Sie sicher, dass Sie eine Version verwenden, die der Version entspricht oder eine neuere Version als ist. 1.3.2

    • Verwenden Sie für Node.js adot-autoinstrumentation-nodeaws-observability/.

      Wenn Sie ein Upgrade auf eine feste Version durchführen, stellen Sie sicher, dass Sie eine Version verwenden, die der Version entspricht oder eine neuere Version als ist. 0.3.0

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

  5. Stellen Sie Ihren 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. Folgen Sie den Anweisungen unter Laden Sie das CloudWatch Agentenpaket herunter und aktualisieren Sie den CloudWatch Agenten auf die neueste Version. Achten Sie darauf, Version 1.300040.0 oder höher auszuwä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 später.

    • 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 später.

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

      Wenn Sie ein Upgrade auf eine feste Version durchführen, achten Sie darauf, 1.3.2 oder später zu wählen.

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

      Wenn Sie ein Upgrade auf eine feste Version durchführen, achten Sie darauf, 0.3.0 oder später zu wählen.

  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.