Często zadawane pytania dotyczące usługi Application Insights — często zadawane pytania

Oficjalne często zadawane pytania dotyczące usługi Azure Monitor Application Insights. Znajdź odpowiedzi na pytania dotyczące korzystania z usługi Application Insights z usługą Azure Monitor.

Przegląd

Jak mogę monitorować aplikację?

Aby uzyskać szczegółowe informacje na temat instrumentowania aplikacji w celu włączenia usługi Application Insights, zobacz Podstawy zbierania danych.

Jak mogę używać usługi Application Insights?

Po włączeniu usługi Application Insights przez instrumentację aplikacji zalecamy najpierw sprawdzenie metryk na żywo i mapy aplikacji.

Jakie dane telemetryczne zbiera usługa Application Insights?

Z poziomu aplikacji internetowych serwera:

• Żądania HTTP.
• Zależności. Wywołania baz danych SQL, wywołania HTTP do usług zewnętrznych, Azure Cosmos DB, Azure Table Storage, Azure Blob Storage i Azure Queue Storage.
• Wyjątki i ślad stosu.
• Liczniki wydajności: liczniki wydajności są dostępne w przypadku użycia:
  • Agent usługi Azure Monitor - Application Insights
  • Monitorowanie platformy Azure dla maszyn wirtualnych lub zestawów skalowania maszyn wirtualnych
  • collectd usługi Application Insights.
• Zdarzenia niestandardowe i metryki , które kodujesz.
• Dzienniki śledzenia jeśli skonfigurujesz odpowiedni moduł zbierający.

Ze stron internetowych klienta:

• Nieprzechwycone wyjątki w aplikacji, w tym informacje na temat

  • Ślad stosu
  • Szczegóły wyjątku i komunikat towarzyszący błędowi
  • Liczba wierszy i kolumn błędów
  • Adres URL, pod którym został zgłoszony błąd
  • Żądania zależności sieci wysyłane przez XML Http Request (XHR) i Fetch (zbiory pobierania są domyślnie wyłączone) obejmują następujące informacje:
    • Adres URL źródła zależności
    • Polecenie i metoda używana do żądania zależności
    • Czas trwania żądania
    • Kod wyniku i stan powodzenia żądania
    • Identyfikator (jeśli istnieje) użytkownika wysyłającego żądanie
    • Kontekst korelacji (jeśli istnieje), w którym jest wykonywane żądanie

• Informacje o użytkowniku (na przykład lokalizacja, sieć, adres IP)

• Informacje o urządzeniu (na przykład Przeglądarka, system operacyjny, wersja, język, model)

• Informacje o sesji

  Uwaga / Notatka

  W przypadku niektórych aplikacji, takich jak aplikacje jednostronicowe (SPA), czas trwania nie zawsze jest rejestrowany i w takich przypadkach wartość domyślna to 0.

  Aby uzyskać więcej informacji, zobacz Zbieranie, przechowywanie i magazynowanie danych w usłudze Application Insights.

Z innych źródeł, jeśli je skonfigurujesz:

• Diagnostyka platformy Azure
• Importowanie do usługi Log Analytics
• Log Analytics
• Usługa Logstash

Ile zasobów usługi Application Insights należy wdrożyć?

Aby zrozumieć liczbę zasobów usługi Application Insights wymaganych do pokrycia aplikacji lub składników w środowiskach, zobacz Przewodnik planowania wdrażania usługi Application Insights.

Jak zarządzać zasobami usługi Application Insights za pomocą programu PowerShell?

Skrypty programu PowerShell można napisać przy użyciu usługi Azure Resource Monitor w celu:

• Tworzenie i aktualizowanie zasobów usługi Application Insights.
• Ustaw plan cenowy.
• Pobierz klucz instrumentacji.
• Dodaj alert dla metryki.
• Dodaj test dostępności.

Nie można skonfigurować raportu eksploratora metryk ani skonfigurować eksportu ciągłego.

Jak mogę wykonywać zapytania dotyczące telemetrii usługi Application Insights?

Użyj interfejsu API REST do uruchamiania zapytań usługi Log Analytics.

Czy mogę wysłać dane telemetryczne do portalu usługi Application Insights?

Zalecamy dystrybucję Azure Monitor OpenTelemetry.

Schemat ingesji i protokół punktu końcowego są dostępne publicznie.

Jak długo trwa zbieranie danych telemetrycznych?

Większość danych usługi Application Insights ma opóźnienie poniżej 5 minut. Niektóre dane mogą trwać dłużej, co jest typowe dla większych plików dziennika. Zobacz umowę dotyczącą poziomu usług usługi Application Insights.

Jak usługa Application Insights obsługuje zbieranie, przechowywanie, retencję oraz prywatność danych?

Kolekcja

Usługa Application Insights zbiera dane telemetryczne dotyczące aplikacji, w tym dane telemetryczne serwera internetowego, telemetrię strony internetowej i liczniki wydajności. Te dane mogą służyć do monitorowania wydajności, kondycji i użycia aplikacji. Możesz wybrać lokalizację podczas tworzenia nowego zasobu usługi Application Insights.

Retencja i przechowywanie

Dane są wysyłane do obszaru roboczego usługi Application Insights Log Analytics. Okres przechowywania danych pierwotnych można wybrać z zakresu od 30 do 730 dni. Zagregowane dane są przechowywane przez 90 dni, a migawki debugowania są przechowywane przez 15 dni.

Prywatność

Usługa Application Insights domyślnie nie obsługuje poufnych danych. Zalecamy, aby nie umieszczać poufnych danych w adresach URL jako zwykłego tekstu i upewnić się, że niestandardowy kod nie zbiera osobistych ani innych poufnych danych. Podczas programowania i testowania sprawdź wysłane dane w środowisku IDE i oknach danych wyjściowych debugowania przeglądarki.

Aby uzyskać zarchiwizowane informacje, zobacz Zbieranie, przechowywanie i przechowywanie danych w usłudze Application Insights.

Jaki jest model cen usługi Application Insights?

Usługa Application Insights jest rozliczana za pośrednictwem obszaru roboczego usługi Log Analytics, gdzie są gromadzone dane dziennika. Domyślna warstwa cenowa usługi Log Analytics z rozliczaniem według zużycia obejmuje 5 GB miesięcznie dostępnej puli danych na konto rozliczeniowe. Dowiedz się więcej o opcjach cen dzienników usługi Azure Monitor.

Czy są naliczane opłaty za transfer danych między aplikacją internetową platformy Azure i usługą Application Insights?

• Jeśli aplikacja internetowa platformy Azure jest hostowana w centrum danych, w którym znajduje się punkt końcowy kolekcji usługi Application Insights, nie są naliczane opłaty.
• Jeśli w centrum danych hosta nie ma punktu końcowego zbierania danych, dane telemetryczne aplikacji generują opłaty za dane wychodzące z Azure.

Ta odpowiedź zależy od dystrybucji naszych punktów końcowych, a nie od lokalizacji, w której jest hostowany zasób usługi Application Insights.

Czy ponoszę koszty sieci, jeśli mój zasób usługi Application Insights monitoruje zasób platformy Azure (czyli producent telemetrii) w innym regionie?

Tak, możesz ponosić więcej kosztów sieciowych, które różnią się w zależności od regionu, z którego pochodzą dane telemetryczne i do którego zmierzają. Aby uzyskać szczegółowe informacje, zapoznaj się z cennikiem przepustowości platformy Azure.

Jeśli widzisz nieoczekiwane opłaty lub wysokie koszty w usłudze Application Insights, ten przewodnik może pomóc. Obejmuje ona typowe przyczyny, takie jak duża ilość danych telemetrycznych, skoki pozyskiwania danych i błędnie skonfigurowane próbkowanie. Jest to szczególnie przydatne, jeśli rozwiązujesz problemy związane ze wzrostem kosztów, ilością danych telemetrycznych, niedziałającym próbkowaniem, limitami danych, wysokim pozyskiwaniem lub nieoczekiwanymi rozliczeniami. Aby rozpocząć, zobacz Rozwiązywanie problemów z wysokim poziomem pobierania danych w usłudze Application Insights.

Jakie wersje protokołu TLS są obsługiwane?

Usługa Application Insights używa protokołu Transport Layer Security (TLS) 1.2 i 1.3.

Ważne

1 marca 2025 r. platforma Azure wycofa starsze wersje protokołu TLS we wszystkich usługach. W tym czasie usługa Application Insights nie obsługuje już protokołów TLS 1.0, TLS 1.1 i wymienionych starszych zestawów szyfrowania TLS 1.2/1.3 i krzywych eliptycznych.

Aby uzyskać ogólne pytania dotyczące starszego problemu z protokołem TLS, zobacz Rozwiązywanie problemów z protokołem TLS i obsługa protokołu TLS w usłudze Azure Resource Manager.

Gdzie można uzyskać więcej informacji na temat usługi Application Insights?

Aby uzyskać więcej informacji, zobacz Wprowadzenie do usługi Application Insights.

API usługi Application Insights dla niestandardowych zdarzeń i metryk

Dlaczego brakuje danych telemetrycznych?

Oba kanały telemetrii utracą buforowane dane telemetryczne, jeśli nie zostaną opróżnione przed zamknięciem aplikacji.

Aby uniknąć utraty danych, opróżnij obiekt TelemetryClient po zamknięciu aplikacji.

Aby uzyskać więcej informacji, zobacz Opróżnianie danych.

Jakie wyjątki mogą Track_() zgłaszane wywołania?

Żaden. Nie musisz ich opakowywać w klauzule try-catch. Jeśli zestaw SDK napotka problemy, będzie rejestrować komunikaty w konsoli debugowania i, jeśli komunikaty przejdą, w wyszukiwarce diagnostycznej.

Czy istnieje interfejs API REST do pobierania danych z portalu?

Tak, API do dostępu do danych. Inne sposoby wyodrębniania danych obejmują usługę Power BI na zasobie opartym na obszarze roboczym.

Dlaczego moje wywołania do niestandardowych zdarzeń i interfejsów API do metryk są ignorowane?

Zestaw SDK usługi Application Insights nie jest zgodny z autoinstrumentacją. Jeśli funkcja autoinstrumentacji jest włączona, wywołania Track() oraz wszystkie inne niestandardowe zdarzenia i API metryk zostaną zignorowane.

Wyłącz automatyczne instrumentację w witrynie Azure Portal na karcie Application Insights na stronie usługi App Service lub ustaw wartość ApplicationInsightsAgent_EXTENSION_VERSIONdisabled.

Dlaczego liczby na wykresach wyszukiwania i wykresach metryk są nierówne?

Próbkowanie zmniejsza liczbę elementów telemetrii (takich jak żądania i zdarzenia definiowane przez użytkownika), które są wysyłane z aplikacji do portalu. W polu Wyszukiwania widzisz liczbę otrzymanych elementów. Na wykresach metryk, które wyświetlają liczbę zdarzeń, zobaczysz liczbę oryginalnych zdarzeń, które wystąpiły.

Każdy przesłany element zawiera itemCount właściwość, która pokazuje, ile oryginalnych zdarzeń reprezentuje dany element. Aby obserwować próbkowanie w operacji, możesz uruchomić to zapytanie w usłudze Log Analytics:

requests | summarize original_events = sum(itemCount), transmitted_events = count()

Jak mogę ustawić alert dotyczący zdarzenia?

Alerty platformy Azure dotyczą tylko metryk. Utwórz niestandardową metrykę, która przekracza próg wartości przy każdym wystąpieniu zdarzenia. Następnie ustaw alert na metrykę. Otrzymasz powiadomienie za każdym razem, gdy metryka przekroczy próg w dowolnym kierunku. Nie otrzymasz powiadomienia do momentu pierwszego przejścia, bez względu na to, czy początkowa wartość jest wysoka, czy niska. Zawsze występuje opóźnienie kilku minut.

Gdzie można uzyskać więcej informacji na temat interfejsu API usługi Application Insights dla zdarzeń niestandardowych i metryk?

Aby uzyskać więcej informacji, zobacz interfejs API usługi Application Insights dla zdarzeń i metryk niestandardowych.

Wdrażanie agenta usługi Application Insights dla serwerów lokalnych

Czy agent usługi Application Insights obsługuje instalacje serwera proxy?

Tak. Istnieje wiele sposobów pobierania agenta usługi Application Insights:

• Jeśli komputer ma dostęp do Internetu, możesz dołączyć do Galeria programu PowerShell przy użyciu -Proxy parametrów.
• Możesz również ręcznie pobrać moduł i zainstalować go na komputerze lub użyć go bezpośrednio.

Każda z tych opcji jest opisana w szczegółowych instrukcjach.

Czy agent usługi Application Insights obsługuje aplikacje ASP.NET Core?

Tak. W programie Application Insights Agent 2.0.0 lub nowszym obsługiwane są aplikacje ASP.NET Core hostowane w usługach IIS.

Jak mogę sprawdzić, czy włączenie zakończyło się pomyślnie?

• Aby sprawdzić, czy włączenie zakończyło się pomyślnie, możesz użyć polecenia cmdlet Get-ApplicationInsightsMonitoringStatus .

• Użyj metryk na żywo , aby szybko określić, czy aplikacja wysyła dane telemetryczne.

• Możesz również użyć usługi Log Analytics , aby wyświetlić listę wszystkich ról chmury, które obecnie wysyłają dane telemetryczne:

  union * | summarize count() by cloud_RoleName, cloud_RoleInstance
  

Jak mogę uzyskać przekazywanie serwera proxy?

Aby uzyskać przekazywanie serwera proxy, skonfiguruj serwer proxy na poziomie komputera lub serwer proxy na poziomie aplikacji. Zobacz DefaultProxy.

Przykład web.config:

<system.net>
    <defaultProxy>
    <proxy proxyaddress="http://xx.xx.xx.xx:yyyy" bypassonlocal="true"/>
    </defaultProxy>
</system.net>

Gdzie można uzyskać więcej informacji na temat wdrażania agenta usługi Application Insights dla serwerów lokalnych?

Aby uzyskać więcej informacji, zobacz Wdrażanie agenta usługi Application Insights dla serwerów lokalnych.

Obsługa protokołu TLS

Sprawdź, czy wycofanie TLS ma na Ciebie wpływ

Application Insights i Azure Monitor nie kontrolują wersji TLS używanej do połączeń HTTPS. Wersja TLS zależy od systemu operacyjnego i środowiska uruchomieniowego, w którym działa Twoja aplikacja.

Aby potwierdzić używaną wersję TLS:

• Przeczytaj dokumentację dotyczącą swojego systemu operacyjnego oraz środowiska wykonawczego lub frameworka.
• Skontaktuj się z odpowiednim zespołem wsparcia, jeśli potrzebujesz dalszej pomocy. Nie otwieraj zgłoszenia do działu wsparcia w Application Insights.

Przykładowy język i wsparcie środowiska uruchomieniowego dla TLS 1.2+

Następujące wersje obejmują zintegrowane wsparcie dla TLS 1.2 lub nowszych:

• .NET / .NET Core: .NET Framework w wersji 4.6.2 lub nowszej oraz wszystkie wersje .NET Core.
• Java: Java 8 update 161 (8u161) lub nowszy
• Python: Dystrybucje Pythona zbudowane z użyciem OpenSSL 1.0.1 lub nowszego
• Node.js: wersja Node.js 10 lub nowsza

Przykładowe wsparcie systemu operacyjnego dla TLS 1.2+

Następujące systemy operacyjne zawierają wbudowaną obsługę TLS 1.2 lub wyższej wersji:

• Windows: Windows 8, Windows Server 2012 i nowsze
• Linux: Większość nowoczesnych dystrybucji Linuxa używających OpenSSL 1.0.1 lub nowszych

Jak mogę upewnić się, że moje zasoby nie zostaną naruszone?

Aby uniknąć zakłóceń w usłudze, każdy zdalny punkt końcowy (w tym zależne żądania), z którym wchodzi w interakcję Twój zasób, musi obsługiwać co najmniej jedną kombinację tej samej wersji protokołu, zestawu szyfrów i krzywej eliptycznej, o której wspomniano wcześniej. Jeśli zdalny punkt końcowy nie obsługuje wymaganej konfiguracji protokołu TLS, należy go zaktualizować z obsługą niektórych kombinacji konfiguracji protokołu TLS po zakończeniu obsługi.

Po 1 maja 2025 roku, jakie są reakcje dotkniętych zasobów?

Zasoby Application Insights, które zostały dotknięte, przestają przyjmować dane i nie mogą uzyskać dostępu do wymaganych komponentów aplikacji. W wyniku tego niektóre funkcje przestają działać.

Które komponenty są dotknięte wycofaniem?

Szczegóły dotyczące wycofywania Transport Layer Security (TLS) opisane w tym dokumencie powinny zacząć wpływać na zachowanie systemu dopiero po 1 maja 2025 roku. Aby uzyskać więcej informacji na temat operacji CRUD, zobacz Azure Resource Manager TLS Support. Ten zasób zawiera więcej szczegółów dotyczących obsługi protokołu TLS i harmonogramów wycofywania.

Gdzie mogę uzyskać wsparcie dla protokołu Transport Layer Security (TLS)?

Aby uzyskać ogólne informacje na temat problemu z przestarzałym TLS, zobacz Rozwiązywanie problemów TLS.

Gdzie można uzyskać więcej informacji na temat obsługi protokołu TLS w usłudze Application Insights?

Aby uzyskać więcej informacji, zobacz Obsługa protokołu TLS.

ASP.NET

Jak mogę odinstalować zestaw SDK?

Aby usunąć usługę Application Insights, należy usunąć pakiety NuGet i odwołania z interfejsu API w aplikacji. Pakiety NuGet można odinstalować przy użyciu Menedżer pakietów NuGet w programie Visual Studio.

1. Jeśli kolekcja śledzenia jest włączona, najpierw odinstaluj pakiet Microsoft.ApplicationInsights.TraceListener za pomocą Menedżera pakietów NuGet, ale nie usuwaj żadnych zależności.
2. Odinstaluj pakiet Microsoft.ApplicationInsights.Web i usuń jego zależności, używając Menedżera pakietów NuGet oraz jego opcji Odinstaluj w kontrolce Opcje Menedżera pakietów NuGet.
3. Aby w pełni usunąć usługę Application Insights, sprawdź i ręcznie usuń dodany kod lub pliki wraz z wszystkimi wywołaniami interfejsu API dodanymi w projekcie. Aby uzyskać więcej informacji, zobacz Co jest tworzone automatycznie podczas dodawania zestawu SDK usługi Application Insights?.

Co jest tworzone automatycznie podczas dodawania zestawu SDK usługi Application Insights?

Po dodaniu usługi Application Insights do projektu program automatycznie tworzy pliki i dodaje kod do niektórych plików. Wyłącznie odinstalowywanie pakietów NuGet nie zawsze odrzuca pliki i kod. Aby w pełni usunąć usługę Application Insights, należy sprawdzić i ręcznie usunąć dodany kod lub pliki wraz z wszystkimi wywołaniami interfejsu API dodanymi w projekcie.

Po dodaniu telemetrii usługi Application Insights do projektu ASP.NET programu Visual Studio dodaje on następujące pliki:

• ApplicationInsights.config
• AiHandleErrorAttribute.cs

Następujące fragmenty kodu są automatycznie dodawane:

• [Nazwa projektu].csproj

    <ApplicationInsightsResourceId>/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourcegroups/Default-ApplicationInsights-EastUS/providers/microsoft.insights/components/WebApplication4</ApplicationInsightsResourceId>
  

• Packages.config

  <packages>
  ...
  
     <package id="Microsoft.ApplicationInsights" version="2.12.0" targetFramework="net472" />
     <package id="Microsoft.ApplicationInsights.Agent.Intercept" version="2.4.0" targetFramework="net472" />
     <package id="Microsoft.ApplicationInsights.DependencyCollector" version="2.12.0" targetFramework="net472" />
     <package id="Microsoft.ApplicationInsights.PerfCounterCollector" version="2.12.0" targetFramework="net472" />
     <package id="Microsoft.ApplicationInsights.Web" version="2.12.0" targetFramework="net472" />
     <package id="Microsoft.ApplicationInsights.WindowsServer" version="2.12.0" targetFramework="net472" />
     <package id="Microsoft.ApplicationInsights.WindowsServer.TelemetryChannel" version="2.12.0" targetFramework="net472" />
  
     <package id="Microsoft.AspNet.TelemetryCorrelation" version="1.0.7" targetFramework="net472" />
  
     <package id="System.Buffers" version="4.4.0" targetFramework="net472" />
     <package id="System.Diagnostics.DiagnosticSource" version="4.6.0" targetFramework="net472" />
     <package id="System.Memory" version="4.5.3" targetFramework="net472" />
     <package id="System.Numerics.Vectors" version="4.4.0" targetFramework="net472" />
     <package id="System.Runtime.CompilerServices.Unsafe" version="4.5.2" targetFramework="net472" />
  ...
  </packages>
  

• Layout.cshtml

  Jeśli projekt ma plik Layout.cshtml , dodawany jest następujący kod.

  <head>
  ...
       <script type = 'text/javascript' >
           var appInsights=window.appInsights||function(config)
           {
               function r(config){ t[config] = function(){ var i = arguments; t.queue.push(function(){ t[config].apply(t, i)})} }
               var t = { config:config},u=document,e=window,o='script',s=u.createElement(o),i,f;for(s.src=config.url||'//az416426.vo.msecnd.net/scripts/a/ai.0.js',u.getElementsByTagName(o)[0].parentNode.appendChild(s),t.cookie=u.cookie,t.queue=[],i=['Event','Exception','Metric','PageView','Trace','Ajax'];i.length;)r('track'+i.pop());return r('setAuthenticatedUserContext'),r('clearAuthenticatedUserContext'),config.disableExceptionTracking||(i='onerror',r('_'+i),f=e[i],e[i]=function(config, r, u, e, o) { var s = f && f(config, r, u, e, o); return s !== !0 && t['_' + i](config, r, u, e, o),s}),t
           }({
               instrumentationKey:'00000000-0000-0000-0000-000000000000'
           });
  
           window.appInsights=appInsights;
           appInsights.trackPageView();
       </script>
  ...
  </head>
  

• ConnectedService.json

  {
     "ProviderId": "Microsoft.ApplicationInsights.ConnectedService.ConnectedServiceProvider",
     "Version": "16.0.0.0",
     "GettingStartedDocument": {
       "Uri": "https://go.microsoft.com/fwlink/?LinkID=613413"
    }
  }
  

• FilterConfig.cs

           public static void RegisterGlobalFilters(GlobalFilterCollection filters)
           {
               filters.Add(new ErrorHandler.AiHandleErrorAttribute());// This line was added
           }
  

Jak wyłączyć korelację telemetrii?

Aby wyłączyć korelację telemetrii w konfiguracji, zobacz <ExcludeComponentCorrelationHttpHeadersOnDomains> w usłudze Application Insights dla aplikacji konsolowych.

Gdzie można uzyskać więcej informacji na temat korzystania z usługi Application Insights z ASP.NET?

Aby uzyskać więcej informacji, zobacz Configure Application Insights for your ASP.NET website (Konfigurowanie usługi Application Insights dla witryny internetowej ASP.NET).

aplikacje ASP.NET Core

Czy usługa Application Insights obsługuje ASP.NET Core 3.1?

ASP.NET Core 3.1 nie jest już obsługiwana przez firmę Microsoft.

Zestaw SDK usługi Application Insights dla ASP.NET Core w wersji 2.8.0 i Visual Studio 2019 lub nowszej może być używany z aplikacjami ASP.NET Core 3.1.

Jak mogę śledzić dane telemetryczne, które nie są zbierane automatycznie?

Uzyskaj wystąpienie TelemetryClient przy użyciu iniekcji konstruktora i wywołaj na nim wymaganą metodę TrackXXX(). Nie zalecamy tworzenia nowych TelemetryClient lub TelemetryConfiguration wystąpień w aplikacji ASP.NET Core. Singleton TelemetryClient jest już zarejestrowany w kontenerze DependencyInjection, który współdzieli TelemetryConfiguration z resztą telemetrii. Utwórz nowe TelemetryClient wystąpienie tylko wtedy, gdy potrzebuje konfiguracji, która jest oddzielona od pozostałej części telemetrii.

W poniższym przykładzie pokazano, jak śledzić więcej danych telemetrycznych z kontrolera.

using Microsoft.ApplicationInsights;

public class HomeController : Controller
{
    private TelemetryClient telemetry;

    // Use constructor injection to get a TelemetryClient instance.
    public HomeController(TelemetryClient telemetry)
    {
       this.telemetry = telemetry;
    }

    public IActionResult Index()
    {
        // Call the required TrackXXX method.
        this.telemetry.TrackEvent("HomePageRequested");
        return View();
    }
}

Aby uzyskać więcej informacji na temat raportowania danych niestandardowych w usłudze Application Insights, zobacz Dokumentacja interfejsu API metryk niestandardowych usługi Application Insights. Podobne podejście może służyć do wysyłania metryk niestandardowych do usługi Application Insights przy użyciu interfejsu API GetMetric.

Jak mogę przechwytywać treść żądania i odpowiedzi w telemetrii?

ASP.NET Core ma wbudowaną obsługę rejestrowania informacji żądania/odpowiedzi HTTP (w tym treści) za pośrednictwem polecenia ILogger. Zaleca się korzystanie z tego. Może to potencjalnie narazić na ujawnienie danych osobowych (PII) w telemetrii i spowodować znaczący wzrost kosztów (kosztów wydajności oraz rozliczeń w usłudze Application Insights), dlatego dokładnie oszacuj ryzyko przed skorzystaniem z tej funkcji.

Jak mogę dostosować kolekcję dzienników ILogger?

Ustawieniem domyślnym usługi Application Insights jest przechwytywanie tylko ostrzeżeń i poważniejszych dzienników.

Przechwyć informacje i logi o mniejszym znaczeniu, zmieniając konfigurację rejestrowania dostawcy Application Insights w następujący sposób.

{
    "Logging": {
        "LogLevel": {
            "Default": "Information"
        },
        "ApplicationInsights": {
            "LogLevel": {
                "Default": "Information"
            }
        }
    },
    "ApplicationInsights": {
        "ConnectionString": "InstrumentationKey=00000000-0000-0000-0000-000000000000"
    }
}

Należy pamiętać, że poniższy przykład nie powoduje przechwycenia Information dzienników przez dostawcę usługi Application Insights. Nie przechwytuje go, ponieważ zestaw SDK dodaje domyślny filtr rejestrowania, który nakazuje ApplicationInsights przechwycenie tylko Warning dzienników i poważniejszych dzienników. Usługa Application Insights wymaga jawnego zastąpienia.

{
    "Logging": {
       "LogLevel": {
           "Default": "Information"
       }
    }
}

Aby uzyskać więcej informacji, zobacz ILogger configuration (Konfiguracja ILogger).

Niektóre szablony programu Visual Studio używały metody rozszerzenia UseApplicationInsights() w narzędziu IWebHostBuilder w celu włączenia usługi Application Insights. Czy to użycie jest nadal prawidłowe?

Metoda rozszerzenia UseApplicationInsights() jest nadal obsługiwana, ale w wersji 2.8.0 i nowszych zestawu SDK usługi Application Insights jest oznaczona jako przestarzała. Zostanie on usunięty w następnej wersji głównej zestawu SDK. Aby włączyć telemetrię usługi Application Insights, użyj funkcji AddApplicationInsightsTelemetry() , ponieważ zapewnia przeciążenia do kontrolowania niektórych konfiguracji. Ponadto w aplikacjach ASP.NET Core 3.X services.AddApplicationInsightsTelemetry() jest jedynym sposobem włączenia Application Insights.

Wdrażam moją aplikację ASP.NET Core w usłudze Web Apps. Czy nadal należy włączyć rozszerzenie usługi Application Insights z poziomu usługi Web Apps?

Jeśli zestaw SDK jest zainstalowany w czasie kompilacji, jak pokazano w tym artykule, nie musisz włączać rozszerzenia usługi Application Insights z portalu usługi App Service. Jeśli rozszerzenie jest zainstalowane, cofa się po wykryciu, że zestaw SDK został już dodany. Jeśli włączysz usługę Application Insights z rozszerzenia, nie musisz instalować i aktualizować zestawu SDK. Jeśli jednak włączysz usługę Application Insights, postępując zgodnie z instrukcjami w tym artykule, masz większą elastyczność, ponieważ:

• Dane telemetryczne usługi Application Insights nadal działają w:
  • Wszystkie systemy operacyjne, w tym Windows, Linux i Mac.
  • Wszystkie tryby publikowania, w tym autonomiczne lub zależne od środowiska.
  • Wszystkie platformy docelowe, w tym pełna platforma .NET Framework.
  • Wszystkie opcje hostingu, w tym aplikacje internetowe, maszyny wirtualne, linux, kontenery, usługa AKS i hosting spoza platformy Azure.
  • Wszystkie wersje platformy .NET Core, w tym wersje zapoznawcza.
• Dane telemetryczne są widoczne lokalnie podczas debugowania z poziomu programu Visual Studio.
• Możesz śledzić więcej niestandardowych danych telemetrycznych, korzystając z interfejsu API TrackXXX().
• Masz pełną kontrolę nad konfiguracją.

Czy mogę włączyć monitorowanie usługi Application Insights przy użyciu narzędzi, takich jak agent usługi Azure Monitor Application Insights (dawniej Monitor stanu w wersji 2)?

Tak. W programie Application Insights Agent 2.0.0-beta1 lub nowszym obsługiwane są aplikacje ASP.NET Core hostowane w usługach IIS.

Czy wszystkie funkcje są obsługiwane, jeśli uruchamiam aplikację w systemie Linux?

Tak. Obsługa funkcji dla zestawu SDK jest taka sama na wszystkich platformach z następującymi wyjątkami:

• Zestaw SDK zbiera liczniki zdarzeń w systemie Linux, ponieważ liczniki wydajności są obsługiwane tylko w systemie Windows. Większość metryk jest taka sama.

Czy ten zestaw SDK jest obsługiwany w przypadku usług pracowniczych?

Nie. Zamiast tego użyj Application Insights dla aplikacji Worker Service (aplikacji nieopartych na HTTP) w przypadku usług worker.

Jak mogę odinstalować zestaw SDK?

Aby usunąć usługę Application Insights, należy usunąć pakiety NuGet i odwołania z interfejsu API w aplikacji. Pakiety NuGet można odinstalować przy użyciu Menedżer pakietów NuGet w programie Visual Studio.

Uwaga / Notatka

Te instrukcje dotyczą odinstalowywania zestawu ASP.NET Core SDK. Jeśli musisz odinstalować zestaw SDK ASP.NET, zobacz Jak mogę odinstalować zestaw SDK ASP.NET?.

1. Odinstaluj pakiet Microsoft.ApplicationInsights.AspNetCore przy użyciu Menedżer pakietów NuGet.
2. Aby w pełni usunąć usługę Application Insights, sprawdź i ręcznie usuń dodany kod lub pliki wraz z wszystkimi wywołaniami interfejsu API dodanymi w projekcie. Aby uzyskać więcej informacji, zobacz Co zostało utworzone podczas dodawania zestawu SDK usługi Application Insights?.

Co zostało utworzone podczas dodawania zestawu SDK usługi Application Insights?

Po dodaniu usługi Application Insights do projektu program tworzy pliki i dodaje kod do niektórych plików. Wyłącznie odinstalowywanie pakietów NuGet nie zawsze odrzuca pliki i kod. Aby w pełni usunąć usługę Application Insights, należy sprawdzić i ręcznie usunąć dodany kod lub pliki wraz z wszystkimi wywołaniami interfejsu API dodanymi w projekcie.

Po dodaniu telemetrii usługi Application Insights do projektu szablonu programu Visual Studio ASP.NET Core dodaje on następujący kod:

• [Nazwa projektu].csproj

  <PropertyGroup>
       <TargetFramework>netcoreapp3.1</TargetFramework>
       <ApplicationInsightsResourceId>/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourcegroups/Default-ApplicationInsights-EastUS/providers/microsoft.insights/components/WebApplication4core</ApplicationInsightsResourceId>
  </PropertyGroup>
  
  <ItemGroup>
       <PackageReference Include="Microsoft.ApplicationInsights.AspNetCore" Version="2.12.0" />
  </ItemGroup>
  
  <ItemGroup>
       <WCFMetadata Include="Connected Services" />
  </ItemGroup>
  

• Appsettings.json

  "ApplicationInsights": {
       "ConnectionString": "InstrumentationKey=00000000-0000-0000-0000-000000000000"
  }
  

