

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

# Sistemi supportati
<a name="CloudWatch-Application-Signals-supportmatrix"></a>

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' CloudWatch agente e AWS Distro for. OpenTelemetry

**Topics**
+ [Compatibilità con Java](#CloudWatch-Application-Signals-supportmatrix-java)
+ [Compatibilità .NET](#CloudWatch-Application-Signals-supportmatrix-dotnet)
+ [Compatibilità PHP](#php-compatibility)
+ [Compatibilità con Ruby](#ruby-compatibility)
+ [Compatibilità con Python](#CloudWatch-Application-Signals-supportmatrix-python)
+ [Compatibilità con Node.js](#CloudWatch-Application-Signals-supportmatrix-node)
+ [GoLang compatibilità](#golang-compatibility)
+ [Tabella per il supporto della versione del runtime](#rumtime-version-matix)
+ [Problemi noti](#AppSignals-Issues)

## Compatibilità con Java
<a name="CloudWatch-Application-Signals-supportmatrix-java"></a>

Application Signals supporta le applicazioni Java e supporta le stesse librerie e framework Java di Distro for. AWS OpenTelemetry Per ulteriori informazioni, consulta [Librerie, framework, server di applicazioni supportati](https://github.com/open-telemetry/opentelemetry-java-instrumentation/blob/main/docs/supported-libraries.md) e. JVMs

## Compatibilità .NET
<a name="CloudWatch-Application-Signals-supportmatrix-dotnet"></a>

Application Signals supporta le stesse librerie e framework .NET di Distro for does. AWS OpenTelemetry Per ulteriori informazioni, consulta [ Supported instrumentations](https://github.com/open-telemetry/opentelemetry-dotnet-instrumentation/blob/main/docs/internal/instrumentation-libraries.md).

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

**Nota**  
L'SDK AWS Distro for Open Telemetry (ADOT) per .NET non supporta SDK per .NET V4. AWS Utilizza AWS SDK .NET V3 per il supporto completo di Application Signals.

## Compatibilità PHP
<a name="php-compatibility"></a>

Application Signals supporta applicazioni PHP con strumentazione Zero Code. OpenTelemetry A tale scopo non è AWS disponibile alcun SDK Distro for Open Telemetry (ADOT). [È necessario utilizzare lo standard OpenTelemetry Instrumentation SDK con Transaction Search abilitato.](AmazonCloudWatch/latest/monitoring/CloudWatch-Transaction-Search.html) [Per iniziare a utilizzare la strumentazione a codice zero in PHP, segui questi passaggi dai documenti di PHP Instrumentation, OpenTelemetry PHP zero-code instrumentation.](https://opentelemetry.io/docs/zero-code/php/) L'instrumentazione automatica è disponibile per diverse librerie PHP di uso comune. Per [OpenTelemetry ulteriori informazioni](https://packagist.org/search/?query=open-telemetry%3Dinstrumentation), consulta Registry.

## Compatibilità con Ruby
<a name="ruby-compatibility"></a>

Application Signals supporta le applicazioni Ruby con strumentazione Zero Code. OpenTelemetry A tale scopo non è AWS disponibile alcun SDK Distro for Open Telemetry (ADOT). [È necessario utilizzare lo standard OpenTelemetry Instrumentation SDK con Transaction Search abilitato.](AmazonCloudWatch/latest/monitoring/CloudWatch-Transaction-Search.html) [Per iniziare a utilizzare la strumentazione a codice zero in Ruby, segui questi passaggi dai documenti di Ruby Instrumentation, OpenTelemetry Ruby zero-code instrumentation.](https://opentelemetry.io/docs/languages/ruby/getting-started/#instrumentation) Per un elenco delle librerie di instrumentazione rilasciate, consulta [Registry](https://opentelemetry.io/ecosystem/registry/?language=rubycomponent=instrumentation). 

## Compatibilità con Python
<a name="CloudWatch-Application-Signals-supportmatrix-python"></a>

Application Signals supporta le stesse librerie e framework di Distro for does. AWS OpenTelemetry Per ulteriori informazioni, consulta Pacchetti **supportati** all'indirizzo. [ opentelemetry-python-contrib](https://github.com/open-telemetry/opentelemetry-python-contrib/blob/main/instrumentation/README.md)

Prima di abilitare Application Signals per le applicazioni Python, tieni presente le considerazioni riportate di seguito.
+ In alcune applicazioni containerizzate, l'assenza della variabile di ambiente `PYTHONPATH` può talvolta impedire l'avvio dell'applicazione. Per risolvere questo problema, assicurati di impostare la variabile di ambiente `PYTHONPATH` sulla posizione della directory di lavoro dell'applicazione. Ciò è dovuto a un problema noto con la OpenTelemetry strumentazione automatica. Per ulteriori informazioni su questo problema, consulta [Python autoinstrumentation setting of PYTHONPATH is not compliant](https://github.com/open-telemetry/opentelemetry-operator/issues/2302).
+ [Per le applicazioni Django, ci sono configurazioni aggiuntive richieste, che sono descritte nella documentazione di Python OpenTelemetry .](https://opentelemetry-python.readthedocs.io/en/latest/examples/django/README.html)
  + Usa il flag `--noreload` per impedire il ricaricamento automatico.
  + Imposta la variabile di ambiente `DJANGO_SETTINGS_MODULE` sulla posizione del file `settings.py` dell'applicazione Django. Ciò garantisce che OpenTelemetry possa accedere e integrarsi correttamente con le impostazioni di Django. 

## Compatibilità con Node.js
<a name="CloudWatch-Application-Signals-supportmatrix-node"></a>

Application Signals supporta le stesse librerie e framework Node.js di AWS Distro for does. OpenTelemetry Per ulteriori informazioni, consulta [ Supported instrumentations](https://github.com/open-telemetry/opentelemetry-js-contrib/tree/main).

### Limitazioni note di Node.js con ESM
<a name="ESM-limitations"></a>

 AWS Distro for Opentelemetry Node.js supporta due sistemi di ECMAScript moduli: Modules (ESM) e CommonJS (CJS). Per abilitare Application Signals, ti consigliamo di utilizzare il formato del modulo CJS perché il supporto di ESM è sperimentale e in OpenTelemetry JavaScript corso di elaborazione. Per maggiori dettagli, consulta [ ECMAScript Modules vs.](https://github.com/open-telemetry/opentelemetry-js/blob/eb3ca4fb07ee31c62093f5fcec56575573c902ce/doc/esm-support.md) 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](https://nodejs.org/api/esm.html#enabling) nella documentazione di Node.js.

La AWS Distro for Opentelemetry Node.js fornisce un supporto limitato per ESM in base al supporto sperimentale per ESM. OpenTelemetry JavaScript Ciò significa che:
+ La versione di Node.js deve essere 18.19.0 o successiva.
+ L'applicazione Node.js che desideri instrumentare deve includere `@aws/aws-distro-opentelemetry-node-autoinstrumentation` e `@opentelemetry/instrumentation` come dipendenze. 
+ L'applicazione Node.js che desideri instrumentare deve iniziare con la seguente opzione di nodo: 

  ```
  NODE_OPTIONS=' --import @aws/aws-distro-opentelemetry-node-autoinstrumentation/register --experimental-loader=@opentelemetry/instrumentation/hook.mjs'
  ```

Per abilitare Application Signals con il formato del modulo ESM Node.js, forniamo diverse configurazioni per diverse piattaforme:
+ **Amazon EKS** — [Configurazione di un'applicazione Node.js con il formato del modulo ESM](CloudWatch-Application-Signals-Enable-EKS.md#EKS-NodeJs-ESM)
+ **Amazon ECS con strategia sidecar**: [Setting up a Node.js application with the ESM module format](CloudWatch-Application-Signals-ECS-Sidecar.md#ECS-NodeJs-ESM)
+ **Amazon ECS con strategia daemon**: [Setting up a Node.js application with the ESM module format](CloudWatch-Application-Signals-ECS-Daemon.md#ECSDaemon-NodeJs-ESM)
+ **Amazon ECS con 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** – [Configurazione di un'applicazione Node.js con il formato del modulo ESM](CloudWatch-Application-Signals-Enable-KubernetesMain.md#Kubernetes-NodeJs-ESM)

## GoLang compatibilità
<a name="golang-compatibility"></a>

Application Signals supporta GoLang applicazioni con strumentazione Zero Code. OpenTelemetry A tale scopo non è AWS disponibile alcun SDK Distro for Open Telemetry (ADOT). [È necessario utilizzare lo standard OpenTelemetry Instrumentation SDK con Transaction Search abilitato.](AmazonCloudWatch/latest/monitoring/CloudWatch-Transaction-Search.html) [Per iniziare a utilizzare la strumentazione a codice zero in GoLang, segui questi passaggi dai documenti di Instrumentation, Guida introduttiva a Go OpenTelemetry GoLang Automatic Instrumentation. OpenTelemetry ](https://github.com/open-telemetry/opentelemetry-go-instrumentation/blob/main/docs/getting-started.md)

### Considerazioni sull'implementazione e strumentazione GoLang
<a name="implementation-considerations-golang"></a>

Scopri importanti dettagli di implementazione per l'utilizzo della strumentazione. GoLang Questa guida spiega come implementare la propagazione esplicita del contesto nelle GoLang applicazioni e configurare gli Application Signals. Una corretta implementazione della GoLang strumentazione consente di monitorare e analizzare efficacemente le prestazioni dell'applicazione.

#### Strumentazione dell'SDK AWS
<a name="instrumenting-aws-sdk"></a>

La libreria di strumentazione automatica Golang non supporta la strumentazione AWS SDK pronta all'uso. È necessario utilizzare l'instrumentazione della libreria `otelaws` insieme all'agente di instrumentazione automatica:

1. Installa la dipendenza richiesta:

   ```
   go get go.opentelemetry.io/contrib/instrumentation/github.com/aws/aws-sdk-go-v2/otelaws
   ```

1. Aggiungi la seguente linea all'applicazione:

   ```
   otelaws.AppendMiddlewares(&cfg.APIOptions)
   ```

1. Crea client successivi con l'oggetto precedente: AWS `aws.Config`

   ```
   s3Client := s3.NewFromConfig(cfg)
   ```

L'esempio seguente genererà intervalli per AWS le chiamate e si integra con la strumentazione 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](https://github.com/open-telemetry/opentelemetry-go-instrumentation/blob/main/docs/configuration.md).

#### Instrumentazione delle chiamate HTTP
<a name="instrumenting-http-calls"></a>

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 strumentazione, gli span 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
<a name="instrumenting-sql-calls"></a>

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:
+ Utilizza `QueryContext` al posto di `Query`
+ Utilizza `ExecContext` al posto di `Exec`

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
}
```

**Nota**  
L'attributo `db.system` non è attualmente supportato per le chiamate SQL. Questa limitazione influisce sulla capacità CloudWatch di identificare con precisione i client del database. Di conseguenza, verranno visualizzate le dipendenze **UnknownRemoteService**al posto del nome del client DB che effettua la query.

#### Rilevatori di risorse
<a name="resource-detectors"></a>

L'instrumentazione automatica Go attualmente non supporta la configurazione dei rilevatori di risorse in fase di runtime. La OpenTelemetry community 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, è possibile utilizzare l' CloudWatch agente con strumentazione automatica per generare automaticamente gli attributi delle risorse host.

## Tabella per il supporto della versione del runtime
<a name="rumtime-version-matix"></a>




| Lingua | Versione di runtime | 
| --- | --- | 
|  Java  |  JVM versioni 8, 11, 17, 21 e 23  | 
|  Python  |  Sono supportate le versioni di Python 3.9 e successive  | 
|  .NET  |  La versione 1.6.0 e precedenti supportano .NET 6, 8 e .NET Framework 4.6.2 e versioni successive La versione 1.7.0 e successive supportano .NET 8, 9 e .NET Framework 4.6.2 e versioni successive  | 
|  Node.js  |  Node.js versioni 14, 16, 18, 20 e 22  | 
|  PHP  |  PHP versione 8.0 e successive  | 
|  Ruby  |  CRuby >= 3.1, >= 9.3.2.0 o >= JRuby 22.1 TruffleRuby   | 
| GoLang | Golang versione 1.18 e successive | 

## Problemi noti
<a name="AppSignals-Issues"></a>

È noto che la raccolta di metriche di runtime nella versione Java SDK v1.32.5 non funziona con le applicazioni che utilizzano Wildfly. JBoss Questo problema si estende al componente aggiuntivo Amazon CloudWatch Observability EKS, interessando le versioni successive`2.3.0-eksbuild.1`. `2.6.0-eksbuild.1` Il problema è stato risolto nella versione Java SDK `v1.32.6` e nella versione aggiuntiva Amazon CloudWatch Observability EKS. `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. 