Konfigurationsalternativ: Azure Monitor Application Insights för Java

Den här artikeln visar hur du konfigurerar Azure Monitor Application Insights för Java.

Anslutningssträng och rollnamn

Anslutningssträngen och rollnamnet är de vanligaste inställningarna du behöver för att komma igång:

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

Anslutningssträng krävs. Rollnamnet är viktigt när du skickar data från olika program till samma Application Insights-resurs.

Mer information och konfigurationsalternativ finns i följande avsnitt.

Konfigurationskonfiguration för JSON

Standardkonfiguration

Som standard förväntar sig Application Insights Java 3 att konfigurationsfilen namnges applicationinsights.json och finns i samma katalog som applicationinsights-agent-3.6.2.jar.

Alternativa konfigurationer

Anpassad konfigurationsfil

Du kan ange en anpassad konfigurationsfil med

• miljövariabeln APPLICATIONINSIGHTS_CONFIGURATION_FILE eller
• systemegenskapen applicationinsights.configuration.file

Om du anger en relativ sökväg matchas den i förhållande till katalogen där applicationinsights-agent-3.6.0.jar finns.

JSON-konfiguration

I stället för att använda en konfigurationsfil kan du ange hela JSON-konfigurationen med:

• miljövariabeln APPLICATIONINSIGHTS_CONFIGURATION_CONTENT eller
• systemegenskapen applicationinsights.configuration.content

Connection string

Anslutningssträng krävs. Du hittar din anslutningssträng i Application Insights-resursen.

{
  "connectionString": "..."
}

Du kan också ange anslutningssträng med hjälp av miljövariabeln APPLICATIONINSIGHTS_CONNECTION_STRING. Den har sedan företräde framför de anslutningssträng som anges i JSON-konfigurationen.

Eller så kan du ange anslutningssträng med hjälp av Java-systemegenskapen applicationinsights.connection.string. Det har också företräde framför de anslutningssträng som anges i JSON-konfigurationen.

Du kan också ange anslutningssträng genom att ange en fil som du vill läsa in anslutningssträng från.

Om du anger en relativ sökväg matchas den i förhållande till katalogen där applicationinsights-agent-3.6.2.jar den finns.

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

Filen ska bara innehålla anslutningssträng och inget annat.

Om du inte anger anslutningssträng inaktiveras Java-agenten.

Om du har flera program som har distribuerats i samma JVM (Java Virtual Machine) och vill att de ska skicka telemetri till olika anslutningssträng läser du åsidosättningar av anslutningssträngar (förhandsversion).

Namn på molnroll

Namnet på molnrollen används för att märka komponenten på programkartan.

Om du vill ange namnet på molnrollen:

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

Om namnet på molnrollen inte har angetts används Application Insights-resursens namn för att märka komponenten på programkartan.

Du kan också ange namnet på molnrollen med hjälp av miljövariabeln APPLICATIONINSIGHTS_ROLE_NAME. Det har sedan företräde framför det molnrollnamn som anges i JSON-konfigurationen.

Eller så kan du ange namnet på molnrollen med hjälp av Java-systemegenskapen applicationinsights.role.name. Det har också företräde framför det molnrollnamn som anges i JSON-konfigurationen.

Om du har flera program distribuerade i samma JVM och vill att de ska skicka telemetri till olika molnrollnamn kan du läsa åsidosättningar av molnrollnamn (förhandsversion).

Instans av molntjänstroll

Molnrollinstansen är som standard datornamnet.

Om du vill ange molnrollinstansen till något annat än datornamnet:

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

Du kan också ange molnrollinstansen med hjälp av miljövariabeln APPLICATIONINSIGHTS_ROLE_INSTANCE. Den har sedan företräde framför den molnrollinstans som anges i JSON-konfigurationen.

Eller så kan du ange molnrollinstansen med hjälp av Java-systemegenskapen applicationinsights.role.instance. Den har också företräde framför den molnrollinstans som anges i JSON-konfigurationen.