• ConnectedService.json

  {    
       "ProviderId": "Microsoft.ApplicationInsights.ConnectedService.ConnectedServiceProvider",
       "Version": "16.0.0.0",
       "GettingStartedDocument": {
           "Uri": "https://go.microsoft.com/fwlink/?LinkID=798432"
       }
  }
  

• Startup.cs

  public void ConfigureServices(IServiceCollection services)
       {
          services.AddRazorPages();
          services.AddApplicationInsightsTelemetry(); // This is added
       }
  

Jak wyłączyć korelację telemetrii?

Aby wyłączyć korelację telemetrii w kodzie, zobacz <ExcludeComponentCorrelationHttpHeadersOnDomains> w temacie Application Insights for console applications (Usługa Application Insights dla aplikacji konsolowych).

Gdzie można uzyskać więcej informacji na temat korzystania z usługi Application Insights dla aplikacji ASP.NET Core?

Aby uzyskać więcej informacji, zobacz Application Insights for ASP.NET Core.

liczniki wydajności ASP.NET

Jaka jest różnica między metryką Współczynnika wyjątków a metryką Wyjątki?

• Exception rate: Współczynnik wyjątków jest licznikiem wydajności systemu. CLR zlicza wszystkie obsługiwane i nieobsługiwane wyjątki, które są zgłaszane, i dzieli sumę w ramach interwału próbkowania przez długość tego interwału. Zestaw SDK usługi Application Insights zbiera ten wynik i wysyła go do portalu.
• Exceptions: Metryka Wyjątki zlicza TrackException raporty odebrane przez portal w interwale próbkowania wykresu. Uwzględnia tylko te obsługiwane wyjątki, dla których piszesz wywołania TrackException w kodzie. Nie obejmuje wszystkich nieobsługiwanych wyjątków.

Gdzie można uzyskać więcej informacji na temat liczników wydajności ASP.NET?

Aby uzyskać więcej informacji, zobacz Liczniki dla platformy .NET w usłudze Application Insights.

liczniki zdarzeń ASP.NET

Czy mogę zobaczyć liczniki zdarzeń w metrykach na żywo?

Metryki na żywo nie pokazują EventCounters. Użyj Eksploratora metryk lub analizy, aby wyświetlić dane telemetryczne.

Dlaczego po włączeniu usługi Application Insights z portalu aplikacji internetowej platformy Azure nie widzę liczników zdarzeń?

Rozszerzenie usługi Application Insights dla platformy ASP.NET Core nie obsługuje jeszcze tej funkcji.

Gdzie można uzyskać więcej informacji na temat liczników zdarzeń ASP.NET?

Aby uzyskać więcej informacji, zobacz Liczniki dla platformy .NET w usłudze Application Insights.

Maszyny wirtualne platformy Azure i zestawy skalowania maszyn wirtualnych

Jak wyłączyć monitorowanie po stronie klienta dla aplikacji ASP.NET Core?

Monitorowanie po stronie klienta jest domyślnie włączone dla aplikacji ASP.NET Core. Jeśli chcesz go wyłączyć, zdefiniuj zmienną środowiskową na serwerze przy użyciu następujących informacji:

• Nazwa:APPINSIGHTS_JAVASCRIPT_ENABLED
• Wartość:false

Gdzie można uzyskać więcej informacji na temat korzystania z usługi Application Insights dla maszyn wirtualnych platformy Azure i zestawów skalowania maszyn wirtualnych?

Aby uzyskać więcej informacji, zobacz Application Insights for Azure VMs and virtual machine scale sets (Usługa Application Insights dla maszyn wirtualnych platformy Azure i zestawy skalowania maszyn wirtualnych).

Śledzenie zależności

Jak automatyczny moduł zbierania zależności raportuje nieudane wywołania zależności?

Nieudane wywołania zależności mają pole success ustawione na False. Moduł DependencyTrackingTelemetryModule nie zgłasza ExceptionTelemetry. Pełny model danych dla zależności został opisany w artykule Model danych telemetrycznych usługi Application Insights.

Jak mogę obliczyć opóźnienie pozyskiwania dla telemetrii zależności?

Użyj tego kodu:

dependencies
| extend E2EIngestionLatency = ingestion_time() - timestamp 
| extend TimeIngested = ingestion_time()

Jak mogę określić czas zainicjowania wywołania zależności?

W widoku zapytania usługi Log Analytics, timestamp reprezentuje moment zainicjowania wywołania TrackDependency(), który następuje natychmiast po otrzymaniu odpowiedzi na wywołanie zależności. Aby obliczyć czas rozpoczęcia wywołania zależności, należy wziąć timestamp i odjąć zarejestrowaną wartość duration dotyczącą wywołania zależności.

Czy śledzenie zależności w usłudze Application Insights obejmuje rejestrowanie treści odpowiedzi?

Śledzenie zależności w usłudze Application Insights nie obejmuje rejestrowania treści odpowiedzi, ponieważ generowałoby to zbyt dużo danych telemetrycznych dla większości aplikacji.

Gdzie można uzyskać więcej informacji na temat śledzenia zależności w usłudze Application Insights?

Aby uzyskać więcej informacji, zobacz Śledzenie zależności.

Testy dostępności

Czy mogę uruchomić testy dostępności na serwerze intranetowym?

Testy dostępności są uruchamiane w punktach obecności rozmieszczonych na całym świecie. Istnieją dwa rozwiązania:

• Drzwi zapory: zezwalaj na żądania do serwera z długiej i możliwej do zmiany listy agentów testujących sieć.
• Kod niestandardowy: napisz własny kod, aby wysyłać okresowe żądania do serwera z wewnątrz intranetu. W tym celu można uruchomić testy internetowe programu Visual Studio. Tester może wysłać wyniki do usługi Application Insights przy użyciu interfejsu TrackAvailability() API.

Jaki jest ciąg identyfikujący agenta użytkownika dla testów dostępności?

Ciąg agenta użytkownika to Mozilla/5.0 (kompatybilny; MSIE 9.0; Windows NT 6.1; Trident/5.0; AppInsights)

Gdzie można uzyskać więcej informacji na temat testów dostępności usługi Application Insights?

Aby uzyskać więcej informacji, zobacz Testy dostępności.

Obsługa protokołu TLS na potrzeby testów dostępności

Jak wycofanie wpływa na zachowanie testu internetowego?

Testy dostępności działają jako klient rozproszony w każdej z obsługiwanych lokalizacji testów sieci Web. Za każdym razem, gdy test internetowy jest wykonywany, usługa testu dostępności próbuje skontaktować się z zdalnym punktem końcowym zdefiniowanym w konfiguracji testu internetowego. Zostanie wysłana wiadomość Hello klienta TLS zawierająca całą obecnie obsługiwaną konfigurację protokołu TLS. Jeśli zdalny punkt końcowy współużytkuje wspólną konfigurację protokołu TLS z klientem testowym dostępności, uzgadnianie protokołu TLS powiedzie się. W przeciwnym razie test internetowy kończy się niepowodzeniem z powodu błędu uzgadniania TLS.

Jak mogę sprawdzić, jaka konfiguracja protokołu TLS obsługuje zdalny punkt końcowy?

Dostępnych jest kilka narzędzi do testowania konfiguracji protokołu TLS obsługiwanej przez punkt końcowy. Jednym ze sposobów jest wykonanie przykładu opisanego na tej stronie. Jeśli zdalny punkt końcowy nie jest dostępny za pośrednictwem Publicznego Internetu, należy sprawdzić poprawność konfiguracji protokołu TLS obsługiwanej w zdalnym punkcie końcowym z komputera, który ma dostęp do wywołania punktu końcowego.

Uwaga / Notatka

Aby wykonać kroki umożliwiające włączenie wymaganej konfiguracji protokołu TLS na serwerze internetowym, najlepiej skontaktować się z zespołem, który jest właścicielem platformy hostingu, na którą działa serwer internetowy, jeśli proces nie jest znany.

Po 1 maja 2025 r. jakie będzie zachowanie testu internetowego dla testów, których dotyczy?

Nie ma jednego rodzaju wyjątku, który dotyczyłby wszystkich błędów uzgadniania TLS w wyniku wycofania. Jednak najczęstszym wyjątkiem, przez który Twój test internetowy zacznie się niepowodzeniem, będzie The request was aborted: Couldn't create SSL/TLS secure channel. W kroku diagnozowania problemów z transportem TLS powinny być widoczne wszystkie błędy związane z protokołem TLS w wyniku testu sieci Web, który może być nimi potencjalnie dotknięty.

Czy mogę wyświetlić, jaka konfiguracja protokołu TLS jest obecnie używana przez mój test internetowy?

Nie można wyświetlić konfiguracji protokołu TLS wynegocjowanej podczas wykonywania testu internetowego. Jeśli zdalny punkt końcowy obsługuje wspólną konfigurację protokołu TLS z testami dostępności, nie powinno być widoczne żadne skutki po zakończeniu obsługi.

Które składniki są dotknięte wycofaniem w usłudze testów dostępności?

Wycofanie protokołu TLS opisane w tym dokumencie powinno mieć wpływ tylko na zachowanie testu dostępności testów sieci Web po 1 maja 2025 r. Aby uzyskać więcej informacji na temat interakcji z usługą testową dostępności dla operacji CRUD, zobacz Obsługa protokołu TLS w usłudze Azure Resource Manager. Ten zasób zawiera więcej szczegółów dotyczących obsługi protokołu TLS i harmonogramów wycofywania.

Gdzie mogę uzyskać pomoc techniczną protokołu TLS?

Aby uzyskać ogólne informacje na temat problemu z przestarzałym TLS, zobacz Rozwiązywanie problemów TLS.

Gdzie można uzyskać więcej informacji na temat obsługi protokołu TLS na potrzeby testów dostępności?

Aby uzyskać więcej informacji, zobacz Obsługiwane konfiguracje protokołu TLS.

Monitorowanie w usłudze Azure App Service dla platformy .NET, Node.js, python i aplikacji Java

Co modyfikuje usługa Application Insights w moim projekcie?

Szczegóły zależą od typu projektu. Poniższa lista jest przykładem aplikacji internetowej.

• Dodaje pliki do projektu:

  • ApplicationInsights.config
  • ai.js

• Instaluje pakiety NuGet:

  • Podstawowe API usługi Application Insights
  • Interfejs API usługi Application Insights dla aplikacji internetowych: służy do wysyłania danych telemetrycznych z serwera
  • Interfejs API usługi Application Insights dla aplikacji JavaScript: służy do wysyłania danych telemetrycznych z klienta

• Obejmuje zestawy w pakietach:

  • Microsoft.ApplicationInsights
  • Microsoft.ApplicationInsights.Platform

• Wstawia elementy do:

  • Web.config
  • packages.config

• Wstawia fragmenty kodu klienta i serwera, aby zainicjować je za pomocą identyfikatora zasobu usługi Application Insights. Na przykład w aplikacji MVC kod jest wstawiany do strony głównej Views/Shared/_Layout.cshtml. Tylko w przypadku nowych projektów dodasz usługę Application Insights do istniejącego projektu ręcznie.

Jaka jest różnica między standardowymi metrykami z usługi Application Insights a metrykami z usługi Azure App Service?

Usługa Application Insights zbiera dane telemetryczne dla żądań wysyłanych do aplikacji. Jeśli błąd wystąpi w usłudze WebApps/WebServer, a żądanie nie dotarło do aplikacji użytkownika, usługa Application Insights nie ma żadnych danych telemetrycznych.

Czas trwania obliczany serverresponsetime przez usługę Application Insights nie musi być zgodny z czasem odpowiedzi serwera obserwowanym przez usługę Web Apps. To zachowanie jest spowodowane tym, że usługa Application Insights liczy czas trwania tylko wtedy, gdy żądanie rzeczywiście dociera do aplikacji użytkownika. Jeśli żądanie jest zablokowane lub umieszczone w kolejce na serwerze WebServer, czas oczekiwania jest uwzględniany w metrykach usługi Web Apps, ale nie w metrykach usługi Application Insights.

Gdzie można uzyskać więcej informacji na temat monitorowania w usłudze Azure App Service dla platformy .NET, Node.js, Python i aplikacji Java?

Aby uzyskać więcej informacji, zobacz Włączanie monitorowania aplikacji w usłudze Azure App Service.

Autoinstrumentacja

Czy termin "autoinstrumentacja" powinien być pisany z łącznikiem?

Postępujemy zgodnie z przewodnikiem stylu firmy Microsoft w celu zapewnienia spójności dokumentacji produktu publikowanej na platformie Microsoft Learn.

Ogólnie rzecz biorąc, nie dołączamy łącznika po prefiksie "auto".

Gdzie można uzyskać więcej informacji na temat autoinstrumentacji?

Aby uzyskać więcej informacji, zobacz Co to jest autoinstrumentacja dla usługi Azure Monitor Application Insights?.

Autoinstrumentacja dla usługi Azure Kubernetes Service

Czy usługa Azure Kubernetes Service (AKS) obsługuje metryki niestandardowe?

Jeśli chcesz, aby metryki niestandardowe w Node.js, instrumentować aplikacje ręcznie za pomocą dystrybucji usługi Azure Monitor OpenTelemetry.

Język Java umożliwia korzystanie z metryk niestandardowych za pomocą autoinstrumentacji. Metryki niestandardowe można zbierać, aktualizując kod i włączając tę funkcję. Jeśli kod ma już metryki niestandardowe, przepływają po włączeniu automatycznej instrumentacji.

Czy automatyczna instrumentacja usługi AKS działa z aplikacjami zainstrumentowanymi za pomocą zestawu Open Source Software (OSS) OpenTelemetry SDK?

Automatyczna instrumentacja usługi AKS może zakłócić telemetrię wysyłaną do stron trzecich przez open-source'owy zestaw SDK OpenTelemetry.

Czy autoinstrumentacja AKS może współistnieć z instrumentacją ręczną?

Autoinstrumentacja usługi AKS jest przeznaczona do współistnienia z opcjami instrumentacji ręcznej: klasycznym zestawem SDK interfejsu API usługi Application Insights i dystrybucją OpenTelemetry.

Zawsze zapobiega duplikacji danych i zapewnia poprawne funkcjonowanie metryk niestandardowych.

Zapoznaj się z tym wykresem, aby określić, kiedy pierwszeństwo ma autoinstrumentacja lub instrumentacja ręczna.

Język	Pierwszeństwo
Node.js	Instrumentacja ręczna
Jawa	Autoinstrumentacja

Jak upewnić się, że używam najnowszych i najbezpieczniejszych wersji dystrybucji OpenTelemetry usługi Azure Monitor?

Luki w zabezpieczeniach wykryte w dystrybucji OpenTelemetry usługi Azure Monitor są priorytetyzowane, naprawiane i wydawane w następnej wersji.

Automatyczna instrumentacja AKS wprowadza najnowszą wersję dystrybucji OpenTelemetry Azure Monitor do zasobników aplikacji za każdym razem, gdy wdrożenie zostanie zmienione lub ponownie uruchomione.

Dystrybucja OpenTelemetry może stać się podatna dla deploymentów, które nie są zmieniane ani ponownie uruchamiane przez dłuższy czas. Z tego powodu zalecamy cotygodniowe aktualizowanie lub ponowne uruchamianie wdrożeń w celu zapewnienia, że jest używana najnowsza wersja dystrybucji.

Jak mogę się dowiedzieć więcej o dystrybucji OpenTelemetry dla usługi Azure Monitor?

Ta funkcja umożliwia automatyczną instrumentację przez wstrzyknięcie Azure Monitor OpenTelemetry Distro do podów aplikacji.

W przypadku języka Java ta funkcja integruje samodzielną dystrybucję Azure Monitor OpenTelemetry dla języka Java. Zapoznaj się z naszą dokumentacją dystrybucji Java, aby dowiedzieć się więcej na temat binarium instrumentacji Java.

W przypadku Node.js wprowadzamy plik binarny automatycznej instrumentacji oparty na naszej dystrybucji OpenTelemetry usługi Azure Monitor dla Node.js. Aby uzyskać więcej informacji, zobacz dokumentację dotyczącąNode.js dystrybucji. Należy pamiętać, że nie mamy autonomicznej autoinstrumentacji dla Node.js więc nasza dokumentacja dystrybucji jest skierowana do instrumentacji ręcznej. Możesz zignorować kroki konfiguracji oparte na kodzie związane z instrumentacją ręczną. Jednak wszystkie inne elementy w naszej dokumentacji dystrybucji, takie jak ustawienia domyślne, konfiguracje zmiennych środowiskowych itp., mają zastosowanie do tej funkcji.

Gdzie można uzyskać więcej informacji na temat autoinstrumentacji dla usługi AKS?

Aby uzyskać więcej informacji, zobacz Autoinstrumentation for AKS (Autoinstrumentacja dla usługi AKS).

Łańcuchy połączenia

Czy nowe regiony platformy Azure wymagają użycia łańcuchów połączenia?

Nowe regiony platformy Azure wymagają użycia ciągów połączenia zamiast kluczy instrumentacji. Parametry połączenia identyfikują zasób, który chcesz skojarzyć z danymi telemetrycznymi. Pozwala także na modyfikację punktów końcowych, które Twój zasób wykorzystuje jako miejsce docelowe dla telemetrii. Skopiuj parametry połączenia i dodaj ją do kodu aplikacji lub zmiennej środowiskowej.

Czy powinienem używać parametrów połączenia czy kluczy instrumentacyjnych?

Zalecamy używanie ciągów połączenia zamiast kluczy instrumentacji.

Kiedy muszę ustawić zmienną środowiskową?

Należy ręcznie ustawić APPLICATIONINSIGHTS_CONNECTION_STRING we wszystkich scenariuszach, w których system nie udostępnia go automatycznie. Te scenariusze obejmują, ale nie są ograniczone do: programowania lokalnego i funkcji izolowanych platformy .NET przy użyciu integracji z platformą ASP.NET Core. W takich przypadkach zmienna środowiskowa gwarantuje, że potok OpenTelemetry może wysyłać dane telemetryczne do usługi Application Insights. Aby uzyskać więcej informacji na temat konfigurowania parametrów połączenia za pomocą zmiennej środowiskowej, zobacz Configuring OpenTelemetry in Application Insights (Konfigurowanie funkcji OpenTelemetry w usłudze Application Insights).

Jak instrumentować globalną aplikację internetową w celu spełnienia regionalnych wymagań dotyczących zgodności danych?

Aby spełnić wymagania dotyczące zgodności danych regionalnych, użyj regionalnych punktów końcowych usługi Application Insights zamiast globalnego punktu końcowego. Globalny punkt końcowy nie gwarantuje, że dane pozostają w określonym regionie. Regionalne punkty końcowe pomagają zapewnić, że dane telemetryczne od użytkowników w obszarach regulowanych są wysyłane tylko do centrów danych w tych regionach.

Aby skonfigurować globalną aplikację internetową pod kątem zgodności regionalnej:

• Utwórz jeden zasób usługi Application Insights na region z rygorystycznymi wymaganiami dotyczącymi zgodności, takimi jak Unia Europejska lub Stany Zjednoczone.
• Utwórz kolejny zasób usługi Application Insights dla użytkowników we wszystkich innych regionach.
• Skonfiguruj aplikację, aby wysyłała dane telemetryczne do odpowiedniego zasobu usługi Application Insights na podstawie regionu każdego użytkownika. Określ region przy użyciu sygnałów, takich jak adres IP, metadane konta lub ustawienia lokalizacji.
• Połącz wszystkie zasoby usługi Application Insights z obszarem roboczym usługi Log Analytics, jeśli potrzebujesz ujednoliconego środowiska zapytań w różnych regionach.

Przykład:

• Wysyłanie danych od użytkowników z Regionu A do zasobu Regionu A usługi Application Insights używając ciągu połączenia Regionu A.
• Wyślij dane użytkowników Regionu B do zasobu Application Insights w Regionie B, korzystając z ciągu połączenia Regionu B.
• Wyślij wszystkie inne dane użytkownika do zasobu usługi Application Insights ogólnego przeznaczenia przy użyciu różnych parametrów połączenia.

Ważne

Użycie globalnego punktu końcowego nie zapewnia zgodności regionalnej. Aby spełnić wymagania dotyczące rezydencji danych, należy zawsze używać punktów końcowych specyficznych dla regionu i kierować dane telemetryczne na podstawie regionu użytkownika.

Na poniższym diagramie przedstawiono przykładową konfigurację globalnej aplikacji internetowej:

Gdzie można uzyskać więcej informacji na temat parametrów połączenia w usłudze Application Insights?

Aby uzyskać więcej informacji, zobacz Parametry połączenia.

Tworzenie i konfigurowanie zasobów usługi Application Insights

Jak mogę przenieść zasób usługi Application Insights do nowego regionu?

Przenoszenie istniejących zasobów usługi Application Insights między regionami nie jest obsługiwane i nie można migrować danych historycznych do nowego regionu. Obejście obejmuje:

• Tworzenie nowego zasobu usługi Application Insights w żądanym regionie.
• Utwórz ponownie wszystkie unikatowe dostosowania z oryginalnego zasobu w nowym.
• Aktualizowanie aplikacji przy użyciu parametrów połączenia nowego zasobu regionu.
• Testowanie w celu upewnienia się, że wszystko działa zgodnie z oczekiwaniami przy użyciu nowego zasobu usługi Application Insights.
• Zdecyduj się zachować lub usunąć oryginalny zasób usługi Application Insights. Usunięcie zasobu klasycznego oznacza utratę wszystkich danych historycznych. Jeśli zasób jest oparty na obszarze roboczym, dane pozostają w usłudze Log Analytics, umożliwiając dostęp do danych historycznych do momentu wygaśnięcia okresu przechowywania.

Unikatowe dostosowania, które często wymagają ręcznego ponownego utworzenia lub zaktualizowania zasobu w nowym regionie, ale nie są ograniczone do następujących elementów:

• Utwórz ponownie niestandardowe pulpity nawigacyjne i skoroszyty.
• Utwórz ponownie lub zaktualizuj zakres dowolnych alertów dzienników niestandardowych/metryk.
• Utwórz ponownie alerty dostępności.
• Utwórz ponownie dowolne niestandardowe ustawienia kontroli dostępu opartej na rolach platformy Azure, które są wymagane dla użytkowników w celu uzyskania dostępu do nowego zasobu.
• Replikuj ustawienia obejmujące próbkowanie pozyskiwania, przechowywanie danych, dzienny limit i włączanie metryk niestandardowych. Te ustawienia są kontrolowane za pośrednictwem okienka Użycie i szacowane koszty .
• Każda integracja, która opiera się na kluczach interfejsu API, takich jak adnotacje wydania i bezpieczny kanał kontroli metryk na żywo. Musisz wygenerować nowe klucze interfejsu API i zaktualizować skojarzą integrację.
• Eksport ciągły w zasobach klasycznych musi zostać ponownie skonfigurowany.
• Należy ponownie skonfigurować ustawienia diagnostyczne w zasobach opartych na obszarze roboczym.

Czy mogę używać dostawców ('Microsoft.Insights', 'components').apiVersions[0] we wdrożeniach usługi Azure Resource Manager?

Nie zalecamy używania tej metody wypełniania wersji interfejsu API. Najnowsza wersja może reprezentować wersje zapoznawcza, które mogą zawierać zmiany powodujące niezgodność. Nawet w nowszych, stabilnych wersjach interfejsu API, nie zawsze są one zgodne wstecznie z istniejącymi szablonami. W niektórych przypadkach wersja interfejsu API może nie być dostępna dla wszystkich subskrypcji.

Gdzie można uzyskać więcej informacji na temat tworzenia i konfigurowania zasobów usługi Application Insights?

Aby uzyskać więcej informacji, zobacz Tworzenie i konfigurowanie zasobów usługi Application Insights.

Model danych telemetrycznych

Jak zgłosić problemy i sugestie dotyczące modelu danych lub schematu?

Aby zgłosić problemy i sugestie dotyczące modelu danych lub schematu, skorzystaj z naszego repozytorium GitHub.

Jak zmierzyć wpływ kampanii monitorowania?

Telemetria PageView zawiera adres URL i można przeanalizować parametr UTM przy użyciu funkcji regex w usłudze Kusto.

Czasami te dane mogą być brakujące lub niedokładne, jeśli użytkownik lub przedsiębiorstwo wyłączy wysyłanie agenta użytkownika w ustawieniach przeglądarki. Wyrażenia regularne UA Parsera mogą nie zawierać wszystkich informacji o urządzeniu. Usługa Application Insights może nie przyjąć najnowszych aktualizacji.

Dlaczego pomiar niestandardowy zakończy się powodzeniem bez błędu, ale dziennik nie zostanie wyświetlony?

Taka sytuacja może wystąpić, jeśli używasz wartości ciągu. Tylko wartości liczbowe działają z pomiarami niestandardowymi.

Gdzie można uzyskać więcej informacji na temat modelu danych telemetrycznych?

Aby uzyskać więcej informacji, zobacz Model danych telemetrycznych usługi Application Insights.

Rejestrowanie przy użyciu platformy .NET

Jaki typ telemetrii usługi Application Insights jest generowany z dzienników ILogger? Gdzie można wyświetlić dzienniki ILogger w usłudze Application Insights?

ApplicationInsightsLoggerProvider przechwytuje ILogger dzienniki i tworzy TraceTelemetry je na ich podstawie. Exception Jeśli obiekt zostanie przekazany do metody w metodzie w Logmetodzie ILogger , ExceptionTelemetry zostanie utworzony zamiast TraceTelemetry.

Wyświetlanie telemetrii ILogger

W witrynie Azure Portal:

1. Przejdź do witryny Azure Portal i uzyskaj dostęp do zasobu usługi Application Insights.
2. Wybierz sekcję Dzienniki w usłudze Application Insights.
3. Użyj język zapytań Kusto (KQL), aby wysyłać zapytania dotyczące komunikatów ILogger przechowywanych w traces tabeli. Przykładowe zapytanie: traces | where message contains "YourSearchTerm".
4. Uściślij zapytania, aby filtrować dane ILogger według ważności, zakresu czasu lub określonej zawartości wiadomości.

W programie Visual Studio (debuger lokalny):

1. Uruchom aplikację w trybie debugowania w programie Visual Studio.
2. Otwórz okno Narzędzia diagnostyczne , gdy aplikacja jest uruchomiona.
3. Na karcie Zdarzenia dzienniki ILogger są wyświetlane wraz z innymi danymi telemetrycznymi.
4. Aby zlokalizować określone komunikaty ILogger, użyj funkcji wyszukiwania i filtrowania w oknie Narzędzia diagnostyczne .

Jeśli wolisz zawsze wysyłać TraceTelemetry, użyj tego fragmentu kodu:

builder.AddApplicationInsights(
    options => options.TrackExceptionsAsExceptionTelemetry = false);

Dlaczego niektóre dzienniki ILogger nie mają tych samych właściwości co inne?

Usługa Application Insights przechwytuje i wysyła ILogger dzienniki przy użyciu tych samych TelemetryConfiguration informacji, które są używane dla każdej innego telemetrii. Ale jest wyjątek. Domyślnie TelemetryConfiguration nie jest w pełni konfigurowana podczas logowania z Program.cs lub Startup.cs. Dzienniki z tych miejsc nie mają konfiguracji domyślnej, więc nie są uruchomione wszystkie TelemetryInitializer wystąpienia i TelemetryProcessor wystąpienia.

Używam autonomicznego pakietu Microsoft.Extensions.Logging.ApplicationInsights i chcę ręcznie rejestrować więcej niestandardowych danych telemetrycznych. Jak to zrobić?

W przypadku korzystania z pakietu TelemetryClient autonomicznego nie jest wstrzykiwany do kontenera wstrzykiwania zależności (DI). Musisz utworzyć nowe wystąpienie i TelemetryClient użyć tej samej konfiguracji, której używa dostawca rejestratora, jak pokazano w poniższym kodzie. To wymaganie gwarantuje, że ta sama konfiguracja jest używana dla wszystkich niestandardowych danych telemetrycznych i telemetrii z programu ILogger.

public class MyController : ApiController
{
   // This TelemetryClient instance can be used to track additional telemetry through the TrackXXX() API.
   private readonly TelemetryClient _telemetryClient;
   private readonly ILogger _logger;

   public MyController(IOptions<TelemetryConfiguration> options, ILogger<MyController> logger)
   {
        _telemetryClient = new TelemetryClient(options.Value);
        _logger = logger;
   }  
}

Uwaga / Notatka

Jeśli używasz pakietu do włączenia Microsoft.ApplicationInsights.AspNetCore usługi Application Insights, zmodyfikuj ten kod, aby uzyskać TelemetryClient bezpośredni dostęp do konstruktora.

Nie mam zainstalowanego zestawu SDK i używam rozszerzenia Azure Web Apps, aby włączyć usługę Application Insights dla aplikacji ASP.NET Core. Jak mogę użyć nowego dostawcy?

Rozszerzenie Application Insights w usłudze Azure Web Apps używa nowego dostawcy. Reguły filtrowania można zmodyfikować w pliku appsettings.json dla aplikacji.

Gdzie można uzyskać więcej informacji na temat rejestrowania przy użyciu platformy .NET?

Aby uzyskać więcej informacji, zobacz Rejestrowanie usługi Application Insights za pomocą platformy .NET.

Java Profiler

Co to jest profilowanie aplikacji w języku Java w usłudze Azure Monitor Application Insights?

Narzędzie Java Profiler używa narzędzia Java Flight Recorder (JFR) do profilowania aplikacji przy użyciu dostosowanej konfiguracji.

Co to jest narzędzie Java Flight Recorder?

Java Flight Recorder (JFR) to narzędzie do zbierania danych profilowania uruchomionej aplikacji Java. JFR jest zintegrowany z maszyną wirtualną Java (JVM) i służy do rozwiązywania problemów z wydajnością. Dowiedz się więcej o środowisku uruchomieniowym Java SE JFR.

Jaki jest wpływ na cenę i/lub opłatę licencyjną za włączenie profilowania java usługi App Insights?

Profilowanie w języku Java to bezpłatna funkcja z usługą Application Insights. Cennik usługi Azure Monitor Application Insights jest oparty na kosztach pozyskiwania.

Które informacje o profilowaniu języka Java są zbierane?

Dane profilowania zebrane przez JFR obejmują: dane profilowania metod i wykonania, dane dotyczące oczyszczania pamięci i profile blokad.

Jak mogę używać profilowania Java usługi App Insights i wizualizować dane?

Nagrywanie JFR można wyświetlać i analizować za pomocą preferowanego narzędzia, na przykład Java Mission Control (JMC).

Czy usługa App Insights do profilowania Java oferuje diagnostykę wydajności i rekomendacje napraw?

"Diagnostyka wydajności i zalecenia" to nowa funkcja, która wkrótce będzie dostępna jako Diagnostyka Java usługi Application Insights. Możesz zarejestrować się w celu wyświetlenia wersji zapoznawczej tej funkcji. Nagrywanie JFR można wyświetlić za pomocą narzędzia Java Mission Control (JMC).

Jaka jest różnica między profilowaniem na żądanie a automatycznym profilowaniem Java w ramach usługi App Insights?

Profilowanie na żądanie jest wyzwalane przez użytkownika w czasie rzeczywistym, podczas gdy automatyczne profilowanie jest ze wstępnie skonfigurowanymi wyzwalaczami.

Użyj Profiluj Teraz dla opcji profilowania na żądanie. Profil Teraz natychmiast profiluje wszystkich agentów przydzielonych do wystąpienia Application Insights.

Profilowanie automatyczne jest wyzwalane przez osiągnięcie progu zasobu.

Które wyzwalacze profilowania Języka Java można skonfigurować?

Agent java usługi Application Insights obsługuje obecnie monitorowanie użycia procesora CPU i pamięci. Próg procesora CPU jest konfigurowany jako procent wszystkich dostępnych rdzeni na maszynie. Pamięć odnosi się do bieżącego zajęcia regionu pamięci stałej (OldGen) w stosunku do maksymalnego możliwego rozmiaru tego regionu.

Jakie są wymagania wstępne wymagane do włączenia profilowania języka Java?

Zapoznaj się z wymaganiami wstępnymi.

Czy mogę używać profilowania Języka Java dla aplikacji mikrousług?

Tak, możesz profilować maszynę wirtualną JVM z uruchomionymi mikrousługami przy użyciu JFR.

Gdzie mogę uzyskać więcej informacji na temat programu Java Profiler?

Aby uzyskać więcej informacji, zobacz Azure Monitor Application Insights Profiler for Java.Aby uzyskać więcej informacji, zobacz Azure Monitor Application Insights Profiler for Java.

