Opcje konfiguracji: Usługa Azure Monitor Application Insights dla języka Java

W tym artykule pokazano, jak skonfigurować usługę Azure Monitor Application Insights dla języka Java.

Aby uzyskać więcej informacji, zobacz Wprowadzenie do biblioteki OpenTelemetry , która zawiera przykładowe aplikacje.

Parametry połączenia i nazwa roli

Parametry połączenia i nazwa roli to najczęstsze ustawienia, które potrzebujesz, aby rozpocząć.

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

Parametry połączenia są wymagane. Nazwa roli jest ważna w dowolnym momencie wysyłania danych z różnych aplikacji do tego samego zasobu usługi Application Insights.

Więcej informacji i opcji konfiguracji znajduje się w poniższych sekcjach.

Ustawienie konfiguracji JSON

Konfiguracja domyślna

Domyślnie środowisko Java 3 usługi Application Insights oczekuje, że plik konfiguracji ma mieć nazwę applicationinsights.json i znajduje się w tym samym katalogu co applicationinsights-agent-3.7.1.jar.

Konfiguracje alternatywne

Niestandardowy plik konfiguracji

Możesz określić niestandardowy plik konfiguracji.

• zmienna środowiskowa APPLICATIONINSIGHTS_CONFIGURATION_FILE lub
• właściwość systemowa applicationinsights.configuration.file

Jeśli podasz ścieżkę względną, zostanie ona określona w odniesieniu do katalogu, w którym znajduje się applicationinsights-agent-3.7.1.jar.

Konfiguracja JSON

Zamiast używać pliku konfiguracji, można ustawić całą konfigurację JSON za pomocą polecenia:

• zmiennej środowiskowej APPLICATIONINSIGHTS_CONFIGURATION_CONTENT lub
• właściwość systemowa applicationinsights.configuration.content

Ciąg połączenia

Parametry połączenia są wymagane. Parametry połączenia można znaleźć w zasobie usługi Application Insights.

{
  "connectionString": "..."
}

Można również ustawić parametry połączenia przy użyciu zmiennej środowiskowej APPLICATIONINSIGHTS_CONNECTION_STRING. Następnie przyjmuje pierwszeństwo nad ciągiem połączenia określonym w konfiguracji JSON.

Możesz też ustawić parametry połączenia za pomocą właściwości applicationinsights.connection.stringsystemu Java . Ma również pierwszeństwo nad parametrem połączenia określonym w konfiguracji JSON.

Można również ustawić ciąg połączenia, określając plik, z którego ma być załadowany ciąg połączenia.

Jeśli określisz ścieżkę względną, zostanie rozpoznana względem katalogu, w którym applicationinsights-agent-3.7.1.jar się znajduje.

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

Plik powinien zawierać tylko parametry połączenia i nic innego.

Nieustawienie ciągu połączenia wyłącza agenta Java.

Jeśli masz wiele aplikacji wdrożonych na tej samej maszynie wirtualnej Java (JVM) i chcesz, aby wysyłały dane telemetryczne do różnych ciągów połączenia, zobacz Przesłonięcia ciągów połączenia (wersja zapoznawcza).

Nazwa roli chmury

Nazwa roli chmury jest używana do oznaczania składnika na mapie aplikacji.

Jeśli chcesz ustawić nazwę roli w chmurze:

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

Jeśli nazwa roli w chmurze nie jest ustawiona, nazwa zasobu usługi Application Insights jest używana do oznaczania składnika na mapie aplikacji.

Nazwę roli chmury można również ustawić przy użyciu zmiennej środowiskowej APPLICATIONINSIGHTS_ROLE_NAME. Następnie ma pierwszeństwo przed nazwą roli chmury określoną w konfiguracji JSON.

Możesz też ustawić nazwę roli chmury przy użyciu właściwości applicationinsights.role.namesystemu Java . Ma również pierwszeństwo przed nazwą roli chmury określoną w konfiguracji JSON.

Jeśli masz wiele aplikacji wdrożonych w tej samej maszynie JVM i chcesz, aby wysyłały dane telemetryczne do różnych nazw ról w chmurze, zobacz Przesłonięcia nazw ról w chmurze (wersja zapoznawcza).

