Udostępnij za pośrednictwem

Application Insights dla języka Java 2.x

Ostrzeżenie

Ten artykuł dotyczy języka Java 2.x usługi Application Insights, który nie jest już zalecany.

Dokumentację dotyczącą najnowszej wersji można znaleźć w witrynie Application Insights Java 3.x.

Z tego artykułu dowiesz się, jak używać języka Java 2.x usługi Application Insights. W tym artykule pokazano, jak wykonać następujące działania:

  • Rozpocznij pracę i dowiedz się, jak instrumentować żądania, śledzić zależności, zbierać liczniki wydajności, diagnozować problemy z wydajnością i wyjątki oraz pisać kod, aby śledzić działania użytkowników w aplikacji.
  • Wysyłanie dzienników śledzenia do usługi Application Insights i eksplorowanie ich przy użyciu portalu usługi Application Insights.
  • Monitoruj zależności, przechwycone wyjątki i czasy wykonywania metod w aplikacjach internetowych Java.
  • Filtrowanie danych telemetrycznych w aplikacji internetowej Java.
  • Zapoznaj się z metrykami wydajności systemu Linux w usłudze Application Insights przy użyciu polecenia collectd.
  • Mierzenie metryk dla kodu aplikacji opartego na maszynie wirtualnej Java (JVM). Wyeksportuj dane do ulubionych systemów monitorowania przy użyciu monitorowania aplikacji Micrometer.

Uwaga / Notatka

31 marca 2025 r. zakończy się wsparcie dla mechanizmu pobierania klucza instrumentacji. Pobieranie klucza instrumentacji będzie nadal działać, ale nie będziemy już udostępniać aktualizacji ani zapewniać wsparcia dla tej funkcji. Przejście do parametrów połączenia w celu skorzystania z nowych możliwości.

Wprowadzenie do usługi Application Insights w projekcie internetowym Java

W tej sekcji użyjesz zestawu SDK usługi Application Insights do instrumentacji żądań, śledzenia zależności, zbierania liczników wydajności, diagnozowania problemów z wydajnością i wyjątków oraz pisania kodu w celu śledzenia działań użytkowników w aplikacji.

Application Insights to rozszerzalna usługa analizy dla deweloperów internetowych, która pomaga zrozumieć wydajność i użycie aplikacji na żywo. Usługa Application Insights obsługuje aplikacje Java działające w systemach Linux, Unix lub Windows.

Wymagania wstępne

Potrzebujesz:

Pobierz klucz instrumentacji usługi Application Insights

  1. Zaloguj się do witryny Azure Portal.

  2. W witrynie Azure Portal utwórz zasób usługi Application Insights. Ustaw typ aplikacji na aplikację internetową Java.

  3. Znajdź klucz instrumentacji nowego zasobu. Ten klucz należy wkleić wkrótce do projektu kodu.

    Zrzut ekranu przedstawiający okienko Przegląd zasobu usługi Application Insights w portalu Azure z wyróżnionym kluczem instrumentacyjnym.

Dodawanie zestawu SDK usługi Application Insights dla języka Java do projektu

Wybierz typ projektu.

Jeśli projekt jest już skonfigurowany do używania narzędzia Maven do kompilacji, wstaw następujący kod do pliku pom.xml. Następnie odśwież zależności projektu, aby pobrać pliki binarne.

    <dependencies>
      <dependency>
        <groupId>com.microsoft.azure</groupId>
        <artifactId>applicationinsights-web-auto</artifactId>
        <!-- or applicationinsights-web for manual web filter registration -->
        <!-- or applicationinsights-core for bare API -->
        <version>2.6.4</version>
      </dependency>
    </dependencies>

Najczęściej zadawane pytania

  • Jaka jest relacja między składnikami -web-auto, -webi -core ?

    • applicationinsights-web-auto Udostępnia metryki, które śledzą liczbę żądań serwletu HTTP i czasy odpowiedzi, automatycznie rejestrując filtr serwletu usługi Application Insights w czasie wykonywania.
    • applicationinsights-web Udostępnia również metryki, które śledzą liczbę żądań serwletu HTTP i czasy odpowiedzi. Jednak wymagana jest ręczna rejestracja filtru serwletu usługi Application Insights w aplikacji.
    • applicationinsights-core Udostępnia na przykład goły interfejs API, jeśli aplikacja nie jest oparta na serwletach.

  • Jak zaktualizować zestaw SDK do najnowszej wersji?

    • Od listopada 2020 r. w celu monitorowania aplikacji Java zalecamy używanie usługi Application Insights Java 3.x. Aby uzyskać więcej informacji na temat rozpoczynania pracy, zobacz Application Insights Java 3.x.

Dodawanie pliku ApplicationInsights.xml

Dodaj ApplicationInsights.xml do folderu resources w projekcie lub upewnij się, że został dodany do ścieżki klasy wdrożenia projektu. Skopiuj do niego następujący kod XML.

Zastąp klucz instrumentacji kluczem otrzymanym z Azure Portal.

<?xml version="1.0" encoding="utf-8"?>
<ApplicationInsights xmlns="http://schemas.microsoft.com/ApplicationInsights/2013/Settings" schemaVersion="2014-05-30">

   <!-- The key from the portal: -->
   <InstrumentationKey>** Your instrumentation key **</InstrumentationKey>

   <!-- HTTP request component (not required for bare API) -->
   <TelemetryModules>
      <Add type="com.microsoft.applicationinsights.web.extensibility.modules.WebRequestTrackingTelemetryModule"/>
      <Add type="com.microsoft.applicationinsights.web.extensibility.modules.WebSessionTrackingTelemetryModule"/>
      <Add type="com.microsoft.applicationinsights.web.extensibility.modules.WebUserTrackingTelemetryModule"/>
   </TelemetryModules>

   <!-- Events correlation (not required for bare API) -->
   <!-- These initializers add context data to each event -->
   <TelemetryInitializers>
      <Add type="com.microsoft.applicationinsights.web.extensibility.initializers.WebOperationIdTelemetryInitializer"/>
      <Add type="com.microsoft.applicationinsights.web.extensibility.initializers.WebOperationNameTelemetryInitializer"/>
      <Add type="com.microsoft.applicationinsights.web.extensibility.initializers.WebSessionTelemetryInitializer"/>
      <Add type="com.microsoft.applicationinsights.web.extensibility.initializers.WebUserTelemetryInitializer"/>
      <Add type="com.microsoft.applicationinsights.web.extensibility.initializers.WebUserAgentTelemetryInitializer"/>
   </TelemetryInitializers>

</ApplicationInsights>

Opcjonalnie plik konfiguracji może znajdować się w dowolnej lokalizacji dostępnej dla aplikacji. Właściwość -Dapplicationinsights.configurationDirectory systemowa określa katalog zawierający ApplicationInsights.xml. Na przykład plik konfiguracji znajdujący się w E:\myconfigs\appinsights\ApplicationInsights.xml zostanie skonfigurowany za pomocą właściwości -Dapplicationinsights.configurationDirectory="E:\myconfigs\appinsights".

  • Klucz instrumentacji jest wysyłany wraz z każdym elementem telemetrii i nakazuje usłudze Application Insights wyświetlanie go w zasobie.
  • Składnik żądania HTTP jest opcjonalny. Automatycznie wysyła dane telemetryczne dotyczące żądań i czasów odpowiedzi do portalu.
  • Korelacja zdarzeń jest dodatkiem do składnika żądania HTTP. Przypisuje identyfikator do każdego żądania odebranego przez serwer. Następnie dodaje ten identyfikator jako właściwość do każdego elementu telemetrii jako właściwość Operation.Id. Umożliwia skorelowanie danych telemetrycznych skojarzonych z każdym żądaniem przez ustawienie filtru w wyszukiwaniu diagnostycznym.

Alternatywne sposoby ustawiania klucza instrumentacji

Zestaw SDK usługi Application Insights szuka klucza w następującej kolejności:

  • Właściwość systemowa: -DAPPINSIGHTS_INSTRUMENTATIONKEY=your_ikey
  • Zmienna środowiskowa: APPINSIGHTS_INSTRUMENTATIONKEY
  • Plik konfiguracji: ApplicationInsights.xml

Można go również ustawić w kodzie:

    String instrumentationKey = "00000000-0000-0000-0000-000000000000";

    if (instrumentationKey != null)
    {
        TelemetryConfiguration.getActive().setInstrumentationKey(instrumentationKey);
    }

Dodawanie agenta

Zainstaluj agenta Java, aby przechwycić wychodzące wywołania HTTP, zapytania JDBC, rejestrowanie aplikacji i lepsze nazewnictwo operacji.

Uruchamianie aplikacji

Uruchom go w trybie debugowania na komputerze deweloperskim lub opublikuj go na serwerze.

Wyświetlanie danych telemetrycznych w usłudze Application Insights

Wróć do zasobu usługi Application Insights w witrynie Azure Portal.

Dane żądań HTTP są wyświetlane w okienku przeglądu. Jeśli tam nie ma, zaczekaj kilka sekund, a następnie wybierz pozycję Odśwież.

Zrzut ekranu przedstawiający przykładowe dane z omówieniem.

Dowiedz się więcej o metrykach.

Kliknij dowolny wykres, aby wyświetlić bardziej szczegółowe zagregowane metryki.

Zrzut ekranu przedstawiający okienko błędów usługi Application Insights z wykresami.

Dane wystąpienia

Kliknij określony typ żądania, aby wyświetlić poszczególne wystąpienia.

Zrzut ekranu przedstawiający zagłębianie się w szczegóły konkretnego widoku próbki.

Log Analytics: zaawansowany język zapytań

W miarę gromadzenia większej ilości danych można uruchamiać zapytania w celu agregowania danych i znajdowania poszczególnych wystąpień. Log Analytics to zaawansowane narzędzie do zrozumienia wydajności i użycia oraz do celów diagnostycznych.

