Fehlerbehebung bei der Installation von Application Signals - Amazon CloudWatch
Application 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-TelemetrieKeine Anwendungsdaten im Application-Signals-DashboardServicemetriken oder Abhängigkeitsmetriken haben unbekannte WerteUmgang mit einem ConfigurationConflict bei der Verwaltung des Add-Ons von Amazon CloudWatch Observability EKSIch 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 FluentBit deaktivieren?Kann ich Container-Protokolle filtern, bevor ich sie nach CloudWatch Logs exportiere? Beheben von TypeError bei der Verwendung des JavaScript-Lambda-Layers von AWS Distro for OpenTelemetry (ADOT) Aktualisieren Sie auf die erforderlichen Versionen der Agenten oder des Amazon-EKS-Add-onsEmbedded Metric Format (EMF) ist für Application Signals deaktiviert

Fehlerbehebung bei der Installation von Application Signals

Dieser Abschnitt enthält Tipps zur Fehlerbehebung bei CloudWatch Application Signals.

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.

Kaltstartzeiten mit Provisioned Concurrency reduzieren – AWS Lambda Provisioned Concurrency weist vorab eine bestimmte Anzahl von Funktions-Instances 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.

Die Startleistung mit Lambda SnapStart optimieren – AWS Lambda SnapStart ist ein Feature, das 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 unter Verbesserung 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-Signals-Artefakte wie den Java- oder Python-Agenten von AWS Distro für OpenTelemetry und die CloudWatch-Agenten-Images 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

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 auf das EKS-Add-On Amazon CloudWatch Observability und betrifft die Versionen 2.3.0-eksbuild.1 bis 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 automatischen OpenTelemetrie-Instrumentierung, dass eine fehlende PYTHONPATH-Umgebungsvariable manchmal dazu führt, 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 auf den Speicherort der settings.py-Datei Ihrer Django-Anwendung fest. Dadurch wird sichergestellt, dass OpenTelemetry korrekt auf Ihre Django-Einstellungen zugreifen und diese integrieren kann.

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 EKS-Add-On Amazon CloudWatch Observability 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-Distro für OpenTelemetry Node.js unterstützt das ESM-Modulformat nicht, da die Unterstützung von OpenTelemetry JavaScript für ESM experimentell 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 ausgeführt wird. Ü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 Folgendes zur Konfigurationsdatei des CloudWatch-Agenten 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-Agenten-Pods nach Fehlern.

  • Überprüfen Sie, ob es Konfigurationsprobleme mit dem CloudWatch-Agenten gibt. 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 OpenTelemetrie-Debugging-Protokolle auf Fehlermeldungen, wie z. B. 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 Debugging-Protokollierung von OpenTelemetry Python zu aktivieren, setzen Sie die Umgebungsvariable OTEL_PYTHON_LOG_LEVEL auf debug und stellen Sie die Anwendung erneut bereit.

  • Prüfen Sie, ob falsche oder unzureichende Berechtigungen für den Export von Daten aus dem CloudWatch-Agenten vorliegen. Wenn Sie Access Denied-Nachrichten in den CloudWatch-Agenten-Protokollen sehen, ist dies möglicherweise das Problem. Es ist möglich, dass die Berechtigungen, die bei der Installation des CloudWatch-Agenten angewendet wurden, später geändert oder aufgehoben wurden.

  • Suchen Sie nach einem AWS Distro für OpenTelemetry (ADOT)-Problem bei der Generierung von Telemetriedaten.

    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 Debugging-Protokollierung im OpenTelemetry-Java-SDK, indem Sie die Umgebungsvariable OTEL_JAVAAGENT_DEBUG auf wahr setzen und die Anwendung erneut bereitstellen. Suchen Sie dann nach Nachrichten, die mit ERROR io.telemetry beginnen.

  • Der Metrik-/Span-Exporter verwirft 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 CloudWatch-Agenten-Protokollen nach Meldungen, die auf eine Drosselung hinweisen.

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

    Wählen Sie zur Bestätigung 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 einen Vorgang sehen, überprüfen Sie, ob das Auftreten von Datenpunkten für den unbekannten Remote-Service und den unbekannten Remote-Vorgang mit ihren Bereitstellungen übereinstimmt.

  • UnknownService bedeutet, 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.

  • UnknownOperation bedeutet, dass der Name eines aufgerufenen Vorgangs 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.

  • UnknownRemoteService bedeutet, dass der Name des Zielservices 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 ist, den CloudWatch-Agenten so zu konfigurieren, dass er den Metrikwert von RemoteService anpasst. Weitere Informationen über Anpassungen im CloudWatch-Agenten finden Sie unter CloudWatch Application Signals aktivieren.

  • UnknownRemoteOperation bedeutet, 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 ist, den CloudWatch-Agenten so zu konfigurieren, dass er den Metrikwert von RemoteOperation anpasst. Weitere Informationen über Anpassungen im CloudWatch-Agenten finden Sie unter CloudWatch Application Signals aktivieren.

Umgang mit einem ConfigurationConflict bei der Verwaltung des Add-Ons von Amazon CloudWatch Observability EKS

