Sistemi supportati

Application Signals è supportato e testato su Amazon EKS, Kubernetes nativo, Amazon ECS e Amazon EC2. Le istruzioni per abilitare Application Signals su Amazon EC2 dovrebbero funzionare su qualsiasi piattaforma che supporti l'agente CloudWatch e AWS Distro per OpenTelemetry.

Compatibilità con Java

Application Signals supporta le applicazioni Java e le stesse librerie e framework Java di AWS Distro per OpenTelemetry. Per ulteriori informazioni, consulta Librerie, framework, server di applicazioni e JVM supportati.

Compatibilità .NET

Application Signals supporta le stesse librerie e framework .NET di AWS Distro per OpenTelemetry. Per ulteriori informazioni, consulta Supported instrumentations.

Application Signals supporta applicazioni .NET in esecuzione su CPU x86-64 o ARM64 e supporta Linux x64, Linux ARM64 e Microsoft Windows Server 2022 x64.

Compatibilità PHP

Application Signals supporta applicazioni PHP con instrumentazione OpenTelemetry Zero Code. A tale scopo non è disponibile alcun SDK AWS Distro per Open Telemetry (ADOT). È necessario utilizzare l'SDK standard di OpenTelemetry Instrumentation con Transaction Search abilitato. Per iniziare a utilizzare l'instrumentazione a codice zero in PHP, segui questi passaggi dalla documentazione di instrumentazione PHP di OpenTelemetry, PHP zero-code instrumentation. L'instrumentazione automatica è disponibile per diverse librerie PHP di uso comune. Per ulteriori informazioni, consulta OpenTelemetry registry.

Compatibilità con Ruby

Application Signals supporta le applicazioni Ruby con instrumentazione OpenTelemetry Zero Code. A tale scopo non è disponibile alcun SDK AWS Distro per Open Telemetry (ADOT). È necessario utilizzare l'SDK standard di OpenTelemetry Instrumentation con Transaction Search abilitato. Per iniziare a utilizzare l'instrumentazione a codice zero in Ruby, segui questi passaggi dalla documentazione di instrumentazione Ruby di OpenTelemetry, Ruby zero-code instrumentation. Per un elenco delle librerie di instrumentazione rilasciate, consulta Registry.

Compatibilità con Python

Application Signals supporta le stesse librerie e framework di AWS Distro per OpenTelemetry. Per ulteriori informazioni, consulta Supported packages sulla pagina opentelemetry-python-contrib.

Prima di abilitare Application Signals per le applicazioni Python, tieni presente le considerazioni riportate di seguito.

Compatibilità con Node.js

Application Signals supporta le stesse librerie e framework Node.js di AWS Distro per OpenTelemetry. Per ulteriori informazioni, consulta Supported instrumentations.

Limitazioni note di Node.js con ESM

AWS Distro per OpenTelemetry Node.js supporta due sistemi di moduli: ECMAScript Modules (ESM) e CommonJS (CJS). Per abilitare Application Signals, ti consigliamo di utilizzare il formato del modulo CJS poiché il supporto di OpenTelemetry JavaScript per ESM è sperimentale e ancora in fase di sviluppo. Per maggiori dettagli, consulta ECMAScript Modules vs. CommonJS su GitHub.

Per determinare se la tua applicazione utilizza CJS e non ESM, assicurati che non soddisfi le condizioni per abilitare ESM. Per ulteriori informazioni su queste condizioni, consulta Enabling nella documentazione di Node.js.

AWS Distro per OpenTelemetry Node.js fornisce un supporto limitato per ESM basato sul supporto sperimentale di OpenTelemetry JavaScript per ESM. Ciò significa che:

Per abilitare Application Signals con il formato del modulo ESM Node.js, forniamo diverse configurazioni per diverse piattaforme:

Compatibilità con GoLang

Application Signals supporta le applicazioni GoLang con instrumentazione OpenTelemetry Zero Code. A tale scopo non è disponibile alcun SDK AWS Distro per Open Telemetry (ADOT). È necessario utilizzare l'SDK standard di OpenTelemetry Instrumentation con Transaction Search abilitato. Per iniziare a utilizzare l'instrumentazione a codice zero in GoLang, segui questi passaggi nella documentazione di instrumentazione GoLang di OpenTelemetry, Getting Started with OpenTelemetry Go Automatic Instrumentation.

Considerazioni di implementazione per l'istrumentazione in GoLang

Scopri importanti dettagli relativi all'implementazione per l'utilizzo dell'instrumentazione GoLang. Questa guida spiega come implementare la propagazione contestuale esplicita nelle applicazioni GoLang e configurare Application Signals. L'implementazione corretta dell'instrumentazione GoLang consente di tracciare e analizzare efficacemente le prestazioni dell'applicazione.

Instrumentazione dell'SDK AWS

La libreria di instrumentazione automatica Golang non supporta nativamente l'instrumentazione dell'SDK AWS. È necessario utilizzare l'instrumentazione della libreria otelaws insieme all'agente di instrumentazione automatica:

L'esempio seguente genererà intervalli per le chiamate AWS e si integra con l'instrumentazione automatica.

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
}

Per informazioni sulla configurazione dell'eseguibile di instrumentazione automatica, consulta Configuration methods.

Instrumentazione delle chiamate HTTP

Le chiamate HTTP possono dividere le tracce quando il contesto non viene passato tra le richieste: i client HTTP devono utilizzare NewRequestWithContext() invece di NewRequest() per garantire che il servizio downstream utilizzi lo stesso contesto. Quando entrambi i servizi dispongono di agenti di instrumentazione, gli intervalli si connettono allo stesso ID di traccia per fornire visibilità 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()
}

Instrumentazione delle chiamate SQL

Gli intervalli SQL possono disconnettersi dall'intervallo principale, facendo sì che le chiamate del client vengano dedotte come intervalli del server. Ciò si verifica quando le chiamate SQL non ricevono il contesto dai rispettivi gestori a monte. Le chiamate SQL standard come Query e Exec utilizzano context.Background() per impostazione predefinita, non il contesto di chi effettua la chiamata a monte. Sostituisci le chiamate SQL standard con i loro equivalenti sensibili al contesto:

Questi metodi passano il contesto della richiesta a monte alle chiamate DB, mantenendo la corretta continuità di traccia.

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
}

Rilevatori di risorse

L'instrumentazione automatica Go attualmente non supporta la configurazione dei rilevatori di risorse in fase di runtime. La community di OpenTelemetry sta lavorando a una funzionalità per configurare i rilevatori di risorse utilizzando variabili di ambiente. Cerca questa funzionalità in uno dei prossimi aggiornamenti. Nel frattempo, puoi utilizzare CloudWatch Agent con instrumentazione automatica per generare automaticamente gli attributi delle risorse host.

Tabella per il supporto della versione del runtime

Problemi noti

È noto che la raccolta delle metriche di runtime nella versione dell'SDK Java v1.32.5 non funziona con le applicazioni che utilizzano JBoss Wildfly. Questo problema si estende al componente aggiuntivo Amazon CloudWatch Observability EKS e riguarda le versioni da 2.3.0-eksbuild.1 a 2.6.0-eksbuild.1. Questo problema è risolto nell'SDK per Java versione v1.32.6 e nel componente aggiuntivo Amazon CloudWatch Observability EKS versione v3.0.0-eksbuild.1.

Se riscontri problemi, esegui l'upgrade della versione dell'SDK per Java o disabilita la raccolta delle metriche di runtime aggiungendo la variabile di ambiente OTEL_AWS_APPLICATION_SIGNALS_RUNTIME_ENABLED=false all'applicazione.