Sampling

Kommentar

Sampling kan vara ett bra sätt att minska kostnaden för Application Insights. Se till att konfigurera samplingskonfigurationen på rätt sätt för ditt användningsfall.

Sampling baseras på begäran, vilket innebär att om en begäran samlas in (samplas), så är även dess beroenden, loggar och undantag.

Samplingen baseras också på spårnings-ID för att säkerställa konsekventa samplingsbeslut för olika tjänster.

Sampling gäller endast för loggar i en begäran. Loggar som inte finns i en begäran (till exempel startloggar) samlas alltid in som standard. Om du vill prova loggarna kan du använda samplings åsidosättningar.

Frekvensbegränsad sampling

Från och med 3.4.0 är hastighetsbegränsad sampling tillgänglig och är nu standard.

Om ingen sampling har konfigurerats är standardinställningen nu hastighetsbegränsad sampling som konfigurerats för att samla in högst (cirka) fem begäranden per sekund, tillsammans med alla beroenden och loggar på dessa begäranden.

Den här konfigurationen ersätter den tidigare standardinställningen, som var att samla in alla begäranden. Om du fortfarande vill samla in alla begäranden använder du sampling med fast procentandel och anger samplingsprocenten till 100.

Kommentar

Den hastighetsbegränsade samplingen är ungefärlig eftersom den internt måste anpassa en "fast" samplingsprocent över tid för att generera korrekta antal objekt på varje telemetripost. Internt justeras den hastighetsbegränsade samplingen så att den snabbt (0,1 sekunder) anpassas till nya programbelastningar. Därför bör du inte se att den överskrider den konfigurerade hastigheten med mycket, eller så länge.

Det här exemplet visar hur du ställer in samplingen så att den samlar in högst (ungefär) en begäran per sekund:

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

requestsPerSecond Kan vara en decimal, så du kan konfigurera den för att samla in mindre än en begäran per sekund om du vill. Till exempel ett värde för 0.5 means capture på högst en begäran var 2:e sekund.

Du kan också ange samplingsprocenten med hjälp av miljövariabeln APPLICATIONINSIGHTS_SAMPLING_REQUESTS_PER_SECOND. Den har sedan företräde framför den hastighetsgräns som anges i JSON-konfigurationen.

Sampling med fast procent

Det här exemplet visar hur du ställer in samplingen för att samla in ungefär en tredjedel av alla begäranden:

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

Du kan också ange samplingsprocenten med hjälp av miljövariabeln APPLICATIONINSIGHTS_SAMPLING_PERCENTAGE. Den har sedan företräde framför den samplingsprocent som anges i JSON-konfigurationen.

Kommentar

För samplingsprocenten väljer du en procentandel som är nära 100/N, där N är ett heltal. Sampling stöder för närvarande inte andra värden.

Åsidosättningar av sampling

Med samplings åsidosättningar kan du åsidosätta standardsamplingsprocenten. Du kan till exempel:

• Ange samplingsprocenten till 0, eller något litet värde, för brusande hälsokontroller.
• Ange samplingsprocenten till 0, eller något litet värde, för störande beroendeanrop.
• Ange samplingsprocenten till 100 för en viktig typ av begäran. Du kan till exempel använda /login även om standardsampling har konfigurerats till något lägre.

Mer information finns i dokumentationen om samplings åsidosättningar .

Mått för Java-hanteringstillägg

Om du vill samla in några andra JMX-mått (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"
    }
  ]
}

I föregående konfigurationsexempel:

• name är måttnamnet som har tilldelats det här JMX-måttet (kan vara vad som helst).
• objectNameär objektnamnet för det JMX MBean som du vill samla in. Jokerteckenasterisk (*) stöds.
• attribute är attributnamnet i det JMX MBean som du vill samla in.

Numeriska och booleska JMX-måttvärden stöds. Booleska JMX-mått mappas till 0 för false och 1 true.

Mer information finns i JMX-måttdokumentationen.