Zrzut ekranu przedstawiający przykład usługi Log Analytics w witrynie Azure Portal.

Instalowanie aplikacji na serwerze

Teraz opublikuj aplikację na serwerze, pozwól użytkownikom na korzystanie z niej i obejrzyj dane telemetryczne wyświetlane w portalu.

  • Upewnij się, że zapora umożliwia aplikacji wysyłanie danych telemetrycznych do następujących portów:

    • dc.services.visualstudio.com:443
    • f5.services.visualstudio.com:443

  • Jeśli ruch wychodzący musi być kierowany przez zaporę, zdefiniuj właściwości http.proxyHost systemowe i http.proxyPort.

  • Na serwerach z systemem Windows zainstaluj:

Azure App Service, Azure Kubernetes Service, konfiguracja maszyn wirtualnych

Najlepszym i najprostszym podejściem do monitorowania aplikacji działających u dowolnego dostawcy zasobów platformy Azure jest użycie usługi Application Insights Java 3.x.

Wyjątki i błędy żądań

Nieobsługiwane wyjątki i błędy żądań są automatycznie zbierane przez filtr internetowy usługi Application Insights.

Aby zebrać dane dotyczące innych wyjątków, możesz wstawić wywołania do funkcji trackException() w kodzie.

Monitorowanie wywołań metod i zależności zewnętrznych

Zainstaluj agenta Java, aby rejestrować określone metody wewnętrzne i wywołania wykonywane za pośrednictwem JDBC, z danymi dotyczącymi czasu wykonania i automatycznego nazewnictwa operacji.

Śledzenie rozproszone W3C

Zestaw JAVA SDK usługi Application Insights obsługuje teraz śledzenie rozproszone W3C.

Konfiguracja przychodzącego zestawu SDK jest dokładniej objaśniona w temacie Korelacja telemetrii w usłudze Application Insights.

Konfiguracja wychodzącego zestawu SDK jest zdefiniowana w pliku AI-Agent.xml .

Liczniki wydajności

Wybierz pozycję Zbadaj>metryki , aby wyświetlić szereg liczników wydajności.

Zrzut ekranu przedstawiający okienko Metryki zasobu usługi Application Insights w portalu Azure z wybranymi prywatnymi bajtami procesu.

Dostosowywanie kolekcji liczników wydajności

Aby wyłączyć zbieranie standardowych zestawów liczników wydajności, dodaj następujący kod w węźle głównym pliku ApplicationInsights.xml :

    <PerformanceCounters>
       <UseBuiltIn>False</UseBuiltIn>
    </PerformanceCounters>

Zbieranie większej liczby liczników wydajności

Można określić dodatkowe liczniki wydajności do zbierania.

Liczniki JMX (uwidocznione przez maszynę wirtualną Java)
    <PerformanceCounters>
      <Jmx>
        <Add objectName="java.lang:type=ClassLoading" attribute="TotalLoadedClassCount" displayName="Loaded Class Count"/>
        <Add objectName="java.lang:type=Memory" attribute="HeapMemoryUsage.used" displayName="Heap Memory Usage-used" type="composite"/>
      </Jmx>
    </PerformanceCounters>
  • displayName: nazwa wyświetlana w portalu usługi Application Insights.
  • objectName: nazwa obiektu JMX.
  • attribute: atrybut nazwy obiektu JMX do uzyskania.
  • type (opcjonalnie): typ atrybutu obiektu JMX:
    • Ustawienie domyślne: prosty typ, taki jak int lub long.
    • composite: Dane licznika wydajności są w formacie Attribute.Data.
    • tabular: Dane licznika wydajności mają format wiersza tabeli.
Liczniki wydajności systemu Windows

Każdy licznik wydajności systemu Windows jest członkiem kategorii (w taki sam sposób, jak pole jest elementem członkowskim klasy). Kategorie mogą być globalne lub mają numerowane lub nazwane wystąpienia.

    <PerformanceCounters>
      <Windows>
        <Add displayName="Process User Time" categoryName="Process" counterName="%User Time" instanceName="__SELF__" />
        <Add displayName="Bytes Printed per Second" categoryName="Print Queue" counterName="Bytes Printed/sec" instanceName="Fax" />
      </Windows>
    </PerformanceCounters>
  • displayName: nazwa wyświetlana w portalu usługi Application Insights.
  • categoryName: kategoria licznika wydajności (obiekt wydajności), z którym jest skojarzony ten licznik wydajności.
  • counterName: nazwa licznika wydajności.
  • instanceName: Nazwa wystąpienia kategorii licznika wydajności lub pusty ciąg (""), jeśli kategoria zawiera pojedyncze wystąpienie. Jeśli categoryName to Process, a licznik wydajności, który chcesz zebrać, pochodzi z bieżącego procesu JVM, na którym działa Twoja aplikacja, określ "__SELF__".

Liczniki wydajności systemu Unix

Zainstaluj collectd z wtyczką Application Insights, aby uzyskać szeroką gamę danych systemowych i sieciowych.

Pobieranie danych użytkownika i sesji

Teraz wysyłasz dane telemetryczne z serwera internetowego. Aby uzyskać pełny widok 360 stopni aplikacji, możesz dodać więcej monitorowania:

Wysyłanie własnych danych telemetrycznych

Po zainstalowaniu zestawu SDK możesz użyć interfejsu API do wysyłania własnych danych telemetrycznych:

Testy dostępności stron internetowych

Usługa Application Insights może testować witrynę internetową w regularnych odstępach czasu, aby sprawdzić, czy działa prawidłowo.

Dowiedz się więcej o sposobie konfigurowania testów dostępności internetowych.

Rozwiązywanie problemów

Zobacz dedykowany artykuł dotyczący rozwiązywania problemów.

Testowanie łączności między hostem aplikacji a usługą zbierania danych

Zestawy SDK i agenci usługi Application Insights wysyłają dane telemetryczne, które są przetwarzane jako wywołania REST do naszych punktów końcowych. Możesz przetestować łączność z serwera webowego lub maszyny hostującej aplikację do punktów końcowych usługi pozyskiwania, używając bezpośrednich klientów REST z poziomu programu PowerShell lub poleceń curl. Zobacz Rozwiązywanie problemów z brakującą telemetrią aplikacji w usłudze Azure Monitor Application Insights.

Eksplorowanie dzienników śledzenia języka Java w usłudze Application Insights

Jeśli używasz funkcji Logback lub Log4J (wersja 1.2 lub 2.0) do śledzenia, możesz automatycznie wysyłać dzienniki śledzenia do usługi Application Insights, gdzie można je eksplorować i wyszukiwać.

Wskazówka

Musisz ustawić klucz instrumentacji Application Insights tylko raz dla swojej aplikacji. Jeśli używasz struktury takiej jak Java Spring, być może klucz został już zarejestrowany w innym miejscu konfiguracji aplikacji.

Korzystanie z agenta Java usługi Application Insights

Domyślnie agent java usługi Application Insights automatycznie przechwytuje rejestrowanie wykonywane na WARN poziomie i powyżej.

Możesz zmienić próg przechwytywanego rejestrowania za pomocą pliku AI-Agent.xml:

<?xml version="1.0" encoding="utf-8"?>
<ApplicationInsightsAgent>
   <Instrumentation>
      <BuiltIn>
         <Logging threshold="info"/>
      </BuiltIn>
   </Instrumentation>
</ApplicationInsightsAgent>

Przechwytywanie rejestrowania agenta Java można wyłączyć przy użyciu pliku AI-Agent.xml :

<?xml version="1.0" encoding="utf-8"?>
<ApplicationInsightsAgent>
   <Instrumentation>
      <BuiltIn>
         <Logging enabled="false"/>
      </BuiltIn>
   </Instrumentation>
</ApplicationInsightsAgent>

Alternatives

Zamiast używać agenta Języka Java, możesz wykonać te instrukcje.

Instalowanie zestawu Java SDK

Postępuj zgodnie z instrukcjami, aby zainstalować zestaw SDK usługi Application Insights dla języka Java, jeśli jeszcze tego nie zrobiono.

Dodaj biblioteki rejestrowania do projektu

Wybierz odpowiedni sposób dla projektu.

Maven

Jeśli projekt został już skonfigurowany do używania narzędzia Maven do kompilacji, scal jeden z poniższych fragmentów kodu do pliku pom.xml . Następnie odśwież zależności projektu, aby pobrać pliki binarne.

Logback


    <dependencies>
       <dependency>
          <groupId>com.microsoft.azure</groupId>
          <artifactId>applicationinsights-logging-logback</artifactId>
          <version>[2.0,)</version>
       </dependency>
    </dependencies>

Log4J, wersja 2.0


    <dependencies>
       <dependency>
          <groupId>com.microsoft.azure</groupId>
          <artifactId>applicationinsights-logging-log4j2</artifactId>
          <version>[2.0,)</version>
       </dependency>
    </dependencies>

Log4J v1.2


    <dependencies>
       <dependency>
          <groupId>com.microsoft.azure</groupId>
          <artifactId>applicationinsights-logging-log4j1_2</artifactId>
          <version>[2.0,)</version>
       </dependency>
    </dependencies>
Gradle

Jeśli projekt został już skonfigurowany do używania narzędzia Gradle do kompilacji, dodaj jeden z następujących wierszy do dependencies grupy w pliku build.gradle . Następnie odśwież zależności projektu, aby pobrać pliki binarne.

Logback


    compile group: 'com.microsoft.azure', name: 'applicationinsights-logging-logback', version: '2.0.+'

Log4J, wersja 2.0

    compile group: 'com.microsoft.azure', name: 'applicationinsights-logging-log4j2', version: '2.0.+'

