Opzioni di configurazione: Application Insights di Monitoraggio di Azure per Java

Questo articolo mostra come configurare Application Insights di Monitoraggio di Azure per Java.

Stringa di connessione e nome del ruolo

La stringa di connessione e il nome del ruolo sono le impostazioni più comuni necessarie per iniziare:

{
  "connectionString": "...",
  "role": {
    "name": "my cloud role name"
  }
}

La stringa di connessione è obbligatoria. Il nome del ruolo è importante ogni volta che si inviano dati da applicazioni diverse alla stessa risorsa di Application Insights.

Altre informazioni e opzioni di configurazione sono disponibili nelle sezioni seguenti.

Configurazione JSON

Configurazione predefinita

Per impostazione predefinita, Application Insights Java 3 prevede che il file di configurazione sia denominato applicationinsights.json e che si trovi nella stessa directory di applicationinsights-agent-3.6.2.jar.

Configurazioni alternative

File di configurazione personalizzato

È possibile specificare un file di configurazione personalizzato con

• la variabile di ambiente APPLICATIONINSIGHTS_CONFIGURATION_FILE o
• proprietà applicationinsights.configuration.file system

Se si specifica un percorso relativo, verrà risolto in relazione alla directory in cui si trova applicationinsights-agent-3.6.0.jar.

Configurazione JSON

Anziché usare un file di configurazione, è possibile impostare l'intera configurazione JSON con:

• la variabile di ambiente APPLICATIONINSIGHTS_CONFIGURATION_CONTENT o
• proprietà di sistema applicationinsights.configuration.content

Stringa di connessione

La stringa di connessione è obbligatoria. È possibile trovare la stringa di connessione nella risorsa di Application Insights.

{
  "connectionString": "..."
}

È anche possibile impostare la stringa di connessione usando la variabile di ambiente APPLICATIONINSIGHTS_CONNECTION_STRING. Ha quindi la precedenza sulla stringa di connessione specificata nella configurazione JSON.

In alternativa, è possibile impostare la stringa di connessione usando la proprietà di sistema Java applicationinsights.connection.string. Ha anch'essa la precedenza sulla stringa di connessione specificata nella configurazione JSON.

È anche possibile impostare la stringa di connessione specificando un file da cui caricare la stringa di connessione.

Se si specifica un percorso relativo, viene risolto in relazione alla directory in cui si trova applicationinsights-agent-3.6.2.jar.

{
  "connectionString": "${file:connection-string-file.txt}"
}

Il file deve contenere solo la stringa di connessione e nient'altro.

Non impostando la stringa di connessione viene disabilitato l'agente Java.

Se sono state distribuite più applicazioni nella stessa Java Virtual Machine (JVM) e si vuole che inviino dati di telemetria a stringhe di connessione diverse, vedere Override della stringa di connessione (anteprima).

Nome del ruolo cloud

Il nome del ruolo cloud viene usato per etichettare il componente sulla mappa dell'applicazione.

Se si desidera impostare il nome del ruolo cloud:

{
  "role": {   
    "name": "my cloud role name"
  }
}

Se il nome del ruolo cloud non è impostato, per etichettare il componente nella mappa dell'applicazione viene usato il nome della risorsa di Application Insights.

È anche possibile impostare il nome del ruolo cloud usando la variabile di ambiente APPLICATIONINSIGHTS_ROLE_NAME. Ha quindi la precedenza sul nome del ruolo cloud specificato nella configurazione JSON.

In alternativa, è possibile impostare il nome del ruolo cloud usando la proprietà di sistema Java applicationinsights.role.name. Ha anch'esso la precedenza sul nome del ruolo cloud specificato nella configurazione JSON.

Se sono state distribuite più applicazioni nella stessa JVM e si vuole che inviino dati di telemetria a stringhe di connessione diverse, vedere Override del nome del ruolo cloud (anteprima).

Istanza del ruolo del cloud

Per impostazione predefinita, l'istanza del ruolo cloud è il nome del computer.

Se si vuole impostare l'istanza del ruolo cloud su un valore diverso rispetto al nome del computer:

{
  "role": {
    "name": "my cloud role name",
    "instance": "my cloud role instance"
  }
}

È anche possibile impostare l'istanza del ruolo cloud usando la variabile di ambiente APPLICATIONINSIGHTS_ROLE_INSTANCE. Ha quindi la precedenza sull'istanza del ruolo cloud specificato nella configurazione JSON.

In alternativa, è possibile impostare l'istanza del ruolo cloud usando la proprietà di sistema Java applicationinsights.role.instance. Ha anch'esso la precedenza sull'istanza del ruolo cloud specificato nella configurazione JSON.

Campionamento

Nota

Il campionamento può essere un ottimo modo per ridurre il costo di Application Insights. Assicurarsi di configurare la configurazione di campionamento in modo appropriato per il caso d'uso.

Il campionamento è basato sulla richiesta, il che significa che se una richiesta viene acquisita (campionata), lo sono anche i relativi log, dipendenze ed eccezioni.

Il campionamento si basa anche sull'ID traccia per garantire decisioni di campionamento coerenti nei diversi servizi.

Il campionamento si applica solo ai log all'interno di una richiesta. I log che non si trovano all'interno di una richiesta (ad esempio, i log di avvio) vengono sempre raccolti per impostazione predefinita. Se si desidera campionare tali log, è possibile usare override di campionamento.

Campionamento con frequenza limitata

A partire dalla versione 3.4.0 è disponibile il campionamento con frequenza limitata, che costituisce ora il valore predefinito.

Se non è configurato alcun campionamento, l'impostazione predefinita è attualmente il campionamento con frequenza limitata per acquisire al massimo (circa) cinque richieste al secondo, insieme a tutte le dipendenze e tutti i log di tali richieste.

Questa configurazione sostituisce l'impostazione predefinita precedente, che acquisiva tutte le richieste. Se si desidera comunque acquisire tutte le richieste, usare il campionamento a percentuale fissa e impostare la percentuale di campionamento su 100.

Nota

Il campionamento con frequenza limitata è approssimativo perché internamente deve adattare una percentuale di campionamento "fissa" nel tempo per generare conteggi accurati degli elementi in ogni record di telemetria. Internamente, il campionamento con frequenza limitata viene ottimizzato per adattarsi rapidamente (0,1 secondi) ai nuovi carichi delle applicazioni. Per questo motivo, non si dovrebbe veder superare di molto o per molto tempo la frequenza configurata.

Questo esempio illustra come impostare il campionamento per acquisire al massimo (approssimativamente) una richiesta al secondo:

{
  "sampling": {
    "requestsPerSecond": 1.0
  }
}

requestsPerSecond può essere un decimale, quindi può essere configurato in modo da acquisire meno di una richiesta al secondo, se necessario. Ad esempio, un valore 0.5 indica l'acquisizione di al massimo una richiesta ogni 2 secondi.

È anche possibile impostare la percentuale di campionamento usando la variabile di ambiente APPLICATIONINSIGHTS_SAMPLING_REQUESTS_PER_SECOND. Ha quindi la precedenza sul limite di frequenza specificato nella configurazione JSON.

Campionamento con percentuale fissa

Questo esempio mostra come impostare il campionamento in modo da acquisire circa un terzo di tutte le richieste:

{
  "sampling": {
    "percentage": 33.333
  }
}

È anche possibile impostare la percentuale di campionamento usando la variabile di ambiente APPLICATIONINSIGHTS_SAMPLING_PERCENTAGE. Ha quindi la precedenza sulla percentuale di campionamento specificata nella configurazione JSON.

Nota

Come percentuale di campionamento, sceglierne una vicina a 100/N dove N è un numero intero. Attualmente il campionamento non supporta altri valori.

Override del campionamento

Gli override di campionamento consentono di eseguire l'override della percentuale di campionamento predefinita. È ad esempio possibile:

• Impostare la percentuale di campionamento su 0 o su un valore ridotto per i controlli di integrità eccessivi.
• Impostare la percentuale di campionamento su 0 o su un valore ridotto per le chiamate di dipendenza eccessive.
• Impostare la percentuale di campionamento su 100 per un tipo di richiesta importante. Ad esempio, è possibile usare /login anche se il campionamento predefinito è configurato su un valore inferiore.