Wystąpienie roli w chmurze

Wystąpienie roli w chmurze domyślnie jest ustawiane na nazwę maszyny.

Jeśli chcesz ustawić wystąpienie roli w chmurze jako inne niż nazwa maszyny:

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

Możesz również ustawić instancję roli w chmurze przy użyciu zmiennej środowiskowej APPLICATIONINSIGHTS_ROLE_INSTANCE. Następnie uzyskuje przewagę nad wystąpieniem roli chmury zdefiniowanym w konfiguracji JSON.

Możesz też ustawić wystąpienie roli w chmurze przy użyciu właściwości applicationinsights.role.instancesystemu Java . Ma również pierwszeństwo przed instancją roli chmury określoną w konfiguracji JSON.

Próbkowanie

Uwaga

Próbkowanie może być doskonałym sposobem na zmniejszenie kosztów usługi Application Insights. Upewnij się, że konfiguracja próbkowania jest odpowiednia do przypadku użycia.

Próbkowanie opiera się na żądaniu, co oznacza, że jeśli żądanie zostanie przechwycone (próbkowane), to także jego zależności, dzienniki i wyjątki zostaną uwzględnione.

Próbkowanie jest również oparte na identyfikatorze śladu, aby zapewnić spójność decyzji dotyczących próbkowania w różnych usługach.

Próbkowanie dotyczy tylko logów wewnątrz żądania. Dzienniki, które nie znajdują się wewnątrz żądania (na przykład logi startowe), domyślnie są zawsze zbierane. Jeśli chcesz próbkować te dzienniki, możesz użyć przesłonięć próbkowania.

Próbkowanie z ograniczoną szybkością

Począwszy od wersji 3.4.0, próbkowanie z ograniczoną szybkością jest dostępne i jest teraz domyślne.

Jeśli nie skonfigurowano próbkowania, wartość domyślna to teraz próbkowanie z ograniczoną szybkością skonfigurowane do przechwytywania maksymalnie (około) pięciu żądań na sekundę, a także wszystkich zależności i dzienników dotyczących tych żądań.

Ta konfiguracja zastępuje poprzednią wartość domyślną, która polegała na przechwyceniu wszystkich żądań. Jeśli nadal chcesz przechwycić wszystkie żądania, użyj próbkowania o stałym procentzie i ustaw wartość procentową próbkowania na 100.

Uwaga

Próbkowanie ograniczone do określonej szybkości jest przybliżone, ponieważ wewnętrznie musi dostosować "stały" procent próbkowania w czasie, aby generować dokładne liczby elementów dla każdego rekordu telemetrii. Próbkowanie z ograniczoną szybkością jest wewnętrznie dostosowywane, aby szybko (0,1 sekundy) reagować na nowe obciążenia aplikacji. Z tego powodu nie powinno być widoczne przekroczenie skonfigurowanej szybkości o wiele lub przez bardzo długi czas.

W tym przykładzie pokazano, jak ustawić próbkowanie w celu przechwycenia co najwyżej jednego żądania (w przybliżeniu) na sekundę:

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

Może requestsPerSecond to być liczba dziesiętna, dzięki czemu można ją skonfigurować tak, aby przechwycić mniej niż jedno żądanie na sekundę, jeśli chcesz. Na przykład wartość 0.5 oznacza przechwytywanie co najwyżej jednego żądania co 2 sekundy.

Możesz również ustawić wartość procentową próbkowania przy użyciu zmiennej środowiskowej APPLICATIONINSIGHTS_SAMPLING_REQUESTS_PER_SECOND. Następnie ma pierwszeństwo przed limitem szybkości określonym w konfiguracji JSON.

Próbkowanie o stałej wartości procentowej

W tym przykładzie pokazano, jak ustawić próbkowanie w celu przechwycenia około jednej trzeciej wszystkich żądań:

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

Możesz również ustawić wartość procentową próbkowania przy użyciu zmiennej środowiskowej APPLICATIONINSIGHTS_SAMPLING_PERCENTAGE. Następnie ma pierwszeństwo przed wartością procentową próbkowania określoną w konfiguracji JSON.

Uwaga

