Konfigurationsoptionen: Azure Monitor Application Insights für Java
Hinweis
Am 31. März 2025 wird der Support für die auf Instrumentierungsschlüsseln basierende Erfassung eingestellt. Die Erfassung von Instrumentierungsschlüsseln funktioniert zwar weiterhin, wir stellen jedoch keine Updates und keinen Support mehr für das Feature bereit. Wechseln Sie zu Verbindungszeichenfolgen, damit Sie neue Funktionen nutzen können.
Verbindungszeichenfolge und Rollenname
Die Verbindungszeichenfolge und der Rollenname sind die gängigsten Einstellungen, die für den Einstieg erforderlich sind:
{
"connectionString": "...",
"role": {
"name": "my cloud role name"
}
}
Eine Verbindungszeichenfolge ist erforderlich. Der Rollenname ist immer dann relevant, wenn Sie Daten unterschiedlicher Anwendungen an dieselbe Application Insights-Ressource senden.
Weitere Informationen und Konfigurationsoptionen finden Sie in den folgenden Abschnitten.
Pfad der Konfigurationsdatei
Standardmäßig erwartet Application Insights Java 3.x eine Konfigurationsdatei mit dem Namen applicationinsights.json
, die sich im gleichen Verzeichnis wie applicationinsights-agent-3.4.7.jar
befindet.
Sie können einen eigenen Konfigurationsdateipfad angeben, indem Sie eine der folgenden beiden Optionen verwenden:
- Umgebungsvariable
APPLICATIONINSIGHTS_CONFIGURATION_FILE
- Java-Systemeigenschaft
applicationinsights.configuration.file
Wenn Sie einen relativen Pfad angeben, wird dieser relativ zum Verzeichnis von applicationinsights-agent-3.4.7.jar
aufgelöst.
Alternativ können Sie anstelle einer Konfigurationsdatei den gesamten Inhalt der JSON-Konfiguration über die Umgebungsvariable APPLICATIONINSIGHTS_CONFIGURATION_CONTENT
angeben.
Verbindungszeichenfolge
Eine Verbindungszeichenfolge ist erforderlich. Die Verbindungszeichenfolge finden Sie in der Application Insights-Ressource.
{
"connectionString": "..."
}
Sie können die Verbindungszeichenfolge auch mit der Umgebungsvariable APPLICATIONINSIGHTS_CONNECTION_STRING
festlegen. Diese hat dann Vorrang vor der in der JSON-Konfiguration angegebenen Verbindungszeichenfolge.
Sie können die Verbindungszeichenfolge auch mithilfe der Java-Systemeigenschaft applicationinsights.connection.string
festlegen. Diese hat auch Vorrang vor der in der JSON-Konfiguration angegebenen Verbindungszeichenfolge.
Sie können die Verbindungszeichenfolge auch festlegen, indem Sie eine Datei angeben, aus der die Verbindungszeichenfolge geladen werden soll.
Wenn Sie einen relativen Pfad angeben, wird dieser relativ zum Verzeichnis von applicationinsights-agent-3.4.7.jar
aufgelöst.
{
"connectionString": "${file:connection-string-file.txt}"
}
Die Datei sollte nur die Verbindungszeichenfolge und sonst nichts enthalten.
Falls die Verbindungszeichenfolge nicht festgelegt wird, wird der Java-Agent deaktiviert.
Wenn Sie mehrere Anwendungen in derselben JVM bereitgestellt haben und sie wollen, dass sie Telemetriedaten an unterschiedliche Instrumentierungsschlüssel senden, lesen Sie Instrumentierungsschlüssel überschreiben (Vorschau).
Cloudrollenname
Der Name der Cloudrolle wird verwendet, um die Komponente in der Anwendungsübersicht zu bezeichnen.
Wenn Sie den Cloudrollennamen festlegen möchten:
{
"role": {
"name": "my cloud role name"
}
}
Falls der Cloudrollenname nicht festgelegt ist, wird der Name der Application Insights-Ressource zur Bezeichnung der Komponente in der Anwendungsübersicht verwendet.
Sie können den Namen der Cloudrolle auch mithilfe der Umgebungsvariablen APPLICATIONINSIGHTS_ROLE_NAME
festlegen. Dieser hat dann Vorrang vor dem in der JSON-Konfiguration angegebenen Cloudrollennamen.
Sie können den Namen der Cloudrolle auch mithilfe der Java-Systemeigenschaft applicationinsights.role.name
festlegen. Auch diese hat dann Vorrang vor dem in der JSON-Konfiguration angegebenen Cloudrollennamen.
Wenn Sie mehrere Anwendungen in derselben JVM bereitgestellt haben und Sie wollen, dass sie Telemetriedaten an verschiedene Cloudrollennamen senden, lesen Sie Überschreiben von Cloud-Rollennamen (Vorschau).
Cloudrolleninstanz
Der Name der Cloudrolleninstanz entspricht standardmäßig dem Computernamen.
Wenn Sie für die Cloudrolleninstanz einen anderen Namen festlegen möchten:
{
"role": {
"name": "my cloud role name",
"instance": "my cloud role instance"
}
}
Sie können den Namen der Cloudrolleninstanz auch mithilfe der Umgebungsvariable APPLICATIONINSIGHTS_ROLE_INSTANCE
festlegen. Dieser hat dann Vorrang vor der in der JSON-Konfiguration angegebenen Cloudrolleninstanz.
Sie können den die Cloudrolleninstanz auch mithilfe der Java-Systemeigenschaft applicationinsights.role.instance
festlegen.
Dieser hat dann ebenfalls Vorrang vor der in der JSON-Konfiguration angegebenen Cloudrolleninstanz.
Stichproben
Hinweis
Das Sampling eignet sich u. U. sehr gut dazu, die Kosten von Application Insights zu reduzieren. Stellen Sie sicher, dass Sie Ihre Samplingkonfiguration Ihrem Anwendungsfall gemäß einrichten.
Das Sampling erfolgt anforderungsbasiert, d. h., wenn eine Anforderung erfasst (gesampelt) wird, werden auch ihre Abhängigkeiten, Protokolle und Ausnahmen erfasst.
Darüber hinaus basiert das Sampling auf einer Überwachungs-ID, um für konsistente Samplingentscheidungen über verschiedene Dienste hinweg zu sorgen.
Sampling mit Ratenbegrenzung
Ab Version 3.4.0 steht Sampling mit Ratenbegrenzung zur Verfügung und ist jetzt Standard.
Wenn kein Sampling konfiguriert wurde, ist die Standardkonfiguration jetzt das Sampling mit Ratenbegrenzung zur Erfassung von maximal (ca.) fünf Anforderungen pro Sekunde, zusammen mit allen Abhängigkeiten und Protokollen für diese Anforderungen.
Durch diese Konfiguration wird die vorherige Standardeinstellung ersetzt, bei der alle Anforderungen erfasst wurden. Wenn Sie weiterhin alle Anforderungen erfassen möchten, verwenden Sie das Sampling mit festem Prozentsatz, und legen Sie den Samplingprozentsatz auf 100 fest.
Hinweis
Das Sampling mit Ratenbegrenzung ist eine ungefähre Einstellung, da intern ein „fester“ Samplingprozentsatz im Zeitverlauf angepasst werden muss, damit genaue Elementzahlen für jeden Telemetriedatensatz ausgegeben werden. Intern wird das Sampling mit Ratenbegrenzung so angepasst, dass schnell (0,1 Sekunden) auf neue Anwendungslasten reagiert werden kann. Aus diesem Grund sollten Sie die konfigurierte Rate nicht sehr stark oder sehr lange überschritten werden.
Das folgende Beispiel zeigt, wie das Sampling eingestellt werden kann, sodass höchstens (ca.) eine Anforderung pro Sekunde erfasst wird:
{
"sampling": {
"requestsPerSecond": 1.0
}
}
Beachten Sie, dass requestsPerSecond
eine Dezimalzahl sein kann, sodass Sie den Wert so konfigurieren können, dass bei Bedarf weniger als eine Anforderung pro Sekunde erfasst wird. Beispiel: Der Wert 0.5
bedeutet eine Erfassung von höchstens einer Anforderung alle zwei Sekunden.
Sie können den Samplingprozentsatz auch mithilfe der Umgebungsvariable APPLICATIONINSIGHTS_SAMPLING_REQUESTS_PER_SECOND
festlegen. Dieser hat dann Vorrang vor dem in der JSON-Konfiguration angegebenen Ratenlimit.
Sampling mit festen Prozentsatz
Das folgende Beispiel veranschaulicht das Festlegen des Samplings, damit ungefähr ein Drittel aller Anforderungen erfasst werden:
{
"sampling": {
"percentage": 33.333
}
}
Sie können den Samplingprozentsatz auch mithilfe der Umgebungsvariable APPLICATIONINSIGHTS_SAMPLING_PERCENTAGE
festlegen. Dieser hat dann Vorrang vor dem in der JSON-Konfiguration angegebenen Samplingprozentsatz.
Hinweis
Für den Samplingprozentsatz wählen Sie einen Wert aus, der sich als Bruch darstellen lässt (100/N, wobei N eine ganze Zahl ist). Andere Werte werden für die Stichprobenerstellung derzeit nicht unterstützt.
Stichprobenüberschreibungen (Vorschau)
Dieses Feature befindet sich ab 3.0.3 in der Vorschauphase.
Mithilfe von Stichprobenüberschreibungen können Sie den Standardprozentsatz für das Sampling überschreiben. Beispielsweise können Sie folgende Aktionen ausführen:
- Legen Sie den Samplingprozentsatz für überflüssige Integritätsprüfungen auf 0 (oder einen kleinen Wert) fest.
- Legen Sie den Samplingprozentsatz für überflüssige Abhängigkeitsaufrufe auf 0 (oder einen kleinen Wert) fest.
- Festlegen des Samplingprozentsatzes auf 100 für einen wichtigen Anforderungstyp. Sie können
/login
z. B. auch dann verwenden, wenn der Standardwert für das Sampling niedriger konfiguriert ist.
Weitere Informationen finden Sie in der Dokumentation zu Stichprobenüberschreibungen.
JMX-Metriken
Verwenden Sie folgenden JSON-Code, wenn Sie einige zusätzliche JMX-Metriken erfassen möchten:
{
"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"
}
]
}
Im vorherigen Konfigurationsbeispiel gilt Folgendes:
name
entspricht dem Metriknamen, der dieser JMX-Metrik zugewiesen wird (ein beliebiger Name kann verwendet werden).objectName
entspricht demobjectName
des verwalteten Beans (MBean) von JMX, das Sie erfassen möchten.attribute
entspricht dem Attributnamen innerhalb des verwalteten Beans (MBean) von JMX, das Sie erfassen möchten.
Numerische und boolesche JMX-Metrikwerte werden unterstützt. Boolesche JMX-Metriken werden 0
für FALSE und 1
für TRUE zugeordnet.
Benutzerdefinierte Dimensionen
Verwenden Sie den folgenden JSON-Code, wenn Sie Ihren gesamten Telemetriedaten benutzerdefinierte Dimensionen hinzufügen möchten:
{
"customDimensions": {
"mytag": "my value",
"anothertag": "${ANOTHER_VALUE}"
}
}
${...}
kann zum Lesen des Werts aus der angegebenen Umgebungsvariable beim Start verwendet werden.
Hinweis
Wenn Sie ab Version 3.0.2 eine benutzerdefinierte Dimension mit dem Namen service.version
hinzufügen, wird der Wert in der Spalte application_Version
in der Tabelle „Application Insights-Protokolle“ und nicht als benutzerdefinierte Dimension gespeichert.
Vererbtes Attribut (Vorschau)
Ab Version 3.2.0 können Sie eine benutzerdefinierte Dimension programmgesteuert in Ihrer Anforderungstelemetrie festlegen und sie an die nachfolgende Abhängigkeitstelemetrie vererben:
{
"inheritedAttributes": [
{
"key": "mycustomer",
"type": "string"
}
]
}
Überschreiben der Verbindungszeichenfolgen (Vorschau)
Dieses Feature befindet sich ab 3.4.0 in der Vorschauphase.
Durch die Überschreibung der Verbindungszeichenfolgen können Sie die Standardverbindungszeichenfolge außer Kraft setzen. Beispielsweise können Sie folgende Aktionen ausführen:
- Legen Sie eine Verbindungszeichenfolge für ein HTTP-Pfadpräfix
/myapp1
fest. - Legen Sie eine andere Verbindungszeichenfolge für ein weiteres HTTP-Pfadpräfix
/myapp2/
fest.
{
"preview": {
"connectionStringOverrides": [
{
"httpPathPrefix": "/myapp1",
"connectionString": "..."
},
{
"httpPathPrefix": "/myapp2",
"connectionString": "..."
}
]
}
}
Überschreiben des Instrumentierungsschlüssels (Vorschau)
Diese Funktion ist in der Vorschau, beginnend mit 3.2.3.
Instrumentierungsschlüsselüberschreibungen ermöglichen Ihnen, den Standardinstrumentierungsschlüssel außer Kraft zu setzen. Beispielsweise können Sie folgende Aktionen ausführen:
- Legen Sie einen Instrumentierungsschlüssel für ein HTTP-Pfadpräfix
/myapp1
fest. - Legen Sie einen weiteren Instrumentierungsschlüssel für ein anderes HTTP-Pfadpräfix
/myapp2/
fest.
{
"preview": {
"instrumentationKeyOverrides": [
{
"httpPathPrefix": "/myapp1",
"instrumentationKey": "12345678-0000-0000-0000-0FEEDDADBEEF"
},
{
"httpPathPrefix": "/myapp2",
"instrumentationKey": "87654321-0000-0000-0000-0FEEDDADBEEF"
}
]
}
}
Überschreiben des Cloud-Rollennamens (Vorschau)
Dieses Feature befindet sich ab 3.3.0 in der Vorschauphase.
Durch die Außerkraftsetzung des Cloudrollennamens können Sie den Standardnamen der Cloudrolle überschreiben. Beispielsweise können Sie folgende Aktionen ausführen:
- Legen Sie einen Cloudrollennamen für ein HTTP-Pfadpräfix
/myapp1
fest. - Legen Sie einen weiteren Cloudrollennamen für ein anderes HTTP-Pfadpräfix
/myapp2/
fest.
{
"preview": {
"roleNameOverrides": [
{
"httpPathPrefix": "/myapp1",
"roleName": "Role A"
},
{
"httpPathPrefix": "/myapp2",
"roleName": "Role B"
}
]
}
}
Automatische Sammlung von InProc-Abhängigkeiten (Vorschau)
Wenn Sie ab Version 3.2.0 InProc-Controllerabhängigkeiten erfassen möchten, verwenden Sie die folgende Konfiguration:
{
"preview": {
"captureControllerSpans": true
}
}
Telemetrieprozessoren (Vorschauversion)
Mit diesem Feature können Sie Regeln konfigurieren, die auf Anforderungs-, Abhängigkeits- und Überwachungstelemetriedaten angewandt werden. Beispielsweise können Sie folgende Aktionen ausführen:
- Maskieren vertraulicher Daten
- Bedingtes Hinzufügen benutzerdefinierter Dimensionen
- Aktualisieren des Namens des span-Elements, das zum Aggregieren ähnlicher Telemetriedaten im Azure-Portal verwendet wird
- Verwerfen bestimmter span-Attribute zur Senkung von Erfassungskosten
Weitere Informationen finden Sie in der Dokumentation zu Telemetrieprozessoren.
Hinweis
Wenn Sie bestimmte (ganze) Span-Elemente zur Senkung von Erfassungskosten verwerfen möchten, lesen Sie unter Stichprobenüberschreibungen nach.
Automatisch gesammelte Protokolle
Log4j, Logback, JBoss Logging und java.util.logging werden automatisch instrumentiert. Die über diese Protokollierungsframeworks ausgeführte Protokollierung wird automatisch erfasst.
Die Protokollierung wird nur erfasst, wenn Folgendes gilt:
- Sie erfüllt die Ebene, die für das Protokollierungsframework konfiguriert ist.
- Sie erfüllt auch die Ebene, die für Application Insights konfiguriert ist.
Wenn Ihr Protokollierungsframework z. B. so konfiguriert ist, dass es WARN
(und höher) aus Paket com.example
protokolliert, und Application Insights so konfiguriert ist, dass es INFO
(und höher) aufzeichnet, dann zeichnet Application Insights nur WARN
(und höher) aus Paket com.example
auf.
Die für Application Insights konfigurierte Standardebene ist INFO
. Wenn Sie diesen Wert ändern möchten, ist das folgendermaßen möglich:
{
"instrumentation": {
"logging": {
"level": "WARN"
}
}
}
Sie können den Schwellenwert auch mithilfe der Umgebungsvariable APPLICATIONINSIGHTS_INSTRUMENTATION_LOGGING_LEVEL
festlegen. Dieser hat dann Vorrang vor dem in der JSON-Konfiguration angegebenen Wert.
Sie können diese gültigen level
-Werte verwenden, um sie in der Datei applicationinsights.json
anzugeben. In der Tabelle wird gezeigt, wie sie den Protokollierungsebenen in verschiedenen Protokollierungsframeworks entsprechen.
Ebene | Log4j | Logback | JBoss | JUL |
---|---|---|---|---|
OFF | OFF | OFF | OFF | OFF |
FATAL | FATAL | ERROR | FATAL | SEVERE |
ERROR (oder SEVERE) | ERROR | ERROR | ERROR | SEVERE |
WARN (oder WARNING) | WARN | WARN | WARN | WARNING |
INFO | INFO | INFO | INFO | INFO |
CONFIG | DEBUG | DEBUG | DEBUG | CONFIG |
DEBUG (oder FINE) | DEBUG | DEBUG | DEBUG | FINE |
FINER | DEBUG | DEBUG | DEBUG | FINER |
TRACE (oder FINEST) | TRACE | TRACE | TRACE | FINEST |
ALL | ALL | ALL | ALL | ALL |
Hinweis
Wenn ein Ausnahmeobjekt an die Protokollierung übergeben wird, wird die Protokollmeldung (zusammen mit Details zum Ausnahmeobjekt) im Azure-Portal in der Tabelle exceptions
und nicht in der Tabelle traces
angezeigt. Wenn Sie die Protokollnachrichten sowohl für die Tabelle traces
als auch für die Tabelle exceptions
anzeigen möchten, können Sie eine beide vereinigende Protokollabfrage (Kusto) schreiben. Beispiel:
union traces, (exceptions | extend message = outerMessage)
| project timestamp, message, itemType
Protokollmarker (Vorschau)
Ab Version 3.4.2 können Sie die Protokollmarker für Logback und Log4j 2 erfassen:
{
"preview": {
"captureLogbackMarker": true,
"captureLog4jMarker": true
}
}
Zusätzliche Protokollattribute für Logback (Vorschau)
Ab Version 3.4.3 können Sie FileName
, ClassName
, MethodName
und LineNumber
für Logback erfassen:
{
"preview": {
"captureLogbackCodeAttributes": true
}
}
Warnung
Das Erfassen von Codeattributen kann einen zusätzlichen Leistungsaufwand bedeuten.
Protokolliergrad als benutzerdefinierte Dimension
Ab Version 3.3.0 wird LoggingLevel
nicht standardmäßig als Teil der benutzerdefinierten Dimension für Ablaufverfolgungen erfasst, da diese Daten bereits im Feld SeverityLevel
erfasst werden.
Bei Bedarf können Sie das vorherige Verhalten temporär wieder aktivieren:
{
"preview": {
"captureLoggingLevelAsCustomDimension": true
}
}
Automatisch gesammelte Micrometer-Metriken (einschließlich Spring Boot Actuator-Metriken)
Wenn Ihre Anwendung Micrometer verwendet, werden Metriken, die an die globale Micrometer-Registrierung gesendet werden, automatisch erfasst.
Wenn Ihre Anwendung auch Spring Boot Actuator verwendet, werden mit Spring Boot Actuator konfigurierte Metriken ebenfalls automatisch erfasst.
So deaktivieren Sie die automatische Erfassung von Micrometer-Metriken und Spring Boot Actuator-Metriken
Hinweis
Benutzerdefinierte Metriken werden separat in Rechnung gestellt und können Zusatzkosten verursachen. Es wird dringend empfohlen, die Preisinformationen zu überprüfen. Fügen Sie die folgende Konfiguration in Ihrer Konfigurationsdatei hinzu, um die Micrometer- und Spring Boot Actuator-Metriken zu deaktivieren.
{
"instrumentation": {
"micrometer": {
"enabled": false
}
}
}
Maskieren der JDBC-Abfrage
Literalwerte in JDBC-Abfragen werden standardmäßig maskiert, um zu vermeiden, dass versehentlich vertrauliche Daten erfasst werden.
Ab Version 3.4.0 kann dieses Verhalten deaktiviert werden. Beispiel:
{
"instrumentation": {
"jdbc": {
"masking": {
"enabled": false
}
}
}
}
Maskieren der Mongo-Abfrage
Literalwerte in Mongo-Abfragen werden standardmäßig maskiert, um zu vermeiden, dass versehentlich vertrauliche Daten erfasst werden.
Ab Version 3.4.0 kann dieses Verhalten deaktiviert werden. Beispiel:
{
"instrumentation": {
"mongo": {
"masking": {
"enabled": false
}
}
}
}
HTTP-Header
Ab Version 3.3.0 können Sie Anforderungs- und Antwort-Header in Servertelemetriedaten (Anforderung) erfassen:
{
"preview": {
"captureHttpServerHeaders": {
"requestHeaders": [
"My-Header-A"
],
"responseHeaders": [
"My-Header-B"
]
}
}
}
Die Groß-/Kleinschreibung wird bei Headernamen nicht beachtet.
Die obigen Beispiele werden unter den Eigenschaftennamen http.request.header.my_header_a
und http.response.header.my_header_b
erfasst.
Auf ähnliche Weise können Sie Anforderungs- und Antwortheader in Ihren Client(Abhängigkeits-)telemetriedaten erfassen:
{
"preview": {
"captureHttpClientHeaders": {
"requestHeaders": [
"My-Header-C"
],
"responseHeaders": [
"My-Header-D"
]
}
}
}
Auch hier wird die Groß-/Kleinschreibung bei Headernamen nicht beachtet. Die obigen Beispiele werden unter den Eigenschaftennamen http.request.header.my_header_c
und http.response.header.my_header_d
erfasst.
4xx-Antwortcodes von HTTP-Servern
Standardmäßig werden HTTP-Serveranforderungen, die 4xx-Antwortcodes zurückgeben, als Fehler erfasst.
Ab Version 3.3.0 können Sie dieses Verhalten ändern, um sie als erfolgreich zu erfassen:
{
"preview": {
"captureHttpServer4xxAsError": false
}
}
Unterdrücken bestimmter automatisch erfasster Telemetriedaten
Ab Version 3.0.3 können bestimmte automatisch erfasste Telemetriedaten mithilfe der folgenden Konfigurationsoptionen unterdrückt werden:
{
"instrumentation": {
"azureSdk": {
"enabled": false
},
"cassandra": {
"enabled": false
},
"jdbc": {
"enabled": false
},
"jms": {
"enabled": false
},
"kafka": {
"enabled": false
},
"micrometer": {
"enabled": false
},
"mongo": {
"enabled": false
},
"quartz": {
"enabled": false
},
"rabbitmq": {
"enabled": false
},
"redis": {
"enabled": false
},
"springScheduling": {
"enabled": false
}
}
}
Sie können diese Instrumentierungen auch unterdrücken, indem Sie folgende Umgebungsvariablen auf false
festlegen:
APPLICATIONINSIGHTS_INSTRUMENTATION_AZURE_SDK_ENABLED
APPLICATIONINSIGHTS_INSTRUMENTATION_CASSANDRA_ENABLED
APPLICATIONINSIGHTS_INSTRUMENTATION_JDBC_ENABLED
APPLICATIONINSIGHTS_INSTRUMENTATION_JMS_ENABLED
APPLICATIONINSIGHTS_INSTRUMENTATION_KAFKA_ENABLED
APPLICATIONINSIGHTS_INSTRUMENTATION_MICROMETER_ENABLED
APPLICATIONINSIGHTS_INSTRUMENTATION_MONGO_ENABLED
APPLICATIONINSIGHTS_INSTRUMENTATION_RABBITMQ_ENABLED
APPLICATIONINSIGHTS_INSTRUMENTATION_REDIS_ENABLED
APPLICATIONINSIGHTS_INSTRUMENTATION_SPRING_SCHEDULING_ENABLED
Diese Variablen haben dann Vorrang vor den aktivierten Variablen, die in der JSON-Konfiguration angegeben sind.
Hinweis
Wenn Sie eine präzisere Steuerung benötigen, z. B. um einige, aber nicht alle Redis-Aufrufe zu unterdrücken, lesen Sie unter Stichprobenüberschreibungen nach.
Vorschau-Instrumentierungen
Ab Version 3.2.0 können die folgenden Vorschauminstrumentierungen aktiviert werden:
{
"preview": {
"instrumentation": {
"akka": {
"enabled": true
},
"apacheCamel": {
"enabled": true
},
"grizzly": {
"enabled": true
},
"play": {
"enabled": true
},
"springIntegration": {
"enabled": true
},
"vertx": {
"enabled": true
}
}
}
}
Hinweis
Die Akka-Instrumentierung ist ab Version 3.2.2 verfügbar. Die Vertx HTTP Library-Instrumentierung ist ab Version 3.3.0 verfügbar.
Metrikintervall
Dieses Feature befindet sich in der Vorschauphase.
Standardmäßig werden Metriken alle 60 Sekunden aufgezeichnet.
Ab Version 3.0.3 können Sie dieses Intervall ändern:
{
"preview": {
"metricIntervalSeconds": 300
}
}
Die Einstellung gilt für die folgenden Metriken:
- Standardleistungsindikatoren: z. B. CPU und Arbeitsspeicher
- Standardmäßige benutzerdefinierte Metriken: z. B. die zeitliche Steuerung der Garbage Collection
- Konfigurierte JMX-Metriken:siehe Abschnitt zu JMX-Metriken
- Micrometer-Metriken:siehe Abschnitt zu automatisch erfassten Micrometer-Metriken
Heartbeat
Application Insights Java 3.x sendet standardmäßig alle 15 Minuten eine Heartbeatmetrik. Wenn Sie die Taktmetrik (Heartbeat) zum Auslösen von Warnungen verwenden, können Sie die Frequenz für den Takt erhöhen:
{
"heartbeat": {
"intervalSeconds": 60
}
}
Hinweis
Sie können das Intervall nicht auf mehr als 15 Minuten erhöhen, da die Taktdaten auch zur Nachverfolgung der Application Insights-Nutzung verwendet werden.
Authentifizierung (Vorschau)
Hinweis
Das Authentifizierungsfeature ist ab Version 3.2.0 verfügbar.
Mit der Authentifizierung können Sie den Agent so konfigurieren, dass Tokenanmeldeinformationen generiert werden, die für die Azure Active Directory-Authentifizierung erforderlich sind. Weitere Informationen finden Sie in der Dokumentation zur Authentifizierung.
HTTP-Proxy
Wenn sich Ihre Anwendung hinter einer Firewall befindet und nicht direkt mit Application Insights verbunden werden kann (siehe Von Application Insights verwendete IP-Adressen), können Sie Application Insights Java 3.x für die Verwendung eines HTTP-Proxys konfigurieren:
{
"proxy": {
"host": "myproxy",
"port": 8080
}
}
Ferner können Sie den HTTP-Proxy mithilfe der Umgebungsvariable APPLICATIONINSIGHTS_PROXY
festlegen, die das Format https://<host>:<port>
annimmt. Dieser hat dann Vorrang vor dem in der JSON-Konfiguration angegebenen Proxy.
Application Insights Java 3.x respektiert auch die globalen Systemeigenschaften https.proxyHost
und https.proxyPort
, wenn diese festgelegt sind (sowie http.nonProxyHosts
, falls erforderlich).
Wiederherstellung nach Erfassungsfehlern
Wenn das Senden von Telemetriedaten an den Application Insights-Dienst zu Fehlern führt, speichert Application Insights Java 3.x die Telemetriedaten auf dem Datenträger und unternimmt weitere Versuche vom Datenträger.
Der Standardgrenzwert für die Datenträgerpersistenz beträgt 50 MB. Wenn Sie über ein hohes Telemetriedatenvolumen verfügen oder in der Lage sein müssen, nach längeren Netzwerk- oder Erfassungsdienstausfällen wiederherzustellen, können Sie diesen Grenzwert ab Version 3.3.0 erhöhen:
{
"preview": {
"diskPersistenceMaxSizeMb": 50
}
}
Selbstdiagnose
„Selbstdiagnose“ bezeichnet die interne Protokollierung von Application Insights Java 3.x. Diese Funktionalität kann hilfreich sein, um Probleme mit Application Insights selbst zu identifizieren und zu diagnostizieren.
Application Insights Java 3.x protokolliert standardmäßig auf Ebene INFO
in der Datei applicationinsights.log
und der Konsole entsprechend der folgenden Konfiguration:
{
"selfDiagnostics": {
"destination": "file+console",
"level": "INFO",
"file": {
"path": "applicationinsights.log",
"maxSizeMb": 5,
"maxHistory": 1
}
}
}
Im vorherigen Konfigurationsbeispiel gilt Folgendes:
level
kannOFF
,ERROR
,WARN
,INFO
,DEBUG
oderTRACE
sein.path
kann ein absoluter oder ein relativer Pfad sein. Relative Pfade werden anhand des Verzeichnisses aufgelöst, in dem sichapplicationinsights-agent-3.4.7.jar
befindet.
Ab Version 3.0.2 können Sie auch das level
der Selbstdiagnose mithilfe der Umgebungsvariable APPLICATIONINSIGHTS_SELF_DIAGNOSTICS_LEVEL
festlegen. Diese hat dann Vorrang vor der in der JSON-Konfiguration angegebenen Selbstdiagnoseebene.
Ab Version 3.0.3 können Sie auch den Speicherort der Selbstdiagnosedatei über die Umgebungsvariable APPLICATIONINSIGHTS_SELF_DIAGNOSTICS_FILE_PATH
festlegen. Dieser hat dann Vorrang vor dem in der JSON-Konfiguration angegebenen Dateipfad für die Selbstdiagnose.
Beispiel
Dieses Beispiel veranschaulicht eine Konfigurationsdatei mit mehreren Komponenten. Konfigurieren Sie spezifische Optionen basierend auf Ihren Anforderungen.
{
"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
}
}
}