Przesłonięcia próbkowania — usługa Application Insights dla języka Java

Czy muszę użyć instrumentacji ręcznej, aby włączyć przesłonięcia próbkowania?

Nie, przesłonięcia próbkowania są teraz ogólnie dostępne (GA) i mogą być używane zarówno z autoinstrumentacją, jak i instrumentacją ręczną.

Jak skonfigurować przesłonięcia próbkowania podczas korzystania z usługi Azure App Service z funkcją autoinstrumentacji?

Jeśli używasz autoinstrumentacji, zaktualizuj plik applicationinsights.json w portalu Azure.

Czy konieczne jest ręczne przekazanie pliku agenta usługi Application Insights na potrzeby przesłonięć próbkowania?

W przypadku autoinstrumentacji nie jest wymagane ręczne przesyłanie agenta. Jednak w przypadku instrumentacji ręcznej nadal trzeba uwzględnić plik JAR agenta usługi Application Insights i pliki konfiguracji w pakiecie wdrożeniowym.

Jaka jest różnica między "programowaniem lokalnym" i "serwerem aplikacji" w kontekście instrumentacji ręcznej?

Programowanie lokalne odnosi się do środowiska, w którym aplikacja jest kompilowana lub testowana, na przykład maszyna dewelopera lub wystąpienie usługi Azure Cloud Shell. Serwer aplikacji odnosi się do serwera internetowego z uruchomioną aplikacją, takiego jak Tomcat 11 w środowisku usługi Azure App Service. W przypadku korzystania z instrumentacji ręcznej należy upewnić się, że plik JAR agenta jest poprawnie umieszczony na serwerze aplikacji.

Jeśli używam usługi Azure App Service ze środowiskiem uruchomieniowym Java (na przykład Tomcat 11), jak skonfigurować przesłonięcia próbkowania?

W przypadku autoinstrumentacji można skonfigurować przesłonięcia próbkowania za pośrednictwem witryny Azure Portal. W przypadku korzystania z instrumentacji ręcznej należy umieścić plik JAR agenta usługi Application Insights w odpowiednim katalogu i dołączyć plik applicationinsights.json z żądanymi ustawieniami próbkowania.

Gdzie można uzyskać więcej informacji na temat przesłonięć próbkowania?

Aby uzyskać więcej informacji, zobacz Próbkowanie przesłonięć — Azure Monitor Application Insights dla języka Java.

Procesory telemetrii

Dlaczego procesor dziennika nie przetwarza plików dziennika przy użyciu elementu TelemetryClient.trackTrace()?

TelemetryClient.trackTrace() jest częścią klasycznego mostka zestawu SDK usługi Application Insights, a procesory dzienników współpracują tylko z nową instrumentacją opartą na protokole OpenTelemetry.

Gdzie można uzyskać więcej informacji na temat procesorów telemetrii?

Aby uzyskać więcej informacji, zobacz Procesory telemetryczne (wersja zapoznawcza) — Azure Monitor Application Insights dla języka Java.

Zestaw SDK dla języka JavaScript

Jakie są liczby użytkowników i sesji?

• Zestaw SDK języka JavaScript ustawia plik cookie użytkownika na kliencie internetowym, aby zidentyfikować zwracanych użytkowników i plik cookie sesji w celu grupowania działań.
• Jeśli nie ma skryptu po stronie klienta, możesz ustawić pliki cookie na serwerze.
• Jeśli jeden rzeczywisty użytkownik korzysta z witryny w różnych przeglądarkach lub korzysta z przeglądania w trybie prywatnym/incognito lub różnych maszyn, są one liczone więcej niż raz.
• Aby zidentyfikować zalogowanego użytkownika na maszynach i przeglądarkach, dodaj wywołanie polecenia setAuthenticatedUserContext().

Jaka jest wydajność/obciążenie zestawu SDK języka JavaScript?

Zestaw SDK JavaScript Application Insights ma minimalne obciążenie na twojej stronie internetowej. Przy rozmiarze zaledwie 36 KB po kompresji gzip i czasie inicjalizacji wynoszącym tylko około 15 ms, zestaw SDK dodaje zaledwie nieznaczny czas ładowania do Twojej witryny. Minimalne składniki biblioteki są szybko ładowane podczas korzystania z zestawu SDK, a pełny skrypt jest pobierany w tle.

Ponadto podczas pobierania skryptu z sieci CDN wszystkie operacje śledzenia strony są kolejkowane, dzięki czemu nie utracisz żadnych danych telemetrii w całym cyklu życia strony. Ten proces konfiguracji udostępnia stronie bezproblemowy system analityczny niewidoczny dla użytkowników.

Jakie przeglądarki są obsługiwane przez zestaw SDK języka JavaScript?

Najnowsza wersja przeglądarki ✔ Chrome	Najnowsza wersja ✔ przeglądarki Firefox	wersja 3.x: IE 9+ i Microsoft Edge ✔ Wersja 2.x: Zgodne z Internet Explorer 8+ i Microsoft Edge ✔	Opera Najnowsza ✔	Najnowsza wersja ✔ przeglądarki Safari

Gdzie można znaleźć przykłady kodu dla zestawu SDK języka JavaScript?

Aby zobaczyć przykłady do uruchomienia, zobacz Przykłady zestawu SDK usługi Application Insights dla języka JavaScript.

Jaka jest zgodność ES3/Internet Explorer 8 z zestawem SDK języka JavaScript?

Musimy podjąć niezbędne środki, aby upewnić się, że ten zestaw SDK nadal działa i nie przerywa wykonywania języka JavaScript podczas ładowania przez starszą przeglądarkę. Byłoby idealnym rozwiązaniem, aby nie obsługiwać starszych przeglądarek, ale wielu dużych klientów nie może kontrolować, której przeglądarki użytkownicy zdecydują się używać.

Ta instrukcja nie oznacza, że obsługujemy tylko najniższy wspólny zestaw funkcji. Musimy zachować zgodność kodu ES3. Nowe funkcje należy dodać w sposób, który nie przerywa analizowania i dodawania kodu JavaScript w wersji ES3 jako funkcji opcjonalnej.

Aby uzyskać szczegółowe informacje na temat obsługi programu Internet Explorer 8, zobacz GitHub.

Czy zestaw SDK języka JavaScript jest typu open source?

Tak, zestaw SDK języka JavaScript usługi Application Insights jest oprogramowaniem open source. Aby wyświetlić kod źródłowy lub współtworzyć projekt, zobacz oficjalne repozytorium GitHub.

Gdzie można uzyskać więcej informacji na temat zestawu SDK języka JavaScript?

Aby uzyskać więcej informacji, zobacz Włączanie monitorowania rzeczywistego użytkownika usługi Application Insights w usłudze Azure Monitor.

Konfiguracja zestawu SDK języka JavaScript

Jak zaktualizować konfigurację serwera innej firmy dla zestawu SDK języka JavaScript?

Po stronie serwera musi być możliwe akceptowanie połączeń z tymi nagłówkami. W zależności od Access-Control-Allow-Headers konfiguracji po stronie serwera często konieczne jest rozszerzenie listy po stronie serwera przez ręczne dodanie Request-Id, Request-Context i traceparent (nagłówek rozproszony W3C).

Access-Control-Allow-Headers: Request-Id, traceparent, Request-Context<your header>

Jak wyłączyć śledzenie rozproszone dla zestawu JAVAScript SDK?

Śledzenie rozproszone można wyłączyć w konfiguracji.

Czy odpowiedzi HTTP 502 i 503 są zawsze przechwytywane przez usługę Application Insights?

Nie. Błędy "Zła brama 502" i "Usługa 503 niedostępne" nie zawsze są przechwytywane przez usługę Application Insights. Jeśli do monitorowania jest używany tylko język JavaScript po stronie klienta, takie zachowanie byłoby oczekiwane, ponieważ odpowiedź o błędzie jest zwracana przed wyrenderowaniem strony zawierającej nagłówek HTML z fragmentem kodu JavaScript do monitorowania.

Jeśli odpowiedź 502 lub 503 została wysłana z serwera z włączonym monitorowaniem po stronie serwera, błędy są zbierane przez zestaw SDK usługi Application Insights.

Nawet jeśli monitorowanie po stronie serwera jest włączone na serwerze internetowym aplikacji, czasami błąd 502 lub 503 nie jest przechwytywany przez usługę Application Insights. Wiele nowoczesnych serwerów internetowych nie zezwala klientowi na bezpośrednią komunikację. Zamiast tego stosują rozwiązania, takie jak serwery proxy typu reverse, w celu przekazywania informacji między klientem a serwerami front-end.

W tym scenariuszu odpowiedź 502 lub 503 może zostać zwrócona do klienta z powodu problemu w odwrotnej warstwie serwera proxy, więc nie jest przechwytywana poza ramką przez usługę Application Insights. Aby ułatwić wykrywanie problemów w tej warstwie, może być konieczne przekazanie dzienników z zwrotnego serwera proxy do usługi Log Analytics i utworzenie reguły niestandardowej w celu sprawdzenia odpowiedzi 502 lub 503. Aby dowiedzieć się więcej o typowych przyczynach błędów 502 i 503, zobacz Rozwiązywanie problemów z błędami HTTP "502 Bad Gateway" i "503 Service Unavailable" w Azure App Service.

Gdzie można uzyskać więcej informacji na temat konfiguracji zestawu SDK języka JavaScript?

Aby uzyskać więcej informacji, zobacz Konfiguracja zestawu JAVAScript SDK usługi Application Insights.

Rozszerzenia platformy JavaScript

Jak usługa Application Insights generuje informacje o urządzeniu, takie jak przeglądarka, system operacyjny, język i model?

Przeglądarka przekazuje ciąg identyfikacyjny agenta użytkownika w nagłówku HTTP żądania. Usługa przesyłania danych usługi Application Insights używa UA Parser do generowania pól, które widzisz w tabelach danych i środowiskach użytkownika. W związku z tym użytkownicy usługi Application Insights nie mogą zmienić tych pól.

Czasami te dane mogą być brakujące lub niedokładne, jeśli użytkownik lub przedsiębiorstwo wyłączy wysyłanie agenta użytkownika w ustawieniach przeglądarki. Wyrażenia regularne UA Parsera mogą nie zawierać wszystkich informacji o urządzeniu. Usługa Application Insights może nie przyjąć najnowszych aktualizacji.

Gdzie można uzyskać więcej informacji na temat rozszerzeń platformy JavaScript?

Aby uzyskać więcej informacji, zobacz Włączanie rozszerzenia platformy dla zestawu SDK języka JavaScript usługi Application Insights.

Zarządzane obszary robocze

Czy muszę zaktualizować skrypty lub automatyzację odwołujące się do zasobów klasycznych?

Nie. Szablony ARM oraz wywołania API nadal działają. Podczas próby utworzenia zasobu klasycznego zamiast tego zostanie utworzony zasób oparty na obszarze roboczym z zarządzanym obszarem roboczym.

Czy otrzymuję powiadomienie, zanim mój zasób zostanie zmigrowany?

Nie. Powiadomienie dotyczące migracji poszczególnych zasobów nie jest dostępne. Aby kontrolować, kiedy i jak są migrowane zasoby, użyj migracji ręcznej.

Jak długo trwa proces migracji?

Poszczególne migracje są zwykle ukończone w mniej niż dwie minuty. Pełne wdrożenie odbywa się w ciągu kilku tygodni we wszystkich regionach.

Jak sprawdzić, czy zasób jest migrowany?

Po migracji zasób łączy się z obszarem roboczym usługi Log Analytics na stronie Przegląd. Klasyczna informacja o przejściu na emeryturę została usunięta, a skoroszyt emerytur nie zawiera już tego zasobu.

Czy moje rozliczenia zmienią się po migracji?

Koszty zwykle pozostają podobne. Usługa Application Insights oparta na obszarze roboczym umożliwia oszczędzanie kosztów i zalecamy przejrzenie planów cenowych.

Jeśli korzystasz ze starszego modelu rozliczeń, zapoznaj się z dokumentacją cennika , aby uzyskać szczegółowe informacje.

Czy utracię alerty lub testy dostępności podczas migracji?

Nie. Wszystkie alerty, pulpity nawigacyjne i testy dostępności pozostają nienaruszone i nadal działają po migracji.

Gdzie można uzyskać więcej informacji o zarządzanych obszarach roboczych?

Aby uzyskać więcej informacji, zobacz Zarządzane obszary robocze w usłudze Application Insights.

Node.js

Jak wyłączyć korelację telemetrii?

Aby wyłączyć korelację telemetrii, użyj właściwości correlationHeaderExcludedDomains w konfiguracji. Aby uzyskać więcej informacji, zobacz ApplicationInsights-node.js.

Jak skonfigurować żądany poziom dziennika?

Aby skonfigurować żądany poziom dziennika używany przez usługę Application Insights, użyj zmiennej środowiskowej APPLICATIONINSIGHTS_INSTRUMENTATION_LOGGING_LEVEL . Obsługiwane wartości to NONE, ERROR, WARN, INFO, DEBUG, VERBOSE i ALL. Aby uzyskać więcej informacji, zobacz ApplicationInsights-node.js.

Gdzie można uzyskać więcej informacji na temat monitorowania usług i aplikacji Node.js za pomocą usługi Application Insights?

Aby uzyskać więcej informacji, zobacz Monitorowanie usług i aplikacji Node.js za pomocą usługi Application Insights.

Azure Monitor OpenTelemetry

Gdzie można znaleźć listę wersji zestawu SDK usługi Application Insights i ich nazwy?

Lista wersji i nazw zestawu SDK jest hostowana w usłudze GitHub. Aby uzyskać więcej informacji, zobacz Wersja zestawu SDK.

Gdzie można uzyskać więcej informacji na temat technologii OpenTelemetry?

Aby uzyskać więcej informacji, zobacz Zbieranie danych telemetrycznych za pomocą technologii OpenTelemetry w usłudze Application Insights.

Przejdź z .NET Application Insights SDKs do Azure Monitor OpenTelemetry

Jak interfejsy API zestawu SDK mapują na pojęcia openTelemetry?

OpenTelemetry to neutralny względem dostawców system obserwacji. W zestawie SDK OpenTelemetry ani w jego bibliotekach nie ma interfejsów API usługi Application Insights. Przed migracją ważne jest zrozumienie niektórych pojęć związanych z platformą OpenTelemetry.

• W usłudze Application Insights wszystkie dane telemetryczne były zarządzane za pomocą jednego TelemetryClient i TelemetryConfiguration. W usłudze OpenTelemetry każdy z trzech sygnałów telemetrii (ślady, metryki i dzienniki) ma własną konfigurację. Dane telemetryczne można tworzyć ręcznie za pośrednictwem środowiska uruchomieniowego platformy .NET bez bibliotek zewnętrznych. Aby uzyskać więcej informacji, zobacz przewodniki platformy .NET dotyczące śledzenia rozproszonego, metryk i rejestrowania.

• Usługa Application Insights używana TelemetryModules do automatycznego zbierania danych telemetrycznych dla aplikacji. Zamiast tego funkcja OpenTelemetry używa bibliotek instrumentacji do zbierania danych telemetrycznych z określonych składników (takich jak AspNetCore dla żądań i httpClient dla zależności).

• Usługa Application Insights służy TelemetryInitializers do wzbogacania danych telemetrycznych dodatkowymi informacjami lub zastępowania właściwości. Za pomocą funkcji OpenTelemetry można napisać procesor w celu dostosowania określonego sygnału. Ponadto wiele bibliotek instrumentacji OpenTelemetry oferuje metodę Enrich dostosowywania telemetrii wygenerowanej przez ten konkretny składnik.

• Application Insights używa TelemetryProcessors do filtrowania telemetrii. Procesor OpenTelemetry może również służyć do stosowania reguł filtrowania na określonym sygnałie.

Jak typy telemetrii usługi Application Insights mapują się na metryę OpenTelemetry?

Ta tabela mapuje typy danych usługi Application Insights na pojęcia OpenTelemetry i ich implementacje platformy .NET.

Tabela usługi Azure Monitor	Typ danych usługi Application Insights	Typ danych OpenTelemetry	Implementacja platformy .NET
customEvents	EventTelemetry	N/A	N/A
customMetrics	MetrykaTelemetria	Wskaźniki	System.Diagnostics.Metrics.Meter
zależności	Telemetria zależności	Zakresy (Klient, Wewnętrzny, Konsument)	System.Diagnostics.Activity
Wyjątki	WyjątekTelemetria	Wyjątki	System.Exception
żądania	Telemetria Żądania	Zakresy (serwer, producent)	System.Diagnostics.Activity
ślady	TraceTelemetry	Dzienniki	Microsoft.Extensions.Logging.ILogger
ślady	TraceTelemetry	Rozpiętość zdarzeń	System.Diagnostics.ActivityEvent

Poniższe dokumenty zawierają więcej informacji.

• Podstawy zbierania danych usługi Azure Monitor Application Insights
• Model danych telemetrii usługi Application Insights
• Pojęcia dotyczące architektury OpenTelemetry

Jak pojęcia dotyczące próbkowania w usłudze Application Insights są mapowane na metrykę OpenTelemetry?

Chociaż usługa Application Insights oferuje wiele opcji konfigurowania próbkowania, eksporter usługi Azure Monitor lub dystrybucja usługi Azure Monitor oferuje tylko próbkowanie o stałej szybkości. Można próbkować tylko żądania i zależności (ślady OpenTelemetry).

Aby uzyskać przykłady kodu zawierające szczegółowe informacje na temat konfigurowania próbkowania, zobacz nasz przewodnik Włączanie próbkowania

Jak procesory telemetryczne i inicjalizatory odnoszą się do OpenTelemetry?

W zestawie SDK platformy .NET usługi Application Insights użyj procesorów telemetrycznych, aby filtrować i modyfikować lub odrzucać dane telemetryczne. Użyj inicjatorów telemetrii, aby dodać lub zmodyfikować właściwości niestandardowe. Aby uzyskać więcej informacji, zobacz dokumentację usługi Azure Monitor. Funkcja OpenTelemetry zastępuje te pojęcia procesorami aktywności lub dzienników, które wzbogacają i filtrują dane telemetryczne.

Filtrowanie śladów

Aby filtrować dane telemetryczne w usłudze OpenTelemetry, można zaimplementować procesor działań. Ten przykład jest odpowiednikiem przykładu usługi Application Insights na potrzeby filtrowania danych telemetrycznych zgodnie z opisem w dokumentacji usługi Azure Monitor. W przykładzie pokazano, gdzie są filtrowane nieudane wywołania zależności.

using System.Diagnostics;
using OpenTelemetry;

internal sealed class SuccessfulDependencyFilterProcessor : BaseProcessor<Activity>
{
    public override void OnEnd(Activity activity)
    {
        if (!OKtoSend(activity))
        {
            activity.ActivityTraceFlags &= ~ActivityTraceFlags.Recorded;
        }
    }

    private bool OKtoSend(Activity activity)
    {
       return activity.Kind == ActivityKind.Client && activity.Status == ActivityStatusCode.Ok;
    }
}

Aby użyć tego procesora, należy utworzyć TracerProvider i dodać procesor przed AddAzureMonitorTraceExporter.

using OpenTelemetry.Trace;

public static void Main()
{
   var tracerProvider = Sdk.CreateTracerProviderBuilder()
       .AddProcessor(new SuccessfulDependencyFilterProcessor())
       .AddAzureMonitorTraceExporter()
       .Build();
}

Filtrowanie dzienników

ILogger implementacje mają wbudowany mechanizm stosowania filtrowania dzienników. Dzięki temu filtrowaniu można kontrolować dzienniki wysyłane do każdego zarejestrowanego dostawcy, w tym OpenTelemetryLoggerProvider. "OpenTelemetry" to alias dla OpenTelemetryLoggerProvider, używany do konfigurowania reguł filtrowania.

W poniższym przykładzie "Błąd" jest zdefiniowany jako domyślny LogLevel, a "Ostrzeżenie" jako minimum LogLevel dla kategorii zdefiniowanej przez użytkownika. Te reguły zgodnie z definicją dotyczą tylko elementu OpenTelemetryLoggerProvider.

builder.AddFilter<OpenTelemetryLoggerProvider>("*", LogLevel.Error);
builder.AddFilter<OpenTelemetryLoggerProvider>("MyProduct.MyLibrary.MyClass", LogLevel.Warning);

Aby uzyskać więcej informacji, przeczytaj dokumentację OpenTelemetry dla platformy .NET dotyczącą dzienników.

Dodawanie właściwości niestandardowych do śladów

W usłudze OpenTelemetry można użyć procesorów działań, aby wzbogacić dane telemetryczne o więcej właściwości. Jest on podobny do używania inicjatorów telemetrii w usłudze Application Insights, gdzie można modyfikować właściwości telemetrii.

Domyślnie eksporter Azure Monitor oznacza każde żądanie HTTP z kodem odpowiedzi 400 lub większym jako niepowodzenie. Jeśli jednak chcesz traktować wartość 400 jako sukces, możesz dodać wzbogacający procesor działań, który ustawia powodzenie działania i dodaje tag w celu uwzględnienia większej liczby właściwości telemetrii. Podobnie jak dodawanie lub modyfikowanie właściwości za pomocą inicjatora w usłudze Application Insights zgodnie z opisem w dokumentacji usługi Azure Monitor.

Oto przykład dodawania właściwości niestandardowych i zastępowania domyślnego zachowania niektórych kodów odpowiedzi:

using System.Diagnostics;
using OpenTelemetry;

/// <summary>
/// Custom Processor that overrides the default behavior of treating response codes >= 400 as failed requests.
/// </summary>
internal class MyEnrichingProcessor : BaseProcessor<Activity>
{
    public override void OnEnd(Activity activity)
    {
        if (activity.Kind == ActivityKind.Server)
        {
            int responseCode = GetResponseCode(activity);

            if (responseCode >= 400 && responseCode < 500)
            {
               // If we set the Success property, the SDK won't change it
               activity.SetStatus(ActivityStatusCode.Ok);

               // Allow to filter these requests in the portal
              activity.SetTag("Overridden400s", "true");
            }

            // else leave the SDK to set the Success property
        }
    }

    private int GetResponseCode(Activity activity)
    {
       foreach (ref readonly var tag in activity.EnumerateTagObjects())
       {    
          if (tag.Key == "http.response.status_code" && tag.Value is int value)
          {
           return value;
          }
       }

       return 0;
    }
}

Aby użyć tego procesora, należy utworzyć TracerProvider i dodać procesor przed AddAzureMonitorTraceExporter.

using OpenTelemetry.Trace;

public static void Main()
{
   var tracerProvider = Sdk.CreateTracerProviderBuilder()
       .AddSource("Company.Product.Name")
       .AddProcessor(new MyEnrichingProcessor())
       .AddAzureMonitorTraceExporter()
       .Build();
}

Jak mogę ręcznie śledzić dane telemetryczne przy użyciu biblioteki OpenTelemetry?

Wysyłanie śladów — ręczne

Ślady w usłudze Application Insights są przechowywane jako RequestTelemetry i DependencyTelemetry. W usłudze OpenTelemetry ślady są modelowane jako Span przy użyciu Activity klasy .

Platforma .NET OpenTelemetry wykorzystuje klasy ActivitySource i Activity do śledzenia, które są częścią środowiska uruchomieniowego platformy .NET. Takie podejście jest charakterystyczne, ponieważ implementacja platformy .NET integruje interfejs API śledzenia bezpośrednio z samym środowiskiem uruchomieniowym. Pakiet System.Diagnostics.DiagnosticSource umożliwia deweloperom użycie ActivitySource do tworzenia i zarządzania wystąpieniami Activity. Ta metoda zapewnia bezproblemowy sposób dodawania śledzenia do aplikacji platformy .NET bez polegania na bibliotekach zewnętrznych, stosując wbudowane możliwości ekosystemu platformy .NET. Aby uzyskać bardziej szczegółowe informacje, zapoznaj się z instrukcjami instrumentacji śledzenia rozproszonego.

Tak można przeprowadzić migrację śledzenia ręcznego:

Uwaga / Notatka

W usłudze Application Insights można ustawić nazwę roli i wystąpienie roli na poziomie telemetrii. Jednak w przypadku eksportera usługi Azure Monitor nie możemy dostosować się na poziomie telemetrii. Nazwa roli i wystąpienie roli są wyodrębniane z zasobu OpenTelemetry i stosowane w danych telemetrycznych. Przeczytaj ten dokument, aby uzyskać więcej informacji: Ustawianie nazwy roli chmury i wystąpienia roli w chmurze.

Telemetria zależności

Usługa Application Insights DependencyTelemetry służy do modelowania żądań wychodzących. Oto jak konwertować na OpenTelemetry.

Przykład usługi Application Insights:

DependencyTelemetry dep = new DependencyTelemetry
{
   Name = "DependencyName",
   Data = "https://www.example.com/",
   Type = "Http",
   Target = "www.example.com",
   Duration = TimeSpan.FromSeconds(10),
   ResultCode = "500",
   Success = false
};

dep.Context.Cloud.RoleName = "MyRole";
dep.Context.Cloud.RoleInstance = "MyRoleInstance";
dep.Properties["customprop1"] = "custom value1";
client.TrackDependency(dep);

Przykład openTelemetry:

var activitySource = new ActivitySource("Company.Product.Name");
var resourceAttributes = new Dictionary<string, object>
{
   { "service.name", "MyRole" },
   { "service.instance.id", "MyRoleInstance" }
};

var resourceBuilder = ResourceBuilder.CreateDefault().AddAttributes(resourceAttributes);

using var tracerProvider = Sdk.CreateTracerProviderBuilder()
  .SetResourceBuilder(resourceBuilder)
  .AddSource(activitySource.Name)
  .AddAzureMonitorTraceExporter()
  .Build();

// Emit traces
using (var activity = activitySource.StartActivity("DependencyName", ActivityKind.Client))
{
  activity?.SetTag("url.full", "https://www.example.com/");
  activity?.SetTag("server.address", "www.example.com");
  activity?.SetTag("http.request.method", "GET");
  activity?.SetTag("http.response.status_code", "500");
  activity?.SetTag("customprop1", "custom value1");
  activity?.SetStatus(ActivityStatusCode.Error);
  activity?.SetEndTime(activity.StartTimeUtc.AddSeconds(10));
}

Telemetria Żądania

Usługa Application Insights RequestTelemetry modeluje żądania przychodzące. Oto jak przeprowadzić migrację do OpenTelemetry:

Przykład usługi Application Insights:

RequestTelemetry req = new RequestTelemetry
{
   Name = "RequestName",
   Url = new Uri("http://example.com"),
   Duration = TimeSpan.FromSeconds(10),
   ResponseCode = "200",
   Success = true,
   Properties = { ["customprop1"] = "custom value1" }
};

req.Context.Cloud.RoleName = "MyRole";
req.Context.Cloud.RoleInstance = "MyRoleInstance";
client.TrackRequest(req);

Przykład openTelemetry:

var activitySource = new ActivitySource("Company.Product.Name");
var resourceAttributes = new Dictionary<string, object>
{
   { "service.name", "MyRole" },
   { "service.instance.id", "MyRoleInstance" }
};

var resourceBuilder = ResourceBuilder.CreateDefault().AddAttributes(resourceAttributes);

using var tracerProvider = Sdk.CreateTracerProviderBuilder()
  .SetResourceBuilder(resourceBuilder)
  .AddSource(activitySource.Name)
  .AddAzureMonitorTraceExporter()
  .Build();

// Emit traces
using (var activity = activitySource.StartActivity("RequestName", ActivityKind.Server))
{
  activity?.SetTag("url.scheme", "https");
  activity?.SetTag("server.address", "www.example.com");
  activity?.SetTag("url.path", "/");
  activity?.SetTag("http.response.status_code", "200");
  activity?.SetTag("customprop1", "custom value1");
  activity?.SetStatus(ActivityStatusCode.Ok);
}

Niestandardowe śledzenie operacji

W usłudze Application Insights śledź operacje niestandardowe przy użyciu metod StartOperation i StopOperation Osiągnij to, używając ActivitySource oraz Activity w OpenTelemetry .NET. W przypadku operacji z ActivityKind.Server i ActivityKind.Consumer, eksporter usługi Azure Monitor generuje RequestTelemetry. Dla ActivityKind.Client, ActivityKind.Producer i ActivityKind.Internal generuje DependencyTelemetry. Aby uzyskać więcej informacji na temat śledzenia operacji niestandardowych, zobacz dokumentację usługi Azure Monitor. Aby uzyskać więcej informacji na temat korzystania z ActivitySource i Activity w .NET, zobacz przewodniki po implementacji śledzenia rozproszonego w .NET.

Oto przykład uruchamiania i zatrzymywania działania dla operacji niestandardowych:

using System.Diagnostics;
using OpenTelemetry;

var activitySource = new ActivitySource("Company.Product.Name");

using var tracerProvider = Sdk.CreateTracerProviderBuilder()
    .AddSource(activitySource.Name)
    .AddAzureMonitorTraceExporter()
    .Build();

// Start a new activity
using (var activity = activitySource.StartActivity("CustomOperation", ActivityKind.Server))
{
    activity?.SetTag("customTag", "customValue");

    // Perform your custom operation logic here

    // No need to explicitly call Activity.Stop() because the using block automatically disposes the Activity object, which stops it.
}

Wysyłanie dzienników

Dzienniki w usłudze Application Insights są przechowywane jako TraceTelemetry i ExceptionTelemetry.

TraceTelemetry

W programie OpenTelemetry rejestrowanie jest zintegrowane za pośrednictwem interfejsu ILogger . Oto jak przeprowadzić migrację TraceTelemetry:

Przykład usługi Application Insights:

TraceTelemetry traceTelemetry = new TraceTelemetry 
{
   Message = "hello from tomato 2.99",
   SeverityLevel = SeverityLevel.Warning,
};

traceTelemetry.Context.Cloud.RoleName = "MyRole";
traceTelemetry.Context.Cloud.RoleInstance = "MyRoleInstance";
client.TrackTrace(traceTelemetry);

Przykład openTelemetry:

var resourceAttributes = new Dictionary<string, object>
{
   { "service.name", "MyRole" },
   { "service.instance.id", "MyRoleInstance" }
};

var resourceBuilder = ResourceBuilder.CreateDefault().AddAttributes(resourceAttributes);

using var loggerFactory = LoggerFactory.Create(builder => builder
   .AddOpenTelemetry(logging =>
   {
       logging.SetResourceBuilder(resourceBuilder);
       logging.AddAzureMonitorLogExporter();
   }));

// Create a new instance `ILogger` from the above LoggerFactory
var logger = loggerFactory.CreateLogger<Program>();

// Emit log: This uses the logger instance to write a new log
logger.FoodPrice("tomato", 2.99);

internal static partial class LoggerExtensions
{
   [LoggerMessage(LogLevel.Warning, "Hello from `{name}` `{price}`.")]
   public static partial void FoodPrice(this ILogger logger, string name, double price);
}

WyjątekTelemetria

Usługa Application Insights używa ExceptionTelemetry do rejestrowania wyjątków. Oto jak przeprowadzić migrację do OpenTelemetry:

Przykład usługi Application Insights:

ExceptionTelemetry exceptionTelemetry = new ExceptionTelemetry(new Exception("Test exception"))
{
    SeverityLevel = SeverityLevel.Error
};

exceptionTelemetry.Context.Cloud.RoleName = "MyRole";
exceptionTelemetry.Context.Cloud.RoleInstance = "MyRoleInstance";
exceptionTelemetry.Properties["customprop1"] = "custom value1";
client.TrackException(exceptionTelemetry);

Przykład openTelemetry:

var resourceAttributes = new Dictionary<string, object> 
{
   { "service.name", "MyRole" },
   { "service.instance.id", "MyRoleInstance" }
};

var resourceBuilder = ResourceBuilder.CreateDefault().AddAttributes(resourceAttributes);

using var loggerFactory = LoggerFactory.Create(builder => builder
   .AddOpenTelemetry(logging =>
   {
       logging.SetResourceBuilder(resourceBuilder);
       logging.AddAzureMonitorLogExporter();
   }));

// Create a new instance `ILogger` from the above LoggerFactory.
var logger = loggerFactory.CreateLogger<Program>();

try
{
    // Simulate exception
    throw new Exception("Test exception");
}
catch (Exception ex)
{
   // Emit exception: This uses the logger instance to write a new exception
   logger?.LogError(ex, "An error occurred");
}

Wysyłanie metryk

