Možnosti konfigurace: Přehledy aplikace Služby Azure Monitor pro Javu

V tomto článku se dozvíte, jak nakonfigurovat aplikační Přehledy služby Azure Monitor pro Javu.

Připojení ionový řetězec a název role

Připojení ř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řipojení ř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 Přehledy aplikace.

Další informace a možnosti konfigurace najdete v následujících částech.

Cesta ke konfiguračnímu souboru

Aplikace Přehledy Java 3.x ve výchozím nastavení očekává, že konfigurační soubor bude pojmenovaný applicationinsights.jsona bude umístěn ve stejném adresáři jako applicationinsights-agent-3.5.1.jar.

Pomocí jedné z těchto dvou možností můžete zadat vlastní cestu ke konfiguračnímu souboru:

• APPLICATIONINSIGHTS_CONFIGURATION_FILE proměnná prostředí
• applicationinsights.configuration.file Systémová vlastnost Java

Pokud zadáte relativní cestu, přeloží se vzhledem k adresáři, ve kterém applicationinsights-agent-3.5.1.jar se nachází.

Alternativně můžete místo použití konfiguračního souboru zadat celý obsah konfigurace JSON prostřednictvím proměnné APPLICATIONINSIGHTS_CONFIGURATION_CONTENTprostředí .

Connection string

Připojení řetězec je povinný. Připojovací řetězec najdete v prostředku Přehledy aplikace.

{
  "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.5.1.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, podívejte se na Připojení ionové přepsání řetězců (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 Přehledy aplikace 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 Přehledy aplikací. 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 Application Přehledy Logs 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í řetězce Připojení (Preview)

Tato funkce je ve verzi Preview počínaje verzí 3.4.0.

přepsání řetězce Připojení 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řipojení ionový ř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>3.5.1</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 řetězce Připojení ionu.

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 v souboru Application Přehledy-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í.

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 Přehledy aplikace.

Pokud je například vaše architektura protokolování nakonfigurovaná tak, aby se protokolovala WARN (a vy jste ji nakonfigurovali tak, jak je popsáno výše) z balíčku com.examplea aplikace Přehledy je nakonfigurovaná tak, aby zachytila INFO (a jak je popsáno), aplikace Přehledy pouze zachytává WARN (a vážněji) z balíčku com.example.

Výchozí úroveň nakonfigurovaná pro Přehledy aplikace 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Í	ZÁVAŽNÉ
CHYBA (nebo ZÁVAŽNÁ)	CHYBA	CHYBA	CHYBA	ZÁVAŽNÉ
UPOZORNĚNÍ (nebo UPOZORNĚNÍ)	VAROVAT	VAROVAT	VAROVAT	UPOZORNĚNÍ
INFO	INFO	INFO	INFO	INFO
CONFIG	LADIT	LADIT	LADIT	CONFIG
LADĚNÍ (nebo FINE)	LADIT	LADIT	LADIT	POŘÁDKU
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:

   Aplikace Přehledy Javě nahradí všechny nealnumerické znaky (kromě 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í ivity v Javě Database

Hodnoty literálů v dotazech Java Database Připojení ivity (JDBC) se ve výchozím nastavení maskují, aby nedocházelo k náhodnému zachytávání 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
    },
    "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_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:

• 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

Tep

Aplikace Přehledy 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 používají také ke sledování využití Přehledy aplikací.

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 Přehledy aplikace, projděte si IP adresy používané Přehledy aplikací.

Tento problém můžete vyřešit tak, že nakonfigurujete aplikaci Přehledy Java 3.x tak, aby používala 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.

Aplikace Přehledy 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 Přehledy service selže, aplikace Přehledy Javě 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 aplikace Přehledy Java 3.x. Tato funkce může být užitečná při zjišťování a diagnostice problémů s Přehledy aplikací.

Ve výchozím nastavení aplikace Přehledy protokoly Java 3.x na úrovni INFO souboru i applicationinsights.log konzoly, které odpovídají 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.5.1.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.

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