Anpassade dimensioner

Om du vill lägga till anpassade dimensioner i all telemetri:

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

Du kan använda ${...} för att läsa värdet från den angivna miljövariabeln vid start.

Kommentar

Från och med version 3.0.2 lagras värdet i kolumnen i application_Version tabellen Application Insights-loggar i stället för som en anpassad dimension om du lägger till en anpassad dimension med namnet service.version.

Ärvt attribut (förhandsversion)

Från och med version 3.2.0 kan du ange en anpassad dimension programmatiskt på din telemetri för begäran. Det säkerställer arv efter beroende och loggtelemetri. Alla samlas in i kontexten för den begäran.

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

I början av varje begäran anropar du sedan:

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

Se även: Lägg till en anpassad egenskap i ett spann.

Åsidosättningar av anslutningssträngar (förhandsversion)

Den här funktionen är i förhandsversion från 3.4.0.

Med åsidosättningar av anslutningssträngar kan du åsidosätta standard anslutningssträng. Du kan till exempel:

• Ange en anslutningssträng för ett HTTP-sökvägsprefix /myapp1.
• Ange ett annat anslutningssträng för ett annat HTTP-sökvägsprefix /myapp2/.

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

Åsidosättningar av molnrollnamn (förhandsversion)

Den här funktionen är i förhandsversion från 3.3.0.

Med åsidosättningar av molnrollen kan du åsidosätta standardnamnet för molnrollen. Du kan till exempel:

• Ange ett molnrollnamn för ett HTTP-sökvägsprefix /myapp1.
• Ange ett annat molnrollnamn för ett annat HTTP-sökvägsprefix /myapp2/.

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

Anslutningssträng som konfigurerats vid körning

Från och med version 3.4.8 lägger du till den här egenskapen i json-konfigurationen om du behöver kunna konfigurera anslutningssträng vid körning:

{
  "connectionStringConfiguredAtRuntime": true
}

Lägg till applicationinsights-core i ditt program:

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

Använd den statiska configure(String) metoden i klassen com.microsoft.applicationinsights.connectionstring.ConnectionString.

Kommentar

All telemetri som samlas in innan du konfigurerar anslutningssträng tas bort, så det är bäst att konfigurera den så tidigt som möjligt i programstarten.

Autocollect InProc-beroenden (förhandsversion)

Från och med version 3.2.0 använder du följande konfiguration om du vill samla in kontrollantens "InProc"-beroenden:

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

Browser SDK Loader (förhandsversion)

Den här funktionen matar automatiskt in webbläsarens SDK-inläsare i programmets HTML-sidor, inklusive att konfigurera lämplig anslutningssträng.

Till exempel när java-programmet returnerar ett svar som:

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

Den ändrar automatiskt för att returnera:

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

Skriptet syftar till att hjälpa kunder att spåra webbanvändardata och skicka insamlingen av telemetri på serversidan tillbaka till användarnas Azure Portal. Information finns på ApplicationInsights-JS.

Om du vill aktivera den här funktionen lägger du till konfigurationsalternativet nedan:

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

Telemetriprocessorer (förhandsversion)

Du kan använda telemetriprocessorer för att konfigurera regler som tillämpas på telemetri för begäran, beroende och spårning. Du kan till exempel:

• Maskera känsliga data.
• Lägg till anpassade dimensioner villkorligt.
• Uppdatera span-namnet, som används för att aggregera liknande telemetri i Azure Portal.
• Ta bort specifika span-attribut för att kontrollera inmatningskostnader.

Mer information finns i dokumentationen om telemetriprocessorn .

Kommentar

Om du vill ta bort specifika (hela) intervall för att kontrollera inmatningskostnaden läser du Samplings åsidosättningar.

Anpassad instrumentation (förhandsversion)

Från och med verion 3.3.1 kan du samla in intervall för en metod i ditt program:

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

Lokalt inaktivera inmatningssampling (förhandsversion)

