Možnosti konfigurace: Azure Monitor Application Insights pro Javu
V tomto článku se dozvíte, jak nakonfigurovat Application Insights pro Azure Monitor pro Javu.
Připojovací řetězec a název role
Připojovací řetězec a název role jsou nejběžnější nastavení, která potřebujete, abyste mohli začít:
{
"connectionString": "...",
"role": {
"name": "my cloud role name"
}
}
Připojovací řetězec je povinný. Název role je důležitý, kdykoli odesíláte data z různých aplikací do stejného prostředku Application Insights.
Další informace a možnosti konfigurace najdete v následujících částech.
Nastavení konfigurace JSON
Výchozí konfigurace
Application Insights Java 3 ve výchozím nastavení očekává, že konfigurační soubor bude pojmenovaný applicationinsights.json a bude umístěný ve stejném adresáři jako applicationinsights-agent-3.6.2.jar.
Alternativní konfigurace
Vlastní konfigurační soubor
Vlastní konfigurační soubor můžete zadat pomocí
- APPLICATIONINSIGHTS_CONFIGURATION_FILE proměnné prostředí nebo
- vlastnost systému applicationinsights.configuration.file
Pokud zadáte relativní cestu, přeloží se vzhledem k adresáři, ve kterém se nachází applicationinsights-agent-3.6.0.jar.
Konfigurace JSON
Místo použití konfiguračního souboru můžete celou konfiguraci JSON nastavit takto:
- APPLICATIONINSIGHTS_CONFIGURATION_CONTENT proměnné prostředí nebo
- vlastnost applicationinsights.configuration.content system
Connection string
Připojovací řetězec je povinný. Svůj připojovací řetězec najdete v prostředku Application Insights.
{
"connectionString": "..."
}
Můžete také nastavit připojovací řetězec pomocí proměnné APPLICATIONINSIGHTS_CONNECTION_STRING
prostředí . Potom má přednost před připojovací řetězec zadaným v konfiguraci JSON.
Nebo můžete nastavit připojovací řetězec pomocí vlastnosti applicationinsights.connection.string
systému Java . Má také přednost před připojovací řetězec zadanými v konfiguraci JSON.
Můžete také nastavit připojovací řetězec zadáním souboru pro načtení připojovací řetězec z.
Pokud zadáte relativní cestu, přeloží se vzhledem k adresáři, ve kterém applicationinsights-agent-3.6.2.jar
se nachází.
{
"connectionString": "${file:connection-string-file.txt}"
}
Soubor by měl obsahovat pouze připojovací řetězec a nic jiného.
Nenastavuje připojovací řetězec zakáže agenta Javy.
Pokud máte ve stejném prostředí Java Virtual Machine (JVM) nasazených více aplikací a chcete, aby odesílaly telemetrii do různých připojovací řetězec, přečtěte si téma Přepsání připojovacího řetězce (Preview).
Název cloudové role
Název cloudové role slouží k označení komponenty na mapě aplikace.
Pokud chcete nastavit název cloudové role:
{
"role": {
"name": "my cloud role name"
}
}
Pokud název cloudové role není nastavený, název prostředku Application Insights se použije k označení komponenty na mapě aplikace.
Název cloudové role můžete také nastavit pomocí proměnné APPLICATIONINSIGHTS_ROLE_NAME
prostředí . Potom má přednost před názvem cloudové role zadaným v konfiguraci JSON.
Nebo můžete název cloudové role nastavit pomocí systémové vlastnosti applicationinsights.role.name
Java . Má také přednost před názvem cloudové role zadané v konfiguraci JSON.
Pokud máte ve stejném prostředí JVM nasazených více aplikací a chcete, aby odesílaly telemetrii do různých názvů cloudových rolí, přečtěte si téma Přepsání názvu cloudové role (Preview).
Instance cloudové role
Instance cloudové role ve výchozím nastavení odkazuje na název počítače.
Pokud chcete nastavit instanci cloudové role na něco jiného než název počítače:
{
"role": {
"name": "my cloud role name",
"instance": "my cloud role instance"
}
}
Instanci cloudové role můžete také nastavit pomocí proměnné APPLICATIONINSIGHTS_ROLE_INSTANCE
prostředí . Potom má přednost před instancí cloudové role zadanou v konfiguraci JSON.
Nebo můžete nastavit instanci cloudové role pomocí vlastnosti applicationinsights.role.instance
systému Java .
Má také přednost před instancí cloudové role zadanou v konfiguraci JSON.
Vzorkování
Poznámka:
Vzorkování může být skvělý způsob, jak snížit náklady na Application Insights. Ujistěte se, že pro váš případ použití správně nastavíte konfiguraci vzorkování.
Vzorkování je založené na požadavku, což znamená, že pokud je požadavek zachycený (vzorkovaný), jsou tedy jeho závislosti, protokoly a výjimky.
Vzorkování je také založené na ID trasování, které pomáhá zajistit konzistentní rozhodování o vzorkování napříč různými službami.
Vzorkování se vztahuje pouze na protokoly uvnitř požadavku. Protokoly, které nejsou uvnitř požadavku (například spouštěcí protokoly), se ve výchozím nastavení shromažďují vždy. Pokud chcete tyto protokoly vzorkovat, můžete použít přepsání vzorkování.
Vzorkování s omezením rychlosti
Od verze 3.4.0 je k dispozici vzorkování s omezením rychlosti a je teď výchozí.
Pokud není nakonfigurované žádné vzorkování, je teď výchozí vzorkování omezené rychlostí nakonfigurované tak, aby zachytilo maximálně (přibližně) pět požadavků za sekundu a všechny závislosti a protokoly těchto požadavků.
Tato konfigurace nahrazuje předchozí výchozí nastavení, které bylo zachytávat všechny požadavky. Pokud stále chcete zaznamenávat všechny požadavky, použijte vzorkování s pevným procentem a nastavte procento vzorkování na 100.
Poznámka:
Vzorkování s omezením rychlosti je přibližné, protože interně musí v průběhu času přizpůsobit "pevné" procento vzorkování, aby bylo možné generovat přesné počty položek na každém záznamu telemetrie. Vzorkování s omezením rychlosti je interně vyladěno tak, aby se rychle přizpůsobilo načítání nových aplikací (0,1 sekund). Z tohoto důvodu byste neměli vidět, že by překročila nakonfigurovanou sazbu o moc, nebo po velmi dlouhou dobu.
Tento příklad ukazuje, jak nastavit vzorkování na zachytávání maximálně (přibližně) jednoho požadavku za sekundu:
{
"sampling": {
"requestsPerSecond": 1.0
}
}
Může requestsPerSecond
to být desítková hodnota, takže ji můžete nakonfigurovat tak, aby v případě potřeby zachytála méně než jeden požadavek za sekundu. Například hodnota 0.5
znamená zachytávání maximálně jednoho požadavku každých 2 sekundy.
Procento vzorkování můžete nastavit také pomocí proměnné APPLICATIONINSIGHTS_SAMPLING_REQUESTS_PER_SECOND
prostředí . Potom má přednost před limitem rychlosti zadaným v konfiguraci JSON.
Vzorkování s pevným procentem
Tento příklad ukazuje, jak nastavit vzorkování tak, aby zachytilo přibližně třetinu všech požadavků:
{
"sampling": {
"percentage": 33.333
}
}
Procento vzorkování můžete nastavit také pomocí proměnné APPLICATIONINSIGHTS_SAMPLING_PERCENTAGE
prostředí . Potom má přednost před procentem vzorkování zadaným v konfiguraci JSON.
Poznámka:
Pro procento vzorkování zvolte procento, které je blízko 100/N, kde N je celé číslo. Vzorkování v současné době jiné hodnoty nepodporuje.
Přepsání vzorkování
Přepsání vzorkování umožňuje přepsat výchozí procento vzorkování. Je například možné:
- Nastavte procento vzorkování na 0 nebo malou hodnotu pro hlučné kontroly stavu.
- Pro volání hlučné závislosti nastavte procento vzorkování na hodnotu 0 nebo na určitou malou hodnotu.
- Nastavte procento vzorkování na 100 pro důležitý typ požadavku. Můžete například použít
/login
, i když máte výchozí vzorkování nakonfigurované na něco nižšího.
Další informace najdete v dokumentaci k přepsání vzorkování .
Metriky rozšíření pro správu Java
Pokud chcete shromáždit některé další metriky JMX (Java Management Extensions):
{
"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"
}
]
}
V předchozím příkladu konfigurace:
name
je název metriky, který je přiřazen k této metrice JMX (může to být cokoli).objectName
je název objektuJMX MBean
, který chcete shromáždit. Podporuje se hvězdička se zástupnými znaky (*).attribute
je název atributuJMX MBean
uvnitř, který chcete shromáždit.
Podporují se číselné a logické hodnoty metrik JMX. Logické metriky JMX se mapují na 0
hodnotu false a 1
true.
Další informace najdete v dokumentaci k metrikám JMX.
Vlastní dimenze
Pokud chcete do všech telemetrických dat přidat vlastní dimenze:
{
"customDimensions": {
"mytag": "my value",
"anothertag": "${ANOTHER_VALUE}"
}
}
Při spuštění můžete ${...}
číst hodnotu ze zadané proměnné prostředí.
Poznámka:
Od verze 3.0.2 pokud přidáte vlastní dimenzi s názvem service.version
, hodnota je uložena ve application_Version
sloupci v tabulce Protokolů Application Insights místo jako vlastní dimenze.
Zděděný atribut (Preview)
Od verze 3.2.0 můžete pro telemetrii požadavku nastavit vlastní dimenzi prostřednictvím kódu programu. Zajišťuje dědičnost závislostí a telemetrií protokolů. Všechny jsou zachyceny v kontextu tohoto požadavku.
{
"preview": {
"inheritedAttributes": [
{
"key": "mycustomer",
"type": "string"
}
]
}
}
A pak na začátku každé žádosti zavolejte:
Span.current().setAttribute("mycustomer", "xyz");
Viz také: Přidání vlastní vlastnosti do spanu.
Přepsání připojovacího řetězce (Preview)
Tato funkce je ve verzi Preview počínaje verzí 3.4.0.
Přepsání připojovacího řetězce umožňuje přepsat výchozí připojovací řetězec. Je například možné:
- Nastavte jednu připojovací řetězec pro jednu předponu
/myapp1
cesty HTTP . - Nastavte další připojovací řetězec pro jinou předponu
/myapp2/
cesty HTTP .
{
"preview": {
"connectionStringOverrides": [
{
"httpPathPrefix": "/myapp1",
"connectionString": "..."
},
{
"httpPathPrefix": "/myapp2",
"connectionString": "..."
}
]
}
}
Přepsání názvu cloudové role (Preview)
Tato funkce je ve verzi Preview počínaje verzí 3.3.0.
Přepsání názvu cloudové role vám umožní přepsat výchozí název cloudové role. Je například možné:
- Nastavte jeden název cloudové role pro jednu předponu
/myapp1
cesty HTTP . - Nastavte jiný název cloudové role pro jinou předponu
/myapp2/
cesty HTTP .
{
"preview": {
"roleNameOverrides": [
{
"httpPathPrefix": "/myapp1",
"roleName": "Role A"
},
{
"httpPathPrefix": "/myapp2",
"roleName": "Role B"
}
]
}
}
Připojovací řetězec nakonfigurovaný za běhu
Od verze 3.4.8, pokud potřebujete možnost nakonfigurovat připojovací řetězec za běhu, přidejte tuto vlastnost do konfigurace JSON:
{
"connectionStringConfiguredAtRuntime": true
}
Přidejte applicationinsights-core
do aplikace:
<dependency>
<groupId>com.microsoft.azure</groupId>
<artifactId>applicationinsights-core</artifactId>
<version></version>
</dependency>
Použijte statickou configure(String)
metodu ve třídě com.microsoft.applicationinsights.connectionstring.ConnectionString
.
Poznámka:
Veškerá telemetrie zachycená před konfigurací připojovací řetězec se zahodí, takže je nejlepší ji co nejdříve nakonfigurovat při spuštění aplikace.
Automatické závislosti inProc (Preview)
Od verze 3.2.0 použijte následující konfiguraci, pokud chcete zachytit závislosti kontroleru InProc:
{
"preview": {
"captureControllerSpans": true
}
}
Zavaděč sady SDK prohlížeče (Preview)
Tato funkce automaticky vloží zavaděč sady Browser SDK na stránky HTML vaší aplikace, včetně konfigurace příslušného připojovacího řetězce.
Například když vaše aplikace v Javě vrátí odpověď jako:
<!DOCTYPE html>
<html lang="en">
<head>
<title>Title</title>
</head>
<body>
</body>
</html>
Automaticky upraví, aby se vrátil:
<!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>
Skript se zaměřuje na pomoc zákazníkům sledovat data webových uživatelů a odesílat shromažďování telemetrických dat na straně serveru zpět na portál Azure Portal uživatelů. Podrobnosti najdete na webu ApplicationInsights-JS.
Pokud chcete tuto funkci povolit, přidejte následující možnost konfigurace:
{
"preview": {
"browserSdkLoader": {
"enabled": true
}
}
}
Procesory telemetrie (Preview)
Pomocí procesorů telemetrie můžete nakonfigurovat pravidla, která se použijí pro požadavky, závislost a trasování telemetrie. Je například možné:
- Maskovat citlivá data.
- Podmíněně přidejte vlastní dimenze.
- Aktualizujte název rozsahu, který se používá k agregaci podobné telemetrie na webu Azure Portal.
- Zahoďte konkrétní atributy rozsahu, abyste mohli řídit náklady na příjem dat.
Další informace najdete v dokumentaci k procesoru telemetrie.
Poznámka:
Pokud chcete pro řízení nákladů na příjem dat vynechat určité (celé) rozsahy, přečtěte si téma Přepsání vzorkování.
Vlastní instrumentace (Preview)
Počínaje verzí 3.3.1 můžete zachytit rozsahy pro metodu v aplikaci:
{
"preview": {
"customInstrumentation": [
{
"className": "my.package.MyClass",
"methodName": "myMethod"
}
]
}
}
Místní zakázání vzorkování příjmu dat (Preview)
Ve výchozím nastavení platí, že pokud je efektivní procento vzorkování v agentu Java 100 % a vzorkování příjmu dat je nakonfigurované u vašeho prostředku Application Insights, použije se procento vzorkování příjmu dat.
Všimněte si, že toto chování platí pro vzorkování s pevnou rychlostí 100 % a vztahuje se také na vzorkování s omezenou rychlostí, pokud frekvence požadavků nepřekračuje limit rychlosti (efektivně zachycuje 100 % během průběžného klouzavého časového intervalu).
Od verze 3.5.3 můžete toto chování zakázat (a v těchto případech zachovat 100 % telemetrie i v případě, že je u prostředku Application Insights nakonfigurované vzorkování příjmu):
{
"preview": {
"sampling": {
"ingestionSamplingEnabled": false
}
}
}
Automatické protokolování
Log4j, Logback, JBoss Logging a java.util.logging jsou automaticky instrumentované. Protokolování prováděné prostřednictvím těchto rozhraní protokolování se automaticky shromažďuje.
Protokolování se zaznamenává pouze v případě, že:
- Splňuje nakonfigurovanou úroveň pro architekturu protokolování.
- Splňuje také nakonfigurovanou úroveň pro Application Insights.
Pokud je například vaše architektura protokolování nakonfigurovaná tak, aby protokolovala WARN
(a vy jste ji nakonfigurovali tak, jak je popsáno výše) z balíčku com.example
a služba Application Insights je nakonfigurovaná tak, aby zachytila INFO
(a podle popisu jste ji nakonfigurovali), Služba Application Insights z balíčku com.example
zachycuje WARN
(a je vážnější).
Výchozí úroveň nakonfigurovaná pro Application Insights je INFO
. Pokud chcete změnit tuto úroveň:
{
"instrumentation": {
"logging": {
"level": "WARN"
}
}
}
Úroveň můžete nastavit také pomocí proměnné APPLICATIONINSIGHTS_INSTRUMENTATION_LOGGING_LEVEL
prostředí . Potom má přednost před úrovní zadanou v konfiguraci JSON.
Tyto platné level
hodnoty můžete použít k zadání v applicationinsights.json
souboru. Tabulka ukazuje, jak odpovídají úrovním protokolování v různých rozhraních protokolování.
Level | Log4j | Zpětný protokol | JBoss | ČERVENEC |
---|---|---|---|---|
OFF | OFF | OFF | OFF | OFF |
FATÁLNÍ | FATÁLNÍ | CHYBA | FATÁLNÍ | HROZNĚ |
CHYBA (nebo ZÁVAŽNÁ) | CHYBA | CHYBA | CHYBA | HROZNĚ |
UPOZORNĚNÍ (nebo UPOZORNĚNÍ) | VAROVAT | VAROVAT | VAROVAT | UPOZORNĚNÍ |
INFO | INFO | INFO | INFO | INFO |
KONFIGURACE | LADIT | LADIT | LADIT | KONFIGURACE |
LADĚNÍ (nebo FINE) | LADIT | LADIT | LADIT | POKUTA |
JEMNĚJŠÍ | LADIT | LADIT | LADIT | JEMNĚJŠÍ |
TRACE (nebo FINEST) | TRACE | TRACE | TRACE | NEJLEPŠÍ |
ALL | ALL | ALL | ALL | ALL |
Poznámka:
Pokud se protokolovacímu nástroji předá objekt výjimky, zobrazí se zpráva protokolu (a podrobnosti o objektu výjimky) na webu Azure Portal pod exceptions
tabulkou místo traces
tabulky. Pokud chcete zobrazit zprávy protokolu v obou traces
tabulkách i exceptions
v tabulkách, můžete napsat dotaz Protokoly (Kusto), který je sjednocuje. Příklad:
union traces, (exceptions | extend message = outerMessage)
| project timestamp, message, itemType
Značky protokolů (Preview)
Od verze 3.4.2 můžete zaznamenat značky protokolu pro logback a Log4j 2:
{
"preview": {
"captureLogbackMarker": true,
"captureLog4jMarker": true
}
}
Další atributy protokolu pro Logback (Preview)
Od verze 3.4.3 můžete zachytit FileName
ClassName
, , MethodName
, a LineNumber
, pro logback:
{
"preview": {
"captureLogbackCodeAttributes": true
}
}
Upozorňující
Zachytávání atributů kódu může vyžadovat režii na výkon.
Úroveň protokolování jako vlastní dimenze
Počínaje verzí 3.3.0 se ve výchozím nastavení nezachytí jako součást vlastní dimenze Trasování, LoggingLevel
protože tato data jsou už v SeverityLevel
poli zachycená.
V případě potřeby můžete dočasně znovu povolit předchozí chování:
{
"preview": {
"captureLoggingLevelAsCustomDimension": true
}
}
Metriky mikrometrů s automatickým kolektovanými metrikami (včetně metrik poháněcího zařízení Spring Boot)
Pokud vaše aplikace používá Micrometer, metriky, které se odesílají do globálního registru Micrometer, se automaticky kompletují.
Pokud vaše aplikace používá ovladač Spring Boot, metriky nakonfigurované ovladačem Spring Boot jsou také automaticky nakonfigurovány.
Odeslání vlastních metrik pomocí mikrometru:
Přidejte do aplikace mikrometr, jak je znázorněno v následujícím příkladu.
<dependency> <groupId>io.micrometer</groupId> <artifactId>micrometer-core</artifactId> <version>1.6.1</version> </dependency>
Pomocí globálního registru Micrometer vytvořte měřič, jak je znázorněno v následujícím příkladu.
static final Counter counter = Metrics.counter("test.counter");
Pomocí čítače můžete zaznamenávat metriky pomocí následujícího příkazu.
counter.increment();
Metriky se ingestují do tabulky customMetrics se značkami zachycenými ve sloupci
customDimensions
. Metriky můžete zobrazit také v Průzkumníku metrik vLog-based metrics
oboru názvů metrik.Poznámka:
Application Insights Java nahrazuje všechny nealnumerické znaky (s výjimkou pomlček) v názvu metriky Micrometer podtržítkami. V důsledku toho se předchozí
test.counter
metrika zobrazí jakotest_counter
.
Zakázání automatického shromažďování metrik mikrometrů a metrik poháněcího zařízení Spring Boot:
Poznámka:
Vlastní metriky se účtují samostatně a můžou generovat další náklady. Nezapomeňte zkontrolovat informace o cenách. Pokud chcete zakázat metriky mikrometrů a ovladače Spring Boot, přidejte do konfiguračního souboru následující konfiguraci.
{
"instrumentation": {
"micrometer": {
"enabled": false
}
}
}
Maskování dotazů připojení k databázi v Javě
Hodnoty literálů v dotazech JDBC (Java Database Connectivity) se ve výchozím nastavení maskují, aby nedocházelo k náhodnému zachycení citlivých dat.
Od verze 3.4.0 je možné toto chování zakázat. Příklad:
{
"instrumentation": {
"jdbc": {
"masking": {
"enabled": false
}
}
}
}
Maskování dotazů Mongo
Hodnoty literálů v dotazech Mongo se ve výchozím nastavení maskují, aby nedošlo k náhodnému zachycení citlivých dat.
Od verze 3.4.0 je možné toto chování zakázat. Příklad:
{
"instrumentation": {
"mongo": {
"masking": {
"enabled": false
}
}
}
}
Záhlaví HTTP
Od verze 3.3.0 můžete zaznamenat hlavičky požadavků a odpovědí na telemetrii serveru (požadavku):
{
"preview": {
"captureHttpServerHeaders": {
"requestHeaders": [
"My-Header-A"
],
"responseHeaders": [
"My-Header-B"
]
}
}
}
Názvy záhlaví nerozlišují malá a velká písmena.
Předchozí příklady jsou zachyceny pod názvy http.request.header.my_header_a
vlastností a http.response.header.my_header_b
.
Podobně můžete zaznamenávat hlavičky požadavků a odpovědí v telemetrii klienta (závislostí):
{
"preview": {
"captureHttpClientHeaders": {
"requestHeaders": [
"My-Header-C"
],
"responseHeaders": [
"My-Header-D"
]
}
}
}
Názvy záhlaví opět nerozlišují malá a velká písmena. Předchozí příklady jsou zachyceny pod názvy http.request.header.my_header_c
vlastností a http.response.header.my_header_d
.
Kódy odpovědí serveru HTTP 4xx
Ve výchozím nastavení se požadavky serveru HTTP, které vedou k kódům odpovědí 4xx, zaznamenávají jako chyby.
Od verze 3.3.0 můžete toto chování změnit, abyste je zachytili jako úspěch:
{
"preview": {
"captureHttpServer4xxAsError": false
}
}
Potlačení konkrétní automatickycollectované telemetrie
Od verze 3.0.3 je možné pomocí těchto možností konfigurace potlačit konkrétní automatickou telemetrii:
{
"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
}
}
}
Tyto instrumentace můžete také potlačit nastavením těchto proměnných prostředí na 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
Tyto proměnné pak mají přednost před povolenými proměnnými zadanými v konfiguraci JSON.
Poznámka:
Pokud hledáte jemněji odstupňované řízení, například potlačení některých volání Redis, ale ne všechna volání Redis, přečtěte si téma Přepsání vzorkování.
Instrumentace ve verzi Preview
Od verze 3.2.0 můžete povolit následující instrumentace ve verzi Preview:
{
"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
}
}
}
}
Poznámka:
Instrumentace Akka je dostupná od verze 3.2.2. Instrumentace knihovny HTTP Vertx je dostupná od verze 3.3.0.
Interval metriky
Ve výchozím nastavení se metriky zaznamenávají každých 60 sekund.
Od verze 3.0.3 můžete tento interval změnit:
{
"metricIntervalSeconds": 300
}
Od verze 3.4.9 GA můžete také nastavit metricIntervalSeconds
pomocí proměnné APPLICATIONINSIGHTS_METRIC_INTERVAL_SECONDS
prostředí . Potom má přednost před zadaným metricIntervalSeconds
v konfiguraci JSON.
Toto nastavení platí pro následující metriky:
- Výchozí čítače výkonu: Například procesor a paměť
- Výchozí vlastní metriky: Například časování uvolňování paměti
- Nakonfigurované metriky JMX: Viz část metrikY JMX
- Metriky mikrometrů: Viz část Metriky autocollected Micrometer
Srdeční tep
Application Insights Java 3.x ve výchozím nastavení odesílá metriku prezenčních signálů jednou za 15 minut. Pokud k aktivaci upozornění používáte metriku prezenčních signálů, můžete zvýšit frekvenci tohoto prezenčních signálu:
{
"heartbeat": {
"intervalSeconds": 60
}
}
Poznámka:
Interval nemůžete prodloužit na déle než 15 minut, protože data prezenčních signálů se také používají ke sledování využití Application Insights.
Ověřování
Poznámka:
Funkce ověřování je obecně dostupná od verze 3.4.17.
Ověřování můžete použít ke konfiguraci agenta tak, aby vygeneroval přihlašovací údaje tokenu, které jsou vyžadovány pro ověřování Microsoft Entra. Další informace najdete v dokumentaci k ověřování .
Proxy server HTTP
Pokud je vaše aplikace za bránou firewall a nemůže se připojit přímo k Application Insights, projděte si IP adresy používané application Insights.
Tento problém můžete vyřešit tak, že nakonfigurujete Application Insights Java 3.x tak, aby používal proxy server HTTP.
{
"proxy": {
"host": "myproxy",
"port": 8080
}
}
Můžete také nastavit proxy http pomocí proměnné APPLICATIONINSIGHTS_PROXY
prostředí , která přebírá formát https://<host>:<port>
. Potom má přednost před proxy serverem zadaným v konfiguraci JSON.
Pro proxy server můžete zadat uživatele a heslo s APPLICATIONINSIGHTS_PROXY
proměnnou prostředí: https://<user>:<password>@<host>:<port>
.
Application Insights Java 3.x také respektuje globální https.proxyHost
a https.proxyPort
systémové vlastnosti, pokud jsou nastavené, a http.nonProxyHosts
v případě potřeby.
Obnovení ze selhání příjmu dat
Při odesílání telemetrie do služby Application Insights selže, Application Insights Java 3.x ukládá telemetrii na disk a pokračuje v opakování z disku.
Výchozí limit trvalosti disku je 50 Mb. Pokud máte velký objem telemetrie nebo potřebujete být schopni se zotavit z delších výpadků sítě nebo služby příjmu dat, můžete tento limit zvýšit od verze 3.3.0:
{
"preview": {
"diskPersistenceMaxSizeMb": 50
}
}
Samoobslužná diagnostika
"Samoobslužná diagnostika" odkazuje na interní protokolování z Application Insights Java 3.x. Tato funkce může být užitečná pro zjišťování a diagnostiku problémů se samotnou službou Application Insights.
Application Insights Java 3.x ve výchozím nastavení protokoluje na úrovni INFO
souboru applicationinsights.log
i konzoly odpovídající této konfiguraci:
{
"selfDiagnostics": {
"destination": "file+console",
"level": "INFO",
"file": {
"path": "applicationinsights.log",
"maxSizeMb": 5,
"maxHistory": 1
}
}
}
V předchozím příkladu konfigurace:
level
může být jedním zOFF
, ,ERROR
,INFO
WARN
, ,DEBUG
neboTRACE
.path
může být absolutní nebo relativní cesta. Relativní cesty se přeloží na adresář, ve kterémapplicationinsights-agent-3.6.2.jar
se nachází.
Počínaje verzí 3.0.2 můžete také nastavit samoobslužnou diagnostiku level
pomocí proměnné APPLICATIONINSIGHTS_SELF_DIAGNOSTICS_LEVEL
prostředí . Potom má přednost před úrovní samoobslužné diagnostiky zadanou v konfiguraci JSON.
Od verze 3.0.3 můžete také nastavit umístění souboru samoobslužné diagnostiky pomocí proměnné APPLICATIONINSIGHTS_SELF_DIAGNOSTICS_FILE_PATH
prostředí . Potom má přednost před cestou k souboru samoobslužné diagnostiky zadané v konfiguraci JSON.
Korelace telemetrie
Korelace telemetrie je ve výchozím nastavení povolená, ale můžete ji zakázat v konfiguraci.
{
"preview": {
"disablePropagation": true
}
}
Příklad
Tento příklad ukazuje, jak konfigurační soubor vypadá s více komponentami. Nakonfigurujte konkrétní možnosti na základě vašich potřeb.
{
"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
}
}
}