Sdílet prostřednictvím


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.

Snímek obrazovky znázorňující připojovací řetězec Application Insights

{
  "connectionString": "..."
}

Můžete také nastavit připojovací řetězec pomocí proměnné APPLICATIONINSIGHTS_CONNECTION_STRINGprostř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.stringsysté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_NAMEprostř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.nameJava . 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_INSTANCEprostř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.instancesysté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_SECONDprostř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_PERCENTAGEprostř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).
  • objectNameje název objektuJMX MBean, který chcete shromáždit. Podporuje se hvězdička se zástupnými znaky (*).
  • attribute je název atributu JMX 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 /myapp1cesty 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 /myapp1cesty 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.examplea služba Application Insights je nakonfigurovaná tak, aby zachytila INFO (a podle popisu jste ji nakonfigurovali), Služba Application Insights z balíčku com.examplezachycuje 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_LEVELprostř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 FileNameClassName, , 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:

  1. 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>
    
  2. 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");
    
  3. Pomocí čítače můžete zaznamenávat metriky pomocí následujícího příkazu.

    counter.increment();
    
  4. Metriky se ingestují do tabulky customMetrics se značkami zachycenými ve sloupci customDimensions . Metriky můžete zobrazit také v Průzkumníku metrik v Log-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í jako test_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_SECONDSprostředí . Potom má přednost před zadaným metricIntervalSeconds v konfiguraci JSON.

Toto nastavení platí pro následující metriky:

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_PROXYprostř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.nonProxyHostsv 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:

  • levelmůže být jedním z OFF, , ERROR, INFOWARN, , DEBUGnebo TRACE.
  • path může být absolutní nebo relativní cesta. Relativní cesty se přeloží na adresář, ve kterém applicationinsights-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_LEVELprostř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_PATHprostř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
    }
  }
}