Metryki w usłudze Application Insights są przechowywane jako MetricTelemetry. W OpenTelemetry metryki są modelowane jako Meter z pakietu System.Diagnostics.DiagnosticSource.

Usługa Application Insights ma zarówno niewstępne (TrackMetric()), jak i wstępnie agregujące (GetMetric().TrackValue()) interfejsy API metryk. W przeciwieństwie do OpenTelemetry, usługa Application Insights nie ma pojęcia o instrumentach. Usługa Application Insights ma ten sam interfejs API dla wszystkich scenariuszy metryk.

Z drugiej strony funkcja OpenTelemetry wymaga od użytkowników uprzedniego wybrania odpowiedniego instrumentu metryki na podstawie rzeczywistej semantyki metryki. Jeśli na przykład intencją jest zliczenie czegoś (na przykład liczba odebranych żądań serwera itp.), należy użyć licznika OpenTelemetry. Jeśli intencją jest obliczenie różnych percentyli (takich jak wartość P99 opóźnienia serwera), należy użyć instrumentu Histogramu OpenTelemetry. Ze względu na tę podstawową różnicę między usługą Application Insights i usługą OpenTelemetry nie dokonano bezpośredniego porównania między nimi.

W przeciwieństwie do usługi Application Insights funkcja OpenTelemetry nie udostępnia wbudowanych mechanizmów wzbogacania ani filtrowania metryk. W usłudze Application Insights procesory telemetryczne i inicjatory mogą służyć do modyfikowania lub odrzucania metryk, ale ta funkcja nie jest dostępna w usłudze OpenTelemetry.

Ponadto OpenTelemetry nie obsługuje bezpośredniego wysyłania nieprzetworzonych metryk, ponieważ nie ma odpowiednika funkcjonalności dostępnej w usłudze Application Insights.

Migracja z usługi Application Insights do OpenTelemetry obejmuje zastąpienie wszystkich użyć interfejsu API metryk usługi Application Insights interfejsem API OpenTelemetry. Wymaga to zrozumienia różnych instrumentów OpenTelemetry i ich semantyki.

Wskazówka

Histogram jest najbardziej wszechstronny i najbliższy odpowiednik interfejsu API usługi Application Insights GetMetric().TrackValue(). Możesz zastąpić metryki API Application Insights histogramem, aby osiągnąć ten sam cel.

Inne typy telemetrii

WydarzeniaNiestandardowe

Nieobsługiwane w usłudze OpenTelemetry.

Przykład usługi Application Insights:

TelemetryClient.TrackEvent()

Telemetria dostępności

Nieobsługiwane w usłudze OpenTelemetry.

Przykład usługi Application Insights:

TelemetryClient.TrackAvailability()

PageViewTelemetry

Nieobsługiwane w usłudze OpenTelemetry.

Przykład usługi Application Insights:

TelemetryClient.TrackPageView()

Czy mogę uzyskać metryki na żywo dla aplikacji konsoli i usługi procesu roboczego?

Zalecamy Azure Monitor OpenTelemetry Exporter dla aplikacji konsolowych i aplikacji usług roboczych, które nie zawierają metryk na żywo.

Gdzie można uzyskać więcej informacji na temat migracji z zestawów SDK usługi Application Insights platformy .NET do biblioteki OpenTelemetry?

Aby uzyskać więcej informacji, zobacz Migrowanie z zestawów SDK usługi .NET Application Insights do usługi Azure Monitor OpenTelemetry.

Próbkowanie OpenTelemetry

Czy niestandardowy próbnik usługi Application Insights jest oparty na analizie końcowej?

Niestandardowy selektor usługi Application Insights podejmuje decyzje dotyczące próbkowania po utworzeniu przedziału, a nie wcześniej, więc nie jest zgodne z tradycyjnym podejściem opartym na początku śladu. Zamiast tego stosuje decyzje dotyczące próbkowania na końcu generowania przedziału — po zakończeniu przedziału, ale przed eksportem.

Mimo że to zachowanie w pewien sposób przypomina próbkowanie końcówkowe, próbnik nie czeka na zebranie wielu odcinków z tej samej ścieżki przed podjęciem decyzji. Zamiast tego używa skrótu identyfikatora śledzenia, aby zapewnić kompletność śledzenia.

Takie podejście równoważy kompletność i wydajność śledzenia oraz pozwala uniknąć wyższych kosztów związanych z pełnym próbkowaniem opartym na ogonie.

Aby podejmować decyzje dotyczące próbkowania na podstawie wyniku całego śledzenia (na przykład określenia, czy jakikolwiek zakres w ramach śledzenia zakończył się niepowodzeniem), w agencie podrzędnym lub module zbierającym wymagane jest pełne próbkowanie oparte na ogonie. Ta funkcja nie jest obecnie obsługiwana, ale możesz zażądać jej jako nowej funkcji za pośrednictwem Centrum opinii.

Jak niestandardowe próbkowanie w Application Insights porównuje się z próbkowaniem opartym na czołówce lub końcówce w OpenTelemetry?

Metoda próbkowania	Punkt decyzji	Mocne strony	Słabości
Oparte na głowie	Przed rozpoczęciem sekcji	Małe opóźnienia, minimalne obciążenie	Może próbować wybrać pożądane ślady, w tym błędy
Oparty na ogonie	Po zbuforowaniu przedziałów na podstawie progów czasu lub wolumenu	Umożliwia wysoce selektywne kryteria próbkowania śledzenia	Wyższy koszt i dodatkowe opóźnienie przetwarzania
Przykład niestandardowy usługi App Insights	Koniec generowania zakresu	Równoważy kompletność śledzenia z wydajnością	Wymagane dla zgodności metryk na żywo i klasycznego interfejsu API

Czy mogę próbkować zależności, żądania lub inne typy telemetrii z różnymi szybkościami?