Dla wartości procentowej próbkowania wybierz wartość procentową zbliżoną do 100/N, gdzie N jest liczbą całkowitą. Obecnie próbkowanie nie obsługuje innych wartości.

Przesłonięcia próbkowania

Nadpisanie próbkowania umożliwia zastąpienie domyślnego procentu próbkowania. Można na przykład:

• Ustaw wartość procentową próbkowania na 0 lub niewielką wartość dla hałaśliwych testów kondycji.
• Ustaw wartość procentową próbkowania na 0 lub niewielką wartość dla hałaśliwych wywołań zależności.
• Ustaw wartość procentową próbkowania na 100 dla ważnego typu żądania. Możesz na przykład użyć /login, nawet jeśli masz domyślne próbkowanie skonfigurowane na niższe.

Aby uzyskać więcej informacji, zobacz dokumentację Przesłanianie próbkowania.

Metryki rozszerzeń zarządzania Java

Jeśli chcesz zebrać inne metryki rozszerzeń zarządzania Java (JMX):

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

W poprzednim przykładzie konfiguracji:

• name to nazwa metryki przypisana do tej metryki JMX (może to być dowolny element).
• objectName to nazwaJMX MBean obiektu, który chcesz zebrać. Symbol wieloznaczny gwiazdka (*) jest obsługiwany.
• attribute to nazwa atrybutu JMX MBean wewnątrz obiektu, który chcesz zebrać.

Wartości metryk JMX typu liczbowego i logicznego są obsługiwane. Metryki logiczne JMX są mapowane na 0 dla wartości false i 1 dla wartości true.

Aby uzyskać więcej informacji, zobacz dokumentację metryk JMX.

Wymiary niestandardowe

Jeśli chcesz dodać wymiary niestandardowe do wszystkich danych telemetrycznych:

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

Możesz użyć ${...} polecenia , aby odczytać wartość z określonej zmiennej środowiskowej podczas uruchamiania.

Uwaga

Począwszy od wersji 3.0.2, jeśli dodasz wymiar niestandardowy o nazwie service.version, wartość jest przechowywana w application_Version kolumnie w tabeli Dzienniki usługi Application Insights zamiast jako wymiar niestandardowy.

Atrybut dziedziczony (wersja zapoznawcza)

Począwszy od wersji 3.2.0, można programowo ustawić niestandardowy wymiar na telemetrii żądania. Zapewnia dziedziczenie poprzez zależności i telemetrię dzienników. Wszystkie są przechwytywane w kontekście tego żądania.

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

Następnie na początku każdego żądania wywołaj:

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

Zobacz również: Dodaj właściwość niestandardową do zakresu.

Przesłonięcia parametrów połączenia (wersja zapoznawcza)

Ta funkcja jest dostępna w wersji zapoznawczej, począwszy od wersji 3.4.0.

Przesłonięcia łańcucha połączenia umożliwiają zastąpienie domyślnego łańcucha połączenia. Można na przykład:

• Ustaw jeden parametr połączenia dla jednego prefiksu ścieżki HTTP /myapp1.
• Ustaw inny parametr połączenia dla innego prefiksu ścieżki HTTP /myapp2/.

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

Przesłonięcia nazw ról w chmurze (wersja zapoznawcza)

Ta funkcja jest dostępna w wersji zapoznawczej, począwszy od wersji 3.3.0.

Przesłonięcia nazw ról w chmurze umożliwiają zastąpienie domyślnej nazwy roli w chmurze. Można na przykład:

• Ustaw jedną nazwę roli w chmurze dla jednego prefiksu ścieżki /myapp1HTTP.
• Ustaw inną nazwę roli w chmurze dla innego prefiksu ścieżki /myapp2/HTTP.

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

Ciąg połączenia skonfigurowany w czasie wykonywania

Począwszy od wersji 3.4.8, jeśli potrzebujesz możliwości skonfigurowania parametru połączenia w czasie wykonywania, dodaj tę właściwość do konfiguracji JSON:

{
  "connectionStringConfiguredAtRuntime": true
}

Dodaj applicationinsights-core do aplikacji:

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

Użyj metody statycznej configure(String) w klasie com.microsoft.applicationinsights.connectionstring.ConnectionString.

Uwaga