Per altre informazioni, vedere la documentazione Override di campionamento.

Metriche delle estensioni di gestione Java

Per raccogliere altre metriche delle estensioni di gestione Java (JMX):

{
  "jmxMetrics": [
    {
      "name": "JVM uptime (millis)",
      "objectName": "java.lang:type=Runtime",
      "attribute": "Uptime"
    },
    {
      "name": "MetaSpace Used",
      "objectName": "java.lang:type=MemoryPool,name=Metaspace",
      "attribute": "Usage.used"
    }
  ]
}

Nell'esempio di configurazione precedente:

• name è il nome della metrica assegnato a questa metrica JMX (può essere di qualsiasi tipo).
• objectName è il nome oggetto di JMX MBean che si desidera raccogliere. È supportato l'asterisco carattere jolly (*).
• attribute è il nome dell'attributo all'interno di JMX MBean da raccogliere.

Sono supportati i valori delle metriche JMX numeriche e booleane. Le metriche JMX booleane vengono mappate a 0 per false e 1 per true.

Per altre informazioni, vedere la documentazione Metriche JMX.

Dimensioni personalizzate

Per aggiungere dimensioni personalizzate a tutti i dati di telemetria:

{
  "customDimensions": {
    "mytag": "my value",
    "anothertag": "${ANOTHER_VALUE}"
  }
}

È possibile usare ${...} per leggere il valore dalla variabile di ambiente specificata all'avvio.

Nota

A partire dalla versione 3.0.2, se si aggiunge una dimensione personalizzata denominata service.version, il valore viene archiviato nella colonna application_Version nella tabella Log di Application Insights anziché come dimensione personalizzata.

Attributo ereditato (anteprima)

A partire dalla versione 3.2.0, è possibile impostare una dimensione personalizzata a livello di codice nei dati di telemetria delle richieste. Garantisce l'ereditarietà in base ai dati di telemetria delle dipendenze e dei log. Tutti vengono acquisiti nel contesto di tale richiesta.

{
  "preview": {
    "inheritedAttributes": [
      {
        "key": "mycustomer",
        "type": "string"
      }
    ]
  }
}

Quindi all'inizio di ogni richiesta, chiamare:

Span.current().setAttribute("mycustomer", "xyz");

Vedere anche: Aggiungere una proprietà personalizzata a un intervallo.

Override della stringa di connessione (anteprima)

Questa funzionalità è in stato di anteprima a partire dalla versione 3.4.0.

Gli override della stringa di connessione consentono di eseguire l'override della stringa di connessione predefinita. È ad esempio possibile:

• Impostare una stringa di connessione per un prefisso di percorso HTTP /myapp1.
• Impostare un'altra stringa di connessione per un altro prefisso di percorso HTTP /myapp2/.

{
  "preview": {
    "connectionStringOverrides": [
      {
        "httpPathPrefix": "/myapp1",
        "connectionString": "..."
      },
      {
        "httpPathPrefix": "/myapp2",
        "connectionString": "..."
      }
    ]
  }
}

Override del nome del ruolo cloud (anteprima)

Questa funzionalità è in stato di anteprima a partire dalla versione 3.3.0.

Gli override del nome del ruolo cloud consentono di eseguire l'override del nome del ruolo cloud predefinito. È ad esempio possibile:

• Impostare un nome del ruolo cloud per un prefisso di percorso HTTP /myapp1.
• Impostare un altro nome del ruolo cloud per un altro prefisso di percorso HTTP /myapp2/.

{
  "preview": {
    "roleNameOverrides": [
      {
        "httpPathPrefix": "/myapp1",
        "roleName": "Role A"
      },
      {
        "httpPathPrefix": "/myapp2",
        "roleName": "Role B"
      }
    ]
  }
}

Stringa di connessione configurata durante il runtime

A partire dalla versione 3.4.8, se serve la possibilità di configurare la stringa di connessione durante il runtime, aggiungere questa proprietà alla configurazione JSON:

{
  "connectionStringConfiguredAtRuntime": true
}