Nie, próbkator stosuje stałą częstotliwość we wszystkich typach telemetrii w śladzie. Żądania, zależności i inne zakresy są zgodne z tą samą wartością procentową próbkowania. Aby zastosować różne stawki na typ telemetrii, rozważ użycie procesorów typu OpenTelemetry span lub (przekształcenia czasu pozyskiwania)[opentelemetry-overview.md#telemetry-routing].

W jaki sposób niestandardowy przykładnik usługi Application Insights propaguje decyzje dotyczące próbkowania?

Niestandardowy selektor usługi Application Insights domyślnie propaguje decyzje o próbkowaniu przy użyciu standardu W3C Trace Context. Ten standard umożliwia podejmowanie decyzji dotyczących próbkowania między usługami. Jednak ponieważ sampler podejmuje decyzje dotyczące próbkowania na końcu generowania segmentu — po wywołaniu usług podrzędnych — propagacja przekazuje niepełne informacje dotyczące próbkowania. To ograniczenie jest zgodne ze specyfikacją kontekstu śledzenia W3C, ale usługi podrzędne nie mogą niezawodnie używać tej propagowanej decyzji próbkowania.

Czy niestandardowy przykładnik usługi Application Insights uwzględnia decyzje dotyczące próbkowania z usług nadrzędnych?

Nie, niestandardowy przykładnik usługi Application Insights zawsze podejmuje niezależną decyzję o próbkowaniu, nawet jeśli usługa nadrzędna używa tego samego algorytmu próbkowania. Decyzje dotyczące próbkowania z usług nadrzędnych, w tym tych korzystających z nagłówków kontekstu śledzenia W3C, nie mają wpływu na decyzję usługi podrzędnej. Jednak wykonuje próbkę na podstawie skrótu identyfikatora śledzenia, aby zapewnić kompletność śledzenia. Aby poprawić spójność i zmniejszyć prawdopodobieństwo uszkodzenia śladów, skonfiguruj wszystkie składniki w systemie tak, aby używały tego samego próbkatora i częstotliwości próbkowania.

Dlaczego niektóre ślady są wyświetlane jako niekompletne nawet w przypadku korzystania z niestandardowego przykładu usługi Application Insights?

Istnieje kilka powodów, dla których ślady mogą być niekompletne:

• Różne węzły w systemie rozproszonym używają różnych metod próbkowania, które nie koordynują decyzji. Na przykład jeden węzeł stosuje próbkowanie oparte na nagłówku OpenTelemetry, a inny węzeł stosuje próbkowanie przy użyciu Niestandardowego Próbnika Azure Monitor.
• Różne węzły są ustawione na różne współczynniki próbkowania, nawet jeśli oba używają tego samego podejścia do próbkowania.
• Ustawiasz filtrowanie, próbkowanie lub limity szybkości w potoku po stronie usługi, a ta konfiguracja pobiera losowe próbki odcinków bez uwzględniania pełności śladu.

Jeśli jeden składnik stosuje próbkowanie oparte na nagłówkach bez propagacji decyzji próbkowania (za pośrednictwem nagłówków kontekstu śledzenia W3C), usługi podrzędne próbkują ślad niezależnie, co może prowadzić do odrzucenia segmentów. W związku z tym niektóre części śladu nie zawsze są dostępne podczas przeglądania w usłudze Application Insights.

Gdzie można uzyskać więcej informacji na temat próbkowania OpenTelemetry?

Aby uzyskać więcej informacji, zobacz Próbkowanie w usłudze Azure Monitor Application Insights z funkcją OpenTelemetry.

Pomoc techniczna i opinie dotyczące platformy OpenTelemetry

Co to jest OpenTelemetry?

Jest to standard open source umożliwiający obserwowanie. Dowiedz się więcej na stronie OpenTelemetry.

Dlaczego usługa Microsoft Azure Monitor inwestuje w rozwiązanie OpenTelemetry?

Firma Microsoft inwestuje w platformę OpenTelemetry z następujących powodów:

• Jest neutralny dla dostawcy i zapewnia spójne interfejsy API/zestawy SDK w różnych językach.
• Z biegiem czasu uważamy, że platforma OpenTelemetry umożliwi klientom usługi Azure Monitor obserwowanie aplikacji napisanych w językach poza obsługiwanymi językami.
• Rozszerza typy danych, które można zbierać za pomocą bogatego zestawu bibliotek instrumentacji.
• Zestawy SDK (Software Development Kit) openTelemetry są zwykle bardziej wydajne na dużą skalę niż ich poprzednicy, zestawy SDK usługi Application Insights.
• OpenTelemetry jest zgodna ze strategią firmy Microsoft w celu przyjęcia rozwiązania open source.

Jaki jest stan funkcji OpenTelemetry?

Zobacz Stan openTelemetry.

Co to jest dystrybucja opentelemetrii usługi Azure Monitor?

Można to postrzegać jako cienką otokę, która łączy wszystkie składniki OpenTelemetry, zapewniając najwyższej klasy doświadczenie na platformie Azure. Ten wrapper jest również nazywany dystrybucją w usłudze OpenTelemetry.

Dlaczego warto używać wersji OpenTelemetry dla Azure Monitor?

Korzystanie z dystrybucji OpenTelemetry usługi Azure Monitor ma kilka zalet w porównaniu z natywnym OpenTelemetry rozwijanym przez społeczność.

• Zmniejsza nakład pracy przy włączaniu
• Obsługiwane przez firmę Microsoft
• Udostępnia funkcje specyficzne dla platformy Azure, takie jak:
  • Próbkowanie zgodne z klasycznymi zestawami SDK usługi Application Insights
  • Uwierzytelnianie Microsoft Entra
  • Przechowywanie offline i automatyczne ponawianie prób
  • Statystykabeat
  • Metryki standardowe usługi Application Insights
  • Wykrywanie metadanych zasobów w celu automatycznego wypełniania nazwy roli chmury i wystąpienia roli chmury w różnych środowiskach Azure.
  • Metryki na żywo

W duchu OpenTelemetry zaprojektowaliśmy dystrybucję tak, aby była otwarta i rozszerzalna. Możesz na przykład dodać następujące elementy:

• Eksportuj Protokołem OTLP (OpenTelemetry Protocol) i jednocześnie wysyłaj do drugiego miejsca docelowego.
• Inne biblioteki instrumentacji niewchodzące w dystrybucję

Ponieważ dystrybucja dostarcza platformę OpenTelemetry, obsługuje wszystko, co jest wspierane przez OpenTelemetry. Na przykład można dodać więcej procesorów telemetrycznych, eksporterów lub bibliotek instrumentacji, jeśli usługa OpenTelemetry je obsługuje.

Uwaga / Notatka

Dystrybucja ustawia próbkownik na niestandardowy próbkownik o stałym współczynniku dla usługi Application Insights. Można to zmienić na inny próbnik, ale może to spowodować wyłączenie niektórych dołączonych możliwości Distro (dystrybucji). Aby uzyskać więcej informacji na temat obsługiwanego próbnika, zobacz sekcję Włączanie próbkowania w Konfigurowaniu Azure Monitor OpenTelemetry.

W przypadku języków bez obsługiwanego autonomicznego eksportera OpenTelemetry usługa Azure Monitor OpenTelemetry Distro jest jedynym obecnie obsługiwanym sposobem korzystania z biblioteki OpenTelemetry w usłudze Azure Monitor. W przypadku języków z obsługiwanym autonomicznym eksporterem OpenTelemetry możesz użyć dystrybucji OpenTelemetry usługi Azure Monitor lub odpowiedniego autonomicznego eksportera OpenTelemetry w zależności od scenariusza telemetrii. Aby uzyskać więcej informacji, zobacz Kiedy należy używać eksportera OpenTelemetry usługi Azure Monitor?.

Jak mogę wypróbować dystrybucję OpenTelemetry usługi Azure Monitor?

Zapoznaj się z naszymi dokumentami dotyczącymi włączania dla platform .NET, Java, JavaScript (Node.js) i języka Python.

Czy powinno się używać OpenTelemetry, czy zestawu SDK usługi Application Insights?

Zalecamy użycie dystrybucji usługi Azure Monitor OpenTelemetry dla nowych projektów, gdy jej możliwości są zgodne z potrzebami monitorowania. OpenTelemetry to standardowa struktura, która zwiększa możliwość obserwacji międzyplatformowych i zapewnia ustandaryzowane podejście do zbierania danych telemetrycznych.

Jednak zestawy SDK usługi Application Insights nadal zapewniają pewne możliwości, które nie są jeszcze w pełni zautomatyzowane w usłudze OpenTelemetry, w tym:

• Automatyczne śledzenie zależności — funkcja OpenTelemetry obsługuje śledzenie zależności, ale niektóre zależności wymagają dodatkowej konfiguracji w porównaniu z automatycznym śledzeniem dostępnym w zestawach SDK usługi Application Insights.
• Niestandardowe typy telemetrii, takie jak AvailabilityTelemetry i PageViewTelemetry — Funkcja OpenTelemetry nie ma bezpośrednich odpowiedników. Podobne funkcje można zaimplementować za pomocą instrumentacji ręcznej.
• Procesory i inicjalizatory telemetrii — platforma OpenTelemetry ma procesory oraz procesory śladów, ale nie zastępują one w pełni procesorów telemetrii i inicjalizatorów w usłudze Application Insights we wszystkich scenariuszach.
• Zbieranie metryk rozszerzonych — chociaż usługa OpenTelemetry ma silny system metryk, niektóre wbudowane metryki z zestawów SDK usługi Application Insights wymagają ręcznej konfiguracji w usłudze OpenTelemetry.

OpenTelemetry zapewnia również zalety w porównaniu do pakietów SDK Application Insights, w tym:

• Lepsza standaryzacja na różnych platformach
• Szerszy ekosystem bibliotek instrumentacji
• Większa elastyczność zbierania i przetwarzania danych
• Ulepszona neutralność dostawcy, chociaż dystrybucja OpenTelemetry w usłudze Azure Monitor jest nadal zoptymalizowana pod kątem platformy Azure.

Integracja rozwiązania OpenTelemetry z usługą Azure Monitor stale się rozwija, a firma Microsoft nadal rozszerza swoje możliwości. Jeśli rozważasz przejście, dokładnie oceń, czy rozwiązanie OpenTelemetry spełnia obecnie wymagania dotyczące możliwości obserwowania, czy zestaw SDK usługi Application Insights pozostaje lepszy dla Twoich potrzeb.

Kiedy należy używać eksportera OpenTelemetry usługi Azure Monitor?

W przypadku ASP.NET Core, Java, Node.js i Python zalecamy użycie dystrybucji OpenTelemetry usługi Azure Monitor. Jest to jeden wiersz kodu, aby rozpocząć pracę.

W przypadku wszystkich innych scenariuszy platformy .NET, w tym klasycznych ASP.NET, aplikacji konsolowych, formularzy systemu Windows (WinForms) itp., zalecamy użycie eksportera OpenTelemetry platformy .NET usługi Azure Monitor: Azure.Monitor.OpenTelemetry.Exporter.

W przypadku bardziej złożonych scenariuszy telemetrii języka Python wymagających zaawansowanej konfiguracji zalecamy użycie eksportera OpenTelemetry usługi Azure Monitor w języku Python.

Jaki jest bieżący stan wersji funkcji w usłudze Azure Monitor OpenTelemetry Distro?

Na poniższym wykresie przedstawiono obsługę funkcji OpenTelemetry dla każdego języka.

Funkcja	.SIEĆ	Node.js	Pyton	Jawa
Śledzenie rozproszone	✅	✅	✅	✅
Metryki niestandardowe	✅	✅	✅	✅
Metryki standardowe	✅	✅	✅	✅
Próbkowanie o stałej częstotliwości	✅	✅	✅	✅
Przechowywanie offline i automatyczne ponowne próby	✅	✅	✅	✅
Raportowanie wyjątków	✅	✅	✅	✅
Zbieranie dzienników	✅	⚠️	✅	✅
Zdarzenia niestandardowe	⚠️	⚠️	⚠️	✅
Uwierzytelnianie Microsoft Entra	✅	✅	✅	✅
Metryki na żywo	✅	✅	✅	✅
Filtrowanie metryk na żywo	✅	❌	❌	❌
Wykrywanie kontekstu zasobów dla maszyn wirtualnych/zestawu skalowania maszyn wirtualnych i usługi App Service	✅	❌	✅	✅
Wykrywanie kontekstu zasobów dla usługi Azure Kubernetes Service (AKS) i funkcji	❌	❌	❌	✅
Zdarzenia testowania dostępności generowane przy użyciu API śledzenia dostępności	❌	❌	❌	✅
Filtrowanie żądań, zależności, dzienników i wyjątków według anonimowego identyfikatora użytkownika i syntetycznego źródła	❌	❌	❌	✅
Filtrowanie zależności, dzienników i wyjątków według nazwy operacji	❌	❌	❌	✅
Próbkowanie adaptacyjne	❌	❌	❌	✅
Profiler platformy .NET	⚠️	❌	❌	⚠️
Debugger Snapshotów	❌	❌	❌	❌

Klucz

• ✅ Ta funkcja jest dostępna dla wszystkich klientów z formalnym wsparciem.
• ⚠✔ Ta funkcja jest dostępna jako publiczna wersja zapoznawcza. Zobacz Dodatkowe warunki użytkowania dla wersji zapoznawczych platformy Microsoft Azure.
• ❌ Ta funkcja jest niedostępna lub nie ma zastosowania.

Czy można używać funkcji OpenTelemetry dla przeglądarek internetowych?

Tak, ale nie zalecamy jej i platforma Azure nie obsługuje jej. Język JavaScript openTelemetry jest mocno zoptymalizowany pod kątem Node.js. Zamiast tego zalecamy używanie zestawu SDK języka JavaScript usługi Application Insights.

Kiedy można oczekiwać, że zestaw SDK OpenTelemetry będzie dostępny do użycia w przeglądarkach internetowych?

Internetowy zestaw SDK openTelemetry nie ma ustalonej osi czasu dostępności. Prawdopodobnie jesteśmy kilka lat od momentu, gdy zestaw SDK dla przeglądarek będzie realną alternatywą dla JavaScript SDK usługi Application Insights.

Czy mogę dzisiaj przetestować OpenTelemetry w przeglądarce internetowej?

Piaskownica sieciowa OpenTelemetry to rozwidlenie stworzone, aby OpenTelemetry działało w przeglądarce. Nie można jeszcze wysyłać danych telemetrycznych do usługi Application Insights. Zestaw SDK nie definiuje ogólnych zdarzeń klienta.

Czy obsługiwane jest działanie usługi Application Insights obok agentów konkurencji, takich jak AppDynamics, DataDog i NewRelic?

Ta praktyka nie jest czymś, co planujemy przetestować ani obsługiwać, chociaż nasze dystrybucje umożliwiają jednoczesne eksportowanie do punktu końcowego OTLP wraz z usługą Azure Monitor.

Czy mogę używać funkcji w wersji zapoznawczej w środowiskach produkcyjnych?

Nie zalecamy tego. Zobacz Dodatkowe warunki użytkowania dla wersji zapoznawczych platformy Microsoft Azure.

Jaka jest różnica między instrumentacją ręczną i automatyczną?

Zobacz Omówienie usługi OpenTelemetry.

Czy mogę użyć kolektora OpenTelemetry?

Niektórzy klienci używają modułu zbierającego OpenTelemetry jako alternatywy dla agenta, mimo że firma Microsoft oficjalnie nie obsługuje podejścia opartego na agencie do monitorowania aplikacji. W międzyczasie społeczność open source przyczyniła się do powstania eksportera OpenTelemetry Collector Azure Monitor, którego niektórzy klienci używają do wysyłania danych do usługi Azure Monitor Application Insights. Nie jest to obsługiwane przez firmę Microsoft.

Jaka jest różnica między usługami OpenCensus i OpenTelemetry?

OpenCensus jest prekursorem OpenTelemetry. Firma Microsoft pomogła połączyć rozwiązania OpenTracing i OpenCensus w celu utworzenia biblioteki OpenTelemetry— jednego standardu obserwacji dla świata. Bieżący zestaw SDK języka Python zalecany w środowisku produkcyjnym dla usługi Azure Monitor jest oparty na usłudze OpenCensus. Firma Microsoft zobowiązuje się do tworzenia usługi Azure Monitor na podstawie biblioteki OpenTelemetry.

W Grafana, dlaczego widzę "Stan 500. Nie można wizualizować zdarzeń śledzenia przy użyciu wizualizatora śledzenia"?

Możesz spróbować zwizualizować nieprzetworzone dzienniki tekstowe, a nie ślady OpenTelemetry.

W usłudze Application Insights tabela "Traces" przechowuje nieprzetworzone dzienniki tekstowe do celów diagnostycznych. Pomagają one identyfikować i korelować ślady skojarzone z żądaniami użytkowników, innymi zdarzeniami i raportami wyjątków. Jednak tabela „Traces” nie przyczynia się bezpośrednio do całościowego przeglądu transakcji (zwanej również wykresem kaskadowym) w narzędziach wizualizacji, takich jak Grafana.

Wraz z rosnącym wdrożeniem rozwiązań natywnych dla chmury istnieje ewolucja kolekcji i terminologii telemetrii. OpenTelemetry stał się standardem zbierania i instrumentowania danych telemetrycznych. W tym kontekście termin "Traces" przyjął nowe znaczenie. Zamiast nieprzetworzonych dzienników funkcja "Traces" w usłudze OpenTelemetry odwołuje się do bogatszej, ustrukturyzowanej formy telemetrii obejmującej zakresy, które reprezentują poszczególne jednostki pracy. Te zakresy mają kluczowe znaczenie dla konstruowania szczegółowych widoków transakcji, co umożliwia lepsze monitorowanie i diagnostykę aplikacji natywnych dla chmury.

Jak instrumentować aplikacje Blazor?

Aby instrumentować aplikację Blazor, najpierw zidentyfikuj model hostingu. Serwer Blazor obsługuje pełną instrumentację opartą na protokole OpenTelemetry. Zestaw WebAssembly platformy Blazor działa w przeglądarce i obsługuje ograniczoną instrumentację za pomocą języka JavaScript.

Gdzie mogę uzyskać więcej informacji na temat pomocy technicznej i opinii dotyczących technologii OpenTelemetry?

Aby uzyskać więcej informacji, zobacz OpenTelemetry Support and Feedback for Application Insights (Obsługa technologii OpenTelemetry i opinie dotyczące usługi Application Insights).

Pulpit nawigacyjny Przegląd

Czy mogę wyświetlić więcej niż 30 dni danych?

Nie, istnieje limit 30 dni danych wyświetlanych na pulpicie nawigacyjnym.

Na pulpicie nawigacyjnym jest wyświetlany błąd "Nie znaleziono zasobu".

Błąd "Nie znaleziono zasobu" może wystąpić w przypadku przeniesienia lub zmiany nazwy wystąpienia usługi Application Insights.

Aby obejść to zachowanie, usuń domyślny pulpit nawigacyjny i ponownie wybierz pozycję Pulpit nawigacyjny aplikacji, aby ponownie utworzyć nowy.

Gdzie można uzyskać więcej informacji na temat pulpitu nawigacyjnego Przegląd?

Aby uzyskać więcej informacji, zobacz Pulpit nawigacyjny przeglądu usługi Application Insights.

Kanały telemetrii

Czy kanał usługi Application Insights gwarantuje dostarczanie danych telemetrycznych? Jeśli nie, jakie są scenariusze, w których można utracić dane telemetryczne?

Krótka odpowiedź polega na tym, że żaden z wbudowanych kanałów nie oferuje gwarancji typu transakcji dostarczania telemetrii do zaplecza. ServerTelemetryChannel jest bardziej zaawansowany w porównaniu z usługą InMemoryChannel w celu zapewnienia niezawodnego dostarczania, ale również sprawia, że tylko próba wysłania danych telemetrycznych jest najlepsza. Dane telemetryczne mogą być nadal tracone w kilku sytuacjach, w tym w następujących typowych scenariuszach:

• Elementy w pamięci zostaną utracone, gdy aplikacja ulegnie awarii.
• Dane telemetryczne są tracone w dłuższych okresach problemów z siecią. Dane telemetryczne są przechowywane na dysku lokalnym podczas awarii sieci lub w przypadku problemów z zapleczem usługi Application Insights. Jednak elementy starsze niż 48 godzin są odrzucane.
• Domyślne lokalizacje dysków do przechowywania danych telemetrycznych w systemie Windows to %LOCALAPPDATA% lub %TEMP%. Te lokalizacje są zwykle lokalne dla maszyny. Jeśli aplikacja migruje fizycznie z jednej lokalizacji do innej, wszelkie dane telemetryczne przechowywane w oryginalnej lokalizacji zostaną utracone.
• W usłudze Azure Web Apps w systemie Windows domyślna lokalizacja magazynu dysków to D:\local\LocalAppData. Ta lokalizacja nie jest utrwalone. Jest on wyczyszczony w przypadku ponownego uruchamiania aplikacji, skalowania w poziomie i innych takich operacji, co prowadzi do utraty przechowywanych tam danych telemetrycznych. Możesz zastąpić wartość domyślną i określić magazyn do utrwalonej lokalizacji, takiej jak D:\home. Jednak takie utrwalone lokalizacje są obsługiwane przez magazyn zdalny i dlatego mogą być powolne.

Chociaż mniej prawdopodobne, kanał może również spowodować zduplikowane elementy telemetrii. To zachowanie występuje, gdy ServerTelemetryChannel ponawianie prób z powodu awarii sieci lub przekroczenia limitu czasu, gdy telemetria została dostarczona do zaplecza, ale odpowiedź została utracona z powodu problemów z siecią lub wystąpiło przekroczenie limitu czasu.

Czy ServerTelemetryChannel działa w systemach innych niż Windows?

Mimo że nazwa pakietu i przestrzeni nazw zawiera ciąg "WindowsServer", ten kanał jest obsługiwany w systemach innych niż Windows, z następującym wyjątkiem. W systemach innych niż Windows kanał domyślnie nie tworzy lokalnego folderu magazynu. Musisz utworzyć folder magazynu lokalnego i skonfigurować kanał, aby go używał. Po skonfigurowaniu magazynu lokalnego kanał działa tak samo jak we wszystkich systemach.

Uwaga / Notatka

W wersji 2.15.0-beta3 i nowszych magazyn lokalny jest teraz automatycznie tworzony dla systemów Linux, Mac i Windows. W przypadku systemów innych niż Windows zestaw SDK automatycznie utworzy lokalny folder magazynu na podstawie następującej logiki:

• ${TMPDIR}: Jeśli zmienna środowiskowa jest ustawiona ${TMPDIR} , ta lokalizacja jest używana.
• /var/tmp: Jeśli poprzednia lokalizacja nie istnieje, spróbujemy wykonać próbę /var/tmp.
• /tmp: Jeśli obie poprzednie lokalizacje nie istnieją, spróbujemy użyć polecenia tmp.
• Jeśli żadna z tych lokalizacji nie istnieje, magazyn lokalny nie zostanie utworzony, a konfiguracja ręczna będzie nadal wymagana. Aby uzyskać szczegółowe informacje o implementacji, zobacz to repozytorium GitHub.

Czy zestaw SDK tworzy magazyn lokalny tymczasowy? Czy dane są szyfrowane w magazynie?

Zestaw SDK przechowuje elementy telemetryczne w magazynie lokalnym podczas problemów z siecią lub podczas ograniczania przepustowości. Te dane nie są szyfrowane lokalnie.

W przypadku systemów Windows zestaw SDK automatycznie tworzy tymczasowy folder lokalny w katalogu %TEMP% lub %LOCALAPPDATA% i ogranicza dostęp tylko do administratorów i bieżącego użytkownika.

W przypadku systemów innych niż Windows żaden magazyn lokalny nie jest tworzony automatycznie przez zestaw SDK, więc żadne dane nie są przechowywane lokalnie.

Uwaga / Notatka

W wersji 2.15.0-beta3 i nowszych magazyn lokalny jest teraz automatycznie tworzony dla systemów Linux, Mac i Windows.

Możesz samodzielnie utworzyć katalog magazynu i skonfigurować go do użycia. W takim przypadku odpowiadasz za zapewnienie, że katalog jest zabezpieczony. Przeczytaj więcej na temat ochrony danych i prywatności.

Gdzie można uzyskać więcej informacji na temat kanałów telemetrii?

Aby uzyskać więcej informacji, zobacz Kanały telemetryczne w usłudze Application Insights.

Wyszukiwanie transakcji

Ile danych jest przechowywanych?

Zobacz podsumowanie limitów.

Jak wyświetlić dane POST w żądaniach serwera?

Nie rejestrujemy danych POST automatycznie, ale możesz użyć funkcji TrackTrace lub wywołań dziennika. Umieść dane POST w parametrze komunikatu. Nie można filtrować komunikatu w taki sam sposób, jak w przypadku właściwości, ale limit rozmiaru jest dłuższy.

Dlaczego wyszukiwanie funkcji platformy Azure nie zwraca żadnych wyników?

Usługa Azure Functions nie rejestruje ciągów zapytań adresu URL.

Gdzie można uzyskać więcej informacji na temat wyszukiwania transakcji?

Aby uzyskać więcej informacji, zobacz Wyszukiwanie transakcji i diagnostyka.

Diagnostyka transakcji

Dlaczego na wykresie widzę jeden składnik, a inne składniki są wyświetlane tylko jako zależności zewnętrzne bez żadnych szczegółów?

Potencjalne przyczyny:

• Czy inne składniki są instrumentowane za pomocą usługi Application Insights?
• Czy korzystają z najnowszego stabilnego zestawu SDK usługi Application Insights?
• Jeśli te składniki są oddzielnymi zasobami usługi Application Insights, sprawdź, czy masz dostęp. Jeśli masz dostęp i składniki są instrumentowane przy użyciu najnowszych zestawów SDK usługi Application Insights, daj nam znać za pośrednictwem kanału opinii w prawym górnym rogu.

Widzę zduplikowane wiersze dla zależności. Czy to zachowanie jest oczekiwane?

Obecnie wyświetlane jest wywołanie zależności ruchu wychodzącego oddzielone od żądania przychodzącego. Zazwyczaj oba wywołania wyglądają identycznie, a różni się tylko długość ich trwania z powodu opóźnienia sieciowego. Ikona wiodąca i odrębne style pasków czasu trwania pomagają je odróżnić. Czy ta prezentacja danych jest myląca? Prześlij nam swoją opinię!

Jakie są rozbieżności zegara między różnymi instancjami składników?

Osie czasu są dostosowywane dla niesymetryczności zegara na wykresie transakcji. Dokładne znaczniki czasu można zobaczyć w okienku szczegółów lub przy użyciu usługi Log Analytics.

Dlaczego w nowym środowisku brakuje większości zapytań dotyczących powiązanych elementów?

Jest to zamierzone działanie. Wszystkie powiązane elementy we wszystkich składnikach są już dostępne po lewej stronie w górnej i dolnej sekcji. Nowe środowisko ma dwa powiązane elementy, których lewa część nie obejmuje: wszystkie dane telemetryczne z pięciu minut przed i po tym zdarzeniu oraz linia czasu użytkownika.

Czy istnieje sposób, aby zobaczyć mniej zdarzeń na transakcję, gdy używam zestawu SDK języka JavaScript usługi Application Insights?

Środowisko diagnostyki transakcji pokazuje wszystkie dane telemetryczne w jednej operacji, która udostępnia identyfikator operacji. Domyślnie zestaw SDK usługi Application Insights dla języka JavaScript tworzy nową operację dla każdego unikatowego widoku strony. W aplikacji jednostronicowej (SPA) generowane jest tylko jedno zdarzenie widoku strony, a dla wszystkich generowanych danych telemetrycznych jest używany pojedynczy identyfikator operacji. W związku z tym wiele zdarzeń może być skorelowanych z tą samą operacją.

W tych scenariuszach możesz użyć automatycznego śledzenia tras, aby automatycznie utworzyć nowe operacje nawigacji w SPA. Należy włączyć funkcję EnableAutoRouteTracking , aby widok strony był generowany za każdym razem, gdy trasa adresu URL jest aktualizowana (występuje widok strony logicznej). Jeśli chcesz ręcznie odświeżyć identyfikator operacji, wywołaj metodę appInsights.properties.context.telemetryTrace.traceID = Microsoft.ApplicationInsights.Telemetry.Util.generateW3CId(). Ręczne wyzwalanie zdarzenia PageView powoduje również zresetowanie identyfikatora operacji.

Dlaczego czasy trwania szczegółów transakcji nie są dodawane do czasu trwania żądania najwyższego poziomu?

Czas, który nie został wyjaśniony na wykresie Gantta, to czas, który nie jest objęty śledzonej zależności. Ten problem może wystąpić, ponieważ wywołania zewnętrzne nie zostały instrumentowane automatycznie lub ręcznie. Może się to również zdarzyć, ponieważ czas potrzebny był w procesie, a nie z powodu wywołania zewnętrznego.

Jeśli wszystkie wywołania zostały instrumentowane, proces jest prawdopodobną główną przyczyną czasu spędzonego. Przydatnym narzędziem do diagnozowania procesu jest Profiler platformy .NET.

Co zrobić, jeśli podczas nawigowania po usłudze Application Insights w witrynie Azure Portal zostanie wyświetlony komunikat "Błąd podczas pobierania danych"?

Wskazuje on, że przeglądarka nie mogła wywołać wymaganego interfejsu API lub interfejs API zwrócił odpowiedź wskazującą na niepowodzenie. Aby rozwiązać problemy z zachowaniem, otwórz okno przeglądarki InPrivate i wyłącz wszystkie uruchomione rozszerzenia przeglądarki , a następnie zidentyfikuj, czy nadal możesz odtworzyć zachowanie portalu. Jeśli błąd portalu nadal występuje, spróbuj przetestować inne przeglądarki lub inne maszyny, zbadaj problemy związane z systemem DNS lub inną siecią z maszyny klienckiej, na której wywołania interfejsu API kończą się niepowodzeniem. Jeśli błąd portalu będzie kontynuowany i wymaga dokładniejszego zbadania, zbierz ślad sieci przeglądarki podczas odtwarzania nieoczekiwanego zachowania portalu, a następnie otwórz zgłoszenie do pomocy technicznej w witrynie Azure Portal.

Gdzie można uzyskać więcej informacji na temat diagnostyki transakcji?

Aby uzyskać więcej informacji, zobacz Wyszukiwanie transakcji i diagnostyka.

Analiza użycia

Czy zdarzenie początkowe reprezentuje pierwszy raz, gdy zdarzenie pojawia się w sesji, czy w dowolnym momencie pojawia się w sesji?

Początkowe zdarzenie w wizualizacji reprezentuje tylko pierwszy raz, gdy użytkownik wysłał ten widok strony lub zdarzenie niestandardowe podczas sesji. Jeśli użytkownicy mogą wysyłać zdarzenie początkowe wielokrotnie w sesji, kolumna Krok 1 pokazuje tylko, jak użytkownicy zachowują się po pierwszym wystąpieniu zdarzenia początkowego, a nie wszystkich wystąpień.

Niektóre węzły w wizualizacji mają zbyt wysoki poziom. Jak uzyskać bardziej szczegółowe węzły?

Użyj opcji Podziel według w menu Edycja:

1. Wybierz zdarzenie, które chcesz podzielić na menu Zdarzenie .

2. Wybierz wymiar w menu Wymiar . Na przykład, jeśli masz zdarzenie o nazwie Button Clicked, spróbuj użyć właściwości niestandardowej o nazwie Nazwa przycisku.

Zdefiniowałem kohortę użytkowników z określonego kraju/regionu. Kiedy porównuję tę kohortę w narzędziu Użytkownicy z ustawieniem filtru na ten kraj/region, dlaczego widzę różne wyniki?

Kohorty i filtry są różne. Załóżmy, że masz kohortę użytkowników z Zjednoczonego Królestwa (zdefiniowaną tak jak w poprzednim przykładzie), a wyniki są porównywane z ustawieniem filtru Country or region = United Kingdom:

• Wersja kohorty pokazuje wszystkie zdarzenia od użytkowników, którzy wysłali co najmniej jedno zdarzenie ze Zjednoczonego Królestwa w bieżącym zakresie czasu. Jeśli podzielisz według kraju lub regionu, prawdopodobnie zobaczysz wiele krajów i regionów.

• Wersja filtrów pokazuje tylko zdarzenia z Zjednoczonego Królestwa. W przypadku podziału według kraju lub regionu zobaczysz tylko Zjednoczone Królestwo.

Jak mogę wyświetlić dane na różnych poziomach szczegółowości (codziennie, co miesiąc lub co tydzień)?

Możesz wybrać filtr ziarnistości daty, aby zmienić poziom szczegółowości. Filtr jest dostępny na wszystkich zakładkach wymiarów.

Jak mogę uzyskać dostęp do szczegółowych informacji z aplikacji, które nie są dostępne w skoroszytach HEART?

Możesz zagłębić się w dane, które zasilają skoroszyt HEART, jeśli wizualizacje nie odpowiadają na wszystkie Twoje pytania. Aby wykonać to zadanie, w sekcji Monitorowanie w usłudze Application Insights wybierz pozycję Dzienniki i wykonaj zapytanie względem customEvents tabeli. Niektóre atrybuty analizy kliknięć znajdują się w customDimensions polu.

Przykładowe zapytanie jest pokazane tutaj:

customEvents
| where isnotnull(customDimensions.actionType)
| extend parentid=tostring(customDimensions.parenId),
pagename=tostring(customDimensions.pageName),
actiontype=tostring(customDimensions.actionType)
| project actiontype,parentid,pagename,
user_AuthenticatedId,user_Id,session_Id,itemType,timestamp

Aby dowiedzieć się więcej na temat dzienników w usłudze Azure Monitor, zobacz Omówienie dzienników usługi Azure Monitor.

Czy mogę edytować wizualizacje w skoroszycie?

Tak. Aby dowiedzieć się, jak edytować szablony skoroszytów, zobacz Szablony skoroszytów platformy Azure.

Gdzie mogę uzyskać więcej informacji na temat analizy użycia?

Aby uzyskać więcej informacji, zobacz Analiza użycia za pomocą usługi Application Insights.

Aplikacje usługi procesów roboczych

Którego pakietu należy użyć?

Scenariusz aplikacji platformy .NET Core	Pakiet
Bez hostowanych usług	WorkerService
Z usługami HostedServices	AspNetCore (nie WorkerService)
W usłudze HostedServices monitorowanie tylko hostowanychusług	WorkerService (rzadki scenariusz)

Czy hostowane usługi w aplikacji .NET Core korzystającej z pakietu AspNetCore mogą mieć wstrzyknięty obiekt TelemetryClient?

Tak, konfiguracja jest udostępniana pozostałej części aplikacji internetowej.

Jak mogę śledzić dane telemetryczne, które nie są zbierane automatycznie?

Uzyskaj wystąpienie TelemetryClient przy użyciu iniekcji konstruktora i wywołaj na nim wymaganą metodę TrackXXX(). Nie zalecamy tworzenia nowych TelemetryClient wystąpień. Singleton TelemetryClient jest już zarejestrowany w kontenerze DependencyInjection, który współdzieli TelemetryConfiguration z resztą telemetrii. Tworzenie nowego TelemetryClient wystąpienia jest zalecane tylko wtedy, gdy wymaga konfiguracji, która jest oddzielona od pozostałej części telemetrii.

Czy mogę użyć środowiska IDE programu Visual Studio do dołączenia usługi Application Insights do projektu usługi Worker Service?

Dołączanie środowiska IDE programu Visual Studio jest obecnie obsługiwane tylko w przypadku aplikacji ASP.NET/ASP.NET Core. Ten dokument jest aktualizowany, gdy Visual Studio wprowadza obsługę wdrażania aplikacji typu Worker Service.

Czy mogę włączyć monitorowanie usługi Application Insights przy użyciu narzędzi, takich jak agent usługi Azure Monitor Application Insights (dawniej Monitor stanu w wersji 2)?

Nie. Agent usługi Azure Monitor Application Insights obecnie obsługuje tylko platformę .NET.

Czy wszystkie funkcje są obsługiwane, jeśli uruchamiam aplikację w systemie Linux?

Tak. Obsługa funkcji dla tego zestawu SDK jest taka sama na wszystkich platformach z następującymi wyjątkami:

• Licznikami wydajności są obsługiwane tylko w systemie Windows, z wyjątkiem liczników Procesora CPU/Pamięci pokazywanych w metrykach na żywo.

• Mimo że ServerTelemetryChannel jest domyślnie włączona, jeśli aplikacja jest uruchomiona w systemie Linux lub macOS, kanał telemetrii nie tworzy automatycznie lokalnego folderu do przechowywania danych telemetrycznych w przypadku problemów z siecią. Z powodu tego ograniczenia dane telemetryczne są tracone, gdy występują tymczasowe problemy z siecią lub serwerem. Aby obejść ten problem, skonfiguruj folder lokalny dla kanału:

  using Microsoft.ApplicationInsights.Channel;
  using Microsoft.ApplicationInsights.WindowsServer.TelemetryChannel;
  
       public void ConfigureServices(IServiceCollection services)
       {
           // The following will configure the channel to use the given folder to temporarily
           // store telemetry items during network or Application Insights server issues.
           // User should ensure that the given folder already exists
           // and that the application has read/write permissions.
           services.AddSingleton(typeof(ITelemetryChannel),
                                   new ServerTelemetryChannel () {StorageFolder = "/tmp/myfolder"});
           services.AddApplicationInsightsTelemetryWorkerService();
       }
  

Gdzie można uzyskać więcej informacji na temat aplikacji usługi procesu roboczego?

Aby uzyskać więcej informacji, zobacz Application Insights for Worker Service applications (aplikacje inne niż HTTP).

Oficjalne często zadawane pytania dotyczące usługi Azure Monitor Application Insights. Znajdź odpowiedzi na pytania dotyczące korzystania z usługi Application Insights z usługą Azure Monitor.

Aby uzyskać szczegółowe informacje na temat instrumentowania aplikacji w celu włączenia usługi Application Insights, zobacz Podstawy zbierania danych.

Po włączeniu usługi Application Insights przez instrumentację aplikacji zalecamy najpierw sprawdzenie metryk na żywo i mapy aplikacji.

Z poziomu aplikacji internetowych serwera:

• Żądania HTTP.
• Zależności. Wywołania baz danych SQL, wywołania HTTP do usług zewnętrznych, Azure Cosmos DB, Azure Table Storage, Azure Blob Storage i Azure Queue Storage.
• Wyjątki i ślad stosu.
• Liczniki wydajności: liczniki wydajności są dostępne w przypadku użycia:
  • Agent usługi Azure Monitor - Application Insights
  • Monitorowanie platformy Azure dla maszyn wirtualnych lub zestawów skalowania maszyn wirtualnych
  • collectd usługi Application Insights.
• Zdarzenia niestandardowe i metryki , które kodujesz.
• Dzienniki śledzenia jeśli skonfigurujesz odpowiedni moduł zbierający.

Ze stron internetowych klienta:

• Nieprzechwycone wyjątki w aplikacji, w tym informacje na temat

  • Ślad stosu
  • Szczegóły wyjątku i komunikat towarzyszący błędowi
  • Liczba wierszy i kolumn błędów
  • Adres URL, pod którym został zgłoszony błąd
  • Żądania zależności sieci wysyłane przez XML Http Request (XHR) i Fetch (zbiory pobierania są domyślnie wyłączone) obejmują następujące informacje:
    • Adres URL źródła zależności
    • Polecenie i metoda używana do żądania zależności
    • Czas trwania żądania
    • Kod wyniku i stan powodzenia żądania
    • Identyfikator (jeśli istnieje) użytkownika wysyłającego żądanie
    • Kontekst korelacji (jeśli istnieje), w którym jest wykonywane żądanie

• Informacje o użytkowniku (na przykład lokalizacja, sieć, adres IP)

• Informacje o urządzeniu (na przykład Przeglądarka, system operacyjny, wersja, język, model)

• Informacje o sesji

  Uwaga / Notatka

  W przypadku niektórych aplikacji, takich jak aplikacje jednostronicowe (SPA), czas trwania nie zawsze jest rejestrowany i w takich przypadkach wartość domyślna to 0.

  Aby uzyskać więcej informacji, zobacz Zbieranie, przechowywanie i magazynowanie danych w usłudze Application Insights.

Z innych źródeł, jeśli je skonfigurujesz:

• Diagnostyka platformy Azure
• Importowanie do usługi Log Analytics
• Log Analytics
• Usługa Logstash

Aby zrozumieć liczbę zasobów usługi Application Insights wymaganych do pokrycia aplikacji lub składników w środowiskach, zobacz Przewodnik planowania wdrażania usługi Application Insights.

Skrypty programu PowerShell można napisać przy użyciu usługi Azure Resource Monitor w celu:

• Tworzenie i aktualizowanie zasobów usługi Application Insights.
• Ustaw plan cenowy.
• Pobierz klucz instrumentacji.
• Dodaj alert dla metryki.
• Dodaj test dostępności.

Nie można skonfigurować raportu eksploratora metryk ani skonfigurować eksportu ciągłego.

Użyj interfejsu API REST do uruchamiania zapytań usługi Log Analytics.

Zalecamy dystrybucję Azure Monitor OpenTelemetry.

Schemat ingesji i protokół punktu końcowego są dostępne publicznie.

Większość danych usługi Application Insights ma opóźnienie poniżej 5 minut. Niektóre dane mogą trwać dłużej, co jest typowe dla większych plików dziennika. Zobacz umowę dotyczącą poziomu usług usługi Application Insights.

Kolekcja

Usługa Application Insights zbiera dane telemetryczne dotyczące aplikacji, w tym dane telemetryczne serwera internetowego, telemetrię strony internetowej i liczniki wydajności. Te dane mogą służyć do monitorowania wydajności, kondycji i użycia aplikacji. Możesz wybrać lokalizację podczas tworzenia nowego zasobu usługi Application Insights.

Retencja i przechowywanie

Dane są wysyłane do obszaru roboczego usługi Application Insights Log Analytics. Okres przechowywania danych pierwotnych można wybrać z zakresu od 30 do 730 dni. Zagregowane dane są przechowywane przez 90 dni, a migawki debugowania są przechowywane przez 15 dni.

Prywatność

Usługa Application Insights domyślnie nie obsługuje poufnych danych. Zalecamy, aby nie umieszczać poufnych danych w adresach URL jako zwykłego tekstu i upewnić się, że niestandardowy kod nie zbiera osobistych ani innych poufnych danych. Podczas programowania i testowania sprawdź wysłane dane w środowisku IDE i oknach danych wyjściowych debugowania przeglądarki.

Aby uzyskać zarchiwizowane informacje, zobacz Zbieranie, przechowywanie i przechowywanie danych w usłudze Application Insights.

Usługa Application Insights jest rozliczana za pośrednictwem obszaru roboczego usługi Log Analytics, gdzie są gromadzone dane dziennika. Domyślna warstwa cenowa usługi Log Analytics z rozliczaniem według zużycia obejmuje 5 GB miesięcznie dostępnej puli danych na konto rozliczeniowe. Dowiedz się więcej o opcjach cen dzienników usługi Azure Monitor.

• Jeśli aplikacja internetowa platformy Azure jest hostowana w centrum danych, w którym znajduje się punkt końcowy kolekcji usługi Application Insights, nie są naliczane opłaty.
• Jeśli w centrum danych hosta nie ma punktu końcowego zbierania danych, dane telemetryczne aplikacji generują opłaty za dane wychodzące z Azure.

Ta odpowiedź zależy od dystrybucji naszych punktów końcowych, a nie od lokalizacji, w której jest hostowany zasób usługi Application Insights.

Tak, możesz ponosić więcej kosztów sieciowych, które różnią się w zależności od regionu, z którego pochodzą dane telemetryczne i do którego zmierzają. Aby uzyskać szczegółowe informacje, zapoznaj się z cennikiem przepustowości platformy Azure.

Jeśli widzisz nieoczekiwane opłaty lub wysokie koszty w usłudze Application Insights, ten przewodnik może pomóc. Obejmuje ona typowe przyczyny, takie jak duża ilość danych telemetrycznych, skoki pozyskiwania danych i błędnie skonfigurowane próbkowanie. Jest to szczególnie przydatne, jeśli rozwiązujesz problemy związane ze wzrostem kosztów, ilością danych telemetrycznych, niedziałającym próbkowaniem, limitami danych, wysokim pozyskiwaniem lub nieoczekiwanymi rozliczeniami. Aby rozpocząć, zobacz Rozwiązywanie problemów z wysokim poziomem pobierania danych w usłudze Application Insights.

Usługa Application Insights używa protokołu Transport Layer Security (TLS) 1.2 i 1.3.

Ważne

1 marca 2025 r. platforma Azure wycofa starsze wersje protokołu TLS we wszystkich usługach. W tym czasie usługa Application Insights nie obsługuje już protokołów TLS 1.0, TLS 1.1 i wymienionych starszych zestawów szyfrowania TLS 1.2/1.3 i krzywych eliptycznych.

Aby uzyskać ogólne pytania dotyczące starszego problemu z protokołem TLS, zobacz Rozwiązywanie problemów z protokołem TLS i obsługa protokołu TLS w usłudze Azure Resource Manager.

Aby uzyskać więcej informacji, zobacz Wprowadzenie do usługi Application Insights.

Oba kanały telemetrii utracą buforowane dane telemetryczne, jeśli nie zostaną opróżnione przed zamknięciem aplikacji.

Aby uniknąć utraty danych, opróżnij obiekt TelemetryClient po zamknięciu aplikacji.

Aby uzyskać więcej informacji, zobacz Opróżnianie danych.

Żaden. Nie musisz ich opakowywać w klauzule try-catch. Jeśli zestaw SDK napotka problemy, będzie rejestrować komunikaty w konsoli debugowania i, jeśli komunikaty przejdą, w wyszukiwarce diagnostycznej.

Tak, API do dostępu do danych. Inne sposoby wyodrębniania danych obejmują usługę Power BI na zasobie opartym na obszarze roboczym.

Zestaw SDK usługi Application Insights nie jest zgodny z autoinstrumentacją. Jeśli funkcja autoinstrumentacji jest włączona, wywołania Track() oraz wszystkie inne niestandardowe zdarzenia i API metryk zostaną zignorowane.

Wyłącz automatyczne instrumentację w witrynie Azure Portal na karcie Application Insights na stronie usługi App Service lub ustaw wartość ApplicationInsightsAgent_EXTENSION_VERSIONdisabled.

Próbkowanie zmniejsza liczbę elementów telemetrii (takich jak żądania i zdarzenia definiowane przez użytkownika), które są wysyłane z aplikacji do portalu. W polu Wyszukiwania widzisz liczbę otrzymanych elementów. Na wykresach metryk, które wyświetlają liczbę zdarzeń, zobaczysz liczbę oryginalnych zdarzeń, które wystąpiły.

Każdy przesłany element zawiera itemCount właściwość, która pokazuje, ile oryginalnych zdarzeń reprezentuje dany element. Aby obserwować próbkowanie w operacji, możesz uruchomić to zapytanie w usłudze Log Analytics:

requests | summarize original_events = sum(itemCount), transmitted_events = count()

Alerty platformy Azure dotyczą tylko metryk. Utwórz niestandardową metrykę, która przekracza próg wartości przy każdym wystąpieniu zdarzenia. Następnie ustaw alert na metrykę. Otrzymasz powiadomienie za każdym razem, gdy metryka przekroczy próg w dowolnym kierunku. Nie otrzymasz powiadomienia do momentu pierwszego przejścia, bez względu na to, czy początkowa wartość jest wysoka, czy niska. Zawsze występuje opóźnienie kilku minut.

Aby uzyskać więcej informacji, zobacz interfejs API usługi Application Insights dla zdarzeń i metryk niestandardowych.

Tak. Istnieje wiele sposobów pobierania agenta usługi Application Insights:

• Jeśli komputer ma dostęp do Internetu, możesz dołączyć do Galeria programu PowerShell przy użyciu -Proxy parametrów.
• Możesz również ręcznie pobrać moduł i zainstalować go na komputerze lub użyć go bezpośrednio.

Każda z tych opcji jest opisana w szczegółowych instrukcjach.

Tak. W programie Application Insights Agent 2.0.0 lub nowszym obsługiwane są aplikacje ASP.NET Core hostowane w usługach IIS.

• Aby sprawdzić, czy włączenie zakończyło się pomyślnie, możesz użyć polecenia cmdlet Get-ApplicationInsightsMonitoringStatus .

• Użyj metryk na żywo , aby szybko określić, czy aplikacja wysyła dane telemetryczne.

• Możesz również użyć usługi Log Analytics , aby wyświetlić listę wszystkich ról chmury, które obecnie wysyłają dane telemetryczne:

  union * | summarize count() by cloud_RoleName, cloud_RoleInstance
  

Aby uzyskać przekazywanie serwera proxy, skonfiguruj serwer proxy na poziomie komputera lub serwer proxy na poziomie aplikacji. Zobacz DefaultProxy.

Przykład web.config:

<system.net>
    <defaultProxy>
    <proxy proxyaddress="http://xx.xx.xx.xx:yyyy" bypassonlocal="true"/>
    </defaultProxy>
</system.net>

Aby uzyskać więcej informacji, zobacz Wdrażanie agenta usługi Application Insights dla serwerów lokalnych.

Application Insights i Azure Monitor nie kontrolują wersji TLS używanej do połączeń HTTPS. Wersja TLS zależy od systemu operacyjnego i środowiska uruchomieniowego, w którym działa Twoja aplikacja.

Aby potwierdzić używaną wersję TLS:

• Przeczytaj dokumentację dotyczącą swojego systemu operacyjnego oraz środowiska wykonawczego lub frameworka.
• Skontaktuj się z odpowiednim zespołem wsparcia, jeśli potrzebujesz dalszej pomocy. Nie otwieraj zgłoszenia do działu wsparcia w Application Insights.

Przykładowy język i wsparcie środowiska uruchomieniowego dla TLS 1.2+

Następujące wersje obejmują zintegrowane wsparcie dla TLS 1.2 lub nowszych:

• .NET / .NET Core: .NET Framework w wersji 4.6.2 lub nowszej oraz wszystkie wersje .NET Core.
• Java: Java 8 update 161 (8u161) lub nowszy
• Python: Dystrybucje Pythona zbudowane z użyciem OpenSSL 1.0.1 lub nowszego
• Node.js: wersja Node.js 10 lub nowsza

Przykładowe wsparcie systemu operacyjnego dla TLS 1.2+

Następujące systemy operacyjne zawierają wbudowaną obsługę TLS 1.2 lub wyższej wersji:

• Windows: Windows 8, Windows Server 2012 i nowsze
• Linux: Większość nowoczesnych dystrybucji Linuxa używających OpenSSL 1.0.1 lub nowszych

Aby uniknąć zakłóceń w usłudze, każdy zdalny punkt końcowy (w tym zależne żądania), z którym wchodzi w interakcję Twój zasób, musi obsługiwać co najmniej jedną kombinację tej samej wersji protokołu, zestawu szyfrów i krzywej eliptycznej, o której wspomniano wcześniej. Jeśli zdalny punkt końcowy nie obsługuje wymaganej konfiguracji protokołu TLS, należy go zaktualizować z obsługą niektórych kombinacji konfiguracji protokołu TLS po zakończeniu obsługi.

Zasoby Application Insights, które zostały dotknięte, przestają przyjmować dane i nie mogą uzyskać dostępu do wymaganych komponentów aplikacji. W wyniku tego niektóre funkcje przestają działać.

Szczegóły dotyczące wycofywania Transport Layer Security (TLS) opisane w tym dokumencie powinny zacząć wpływać na zachowanie systemu dopiero po 1 maja 2025 roku. Aby uzyskać więcej informacji na temat operacji CRUD, zobacz Azure Resource Manager TLS Support. Ten zasób zawiera więcej szczegółów dotyczących obsługi protokołu TLS i harmonogramów wycofywania.

Aby uzyskać ogólne informacje na temat problemu z przestarzałym TLS, zobacz Rozwiązywanie problemów TLS.

Aby uzyskać więcej informacji, zobacz Obsługa protokołu TLS.

Aby usunąć usługę Application Insights, należy usunąć pakiety NuGet i odwołania z interfejsu API w aplikacji. Pakiety NuGet można odinstalować przy użyciu Menedżer pakietów NuGet w programie Visual Studio.

1. Jeśli kolekcja śledzenia jest włączona, najpierw odinstaluj pakiet Microsoft.ApplicationInsights.TraceListener za pomocą Menedżera pakietów NuGet, ale nie usuwaj żadnych zależności.
2. Odinstaluj pakiet Microsoft.ApplicationInsights.Web i usuń jego zależności, używając Menedżera pakietów NuGet oraz jego opcji Odinstaluj w kontrolce Opcje Menedżera pakietów NuGet.
3. Aby w pełni usunąć usługę Application Insights, sprawdź i ręcznie usuń dodany kod lub pliki wraz z wszystkimi wywołaniami interfejsu API dodanymi w projekcie. Aby uzyskać więcej informacji, zobacz Co jest tworzone automatycznie podczas dodawania zestawu SDK usługi Application Insights?.

Po dodaniu usługi Application Insights do projektu program automatycznie tworzy pliki i dodaje kod do niektórych plików. Wyłącznie odinstalowywanie pakietów NuGet nie zawsze odrzuca pliki i kod. Aby w pełni usunąć usługę Application Insights, należy sprawdzić i ręcznie usunąć dodany kod lub pliki wraz z wszystkimi wywołaniami interfejsu API dodanymi w projekcie.

Po dodaniu telemetrii usługi Application Insights do projektu ASP.NET programu Visual Studio dodaje on następujące pliki:

• ApplicationInsights.config
• AiHandleErrorAttribute.cs

Następujące fragmenty kodu są automatycznie dodawane:

• [Nazwa projektu].csproj

    <ApplicationInsightsResourceId>/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourcegroups/Default-ApplicationInsights-EastUS/providers/microsoft.insights/components/WebApplication4</ApplicationInsightsResourceId>
  

• Packages.config

  <packages>
  ...
  
     <package id="Microsoft.ApplicationInsights" version="2.12.0" targetFramework="net472" />
     <package id="Microsoft.ApplicationInsights.Agent.Intercept" version="2.4.0" targetFramework="net472" />
     <package id="Microsoft.ApplicationInsights.DependencyCollector" version="2.12.0" targetFramework="net472" />
     <package id="Microsoft.ApplicationInsights.PerfCounterCollector" version="2.12.0" targetFramework="net472" />
     <package id="Microsoft.ApplicationInsights.Web" version="2.12.0" targetFramework="net472" />
     <package id="Microsoft.ApplicationInsights.WindowsServer" version="2.12.0" targetFramework="net472" />
     <package id="Microsoft.ApplicationInsights.WindowsServer.TelemetryChannel" version="2.12.0" targetFramework="net472" />
  
     <package id="Microsoft.AspNet.TelemetryCorrelation" version="1.0.7" targetFramework="net472" />
  
     <package id="System.Buffers" version="4.4.0" targetFramework="net472" />
     <package id="System.Diagnostics.DiagnosticSource" version="4.6.0" targetFramework="net472" />
     <package id="System.Memory" version="4.5.3" targetFramework="net472" />
     <package id="System.Numerics.Vectors" version="4.4.0" targetFramework="net472" />
     <package id="System.Runtime.CompilerServices.Unsafe" version="4.5.2" targetFramework="net472" />
  ...
  </packages>
  

• Layout.cshtml

  Jeśli projekt ma plik Layout.cshtml , dodawany jest następujący kod.

  <head>
  ...
       <script type = 'text/javascript' >
           var appInsights=window.appInsights||function(config)
           {
               function r(config){ t[config] = function(){ var i = arguments; t.queue.push(function(){ t[config].apply(t, i)})} }
               var t = { config:config},u=document,e=window,o='script',s=u.createElement(o),i,f;for(s.src=config.url||'//az416426.vo.msecnd.net/scripts/a/ai.0.js',u.getElementsByTagName(o)[0].parentNode.appendChild(s),t.cookie=u.cookie,t.queue=[],i=['Event','Exception','Metric','PageView','Trace','Ajax'];i.length;)r('track'+i.pop());return r('setAuthenticatedUserContext'),r('clearAuthenticatedUserContext'),config.disableExceptionTracking||(i='onerror',r('_'+i),f=e[i],e[i]=function(config, r, u, e, o) { var s = f && f(config, r, u, e, o); return s !== !0 && t['_' + i](config, r, u, e, o),s}),t
           }({
               instrumentationKey:'00000000-0000-0000-0000-000000000000'
           });
  
           window.appInsights=appInsights;
           appInsights.trackPageView();
       </script>
  ...
  </head>
  

• ConnectedService.json

  {
     "ProviderId": "Microsoft.ApplicationInsights.ConnectedService.ConnectedServiceProvider",
     "Version": "16.0.0.0",
     "GettingStartedDocument": {
       "Uri": "https://go.microsoft.com/fwlink/?LinkID=613413"
    }
  }
  

• FilterConfig.cs

           public static void RegisterGlobalFilters(GlobalFilterCollection filters)
           {
               filters.Add(new ErrorHandler.AiHandleErrorAttribute());// This line was added
           }
  

Aby wyłączyć korelację telemetrii w konfiguracji, zobacz <ExcludeComponentCorrelationHttpHeadersOnDomains> w usłudze Application Insights dla aplikacji konsolowych.

Aby uzyskać więcej informacji, zobacz Configure Application Insights for your ASP.NET website (Konfigurowanie usługi Application Insights dla witryny internetowej ASP.NET).

ASP.NET Core 3.1 nie jest już obsługiwana przez firmę Microsoft.

Zestaw SDK usługi Application Insights dla ASP.NET Core w wersji 2.8.0 i Visual Studio 2019 lub nowszej może być używany z aplikacjami ASP.NET Core 3.1.

Uzyskaj wystąpienie TelemetryClient przy użyciu iniekcji konstruktora i wywołaj na nim wymaganą metodę TrackXXX(). Nie zalecamy tworzenia nowych TelemetryClient lub TelemetryConfiguration wystąpień w aplikacji ASP.NET Core. Singleton TelemetryClient jest już zarejestrowany w kontenerze DependencyInjection, który współdzieli TelemetryConfiguration z resztą telemetrii. Utwórz nowe TelemetryClient wystąpienie tylko wtedy, gdy potrzebuje konfiguracji, która jest oddzielona od pozostałej części telemetrii.

W poniższym przykładzie pokazano, jak śledzić więcej danych telemetrycznych z kontrolera.

using Microsoft.ApplicationInsights;

public class HomeController : Controller
{
    private TelemetryClient telemetry;

    // Use constructor injection to get a TelemetryClient instance.
    public HomeController(TelemetryClient telemetry)
    {
       this.telemetry = telemetry;
    }

    public IActionResult Index()
    {
        // Call the required TrackXXX method.
        this.telemetry.TrackEvent("HomePageRequested");
        return View();
    }
}

Aby uzyskać więcej informacji na temat raportowania danych niestandardowych w usłudze Application Insights, zobacz Dokumentacja interfejsu API metryk niestandardowych usługi Application Insights. Podobne podejście może służyć do wysyłania metryk niestandardowych do usługi Application Insights przy użyciu interfejsu API GetMetric.

ASP.NET Core ma wbudowaną obsługę rejestrowania informacji żądania/odpowiedzi HTTP (w tym treści) za pośrednictwem polecenia ILogger. Zaleca się korzystanie z tego. Może to potencjalnie narazić na ujawnienie danych osobowych (PII) w telemetrii i spowodować znaczący wzrost kosztów (kosztów wydajności oraz rozliczeń w usłudze Application Insights), dlatego dokładnie oszacuj ryzyko przed skorzystaniem z tej funkcji.

Ustawieniem domyślnym usługi Application Insights jest przechwytywanie tylko ostrzeżeń i poważniejszych dzienników.

Przechwyć informacje i logi o mniejszym znaczeniu, zmieniając konfigurację rejestrowania dostawcy Application Insights w następujący sposób.

{
    "Logging": {
        "LogLevel": {
            "Default": "Information"
        },
        "ApplicationInsights": {
            "LogLevel": {
                "Default": "Information"
            }
        }
    },
    "ApplicationInsights": {
        "ConnectionString": "InstrumentationKey=00000000-0000-0000-0000-000000000000"
    }
}

Należy pamiętać, że poniższy przykład nie powoduje przechwycenia Information dzienników przez dostawcę usługi Application Insights. Nie przechwytuje go, ponieważ zestaw SDK dodaje domyślny filtr rejestrowania, który nakazuje ApplicationInsights przechwycenie tylko Warning dzienników i poważniejszych dzienników. Usługa Application Insights wymaga jawnego zastąpienia.

{
    "Logging": {
       "LogLevel": {
           "Default": "Information"
       }
    }
}

Aby uzyskać więcej informacji, zobacz ILogger configuration (Konfiguracja ILogger).

Metoda rozszerzenia UseApplicationInsights() jest nadal obsługiwana, ale w wersji 2.8.0 i nowszych zestawu SDK usługi Application Insights jest oznaczona jako przestarzała. Zostanie on usunięty w następnej wersji głównej zestawu SDK. Aby włączyć telemetrię usługi Application Insights, użyj funkcji AddApplicationInsightsTelemetry() , ponieważ zapewnia przeciążenia do kontrolowania niektórych konfiguracji. Ponadto w aplikacjach ASP.NET Core 3.X services.AddApplicationInsightsTelemetry() jest jedynym sposobem włączenia Application Insights.

Jeśli zestaw SDK jest zainstalowany w czasie kompilacji, jak pokazano w tym artykule, nie musisz włączać rozszerzenia usługi Application Insights z portalu usługi App Service. Jeśli rozszerzenie jest zainstalowane, cofa się po wykryciu, że zestaw SDK został już dodany. Jeśli włączysz usługę Application Insights z rozszerzenia, nie musisz instalować i aktualizować zestawu SDK. Jeśli jednak włączysz usługę Application Insights, postępując zgodnie z instrukcjami w tym artykule, masz większą elastyczność, ponieważ:

• Dane telemetryczne usługi Application Insights nadal działają w:
  • Wszystkie systemy operacyjne, w tym Windows, Linux i Mac.
  • Wszystkie tryby publikowania, w tym autonomiczne lub zależne od środowiska.
  • Wszystkie platformy docelowe, w tym pełna platforma .NET Framework.
  • Wszystkie opcje hostingu, w tym aplikacje internetowe, maszyny wirtualne, linux, kontenery, usługa AKS i hosting spoza platformy Azure.
  • Wszystkie wersje platformy .NET Core, w tym wersje zapoznawcza.
• Dane telemetryczne są widoczne lokalnie podczas debugowania z poziomu programu Visual Studio.
• Możesz śledzić więcej niestandardowych danych telemetrycznych, korzystając z interfejsu API TrackXXX().
• Masz pełną kontrolę nad konfiguracją.

Tak. W programie Application Insights Agent 2.0.0-beta1 lub nowszym obsługiwane są aplikacje ASP.NET Core hostowane w usługach IIS.

Tak. Obsługa funkcji dla zestawu SDK jest taka sama na wszystkich platformach z następującymi wyjątkami:

• Zestaw SDK zbiera liczniki zdarzeń w systemie Linux, ponieważ liczniki wydajności są obsługiwane tylko w systemie Windows. Większość metryk jest taka sama.

Nie. Zamiast tego użyj Application Insights dla aplikacji Worker Service (aplikacji nieopartych na HTTP) w przypadku usług worker.

Aby usunąć usługę Application Insights, należy usunąć pakiety NuGet i odwołania z interfejsu API w aplikacji. Pakiety NuGet można odinstalować przy użyciu Menedżer pakietów NuGet w programie Visual Studio.

Uwaga / Notatka

Te instrukcje dotyczą odinstalowywania zestawu ASP.NET Core SDK. Jeśli musisz odinstalować zestaw SDK ASP.NET, zobacz Jak mogę odinstalować zestaw SDK ASP.NET?.

1. Odinstaluj pakiet Microsoft.ApplicationInsights.AspNetCore przy użyciu Menedżer pakietów NuGet.
2. Aby w pełni usunąć usługę Application Insights, sprawdź i ręcznie usuń dodany kod lub pliki wraz z wszystkimi wywołaniami interfejsu API dodanymi w projekcie. Aby uzyskać więcej informacji, zobacz Co zostało utworzone podczas dodawania zestawu SDK usługi Application Insights?.

Po dodaniu usługi Application Insights do projektu program tworzy pliki i dodaje kod do niektórych plików. Wyłącznie odinstalowywanie pakietów NuGet nie zawsze odrzuca pliki i kod. Aby w pełni usunąć usługę Application Insights, należy sprawdzić i ręcznie usunąć dodany kod lub pliki wraz z wszystkimi wywołaniami interfejsu API dodanymi w projekcie.

Po dodaniu telemetrii usługi Application Insights do projektu szablonu programu Visual Studio ASP.NET Core dodaje on następujący kod:

• [Nazwa projektu].csproj

  <PropertyGroup>
       <TargetFramework>netcoreapp3.1</TargetFramework>
       <ApplicationInsightsResourceId>/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourcegroups/Default-ApplicationInsights-EastUS/providers/microsoft.insights/components/WebApplication4core</ApplicationInsightsResourceId>
  </PropertyGroup>
  
  <ItemGroup>
       <PackageReference Include="Microsoft.ApplicationInsights.AspNetCore" Version="2.12.0" />
  </ItemGroup>
  
  <ItemGroup>
       <WCFMetadata Include="Connected Services" />
  </ItemGroup>
  

• Appsettings.json

  "ApplicationInsights": {
       "ConnectionString": "InstrumentationKey=00000000-0000-0000-0000-000000000000"
  }
  

• ConnectedService.json

  {    
       "ProviderId": "Microsoft.ApplicationInsights.ConnectedService.ConnectedServiceProvider",
       "Version": "16.0.0.0",
       "GettingStartedDocument": {
           "Uri": "https://go.microsoft.com/fwlink/?LinkID=798432"
       }
  }
  

• Startup.cs

  public void ConfigureServices(IServiceCollection services)
       {
          services.AddRazorPages();
          services.AddApplicationInsightsTelemetry(); // This is added
       }
  

Aby wyłączyć korelację telemetrii w kodzie, zobacz <ExcludeComponentCorrelationHttpHeadersOnDomains> w temacie Application Insights for console applications (Usługa Application Insights dla aplikacji konsolowych).

Aby uzyskać więcej informacji, zobacz Application Insights for ASP.NET Core.

• Exception rate: Współczynnik wyjątków jest licznikiem wydajności systemu. CLR zlicza wszystkie obsługiwane i nieobsługiwane wyjątki, które są zgłaszane, i dzieli sumę w ramach interwału próbkowania przez długość tego interwału. Zestaw SDK usługi Application Insights zbiera ten wynik i wysyła go do portalu.
• Exceptions: Metryka Wyjątki zlicza TrackException raporty odebrane przez portal w interwale próbkowania wykresu. Uwzględnia tylko te obsługiwane wyjątki, dla których piszesz wywołania TrackException w kodzie. Nie obejmuje wszystkich nieobsługiwanych wyjątków.

Aby uzyskać więcej informacji, zobacz Liczniki dla platformy .NET w usłudze Application Insights.

Metryki na żywo nie pokazują EventCounters. Użyj Eksploratora metryk lub analizy, aby wyświetlić dane telemetryczne.

Rozszerzenie usługi Application Insights dla platformy ASP.NET Core nie obsługuje jeszcze tej funkcji.

Aby uzyskać więcej informacji, zobacz Liczniki dla platformy .NET w usłudze Application Insights.

Monitorowanie po stronie klienta jest domyślnie włączone dla aplikacji ASP.NET Core. Jeśli chcesz go wyłączyć, zdefiniuj zmienną środowiskową na serwerze przy użyciu następujących informacji:

• Nazwa:APPINSIGHTS_JAVASCRIPT_ENABLED
• Wartość:false

Aby uzyskać więcej informacji, zobacz Application Insights for Azure VMs and virtual machine scale sets (Usługa Application Insights dla maszyn wirtualnych platformy Azure i zestawy skalowania maszyn wirtualnych).

Nieudane wywołania zależności mają pole success ustawione na False. Moduł DependencyTrackingTelemetryModule nie zgłasza ExceptionTelemetry. Pełny model danych dla zależności został opisany w artykule Model danych telemetrycznych usługi Application Insights.

Użyj tego kodu:

dependencies
| extend E2EIngestionLatency = ingestion_time() - timestamp 
| extend TimeIngested = ingestion_time()

W widoku zapytania usługi Log Analytics, timestamp reprezentuje moment zainicjowania wywołania TrackDependency(), który następuje natychmiast po otrzymaniu odpowiedzi na wywołanie zależności. Aby obliczyć czas rozpoczęcia wywołania zależności, należy wziąć timestamp i odjąć zarejestrowaną wartość duration dotyczącą wywołania zależności.

Śledzenie zależności w usłudze Application Insights nie obejmuje rejestrowania treści odpowiedzi, ponieważ generowałoby to zbyt dużo danych telemetrycznych dla większości aplikacji.

Aby uzyskać więcej informacji, zobacz Śledzenie zależności.

Testy dostępności są uruchamiane w punktach obecności rozmieszczonych na całym świecie. Istnieją dwa rozwiązania:

• Drzwi zapory: zezwalaj na żądania do serwera z długiej i możliwej do zmiany listy agentów testujących sieć.
• Kod niestandardowy: napisz własny kod, aby wysyłać okresowe żądania do serwera z wewnątrz intranetu. W tym celu można uruchomić testy internetowe programu Visual Studio. Tester może wysłać wyniki do usługi Application Insights przy użyciu interfejsu TrackAvailability() API.

Ciąg agenta użytkownika to Mozilla/5.0 (kompatybilny; MSIE 9.0; Windows NT 6.1; Trident/5.0; AppInsights)

Aby uzyskać więcej informacji, zobacz Testy dostępności.

Testy dostępności działają jako klient rozproszony w każdej z obsługiwanych lokalizacji testów sieci Web. Za każdym razem, gdy test internetowy jest wykonywany, usługa testu dostępności próbuje skontaktować się z zdalnym punktem końcowym zdefiniowanym w konfiguracji testu internetowego. Zostanie wysłana wiadomość Hello klienta TLS zawierająca całą obecnie obsługiwaną konfigurację protokołu TLS. Jeśli zdalny punkt końcowy współużytkuje wspólną konfigurację protokołu TLS z klientem testowym dostępności, uzgadnianie protokołu TLS powiedzie się. W przeciwnym razie test internetowy kończy się niepowodzeniem z powodu błędu uzgadniania TLS.

Dostępnych jest kilka narzędzi do testowania konfiguracji protokołu TLS obsługiwanej przez punkt końcowy. Jednym ze sposobów jest wykonanie przykładu opisanego na tej stronie. Jeśli zdalny punkt końcowy nie jest dostępny za pośrednictwem Publicznego Internetu, należy sprawdzić poprawność konfiguracji protokołu TLS obsługiwanej w zdalnym punkcie końcowym z komputera, który ma dostęp do wywołania punktu końcowego.

Uwaga / Notatka

Aby wykonać kroki umożliwiające włączenie wymaganej konfiguracji protokołu TLS na serwerze internetowym, najlepiej skontaktować się z zespołem, który jest właścicielem platformy hostingu, na którą działa serwer internetowy, jeśli proces nie jest znany.

Nie ma jednego rodzaju wyjątku, który dotyczyłby wszystkich błędów uzgadniania TLS w wyniku wycofania. Jednak najczęstszym wyjątkiem, przez który Twój test internetowy zacznie się niepowodzeniem, będzie The request was aborted: Couldn't create SSL/TLS secure channel. W kroku diagnozowania problemów z transportem TLS powinny być widoczne wszystkie błędy związane z protokołem TLS w wyniku testu sieci Web, który może być nimi potencjalnie dotknięty.

Nie można wyświetlić konfiguracji protokołu TLS wynegocjowanej podczas wykonywania testu internetowego. Jeśli zdalny punkt końcowy obsługuje wspólną konfigurację protokołu TLS z testami dostępności, nie powinno być widoczne żadne skutki po zakończeniu obsługi.

Wycofanie protokołu TLS opisane w tym dokumencie powinno mieć wpływ tylko na zachowanie testu dostępności testów sieci Web po 1 maja 2025 r. Aby uzyskać więcej informacji na temat interakcji z usługą testową dostępności dla operacji CRUD, zobacz Obsługa protokołu TLS w usłudze Azure Resource Manager. Ten zasób zawiera więcej szczegółów dotyczących obsługi protokołu TLS i harmonogramów wycofywania.

Aby uzyskać ogólne informacje na temat problemu z przestarzałym TLS, zobacz Rozwiązywanie problemów TLS.

Aby uzyskać więcej informacji, zobacz Obsługiwane konfiguracje protokołu TLS.

Szczegóły zależą od typu projektu. Poniższa lista jest przykładem aplikacji internetowej.

• Dodaje pliki do projektu:

  • ApplicationInsights.config
  • ai.js

• Instaluje pakiety NuGet:

  • Podstawowe API usługi Application Insights
  • Interfejs API usługi Application Insights dla aplikacji internetowych: służy do wysyłania danych telemetrycznych z serwera
  • Interfejs API usługi Application Insights dla aplikacji JavaScript: służy do wysyłania danych telemetrycznych z klienta

• Obejmuje zestawy w pakietach:

  • Microsoft.ApplicationInsights
  • Microsoft.ApplicationInsights.Platform

• Wstawia elementy do:

  • Web.config
  • packages.config

• Wstawia fragmenty kodu klienta i serwera, aby zainicjować je za pomocą identyfikatora zasobu usługi Application Insights. Na przykład w aplikacji MVC kod jest wstawiany do strony głównej Views/Shared/_Layout.cshtml. Tylko w przypadku nowych projektów dodasz usługę Application Insights do istniejącego projektu ręcznie.

Usługa Application Insights zbiera dane telemetryczne dla żądań wysyłanych do aplikacji. Jeśli błąd wystąpi w usłudze WebApps/WebServer, a żądanie nie dotarło do aplikacji użytkownika, usługa Application Insights nie ma żadnych danych telemetrycznych.

Czas trwania obliczany serverresponsetime przez usługę Application Insights nie musi być zgodny z czasem odpowiedzi serwera obserwowanym przez usługę Web Apps. To zachowanie jest spowodowane tym, że usługa Application Insights liczy czas trwania tylko wtedy, gdy żądanie rzeczywiście dociera do aplikacji użytkownika. Jeśli żądanie jest zablokowane lub umieszczone w kolejce na serwerze WebServer, czas oczekiwania jest uwzględniany w metrykach usługi Web Apps, ale nie w metrykach usługi Application Insights.

Aby uzyskać więcej informacji, zobacz Włączanie monitorowania aplikacji w usłudze Azure App Service.

Postępujemy zgodnie z przewodnikiem stylu firmy Microsoft w celu zapewnienia spójności dokumentacji produktu publikowanej na platformie Microsoft Learn.

Ogólnie rzecz biorąc, nie dołączamy łącznika po prefiksie "auto".

Aby uzyskać więcej informacji, zobacz Co to jest autoinstrumentacja dla usługi Azure Monitor Application Insights?.

Jeśli chcesz, aby metryki niestandardowe w Node.js, instrumentować aplikacje ręcznie za pomocą dystrybucji usługi Azure Monitor OpenTelemetry.

Język Java umożliwia korzystanie z metryk niestandardowych za pomocą autoinstrumentacji. Metryki niestandardowe można zbierać, aktualizując kod i włączając tę funkcję. Jeśli kod ma już metryki niestandardowe, przepływają po włączeniu automatycznej instrumentacji.

Automatyczna instrumentacja usługi AKS może zakłócić telemetrię wysyłaną do stron trzecich przez open-source'owy zestaw SDK OpenTelemetry.

Autoinstrumentacja usługi AKS jest przeznaczona do współistnienia z opcjami instrumentacji ręcznej: klasycznym zestawem SDK interfejsu API usługi Application Insights i dystrybucją OpenTelemetry.

Zawsze zapobiega duplikacji danych i zapewnia poprawne funkcjonowanie metryk niestandardowych.

Zapoznaj się z tym wykresem, aby określić, kiedy pierwszeństwo ma autoinstrumentacja lub instrumentacja ręczna.

Język	Pierwszeństwo
Node.js	Instrumentacja ręczna
Jawa	Autoinstrumentacja

Luki w zabezpieczeniach wykryte w dystrybucji OpenTelemetry usługi Azure Monitor są priorytetyzowane, naprawiane i wydawane w następnej wersji.

Automatyczna instrumentacja AKS wprowadza najnowszą wersję dystrybucji OpenTelemetry Azure Monitor do zasobników aplikacji za każdym razem, gdy wdrożenie zostanie zmienione lub ponownie uruchomione.

Dystrybucja OpenTelemetry może stać się podatna dla deploymentów, które nie są zmieniane ani ponownie uruchamiane przez dłuższy czas. Z tego powodu zalecamy cotygodniowe aktualizowanie lub ponowne uruchamianie wdrożeń w celu zapewnienia, że jest używana najnowsza wersja dystrybucji.

Ta funkcja umożliwia automatyczną instrumentację przez wstrzyknięcie Azure Monitor OpenTelemetry Distro do podów aplikacji.

W przypadku języka Java ta funkcja integruje samodzielną dystrybucję Azure Monitor OpenTelemetry dla języka Java. Zapoznaj się z naszą dokumentacją dystrybucji Java, aby dowiedzieć się więcej na temat binarium instrumentacji Java.

W przypadku Node.js wprowadzamy plik binarny automatycznej instrumentacji oparty na naszej dystrybucji OpenTelemetry usługi Azure Monitor dla Node.js. Aby uzyskać więcej informacji, zobacz dokumentację dotyczącąNode.js dystrybucji. Należy pamiętać, że nie mamy autonomicznej autoinstrumentacji dla Node.js więc nasza dokumentacja dystrybucji jest skierowana do instrumentacji ręcznej. Możesz zignorować kroki konfiguracji oparte na kodzie związane z instrumentacją ręczną. Jednak wszystkie inne elementy w naszej dokumentacji dystrybucji, takie jak ustawienia domyślne, konfiguracje zmiennych środowiskowych itp., mają zastosowanie do tej funkcji.

Aby uzyskać więcej informacji, zobacz Autoinstrumentation for AKS (Autoinstrumentacja dla usługi AKS).

Nowe regiony platformy Azure wymagają użycia ciągów połączenia zamiast kluczy instrumentacji. Parametry połączenia identyfikują zasób, który chcesz skojarzyć z danymi telemetrycznymi. Pozwala także na modyfikację punktów końcowych, które Twój zasób wykorzystuje jako miejsce docelowe dla telemetrii. Skopiuj parametry połączenia i dodaj ją do kodu aplikacji lub zmiennej środowiskowej.

Zalecamy używanie ciągów połączenia zamiast kluczy instrumentacji.

Należy ręcznie ustawić APPLICATIONINSIGHTS_CONNECTION_STRING we wszystkich scenariuszach, w których system nie udostępnia go automatycznie. Te scenariusze obejmują, ale nie są ograniczone do: programowania lokalnego i funkcji izolowanych platformy .NET przy użyciu integracji z platformą ASP.NET Core. W takich przypadkach zmienna środowiskowa gwarantuje, że potok OpenTelemetry może wysyłać dane telemetryczne do usługi Application Insights. Aby uzyskać więcej informacji na temat konfigurowania parametrów połączenia za pomocą zmiennej środowiskowej, zobacz Configuring OpenTelemetry in Application Insights (Konfigurowanie funkcji OpenTelemetry w usłudze Application Insights).

Aby spełnić wymagania dotyczące zgodności danych regionalnych, użyj regionalnych punktów końcowych usługi Application Insights zamiast globalnego punktu końcowego. Globalny punkt końcowy nie gwarantuje, że dane pozostają w określonym regionie. Regionalne punkty końcowe pomagają zapewnić, że dane telemetryczne od użytkowników w obszarach regulowanych są wysyłane tylko do centrów danych w tych regionach.

Aby skonfigurować globalną aplikację internetową pod kątem zgodności regionalnej:

• Utwórz jeden zasób usługi Application Insights na region z rygorystycznymi wymaganiami dotyczącymi zgodności, takimi jak Unia Europejska lub Stany Zjednoczone.
• Utwórz kolejny zasób usługi Application Insights dla użytkowników we wszystkich innych regionach.
• Skonfiguruj aplikację, aby wysyłała dane telemetryczne do odpowiedniego zasobu usługi Application Insights na podstawie regionu każdego użytkownika. Określ region przy użyciu sygnałów, takich jak adres IP, metadane konta lub ustawienia lokalizacji.
• Połącz wszystkie zasoby usługi Application Insights z obszarem roboczym usługi Log Analytics, jeśli potrzebujesz ujednoliconego środowiska zapytań w różnych regionach.

Przykład:

• Wysyłanie danych od użytkowników z Regionu A do zasobu Regionu A usługi Application Insights używając ciągu połączenia Regionu A.
• Wyślij dane użytkowników Regionu B do zasobu Application Insights w Regionie B, korzystając z ciągu połączenia Regionu B.
• Wyślij wszystkie inne dane użytkownika do zasobu usługi Application Insights ogólnego przeznaczenia przy użyciu różnych parametrów połączenia.

Ważne

Użycie globalnego punktu końcowego nie zapewnia zgodności regionalnej. Aby spełnić wymagania dotyczące rezydencji danych, należy zawsze używać punktów końcowych specyficznych dla regionu i kierować dane telemetryczne na podstawie regionu użytkownika.

Na poniższym diagramie przedstawiono przykładową konfigurację globalnej aplikacji internetowej:

Aby uzyskać więcej informacji, zobacz Parametry połączenia.

Przenoszenie istniejących zasobów usługi Application Insights między regionami nie jest obsługiwane i nie można migrować danych historycznych do nowego regionu. Obejście obejmuje:

• Tworzenie nowego zasobu usługi Application Insights w żądanym regionie.
• Utwórz ponownie wszystkie unikatowe dostosowania z oryginalnego zasobu w nowym.
• Aktualizowanie aplikacji przy użyciu parametrów połączenia nowego zasobu regionu.
• Testowanie w celu upewnienia się, że wszystko działa zgodnie z oczekiwaniami przy użyciu nowego zasobu usługi Application Insights.
• Zdecyduj się zachować lub usunąć oryginalny zasób usługi Application Insights. Usunięcie zasobu klasycznego oznacza utratę wszystkich danych historycznych. Jeśli zasób jest oparty na obszarze roboczym, dane pozostają w usłudze Log Analytics, umożliwiając dostęp do danych historycznych do momentu wygaśnięcia okresu przechowywania.

Unikatowe dostosowania, które często wymagają ręcznego ponownego utworzenia lub zaktualizowania zasobu w nowym regionie, ale nie są ograniczone do następujących elementów:

• Utwórz ponownie niestandardowe pulpity nawigacyjne i skoroszyty.
• Utwórz ponownie lub zaktualizuj zakres dowolnych alertów dzienników niestandardowych/metryk.
• Utwórz ponownie alerty dostępności.
• Utwórz ponownie dowolne niestandardowe ustawienia kontroli dostępu opartej na rolach platformy Azure, które są wymagane dla użytkowników w celu uzyskania dostępu do nowego zasobu.
• Replikuj ustawienia obejmujące próbkowanie pozyskiwania, przechowywanie danych, dzienny limit i włączanie metryk niestandardowych. Te ustawienia są kontrolowane za pośrednictwem okienka Użycie i szacowane koszty .
• Każda integracja, która opiera się na kluczach interfejsu API, takich jak adnotacje wydania i bezpieczny kanał kontroli metryk na żywo. Musisz wygenerować nowe klucze interfejsu API i zaktualizować skojarzą integrację.
• Eksport ciągły w zasobach klasycznych musi zostać ponownie skonfigurowany.
• Należy ponownie skonfigurować ustawienia diagnostyczne w zasobach opartych na obszarze roboczym.

Nie zalecamy używania tej metody wypełniania wersji interfejsu API. Najnowsza wersja może reprezentować wersje zapoznawcza, które mogą zawierać zmiany powodujące niezgodność. Nawet w nowszych, stabilnych wersjach interfejsu API, nie zawsze są one zgodne wstecznie z istniejącymi szablonami. W niektórych przypadkach wersja interfejsu API może nie być dostępna dla wszystkich subskrypcji.

Aby uzyskać więcej informacji, zobacz Tworzenie i konfigurowanie zasobów usługi Application Insights.

Aby zgłosić problemy i sugestie dotyczące modelu danych lub schematu, skorzystaj z naszego repozytorium GitHub.

Telemetria PageView zawiera adres URL i można przeanalizować parametr UTM przy użyciu funkcji regex w usłudze Kusto.

Czasami te dane mogą być brakujące lub niedokładne, jeśli użytkownik lub przedsiębiorstwo wyłączy wysyłanie agenta użytkownika w ustawieniach przeglądarki. Wyrażenia regularne UA Parsera mogą nie zawierać wszystkich informacji o urządzeniu. Usługa Application Insights może nie przyjąć najnowszych aktualizacji.

Taka sytuacja może wystąpić, jeśli używasz wartości ciągu. Tylko wartości liczbowe działają z pomiarami niestandardowymi.

Aby uzyskać więcej informacji, zobacz Model danych telemetrycznych usługi Application Insights.

ApplicationInsightsLoggerProvider przechwytuje ILogger dzienniki i tworzy TraceTelemetry je na ich podstawie. Exception Jeśli obiekt zostanie przekazany do metody w metodzie w Logmetodzie ILogger , ExceptionTelemetry zostanie utworzony zamiast TraceTelemetry.

Wyświetlanie telemetrii ILogger

W witrynie Azure Portal:

1. Przejdź do witryny Azure Portal i uzyskaj dostęp do zasobu usługi Application Insights.
2. Wybierz sekcję Dzienniki w usłudze Application Insights.
3. Użyj język zapytań Kusto (KQL), aby wysyłać zapytania dotyczące komunikatów ILogger przechowywanych w traces tabeli. Przykładowe zapytanie: traces | where message contains "YourSearchTerm".
4. Uściślij zapytania, aby filtrować dane ILogger według ważności, zakresu czasu lub określonej zawartości wiadomości.

W programie Visual Studio (debuger lokalny):

1. Uruchom aplikację w trybie debugowania w programie Visual Studio.
2. Otwórz okno Narzędzia diagnostyczne , gdy aplikacja jest uruchomiona.
3. Na karcie Zdarzenia dzienniki ILogger są wyświetlane wraz z innymi danymi telemetrycznymi.
4. Aby zlokalizować określone komunikaty ILogger, użyj funkcji wyszukiwania i filtrowania w oknie Narzędzia diagnostyczne .

Jeśli wolisz zawsze wysyłać TraceTelemetry, użyj tego fragmentu kodu:

builder.AddApplicationInsights(
    options => options.TrackExceptionsAsExceptionTelemetry = false);

Usługa Application Insights przechwytuje i wysyła ILogger dzienniki przy użyciu tych samych TelemetryConfiguration informacji, które są używane dla każdej innego telemetrii. Ale jest wyjątek. Domyślnie TelemetryConfiguration nie jest w pełni konfigurowana podczas logowania z Program.cs lub Startup.cs. Dzienniki z tych miejsc nie mają konfiguracji domyślnej, więc nie są uruchomione wszystkie TelemetryInitializer wystąpienia i TelemetryProcessor wystąpienia.

W przypadku korzystania z pakietu TelemetryClient autonomicznego nie jest wstrzykiwany do kontenera wstrzykiwania zależności (DI). Musisz utworzyć nowe wystąpienie i TelemetryClient użyć tej samej konfiguracji, której używa dostawca rejestratora, jak pokazano w poniższym kodzie. To wymaganie gwarantuje, że ta sama konfiguracja jest używana dla wszystkich niestandardowych danych telemetrycznych i telemetrii z programu ILogger.

public class MyController : ApiController
{
   // This TelemetryClient instance can be used to track additional telemetry through the TrackXXX() API.
   private readonly TelemetryClient _telemetryClient;
   private readonly ILogger _logger;

   public MyController(IOptions<TelemetryConfiguration> options, ILogger<MyController> logger)
   {
        _telemetryClient = new TelemetryClient(options.Value);
        _logger = logger;
   }  
}

Uwaga / Notatka

Jeśli używasz pakietu do włączenia Microsoft.ApplicationInsights.AspNetCore usługi Application Insights, zmodyfikuj ten kod, aby uzyskać TelemetryClient bezpośredni dostęp do konstruktora.

Rozszerzenie Application Insights w usłudze Azure Web Apps używa nowego dostawcy. Reguły filtrowania można zmodyfikować w pliku appsettings.json dla aplikacji.

Aby uzyskać więcej informacji, zobacz Rejestrowanie usługi Application Insights za pomocą platformy .NET.

Narzędzie Java Profiler używa narzędzia Java Flight Recorder (JFR) do profilowania aplikacji przy użyciu dostosowanej konfiguracji.

Java Flight Recorder (JFR) to narzędzie do zbierania danych profilowania uruchomionej aplikacji Java. JFR jest zintegrowany z maszyną wirtualną Java (JVM) i służy do rozwiązywania problemów z wydajnością. Dowiedz się więcej o środowisku uruchomieniowym Java SE JFR.

Profilowanie w języku Java to bezpłatna funkcja z usługą Application Insights. Cennik usługi Azure Monitor Application Insights jest oparty na kosztach pozyskiwania.

Dane profilowania zebrane przez JFR obejmują: dane profilowania metod i wykonania, dane dotyczące oczyszczania pamięci i profile blokad.

Nagrywanie JFR można wyświetlać i analizować za pomocą preferowanego narzędzia, na przykład Java Mission Control (JMC).

"Diagnostyka wydajności i zalecenia" to nowa funkcja, która wkrótce będzie dostępna jako Diagnostyka Java usługi Application Insights. Możesz zarejestrować się w celu wyświetlenia wersji zapoznawczej tej funkcji. Nagrywanie JFR można wyświetlić za pomocą narzędzia Java Mission Control (JMC).

Profilowanie na żądanie jest wyzwalane przez użytkownika w czasie rzeczywistym, podczas gdy automatyczne profilowanie jest ze wstępnie skonfigurowanymi wyzwalaczami.

Użyj Profiluj Teraz dla opcji profilowania na żądanie. Profil Teraz natychmiast profiluje wszystkich agentów przydzielonych do wystąpienia Application Insights.

Profilowanie automatyczne jest wyzwalane przez osiągnięcie progu zasobu.

Agent java usługi Application Insights obsługuje obecnie monitorowanie użycia procesora CPU i pamięci. Próg procesora CPU jest konfigurowany jako procent wszystkich dostępnych rdzeni na maszynie. Pamięć odnosi się do bieżącego zajęcia regionu pamięci stałej (OldGen) w stosunku do maksymalnego możliwego rozmiaru tego regionu.

Zapoznaj się z wymaganiami wstępnymi.

Tak, możesz profilować maszynę wirtualną JVM z uruchomionymi mikrousługami przy użyciu JFR.

Aby uzyskać więcej informacji, zobacz Azure Monitor Application Insights Profiler for Java.Aby uzyskać więcej informacji, zobacz Azure Monitor Application Insights Profiler for Java.

Nie, przesłonięcia próbkowania są teraz ogólnie dostępne (GA) i mogą być używane zarówno z autoinstrumentacją, jak i instrumentacją ręczną.

Jeśli używasz autoinstrumentacji, zaktualizuj plik applicationinsights.json w portalu Azure.

W przypadku autoinstrumentacji nie jest wymagane ręczne przesyłanie agenta. Jednak w przypadku instrumentacji ręcznej nadal trzeba uwzględnić plik JAR agenta usługi Application Insights i pliki konfiguracji w pakiecie wdrożeniowym.

Programowanie lokalne odnosi się do środowiska, w którym aplikacja jest kompilowana lub testowana, na przykład maszyna dewelopera lub wystąpienie usługi Azure Cloud Shell. Serwer aplikacji odnosi się do serwera internetowego z uruchomioną aplikacją, takiego jak Tomcat 11 w środowisku usługi Azure App Service. W przypadku korzystania z instrumentacji ręcznej należy upewnić się, że plik JAR agenta jest poprawnie umieszczony na serwerze aplikacji.

W przypadku autoinstrumentacji można skonfigurować przesłonięcia próbkowania za pośrednictwem witryny Azure Portal. W przypadku korzystania z instrumentacji ręcznej należy umieścić plik JAR agenta usługi Application Insights w odpowiednim katalogu i dołączyć plik applicationinsights.json z żądanymi ustawieniami próbkowania.

Aby uzyskać więcej informacji, zobacz Próbkowanie przesłonięć — Azure Monitor Application Insights dla języka Java.

TelemetryClient.trackTrace() jest częścią klasycznego mostka zestawu SDK usługi Application Insights, a procesory dzienników współpracują tylko z nową instrumentacją opartą na protokole OpenTelemetry.

Aby uzyskać więcej informacji, zobacz Procesory telemetryczne (wersja zapoznawcza) — Azure Monitor Application Insights dla języka Java.

• Zestaw SDK języka JavaScript ustawia plik cookie użytkownika na kliencie internetowym, aby zidentyfikować zwracanych użytkowników i plik cookie sesji w celu grupowania działań.
• Jeśli nie ma skryptu po stronie klienta, możesz ustawić pliki cookie na serwerze.
• Jeśli jeden rzeczywisty użytkownik korzysta z witryny w różnych przeglądarkach lub korzysta z przeglądania w trybie prywatnym/incognito lub różnych maszyn, są one liczone więcej niż raz.
• Aby zidentyfikować zalogowanego użytkownika na maszynach i przeglądarkach, dodaj wywołanie polecenia setAuthenticatedUserContext().

Zestaw SDK JavaScript Application Insights ma minimalne obciążenie na twojej stronie internetowej. Przy rozmiarze zaledwie 36 KB po kompresji gzip i czasie inicjalizacji wynoszącym tylko około 15 ms, zestaw SDK dodaje zaledwie nieznaczny czas ładowania do Twojej witryny. Minimalne składniki biblioteki są szybko ładowane podczas korzystania z zestawu SDK, a pełny skrypt jest pobierany w tle.

Ponadto podczas pobierania skryptu z sieci CDN wszystkie operacje śledzenia strony są kolejkowane, dzięki czemu nie utracisz żadnych danych telemetrii w całym cyklu życia strony. Ten proces konfiguracji udostępnia stronie bezproblemowy system analityczny niewidoczny dla użytkowników.

Najnowsza wersja przeglądarki ✔ Chrome	Najnowsza wersja ✔ przeglądarki Firefox	wersja 3.x: IE 9+ i Microsoft Edge ✔ Wersja 2.x: Zgodne z Internet Explorer 8+ i Microsoft Edge ✔	Opera Najnowsza ✔	Najnowsza wersja ✔ przeglądarki Safari

Aby zobaczyć przykłady do uruchomienia, zobacz Przykłady zestawu SDK usługi Application Insights dla języka JavaScript.

Musimy podjąć niezbędne środki, aby upewnić się, że ten zestaw SDK nadal działa i nie przerywa wykonywania języka JavaScript podczas ładowania przez starszą przeglądarkę. Byłoby idealnym rozwiązaniem, aby nie obsługiwać starszych przeglądarek, ale wielu dużych klientów nie może kontrolować, której przeglądarki użytkownicy zdecydują się używać.

Ta instrukcja nie oznacza, że obsługujemy tylko najniższy wspólny zestaw funkcji. Musimy zachować zgodność kodu ES3. Nowe funkcje należy dodać w sposób, który nie przerywa analizowania i dodawania kodu JavaScript w wersji ES3 jako funkcji opcjonalnej.

Aby uzyskać szczegółowe informacje na temat obsługi programu Internet Explorer 8, zobacz GitHub.

Tak, zestaw SDK języka JavaScript usługi Application Insights jest oprogramowaniem open source. Aby wyświetlić kod źródłowy lub współtworzyć projekt, zobacz oficjalne repozytorium GitHub.

Aby uzyskać więcej informacji, zobacz Włączanie monitorowania rzeczywistego użytkownika usługi Application Insights w usłudze Azure Monitor.

Po stronie serwera musi być możliwe akceptowanie połączeń z tymi nagłówkami. W zależności od Access-Control-Allow-Headers konfiguracji po stronie serwera często konieczne jest rozszerzenie listy po stronie serwera przez ręczne dodanie Request-Id, Request-Context i traceparent (nagłówek rozproszony W3C).

Access-Control-Allow-Headers: Request-Id, traceparent, Request-Context<your header>

Śledzenie rozproszone można wyłączyć w konfiguracji.

Nie. Błędy "Zła brama 502" i "Usługa 503 niedostępne" nie zawsze są przechwytywane przez usługę Application Insights. Jeśli do monitorowania jest używany tylko język JavaScript po stronie klienta, takie zachowanie byłoby oczekiwane, ponieważ odpowiedź o błędzie jest zwracana przed wyrenderowaniem strony zawierającej nagłówek HTML z fragmentem kodu JavaScript do monitorowania.

Jeśli odpowiedź 502 lub 503 została wysłana z serwera z włączonym monitorowaniem po stronie serwera, błędy są zbierane przez zestaw SDK usługi Application Insights.

Nawet jeśli monitorowanie po stronie serwera jest włączone na serwerze internetowym aplikacji, czasami błąd 502 lub 503 nie jest przechwytywany przez usługę Application Insights. Wiele nowoczesnych serwerów internetowych nie zezwala klientowi na bezpośrednią komunikację. Zamiast tego stosują rozwiązania, takie jak serwery proxy typu reverse, w celu przekazywania informacji między klientem a serwerami front-end.

W tym scenariuszu odpowiedź 502 lub 503 może zostać zwrócona do klienta z powodu problemu w odwrotnej warstwie serwera proxy, więc nie jest przechwytywana poza ramką przez usługę Application Insights. Aby ułatwić wykrywanie problemów w tej warstwie, może być konieczne przekazanie dzienników z zwrotnego serwera proxy do usługi Log Analytics i utworzenie reguły niestandardowej w celu sprawdzenia odpowiedzi 502 lub 503. Aby dowiedzieć się więcej o typowych przyczynach błędów 502 i 503, zobacz Rozwiązywanie problemów z błędami HTTP "502 Bad Gateway" i "503 Service Unavailable" w Azure App Service.

Aby uzyskać więcej informacji, zobacz Konfiguracja zestawu JAVAScript SDK usługi Application Insights.

Przeglądarka przekazuje ciąg identyfikacyjny agenta użytkownika w nagłówku HTTP żądania. Usługa przesyłania danych usługi Application Insights używa UA Parser do generowania pól, które widzisz w tabelach danych i środowiskach użytkownika. W związku z tym użytkownicy usługi Application Insights nie mogą zmienić tych pól.

Czasami te dane mogą być brakujące lub niedokładne, jeśli użytkownik lub przedsiębiorstwo wyłączy wysyłanie agenta użytkownika w ustawieniach przeglądarki. Wyrażenia regularne UA Parsera mogą nie zawierać wszystkich informacji o urządzeniu. Usługa Application Insights może nie przyjąć najnowszych aktualizacji.

Aby uzyskać więcej informacji, zobacz Włączanie rozszerzenia platformy dla zestawu SDK języka JavaScript usługi Application Insights.

Nie. Szablony ARM oraz wywołania API nadal działają. Podczas próby utworzenia zasobu klasycznego zamiast tego zostanie utworzony zasób oparty na obszarze roboczym z zarządzanym obszarem roboczym.

Nie. Powiadomienie dotyczące migracji poszczególnych zasobów nie jest dostępne. Aby kontrolować, kiedy i jak są migrowane zasoby, użyj migracji ręcznej.

Poszczególne migracje są zwykle ukończone w mniej niż dwie minuty. Pełne wdrożenie odbywa się w ciągu kilku tygodni we wszystkich regionach.

Po migracji zasób łączy się z obszarem roboczym usługi Log Analytics na stronie Przegląd. Klasyczna informacja o przejściu na emeryturę została usunięta, a skoroszyt emerytur nie zawiera już tego zasobu.

Koszty zwykle pozostają podobne. Usługa Application Insights oparta na obszarze roboczym umożliwia oszczędzanie kosztów i zalecamy przejrzenie planów cenowych.

Jeśli korzystasz ze starszego modelu rozliczeń, zapoznaj się z dokumentacją cennika , aby uzyskać szczegółowe informacje.

Nie. Wszystkie alerty, pulpity nawigacyjne i testy dostępności pozostają nienaruszone i nadal działają po migracji.

Aby uzyskać więcej informacji, zobacz Zarządzane obszary robocze w usłudze Application Insights.

Aby wyłączyć korelację telemetrii, użyj właściwości correlationHeaderExcludedDomains w konfiguracji. Aby uzyskać więcej informacji, zobacz ApplicationInsights-node.js.

Aby skonfigurować żądany poziom dziennika używany przez usługę Application Insights, użyj zmiennej środowiskowej APPLICATIONINSIGHTS_INSTRUMENTATION_LOGGING_LEVEL . Obsługiwane wartości to NONE, ERROR, WARN, INFO, DEBUG, VERBOSE i ALL. Aby uzyskać więcej informacji, zobacz ApplicationInsights-node.js.

Aby uzyskać więcej informacji, zobacz Monitorowanie usług i aplikacji Node.js za pomocą usługi Application Insights.

Lista wersji i nazw zestawu SDK jest hostowana w usłudze GitHub. Aby uzyskać więcej informacji, zobacz Wersja zestawu SDK.

Aby uzyskać więcej informacji, zobacz Zbieranie danych telemetrycznych za pomocą technologii OpenTelemetry w usłudze Application Insights.

OpenTelemetry to neutralny względem dostawców system obserwacji. W zestawie SDK OpenTelemetry ani w jego bibliotekach nie ma interfejsów API usługi Application Insights. Przed migracją ważne jest zrozumienie niektórych pojęć związanych z platformą OpenTelemetry.

• W usłudze Application Insights wszystkie dane telemetryczne były zarządzane za pomocą jednego TelemetryClient i TelemetryConfiguration. W usłudze OpenTelemetry każdy z trzech sygnałów telemetrii (ślady, metryki i dzienniki) ma własną konfigurację. Dane telemetryczne można tworzyć ręcznie za pośrednictwem środowiska uruchomieniowego platformy .NET bez bibliotek zewnętrznych. Aby uzyskać więcej informacji, zobacz przewodniki platformy .NET dotyczące śledzenia rozproszonego, metryk i rejestrowania.

• Usługa Application Insights używana TelemetryModules do automatycznego zbierania danych telemetrycznych dla aplikacji. Zamiast tego funkcja OpenTelemetry używa bibliotek instrumentacji do zbierania danych telemetrycznych z określonych składników (takich jak AspNetCore dla żądań i httpClient dla zależności).

• Usługa Application Insights służy TelemetryInitializers do wzbogacania danych telemetrycznych dodatkowymi informacjami lub zastępowania właściwości. Za pomocą funkcji OpenTelemetry można napisać procesor w celu dostosowania określonego sygnału. Ponadto wiele bibliotek instrumentacji OpenTelemetry oferuje metodę Enrich dostosowywania telemetrii wygenerowanej przez ten konkretny składnik.

• Application Insights używa TelemetryProcessors do filtrowania telemetrii. Procesor OpenTelemetry może również służyć do stosowania reguł filtrowania na określonym sygnałie.

Ta tabela mapuje typy danych usługi Application Insights na pojęcia OpenTelemetry i ich implementacje platformy .NET.

Tabela usługi Azure Monitor	Typ danych usługi Application Insights	Typ danych OpenTelemetry	Implementacja platformy .NET
customEvents	EventTelemetry	N/A	N/A
customMetrics	MetrykaTelemetria	Wskaźniki	System.Diagnostics.Metrics.Meter
zależności	Telemetria zależności	Zakresy (Klient, Wewnętrzny, Konsument)	System.Diagnostics.Activity
Wyjątki	WyjątekTelemetria	Wyjątki	System.Exception
żądania	Telemetria Żądania	Zakresy (serwer, producent)	System.Diagnostics.Activity
ślady	TraceTelemetry	Dzienniki	Microsoft.Extensions.Logging.ILogger
ślady	TraceTelemetry	Rozpiętość zdarzeń	System.Diagnostics.ActivityEvent

Poniższe dokumenty zawierają więcej informacji.

• Podstawy zbierania danych usługi Azure Monitor Application Insights
• Model danych telemetrii usługi Application Insights
• Pojęcia dotyczące architektury OpenTelemetry

Chociaż usługa Application Insights oferuje wiele opcji konfigurowania próbkowania, eksporter usługi Azure Monitor lub dystrybucja usługi Azure Monitor oferuje tylko próbkowanie o stałej szybkości. Można próbkować tylko żądania i zależności (ślady OpenTelemetry).

Aby uzyskać przykłady kodu zawierające szczegółowe informacje na temat konfigurowania próbkowania, zobacz nasz przewodnik Włączanie próbkowania

W zestawie SDK platformy .NET usługi Application Insights użyj procesorów telemetrycznych, aby filtrować i modyfikować lub odrzucać dane telemetryczne. Użyj inicjatorów telemetrii, aby dodać lub zmodyfikować właściwości niestandardowe. Aby uzyskać więcej informacji, zobacz dokumentację usługi Azure Monitor. Funkcja OpenTelemetry zastępuje te pojęcia procesorami aktywności lub dzienników, które wzbogacają i filtrują dane telemetryczne.

Filtrowanie śladów

Aby filtrować dane telemetryczne w usłudze OpenTelemetry, można zaimplementować procesor działań. Ten przykład jest odpowiednikiem przykładu usługi Application Insights na potrzeby filtrowania danych telemetrycznych zgodnie z opisem w dokumentacji usługi Azure Monitor. W przykładzie pokazano, gdzie są filtrowane nieudane wywołania zależności.

using System.Diagnostics;
using OpenTelemetry;

internal sealed class SuccessfulDependencyFilterProcessor : BaseProcessor<Activity>
{
    public override void OnEnd(Activity activity)
    {
        if (!OKtoSend(activity))
        {
            activity.ActivityTraceFlags &= ~ActivityTraceFlags.Recorded;
        }
    }

    private bool OKtoSend(Activity activity)
    {
       return activity.Kind == ActivityKind.Client && activity.Status == ActivityStatusCode.Ok;
    }
}

Aby użyć tego procesora, należy utworzyć TracerProvider i dodać procesor przed AddAzureMonitorTraceExporter.

using OpenTelemetry.Trace;

public static void Main()
{
   var tracerProvider = Sdk.CreateTracerProviderBuilder()
       .AddProcessor(new SuccessfulDependencyFilterProcessor())
       .AddAzureMonitorTraceExporter()
       .Build();
}

Filtrowanie dzienników

ILogger implementacje mają wbudowany mechanizm stosowania filtrowania dzienników. Dzięki temu filtrowaniu można kontrolować dzienniki wysyłane do każdego zarejestrowanego dostawcy, w tym OpenTelemetryLoggerProvider. "OpenTelemetry" to alias dla OpenTelemetryLoggerProvider, używany do konfigurowania reguł filtrowania.

W poniższym przykładzie "Błąd" jest zdefiniowany jako domyślny LogLevel, a "Ostrzeżenie" jako minimum LogLevel dla kategorii zdefiniowanej przez użytkownika. Te reguły zgodnie z definicją dotyczą tylko elementu OpenTelemetryLoggerProvider.

builder.AddFilter<OpenTelemetryLoggerProvider>("*", LogLevel.Error);
builder.AddFilter<OpenTelemetryLoggerProvider>("MyProduct.MyLibrary.MyClass", LogLevel.Warning);

Aby uzyskać więcej informacji, przeczytaj dokumentację OpenTelemetry dla platformy .NET dotyczącą dzienników.

Dodawanie właściwości niestandardowych do śladów

W usłudze OpenTelemetry można użyć procesorów działań, aby wzbogacić dane telemetryczne o więcej właściwości. Jest on podobny do używania inicjatorów telemetrii w usłudze Application Insights, gdzie można modyfikować właściwości telemetrii.

Domyślnie eksporter Azure Monitor oznacza każde żądanie HTTP z kodem odpowiedzi 400 lub większym jako niepowodzenie. Jeśli jednak chcesz traktować wartość 400 jako sukces, możesz dodać wzbogacający procesor działań, który ustawia powodzenie działania i dodaje tag w celu uwzględnienia większej liczby właściwości telemetrii. Podobnie jak dodawanie lub modyfikowanie właściwości za pomocą inicjatora w usłudze Application Insights zgodnie z opisem w dokumentacji usługi Azure Monitor.

Oto przykład dodawania właściwości niestandardowych i zastępowania domyślnego zachowania niektórych kodów odpowiedzi:

using System.Diagnostics;
using OpenTelemetry;

/// <summary>
/// Custom Processor that overrides the default behavior of treating response codes >= 400 as failed requests.
/// </summary>
internal class MyEnrichingProcessor : BaseProcessor<Activity>
{
    public override void OnEnd(Activity activity)
    {
        if (activity.Kind == ActivityKind.Server)
        {
            int responseCode = GetResponseCode(activity);

            if (responseCode >= 400 && responseCode < 500)
            {
               // If we set the Success property, the SDK won't change it
               activity.SetStatus(ActivityStatusCode.Ok);

               // Allow to filter these requests in the portal
              activity.SetTag("Overridden400s", "true");
            }

            // else leave the SDK to set the Success property
        }
    }

    private int GetResponseCode(Activity activity)
    {
       foreach (ref readonly var tag in activity.EnumerateTagObjects())
       {    
          if (tag.Key == "http.response.status_code" && tag.Value is int value)
          {
           return value;
          }
       }

       return 0;
    }
}

Aby użyć tego procesora, należy utworzyć TracerProvider i dodać procesor przed AddAzureMonitorTraceExporter.

using OpenTelemetry.Trace;

public static void Main()
{
   var tracerProvider = Sdk.CreateTracerProviderBuilder()
       .AddSource("Company.Product.Name")
       .AddProcessor(new MyEnrichingProcessor())
       .AddAzureMonitorTraceExporter()
       .Build();
}

Wysyłanie śladów — ręczne

Ślady w usłudze Application Insights są przechowywane jako RequestTelemetry i DependencyTelemetry. W usłudze OpenTelemetry ślady są modelowane jako Span przy użyciu Activity klasy .

Platforma .NET OpenTelemetry wykorzystuje klasy ActivitySource i Activity do śledzenia, które są częścią środowiska uruchomieniowego platformy .NET. Takie podejście jest charakterystyczne, ponieważ implementacja platformy .NET integruje interfejs API śledzenia bezpośrednio z samym środowiskiem uruchomieniowym. Pakiet System.Diagnostics.DiagnosticSource umożliwia deweloperom użycie ActivitySource do tworzenia i zarządzania wystąpieniami Activity. Ta metoda zapewnia bezproblemowy sposób dodawania śledzenia do aplikacji platformy .NET bez polegania na bibliotekach zewnętrznych, stosując wbudowane możliwości ekosystemu platformy .NET. Aby uzyskać bardziej szczegółowe informacje, zapoznaj się z instrukcjami instrumentacji śledzenia rozproszonego.

Tak można przeprowadzić migrację śledzenia ręcznego:

Uwaga / Notatka

W usłudze Application Insights można ustawić nazwę roli i wystąpienie roli na poziomie telemetrii. Jednak w przypadku eksportera usługi Azure Monitor nie możemy dostosować się na poziomie telemetrii. Nazwa roli i wystąpienie roli są wyodrębniane z zasobu OpenTelemetry i stosowane w danych telemetrycznych. Przeczytaj ten dokument, aby uzyskać więcej informacji: Ustawianie nazwy roli chmury i wystąpienia roli w chmurze.

Telemetria zależności

Usługa Application Insights DependencyTelemetry służy do modelowania żądań wychodzących. Oto jak konwertować na OpenTelemetry.

Przykład usługi Application Insights:

DependencyTelemetry dep = new DependencyTelemetry
{
   Name = "DependencyName",
   Data = "https://www.example.com/",
   Type = "Http",
   Target = "www.example.com",
   Duration = TimeSpan.FromSeconds(10),
   ResultCode = "500",
   Success = false
};

dep.Context.Cloud.RoleName = "MyRole";
dep.Context.Cloud.RoleInstance = "MyRoleInstance";
dep.Properties["customprop1"] = "custom value1";
client.TrackDependency(dep);

Przykład openTelemetry:

var activitySource = new ActivitySource("Company.Product.Name");
var resourceAttributes = new Dictionary<string, object>
{
   { "service.name", "MyRole" },
   { "service.instance.id", "MyRoleInstance" }
};

var resourceBuilder = ResourceBuilder.CreateDefault().AddAttributes(resourceAttributes);

using var tracerProvider = Sdk.CreateTracerProviderBuilder()
  .SetResourceBuilder(resourceBuilder)
  .AddSource(activitySource.Name)
  .AddAzureMonitorTraceExporter()
  .Build();

// Emit traces
using (var activity = activitySource.StartActivity("DependencyName", ActivityKind.Client))
{
  activity?.SetTag("url.full", "https://www.example.com/");
  activity?.SetTag("server.address", "www.example.com");
  activity?.SetTag("http.request.method", "GET");
  activity?.SetTag("http.response.status_code", "500");
  activity?.SetTag("customprop1", "custom value1");
  activity?.SetStatus(ActivityStatusCode.Error);
  activity?.SetEndTime(activity.StartTimeUtc.AddSeconds(10));
}

Telemetria Żądania

Usługa Application Insights RequestTelemetry modeluje żądania przychodzące. Oto jak przeprowadzić migrację do OpenTelemetry:

Przykład usługi Application Insights:

RequestTelemetry req = new RequestTelemetry
{
   Name = "RequestName",
   Url = new Uri("http://example.com"),
   Duration = TimeSpan.FromSeconds(10),
   ResponseCode = "200",
   Success = true,
   Properties = { ["customprop1"] = "custom value1" }
};

req.Context.Cloud.RoleName = "MyRole";
req.Context.Cloud.RoleInstance = "MyRoleInstance";
client.TrackRequest(req);

Przykład openTelemetry:

var activitySource = new ActivitySource("Company.Product.Name");
var resourceAttributes = new Dictionary<string, object>
{
   { "service.name", "MyRole" },
   { "service.instance.id", "MyRoleInstance" }
};

var resourceBuilder = ResourceBuilder.CreateDefault().AddAttributes(resourceAttributes);

using var tracerProvider = Sdk.CreateTracerProviderBuilder()
  .SetResourceBuilder(resourceBuilder)
  .AddSource(activitySource.Name)
  .AddAzureMonitorTraceExporter()
  .Build();

// Emit traces
using (var activity = activitySource.StartActivity("RequestName", ActivityKind.Server))
{
  activity?.SetTag("url.scheme", "https");
  activity?.SetTag("server.address", "www.example.com");
  activity?.SetTag("url.path", "/");
  activity?.SetTag("http.response.status_code", "200");
  activity?.SetTag("customprop1", "custom value1");
  activity?.SetStatus(ActivityStatusCode.Ok);
}

Niestandardowe śledzenie operacji

W usłudze Application Insights śledź operacje niestandardowe przy użyciu metod StartOperation i StopOperation Osiągnij to, używając ActivitySource oraz Activity w OpenTelemetry .NET. W przypadku operacji z ActivityKind.Server i ActivityKind.Consumer, eksporter usługi Azure Monitor generuje RequestTelemetry. Dla ActivityKind.Client, ActivityKind.Producer i ActivityKind.Internal generuje DependencyTelemetry. Aby uzyskać więcej informacji na temat śledzenia operacji niestandardowych, zobacz dokumentację usługi Azure Monitor. Aby uzyskać więcej informacji na temat korzystania z ActivitySource i Activity w .NET, zobacz przewodniki po implementacji śledzenia rozproszonego w .NET.

Oto przykład uruchamiania i zatrzymywania działania dla operacji niestandardowych:

using System.Diagnostics;
using OpenTelemetry;

var activitySource = new ActivitySource("Company.Product.Name");

using var tracerProvider = Sdk.CreateTracerProviderBuilder()
    .AddSource(activitySource.Name)
    .AddAzureMonitorTraceExporter()
    .Build();

// Start a new activity
using (var activity = activitySource.StartActivity("CustomOperation", ActivityKind.Server))
{
    activity?.SetTag("customTag", "customValue");

    // Perform your custom operation logic here

    // No need to explicitly call Activity.Stop() because the using block automatically disposes the Activity object, which stops it.
}

Wysyłanie dzienników

Dzienniki w usłudze Application Insights są przechowywane jako TraceTelemetry i ExceptionTelemetry.

TraceTelemetry

W programie OpenTelemetry rejestrowanie jest zintegrowane za pośrednictwem interfejsu ILogger . Oto jak przeprowadzić migrację TraceTelemetry:

Przykład usługi Application Insights:

TraceTelemetry traceTelemetry = new TraceTelemetry 
{
   Message = "hello from tomato 2.99",
   SeverityLevel = SeverityLevel.Warning,
};

traceTelemetry.Context.Cloud.RoleName = "MyRole";
traceTelemetry.Context.Cloud.RoleInstance = "MyRoleInstance";
client.TrackTrace(traceTelemetry);

Przykład openTelemetry:

var resourceAttributes = new Dictionary<string, object>
{
   { "service.name", "MyRole" },
   { "service.instance.id", "MyRoleInstance" }
};

var resourceBuilder = ResourceBuilder.CreateDefault().AddAttributes(resourceAttributes);

using var loggerFactory = LoggerFactory.Create(builder => builder
   .AddOpenTelemetry(logging =>
   {
       logging.SetResourceBuilder(resourceBuilder);
       logging.AddAzureMonitorLogExporter();
   }));

// Create a new instance `ILogger` from the above LoggerFactory
var logger = loggerFactory.CreateLogger<Program>();

// Emit log: This uses the logger instance to write a new log
logger.FoodPrice("tomato", 2.99);

internal static partial class LoggerExtensions
{
   [LoggerMessage(LogLevel.Warning, "Hello from `{name}` `{price}`.")]
   public static partial void FoodPrice(this ILogger logger, string name, double price);
}

WyjątekTelemetria

Usługa Application Insights używa ExceptionTelemetry do rejestrowania wyjątków. Oto jak przeprowadzić migrację do OpenTelemetry:

Przykład usługi Application Insights:

ExceptionTelemetry exceptionTelemetry = new ExceptionTelemetry(new Exception("Test exception"))
{
    SeverityLevel = SeverityLevel.Error
};

exceptionTelemetry.Context.Cloud.RoleName = "MyRole";
exceptionTelemetry.Context.Cloud.RoleInstance = "MyRoleInstance";
exceptionTelemetry.Properties["customprop1"] = "custom value1";
client.TrackException(exceptionTelemetry);

Przykład openTelemetry:

var resourceAttributes = new Dictionary<string, object> 
{
   { "service.name", "MyRole" },
   { "service.instance.id", "MyRoleInstance" }
};

var resourceBuilder = ResourceBuilder.CreateDefault().AddAttributes(resourceAttributes);

using var loggerFactory = LoggerFactory.Create(builder => builder
   .AddOpenTelemetry(logging =>
   {
       logging.SetResourceBuilder(resourceBuilder);
       logging.AddAzureMonitorLogExporter();
   }));

// Create a new instance `ILogger` from the above LoggerFactory.
var logger = loggerFactory.CreateLogger<Program>();

try
{
    // Simulate exception
    throw new Exception("Test exception");
}
catch (Exception ex)
{
   // Emit exception: This uses the logger instance to write a new exception
   logger?.LogError(ex, "An error occurred");
}

Wysyłanie metryk

Metryki w usłudze Application Insights są przechowywane jako MetricTelemetry. W OpenTelemetry metryki są modelowane jako Meter z pakietu System.Diagnostics.DiagnosticSource.

Usługa Application Insights ma zarówno niewstępne (TrackMetric()), jak i wstępnie agregujące (GetMetric().TrackValue()) interfejsy API metryk. W przeciwieństwie do OpenTelemetry, usługa Application Insights nie ma pojęcia o instrumentach. Usługa Application Insights ma ten sam interfejs API dla wszystkich scenariuszy metryk.

Z drugiej strony funkcja OpenTelemetry wymaga od użytkowników uprzedniego wybrania odpowiedniego instrumentu metryki na podstawie rzeczywistej semantyki metryki. Jeśli na przykład intencją jest zliczenie czegoś (na przykład liczba odebranych żądań serwera itp.), należy użyć licznika OpenTelemetry. Jeśli intencją jest obliczenie różnych percentyli (takich jak wartość P99 opóźnienia serwera), należy użyć instrumentu Histogramu OpenTelemetry. Ze względu na tę podstawową różnicę między usługą Application Insights i usługą OpenTelemetry nie dokonano bezpośredniego porównania między nimi.

W przeciwieństwie do usługi Application Insights funkcja OpenTelemetry nie udostępnia wbudowanych mechanizmów wzbogacania ani filtrowania metryk. W usłudze Application Insights procesory telemetryczne i inicjatory mogą służyć do modyfikowania lub odrzucania metryk, ale ta funkcja nie jest dostępna w usłudze OpenTelemetry.

Ponadto OpenTelemetry nie obsługuje bezpośredniego wysyłania nieprzetworzonych metryk, ponieważ nie ma odpowiednika funkcjonalności dostępnej w usłudze Application Insights.

Migracja z usługi Application Insights do OpenTelemetry obejmuje zastąpienie wszystkich użyć interfejsu API metryk usługi Application Insights interfejsem API OpenTelemetry. Wymaga to zrozumienia różnych instrumentów OpenTelemetry i ich semantyki.

Wskazówka

Histogram jest najbardziej wszechstronny i najbliższy odpowiednik interfejsu API usługi Application Insights GetMetric().TrackValue(). Możesz zastąpić metryki API Application Insights histogramem, aby osiągnąć ten sam cel.

Inne typy telemetrii

WydarzeniaNiestandardowe

Nieobsługiwane w usłudze OpenTelemetry.

Przykład usługi Application Insights:

TelemetryClient.TrackEvent()

Telemetria dostępności

Nieobsługiwane w usłudze OpenTelemetry.

Przykład usługi Application Insights:

TelemetryClient.TrackAvailability()

PageViewTelemetry

Nieobsługiwane w usłudze OpenTelemetry.

Przykład usługi Application Insights:

TelemetryClient.TrackPageView()

Zalecamy Azure Monitor OpenTelemetry Exporter dla aplikacji konsolowych i aplikacji usług roboczych, które nie zawierają metryk na żywo.

Aby uzyskać więcej informacji, zobacz Migrowanie z zestawów SDK usługi .NET Application Insights do usługi Azure Monitor OpenTelemetry.

Niestandardowy selektor usługi Application Insights podejmuje decyzje dotyczące próbkowania po utworzeniu przedziału, a nie wcześniej, więc nie jest zgodne z tradycyjnym podejściem opartym na początku śladu. Zamiast tego stosuje decyzje dotyczące próbkowania na końcu generowania przedziału — po zakończeniu przedziału, ale przed eksportem.

Mimo że to zachowanie w pewien sposób przypomina próbkowanie końcówkowe, próbnik nie czeka na zebranie wielu odcinków z tej samej ścieżki przed podjęciem decyzji. Zamiast tego używa skrótu identyfikatora śledzenia, aby zapewnić kompletność śledzenia.

Takie podejście równoważy kompletność i wydajność śledzenia oraz pozwala uniknąć wyższych kosztów związanych z pełnym próbkowaniem opartym na ogonie.

Aby podejmować decyzje dotyczące próbkowania na podstawie wyniku całego śledzenia (na przykład określenia, czy jakikolwiek zakres w ramach śledzenia zakończył się niepowodzeniem), w agencie podrzędnym lub module zbierającym wymagane jest pełne próbkowanie oparte na ogonie. Ta funkcja nie jest obecnie obsługiwana, ale możesz zażądać jej jako nowej funkcji za pośrednictwem Centrum opinii.

Metoda próbkowania	Punkt decyzji	Mocne strony	Słabości
Oparte na głowie	Przed rozpoczęciem sekcji	Małe opóźnienia, minimalne obciążenie	Może próbować wybrać pożądane ślady, w tym błędy
Oparty na ogonie	Po zbuforowaniu przedziałów na podstawie progów czasu lub wolumenu	Umożliwia wysoce selektywne kryteria próbkowania śledzenia	Wyższy koszt i dodatkowe opóźnienie przetwarzania
Przykład niestandardowy usługi App Insights	Koniec generowania zakresu	Równoważy kompletność śledzenia z wydajnością	Wymagane dla zgodności metryk na żywo i klasycznego interfejsu API

Nie, próbkator stosuje stałą częstotliwość we wszystkich typach telemetrii w śladzie. Żądania, zależności i inne zakresy są zgodne z tą samą wartością procentową próbkowania. Aby zastosować różne stawki na typ telemetrii, rozważ użycie procesorów typu OpenTelemetry span lub (przekształcenia czasu pozyskiwania)[opentelemetry-overview.md#telemetry-routing].

Niestandardowy selektor usługi Application Insights domyślnie propaguje decyzje o próbkowaniu przy użyciu standardu W3C Trace Context. Ten standard umożliwia podejmowanie decyzji dotyczących próbkowania między usługami. Jednak ponieważ sampler podejmuje decyzje dotyczące próbkowania na końcu generowania segmentu — po wywołaniu usług podrzędnych — propagacja przekazuje niepełne informacje dotyczące próbkowania. To ograniczenie jest zgodne ze specyfikacją kontekstu śledzenia W3C, ale usługi podrzędne nie mogą niezawodnie używać tej propagowanej decyzji próbkowania.

Nie, niestandardowy przykładnik usługi Application Insights zawsze podejmuje niezależną decyzję o próbkowaniu, nawet jeśli usługa nadrzędna używa tego samego algorytmu próbkowania. Decyzje dotyczące próbkowania z usług nadrzędnych, w tym tych korzystających z nagłówków kontekstu śledzenia W3C, nie mają wpływu na decyzję usługi podrzędnej. Jednak wykonuje próbkę na podstawie skrótu identyfikatora śledzenia, aby zapewnić kompletność śledzenia. Aby poprawić spójność i zmniejszyć prawdopodobieństwo uszkodzenia śladów, skonfiguruj wszystkie składniki w systemie tak, aby używały tego samego próbkatora i częstotliwości próbkowania.

Istnieje kilka powodów, dla których ślady mogą być niekompletne:

• Różne węzły w systemie rozproszonym używają różnych metod próbkowania, które nie koordynują decyzji. Na przykład jeden węzeł stosuje próbkowanie oparte na nagłówku OpenTelemetry, a inny węzeł stosuje próbkowanie przy użyciu Niestandardowego Próbnika Azure Monitor.
• Różne węzły są ustawione na różne współczynniki próbkowania, nawet jeśli oba używają tego samego podejścia do próbkowania.
• Ustawiasz filtrowanie, próbkowanie lub limity szybkości w potoku po stronie usługi, a ta konfiguracja pobiera losowe próbki odcinków bez uwzględniania pełności śladu.

Jeśli jeden składnik stosuje próbkowanie oparte na nagłówkach bez propagacji decyzji próbkowania (za pośrednictwem nagłówków kontekstu śledzenia W3C), usługi podrzędne próbkują ślad niezależnie, co może prowadzić do odrzucenia segmentów. W związku z tym niektóre części śladu nie zawsze są dostępne podczas przeglądania w usłudze Application Insights.

Aby uzyskać więcej informacji, zobacz Próbkowanie w usłudze Azure Monitor Application Insights z funkcją OpenTelemetry.

Jest to standard open source umożliwiający obserwowanie. Dowiedz się więcej na stronie OpenTelemetry.

Firma Microsoft inwestuje w platformę OpenTelemetry z następujących powodów:

• Jest neutralny dla dostawcy i zapewnia spójne interfejsy API/zestawy SDK w różnych językach.
• Z biegiem czasu uważamy, że platforma OpenTelemetry umożliwi klientom usługi Azure Monitor obserwowanie aplikacji napisanych w językach poza obsługiwanymi językami.
• Rozszerza typy danych, które można zbierać za pomocą bogatego zestawu bibliotek instrumentacji.
• Zestawy SDK (Software Development Kit) openTelemetry są zwykle bardziej wydajne na dużą skalę niż ich poprzednicy, zestawy SDK usługi Application Insights.
• OpenTelemetry jest zgodna ze strategią firmy Microsoft w celu przyjęcia rozwiązania open source.

Zobacz Stan openTelemetry.

Można to postrzegać jako cienką otokę, która łączy wszystkie składniki OpenTelemetry, zapewniając najwyższej klasy doświadczenie na platformie Azure. Ten wrapper jest również nazywany dystrybucją w usłudze OpenTelemetry.

Korzystanie z dystrybucji OpenTelemetry usługi Azure Monitor ma kilka zalet w porównaniu z natywnym OpenTelemetry rozwijanym przez społeczność.

• Zmniejsza nakład pracy przy włączaniu
• Obsługiwane przez firmę Microsoft
• Udostępnia funkcje specyficzne dla platformy Azure, takie jak:
  • Próbkowanie zgodne z klasycznymi zestawami SDK usługi Application Insights
  • Uwierzytelnianie Microsoft Entra
  • Przechowywanie offline i automatyczne ponawianie prób
  • Statystykabeat
  • Metryki standardowe usługi Application Insights
  • Wykrywanie metadanych zasobów w celu automatycznego wypełniania nazwy roli chmury i wystąpienia roli chmury w różnych środowiskach Azure.
  • Metryki na żywo

W duchu OpenTelemetry zaprojektowaliśmy dystrybucję tak, aby była otwarta i rozszerzalna. Możesz na przykład dodać następujące elementy:

• Eksportuj Protokołem OTLP (OpenTelemetry Protocol) i jednocześnie wysyłaj do drugiego miejsca docelowego.
• Inne biblioteki instrumentacji niewchodzące w dystrybucję

Ponieważ dystrybucja dostarcza platformę OpenTelemetry, obsługuje wszystko, co jest wspierane przez OpenTelemetry. Na przykład można dodać więcej procesorów telemetrycznych, eksporterów lub bibliotek instrumentacji, jeśli usługa OpenTelemetry je obsługuje.

Uwaga / Notatka

Dystrybucja ustawia próbkownik na niestandardowy próbkownik o stałym współczynniku dla usługi Application Insights. Można to zmienić na inny próbnik, ale może to spowodować wyłączenie niektórych dołączonych możliwości Distro (dystrybucji). Aby uzyskać więcej informacji na temat obsługiwanego próbnika, zobacz sekcję Włączanie próbkowania w Konfigurowaniu Azure Monitor OpenTelemetry.

W przypadku języków bez obsługiwanego autonomicznego eksportera OpenTelemetry usługa Azure Monitor OpenTelemetry Distro jest jedynym obecnie obsługiwanym sposobem korzystania z biblioteki OpenTelemetry w usłudze Azure Monitor. W przypadku języków z obsługiwanym autonomicznym eksporterem OpenTelemetry możesz użyć dystrybucji OpenTelemetry usługi Azure Monitor lub odpowiedniego autonomicznego eksportera OpenTelemetry w zależności od scenariusza telemetrii. Aby uzyskać więcej informacji, zobacz Kiedy należy używać eksportera OpenTelemetry usługi Azure Monitor?.

Zapoznaj się z naszymi dokumentami dotyczącymi włączania dla platform .NET, Java, JavaScript (Node.js) i języka Python.

Zalecamy użycie dystrybucji usługi Azure Monitor OpenTelemetry dla nowych projektów, gdy jej możliwości są zgodne z potrzebami monitorowania. OpenTelemetry to standardowa struktura, która zwiększa możliwość obserwacji międzyplatformowych i zapewnia ustandaryzowane podejście do zbierania danych telemetrycznych.

Jednak zestawy SDK usługi Application Insights nadal zapewniają pewne możliwości, które nie są jeszcze w pełni zautomatyzowane w usłudze OpenTelemetry, w tym:

• Automatyczne śledzenie zależności — funkcja OpenTelemetry obsługuje śledzenie zależności, ale niektóre zależności wymagają dodatkowej konfiguracji w porównaniu z automatycznym śledzeniem dostępnym w zestawach SDK usługi Application Insights.
• Niestandardowe typy telemetrii, takie jak AvailabilityTelemetry i PageViewTelemetry — Funkcja OpenTelemetry nie ma bezpośrednich odpowiedników. Podobne funkcje można zaimplementować za pomocą instrumentacji ręcznej.
• Procesory i inicjalizatory telemetrii — platforma OpenTelemetry ma procesory oraz procesory śladów, ale nie zastępują one w pełni procesorów telemetrii i inicjalizatorów w usłudze Application Insights we wszystkich scenariuszach.
• Zbieranie metryk rozszerzonych — chociaż usługa OpenTelemetry ma silny system metryk, niektóre wbudowane metryki z zestawów SDK usługi Application Insights wymagają ręcznej konfiguracji w usłudze OpenTelemetry.

OpenTelemetry zapewnia również zalety w porównaniu do pakietów SDK Application Insights, w tym:

• Lepsza standaryzacja na różnych platformach
• Szerszy ekosystem bibliotek instrumentacji
• Większa elastyczność zbierania i przetwarzania danych
• Ulepszona neutralność dostawcy, chociaż dystrybucja OpenTelemetry w usłudze Azure Monitor jest nadal zoptymalizowana pod kątem platformy Azure.

Integracja rozwiązania OpenTelemetry z usługą Azure Monitor stale się rozwija, a firma Microsoft nadal rozszerza swoje możliwości. Jeśli rozważasz przejście, dokładnie oceń, czy rozwiązanie OpenTelemetry spełnia obecnie wymagania dotyczące możliwości obserwowania, czy zestaw SDK usługi Application Insights pozostaje lepszy dla Twoich potrzeb.

W przypadku ASP.NET Core, Java, Node.js i Python zalecamy użycie dystrybucji OpenTelemetry usługi Azure Monitor. Jest to jeden wiersz kodu, aby rozpocząć pracę.

W przypadku wszystkich innych scenariuszy platformy .NET, w tym klasycznych ASP.NET, aplikacji konsolowych, formularzy systemu Windows (WinForms) itp., zalecamy użycie eksportera OpenTelemetry platformy .NET usługi Azure Monitor: Azure.Monitor.OpenTelemetry.Exporter.

W przypadku bardziej złożonych scenariuszy telemetrii języka Python wymagających zaawansowanej konfiguracji zalecamy użycie eksportera OpenTelemetry usługi Azure Monitor w języku Python.

Na poniższym wykresie przedstawiono obsługę funkcji OpenTelemetry dla każdego języka.

Funkcja	.SIEĆ	Node.js	Pyton	Jawa
Śledzenie rozproszone	✅	✅	✅	✅
Metryki niestandardowe	✅	✅	✅	✅
Metryki standardowe	✅	✅	✅	✅
Próbkowanie o stałej częstotliwości	✅	✅	✅	✅
Przechowywanie offline i automatyczne ponowne próby	✅	✅	✅	✅
Raportowanie wyjątków	✅	✅	✅	✅
Zbieranie dzienników	✅	⚠️	✅	✅
Zdarzenia niestandardowe	⚠️	⚠️	⚠️	✅
Uwierzytelnianie Microsoft Entra	✅	✅	✅	✅
Metryki na żywo	✅	✅	✅	✅
Filtrowanie metryk na żywo	✅	❌	❌	❌
Wykrywanie kontekstu zasobów dla maszyn wirtualnych/zestawu skalowania maszyn wirtualnych i usługi App Service	✅	❌	✅	✅
Wykrywanie kontekstu zasobów dla usługi Azure Kubernetes Service (AKS) i funkcji	❌	❌	❌	✅
Zdarzenia testowania dostępności generowane przy użyciu API śledzenia dostępności	❌	❌	❌	✅
Filtrowanie żądań, zależności, dzienników i wyjątków według anonimowego identyfikatora użytkownika i syntetycznego źródła	❌	❌	❌	✅
Filtrowanie zależności, dzienników i wyjątków według nazwy operacji	❌	❌	❌	✅
Próbkowanie adaptacyjne	❌	❌	❌	✅
Profiler platformy .NET	⚠️	❌	❌	⚠️
Debugger Snapshotów	❌	❌	❌	❌

Klucz

• ✅ Ta funkcja jest dostępna dla wszystkich klientów z formalnym wsparciem.
• ⚠✔ Ta funkcja jest dostępna jako publiczna wersja zapoznawcza. Zobacz Dodatkowe warunki użytkowania dla wersji zapoznawczych platformy Microsoft Azure.
• ❌ Ta funkcja jest niedostępna lub nie ma zastosowania.

Tak, ale nie zalecamy jej i platforma Azure nie obsługuje jej. Język JavaScript openTelemetry jest mocno zoptymalizowany pod kątem Node.js. Zamiast tego zalecamy używanie zestawu SDK języka JavaScript usługi Application Insights.

Internetowy zestaw SDK openTelemetry nie ma ustalonej osi czasu dostępności. Prawdopodobnie jesteśmy kilka lat od momentu, gdy zestaw SDK dla przeglądarek będzie realną alternatywą dla JavaScript SDK usługi Application Insights.

Piaskownica sieciowa OpenTelemetry to rozwidlenie stworzone, aby OpenTelemetry działało w przeglądarce. Nie można jeszcze wysyłać danych telemetrycznych do usługi Application Insights. Zestaw SDK nie definiuje ogólnych zdarzeń klienta.

Ta praktyka nie jest czymś, co planujemy przetestować ani obsługiwać, chociaż nasze dystrybucje umożliwiają jednoczesne eksportowanie do punktu końcowego OTLP wraz z usługą Azure Monitor.

Nie zalecamy tego. Zobacz Dodatkowe warunki użytkowania dla wersji zapoznawczych platformy Microsoft Azure.

Zobacz Omówienie usługi OpenTelemetry.

Niektórzy klienci używają modułu zbierającego OpenTelemetry jako alternatywy dla agenta, mimo że firma Microsoft oficjalnie nie obsługuje podejścia opartego na agencie do monitorowania aplikacji. W międzyczasie społeczność open source przyczyniła się do powstania eksportera OpenTelemetry Collector Azure Monitor, którego niektórzy klienci używają do wysyłania danych do usługi Azure Monitor Application Insights. Nie jest to obsługiwane przez firmę Microsoft.

OpenCensus jest prekursorem OpenTelemetry. Firma Microsoft pomogła połączyć rozwiązania OpenTracing i OpenCensus w celu utworzenia biblioteki OpenTelemetry— jednego standardu obserwacji dla świata. Bieżący zestaw SDK języka Python zalecany w środowisku produkcyjnym dla usługi Azure Monitor jest oparty na usłudze OpenCensus. Firma Microsoft zobowiązuje się do tworzenia usługi Azure Monitor na podstawie biblioteki OpenTelemetry.

Możesz spróbować zwizualizować nieprzetworzone dzienniki tekstowe, a nie ślady OpenTelemetry.

W usłudze Application Insights tabela "Traces" przechowuje nieprzetworzone dzienniki tekstowe do celów diagnostycznych. Pomagają one identyfikować i korelować ślady skojarzone z żądaniami użytkowników, innymi zdarzeniami i raportami wyjątków. Jednak tabela „Traces” nie przyczynia się bezpośrednio do całościowego przeglądu transakcji (zwanej również wykresem kaskadowym) w narzędziach wizualizacji, takich jak Grafana.

Wraz z rosnącym wdrożeniem rozwiązań natywnych dla chmury istnieje ewolucja kolekcji i terminologii telemetrii. OpenTelemetry stał się standardem zbierania i instrumentowania danych telemetrycznych. W tym kontekście termin "Traces" przyjął nowe znaczenie. Zamiast nieprzetworzonych dzienników funkcja "Traces" w usłudze OpenTelemetry odwołuje się do bogatszej, ustrukturyzowanej formy telemetrii obejmującej zakresy, które reprezentują poszczególne jednostki pracy. Te zakresy mają kluczowe znaczenie dla konstruowania szczegółowych widoków transakcji, co umożliwia lepsze monitorowanie i diagnostykę aplikacji natywnych dla chmury.

Aby instrumentować aplikację Blazor, najpierw zidentyfikuj model hostingu. Serwer Blazor obsługuje pełną instrumentację opartą na protokole OpenTelemetry. Zestaw WebAssembly platformy Blazor działa w przeglądarce i obsługuje ograniczoną instrumentację za pomocą języka JavaScript.

Aby uzyskać więcej informacji, zobacz OpenTelemetry Support and Feedback for Application Insights (Obsługa technologii OpenTelemetry i opinie dotyczące usługi Application Insights).

Nie, istnieje limit 30 dni danych wyświetlanych na pulpicie nawigacyjnym.

Błąd "Nie znaleziono zasobu" może wystąpić w przypadku przeniesienia lub zmiany nazwy wystąpienia usługi Application Insights.

Aby obejść to zachowanie, usuń domyślny pulpit nawigacyjny i ponownie wybierz pozycję Pulpit nawigacyjny aplikacji, aby ponownie utworzyć nowy.

Aby uzyskać więcej informacji, zobacz Pulpit nawigacyjny przeglądu usługi Application Insights.

Krótka odpowiedź polega na tym, że żaden z wbudowanych kanałów nie oferuje gwarancji typu transakcji dostarczania telemetrii do zaplecza. ServerTelemetryChannel jest bardziej zaawansowany w porównaniu z usługą InMemoryChannel w celu zapewnienia niezawodnego dostarczania, ale również sprawia, że tylko próba wysłania danych telemetrycznych jest najlepsza. Dane telemetryczne mogą być nadal tracone w kilku sytuacjach, w tym w następujących typowych scenariuszach:

• Elementy w pamięci zostaną utracone, gdy aplikacja ulegnie awarii.
• Dane telemetryczne są tracone w dłuższych okresach problemów z siecią. Dane telemetryczne są przechowywane na dysku lokalnym podczas awarii sieci lub w przypadku problemów z zapleczem usługi Application Insights. Jednak elementy starsze niż 48 godzin są odrzucane.
• Domyślne lokalizacje dysków do przechowywania danych telemetrycznych w systemie Windows to %LOCALAPPDATA% lub %TEMP%. Te lokalizacje są zwykle lokalne dla maszyny. Jeśli aplikacja migruje fizycznie z jednej lokalizacji do innej, wszelkie dane telemetryczne przechowywane w oryginalnej lokalizacji zostaną utracone.
• W usłudze Azure Web Apps w systemie Windows domyślna lokalizacja magazynu dysków to D:\local\LocalAppData. Ta lokalizacja nie jest utrwalone. Jest on wyczyszczony w przypadku ponownego uruchamiania aplikacji, skalowania w poziomie i innych takich operacji, co prowadzi do utraty przechowywanych tam danych telemetrycznych. Możesz zastąpić wartość domyślną i określić magazyn do utrwalonej lokalizacji, takiej jak D:\home. Jednak takie utrwalone lokalizacje są obsługiwane przez magazyn zdalny i dlatego mogą być powolne.

Chociaż mniej prawdopodobne, kanał może również spowodować zduplikowane elementy telemetrii. To zachowanie występuje, gdy ServerTelemetryChannel ponawianie prób z powodu awarii sieci lub przekroczenia limitu czasu, gdy telemetria została dostarczona do zaplecza, ale odpowiedź została utracona z powodu problemów z siecią lub wystąpiło przekroczenie limitu czasu.

Mimo że nazwa pakietu i przestrzeni nazw zawiera ciąg "WindowsServer", ten kanał jest obsługiwany w systemach innych niż Windows, z następującym wyjątkiem. W systemach innych niż Windows kanał domyślnie nie tworzy lokalnego folderu magazynu. Musisz utworzyć folder magazynu lokalnego i skonfigurować kanał, aby go używał. Po skonfigurowaniu magazynu lokalnego kanał działa tak samo jak we wszystkich systemach.

Uwaga / Notatka

W wersji 2.15.0-beta3 i nowszych magazyn lokalny jest teraz automatycznie tworzony dla systemów Linux, Mac i Windows. W przypadku systemów innych niż Windows zestaw SDK automatycznie utworzy lokalny folder magazynu na podstawie następującej logiki:

• ${TMPDIR}: Jeśli zmienna środowiskowa jest ustawiona ${TMPDIR} , ta lokalizacja jest używana.
• /var/tmp: Jeśli poprzednia lokalizacja nie istnieje, spróbujemy wykonać próbę /var/tmp.
• /tmp: Jeśli obie poprzednie lokalizacje nie istnieją, spróbujemy użyć polecenia tmp.
• Jeśli żadna z tych lokalizacji nie istnieje, magazyn lokalny nie zostanie utworzony, a konfiguracja ręczna będzie nadal wymagana. Aby uzyskać szczegółowe informacje o implementacji, zobacz to repozytorium GitHub.

Zestaw SDK przechowuje elementy telemetryczne w magazynie lokalnym podczas problemów z siecią lub podczas ograniczania przepustowości. Te dane nie są szyfrowane lokalnie.

W przypadku systemów Windows zestaw SDK automatycznie tworzy tymczasowy folder lokalny w katalogu %TEMP% lub %LOCALAPPDATA% i ogranicza dostęp tylko do administratorów i bieżącego użytkownika.

W przypadku systemów innych niż Windows żaden magazyn lokalny nie jest tworzony automatycznie przez zestaw SDK, więc żadne dane nie są przechowywane lokalnie.

Uwaga / Notatka

W wersji 2.15.0-beta3 i nowszych magazyn lokalny jest teraz automatycznie tworzony dla systemów Linux, Mac i Windows.

Możesz samodzielnie utworzyć katalog magazynu i skonfigurować go do użycia. W takim przypadku odpowiadasz za zapewnienie, że katalog jest zabezpieczony. Przeczytaj więcej na temat ochrony danych i prywatności.

Aby uzyskać więcej informacji, zobacz Kanały telemetryczne w usłudze Application Insights.

Zobacz podsumowanie limitów.

Nie rejestrujemy danych POST automatycznie, ale możesz użyć funkcji TrackTrace lub wywołań dziennika. Umieść dane POST w parametrze komunikatu. Nie można filtrować komunikatu w taki sam sposób, jak w przypadku właściwości, ale limit rozmiaru jest dłuższy.

Usługa Azure Functions nie rejestruje ciągów zapytań adresu URL.

Aby uzyskać więcej informacji, zobacz Wyszukiwanie transakcji i diagnostyka.

Potencjalne przyczyny:

• Czy inne składniki są instrumentowane za pomocą usługi Application Insights?
• Czy korzystają z najnowszego stabilnego zestawu SDK usługi Application Insights?
• Jeśli te składniki są oddzielnymi zasobami usługi Application Insights, sprawdź, czy masz dostęp. Jeśli masz dostęp i składniki są instrumentowane przy użyciu najnowszych zestawów SDK usługi Application Insights, daj nam znać za pośrednictwem kanału opinii w prawym górnym rogu.

Obecnie wyświetlane jest wywołanie zależności ruchu wychodzącego oddzielone od żądania przychodzącego. Zazwyczaj oba wywołania wyglądają identycznie, a różni się tylko długość ich trwania z powodu opóźnienia sieciowego. Ikona wiodąca i odrębne style pasków czasu trwania pomagają je odróżnić. Czy ta prezentacja danych jest myląca? Prześlij nam swoją opinię!

Osie czasu są dostosowywane dla niesymetryczności zegara na wykresie transakcji. Dokładne znaczniki czasu można zobaczyć w okienku szczegółów lub przy użyciu usługi Log Analytics.

Jest to zamierzone działanie. Wszystkie powiązane elementy we wszystkich składnikach są już dostępne po lewej stronie w górnej i dolnej sekcji. Nowe środowisko ma dwa powiązane elementy, których lewa część nie obejmuje: wszystkie dane telemetryczne z pięciu minut przed i po tym zdarzeniu oraz linia czasu użytkownika.

Środowisko diagnostyki transakcji pokazuje wszystkie dane telemetryczne w jednej operacji, która udostępnia identyfikator operacji. Domyślnie zestaw SDK usługi Application Insights dla języka JavaScript tworzy nową operację dla każdego unikatowego widoku strony. W aplikacji jednostronicowej (SPA) generowane jest tylko jedno zdarzenie widoku strony, a dla wszystkich generowanych danych telemetrycznych jest używany pojedynczy identyfikator operacji. W związku z tym wiele zdarzeń może być skorelowanych z tą samą operacją.

W tych scenariuszach możesz użyć automatycznego śledzenia tras, aby automatycznie utworzyć nowe operacje nawigacji w SPA. Należy włączyć funkcję EnableAutoRouteTracking , aby widok strony był generowany za każdym razem, gdy trasa adresu URL jest aktualizowana (występuje widok strony logicznej). Jeśli chcesz ręcznie odświeżyć identyfikator operacji, wywołaj metodę appInsights.properties.context.telemetryTrace.traceID = Microsoft.ApplicationInsights.Telemetry.Util.generateW3CId(). Ręczne wyzwalanie zdarzenia PageView powoduje również zresetowanie identyfikatora operacji.

Czas, który nie został wyjaśniony na wykresie Gantta, to czas, który nie jest objęty śledzonej zależności. Ten problem może wystąpić, ponieważ wywołania zewnętrzne nie zostały instrumentowane automatycznie lub ręcznie. Może się to również zdarzyć, ponieważ czas potrzebny był w procesie, a nie z powodu wywołania zewnętrznego.

Jeśli wszystkie wywołania zostały instrumentowane, proces jest prawdopodobną główną przyczyną czasu spędzonego. Przydatnym narzędziem do diagnozowania procesu jest Profiler platformy .NET.

Wskazuje on, że przeglądarka nie mogła wywołać wymaganego interfejsu API lub interfejs API zwrócił odpowiedź wskazującą na niepowodzenie. Aby rozwiązać problemy z zachowaniem, otwórz okno przeglądarki InPrivate i wyłącz wszystkie uruchomione rozszerzenia przeglądarki , a następnie zidentyfikuj, czy nadal możesz odtworzyć zachowanie portalu. Jeśli błąd portalu nadal występuje, spróbuj przetestować inne przeglądarki lub inne maszyny, zbadaj problemy związane z systemem DNS lub inną siecią z maszyny klienckiej, na której wywołania interfejsu API kończą się niepowodzeniem. Jeśli błąd portalu będzie kontynuowany i wymaga dokładniejszego zbadania, zbierz ślad sieci przeglądarki podczas odtwarzania nieoczekiwanego zachowania portalu, a następnie otwórz zgłoszenie do pomocy technicznej w witrynie Azure Portal.

Aby uzyskać więcej informacji, zobacz Wyszukiwanie transakcji i diagnostyka.

Początkowe zdarzenie w wizualizacji reprezentuje tylko pierwszy raz, gdy użytkownik wysłał ten widok strony lub zdarzenie niestandardowe podczas sesji. Jeśli użytkownicy mogą wysyłać zdarzenie początkowe wielokrotnie w sesji, kolumna Krok 1 pokazuje tylko, jak użytkownicy zachowują się po pierwszym wystąpieniu zdarzenia początkowego, a nie wszystkich wystąpień.

Użyj opcji Podziel według w menu Edycja:

1. Wybierz zdarzenie, które chcesz podzielić na menu Zdarzenie .

2. Wybierz wymiar w menu Wymiar . Na przykład, jeśli masz zdarzenie o nazwie Button Clicked, spróbuj użyć właściwości niestandardowej o nazwie Nazwa przycisku.

Kohorty i filtry są różne. Załóżmy, że masz kohortę użytkowników z Zjednoczonego Królestwa (zdefiniowaną tak jak w poprzednim przykładzie), a wyniki są porównywane z ustawieniem filtru Country or region = United Kingdom:

• Wersja kohorty pokazuje wszystkie zdarzenia od użytkowników, którzy wysłali co najmniej jedno zdarzenie ze Zjednoczonego Królestwa w bieżącym zakresie czasu. Jeśli podzielisz według kraju lub regionu, prawdopodobnie zobaczysz wiele krajów i regionów.

• Wersja filtrów pokazuje tylko zdarzenia z Zjednoczonego Królestwa. W przypadku podziału według kraju lub regionu zobaczysz tylko Zjednoczone Królestwo.

Możesz wybrać filtr ziarnistości daty, aby zmienić poziom szczegółowości. Filtr jest dostępny na wszystkich zakładkach wymiarów.

Możesz zagłębić się w dane, które zasilają skoroszyt HEART, jeśli wizualizacje nie odpowiadają na wszystkie Twoje pytania. Aby wykonać to zadanie, w sekcji Monitorowanie w usłudze Application Insights wybierz pozycję Dzienniki i wykonaj zapytanie względem customEvents tabeli. Niektóre atrybuty analizy kliknięć znajdują się w customDimensions polu.

Przykładowe zapytanie jest pokazane tutaj:

customEvents
| where isnotnull(customDimensions.actionType)
| extend parentid=tostring(customDimensions.parenId),
pagename=tostring(customDimensions.pageName),
actiontype=tostring(customDimensions.actionType)
| project actiontype,parentid,pagename,
user_AuthenticatedId,user_Id,session_Id,itemType,timestamp

Aby dowiedzieć się więcej na temat dzienników w usłudze Azure Monitor, zobacz Omówienie dzienników usługi Azure Monitor.

Tak. Aby dowiedzieć się, jak edytować szablony skoroszytów, zobacz Szablony skoroszytów platformy Azure.

Aby uzyskać więcej informacji, zobacz Analiza użycia za pomocą usługi Application Insights.

Scenariusz aplikacji platformy .NET Core	Pakiet
Bez hostowanych usług	WorkerService
Z usługami HostedServices	AspNetCore (nie WorkerService)
W usłudze HostedServices monitorowanie tylko hostowanychusług	WorkerService (rzadki scenariusz)

Tak, konfiguracja jest udostępniana pozostałej części aplikacji internetowej.

Uzyskaj wystąpienie TelemetryClient przy użyciu iniekcji konstruktora i wywołaj na nim wymaganą metodę TrackXXX(). Nie zalecamy tworzenia nowych TelemetryClient wystąpień. Singleton TelemetryClient jest już zarejestrowany w kontenerze DependencyInjection, który współdzieli TelemetryConfiguration z resztą telemetrii. Tworzenie nowego TelemetryClient wystąpienia jest zalecane tylko wtedy, gdy wymaga konfiguracji, która jest oddzielona od pozostałej części telemetrii.

Dołączanie środowiska IDE programu Visual Studio jest obecnie obsługiwane tylko w przypadku aplikacji ASP.NET/ASP.NET Core. Ten dokument jest aktualizowany, gdy Visual Studio wprowadza obsługę wdrażania aplikacji typu Worker Service.

Nie. Agent usługi Azure Monitor Application Insights obecnie obsługuje tylko platformę .NET.

Tak. Obsługa funkcji dla tego zestawu SDK jest taka sama na wszystkich platformach z następującymi wyjątkami:

• Licznikami wydajności są obsługiwane tylko w systemie Windows, z wyjątkiem liczników Procesora CPU/Pamięci pokazywanych w metrykach na żywo.

• Mimo że ServerTelemetryChannel jest domyślnie włączona, jeśli aplikacja jest uruchomiona w systemie Linux lub macOS, kanał telemetrii nie tworzy automatycznie lokalnego folderu do przechowywania danych telemetrycznych w przypadku problemów z siecią. Z powodu tego ograniczenia dane telemetryczne są tracone, gdy występują tymczasowe problemy z siecią lub serwerem. Aby obejść ten problem, skonfiguruj folder lokalny dla kanału:

  using Microsoft.ApplicationInsights.Channel;
  using Microsoft.ApplicationInsights.WindowsServer.TelemetryChannel;
  
       public void ConfigureServices(IServiceCollection services)
       {
           // The following will configure the channel to use the given folder to temporarily
           // store telemetry items during network or Application Insights server issues.
           // User should ensure that the given folder already exists
           // and that the application has read/write permissions.
           services.AddSingleton(typeof(ITelemetryChannel),
                                   new ServerTelemetryChannel () {StorageFolder = "/tmp/myfolder"});
           services.AddApplicationInsightsTelemetryWorkerService();
       }
  

Aby uzyskać więcej informacji, zobacz Application Insights for Worker Service applications (aplikacje inne niż HTTP).