Log4J v1.2

    compile group: 'com.microsoft.azure', name: 'applicationinsights-logging-log4j1_2', version: '2.0.+'

Postępuj zgodnie z wytycznymi, aby ręcznie zainstalować zestaw JAVA SDK usługi Application Insights i pobrać plik jar. Na stronie Maven Central wybierz jar łącze w sekcji pobierania dla odpowiedniego appendera. Dodaj pobrany plik jar appendera do projektu.

Logger Pobierz Biblioteka
Rejestrowanie zwrotne Appender Logback Jar applicationinsights-logging-logback
Log4J, wersja 2.0 Log4J v2 appender Jar applicationinsights-logging-log4j2
Log4j, wersja 1.2 Appender Log4J w wersji 1.2 jar applicationinsights-logging-log4j1_2

Dodaj dołącznik do frameworka rejestrowania

Aby rozpocząć pobieranie śladów, scal odpowiedni fragment kodu z plikiem konfiguracji Logback lub Log4J.

Logback


    <appender name="aiAppender" 
      class="com.microsoft.applicationinsights.logback.ApplicationInsightsAppender">
        <instrumentationKey>[APPLICATION_INSIGHTS_KEY]</instrumentationKey>
    </appender>
    <root level="trace">
      <appender-ref ref="aiAppender" />
    </root>

Log4J, wersja 2.0


    <Configuration packages="com.microsoft.applicationinsights.log4j.v2">
      <Appenders>
        <ApplicationInsightsAppender name="aiAppender" instrumentationKey="[APPLICATION_INSIGHTS_KEY]" />
      </Appenders>
      <Loggers>
        <Root level="trace">
          <AppenderRef ref="aiAppender"/>
        </Root>
      </Loggers>
    </Configuration>

Log4J v1.2


    <appender name="aiAppender" 
         class="com.microsoft.applicationinsights.log4j.v1_2.ApplicationInsightsAppender">
        <param name="instrumentationKey" value="[APPLICATION_INSIGHTS_KEY]" />
    </appender>
    <root>
      <priority value ="trace" />
      <appender-ref ref="aiAppender" />
    </root>

Dołączniki Application Insights mogą być odnoszone przez dowolnego zarejestrowanego rejestratora, a niekoniecznie przez główny rejestrator, jak pokazano w poprzednich przykładach kodu.

Przeglądaj swoje ślady w portalu usługi Application Insights

Po skonfigurowaniu projektu w celu wysyłania śladów do usługi Application Insights możesz wyświetlać i przeszukiwać te ślady w portalu usługi Application Insights w okienku Wyszukiwania .

Wyjątki przesłane za pośrednictwem rejestratorów będą wyświetlane w portalu jako dane telemetryczne wyjątków .

Zrzut ekranu przedstawiający okienko Wyszukiwania zasobu usługi Application Insights w witrynie Azure Portal.

Monitorowanie zależności, wyjątków przechwyconych i czasów wykonywania metod w aplikacjach internetowych Java

Jeśli instrumentujesz aplikację internetową Java za pomocą zestawu SDK usługi Application Insights, możesz użyć agenta Języka Java, aby uzyskać bardziej szczegółowe informacje bez żadnych zmian kodu:

  • Zależności: dane dotyczące wywołań, które aplikacja wykonuje do innych składników, w tym:

    • Wychodzące wywołania HTTP: wywołania wykonywane za pośrednictwem Apache HttpClient, OkHttp, i java.net.HttpURLConnection są przechwytywane.
    • Wywołania usługi Redis: wywołania wykonywane za pośrednictwem klienta Jedis są przechwytywane.
    • Zapytania JDBC: w przypadku baz danych MySQL i PostgreSQL, jeśli wywołanie trwa dłużej niż 10 sekund, agent zgłasza plan zapytania.

  • Rejestrowanie aplikacji: przechwytywanie i korelowanie dzienników aplikacji z żądaniami HTTP i innymi danymi telemetrycznymi:

    • Log4j 1.2
    • Log4j2
    • Logback

  • Lepsze nazewnictwo operacji: służy do agregacji żądań w portalu.

    • Spring: na @RequestMappingpodstawie .
    • JAX-RS: na podstawie @Path.

Aby użyć agenta Języka Java, zainstaluj go na serwerze. Aplikacje internetowe muszą być instrumentowane przy użyciu zestawu JAVA SDK usługi Application Insights.

Instalowanie agenta usługi Application Insights dla języka Java

  1. Na maszynie z uruchomionym serwerem Java pobierz agenta 2.x. Upewnij się, że wersja używanego agenta Java 2.x jest zgodna z wersją używanego zestawu JAVA SDK usługi Application Insights w wersji 2.x.

  2. Edytuj skrypt uruchamiania serwera aplikacji i dodaj następujący argument JVM:

    -javaagent:<full path to the agent JAR file>

    Na przykład w usłudze Tomcat na maszynie z systemem Linux:

    export JAVA_OPTS="$JAVA_OPTS -javaagent:<full path to agent JAR file>"

  3. Uruchom ponownie serwer aplikacji.

Konfigurowanie agenta

Utwórz plik o nazwie AI-Agent.xml i umieść go w tym samym folderze co plik jar agenta.

Ustaw zawartość pliku XML. Zmodyfikuj poniższy przykład, aby uwzględnić lub pominąć żądane funkcje.

<?xml version="1.0" encoding="utf-8"?>
<ApplicationInsightsAgent>
   <Instrumentation>
      <BuiltIn enabled="true">

         <!-- capture logging via Log4j 1.2, Log4j2, and Logback, default is true -->
         <Logging enabled="true" />

         <!-- capture outgoing HTTP calls performed through Apache HttpClient, OkHttp,
              and java.net.HttpURLConnection, default is true -->
         <HTTP enabled="true" />

         <!-- capture JDBC queries, default is true -->
         <JDBC enabled="true" />

         <!-- capture Redis calls, default is true -->
         <Jedis enabled="true" />

         <!-- capture query plans for JDBC queries that exceed this value (MySQL, PostgreSQL),
              default is 10000 milliseconds -->
         <MaxStatementQueryLimitInMS>1000</MaxStatementQueryLimitInMS>

      </BuiltIn>
   </Instrumentation>
</ApplicationInsightsAgent>

Więcej opcji konfiguracyjnych (Spring Boot)

java -javaagent:/path/to/agent.jar -jar path/to/TestApp.jar

W przypadku usługi Azure App Service wykonaj następujące kroki:

  1. Wybierz pozycję Ustawienia>aplikacji.

  2. W obszarze Ustawienia aplikacji dodaj nową parę wartości klucza:

    • Klucz: JAVA_OPTS
    • Wartość: -javaagent:D:/home/site/wwwroot/applicationinsights-agent-2.6.4.jar

    Agent musi być spakowany jako zasób w projekcie, aby mógł on znajdować się w katalogu D:/home/site/wwwroot/ . Aby potwierdzić, że agent znajduje się w poprawnym katalogu usługi App Service, przejdź do pozycji Narzędzia programistyczne>>Konsola debugowania i sprawdź zawartość katalogu aplikacji.

  3. Zapisz ustawienia i uruchom ponownie aplikację. Te kroki dotyczą tylko usług aplikacji działających w systemie Windows.

Uwaga / Notatka

AI-Agent.xml , a plik jar agenta powinien znajdować się w tym samym folderze. Są one często umieszczane razem w folderze /resources projektu.

Włącz śledzenie rozproszone W3C

Dodaj następujący fragment kodu do AI-Agent.xml:

<Instrumentation>
   <BuiltIn enabled="true">
      <HTTP enabled="true" W3C="true" enableW3CBackCompat="true"/>
   </BuiltIn>
</Instrumentation>

Uwaga / Notatka

Tryb zgodności z poprzednimi wersjami jest domyślnie włączony. Parametr enableW3CBackCompat jest opcjonalny i powinien być używany tylko wtedy, gdy chcesz go wyłączyć.

Najlepiej byłoby, gdyby wszystkie usługi zostały zaktualizowane do nowszych wersji zestawów SDK obsługujących protokół W3C. Zalecamy jak najszybsze przejście do nowszych wersji zestawów SDK z obsługą usługi W3C.

Upewnij się, że zarówno konfiguracje przychodzące , jak i wychodzące (agent) są dokładnie takie same.

Wyświetlanie danych

W zasobie usługi Application Insights zagregowane czasy wykonywania zależności zdalnej i metody są wyświetlane na kafelku Wydajność.

Aby wyszukać poszczególne wystąpienia raportów zależności, wyjątków i metod, otwórz pozycję Wyszukaj.

Dowiedz się więcej na temat diagnozowania problemów z zależnościami.

Pytania lub problemy?

Użyj następujących zasobów:

Filtrowanie danych telemetrycznych w aplikacji internetowej Java

Filtry umożliwiają wybranie danych telemetrycznych wysyłanych przez aplikację internetową Java do usługi Application Insights. Istnieje kilka wbudowanych filtrów, których można użyć. Możesz również napisać własne filtry niestandardowe.

Filtry dostępne od razu po instalacji obejmują:

  • Poziom ważności śledzenia.
  • Określone adresy URL, słowa kluczowe lub kody odpowiedzi.
  • Szybkie odpowiedzi. Innymi słowy, żądania, na które aplikacja szybko odpowiedziała.
  • Określone nazwy zdarzeń.

Uwaga / Notatka

Filtry zniekształcają metryki aplikacji. Możesz na przykład zdecydować, że aby zdiagnozować powolne odpowiedzi, ustawisz filtr, aby odrzucić szybkie czasy odpowiedzi. Należy jednak pamiętać, że średni czas odpowiedzi zgłoszony przez usługę Application Insights będzie wtedy wolniejszy niż rzeczywista szybkość. Ponadto liczba żądań będzie mniejsza niż rzeczywista liczba.