Aggiungere applicationinsights-core all'applicazione:

<dependency>
  <groupId>com.microsoft.azure</groupId>
  <artifactId>applicationinsights-core</artifactId>
  <version></version>
</dependency>

Usare il metodo configure(String) statico nella classe com.microsoft.applicationinsights.connectionstring.ConnectionString.

Nota

Tutti i dati di telemetria acquisiti prima di configurare la stringa di connessione verranno eliminati, pertanto è consigliabile configurarli il prima possibile all'avvio dell'applicazione.

Dipendenze in-process con raccolta automatica (anteprima)

A partire dalla versione 3.2.0, se si vuole acquisire le dipendenze "in-process" del controller, usare la configurazione seguente:

{
  "preview": {
    "captureControllerSpans": true
  }
}

Caricatore dell'SDK del browser (anteprima)

Questa funzionalità inserisce automaticamente il caricatore dell'SDK del browser nelle pagine HTML dell'applicazione, inclusa la configurazione della stringa di connessione appropriata.

Ad esempio, quando l'applicazione Java restituisce una risposta simile alla seguente:

<!DOCTYPE html>
<html lang="en">
  <head>
    <title>Title</title>
  </head>
  <body>
  </body>
</html>

Modifica automaticamente in modo da restituire:

<!DOCTYPE html>
<html lang="en">
  <head>
    <script type="text/javascript">
    !function(v,y,T){var S=v.location,k="script"
    <!-- Removed for brevity -->
    connectionString: "YOUR_CONNECTION_STRING"
    <!-- Removed for brevity --> }});
    </script>
    <title>Title</title>
  </head>
  <body>
  </body>
</html>

Lo script ha lo scopo di aiutare i clienti a tenere traccia dei dati utente Web e a inviare di nuovo i dati di telemetria lato server raccolti al portale di Azure degli utenti. I dettagli sono disponibili in ApplicationInsights-JS.

Per abilitare questa funzionalità, aggiungere l'opzione di configurazione seguente:

{
  "preview": {
    "browserSdkLoader": {
      "enabled": true
    }
  }
}

Processori di telemetria (anteprima)

È possibile usare i processori di telemetria per configurare le regole applicate ai dati di telemetria di richiesta, dipendenza e traccia. È ad esempio possibile:

• Mascherare i dati sensibili.
• Aggiungere in modo condizionale dimensioni personalizzate.
• Aggiornare il nome dell'intervallo, che viene usato per aggregare dati di telemetria simili nel portale di Azure.
• Rimuovere attributi di intervallo specifici per controllare i costi di inserimento.

Per altre informazioni, vedere la documentazione Processore di telemetria.

Nota

Per rimuovere intervalli specifici (interi) per controllare i costi di inserimento, vedere Override di campionamento.

Strumentazione personalizzata (anteprima)

A partire dalla versione 3.3.1, è possibile acquisire intervalli per un metodo nell'applicazione:

{
  "preview": {
    "customInstrumentation": [
      {
        "className": "my.package.MyClass",
        "methodName": "myMethod"
      }
    ]
  }
}

Disabilitazione locale del campionamento per inserimento (anteprima)

Per impostazione predefinita, quando la percentuale di campionamento effettiva nell'agente Java è pari al 100% e il campionamento per inserimento è stato configurato nella risorsa di Application Insights, verrà applicata la percentuale di campionamento per inserimento.