Wszelkie dane telemetryczne przechwycone przed skonfigurowaniem parametrów połączenia zostaną porzucone, dlatego najlepiej skonfigurować je tak szybko, jak to możliwe podczas uruchamiania aplikacji.

Zależności Autokolekt InProc (wersja zapoznawcza)

Począwszy od wersji 3.2.0, jeśli chcesz przechwycić zależności kontrolera "InProc", użyj następującej konfiguracji:

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

Moduł ładujący zestawu SDK przeglądarki (wersja zapoznawcza)

Ta funkcja automatycznie wprowadza moduł ładujący zestawu SDK przeglądarki do stron HTML aplikacji, w tym konfigurowanie odpowiednich parametrów połączenia.

Na przykład gdy aplikacja Java zwraca odpowiedź, na przykład:

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

Automatycznie zmodyfikuje się, aby zwrócić:

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

Skrypt ma na celu ułatwienie klientom śledzenia danych użytkowników sieciowych i wysyłanie zebranych danych telemetrycznych po stronie serwera z powrotem do portalu Azure użytkowników. Szczegóły można znaleźć w artykule ApplicationInsights-JS.

Jeśli chcesz włączyć tę funkcję, dodaj poniższą opcję konfiguracji:

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

Procesory telemetryczne (wersja zapoznawcza)

Za pomocą procesorów telemetrii można skonfigurować reguły stosowane do telemetrii żądań, zależności i śledzenia. Można na przykład:

• Maskuj poufne dane.
• Warunkowo dodaj niestandardowe wymiary.
• Zaktualizuj nazwę zakresu, która jest używana do agregowania podobnych danych telemetrycznych w witrynie Azure Portal.
• Porzucanie określonych atrybutów zakresu w celu kontrolowania kosztów pozyskiwania.

Aby uzyskać więcej informacji, zobacz dokumentację procesora telemetrii.

Uwaga

Jeśli chcesz usunąć określone (całe) fragmenty w celu kontrolowania kosztów pozyskiwania, zobacz Przesłonięcia próbkowania.

Instrumentacja niestandardowa (wersja zapoznawcza)

Począwszy od wersji 3.3.1, można przechwytywać zakresy dla metody w aplikacji:

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

Lokalne wyłączanie trybu próbkowania pobierania danych (wersja zapoznawcza)

Domyślnie, gdy efektywny procent próbkowania w agencie Java wynosi 100% i skonfigurowano próbki ingestii w zasobie Application Insights, zostanie zastosowany procent próbkowania ingestii.

Należy pamiętać, że to zachowanie dotyczy zarówno próbkowania o stałej szybkości wynoszącej 100%, jak i ma zastosowanie do próbkowania z ograniczoną szybkością, gdy szybkość żądania nie przekracza limitu szybkości (efektywnie przechwytując 100% w ciągłym przesuwaniu przedziału czasu).

Począwszy od wersji 3.5.3, można wyłączyć to zachowanie (i zachować 100% danych telemetrycznych w takich przypadkach, nawet wtedy, gdy próbkowanie pozyskiwania telemetrii zostało skonfigurowane w zasobie usługi Application Insights):

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

Automatyczne rejestrowanie

Log4j, Logback, JBoss Logging i java.util.logging są automatycznie instrumentowane. Rejestrowanie wykonywane za pośrednictwem tych struktur rejestrowania jest automatycznie generowane.

Rejestrowanie jest przechwytywane tylko wtedy, gdy:

• Spełnia skonfigurowany poziom dla struktury logowania.
• Spełnia również skonfigurowany poziom usługi Application Insights.

Jeśli na przykład struktura rejestrowania jest skonfigurowana do rejestrowania WARN (i skonfigurowano ją zgodnie z wcześniejszym opisem) z pakietu com.example, a usługa Application Insights jest skonfigurowana do przechwytywania INFO (i skonfigurowana zgodnie z opisem), usługa Application Insights przechwytuje tylko WARN (i poważniejsze) z pakietu com.example.

Domyślnym poziomem skonfigurowanym dla usługi Application Insights jest INFO. Jeśli chcesz zmienić ten poziom:

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