När den effektiva samplingsprocenten i Java-agenten som standard är 100 % och inmatningssampling har konfigurerats på Application Insights-resursen tillämpas samplingsprocenten för inmatning.

Observera att det här beteendet gäller för både fast sampling på 100 % och gäller även för frekvensbegränsad sampling när begärandefrekvensen inte överskrider hastighetsgränsen (vilket effektivt fångar upp 100 % under den kontinuerligt glidande tidsperioden).

Från och med 3.5.3 kan du inaktivera det här beteendet (och behålla 100 % av telemetrin i dessa fall även när inmatningssampling har konfigurerats på application insights-resursen):

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

Automatisk insamling av loggning

Log4j, Logback, JBoss-loggning och java.util.logging instrumenteras automatiskt. Loggning som utförs via dessa loggningsramverk samlas in automatiskt.

Loggning registreras endast om den:

• Uppfyller den konfigurerade nivån för loggningsramverket.
• Uppfyller även den konfigurerade nivån för Application Insights.

Om ditt loggningsramverk till exempel har konfigurerats för att logga WARN (och du konfigurerade det enligt beskrivningen tidigare) från paketet com.exampleoch Application Insights har konfigurerats för att avbilda INFO (och du har konfigurerat enligt beskrivningen), samlar Application Insights bara in WARN (och allvarligare) från paketet com.example.

Standardnivån som konfigurerats för Application Insights är INFO. Om du vill ändra den här nivån:

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

Du kan också ange nivån med hjälp av miljövariabeln APPLICATIONINSIGHTS_INSTRUMENTATION_LOGGING_LEVEL. Den har sedan företräde framför den nivå som anges i JSON-konfigurationen.

Du kan använda dessa giltiga level värden för att ange i applicationinsights.json filen. Tabellen visar hur de motsvarar loggningsnivåer i olika loggningsramverk.

Nivå	Log4j	Tillbakaloggning	JBoss	JUL
OFF	OFF	OFF	OFF	OFF
DÖDLIG	DÖDLIG	ERROR	DÖDLIG	SEVERE
FEL (eller ALLVARLIGT)	ERROR	ERROR	ERROR	SEVERE
VARNA (eller VARNING)	VARNA	VARNA	VARNA	WARNING
INFO	INFO	INFO	INFO	INFO
CONFIG	FELSÖKNING	FELSÖKNING	FELSÖKNING	CONFIG
FELSÖKNING (eller FINE)	FELSÖKNING	FELSÖKNING	FELSÖKNING	FINE
FINER	FELSÖKNING	FELSÖKNING	FELSÖKNING	FINER
TRACE (eller FINEST)	SPÅRNING	SPÅRNING	SPÅRNING	FINEST
ALL	ALL	ALL	ALL	ALL

Kommentar

Om ett undantagsobjekt skickas till loggaren visas loggmeddelandet (och information om undantagsobjektet) i Azure Portal under exceptions tabellen i stället för tabellentraces. Om du vill se loggmeddelandena i både tabellerna traces och exceptions kan du skriva en Kusto-fråga (Logs) för att förena dem. Till exempel:

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

Loggmarkörer (förhandsversion)

Från och med 3.4.2 kan du avbilda loggmarkörerna för Logback och Log4j 2:

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

Andra loggattribut för Logback (förhandsversion)

Från och med 3.4.3 kan du avbilda FileName, ClassName, MethodNameoch , LineNumberför Logback:

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

Varning

Att samla in kodattribut kan ge prestanda.

Loggningsnivå som en anpassad dimension

Från och med version 3.3.0 LoggingLevel registreras inte som standard som en del av den anpassade dimensionen Traces eftersom dessa data redan har samlats in i fältet SeverityLevel .

Om det behövs kan du tillfälligt återaktivera det tidigare beteendet:

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

Autokollected Micrometer metrics (inklusive Spring Boot Actuator-mått)

Om ditt program använder Micrometer samlas mått som skickas till det globala mikrometerregistret automatiskt.

