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

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. Die 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 der OpenTelemetry Ruby-Instrumentierungsdokumentation, 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 Punkte beachten.

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.

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

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:

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

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 Null-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 die 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 zum Konfigurieren der ausführbaren Datei für die automatische Instrumentierung finden Sie unter Konfigurationsmethoden.

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:

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
}

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

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