Jeśli jest to problem, zamiast tego użyj opcji Próbkowanie .

Ustawianie filtrów

W ApplicationInsights.xml dodaj sekcję taką jak ten przykład TelemetryProcessors:


    <ApplicationInsights>
      <TelemetryProcessors>

        <BuiltInProcessors>
           <Processor type="TraceTelemetryFilter">
                  <Add name="FromSeverityLevel" value="ERROR"/>
           </Processor>

           <Processor type="RequestTelemetryFilter">
                  <Add name="MinimumDurationInMS" value="100"/>
                  <Add name="NotNeededResponseCodes" value="200-400"/>
           </Processor>

           <Processor type="PageViewTelemetryFilter">
                  <Add name="DurationThresholdInMS" value="100"/>
                  <Add name="NotNeededNames" value="home,index"/>
                  <Add name="NotNeededUrls" value=".jpg,.css"/>
           </Processor>

           <Processor type="TelemetryEventFilter">
                  <!-- Names of events we don't want to see -->
                  <Add name="NotNeededNames" value="Start,Stop,Pause"/>
           </Processor>

           <!-- Exclude telemetry from availability tests and bots -->
           <Processor type="SyntheticSourceFilter">
                <!-- Optional: specify which synthetic sources,
                     comma-separated
                     - default is all synthetics -->
                <Add name="NotNeededSources" value="Application Insights Availability Monitoring,BingPreview"
           </Processor>

        </BuiltInProcessors>

        <CustomProcessors>
          <Processor type="com.fabrikam.MyFilter">
            <Add name="Successful" value="false"/>
          </Processor>
        </CustomProcessors>

      </TelemetryProcessors>
    </ApplicationInsights>

Sprawdź pełny zestaw wbudowanych procesorów.

Filtry wbudowane

W tej sekcji omówiono wbudowane filtry, które są dostępne.

Filtr metryki telemetrii


           <Processor type="MetricTelemetryFilter">
                  <Add name="NotNeeded" value="metric1,metric2"/>
           </Processor>
  • NotNeeded: Rozdzielona przecinkami lista niestandardowych nazw metryk

Filtr telemetrii widoku strony


           <Processor type="PageViewTelemetryFilter">
                  <Add name="DurationThresholdInMS" value="500"/>
                  <Add name="NotNeededNames" value="page1,page2"/>
                  <Add name="NotNeededUrls" value="url1,url2"/>
           </Processor>
  • DurationThresholdInMS: czas trwania odnosi się do czasu potrzebnego do załadowania strony. Jeśli ten parametr jest ustawiony, strony ładowane szybciej niż tym razem nie są zgłaszane.
  • NotNeededNames: Rozdzielona przecinkami lista nazw stron.
  • NotNeededUrls: rozdzielona przecinkami lista fragmentów adresów URL. Na przykład "home" filtruje wszystkie strony, które mają "strona główna" w adresie URL.

Filtr żądań telemetrii


           <Processor type="RequestTelemetryFilter">
                  <Add name="MinimumDurationInMS" value="500"/>
                  <Add name="NotNeededResponseCodes" value="page1,page2"/>
                  <Add name="NotNeededUrls" value="url1,url2"/>
           </Processor>

Filtr syntetycznego źródła

Filtruje wszystkie dane telemetryczne, które mają wartości w właściwości SyntheticSource. Uwzględniane są żądania botów, pająków i testów dostępności.

Filtruje dane telemetryczne dla wszystkich syntetycznych żądań:


           <Processor type="SyntheticSourceFilter" />

Filtruje dane telemetryczne dla określonych syntetycznych źródeł:


           <Processor type="SyntheticSourceFilter" >
                  <Add name="NotNeeded" value="source1,source2"/>
           </Processor>
  • NotNeeded: Rozdzielona przecinkami lista syntetycznych nazw źródłowych

Filtr zdarzeń telemetrii

Filtruje zdarzenia niestandardowe, które zostały zarejestrowane przy użyciu funkcji TrackEvent():


           <Processor type="TelemetryEventFilter" >
                  <Add name="NotNeededNames" value="event1, event2"/>
           </Processor>
  • NotNeededNames: Rozdzielona przecinkami lista nazw zdarzeń

Filtr telemetrii śledzenia

Filtruje ślady dzienników rejestrowane przy użyciu funkcji TrackTrace() lub kolektora frameworku logowania:


           <Processor type="TraceTelemetryFilter">
                  <Add name="FromSeverityLevel" value="ERROR"/>
           </Processor>

  • Prawidłowe FromSeverityLevel wartości to:

    • OFF: Filtruje wszystkie ślady.
    • TRACE: Brak filtrowania. Równa się poziomowi TRACE.
    • INFO: Filtruje poziom TRACE.
    • OSTRZEGAJ: filtruje dane TRACE i INFO.
    • BŁĄD: Filtruje ostrzeżenie, INFORMACJE i ŚLAD.
    • KRYTYCZNE: filtruje wszystko poza KRYTYCZNYMI.

Filtry niestandardowe

W poniższych sekcjach przedstawiono kroki tworzenia własnych filtrów niestandardowych.

Zaprogramuj filtr

W kodzie utwórz klasę, która implementuje TelemetryProcessorelement :


    package com.fabrikam.MyFilter;
    import com.microsoft.applicationinsights.extensibility.TelemetryProcessor;
    import com.microsoft.applicationinsights.telemetry.Telemetry;

    public class SuccessFilter implements TelemetryProcessor {

        /* Any parameters that are required to support the filter.*/
        private final String successful;

        /* Initializers for the parameters, named "setParameterName" */
        public void setNotNeeded(String successful)
        {
            this.successful = successful;
        }

        /* This method is called for each item of telemetry to be sent.
           Return false to discard it.
           Return true to allow other processors to inspect it. */
        @Override
        public boolean process(Telemetry telemetry) {
            if (telemetry == null) { return true; }
            if (telemetry instanceof RequestTelemetry)
            {
                RequestTelemetry requestTelemetry = (RequestTelemetry)    telemetry;
                return request.getSuccess() == successful;
            }
            return true;
        }
    }

Wywoływanie filtru w pliku konfiguracji

Teraz w ApplicationInsights.xml:



    <ApplicationInsights>
      <TelemetryProcessors>
        <CustomProcessors>
          <Processor type="com.fabrikam.SuccessFilter">
            <Add name="Successful" value="false"/>
          </Processor>
        </CustomProcessors>
      </TelemetryProcessors>
    </ApplicationInsights>

Wywoływanie filtru (Java Spring)

W przypadku aplikacji opartych na frameworku Spring niestandardowe procesory telemetryczne muszą być zarejestrowane w głównej klasie aplikacji jako bean. Zostaną następnie automatycznie powiązane po uruchomieniu aplikacji.

@Bean
public TelemetryProcessor successFilter() {
      return new SuccessFilter();
}

Utworzysz własne parametry filtru w pliku application.properties. Następnie użyjesz zewnętrznej struktury konfiguracji Spring Boot, aby przekazać te parametry do niestandardowego filtru.

Rozwiązywanie problemów

Ta sekcja zawiera poradę dotyczącą rozwiązywania problemów.

Mój filtr nie działa

Sprawdź, czy podano prawidłowe wartości parametrów. Na przykład czasy trwania powinny być liczbami całkowitymi. Nieprawidłowe wartości spowodują zignorowanie filtru. Jeśli filtr niestandardowy zgłasza wyjątek w konstruktorze lub metodzie ustawiającej, zostanie zignorowany.

zbierane: metryki wydajności systemu Linux w usłudze Application Insights (przestarzałe)

Aby zapoznać się z metrykami wydajności systemu Linux w usłudze Application Insights, zainstaluj collectd wraz z wtyczką do Application Insights. To rozwiązanie typu open source zbiera różne statystyki systemowe i sieciowe.

Zazwyczaj należy użyć narzędzia collectd , jeśli usługa internetowa Java została już instrumentowana za pomocą usługi Application Insights. Udostępnia ona więcej danych, które ułatwiają zwiększenie wydajności aplikacji lub diagnozowanie problemów.

Pobierz klucz instrumentacji

W witrynie Azure Portal otwórz zasób usługi Application Insights , w którym mają być wyświetlane dane. Możesz też utworzyć nowy zasób.

Utwórz kopię klucza instrumentacji, który identyfikuje zasób.

Zrzut ekranu przedstawiający okienko przeglądu zasobu usługi Application Insights w portalu Azure z wyróżnionym kluczem instrumentacyjnym.

Zainstaluj collectd i wtyczkę.

Na serwerach z systemem Linux:

  1. Zainstaluj zebraną wersję 5.4.0 lub nowszą.
  2. Pobierz wtyczkę collectd writer dla aplikacji Application Insights. Zanotuj numer wersji.
  3. Skopiuj plik JAR wtyczki do folderu /usr/share/collectd/java.
  4. Edytuj /etc/collectd/collectd.conf:

    • Upewnij się, że wtyczka Java jest włączona.

    • Zaktualizuj element JVMArg dla elementu java.class.path , aby uwzględnić następujący plik jar. Zaktualizuj numer wersji, aby był zgodny z pobranym numerem:

      • /usr/share/collectd/java/applicationinsights-collectd-1.0.5.jar

    • Dodaj ten fragment kodu przy użyciu klucza instrumentacji z zasobu:

      
     LoadPlugin "com.microsoft.applicationinsights.collectd.ApplicationInsightsWriter"
     <Plugin ApplicationInsightsWriter>
        InstrumentationKey "Your key"
     </Plugin>

      Oto część przykładowego pliku konfiguracji:

      
    ...
    # collectd plugins
    LoadPlugin cpu
    LoadPlugin disk
    LoadPlugin load
    ...

    # Enable Java Plugin
    LoadPlugin "java"

    # Configure Java Plugin
    <Plugin "java">
      JVMArg "-verbose:jni"
      JVMArg "-Djava.class.path=/usr/share/collectd/java/applicationinsights-collectd-1.0.5.jar:/usr/share/collectd/java/collectd-api.jar"

      # Enabling Application Insights plugin
      LoadPlugin "com.microsoft.applicationinsights.collectd.ApplicationInsightsWriter"

      # Configuring Application Insights plugin
      <Plugin ApplicationInsightsWriter>
        InstrumentationKey "12345678-1234-1234-1234-123456781234"
      </Plugin>

      # Other plugin configurations ...
      ...
    </Plugin>
    ...