Poziom można również ustawić przy użyciu zmiennej środowiskowej APPLICATIONINSIGHTS_INSTRUMENTATION_LOGGING_LEVEL. Następnie ma pierwszeństwo przed poziomem określonym w konfiguracji JSON.

Możesz użyć tych prawidłowych wartości level do ich określenia w pliku applicationinsights.json. W tabeli przedstawiono sposób, w jaki odpowiadają poziomom rejestrowania w różnych strukturach rejestrowania.

Poziom	Log4j	Rejestrowanie zwrotne	JBoss	LIP
Wyłączony	Wyłączony	Wyłączony	Wyłączony	Wyłączony
ŚMIERTELNY	ŚMIERTELNY	BŁĄD	ŚMIERTELNY	CIĘŻKI
BŁĄD (lub POWAŻNY)	BŁĄD	BŁĄD	BŁĄD	CIĘŻKI
OSTRZEŻENIE (lub OSTRZEGAJ)	OSTRZEŻENIE	OSTRZEŻENIE	OSTRZEŻENIE	OSTRZEŻENIE
INFORMACJA	INFORMACJA	INFORMACJA	INFORMACJA	INFORMACJA
Konfiguracja	DEBUGOWANIE	DEBUGOWANIE	DEBUGOWANIE	Konfiguracja
DEBUG (lub FINE)	DEBUGOWANIE	DEBUGOWANIE	DEBUGOWANIE	GRZYWNA
DROBNIEJSZE	DEBUGOWANIE	DEBUGOWANIE	DEBUGOWANIE	DROBNIEJSZE
TRACE (lub FINEST)	ŚLAD	ŚLAD	ŚLAD	NAJLEPSZY
WSZYSTKO	WSZYSTKO	WSZYSTKO	WSZYSTKO	WSZYSTKO

Uwaga

Jeśli obiekt wyjątku zostanie przekazany do rejestratora, komunikat dziennika (i szczegóły obiektu wyjątku) pojawi się na platformie Azure w tabeli exceptions zamiast w tabeli traces. Jeśli chcesz wyświetlić komunikaty dzienników zarówno w tabelach traces, jak i exceptions, możesz napisać zapytanie Dzienniki (Kusto) w celu ich zuniowania. Na przykład:

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

Znaczniki dziennikowe (wersja próbna)

Począwszy od wersji 3.4.2, można przechwycić znaczniki logów dla Logback i Log4j 2.

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

Inne atrybuty logów dla Logback (wersja zapoznawcza)

Począwszy od wersji 3.4.3, można przechwytywać FileName, ClassName, MethodName i LineNumber dla Logback.

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

Ostrzeżenie

Przechwytywanie atrybutów kodu może zwiększyć obciążenie związane z wydajnością.

Poziom logowania jako niestandardowy wymiar

Począwszy od wersji 3.3.0, LoggingLevel nie jest domyślnie przechwytywane jako część niestandardowego wymiaru Traces, ponieważ te dane są już przechwytywane w polu SeverityLevel.

W razie potrzeby możesz tymczasowo ponownie włączyć poprzednie zachowanie:

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

Metryki mikrometrów autokolektowanych (w tym metryki siłownika Spring Boot)

Jeśli aplikacja używa Micrometer, metryki wysyłane do rejestru globalnego Micrometer są automatycznie zbierane.

Ponadto jeśli aplikacja używa Spring Boot Actuator, metryki skonfigurowane przez Spring Boot Actuator również są automatycznie zbierane.

Aby wysłać metryki niestandardowe przy użyciu mikrometru:

1. Dodaj mikrometr do aplikacji, jak pokazano w poniższym przykładzie.

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

2. Użyj globalnego rejestru Micrometer, aby utworzyć miernik, jak pokazano w poniższym przykładzie.

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

3. Użyj licznika, aby zarejestrować metryki przy użyciu następującego polecenia.

   counter.increment();
   

4. Metryki są pozyskiwane do tabeli customMetrics, a tagi są przechwytywane w kolumnie customDimensions. Metryki można również wyświetlić w Eksploratorze metryk w ramach Log-based metrics przestrzeni nazw metryk.

   Uwaga

   Język Java usługi Application Insights zastępuje wszystkie znaki niefanumeryczne (z wyjątkiem kreski) w nazwie metryki Micrometer podkreśleniami. W związku z tym poprzednia test.counter metryka będzie wyświetlana jako test_counter.

