Aktualizacja z pakietu SDK Java 2.x usługi Application Insights

Zazwyczaj podczas uaktualniania do wersji 3.x nie ma żadnych zmian w kodzie. Zależności SDK w wersji 3.x są wersjami API bez operacji dla zależności SDK w wersji 2.x. Jednak gdy używany jest z agentem Java 3.x, to właśnie agent Java 3.x dostarcza ich implementację. W rezultacie twoja niestandardowa instrumentacja jest zintegrowana z nowymi funkcjami autoinstrumentacji dostarczonymi przez agenta Java 3.x.

Krok 1. Aktualizowanie zależności

Zależność 2.x	Akcja	Uwagi
applicationinsights-core	Aktualizowanie wersji do 3.4.3 lub nowszej
applicationinsights-web	Zaktualizuj wersję do 3.4.3 lub nowszej i usuń filtr internetowy usługi Application Insights w pliku web.xml .
applicationinsights-web-auto	Zamień na 3.4.3 lub na nowszą wersję applicationinsights-web
applicationinsights-logging-log4j1_2	Usuń zależność i usuń dołączanie usługi Application Insights z konfiguracji usługi Log4j.	Nie są już potrzebne, ponieważ usługa Log4j 1.2 jest automatycznie uruchamiana w agencie java 3.x.
applicationinsights-logging-log4j2	Usuń zależność i usuń dołączanie usługi Application Insights z konfiguracji usługi Log4j.	Nie jest już potrzebne, ponieważ usługa Log4j 2 jest automatycznie uruchamiana w agencie java 3.x.
applicationinsights-logging-logback	Usuń zależność i usuń dodatek usługi Application Insights z konfiguracji usługi Logback.	Nie są już potrzebne, ponieważ Logback jest automatycznie instrumentowany przez agenta Java 3.x.
applicationinsights-spring-boot-starter	Zamień na 3.4.3 lub na nowszą wersję applicationinsights-web	Nazwa roli chmury nie jest już domyślnie ustawiona na spring.application.name. Aby dowiedzieć się, jak skonfigurować nazwę roli w chmurze, zobacz dokumentację konfiguracji 3.x.

Krok 2. Dodawanie agenta Java 3.x

Dodaj agenta Java 3.x do argumentów wiersza polecenia Java Virtual Machine (JVM), na przykład:

-javaagent:path/to/applicationinsights-agent-3.7.1.jar

Jeśli używasz agenta języka Java usługi Application Insights 2.x, po prostu zastąp istniejący -javaagent:... poprzednim przykładem.

Uwaga

Jeśli używasz pakietu spring-boot-starter, a preferujesz inne rozwiązania, istnieje alternatywa dla korzystania z agenta Java. Zobacz 3.x Spring Boot.

Krok 3. Konfigurowanie parametry połączenia usługi Application Insights

Zobacz konfigurowanie parametrów połączenia.

Inne notatki

W pozostałej części tego dokumentu opisano ograniczenia i zmiany, które mogą wystąpić podczas uaktualniania z wersji 2.x do 3.x, a także niektóre obejścia, które mogą okazać się przydatne.

TelemetriaInitializers

2.x SDK TelemetryInitializers nie są uruchamiane podczas korzystania z agenta 3.x. Wiele przypadków użycia, które wcześniej wymagały napisania kodu TelemetryInitializer, można rozwiązać w usłudze Application Insights Java 3.x, konfigurując niestandardowe wymiary. Lub przy użyciu atrybutów dziedziczynych.

Procesory telemetrii

2.x Zestaw SDK TelemetryProcessors nie jest uruchamiany podczas korzystania z agenta 3.x. Wiele przypadków użycia, które wcześniej wymagały napisania TelemetryProcessor, można rozwiązać w Application Insights dla Java 3.x, konfigurując nadpisania próbkowania.

Wiele aplikacji w jednej maszynie wirtualnej JVM

Ten przypadek użycia jest obsługiwany w Application Insights Java 3.x przy użyciu przesłonięć nazw ról w chmurze (wersja zapoznawcza) i/lub przesłonięć parametrów połączenia (wersja zapoznawcza).

Nazwy operacji

W przypadku zestawu SDK Java 2.x usługi Application Insights nazwy operacji zawierały pełną ścieżkę, na przykład:

Nazwy operacji w środowisku Java 3.x usługi Application Insights zmieniły się, aby ogólnie zapewnić lepszy zagregowany widok w portalu usługi Application Insights U/X, na przykład:

Jednak w przypadku niektórych aplikacji nadal możesz preferować zagregowany widok w U/X, który został dostarczony przez poprzednie nazwy operacji. W takim przypadku można użyć funkcji procesorów telemetrycznych (wersja zapoznawcza) w wersji 3.x, aby zreplikować poprzednie zachowanie.

Poniższy fragment kodu konfiguruje trzy procesory telemetryczne, które łączą się w celu replikowania poprzedniego zachowania. Procesory telemetryczne wykonują następujące akcje (w kolejności):

1. Pierwszy procesor telemetrii jest procesorem atrybutów (ma typ attribute), co oznacza, że ma zastosowanie do wszystkich danych telemetrycznych, które mają atrybuty (obecnie requests i dependencies, ale wkrótce także traces).

   Pasuje do dowolnej telemetrii, która ma atrybuty o nazwach http.request.method i url.path.

   Następnie wyodrębnia url.path atrybut do nowego atrybutu o nazwie tempName.

2. Drugi procesor telemetrii jest procesorem span (ma typ span), co oznacza, że ma zastosowanie do requests i dependencies.

   Pasuje do dowolnego zakresu, który ma atrybut o nazwie tempPath.

   Następnie aktualizuje nazwę zakresu z atrybutu tempPath.

3. Ostatni procesor telemetrii jest procesorem atrybutów, takim samym typem jak pierwszy procesor telemetrii.

   Pasuje do wszystkich danych telemetrycznych, które mają atrybut o nazwie tempPath.

   Następnie usuwa atrybut o nazwie tempPath, a atrybut jest wyświetlany jako wymiar niestandardowy.

{
  "preview": {
    "processors": [
      {
        "type": "attribute",
        "include": {
          "matchType": "strict",
          "attributes": [
            { "key": "http.request.method" },
            { "key": "url.path" }
          ]
        },
        "actions": [
          {
            "key": "url.path",
            "pattern": "https?://[^/]+(?<tempPath>/[^?]*)",
            "action": "extract"
          }
        ]
      },
      {
        "type": "span",
        "include": {
          "matchType": "strict",
          "attributes": [
            { "key": "tempPath" }
          ]
        },
        "name": {
          "fromAttributes": [ "http.request.method", "tempPath" ],
          "separator": " "
        }
      },
      {
        "type": "attribute",
        "include": {
          "matchType": "strict",
          "attributes": [
            { "key": "tempPath" }
          ]
        },
        "actions": [
          { "key": "tempPath", "action": "delete" }
        ]
      }
    ]
  }
}

Próbkowanie i brakujące logi

Próbkowanie z ograniczoną szybkością jest domyślnie włączone począwszy od wersji agenta 3.4, co może powodować nieoczekiwane braki w dziennikach.

Przykład projektu

Ten projekt zestawu JAVA 2.x SDK jest migrowany do nowego projektu przy użyciu agenta Java 3.x.