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. # Unterstützte Systeme Application Signals wird in Amazon EKS, nativem Kubernetes, Amazon ECS und Amazon EC2 unterstützt und getestet. Die Anweisungen zur Aktivierung von Application Signals auf Amazon EC2 sollten auf jeder Plattform funktionieren, die den CloudWatch Agenten und die AWS Distribution für unterstützt. OpenTelemetry **Topics** + [Java-Kompatibilität](#CloudWatch-Application-Signals-supportmatrix-java) + [.NET-Kompatibilität](#CloudWatch-Application-Signals-supportmatrix-dotnet) + [PHP-Kompatibilität](#php-compatibility) + [Ruby-Kompatibilität](#ruby-compatibility) + [Python-Kompatibilität](#CloudWatch-Application-Signals-supportmatrix-python) + [Node.js-Kompatibilität](#CloudWatch-Application-Signals-supportmatrix-node) + [GoLang Kompatibilität](#golang-compatibility) + [Laufzeitversion – Unterstützungsmatrix](#rumtime-version-matix) + [Bekannte Probleme](#AppSignals-Issues) ## Java-Kompatibilität Application Signals unterstützt Java-Anwendungen und unterstützt dieselben Java-Bibliotheken und Frameworks wie AWS Distro for. OpenTelemetry Weitere Informationen finden Sie unter [Unterstützte Bibliotheken, Frameworks, Anwendungsserver und JVMs](https://github.com/open-telemetry/opentelemetry-java-instrumentation/blob/main/docs/supported-libraries.md). ## .NET-Kompatibilität Application Signals unterstützt dieselben .NET-Bibliotheken und Frameworks wie die AWS Distribution for OpenTelemetry . Weitere Informationen finden Sie unter [Unterstützte Instrumentierungen](https://github.com/open-telemetry/opentelemetry-dotnet-instrumentation/blob/main/docs/internal/instrumentation-libraries.md). Application Signals unterstützt .NET-Anwendungen, die auf x86-64 oder ausgeführt werden ARM64 CPUs, und unterstützt Linux x64 ARM64, Linux und Microsoft Windows Server 2022 x64. **Anmerkung** 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. ## PHP-Kompatibilität Application Signals unterstützt PHP-Anwendungen mit OpenTelemetry Zero-Code-Instrumentierung. Für diesen Zweck ist kein SDK für AWS Distro for Open Telemetry (ADOT) verfügbar. Sie sollten das standardmäßige OpenTelemetry Instrumentierungs-SDK mit aktivierter [Transaktionssuche](AmazonCloudWatch/latest/monitoring/CloudWatch-Transaction-Search.html) verwenden. Um mit der Verwendung der Zero-Code-Instrumentierung in PHP zu beginnen, folgen Sie diesen Schritten aus den OpenTelemetry PHP-Instrumentierungsdokumenten, [PHP-Zero-Code-Instrumentierung](https://opentelemetry.io/docs/zero-code/php/). Die automatische Instrumentierung ist für eine Reihe häufig verwendeter PHP-Bibliotheken verfügbar. [Weitere Informationen finden Sie unter OpenTelemetry Registrierung.](https://packagist.org/search/?query=open-telemetry%3Dinstrumentation) ## Ruby-Kompatibilität Application Signals unterstützt Ruby-Anwendungen mit OpenTelemetry Zero-Code-Instrumentierung. Für diesen Zweck ist kein SDK für AWS Distro for Open Telemetry (ADOT) verfügbar. Sie sollten das standardmäßige OpenTelemetry Instrumentierungs-SDK mit aktivierter [Transaktionssuche](AmazonCloudWatch/latest/monitoring/CloudWatch-Transaction-Search.html) verwenden. Um mit der Verwendung der Zero-Code-Instrumentierung in Ruby zu beginnen, folgen Sie diesen Schritten aus der OpenTelemetry Ruby-Instrumentierungsdokumentation, [Ruby-Zero-Code-Instrumentierung](https://opentelemetry.io/docs/languages/ruby/getting-started/#instrumentation). Eine Liste der veröffentlichten Instrumentierungsbibliotheken finden Sie unter [Registry](https://opentelemetry.io/ecosystem/registry/?language=rubycomponent=instrumentation). ## Python-Kompatibilität Application Signals unterstützt dieselben Bibliotheken und Frameworks wie die AWS Distribution for. OpenTelemetry Weitere Informationen finden Sie unter **Unterstützte Pakete** unter [ opentelemetry-python-contrib](https://github.com/open-telemetry/opentelemetry-python-contrib/blob/main/instrumentation/README.md). Bevor Sie Application Signals für Ihre Python-Anwendungen aktivieren, sollten Sie die folgenden Punkte beachten. + In einigen containerisierten Anwendungen kann eine fehlende `PYTHONPATH`-Umgebungsvariable manchmal dazu führen, 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. Dies ist auf ein bekanntes Problem mit der OpenTelemetry automatischen Instrumentierung zurückzuführen. Weitere Informationen zu diesem Problem finden Sie unter [Python-Autoinstrumentierungs-Einstellung von PYTHONPATH ist nicht kompatibel](https://github.com/open-telemetry/opentelemetry-operator/issues/2302). + Für Django-Anwendungen sind zusätzliche Konfigurationen erforderlich, die in der [ OpenTelemetry Python-Dokumentation](https://opentelemetry-python.readthedocs.io/en/latest/examples/django/README.html) 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. ## Node.js-Kompatibilität Application Signals unterstützt dieselben Node.js Bibliotheken und Frameworks wie AWS Distro for OpenTelemetry . Weitere Informationen finden Sie unter [Unterstützte Instrumentierungen](https://github.com/open-telemetry/opentelemetry-js-contrib/tree/main). ### Bekannte Einschränkungen von Node.js mit ESM Die AWS Distribution für Opentelemetry Node.js unterstützt zwei Modulsysteme: ECMAScript Modules (ESM) und CommonJS (CJS). Um Application Signals zu aktivieren, empfehlen wir, das CJS-Modulformat zu verwenden, da die Unterstützung von ESM experimentell OpenTelemetry JavaScript ist und noch in Arbeit ist. Weitere Informationen finden Sie unter [ ECMAScript Module im Vergleich zu CommonJS](https://github.com/open-telemetry/opentelemetry-js/blob/eb3ca4fb07ee31c62093f5fcec56575573c902ce/doc/esm-support.md) auf. GitHub 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. Weitere Informationen zu diesen Bedingungen finden Sie in der Node.js-Dokumentation unter [Aktivieren](https://nodejs.org/api/esm.html#enabling). Die AWS Distribution für Opentelemetry Node.js bietet begrenzte Unterstützung für ESM, basierend auf OpenTelemetry JavaScript der experimentellen Unterstützung für ESM. Das bedeutet: + Die Node.js-Version muss mindestens 18.19.0 sein. + Die Node.js-Anwendung, die Sie instrumentieren möchten, muss die Abhängigkeiten `@aws/aws-distro-opentelemetry-node-autoinstrumentation` und `@opentelemetry/instrumentation` enthalten. + Die Node.js-Anwendung, die Sie instrumentieren möchten, muss mit der folgenden Knotenoption beginnen: ``` NODE_OPTIONS=' --import @aws/aws-distro-opentelemetry-node-autoinstrumentation/register --experimental-loader=@opentelemetry/instrumentation/hook.mjs' ``` Um Application Signals mit dem Node.js-ESM-Modulformat zu aktivieren, bieten wir verschiedene Setups für verschiedene Plattformen: + **Amazon EKS** — [Einrichten einer Node.js-Anwendung mit dem ESM-Modulformat](CloudWatch-Application-Signals-Enable-EKS.md#EKS-NodeJs-ESM) + **Amazon ECS mit Sidecar-Strategie** – [Setting up a Node.js application with the ESM module format](CloudWatch-Application-Signals-ECS-Sidecar.md#ECS-NodeJs-ESM) + **Amazon ECS mit Daemon-Strategie** – [Setting up a Node.js application with the ESM module format](CloudWatch-Application-Signals-ECS-Daemon.md#ECSDaemon-NodeJs-ESM) + **Amazon ECS mit AWS CDK** + **Amazon EC2** — [Setting up a Node.js application with the ESM module format](CloudWatch-Application-Signals-Enable-EC2Main.md#EC2-NodeJs-ESM) + **Kubernetes** – [Einrichten einer Node.js-Anwendung mit dem ESM-Modulformat](CloudWatch-Application-Signals-Enable-KubernetesMain.md#Kubernetes-NodeJs-ESM) ## GoLang Kompatibilität Application Signals unterstützt GoLang Anwendungen mit OpenTelemetry Zero-Code-Instrumentierung. Für diesen Zweck ist kein SDK für AWS Distro for Open Telemetry (ADOT) verfügbar. Sie sollten das standardmäßige OpenTelemetry Instrumentierungs-SDK mit aktivierter [Transaktionssuche](AmazonCloudWatch/latest/monitoring/CloudWatch-Transaction-Search.html) verwenden. Um mit der Verwendung der Null-Code-Instrumentierung in zu beginnen GoLang, folgen Sie diesen Schritten aus der OpenTelemetry GoLang Instrumentierungsdokumentation „[Erste Schritte mit OpenTelemetry Go Automatic Instrumentation](https://github.com/open-telemetry/opentelemetry-go-instrumentation/blob/main/docs/getting-started.md)“. ### Überlegungen zur Implementierung, GoLang Instrumentierung Erfahren Sie mehr über wichtige Implementierungsdetails für die Verwendung von GoLang Instrumentierung. In dieser Anleitung wird erklärt, wie die explizite Kontextweiterleitung in GoLang Anwendungen implementiert und Anwendungssignale eingerichtet werden. Durch die korrekte Implementierung der GoLang Instrumentierung können Sie die Leistung Ihrer Anwendung effektiv verfolgen und analysieren. #### Instrumentierung des SDK AWS Die Golang-Bibliothek für automatische Instrumentierung unterstützt standardmäßig keine AWS SDK-Instrumentierung. Sie müssen die `otelaws`-Bibliotheksinstrumentierung zusammen mit dem Agenten für die automatische Instrumentierung verwenden: 1. Installieren Sie die erforderliche Abhängigkeit: ``` go get go.opentelemetry.io/contrib/instrumentation/github.com/aws/aws-sdk-go-v2/otelaws ``` 1. Fügen Sie der Anwendung den folgenden Code hinzu: ``` otelaws.AppendMiddlewares(&cfg.APIOptions) ``` 1. Erstellen Sie nachfolgende AWS Clients mit dem vorherigen `aws.Config` Objekt: ``` s3Client := s3.NewFromConfig(cfg) ``` Das folgende Beispiel generiert Spans für AWS Anrufe und integriert die automatische Instrumentierung. ``` func handleRequest(ctx context.Context) error { cfg, err := config.LoadDefaultConfig(ctx) if err != nil { return err } // Add OpenTelemetry instrumentation middleware to the AWS config otelaws.AppendMiddlewares(&cfg.APIOptions) // Create S3 client with the instrumented config s3Client := s3.NewFromConfig(cfg) // Now any operations with this client will be traced // with the context from the upstream call _, err = s3Client.ListBuckets(ctx, &s3.ListBucketsInput{}) return err } ``` Informationen zum Konfigurieren der ausführbaren Datei für die automatische Instrumentierung finden Sie unter [Konfigurationsmethoden](https://github.com/open-telemetry/opentelemetry-go-instrumentation/blob/main/docs/configuration.md). #### Instrumentieren von HTTP-Aufrufen HTTP-Aufrufe können Traces aufteilen, wenn zwischen Anforderungen kein Kontext übergeben wird – HTTP-Clients müssen `NewRequestWithContext()` statt `NewRequest()` verwenden, um sicherzustellen, dass der nachgelagerte Service denselben Kontext verwendet. Wenn beide Dienste über Instrumentierungsagenten verfügen, stellen die Spans aus Gründen der Transparenz eine Verbindung mit derselben Trace-ID her. end-to-end ``` func makeDownstreamCall(ctx context.Context, url string) ([]byte, error) { client := &http.Client{} // Create request with context from the upstream call req, err := http.NewRequestWithContext(ctx, http.MethodGet, url, nil) if err != nil { return nil, err } // Execute the request resp, err := client.Do(req) if err != nil { return nil, err } defer resp.Body.Close() } ``` #### Instrumentieren von SQL-Aufrufen SQL-Spans können von ihrem übergeordneten Span getrennt werden, wodurch Client-Aufrufe als Server-Spans abgeleitet werden. Dies tritt auf, wenn SQL-Aufrufe von ihren vorgelagerten Handlern keinen Kontext erhalten. Standard-SQL-Aufrufe wie `Query` und `Exec` verwenden standardmäßig `context.Background()` und nicht den Kontext des vorgelagerten Aufrufers. Ersetzen Sie Standard-SQL-Aufrufe durch ihre kontextbezogenen Entsprechungen: + Verwenden Sie `QueryContext` anstelle von `Query`. + Verwenden Sie `ExecContext` anstelle von `Exec`. Diese Methoden übergeben den vorgelagerten Anforderungskontext an die DB-Aufrufe und sorgen so für eine korrekte Trace-Kontinuität. ``` func queryDatabase(ctx context.Context, db *sql.DB, userID string) (*sql.Rows, error) { // This breaks the trace context // row := db.Query("SELECT name FROM users WHERE id = $1", userID) // This passes the context from the upstream call for trace continuity rows, err := db.QueryContext(ctx, "SELECT name FROM users WHERE id = $1", userID) return rows, error } ``` **Anmerkung** Das `db.system`-Attribut wird für SQL-Aufrufe derzeit nicht unterstützt. Diese Einschränkung beeinträchtigt die CloudWatch Fähigkeit, Datenbankclients genau zu identifizieren. Infolgedessen werden Abhängigkeiten **UnknownRemoteService**anstelle des Namens des DB-Clients angezeigt, der die Abfrage durchführt. #### Ressourcendetektoren Die automatische Go-Instrumentierung unterstützt derzeit keine Konfiguration von Ressourcendetektoren zur Laufzeit. Die OpenTelemetry Community arbeitet an einer Funktion zur Konfiguration von Ressourcendetektoren mithilfe von Umgebungsvariablen. Diese Funktion sollte in einem künftigen Update verfügbar sein. In der Zwischenzeit können Sie den CloudWatch Agenten mit automatischer Instrumentierung verwenden, um automatisch Host-Ressourcenattribute zu generieren. ## Laufzeitversion – Unterstützungsmatrix | Sprache | Laufzeitversion | | --- | --- | | Java | JVM-Versionen 8, 11, 17, 21 und 23 | | Python | Python-Versionen 3.9 und höher werden unterstützt | | .NET | Version 1.6.0 und niedriger unterstützt .NET 6, 8 und .NET Framework ab Version 4.6.2 Version 1.7.0 und höher unterstützt .NET 8, 9 und .NET Framework ab Version 4.6.2 | | Node.js | Node.js-Versionen 14, 16, 18, 20 und 22 | | PHP | PHP ab Version 8.0 | | Ruby | CRuby >= 3.1, >= JRuby 9.3.2.0 oder >= 22.1 TruffleRuby | | GoLang | GoLang ab Version 1.18 | ## 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` bis`2.6.0-eksbuild.1`. Das Problem wurde in der Java SDK-Version `v1.32.6` und der Amazon CloudWatch Observability EKS-Add-On-Version `v3.0.0-eksbuild.1` behoben. Wenn Sie betroffen sind, aktualisieren Sie entweder die Java-SDK-Version oder deaktivieren Sie die Erfassung von Laufzeitmetriken, indem Sie Ihrer Anwendung die Umgebungsvariable `OTEL_AWS_APPLICATION_SIGNALS_RUNTIME_ENABLED=false` hinzufügen.