Skonfiguruj inne zebrane wtyczki, które mogą zbierać różne dane z różnych źródeł.

Uruchom ponownie collectd zgodnie z instrukcjami ręcznymi.

Wyświetlanie danych w usłudze Application Insights

W zasobie usługi Application Insights otwórz pozycję Metryki i dodaj wykresy. Wybierz metryki, które chcesz wyświetlić w kategorii Niestandardowe .

Domyślnie metryki są agregowane na wszystkich maszynach hosta, z których zostały zebrane metryki. Aby wyświetlić metryki na hosta, w okienku Szczegóły wykresu włącz grupowanie, a następnie wybierz grupowanie według kolekcji CollectD-Host.

Wyklucz przekazywanie określonych statystyk

Domyślnie wtyczka usługi Application Insights wysyła wszystkie dane zebrane przez wszystkie włączone collectd read wtyczki.

Aby wykluczyć dane z określonych wtyczek lub źródeł danych:

  • Edytuj plik konfiguracji.

  • W <Plugin ApplicationInsightsWriter> dodaj wiersze dyrektywy podobne do tych w poniższej tabeli:

    Dyrektywa Efekt
    Exclude disk Wyklucz wszystkie dane zebrane przez wtyczkę disk .
    Exclude disk:read,write Wyklucz źródła o nazwie read i write z disk wtyczki.

Oddziel instrukcje przez wiersz nowy.

Masz problemy?

Ta sekcja zawiera porady dotyczące rozwiązywania problemów.

Nie widzę danych w portalu

Wypróbuj następujące opcje:

  • Otwórz pozycję Wyszukaj , aby sprawdzić, czy dotarły nieprzetworzone zdarzenia. Czasami pojawiają się one dłużej w Eksploratorze metryk.
  • Może być konieczne ustawienie wyjątków zapory dla danych wychodzących.
  • Włącz śledzenie w wtyczce usługi Application Insights. Dodaj ten wiersz w pliku <Plugin ApplicationInsightsWriter>:
    • SDKLogger true
  • Otwórz terminal i uruchom collectd w trybie szczegółowym, aby sprawdzić wszelkie zgłaszane problemy:
    • sudo collectd -f

Znany problem

Wtyczka zapisu Application Insights jest niezgodna z niektórymi wtyczkami odczytu. Niektóre wtyczki czasami wysyłają NaN wartość, ale wtyczka Application Insights oczekuje liczby zmiennoprzecinkowej.

  • Objaw: w dzienniku są wyświetlane błędy, które obejmują "Sztuczna collectd inteligencja: ... SyntaxError: Nieoczekiwany token N."
  • Obejście: Wyklucz dane zebrane przez wtyczki do zapisu danych problemu.

Mikrometryczne monitorowanie aplikacji mierzy metryki kodu aplikacji opartego na maszynie JVM i umożliwia eksportowanie danych do ulubionych systemów monitorowania. W tej sekcji pokazano, jak używać mikrometru z usługą Application Insights zarówno dla aplikacji Spring Boot, jak i innych niż Spring Boot.

Korzystanie z platformy Spring Boot 1.5x

Dodaj następujące zależności do pliku pom.xml lub build.gradle:

Wykonaj te kroki:

  1. Zaktualizuj plik pom.xml aplikacji Spring Boot i dodaj w nim następujące zależności:

    <dependency>
    <groupId>com.microsoft.azure</groupId>
    <artifactId>applicationinsights-spring-boot-starter</artifactId>
    <version>2.5.0</version>
</dependency>

<dependency>
    <groupId>io.micrometer</groupId>
    <artifactId>micrometer-spring-legacy</artifactId>
    <version>1.1.0</version>
</dependency>

<dependency>
    <groupId>io.micrometer</groupId>
    <artifactId>micrometer-registry-azure-monitor</artifactId>
    <version>1.1.0</version>
</dependency>

  2. Zaktualizuj plik application.properties lub YML przy użyciu klucza instrumentacji usługi Application Insights, używając następującej właściwości:

    azure.application-insights.instrumentation-key=<your-instrumentation-key-here>

  3. Skompiluj aplikację i uruchom ją.

Powyższe kroki powinny pomóc Ci w uruchomieniu zbierania wstępnie zagregowanych metryk automatycznie zbieranych w usłudze Azure Monitor.

Korzystanie z platformy Spring 2.x

Dodaj następujące zależności do pliku pom.xml lub build.gradle :

Wykonaj te kroki:

  1. Zaktualizuj plik pom.xml aplikacji Spring Boot i dodaj w niej następującą zależność:

    <dependency> 
      <groupId>com.microsoft.azure</groupId>
      <artifactId>azure-spring-boot-metrics-starter</artifactId>
      <version>2.0.7</version>
</dependency>

  2. Zaktualizuj plik application.properties lub YML przy użyciu klucza instrumentacji usługi Application Insights, używając następującej właściwości:

    azure.application-insights.instrumentation-key=<your-instrumentation-key-here>

  3. Skompiluj aplikację i uruchom ją.

Powyższe kroki powinny umożliwić Ci działanie z wstępnie zagregowanymi metrykami, automatycznie zbieranymi w usłudze Azure Monitor. Aby uzyskać więcej informacji na temat dostosowywania szablonu startowego Usługi Application Insights Spring Boot, zobacz plik readme w witrynie GitHub.

Metryki domyślne:

  • Automatycznie skonfigurowane metryki dla serwerów Tomcat, JVM, Logback Metrics, Log4J Metrics, Uptime Metrics, Processor Metrics i FileDescriptorMetrics.
  • Jeśli na przykład program Netflix Hystrix znajduje się na ścieżce klasy, otrzymamy również te metryki.
  • Następujące metryki mogą być dostępne przez dodanie odpowiednich JavaBeans:
    • CacheMetrics (CaffeineCache, EhCache2, GuavaCache, HazelcastCache i JCache)
    • DataBaseTableMetrics
    • HibernateMetrics
    • JettyMetrics
    • OkHttp3 Metryki
    • Kafka Metryki

Wyłącz zbieranie metryk automatycznych:

  • Metryki JVM:
    • management.metrics.binders.jvm.enabled=false
  • Metryki logback:
    • management.metrics.binders.logback.enabled=false
  • Metryki niezawodności
    • management.metrics.binders.uptime.enabled=false
  • Metryki procesora:
    • management.metrics.binders.processor.enabled=false
  • FileDescriptorMetrics:
    • management.metrics.binders.files.enabled=false
  • Metryki programu Hystrix, gdy biblioteka jest w systemie classpath:
    • management.metrics.binders.hystrix.enabled=false
  • Metryki interfejsu AspectJ, jeśli biblioteka w pliku classpath:
    • spring.aop.enabled=false

Uwaga / Notatka

Określ poprzednie właściwości w pliku application.properties lub application.yml aplikacji Spring Boot.

Używanie mikrometru z aplikacjami internetowymi spoza platformy Spring Boot

Dodaj następujące zależności do pliku pom.xml lub build.gradle:

Wykonaj te kroki:

  1. Dodaj następujące zależności w pliku pom.xml lub build.gradle :

        <dependency>
        <groupId>io.micrometer</groupId>
        <artifactId>micrometer-registry-azure-monitor</artifactId>
        <version>1.1.0</version>
    </dependency>

    <dependency>
        <groupId>com.microsoft.azure</groupId>
        <artifactId>applicationinsights-web-auto</artifactId>
        <version>2.5.0</version>
    </dependency>

  2. Jeśli jeszcze tego nie zrobiono, dodaj plik ApplicationInsights.xml w folderze resources. Aby uzyskać więcej informacji, zobacz Dodawanie pliku ApplicationInsights.xml.

  3. Przykładowa klasa Servlet (emituje metrykę czasomierza):

        @WebServlet("/hello")
    public class TimedDemo extends HttpServlet {

      private static final long serialVersionUID = -4751096228274971485L;

      @Override
      @Timed(value = "hello.world")
      protected void doGet(HttpServletRequest request, HttpServletResponse response)
          throws ServletException, IOException {

        response.getWriter().println("Hello World!");
        MeterRegistry registry = (MeterRegistry) getServletContext().getAttribute("AzureMonitorMeterRegistry");

    //create new Timer metric
        Timer sampleTimer = registry.timer("timer");
        Stream<Integer> infiniteStream = Stream.iterate(0, i -> i+1);
        infiniteStream.limit(10).forEach(integer -> {
          try {
            Thread.sleep(1000);
            sampleTimer.record(integer, TimeUnit.MILLISECONDS);
          } catch (Exception e) {}
           });
      }
      @Override
      public void init() throws ServletException {
        System.out.println("Servlet " + this.getServletName() + " has started");
      }
      @Override
      public void destroy() {
        System.out.println("Servlet " + this.getServletName() + " has stopped");
      }

    }

  4. Przykładowa klasa konfiguracji:

         @WebListener
     public class MeterRegistryConfiguration implements ServletContextListener {

       @Override
       public void contextInitialized(ServletContextEvent servletContextEvent) {

     // Create AzureMonitorMeterRegistry
       private final AzureMonitorConfig config = new AzureMonitorConfig() {
         @Override
         public String get(String key) {
             return null;
         }
        @Override
           public Duration step() {
             return Duration.ofSeconds(60);}

         @Override
         public boolean enabled() {
             return false;
         }
     };

  MeterRegistry azureMeterRegistry = AzureMonitorMeterRegistry.builder(config);

         //set the config to be used elsewhere
         servletContextEvent.getServletContext().setAttribute("AzureMonitorMeterRegistry", azureMeterRegistry);

       }

       @Override
       public void contextDestroyed(ServletContextEvent servletContextEvent) {

       }
     }