Si noti che questo comportamento si applica sia con campionamento a frequenza fissa del 100% sia al campionamento con frequenza limitata quando la frequenza delle richieste non supera il limite di frequenza (acquisendo in modo efficace il 100% durante l'intervallo di tempo continuo).

A partire dalla versione 3.5.3, è possibile disabilitare questo comportamento e mantenere il 100% dei dati di telemetria in questi casi anche quando il campionamento per inserimento è stato configurato nella risorsa di Application Insights:

{
  "preview": {
    "sampling": {
      "ingestionSamplingEnabled": false
    }
  }
}

Registrazione con raccolta automatica

Log4j, Logback, JBoss Logging e java.util.logging vengono strumentati automaticamente. La registrazione eseguita tramite questi framework di registrazione viene raccolta automaticamente.

La registrazione viene acquisita solo se:

• Soddisfa il livello configurato per il framework di registrazione.
• Soddisfa anche il livello configurato per Application Insights.

Ad esempio, se il framework di registrazione è configurato in modo da registrare WARN (ed è stato configurato come descritto in precedenza) dal pacchetto com.example e Application Insights è configurato in modo da acquisire INFO (ed è stato configurato come descritto), Application Insights acquisisce solo WARN (e più grave) dal pacchetto com.example.

Il livello predefinito configurato per Application Insights è INFO. Se si desidera modificare il livello:

{
  "instrumentation": {
    "logging": {
      "level": "WARN"
    }
  }
}

È anche possibile impostare il livello usando la variabile di ambiente APPLICATIONINSIGHTS_INSTRUMENTATION_LOGGING_LEVEL. Ha quindi la precedenza sul livello specificato nella configurazione JSON.

È possibile usare questi valori level validi per specificare nel file applicationinsights.json. La tabella mostra come corrispondono ai livelli di registrazione in framework di registrazione diversi.

Level	Log4j	Logback	JBoss	JUL
OFF	OFF	OFF	OFF	OFF
FATAL	FATAL	ERROR	FATAL	SEVERE
ERROR (o SEVERE)	ERROR	ERROR	ERROR	SEVERE
WARN (o WARNING)	WARN	WARN	WARN	AVVISO
INFO	INFO	INFO	INFO	INFO
CONFIG	DEBUG	DEBUG	DEBUG	CONFIG
DEBUG (o FINE)	DEBUG	DEBUG	DEBUG	FINE
FINER	DEBUG	DEBUG	DEBUG	FINER
TRACE (o FINEST)	TRACE	TRACE	TRACE	FINEST
ALL	ALL	ALL	ALL	ALL

Nota

Se viene trasmesso al logger un oggetto eccezione, il messaggio di log (e i dettagli dell'oggetto eccezione) verrà visualizzato nel portale di Azure nella tabella exceptions anziché nella tabella traces. Se si vuole visualizzare i messaggi di log nelle tabelle traces e exceptions, è possibile scrivere una query Logs (Kusto) per l'unione tra di loro. Ad esempio:

union traces, (exceptions | extend message = outerMessage)
| project timestamp, message, itemType

Marcatori di log (anteprima)

A partire dalla versione 3.4.2, è possibile acquisire i marcatori di log per Logback e Log4j 2:

{
  "preview": {
    "captureLogbackMarker":  true,
    "captureLog4jMarker":  true
  }
}

Altri attributi di log per Logback (anteprima)

A partire dalla versione 3.4.3, è possibile acquisire FileName, ClassName, MethodNamee LineNumber, per Logback:

{
  "preview": {
    "captureLogbackCodeAttributes": true
  }
}

Avviso

L'acquisizione degli attributi del codice potrebbe comportare un sovraccarico delle prestazioni.

Livello di registrazione come dimensione personalizzata

A partire dalla versione 3.3.0, LoggingLevel non viene acquisito per impostazione predefinita come parte della dimensione personalizzata Traces perché tali dati sono già acquisiti nel campo SeverityLevel.

Se necessario, è possibile riabilitare temporaneamente il comportamento precedente:

{
  "preview": {
    "captureLoggingLevelAsCustomDimension": true
  }
}

Metriche di Micrometer raccolte automaticamente (incluse le metriche dell'attuatore Spring Boot)

Se l'applicazione usa Micrometer, le metriche inviate al Registro di sistema globale Micrometer vengono raccolte automaticamente.

Inoltre, se l'applicazione usa l'attuatore Spring Boot, vengono raccolte automaticamente anche le metriche configurate dall'attuatore Spring Boot.

Per inviare metriche personalizzate usando Micrometer:

1. Aggiungere Micrometer all'applicazione, come illustrato nell'esempio seguente.

   <dependency>
     <groupId>io.micrometer</groupId>
     <artifactId>micrometer-core</artifactId>
     <version>1.6.1</version>
   </dependency>
   

2. Usare il registro globale di Micrometer per creare un contatore, come illustrato nell'esempio seguente.

   static final Counter counter = Metrics.counter("test.counter");
   

3. Usare il contatore per registrare le metriche usando il comando seguente.

   counter.increment();
   

4. Le metriche vengono inserite nella tabella customMetrics, con tag acquisiti nella colonna customDimensions. È anche possibile visualizzare le metriche nello strumento di esplorazione delle metriche nello spazio dei nomi delle metriche Log-based metrics.

   Nota

   Application Insights Java sostituisce tutti i caratteri non alfanumerici (ad eccezione dei trattini) presenti nel nome della metrica di Micrometer con caratteri di sottolineatura. Di conseguenza, la metrica test.counter precedente verrà visualizzata come test_counter.

Per disabilitare la raccolta automatica delle metriche di Micrometer e delle metriche dell'attuatore Spring Boot:

Nota

Le metriche personalizzate vengono fatturate separatamente e possono generare costi aggiuntivi. Assicurarsi di consultare le informazioni sui prezzi. Per disabilitare le metriche di Micrometer e dell'attuatore Spring Boot, aggiungere la configurazione seguente al file di configurazione.

{
  "instrumentation": {
    "micrometer": {
      "enabled": false
    }
  }
}

Mascheramento delle query Java Database Connectivity

I valori letterali nelle query Java Database Connectivity (JDBC) vengono mascherati per impostazione predefinita per evitare di acquisire accidentalmente dati sensibili.

A partire dalla versione 3.4.0, questo comportamento può essere disabilitato. Ad esempio:

{
  "instrumentation": {
    "jdbc": {
      "masking": {
        "enabled": false
      }
    }
  }
}

Mascheramento delle query Mongo

I valori letterali nelle query Mongo vengono mascherati per impostazione predefinita per evitare di acquisire accidentalmente dati sensibili.

A partire dalla versione 3.4.0, questo comportamento può essere disabilitato. Ad esempio:

{
  "instrumentation": {
    "mongo": {
      "masking": {
        "enabled": false
      }
    }
  }
}

Intestazioni HTTP

A partire dalla versione 3.3.0, è possibile acquisire le intestazioni di richiesta e risposta nei dati di telemetria del server (richiesta):

{
  "preview": {
    "captureHttpServerHeaders": {
      "requestHeaders": [
        "My-Header-A"
      ],
      "responseHeaders": [
        "My-Header-B"
      ]
    }
  }
}

I nomi delle intestazioni non fanno distinzione tra maiuscole e minuscole.

Gli esempi precedenti vengono acquisiti con i nomi delle proprietà http.request.header.my_header_a e http.response.header.my_header_b.

Analogamente, è possibile acquisire le intestazioni di richiesta e risposta nei dati di telemetria del client (dipendenza):

{
  "preview": {
    "captureHttpClientHeaders": {
      "requestHeaders": [
        "My-Header-C"
      ],
      "responseHeaders": [
        "My-Header-D"
      ]
    }
  }
}

Anche in questo caso i nomi delle intestazioni non fanno distinzione tra maiuscole e minuscole. Gli esempi precedenti vengono acquisiti con i nomi delle proprietà http.request.header.my_header_c e http.response.header.my_header_d.

Codici di risposta del server HTTP 4xx

Per impostazione predefinita, le richieste del server HTTP che generano codici di risposta 4xx vengono acquisite come errori.

A partire dalla versione 3.3.0, è possibile modificare questo comportamento per acquisirli come esito positivo:

{
  "preview": {
    "captureHttpServer4xxAsError": false
  }
}

Eliminare dati di telemetria specifici raccolti automaticamente

A partire dalla versione 3.0.3, è possibile eliminare specifici dati di telemetria raccolti automaticamente usando queste opzioni di configurazione:

{
  "instrumentation": {
    "azureSdk": {
      "enabled": false
    },
    "cassandra": {
      "enabled": false
    },
    "jdbc": {
      "enabled": false
    },
    "jms": {
      "enabled": false
    },
    "kafka": {
      "enabled": false
    },
    "logging": {
      "enabled": false
    },
    "micrometer": {
      "enabled": false
    },
    "mongo": {
      "enabled": false
    },
    "quartz": {
      "enabled": false
    },
    "rabbitmq": {
      "enabled": false
    },
    "redis": {
      "enabled": false
    },
    "springScheduling": {
      "enabled": false
    }
  }
}

È anche possibile eliminare queste strumentazioni impostando queste variabili di ambiente su false:

• APPLICATIONINSIGHTS_INSTRUMENTATION_AZURE_SDK_ENABLED
• APPLICATIONINSIGHTS_INSTRUMENTATION_CASSANDRA_ENABLED
• APPLICATIONINSIGHTS_INSTRUMENTATION_JDBC_ENABLED
• APPLICATIONINSIGHTS_INSTRUMENTATION_JMS_ENABLED
• APPLICATIONINSIGHTS_INSTRUMENTATION_KAFKA_ENABLED
• APPLICATIONINSIGHTS_INSTRUMENTATION_LOGGING_ENABLED
• APPLICATIONINSIGHTS_INSTRUMENTATION_MICROMETER_ENABLED
• APPLICATIONINSIGHTS_INSTRUMENTATION_MONGO_ENABLED
• APPLICATIONINSIGHTS_INSTRUMENTATION_RABBITMQ_ENABLED
• APPLICATIONINSIGHTS_INSTRUMENTATION_REDIS_ENABLED
• APPLICATIONINSIGHTS_INSTRUMENTATION_SPRING_SCHEDULING_ENABLED

Queste variabili hanno quindi la precedenza sulle variabili abilitate specificate nella configurazione JSON.

Nota

Se si sta cercando un controllo più granulare, ad esempio per eliminare alcune chiamate Redis ma non tutte, vedere Override di campionamento.

Strumentazioni di anteprima

A partire dalla versione 3.2.0, è possibile abilitare le strumentazioni di anteprima seguenti:

{
  "preview": {
    "instrumentation": {
      "akka": {
        "enabled": true
      },
      "apacheCamel": {
        "enabled": true
      },
      "grizzly": {
        "enabled": true
      },
      "ktor": {
        "enabled": true
      },
      "play": {
        "enabled": true
      },
      "r2dbc": {
        "enabled": true
      },
      "springIntegration": {
        "enabled": true
      },
      "vertx": {
        "enabled": true
      }
    }
  }
}

Nota

La strumentazione Akka è disponibile a partire dalla versione 3.2.2. La strumentazione della libreria HTTP Vertx è disponibile a partire dalla versione 3.3.0.

Intervallo di metriche

Per impostazione predefinita, le metriche vengono acquisite ogni 60 secondi.

A partire dalla versione 3.0.3, è possibile modificare questo intervallo:

{
  "metricIntervalSeconds": 300
}

A partire dalla versione 3.4.9 con disponibilità generale, è anche possibile impostare metricIntervalSeconds usando la variabile di ambiente APPLICATIONINSIGHTS_METRIC_INTERVAL_SECONDS. Ha quindi la precedenza su metricIntervalSeconds specificato nella configurazione JSON.

Questa impostazione è valida solo per le metriche seguenti:

• Contatori delle prestazioni prede: ad esempio, CPU e memoria
• Metriche personalizzate predefinite: ad esempio, tempi di GC
• Metriche JMX configurate: vedere la sezione Metriche JMX
• Metriche di Micrometer: vedere la sezione Metriche di Micrometer raccolte automaticamente

Heartbeat

Per impostazione predefinita, Application Insights Java 3.x invia una metrica heartbeat ogni 15 minuti. Se si usa la metrica heartbeat per attivare gli avvisi, è possibile aumentare la frequenza di questo heartbeat:

{
  "heartbeat": {
    "intervalSeconds": 60
  }
}

Nota

Non è possibile aumentare l'intervallo fino a più di 15 minuti perché i dati heartbeat vengono usati anche per tenere traccia dell'utilizzo di Application Insights.

Autenticazione

Nota

La funzionalità di autenticazione è disponibile a livello generale dalla versione 3.4.17.

È possibile usare l'autenticazione per configurare l'agente in modo da generare le credenziali del token necessarie per l'autenticazione di Microsoft Entra. Per altre informazioni, vedere la documentazione Autenticazione.

Proxy HTTP

Se l'applicazione è protetta da un firewall e non può connettersi direttamente ad Application Insights, vedere Indirizzi IP usati da Application Insights.

Per risolvere questo problema, è possibile configurare Application Insights Java 3.x per l'uso di un proxy HTTP.

{
  "proxy": {
    "host": "myproxy",
    "port": 8080
  }
}

È anche possibile impostare il proxy HTTP usando la variabile di ambiente APPLICATIONINSIGHTS_PROXY, che accetta il formato https://<host>:<port>. Ha quindi la precedenza sul proxy specificato nella configurazione JSON.

È possibile fornire un utente e una password per il proxy con la APPLICATIONINSIGHTS_PROXYvariabile di ambiente: https://<user>:<password>@<host>:<port>.

Application Insights Java 3.x rispetta anche le proprietà di sistema globali https.proxyHost e https.proxyPort, se impostate, e http.nonProxyHosts, se necessario.

Ripristino da errori di inserimento

Quando l'invio di dati di telemetria al servizio Application Insights ha esito negativo, Application Insights Java 3.x archivia tali dati sul disco e continua a riprovare dal disco.

Il limite predefinito per la persistenza del disco è 50 Mb. Se si dispone di un volume di telemetria elevato o se è necessario essere in grado di eseguire il ripristino da interruzioni del servizio di inserimento o rete più lunghe, è possibile aumentare questo limite a partire dalla versione 3.3.0:

{
  "preview": {
    "diskPersistenceMaxSizeMb": 50
  }
}

Diagnostica self-service

"Diagnostica self-service" si riferisce alla registrazione interna da Application Insights Java 3.x. Questa funzionalità può essere utile per individuare e diagnosticare i problemi con Application Insights stesso.

Per impostazione predefinita, Application Insights Java 3.x registra a livello INFO sia sul file applicationinsights.log che sulla console, come questa configurazione:

{
  "selfDiagnostics": {
    "destination": "file+console",
    "level": "INFO",
    "file": {
      "path": "applicationinsights.log",
      "maxSizeMb": 5,
      "maxHistory": 1
    }
  }
}

Nell'esempio di configurazione precedente:

• level può essere uno tra OFF, ERROR, WARN, INFO, DEBUG e TRACE.
• path può essere un percorso assoluto o relativo. I percorsi relativi vengono risolti nella directory in cui si trova applicationinsights-agent-3.6.2.jar.

A partire dalla versione 3.0.2, è anche possibile impostare la diagnostica self-service level usando la variabile di ambiente APPLICATIONINSIGHTS_SELF_DIAGNOSTICS_LEVEL. Ha quindi la precedenza sul livello di diagnostica self-service specificato nella configurazione JSON.

A partire dalla versione 3.0.3, è anche possibile impostare la posizione del file della diagnostica self-service usando la variabile di ambiente APPLICATIONINSIGHTS_SELF_DIAGNOSTICS_FILE_PATH. Ha quindi la precedenza sul percorso del file della diagnostica self-service specificato nella configurazione JSON.

Correlazione di dati di telemetria

La correlazione dei dati di telemetria è abilitata per impostazione predefinita, ma è possibile disabilitarla nella configurazione.

{
  "preview": {
    "disablePropagation": true
  }
}

Esempio

Questo esempio mostra l'aspetto di un file di configurazione con più componenti. Configurare opzioni specifiche in base alle esigenze.

{
  "connectionString": "...",
  "role": {
    "name": "my cloud role name"
  },
  "sampling": {
    "percentage": 100
  },
  "jmxMetrics": [
  ],
  "customDimensions": {
  },
  "instrumentation": {
    "logging": {
      "level": "INFO"
    },
    "micrometer": {
      "enabled": true
    }
  },
  "proxy": {
  },
  "preview": {
    "processors": [
    ]
  },
  "selfDiagnostics": {
    "destination": "file+console",
    "level": "INFO",
    "file": {
      "path": "applicationinsights.log",
      "maxSizeMb": 5,
      "maxHistory": 1
    }
  }
}