Metryki oparte na dzienniku i metryki wstępnie zagregowane w usłudze Application Insights
Uwaga
Poniższa dokumentacja opiera się na klasycznym interfejsie API usługi Application Szczegółowe informacje. Długoterminowy plan Szczegółowe informacje aplikacji polega na zbieraniu danych przy użyciu biblioteki OpenTelemetry. Aby uzyskać więcej informacji, zobacz Enable Azure Monitor OpenTelemetry for .NET, Node.js, Python and Java applications (Włączanie usługi Azure Monitor OpenTelemetry dla platformy .NET, Node.js, Python i Java applications).
W tym artykule wyjaśniono różnicę między "tradycyjnymi" metrykami aplikacji Szczegółowe informacje opartymi na dziennikach i wstępnie zagregowanych metrykach. Oba typy metryk są dostępne dla użytkowników Szczegółowe informacje aplikacji. Każdy z nich zapewnia unikatową wartość monitorowania kondycji, diagnostyki i analizy aplikacji. Deweloperzy, którzy instrumentują aplikacje, mogą zdecydować, który typ metryki najlepiej nadaje się do określonego scenariusza. Decyzje są oparte na rozmiarze aplikacji, oczekiwanej ilości danych telemetrycznych i wymaganiach biznesowych dotyczących dokładności i alertów metryk.
Metryki na podstawie dzienników
W przeszłości model danych telemetrycznych monitorowania aplikacji w usłudze Application Szczegółowe informacje był oparty wyłącznie na kilku wstępnie zdefiniowanych typach zdarzeń, takich jak żądania, wyjątki, wywołania zależności i widoki stron. Deweloperzy mogą użyć zestawu SDK do ręcznego emitowania tych zdarzeń, pisząc kod, który jawnie wywołuje zestaw SDK. Mogą też polegać na automatycznej kolekcji zdarzeń z autoinstrumentacji. W obu przypadkach usługa Application Szczegółowe informacje zaplecza przechowuje wszystkie zebrane zdarzenia jako dzienniki. Okienka Szczegółowe informacje aplikacji w witrynie Azure Portal działają jako narzędzie analityczne i diagnostyczne służące do wizualizowania danych opartych na zdarzeniach z dzienników.
Przechowywanie pełnego zestawu zdarzeń przy użyciu dzienników może przynieść doskonałą wartość analityczną i diagnostyczną. Możesz na przykład uzyskać dokładną liczbę żądań do określonego adresu URL z liczbą różnych użytkowników, którzy wykonali te wywołania. Możesz też uzyskać szczegółowe ślady diagnostyczne, w tym wyjątki i wywołania zależności dla dowolnej sesji użytkownika. Posiadanie tego typu informacji może poprawić widoczność kondycji i użycia aplikacji. Może również skrócić czas potrzebny do zdiagnozowania problemów z aplikacją.
Jednocześnie zbieranie pełnego zestawu zdarzeń może być niepraktyczne lub nawet niemożliwe dla aplikacji, które generują dużą ilość danych telemetrycznych. W sytuacjach, gdy ilość zdarzeń jest zbyt duża, aplikacja Szczegółowe informacje implementuje kilka technik redukcji woluminów telemetrycznych, które zmniejszają liczbę zebranych i przechowywanych zdarzeń. Te techniki obejmują próbkowanie i filtrowanie. Niestety obniżenie liczby przechowywanych zdarzeń zmniejsza również dokładność metryk, które w tle muszą wykonywać agregacje czasu zapytania zdarzeń przechowywanych w dziennikach.
Uwaga
W Szczegółowe informacje aplikacji metryki oparte na agregacji czasu zapytania zdarzeń i pomiarów przechowywanych w dziennikach są nazywane metrykami opartymi na dziennikach. Te metryki zwykle mają wiele wymiarów z właściwości zdarzenia, co sprawia, że są one lepsze dla analizy. Dokładność tych metryk ma negatywny wpływ na próbkowanie i filtrowanie.
Wstępnie zagregowane metryki
Oprócz metryk opartych na dziennikach pod koniec 2018 r. zespół aplikacji Szczegółowe informacje wysłał publiczną wersję zapoznawcza metryk przechowywanych w wyspecjalizowanym repozytorium zoptymalizowanym pod kątem szeregów czasowych. Nowe metryki nie są już przechowywane jako pojedyncze zdarzenia z dużą częścią właściwości. Zamiast tego są one przechowywane jako wstępnie zagregowane szeregi czasowe i tylko z kluczowymi wymiarami. Ta zmiana sprawia, że nowe metryki są lepsze w czasie wykonywania zapytań. Pobieranie danych odbywa się szybciej i wymaga mniejszej mocy obliczeniowej. W związku z tym nowe scenariusze są włączone, takie jak alerty niemal w czasie rzeczywistym dotyczące wymiarów metryk i bardziej dynamicznych pulpitów nawigacyjnych.
Ważne
Zarówno metryki oparte na dzienniku, jak i wstępnie zagregowane współistnieją w Szczegółowe informacje aplikacji. Aby odróżnić te dwie metryki, w środowisku użytkownika Szczegółowe informacje aplikacji metryki wstępnie zagregowane są teraz nazywane metrykami standardowymi (wersja zapoznawcza). Nazwa tradycyjnych metryk z zdarzeń została zmieniona na Metryki oparte na dzienniku.
Nowsze zestawy SDK (zestaw SDK aplikacji Szczegółowe informacje 2.7 lub nowszy dla platformy .NET) wstępnie zagregowane metryki podczas zbierania. Ten proces ma zastosowanie do standardowych metryk wysyłanych domyślnie, więc dokładność nie ma wpływu na próbkowanie ani filtrowanie. Dotyczy to również metryk niestandardowych wysyłanych przy użyciu polecenia GetMetric, co skutkuje mniejszym pozyskiwaniem danych i niższym kosztem.
W przypadku zestawów SDK, które nie implementują wstępnego agregacji (czyli starszych wersji zestawów SDK aplikacji Szczegółowe informacje lub instrumentacji przeglądarki), zaplecze Application Szczegółowe informacje nadal wypełnia nowe metryki przez agregowanie zdarzeń odebranych przez punkt końcowy kolekcji zdarzeń usługi Application Szczegółowe informacje. Mimo że nie korzystasz z mniejszej ilości danych przesyłanych za pośrednictwem przewodu, nadal możesz używać wstępnie zagregowanych metryk i uzyskać lepszą wydajność oraz obsługę alertów wymiarowych niemal w czasie rzeczywistym za pomocą zestawów SDK, które nie są wstępnie agregowane metryki podczas zbierania.
Punkt końcowy kolekcji wstępnie agreguje zdarzenia przed próbkowaniem pozyskiwania. Z tego powodu próbkowanie pozyskiwania nigdy nie wpływa na dokładność wstępnie zagregowanych metryk, niezależnie od wersji zestawu SDK używanej z aplikacją.
Obsługiwana wstępnie zagregowana tabela metryk zestawu SDK
| Bieżące produkcyjne zestawy SDK | Metryki standardowe (agregacja wstępna zestawu SDK) | Metryki niestandardowe (bez agregacji wstępnej zestawu SDK) | Metryki niestandardowe (z agregacją wstępną zestawu SDK) |
|---|---|---|---|
| .NET Core i .NET Framework | Obsługiwane (wersja 2.13.1 lub nowsza) | Obsługiwane za pomocą usługi TrackMetric | Obsługiwane (wersja 2.7.2 lub nowsza) za pośrednictwem polecenia GetMetric |
| Java | Nieobsługiwane | Obsługiwane za pomocą usługi TrackMetric | Nieobsługiwane |
| Node.js | Obsługiwane (wersja 2.0.0 lub nowsza) | Obsługiwane za pomocą usługi TrackMetric | Nieobsługiwane |
| Python | Nieobsługiwane | Obsługiwane | Częściowo obsługiwane za pośrednictwem pliku OpenCensus.stats |
Uwaga
Implementacja metryk dla języka Python przy użyciu biblioteki OpenCensus.stats różni się od metody GetMetric. Aby uzyskać więcej informacji, zobacz dokumentację języka Python dotyczącą metryk.
Tabela metryk wstępnie zagregowanych bez kodu
| Bieżące produkcyjne zestawy SDK | Metryki standardowe (agregacja wstępna zestawu SDK) | Metryki niestandardowe (bez agregacji wstępnej zestawu SDK) | Metryki niestandardowe (z agregacją wstępną zestawu SDK) |
|---|---|---|---|
| ASP.NET | Obsługiwane 1 | Nieobsługiwane | Nieobsługiwane |
| ASP.NET Core | Obsługiwane 2 | Nieobsługiwane | Nieobsługiwane |
| Java | Nieobsługiwane | Nieobsługiwane | Obsługiwane |
| Node.js | Nieobsługiwane | Nieobsługiwane | Nieobsługiwane |
- ASP.NET dołączanie bez kodu na maszynach wirtualnych/zestawach skalowania maszyn wirtualnych i lokalnie emituje standardowe metryki bez wymiarów. To samo dotyczy usługi aplikacja systemu Azure, ale poziom kolekcji musi być ustawiony na zalecany. Zestaw SDK jest wymagany dla wszystkich wymiarów.
- ASP.NET Dołączanie bez kodu w usłudze App Service emituje standardowe metryki bez wymiarów. Zestaw SDK jest wymagany dla wszystkich wymiarów.
Używanie wstępnego agregacji z metrykami niestandardowymi usługi Application Szczegółowe informacje
Możesz użyć wstępnej agregacji z metrykami niestandardowymi. Dwie główne korzyści to:
- Możliwość konfigurowania i zgłaszania alertów dotyczących wymiaru metryki niestandardowej
- Zmniejsz ilość danych wysyłanych z zestawu SDK do punktu końcowego kolekcji aplikacji Szczegółowe informacje
Istnieje kilka sposobów wysyłania metryk niestandardowych z zestawu SDK usługi Application Szczegółowe informacje. Jeśli twoja wersja zestawu SDK oferuje metody GetMetric i TrackValue, te metody są preferowanym sposobem wysyłania metryk niestandardowych. W takim przypadku agregacja wstępna odbywa się wewnątrz zestawu SDK. Takie podejście zmniejsza ilość danych przechowywanych na platformie Azure, a także ilość danych przesyłanych z zestawu SDK do usługi Application Szczegółowe informacje. W przeciwnym razie użyj metody trackMetric, która wstępnie agreguje zdarzenia metryk podczas pozyskiwania danych.
Niestandardowe wymiary metryk i wstępne agregacje
Wszystkie metryki wysyłane przy użyciu biblioteki OpenTelemetry, trackMetric lub GetMetric oraz Wywołania interfejsu API TrackValue są automatycznie przechowywane zarówno w magazynach dzienników, jak i metryk. Te metryki można znaleźć w tabeli customMetrics w obszarze Application Szczegółowe informacje i w Eksploratorze metryk w obszarze Niestandardowa przestrzeń nazw metryki o nazwie "azure.applicationinsights". Mimo że wersja oparta na dzienniku metryki niestandardowej zawsze zachowuje wszystkie wymiary, wstępnie zagregowana wersja metryki jest przechowywana domyślnie bez wymiarów. Zachowywanie wymiarów metryk niestandardowych jest funkcją w wersji zapoznawczej, którą można włączyć na karcie Użycie i szacowany koszt , wybierając pozycję Z wymiarami w obszarze Wyślij metryki niestandardowe do magazynu metryk platformy Azure.
Normy sprzedaży
Wstępnie zagregowane metryki są przechowywane jako szeregi czasowe w usłudze Azure Monitor. Mają zastosowanie limity przydziału usługi Azure Monitor dla metryk niestandardowych.
Uwaga
Przekroczenie limitu przydziału może mieć niezamierzone konsekwencje. Usługa Azure Monitor może stać się zawodna w twojej subskrypcji lub regionie. Aby dowiedzieć się, jak uniknąć przekroczenia limitu przydziału, zobacz Ograniczenia i zagadnienia dotyczące projektowania.
Dlaczego kolekcja wymiarów metryk niestandardowych jest domyślnie wyłączona?
Kolekcja niestandardowych wymiarów metryk jest domyślnie wyłączona, ponieważ w przyszłości przechowywanie niestandardowych metryk z wymiarami będzie rozliczane oddzielnie od usługi Application Szczegółowe informacje. Przechowywanie niewymiarowych metryk niestandardowych pozostaje bezpłatne (do limitu przydziału). Możesz dowiedzieć się więcej o nadchodzących zmianach modelu cenowych na naszej oficjalnej stronie cennika.
Tworzenie wykresów i eksplorowanie wstępnie zagregowanych metryk opartych na dziennikach i standardowych
Użyj Eksploratora metryk usługi Azure Monitor, aby wykreślić wykresy ze wstępnie zagregowanych i opartych na dziennikach metryki oraz tworzyć pulpity nawigacyjne z wykresami. Po wybraniu żądanego zasobu Aplikacja Szczegółowe informacje użyj selektora przestrzeni nazw, aby przełączać się między standardowymi (wersja zapoznawcza) i metrykami opartymi na dziennikach. Możesz również wybrać niestandardową przestrzeń nazw metryki.
Modele cenowe metryk usługi Application Szczegółowe informacje
Pozyskiwanie metryk w usłudze Application Szczegółowe informacje, zarówno oparte na dzienniku, jak i wstępnie zagregowane, generuje koszty na podstawie rozmiaru pozyskanych danych. Aby uzyskać więcej informacji, zobacz artykuł Cennik usługi Azure Monitor Logs. Metryki niestandardowe, w tym wszystkie jego wymiary, są zawsze przechowywane w magazynie dzienników usługi Application Szczegółowe informacje. Ponadto wstępnie zagregowana wersja metryk niestandardowych bez wymiarów jest domyślnie przekazywana do magazynu metryk.
Wybranie opcji Włącz alerty dotyczące niestandardowych wymiarów metryk w celu przechowywania wszystkich wymiarów wstępnie zagregowanych metryk w magazynie metryk może wygenerować dodatkowe koszty na podstawie niestandardowych cen metryk.