Wenn Sie bei der Installation oder Aktualisierung des Add-Ons von Amazon CloudWatch Observability EKS einen Fehler feststellen, der durch ein Health Issue des Typs ConfigurationConflict mit einer Beschreibung, die mit Conflicts found when trying to apply. Will not continue due to resolve conflicts mode beginnt, verursacht wird, liegt das wahrscheinlich daran, dass Sie den CloudWatch-Agenten und die zugehörigen Komponenten wie ServiceAccount, ClusterRole und ClusterRoleBinding bereits auf dem Cluster 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 die Installation oder Aktualisierung standardmäßig fehl, um zu verhindern, dass der Status der Ressourcen auf dem Cluster überschrieben wird.

Wenn Sie versuchen, das Add-On von Amazon CloudWatch Observability EKS zu integrieren und dieser Fehler auftritt, empfehlen wir, eine vorhandene CloudWatch-Agenten-Einrichtung zu löschen, die Sie möglicherweise zuvor auf dem Cluster installiert haben, und dann das EKS-Add-On zu installieren. Stellen Sie sicher, dass Sie alle Anpassungen, die Sie möglicherweise an der ursprünglichen CloudWatch-Agenten-Einrichtung vorgenommen haben, wie z. B. eine benutzerdefinierte Agentenkonfiguration, sichern und diese dem Add-On von Amazon CloudWatch Observability EKS zur Verfügung stellen, wenn Sie es das nächste Mal installieren oder aktualisieren. Wenn Sie zuvor den CloudWatch-Agenten für das Onboarding in Container Insights installiert haben, finden Sie weitere Informationen unter Löschen des CloudWatch-Agenten und Fluent Bid für Container Insights.

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 die AWS CLI verwenden, können Sie --resolve-conflicts OVERWRITE an Ihren Befehl übergeben, um das Add-On zu erstellen oder zu aktualisieren.

Ich möchte unnötige Metriken und Ablaufverfolgungsdaten herausfiltern

Wenn Application Signals unerwünschte Ablaufverfolgungsdaten und Metriken erfasst, finden Sie unter Vorgänge mit hoher Kardinalität verwalten Informationen 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 unter Problembehandlung bei Problemen mit der automatischen .NET-Instrumentierung in der OpenTelemetrie-Dokumentation.

  • 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 Assembly-Versionskonflikte eine Anleitung zur Problemlösung.

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 FluentBit deaktivieren?

Sie können FluentBit durch Konfiguration des EKS-Add-On Amazon CloudWatch Observability deaktivieren. 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.

Beheben von TypeError bei der Verwendung des JavaScript-Lambda-Layers von AWS Distro for OpenTelemetry (ADOT)

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

  • Sie verwenden den ADOT-JavaScript-Lambda-Layer

  • Sie verwenden esbuild zum Kompilieren von TypeScript

  • Sie exportieren Ihren Handler mit dem Schlüsselwort export

Der ADOT-JavaScript-Lambda-Layer muss Ihren Handler zur Laufzeit ändern. Wenn Sie das Schlüsselwort export mit esbuild verwenden (direkt oder über AWS CDK), macht esbuild Ihren Handler unveränderlich, 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 }

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 EKS-Add-ons Amazon CloudWatch Observability, des CloudWatch-Agenten und des Autoinstrumentations-Agenten von AWS Distro for OpenTelemetry nicht mehr unterstützen.

  • Für das EKS-Add-On Amazon CloudWatch Observability werden Versionen vor v1.7.0-eksbuild.1 nicht unterstützt.

  • Für den CloudWatch-Agenten werden Versionen vor 1.300040.0 nicht unterstützt.

  • Für den Autoinstrumentations-Agenten von AWS Distro for OpenTelemetry:

    • 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 ausgeführt wird, 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 Autoinstrumentations-Agenten von AWS OpenTelemetry auf die neuesten Versionen aktualisieren.

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

Das Add-On von Amazon CloudWatch Observability EKS aktualisieren

Zum Aktualisieren des Add-On von Amazon CloudWatch Observability EKS können Sie die AWS-Managementkonsole oder die 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 die Registerkarte 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 die Services 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 der AWS CLI

So aktualisieren Sie das Add-on mit der 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. Ersetzen Sie $VERSION durch v1.7.0-eksbuild.1 oder eine neuere Version. Ersetzen Sie $AWS_REGION und $CLUSTER durch Ihre Region und den Cluster-Namen.

    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 Konfiguration, die Sie für $JSON_CONFIG verwenden können, unter CloudWatch Application Signals aktivieren.

  3. Geben Sie einen der folgenden AWS CLI-Befehle ein, um Ihre Services 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

Den CloudWatch-Agenten und den ADOT-Agenten aktualisieren

Wenn Ihre Services auf anderen Architekturen als Amazon EKS ausgeführt werden, müssen Sie sowohl den CloudWatch-Agenten als auch den ADOT-Agenten für automatische Instrumentation aktualisieren, um die neuesten Features 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: Ihre Anwendung mit dem CloudWatch-Agenten instrumentieren 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, Version 1.300040.0 oder höher der CloudWatch-Agent-Version auszuwählen.

  2. Laden Sie die neueste Version des Auto-Instrumentations-Agenten von AWS Distro for OpenTelemetry 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.