Aby dowiedzieć się więcej o metrykach, zobacz dokumentację mikrometru.

Inny przykładowy kod dotyczący tworzenia różnych typów metryk można znaleźć w oficjalnym repozytorium GitHub Micrometer.

Wiązanie większej liczby kolekcji metryk

W poniższych sekcjach pokazano, jak zebrać więcej metryk.

SpringBoot/Spring

Utwórz fasolę odpowiedniej kategorii metryk. Załóżmy na przykład, że potrzebujesz metryk usługi Guava Cache:

    @Bean
    GuavaCacheMetrics guavaCacheMetrics() {
        Return new GuavaCacheMetrics();
    }

Kilka metryk nie jest domyślnie włączonych, ale można je powiązać w poprzedni sposób. Aby uzyskać pełną listę, zobacz repozytorium Micrometer GitHub.

Aplikacje inne niż Spring

Dodaj następujący kod powiązania do pliku konfiguracji:

    New GuavaCacheMetrics().bind(registry);

Podstawowy interfejs API dla zdarzeń niestandardowych i metryk

Wstaw kilka wierszy kodu w aplikacji, aby dowiedzieć się, co użytkownicy robią z nim, lub aby ułatwić diagnozowanie problemów. Dane telemetryczne można wysyłać z aplikacji urządzeń i komputerów stacjonarnych, klientów internetowych i serwerów internetowych. Użyj podstawowego API telemetrii usługi Application Insights, aby wysyłać niestandardowe zdarzenia i metryki oraz własne wersje standardowej telemetrii. Ten interfejs API jest tym samym interfejsem API, którego używają standardowe moduły zbierające dane usługi Application Insights.

Podsumowanie interfejsu API

Podstawowy interfejs API jest jednolity na wszystkich platformach, oprócz kilku odmian, takich jak GetMetric (tylko platforma.NET).

Metoda Używany do
TrackPageView Strony, ekrany, okienka lub formularze.
TrackEvent Akcje użytkownika i inne zdarzenia. Służy do śledzenia zachowania użytkownika lub monitorowania wydajności.
TrackMetric Pomiary wydajności, takie jak długość kolejki, niezwiązane z określonymi zdarzeniami.
TrackException Rejestrowanie wyjątków dla diagnostyki. Prześledź, gdzie występują w odniesieniu do innych zdarzeń i zbadaj ślady stosu.
TrackRequest Rejestrowanie częstotliwości i czasu trwania żądań serwera na potrzeby analizy wydajności.
TrackTrace Komunikaty dziennika diagnostycznego zasobów. Możesz również przechwytywać dzienniki innych firm.
TrackDependency Rejestrowanie czasu trwania i częstotliwości wywołań do składników zewnętrznych, od których zależy aplikacja.

Do większości tych wywołań telemetrii można dołączyć właściwości i metryki.

Wymagania wstępne

Jeśli nie masz jeszcze odwołania do zestawu SDK usługi Application Insights:

  • Dodaj zestaw SDK usługi Application Insights do projektu.

  • W kodzie urządzenia lub serwera internetowego uwzględnij następujące elementy:

    import com.microsoft.applicationinsights.TelemetryClient;

Uzyskaj instancję TelemetryClient

Pobierz wystąpienie klasy TelemetryClient:

private TelemetryClient telemetry = new TelemetryClient();

TelemetryClient jest bezpieczny wątkowo.

Uwaga / Notatka

Jeśli używasz usługi Azure Functions w wersji 2 lub nowszej lub usługi Azure WebJobs w wersji 3 lub nowszej, zobacz Monitorowanie usługi Azure Functions.

Możesz chcieć utworzyć więcej wystąpień TelemetryClient dla innych modułów swojej aplikacji. Na przykład może istnieć jedno TelemetryClient wystąpienie w klasie środowiska pośredniczącego do raportowania zdarzeń logiki biznesowej. Możesz ustawić właściwości, takie jak UserId i DeviceId , aby zidentyfikować maszynę. Te informacje są dołączone do wszystkich zdarzeń wysyłanych przez wystąpienie.

telemetry.getContext().getUser().setId("...");
telemetry.getContext().getDevice().setId("...");

TrackEvent