Om ditt program använder Spring Boot-aktuator samlas även mått som konfigurerats av Spring Boot-aktuatorn automatiskt insamlade.

Så här skickar du anpassade mått med hjälp av mikrometer:

1. Lägg till Mikrometer i ditt program enligt följande exempel.

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

2. Använd det globala mikrometerregistret för att skapa en mätare som du ser i följande exempel.

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

3. Använd räknaren för att registrera mått med hjälp av följande kommando.

   counter.increment();
   

4. Måtten matas in i tabellen customMetrics med taggar som samlas in i customDimensions kolumnen. Du kan också visa måtten i måttutforskaren under Log-based metrics måttnamnområdet.

   Kommentar

   Application Insights Java ersätter alla icke-alfanumeriska tecken (utom bindestreck) i måttnamnet Micrometer med understreck. Därför visas föregående test.counter mått som test_counter.

Så här inaktiverar du automatisk insamling av mikrometermått och Spring Boot-aktuatormått:

Kommentar

Anpassade mått faktureras separat och kan generera extra kostnader. Kontrollera prisinformationen. Om du vill inaktivera måtten Micrometer och Spring Boot Actuator lägger du till följande konfiguration i konfigurationsfilen.

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

Frågemaskning för Java Database Connectivity

Literalvärden i JDBC-frågor (Java Database Connectivity) maskeras som standard för att undvika att oavsiktligt samla in känsliga data.

Från och med 3.4.0 kan det här beteendet inaktiveras. Till exempel:

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

Mongo-frågemaskering

Literalvärden i Mongo-frågor maskeras som standard för att undvika att oavsiktligt samla in känsliga data.

Från och med 3.4.0 kan det här beteendet inaktiveras. Till exempel:

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

HTTP-rubriker

Från och med version 3.3.0 kan du samla in begärande- och svarshuvuden på din servertelemetri (begäran):

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

Rubriknamnen är skiftlägesokänsliga.

Föregående exempel samlas in under egenskapsnamnen http.request.header.my_header_a och http.response.header.my_header_b.

På samma sätt kan du samla in begärande- och svarshuvuden på din klienttelemetri (beroende):

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

Återigen är rubriknamnen skiftlägesokänsliga. Föregående exempel samlas in under egenskapsnamnen http.request.header.my_header_c och http.response.header.my_header_d.

HTTP-server 4xx-svarskoder

Som standard registreras HTTP-serverbegäranden som resulterar i 4xx-svarskoder som fel.

Från och med version 3.3.0 kan du ändra det här beteendet så att de fångas upp som lyckade:

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

Utelämna specifik telemetri med automatisk insamling

Från och med version 3.0.3 kan specifik automatisk samlad telemetri ignoreras med hjälp av följande konfigurationsalternativ:

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

Du kan också ignorera dessa instrumentationer genom att ställa in dessa miljövariabler på 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

Dessa variabler har sedan företräde framför de aktiverade variabler som anges i JSON-konfigurationen.

Kommentar

Om du vill ha mer detaljerad kontroll, till exempel för att förhindra vissa redis-anrop men inte alla Redis-anrop, kan du läsa Avsnittet om samplings åsidosättningar.

Förhandsgranska instrumenteringar

Från och med version 3.2.0 kan du aktivera följande förhandsversionsinstrumentationer:

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

Kommentar

Akka-instrumentation är tillgänglig från och med version 3.2.2. Instrumentation för Vertx HTTP-bibliotek är tillgänglig från version 3.3.0.

Måttintervall

Som standard registreras mått var 60:e sekund.

Från och med version 3.0.3 kan du ändra det här intervallet:

{
  "metricIntervalSeconds": 300
}

Från och med 3.4.9 GA kan du också ange metricIntervalSeconds med hjälp av miljövariabeln APPLICATIONINSIGHTS_METRIC_INTERVAL_SECONDS. Den har sedan företräde framför den metricIntervalSeconds som anges i JSON-konfigurationen.