Aby wyłączyć automatyczne zbieranie metryk Micrometer i metryk Actuator Spring Boot:

Uwaga

Metryki niestandardowe są rozliczane oddzielnie i mogą generować dodatkowe koszty. Pamiętaj, aby sprawdzić informacje o cenach. Aby wyłączyć metryki mikrometru i siłownika Spring Boot, dodaj następującą konfigurację do pliku konfiguracji.

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

Maskowanie zapytań dotyczących łączności z bazą danych Java

Wartości dosłowne w zapytaniach JDBC (Java Database Connectivity) są domyślnie maskowane, aby zapobiec przypadkowemu pozyskaniu poufnych danych.

Począwszy od wersji 3.4.0, to zachowanie można wyłączyć. Na przykład:

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

Maskowanie zapytań Mongo

Wartości literałów w zapytaniach Mongo są domyślnie maskowane, aby uniknąć przypadkowego przechwytywania poufnych danych.

Począwszy od wersji 3.4.0, to zachowanie można wyłączyć. Na przykład:

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

Nagłówki HTTP

Począwszy od wersji 3.3.0, można przechwytywać nagłówki żądań i odpowiedzi w telemetrii serwera (żądania):

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

Nazwy nagłówków są niewrażliwe na wielkość liter.

Powyższe przykłady są ujęte pod nazwami właściwości http.request.header.my_header_a i http.response.header.my_header_b.

Podobnie można przechwytywać nagłówki żądań i odpowiedzi w telemetrii klienta (zależności):

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

Ponownie nazwy nagłówków są niewrażliwe na wielkość liter. Powyższe przykłady są ujęte pod nazwami właściwości http.request.header.my_header_c i http.response.header.my_header_d.

Kody odpowiedzi serwera HTTP 4xx

Domyślnie żądania serwera HTTP, które powodują kod odpowiedzi 4xx, są przechwytywane jako błędy.

Począwszy od wersji 3.3.0, można zmienić to zachowanie, aby przechwycić je jako pomyślne:

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

Zablokowanie określonej automatycznie zbieranej telemetrii

Począwszy od wersji 3.0.3, określone dane telemetryczne autokolektowane mogą być pomijane przy użyciu następujących opcji konfiguracji:

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

Możesz również pominąć te instrumentacje, ustawiając następujące zmienne środowiskowe 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

Te zmienne mają następnie pierwszeństwo przed włączonymi zmiennymi określonymi w konfiguracji JSON.

Uwaga

Jeśli szukasz bardziej szczegółowej kontroli, na przykład, aby pominąć niektóre wywołania usługi Redis, ale nie wszystkie wywołania usługi Redis, zobacz Przesłanianie próbkowania.

Instrumentacje w wersji zapoznawczej

Począwszy od wersji 3.2.0, można włączyć następujące instrumentacje w wersji zapoznawczej:

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

Uwaga

Instrumentacja Akka jest dostępna od wersji 3.2.2. Instrumentacja biblioteki HTTP Vertx jest dostępna od wersji 3.3.0.

Przedział metryczny

Domyślnie metryki są przechwytywane co 60 sekund.

Począwszy od wersji 3.0.3, można zmienić ten interwał:

{
  "metricIntervalSeconds": 300
}

Począwszy od wersji 3.4.9 GA, można również ustawić metricIntervalSeconds używając zmiennej środowiskowej APPLICATIONINSIGHTS_METRIC_INTERVAL_SECONDS. Następnie ma pierwszeństwo przed metricIntervalSeconds określonym w konfiguracji JSON.

Ustawienie dotyczy następujących metryk:

• Domyślne liczniki wydajności: na przykład procesor CPU i pamięć
• Domyślne niestandardowe metryki: na przykład czas trwania zbierania śmieci
• Skonfigurowane metryki JMX: zobacz sekcję metryki JMX
• Metryki mikrometrów: zobacz sekcję Autokolektowane metryki mikrometrów

Puls

Domyślnie usługa Application Insights Java 3.x wysyła metrykę pulsu co 15 minut. Jeśli używasz metryki pulsu do wyzwalania alertów, możesz zwiększyć częstotliwość tego pulsu:

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