W usłudze Application Insights zdarzenie niestandardowe to punkt danych, który można wyświetlić w Eksploratorze metryk jako zagregowaną liczbę i w wyszukiwaniu diagnostycznym jako pojedyncze wystąpienia. (Nie jest to związane z MVC ani inną strukturą "events".

Wstaw wywołania TrackEvent w kodzie, aby zliczyć różne zdarzenia. Możesz na przykład śledzić, jak często użytkownicy wybierają określoną funkcję. Możesz też chcieć wiedzieć, jak często osiągają określone cele lub popełniają określone błędy.

Na przykład w aplikacji do gry wyślij zdarzenie za każdym razem, gdy użytkownik wygra grę:

telemetry.trackEvent("WinGame");

Zdarzenia niestandardowe w usłudze Log Analytics

Dane telemetryczne są dostępne w customEvents tabeli na karcie Dzienniki usługi Application Insights lub w interfejsie użytkownika. Zdarzenia mogą pochodzić z trackEvent(..) lub wtyczki automatycznej kolekcji analizy kliknięć.

Jeśli próbkowanie jest wykonywane, itemCount właściwość pokazuje wartość większą niż 1. Na przykład itemCount==10 oznacza, że z 10 wywołań do trackEvent() metody, proces próbkowania przesłał tylko jedno z nich. Aby uzyskać poprawną liczbę zdarzeń niestandardowych, użyj kodu takiego jak customEvents | summarize sum(itemCount).

Uwaga / Notatka

itemCount ma minimalną wartość jedną; sam rekord reprezentuje wpis.

TrackMetric

Usługa Application Insights może wyświetlać metryki, które nie są dołączone do określonych zdarzeń. Można na przykład monitorować długość kolejki w regularnych odstępach czasu. W przypadku metryk poszczególne miary są mniej interesujące niż różnice i trendy, dlatego wykresy statystyczne są przydatne.

Aby wysyłać metryki do usługi Application Insights, możesz użyć interfejsu TrackMetric(..) API. Istnieją dwa sposoby na przesłanie metryki:

  • Pojedyncza wartość. Za każdym razem, gdy wykonujesz pomiar w aplikacji, wysyłasz odpowiednią wartość do usługi Application Insights.

    Załóżmy na przykład, że masz metrykę opisjącą liczbę elementów w kontenerze. W określonym przedziale czasu najpierw umieścisz trzy elementy w kontenerze, a następnie usuniesz dwa elementy. Zatem należy zadzwonić TrackMetric dwa razy. Najpierw należy przekazać wartość 3 , a następnie przekazać wartość -2. Usługa Application Insights przechowuje obie wartości.

  • Agregacja. Podczas pracy z metrykami każda pojedyncza miara jest rzadko interesująca. Zamiast tego ważne jest podsumowanie tego, co wydarzyło się w określonym okresie. Takie podsumowanie jest nazywane agregacją.

    W poprzednim przykładzie suma zagregowanej metryki dla tego okresu to 1 , a liczba wartości metryki to 2. W przypadku korzystania z podejścia agregacji należy wywołać TrackMetric tylko raz w danym okresie i wysłać zagregowane wartości. Zalecamy takie podejście, ponieważ może znacznie zmniejszyć koszty i obciążenie związane z wydajnością, wysyłając mniej punktów danych do usługi Application Insights, jednocześnie zbierając wszystkie istotne informacje.

Przykłady pojedynczej wartości

Aby wysłać pojedynczą wartość metryki:

telemetry.trackMetric("queueLength", 42.0);

Metryki zdefiniowane przez użytkownika w usłudze Log Analytics

Dane telemetryczne są dostępne w customMetrics tabeli w usłudze Application Insights Analytics. Każdy wiersz reprezentuje wywołanie metody trackMetric(..) w aplikacji.

  • valueSum: suma pomiarów. Aby uzyskać średnią wartość, podziel przez valueCount.
  • valueCount: liczba pomiarów, które zostały zebrane w tym wywołaniu trackMetric(..).

Uwaga / Notatka

valueCount ma minimalną wartość jedną; sam rekord reprezentuje wpis.

Widoki stron

W aplikacji urządzenia lub strony internetowej dane telemetryczne widoku strony są wysyłane domyślnie po załadowaniu każdego ekranu lub strony. Można jednak zmienić wartość domyślną, aby śledzić wyświetlenia stron w więcej lub innym czasie. Na przykład w aplikacji, która wyświetla karty lub okienka, możesz śledzić stronę za każdym razem, gdy użytkownik otworzy nowe okienko.

Dane użytkownika i sesji są wysyłane jako właściwości wraz z widokami stron, więc wykresy użytkownika i sesji nabierają znaczenia, gdy pojawiają się dane telemetryczne dotyczące wyświetleń strony.

Niestandardowe widoki stron

telemetry.trackPageView("GameReviewPage");

Telemetria stron w usłudze Log Analytics

W usłudze Log Analytics dwie tabele pokazują dane z operacji przeglądarki:

  • pageViews: zawiera dane dotyczące adresu URL i tytułu strony.
  • browserTimings: zawiera dane dotyczące wydajności klienta, takie jak czas potrzebny na przetwarzanie danych przychodzących.

Aby dowiedzieć się, jak długo trwa przetwarzanie różnych stron w przeglądarce:

browserTimings
| summarize avg(networkDuration), avg(processingDuration), avg(totalDuration) by name

Aby odkryć popularność różnych przeglądarek:

pageViews
| summarize count() by client_Browser

Aby skojarzyć widoki stron z wywołaniami AJAX, złącz je z zależnościami.

pageViews
| join (dependencies) on operation_Id

TrackRequest

Zestaw SDK serwera używa TrackRequest do rejestrowania żądań HTTP.

Możesz również wywołać je samodzielnie, jeśli chcesz symulować żądania w kontekście, w którym nie masz uruchomionego modułu usługi internetowej.

Zalecanym sposobem wysyłania danych telemetrycznych żądania jest traktowanie żądania jako kontekstu operacji.

Kontekst operacji

Elementy telemetryczne można skorelować razem, kojarząc je z kontekstem operacji. Standardowy moduł śledzenia żądań wykonuje tę funkcję w przypadku wyjątków i innych zdarzeń wysyłanych podczas przetwarzania żądania HTTP. W obszarze Wyszukiwanie i analiza można łatwo znaleźć wszelkie zdarzenia skojarzone z żądaniem przy użyciu jego identyfikatora operacji.

Elementy telemetryczne zgłaszane w zakresie operacji stają się elementami podrzędnym takiej operacji. Konteksty operacji można zagnieżdżać.

W obszarze Wyszukiwanie kontekst operacji służy do tworzenia listy Powiązane elementy .

Zrzut ekranu pokazujący listę Powiązane elementy.

Żądania w usłudze Log Analytics

W usłudze Application Insights Analytics żądania są wyświetlane w requests tabeli.

Jeśli próbkowanie jest wykonywane, itemCount właściwość pokazuje wartość większą niż 1. Na przykład itemCount==10 oznacza, że z 10 wywołań do trackRequest() metody, proces próbkowania przesłał tylko jedno z nich. Aby uzyskać prawidłową liczbę żądań i średni czas trwania segmentowany według nazw żądań, użyj kodu takiego jak:

requests
| summarize count = sum(itemCount), avgduration = avg(duration) by name

TrackException

Wysyłanie wyjątków do usługi Application Insights:

Raporty obejmują ślady stosu.

try {
    ...
} catch (Exception ex) {
    telemetry.trackException(ex);
}

Wyjątki są przechwytywane automatycznie, więc nie zawsze trzeba wywoływać TrackException jawnie.

Wyjątki w usłudze Log Analytics

W usłudze Application Insights Analytics wyjątki są wyświetlane w exceptions tabeli.

Jeśli próbkowanie jest wykonywane, itemCount właściwość pokazuje wartość większą niż 1. Na przykład itemCount==10 oznacza, że z 10 wywołań do trackException() metody, proces próbkowania przesłał tylko jedno z nich. Aby uzyskać prawidłową liczbę wyjątków segmentowanych według typu wyjątku, użyj kodu takiego jak:

exceptions
| summarize sum(itemCount) by type

Większość ważnych informacji o stosie jest już wyodrębniona do osobnych zmiennych, ale można rozłożyć strukturę details, aby uzyskać więcej informacji. Ponieważ ta struktura jest dynamiczna, należy przekształcić wynik na oczekiwany typ. Przykład:

exceptions
| extend method2 = tostring(details[0].parsedStack[1].method)

Aby skojarzyć wyjątki z powiązanymi żądaniami, użyj operacji łączenia:

exceptions
| join (requests) on operation_Id

TrackTrace

Użyj TrackTrace do diagnozowania problemów przez wysłanie "śladu nawigacyjnego" do usługi Application Insights. Fragmenty danych diagnostycznych można wysyłać i sprawdzać w wyszukiwaniu diagnostycznym.

Uwaga / Notatka

W języku Java agent java usługi Application Insights autokolektuje i wysyła dzienniki do portalu.

telemetry.trackTrace(message, SeverityLevel.Warning, properties);

Rejestrowanie zdarzenia diagnostycznego, takiego jak wprowadzanie lub opuszczanie metody.

Parameter Description
message Dane diagnostyczne. Może być znacznie dłuższa niż nazwa.
properties Mapa ciągu na ciąg. Więcej danych służy do filtrowania wyjątków w portalu. Wartości domyślne są puste.
severityLevel Obsługiwane wartości: SeverityLevel.ts.

Możesz wyszukiwać zawartość wiadomości, ale w przeciwieństwie do wartości właściwości, nie można jej filtrować.

Limit rozmiaru elementu message jest znacznie wyższy niż limit rozmiaru właściwości. Zaletą TrackTrace jest to, że można umieścić stosunkowo długie dane w komunikacie. Możesz na przykład zakodować tam dane POST.

Możesz również dodać stopień surowości do wiadomości. Podobnie jak inne dane telemetryczne, możesz dodać wartości właściwości, aby ułatwić filtrowanie lub wyszukiwanie różnych zestawów śladów. Przykład:

Map<String, Integer> properties = new HashMap<>();
properties.put("Database", db.ID);
telemetry.trackTrace("Slow Database response", SeverityLevel.Warning, properties);

W obszarze Wyszukiwanie można łatwo odfiltrować wszystkie komunikaty określonego poziomu ważności powiązanego z określoną bazą danych.

Ślady w usłudze Log Analytics

W usłudze Application Insights Analytics wywołania pojawiają się w tabeli TrackTrace.

Jeśli próbkowanie jest wykonywane, itemCount właściwość pokazuje wartość większą niż 1. Na przykład itemCount==10 oznacza, że z 10 wywołań do trackTrace() metody, proces próbkowania przesłał tylko jedno z nich. Aby uzyskać poprawną liczbę wywołań śledzenia, użyj kodu takiego jak traces | summarize sum(itemCount).

TrackDependency

Użyj wywołania , TrackDependency aby śledzić czasy odpowiedzi i wskaźniki powodzenia wywołań do zewnętrznego fragmentu kodu. Wyniki są wyświetlane na wykresach zależności w portalu. Poniższy fragment kodu musi zostać dodany wszędzie tam, gdzie jest wykonywane wywołanie zależności.

boolean success = false;
Instant startTime = Instant.now();
try {
    success = dependency.call();
}
finally {
    Instant endTime = Instant.now();
    Duration delta = Duration.between(startTime, endTime);
    RemoteDependencyTelemetry dependencyTelemetry = new RemoteDependencyTelemetry("My Dependency", "myCall", delta, success);
    dependencyTelemetry.setTimeStamp(startTime);
    telemetry.trackDependency(dependencyTelemetry);
}

Uwaga / Notatka

W języku Java wiele wywołań zależności można automatycznie śledzić przy użyciu agenta Java usługi Application Insights.

To wywołanie jest używane, jeśli chcesz śledzić wywołania, których automatyczne śledzenie nie przechwyci.

Zależności w usłudze Log Analytics

W usłudze Application Insights Analytics wywołania trackDependency są wyświetlane w dependencies tabeli.

Jeśli próbkowanie jest wykonywane, itemCount właściwość pokazuje wartość większą niż 1. Na przykład itemCount==10 oznacza, że z 10 wywołań do trackDependency() metody, proces próbkowania przesłał tylko jedno z nich. Aby uzyskać poprawną liczbę zależności segmentowanych według składnika docelowego, użyj kodu takiego jak:

dependencies
| summarize sum(itemCount) by target

Aby skojarzyć zależności z powiązanymi żądaniami, użyj sprzężenia:

dependencies
| join (requests) on operation_Id

Opróżnianie danych

Zwykle zestaw SDK wysyła dane w stałych odstępach czasu, zazwyczaj 30 sekund lub za każdym razem, gdy bufor jest pełny, czyli zazwyczaj 500 elementów. W niektórych przypadkach może być konieczne opróżnienie buforu. Przykładem jest użycie zestawu SDK w aplikacji, która zostanie zamknięta.

telemetry.flush();
//Allow some time for flushing before shutting down
Thread.sleep(5000);

Uwaga / Notatka

Java SDK automatycznie opróżnia dane podczas zamykania aplikacji.

Uwierzytelnieni użytkownicy

W aplikacji internetowej użytkownicy są domyślnie identyfikowani przez pliki cookie . Użytkownik może być liowany więcej niż raz, jeśli uzyskuje dostęp do aplikacji z innej maszyny lub przeglądarki lub jeśli usunie pliki cookie.

Jeśli użytkownicy logowali się do aplikacji, możesz uzyskać dokładniejszą liczbę, ustawiając uwierzytelniony identyfikator użytkownika w kodzie przeglądarki. Nie jest konieczne użycie rzeczywistej nazwy logowania użytkownika. Musi być tylko identyfikatorem unikatowym dla tego użytkownika. Nie może zawierać spacji ani znaków ,;=|.

Identyfikator użytkownika jest również ustawiany w pliku cookie sesji i wysyłany do serwera. Jeśli zestaw SDK serwera jest zainstalowany, uwierzytelniony identyfikator użytkownika jest wysyłany jako część właściwości kontekstu zarówno telemetrii klienta, jak i serwera. Następnie możesz filtrować i wyszukiwać.

Jeśli aplikacja grupuje użytkowników na kontach, możesz również przekazać identyfikator konta. Obowiązują te same ograniczenia znaków.

W Eksploratorze metryk można utworzyć wykres zliczający użytkowników, uwierzytelnione i konta użytkowników.

Możesz również wyszukać punkty danych klienta powiązane z określonymi nazwami użytkowników i kontami.

Filtrowanie, wyszukiwanie i segmentowanie danych przy użyciu właściwości

Właściwości i miary można dołączać do zdarzeń, metryk, widoków stron, wyjątków i innych danych telemetrycznych.

Właściwości to wartości ciągów, których można użyć do filtrowania danych telemetrycznych w raportach użycia. Jeśli na przykład aplikacja udostępnia kilka gier, możesz dołączyć nazwę gry do każdego wydarzenia, aby zobaczyć, które gry są bardziej popularne.

Istnieje ograniczenie długości ciągu do 8,192 znaków. Jeśli chcesz wysłać duże fragmenty danych, użyj parametru komunikatu .TrackTrace

Metryki to wartości liczbowe, które można przedstawiać graficznie. Na przykład możesz sprawdzić, czy występuje stopniowy wzrost wyników osiąganych przez graczy. Wykresy można podzielić na segmenty według właściwości, które są wysyłane ze zdarzeniem, aby można było uzyskać oddzielne lub skumulowane grafy dla różnych gier.

Wartości metryki powinny być większe lub równe 0, aby wyświetlić poprawnie.

Istnieją pewne ograniczenia dotyczące liczby właściwości, wartości właściwości i metryk , których można użyć.

Map<String, String> properties = new HashMap<String, String>();
properties.put("game", currentGame.getName());
properties.put("difficulty", currentGame.getDifficulty());

Map<String, Double> metrics = new HashMap<String, Double>();
metrics.put("Score", currentGame.getScore());
metrics.put("Opponents", currentGame.getOpponentCount());

telemetry.trackEvent("WinGame", properties, metrics);

Ważne

Upewnij się, że nie rejestrujesz informacji umożliwiających identyfikację w ustawieniach.

Ostrzeżenie

Nie używaj tego samego wystąpienia elementu telemetrii (event w tym przykładzie) do powtarzającego się wywoływania Track*(). Takie rozwiązanie może spowodować wysłanie danych telemetrycznych z nieprawidłową konfiguracją.

Niestandardowe pomiary i właściwości w usłudze Log Analytics

W usłudze Log Analytics metryki niestandardowe oraz właściwości są wyświetlane w atrybutach customMeasurements oraz customDimensions każdego rekordu telemetrii.

Jeśli na przykład dodasz właściwość o nazwie "game" do danych telemetrycznych żądania, to zapytanie zlicza wystąpienia różnych wartości "game" i wyświetla średnią metryki niestandardowej "score".

requests
| summarize sum(itemCount), avg(todouble(customMeasurements.score)) by tostring(customDimensions.game)

Zwróć uwagę, że:

  • Podczas wyodrębniania wartości z JSON-a customDimensions lub customMeasurements ma ona typ dynamiczny, więc należy ją rzutować na tostring lub todouble.
  • Aby wziąć pod uwagę możliwość próbkowania, użyj sum(itemCount), a nie count().

Zdarzenia czasowe

Czasami chcesz utworzyć wykres czasu potrzebnego do wykonania akcji. Na przykład możesz chcieć wiedzieć, jak długo użytkownicy będą rozważać wybory w grze. Aby uzyskać te informacje, użyj parametru pomiaru.

long startTime = System.currentTimeMillis();

// Perform timed action

long endTime = System.currentTimeMillis();
Map<String, Double> metrics = new HashMap<>();
metrics.put("ProcessingTime", (double)endTime-startTime);

// Setup some properties
Map<String, String> properties = new HashMap<>();
properties.put("signalSource", currentSignalSource.getName());

// Send the event
telemetry.trackEvent("SignalProcessed", properties, metrics);

Domyślne właściwości niestandardowej telemetrii

Jeśli chcesz ustawić domyślne wartości właściwości dla niektórych zapisywanych zdarzeń niestandardowych, ustaw je w wystąpieniu TelemetryClient . Do każdego elementu telemetrii, który jest wysyłany z tego klienta, są one dołączone.

import com.microsoft.applicationinsights.TelemetryClient;
import com.microsoft.applicationinsights.TelemetryContext;
...

TelemetryClient gameTelemetry = new TelemetryClient();
TelemetryContext context = gameTelemetry.getContext();
context.getProperties().put("Game", currentGame.Name);

gameTelemetry.TrackEvent("WinGame");

Poszczególne wywołania telemetryczne mogą zastąpić wartości domyślne w słownikach właściwości.

Wyłączanie telemetrii

Aby dynamicznie zatrzymywać i uruchamiać zbieranie i przesyłanie danych telemetrycznych:

telemetry.getConfiguration().setTrackingDisabled(true);

Dynamiczny ciąg połączenia

Aby uniknąć mieszania danych telemetrycznych z środowisk programistycznych, testowych i produkcyjnych, możesz utworzyć oddzielne zasoby usługi Application Insights i zmienić ich parametry połączenia w zależności od środowiska.

Zamiast uzyskiwać parametry połączenia z pliku konfiguracji, można ustawić je w metodzie inicjowania kodu:

// Initialize once, e.g., at startup
TelemetryClient telemetry = new TelemetryClient();

// Prefer env var; falls back to hard-coded for illustration
String cs = System.getenv("APPLICATIONINSIGHTS_CONNECTION_STRING");
if (cs != null && !cs.isEmpty()) {
    telemetry.getContext().setConnectionString(cs);
}

TelemetriaContext

TelemetryClient ma właściwość Context, która zawiera wartości, które są wysyłane wraz ze wszystkimi danymi telemetrycznymi. Są one zwykle ustawiane przez standardowe moduły telemetryczne, ale można je również ustawić samodzielnie. Przykład:

telemetry.Context.Operation.Name = "MyOperationName";

Jeśli ustawisz dowolną z tych wartości samodzielnie, rozważ usunięcie odpowiedniego wiersza z ApplicationInsights.config , aby wartości i wartości standardowe nie były mylone.

  • Składnik: aplikacja i jej wersja.
  • Urządzenie: dane dotyczące urządzenia, na którym działa aplikacja. W aplikacjach internetowych jest to serwer lub urządzenie klienckie, z którego są wysyłane dane telemetryczne.
  • InstrumentationKey: zasób usługi Application Insights na platformie Azure, na którym jest wyświetlana telemetria.
  • Lokalizacja: lokalizacja geograficzna urządzenia.
  • Operacja: Bieżące żądanie HTTP w aplikacjach internetowych. W innych typach aplikacji można ustawić tę wartość na grupowanie zdarzeń.
    • ID: wygenerowana wartość, która powiązuje różne zdarzenia, umożliwiając znalezienie powiązanych elementów podczas przeszukiwania diagnostycznego dowolnego zdarzenia.
    • Nazwa: identyfikator, zazwyczaj adres URL żądania HTTP.
    • Syntetyczne źródło: jeśli nie ma wartości null lub jest pusty, ciąg wskazujący, że źródło żądania zostało zidentyfikowane jako robot lub test internetowy. Domyślnie jest on wykluczony z obliczeń w Eksploratorze metryk.
  • Sesja: sesja użytkownika. Identyfikator jest ustawiony na wygenerowaną wartość, która jest zmieniana, gdy użytkownik nie był aktywny przez jakiś czas.
  • Użytkownik: informacje o użytkowniku.

Limits

Istnieją pewne limity liczby metryk i zdarzeń na aplikację, czyli na klucz instrumentacji. Ograniczenia zależą od wybranego planu cenowego.

Resource Limit domyślny Maksymalny limit Notatki
Łączna ilość danych na dzień 100 GB Skontaktuj się z pomocą techniczną. Możesz ustawić limit w celu zmniejszenia ilości danych. Jeśli potrzebujesz więcej danych, możesz zwiększyć limit w portalu do 1000 GB. W przypadku pojemności większych niż 1000 GB wyślij wiadomość e-mail na AIDataCap@microsoft.comadres .
Throttling 32 000 zdarzeń na sekundę Skontaktuj się z pomocą techniczną. Limit jest mierzony w ciągu minuty.
Dzienniki przechowywania danych Od 30 do 730 dni 730 dni Ten zasób jest przeznaczony dla dzienników.
Metryki przechowywania danych 90 dni 90 dni Ten zasób jest przeznaczony dla Eksploratora metryk.
Utrzymanie szczegółowych wyników wieloetapowego testu dostępności 90 dni 90 dni Ten zasób zapewnia szczegółowe wyniki każdego kroku.
Maksymalny rozmiar elementu telemetrii 64 KB 64 KB
Maksymalna liczba elementów telemetrii na partię 64,000 64,000
Długość nazwy właściwości i metryki 150 150 Zobacz schematy typów.
Długość ciągu wartości właściwości 8,192 8,192 Zobacz schematy typów.
Długość komunikatu śladu i wyjątku 32,768 32,768 Zobacz schematy typów.
Liczba testów dostępności dla zasobu usługi Application Insights 100 100
Liczba testów dostępności na grupę zasobów 800 800 Zobacz Azure Resource Manager
Maksymalna liczba przekierowań na test dostępności 10 10
Minimalna częstotliwość testów dostępności 300 sekund Niestandardowe częstotliwości testów lub częstotliwości krótsze niż 5 minut wymagają niestandardowych implementacji TrackAvailability.
Przechowywanie danych programu .NET Profiler i Snapshot Debugger Dwa tygodnie Skontaktuj się z pomocą techniczną. Maksymalny limit przechowywania wynosi sześć miesięcy.
Dane profilera .NET wysyłane codziennie Brak ograniczeń Brak limitu.
Snapshot Debugger dane wysyłane dziennie 30 migawek dziennie na monitorowaną aplikację Brak limitu. Liczbę migawek zebranych na aplikację można modyfikować za pomocą konfiguracji.

Aby uzyskać więcej informacji na temat cen i przydziałów, zobacz Rozliczenia usługi Application Insights.

Aby uniknąć osiągnięcia limitu szybkości danych, użyj próbkowania.

Aby określić, jak długo są przechowywane dane, zobacz Przechowywanie danych i prywatność.

Dalsze kroki

  • Last updated on