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 auf Amazon EKS, nativem Kubernetes, Amazon ECS und Amazon unterstützt und getestet. EC2 Die Anweisungen zur Aktivierung von Application Signals auf Amazon EC2 sollten auf jeder Plattform funktionieren, die den CloudWatch Agenten und AWS Distro für OpenTelemetry unterstützt.

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.

.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 Instrumentationen.

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.

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 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. Automatische Instrumentierung ist für eine Reihe häufig verwendeter PHP-Bibliotheken verfügbar. Weitere Informationen finden Sie unter OpenTelemetry Registrierung.

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 verwenden. Um mit der Verwendung der Zero-Code-Instrumentierung in Ruby zu beginnen, folgen Sie diesen Schritten aus den OpenTelemetry Ruby-Instrumentierungsdokumenten, Ruby-Zero-Code-Instrumentierung. Eine Liste der veröffentlichten Instrumentierungsbibliotheken finden Sie unter Registry.

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.

Bevor Sie Application Signals für Ihre Python-Anwendungen aktivieren, sollten Sie die folgenden Überlegungen beachten.

Kompatibilität mit Node.js

Application Signals unterstützt dieselben Node.js Bibliotheken und Frameworks wie die AWS Distribution for OpenTelemetry . Weitere Informationen finden Sie unter Unterstützte Instrumentierungen.

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 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 unter Enabling in der Dokumentation zu Node.js.

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 Folgendes:

Um Application Signals mit dem ESM-Modulformat Node.js zu aktivieren, bieten wir verschiedene Setups für verschiedene Plattformen an:

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 verwenden. Um mit der Verwendung der Zero-Code-Instrumentierung in zu beginnen GoLang, folgen Sie diesen Schritten aus der OpenTelemetry GoLang Instrumentierungsdokumentation „Erste Schritte mit OpenTelemetry Go Automatic Instrumentation“.

Ü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 automatische Instrumentierung verwenden:

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 zur Konfiguration der ausführbaren Datei mit automatischer Instrumentierung finden Sie unter Konfigurationsmethoden.

Instrumentierung von HTTP-Aufrufen

HTTP-Aufrufe können Traces aufteilen, wenn kein Kontext zwischen Anfragen weitergegeben wird. HTTP-Clients müssen NewRequestWithContext() stattdessen verwendenNewRequest(), um sicherzustellen, dass der nachgelagerte Dienst denselben Kontext verwendet. Wenn beide Dienste über Instrumentierungsagenten verfügen, stellen die Spans aus Gründen der end-to-end Transparenz eine Verbindung mit derselben Trace-ID her.

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 Bereich getrennt werden, was dazu führt, dass Client-Aufrufe als Server-Spans abgeleitet werden. Dies tritt auf, wenn SQL-Aufrufe den Kontext nicht von ihren Upstream-Handlern erhalten. Standard-SQL-Aufrufe mögen Query und Exec verwenden context.Background() standardmäßig nicht den Kontext des Upstream-Aufrufers. Ersetzen Sie Standard-SQL-Aufrufe durch ihre kontextsensitiven Entsprechungen:

Diese Methoden übergeben den Upstream-Anforderungskontext an die DB-Aufrufe und sorgen so für eine korrekte Ablaufkontinuitä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
}

Ressourcendetektoren

Die automatische Go-Instrumentierung unterstützt derzeit nicht die Konfiguration von Ressourcendetektoren zur Laufzeit. Die OpenTelemetry Community arbeitet an einer Funktion zur Konfiguration von Ressourcendetektoren mithilfe von Umgebungsvariablen. Halten Sie in einem future Update nach dieser Funktion Ausschau. In der Zwischenzeit können Sie den CloudWatch Agenten mit automatischer Instrumentierung verwenden, um automatisch Host-Ressourcenattribute zu generieren.

Matrix zur Unterstützung der Runtime-Version

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.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 Ihrer Laufzeitmetriken, indem Sie Ihrer Anwendung die Umgebungsvariable OTEL_AWS_APPLICATION_SIGNALS_RUNTIME_ENABLED=false hinzufügen.