Uwaga

Nie można zwiększyć interwału do dłuższego niż 15 minut, ponieważ dane pulsu są również używane do śledzenia użycia usługi Application Insights.

Uwierzytelnianie

Uwaga

Funkcja uwierzytelniania jest dostępna w wersji GA od wersji 3.4.17.

Możesz używać uwierzytelniania, aby skonfigurować agenta do generowania poświadczeń tokenu, które są wymagane do uwierzytelniania Microsoft Entra. Aby uzyskać więcej informacji, zobacz dokumentację uwierzytelniania .

Serwer proxy HTTP

Jeśli aplikacja znajduje się za zaporą i nie może połączyć się bezpośrednio z usługą Application Insights, zapoznaj się z artykułem Dostęp do punktu końcowego usługi Azure Monitor i konfiguracja zapory.

Aby obejść ten problem, możesz skonfigurować środowisko Java 3.x usługi Application Insights do korzystania z serwera proxy HTTP.

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

Serwer proxy http można również ustawić przy użyciu zmiennej środowiskowej APPLICATIONINSIGHTS_PROXY, która przyjmuje format https://<host>:<port>. Następnie zyskuje pierwszeństwo przed serwerem proxy określonym w konfiguracji JSON.

Możesz podać użytkownikowi i hasło serwera proxy ze zmienną APPLICATIONINSIGHTS_PROXY środowiskową: https://<user>:<password>@<host>:<port>.

Application Insights Java 3.x również uwzględnia właściwości globalne https.proxyHost i https.proxyPort systemowe, jeśli są ustawione, oraz http.nonProxyHosts, jeśli to konieczne.

Odzyskiwanie po niepowodzeniach procesowych

W przypadku niepowodzenia wysyłania danych telemetrycznych do usługi Application Insights usługa Application Insights Java 3.x przechowuje dane telemetryczne na dysku i kontynuuje ponawianie próby z dysku.

Domyślny limit trwałości dysku wynosi 50 Mb. Jeśli masz dużą ilość danych telemetrycznych lub chcesz mieć możliwość odzyskania sprawności po dłuższych awariach sieci lub usługi pozyskiwania, możesz zwiększyć ten limit, począwszy od wersji 3.3.0:

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

Samodzielna diagnostyka

"Samodzielna diagnostyka" odnosi się do wewnętrznego rejestrowania z poziomu środowiska Java 3.x usługi Application Insights. Ta funkcja może być przydatna do wykrywania i diagnozowania problemów z samą usługą Application Insights.

Domyślnie dzienniki Java 3.x w ramach usługi Application Insights są rejestrowane z poziomem INFO zarówno do pliku applicationinsights.log, jak i konsoli, co odpowiada następującej konfiguracji:

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

W poprzednim przykładzie konfiguracji:

• level może być jednym z OFF, ERROR, WARN, INFO, DEBUG lub TRACE.
• path może być ścieżką bezwzględną lub względną. Ścieżki względne są rozpoznawane w odniesieniu do katalogu, w którym applicationinsights-agent-3.7.1.jar się znajduje.

Począwszy od wersji 3.0.2, można również ustawić samodzielną diagnostykę level przy użyciu zmiennej środowiskowej APPLICATIONINSIGHTS_SELF_DIAGNOSTICS_LEVEL. Następnie ma pierwszeństwo przed poziomem samodzielnej diagnostyki określonym w konfiguracji JSON.

Począwszy od wersji 3.0.3, można również ustawić lokalizację pliku samodzielnej diagnostyki przy użyciu zmiennej środowiskowej APPLICATIONINSIGHTS_SELF_DIAGNOSTICS_FILE_PATH. Następnie pierwszeństwo ma ścieżka pliku samodzielnej diagnostyki określona w konfiguracji JSON.

Korelacja telemetrii

Korelacja telemetrii jest domyślnie włączona, ale można ją wyłączyć w konfiguracji.

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

Przykład

W tym przykładzie pokazano, jak wygląda plik konfiguracji z wieloma składnikami. Skonfiguruj określone opcje na podstawie Twoich potrzeb.

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