Inställningen gäller för följande mått:

• Standardprestandaräknare: Till exempel CPU och minne
• Anpassade standardmått: Till exempel tidsinställning för skräpinsamling
• Konfigurerade JMX-mått: Se avsnittet JMX-mått
• Mikrometermått: Se avsnittet Autocollected Micrometer metrics (Mått för automatisk insamling av mikrometer)

Pulsslag

Som standard skickar Application Insights Java 3.x ett pulsslagsmått en gång var 15:e minut. Om du använder pulsslagsmåttet för att utlösa aviseringar kan du öka pulsslagets frekvens:

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

Kommentar

Du kan inte öka intervallet till längre än 15 minuter eftersom pulsslagsdata också används för att spåra Application Insights-användning.

Autentisering

Kommentar

Autentiseringsfunktionen är GA sedan version 3.4.17.

Du kan använda autentisering för att konfigurera agenten för att generera tokenautentiseringsuppgifter som krävs för Microsoft Entra-autentisering. Mer information finns i dokumentationen om autentisering .

HTTP-proxy

Om ditt program ligger bakom en brandvägg och inte kan ansluta direkt till Application Insights kan du läsa IP-adresser som används av Application Insights.

Du kan lösa det här problemet genom att konfigurera Application Insights Java 3.x för att använda en HTTP-proxy.

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

Du kan också ange http-proxyn med hjälp av miljövariabeln APPLICATIONINSIGHTS_PROXY, som tar formatet https://<host>:<port>. Den har sedan företräde framför den proxy som anges i JSON-konfigurationen.

Du kan ange en användare och ett lösenord för proxyn med APPLICATIONINSIGHTS_PROXY miljövariabeln: https://<user>:<password>@<host>:<port>.

Application Insights Java 3.x respekterar även de globala https.proxyHost egenskaperna och https.proxyPort systemegenskaperna om de anges och http.nonProxyHosts, om det behövs.

Återställning från inmatningsfel

När telemetri skickas till Application Insights-tjänsten misslyckas lagrar Application Insights Java 3.x telemetrin till disken och fortsätter att försöka igen från disken.

Standardgränsen för diskpersistence är 50 Mb. Om du har hög telemetrivolym eller behöver kunna återställa från längre avbrott i nätverket eller inmatningstjänsten kan du öka den här gränsen från version 3.3.0:

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

Självdiagnostik

"Självdiagnostik" avser intern loggning från Application Insights Java 3.x. Den här funktionen kan vara användbar för att upptäcka och diagnostisera problem med själva Application Insights.

Som standard loggar Application Insights Java 3.x på samma nivå INFO som både filen applicationinsights.log och konsolen, vilket motsvarar den här konfigurationen:

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

I föregående konfigurationsexempel:

• level kan vara en av OFF, ERROR, WARN, INFO, DEBUGeller TRACE.
• path kan vara en absolut eller relativ sökväg. Relativa sökvägar matchas mot katalogen där applicationinsights-agent-3.6.2.jar finns.

Från och med version 3.0.2 kan du också ange självdiagnostik level med hjälp av miljövariabeln APPLICATIONINSIGHTS_SELF_DIAGNOSTICS_LEVEL. Den har sedan företräde framför den självdiagnostiknivå som anges i JSON-konfigurationen.

Från och med version 3.0.3 kan du också ange platsen för självdiagnostikfilen med hjälp av miljövariabeln APPLICATIONINSIGHTS_SELF_DIAGNOSTICS_FILE_PATH. Den har sedan företräde framför den sökväg för självdiagnostikfil som anges i JSON-konfigurationen.

Telemetrikorrelation

Telemetrikorrelation är aktiverat som standard, men du kan inaktivera det i konfigurationen.

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

Ett exempel

Det här exemplet visar hur en konfigurationsfil ser ut med flera komponenter. Konfigurera specifika alternativ baserat på dina behov.

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