Czas pozyskiwania danych dziennika w usłudze Azure Monitor

Azure Monitor to usługa danych o dużej skali, która obsługuje tysiące klientów, którzy wysyłają terabajty danych każdego miesiąca w rosnącym tempie. Często pojawiają się pytania dotyczące czasu, przez jaki dane dziennika staną się dostępne po zebraniu. W tym artykule wyjaśniono różne czynniki wpływające na to opóźnienie.

Średnie opóźnienie

Opóźnienie odnosi się do czasu utworzenia danych w monitorowanym systemie oraz czasu, w jaki staną się dostępne do analizy w usłudze Azure Monitor. Średnie opóźnienie pozyskiwania danych dziennika wynosi od 20 sekund do 3 minut. Określone opóźnienie dla konkretnych danych będzie się różnić w zależności od kilku czynników, które zostały wyjaśnione w tym artykule.

Czynniki wpływające na opóźnienie

Łączny czas pozyskiwania dla określonego zestawu danych można podzielić na następujące obszary wysokiego poziomu:

• Czas agenta: czas odnajdywania zdarzenia, zbierania go, a następnie wysyłania go do punktu końcowego zbierania danych jako rekordu dziennika. W większości przypadków ten proces jest obsługiwany przez agenta. W sieci może zostać wprowadzone większe opóźnienie.
• Czas potoku: czas przetwarzania rekordu dziennika przez potok pozyskiwania. Ten okres obejmuje analizowanie właściwości zdarzenia i potencjalnie dodawanie informacji obliczeniowych.
• Czas indeksowania: czas spędzony na pozyskiwaniu rekordu dziennika do magazynu danych big data usługi Azure Monitor.

Szczegółowe informacje na temat różnych opóźnień wprowadzonych w tym procesie opisano w poniższych sekcjach.

Opóźnienie zbierania agenta

Czas różni się

Agenci i rozwiązania do zarządzania używają różnych strategii do zbierania danych z maszyny wirtualnej, co może mieć wpływ na opóźnienie. Niektóre konkretne przykłady zostały wymienione w poniższej tabeli.

Typ danych	Częstotliwość zbierania	Uwagi
Zdarzenia systemu Windows, zdarzenia dziennika systemowego i metryki wydajności	Zbierane natychmiast
Liczniki wydajności systemu Linux	Sondowane w 30-sekundowych odstępach czasu
Dzienniki i dzienniki tekstowe usług IIS	Zbierane po zmianach sygnatury czasowej	W przypadku dzienników usług IIS ten harmonogram ma wpływ na harmonogram przerzucania skonfigurowany w usługach IIS.
Rozwiązanie replikacji usługi Active Directory	Ocena co pięć dni	Agent zbiera dzienniki tylko po zakończeniu oceny.
Rozwiązanie do oceny usługi Active Directory	Tygodniowa ocena infrastruktury usługi Active Directory	Agent zbiera dzienniki tylko po zakończeniu oceny.

Częstotliwość przekazywania agenta

Poniżej 1 minuty

Aby upewnić się, że agent usługi Log Analytics jest lekki, agent buforuje dzienniki i okresowo przekazuje je do usługi Azure Monitor. Częstotliwość przekazywania różni się w zakresie od 30 sekund do 2 minut w zależności od typu danych. Większość danych jest przekazywanych w ciągu poniżej 1 minuty.

Sieć

Różni się

Warunki sieciowe mogą negatywnie wpłynąć na opóźnienie tych danych, aby uzyskać dostęp do punktu końcowego zbierania danych.

Metryki platformy Azure, dzienniki zasobów, dziennik aktywności

Od 30 sekund do 20 minut

W punkcie końcowym zbierania danych na potrzeby przetwarzania danych platforma Azure dodaje więcej czasu:

• Metryki platformy Azure są dostępne w ciągu minuty w bazie danych metryk, ale ich wyeksportowanie do punktu końcowego zbierania danych zajmuje kolejne 3 minuty.
• Dzienniki zasobów zwykle dodają od 30 do 90 sekund, w zależności od usługi platformy Azure. Niektóre usługi platformy Azure (w szczególności Azure SQL Database i Azure Virtual Network) obecnie zgłaszają swoje dzienniki w 5-minutowych odstępach czasu. Prace są w toku, aby ulepszyć ten czas. Aby sprawdzić to opóźnienie w środowisku, zobacz zapytanie, które następuje poniżej.
• Dzienniki aktywności są dostępne do analizy i alertów w ciągu 3 do 20 minut.

Kolekcja rozwiązań do zarządzania

Różni się

Niektóre rozwiązania nie zbierają danych z agenta i mogą używać metody kolekcji, która wprowadza większe opóźnienie. Niektóre rozwiązania zbierają dane w regularnych odstępach czasu bez próby zbierania danych niemal w czasie rzeczywistym. Oto konkretne przykłady:

• Rozwiązanie Platformy Microsoft 365 sonduje dzienniki aktywności przy użyciu interfejsu API aktywności zarządzania, który obecnie nie zapewnia żadnych gwarancji opóźnienia niemal w czasie rzeczywistym.
• Rozwiązania Windows Analytics (na przykład zgodność aktualizacji) są zbierane przez rozwiązanie z częstotliwością dzienną.

Aby określić częstotliwość zbierania rozwiązania, zapoznaj się z dokumentacją każdego rozwiązania.

Czas procesu potoku

Od 30 do 60 sekund

Gdy dane są dostępne w punkcie końcowym zbierania danych, udostępnienie zapytań zajmuje kolejne 30–60 sekund.

Po pozyskiwaniu rekordów dzienników do potoku usługi Azure Monitor (zgodnie z właściwością _TimeReceived ) są one zapisywane w magazynie tymczasowym, aby zapewnić izolację dzierżawy i upewnić się, że dane nie zostaną utracone. Ten proces zwykle dodaje 5 do 15 sekund.

Niektóre rozwiązania implementują cięższe algorytmy w celu agregowania danych i uzyskiwania szczegółowych informacji w miarę przesyłania strumieniowego danych. Na przykład usługa Application Insights oblicza dane mapy aplikacji; Usługa Azure Network monitor wydajności agreguje dane przychodzące w 3-minutowych odstępach czasu, co skutecznie zwiększa opóźnienie 3-minutowe.

Jeśli zbieranie danych obejmuje transformację czasu pozyskiwania, spowoduje to dodanie pewnego opóźnienia do potoku. Użyj czasu trwania transformacji dzienników metryk na minutę , aby monitorować wydajność zapytania przekształcenia.

Innym procesem, który dodaje opóźnienie, jest proces obsługujący dzienniki niestandardowe. W niektórych przypadkach ten proces może dodać kilka minut opóźnienia do dzienników zebranych z plików przez agenta.

Aprowizacja nowych niestandardowych typów danych

Po utworzeniu nowego typu danych niestandardowych na podstawie dziennika niestandardowego lub interfejsu API modułu zbierającego dane system tworzy dedykowany kontener magazynu. To jednorazowe obciążenie występuje tylko na pierwszym wyglądzie tego typu danych.

Ochrona przed przepięciami

Zazwyczaj mniej niż 1 minuta, ale może być więcej

Najwyższym priorytetem usługi Azure Monitor jest zapewnienie, że żadne dane klienta nie zostaną utracone, dlatego system ma wbudowaną ochronę przed wzrostami danych. Ta ochrona obejmuje w celu zapewnienia, że nawet pod ogromnym obciążeniem system będzie działać. W przypadku normalnego obciążenia te kontrolki dodają mniej niż minutę. W ekstremalnych warunkach i awariach mogą one znacznie zwiększyć czas, zapewniając bezpieczeństwo danych.

Czas indeksowania

5 minut lub mniej

Istnieje wbudowana równowaga dla każdej platformy danych big data między zapewnieniem możliwości analizy i zaawansowanego wyszukiwania, a nie zapewnieniem natychmiastowego dostępu do danych. Usługa Azure Monitor umożliwia uruchamianie zaawansowanych zapytań dotyczących miliardów rekordów i uzyskiwanie wyników w ciągu kilku sekund. Ta wydajność jest możliwa, ponieważ infrastruktura przekształca dane dramatycznie podczas pozyskiwania i przechowuje je w unikatowych strukturach kompaktowych. System buforuje dane do momentu udostępnienia wystarczającej ilości danych do utworzenia tych struktur. Ten proces musi zostać ukończony przed wyświetleniem rekordu dziennika w wynikach wyszukiwania.

Ten proces trwa obecnie około 5 minut, gdy istnieje mała ilość danych, ale może upłynąć mniej czasu z wyższymi szybkościami danych. Takie zachowanie wydaje się sprzeczne, ale ten proces umożliwia optymalizację opóźnienia dla obciążeń produkcyjnych o dużej ilości.

Sprawdzanie czasu pozyskiwania

Czas pozyskiwania może się różnić w różnych okolicznościach dla różnych zasobów. Zapytania dzienników umożliwiają identyfikowanie konkretnego zachowania środowiska. W poniższej tabeli opisano, jak można określić różne czasy dla rekordu podczas jego tworzenia i wysyłania do usługi Azure Monitor.

Krok	Właściwość lub funkcja	Komentarze
Rekord utworzony w źródle danych	TimeGenerated	Wartość TimeGenerated nie może być większa niż dwa dni przed odebraniem lub więcej niż dzień w przyszłości. W przeciwnym razie dzienniki usługi Azure Monitor zastępują wartość TimeGenerated rzeczywistą odebraną godziną. Jeśli źródło danych nie ustawi tej wartości, dzienniki usługi Azure Monitor ustawiają wartość na taki sam czas, jak _TimeReceived.
Rekord odebrany przez punkt końcowy zbierania danych	_TimeReceived	To pole nie jest zoptymalizowane pod kątem masowego przetwarzania i nie powinno być używane do filtrowania dużych zestawów danych.
Rekord przechowywany w obszarze roboczym i dostępny dla zapytań	ingestion_time()	Zalecamy użycie metody ingestion_time() , jeśli istnieje potrzeba filtrowania tylko rekordów, które zostały pozyskane w określonym przedziale czasu. W takich przypadkach zalecamy również dodanie filtru TimeGenerated z większym zakresem.

Opóźnienia pozyskiwania

Opóźnienie określonego rekordu można zmierzyć, porównując wynik funkcji ingestion_time() z właściwością TimeGenerated . Te dane mogą być używane z różnymi agregacjami, aby dowiedzieć się, jak działa opóźnienie pozyskiwania. Sprawdź jakiś percentyl czasu pozyskiwania, aby uzyskać szczegółowe informacje dotyczące dużych ilości danych.

Na przykład następujące zapytanie pokaże, które komputery miały najwyższy czas pozyskiwania w ciągu ostatnich 8 godzin:

Heartbeat
| where TimeGenerated > ago(8h) 
| extend E2EIngestionLatency = ingestion_time() - TimeGenerated 
| extend AgentLatency = _TimeReceived - TimeGenerated 
| summarize percentiles(E2EIngestionLatency,50,95), percentiles(AgentLatency,50,95) by Computer 
| top 20 by percentile_E2EIngestionLatency_95 desc

Poprzednie testy percentylu są dobre do znajdowania ogólnych trendów opóźnień. Aby zidentyfikować krótkotrwały wzrost opóźnienia, użycie maksymalnej wartości (max()) może być bardziej skuteczne.

Jeśli chcesz przejść do szczegółów czasu pozyskiwania dla określonego komputera w danym okresie, użyj następującego zapytania, które wizualizuje dane z ostatniego dnia na wykresie:

Heartbeat 
| where TimeGenerated > ago(24h) //and Computer == "ContosoWeb2-Linux"  
| extend E2EIngestionLatencyMin = todouble(datetime_diff("Second",ingestion_time(),TimeGenerated))/60 
| extend AgentLatencyMin = todouble(datetime_diff("Second",_TimeReceived,TimeGenerated))/60 
| summarize percentiles(E2EIngestionLatencyMin,50,95), percentiles(AgentLatencyMin,50,95) by bin(TimeGenerated,30m) 
| render timechart

Użyj następującego zapytania, aby wyświetlić czas pozyskiwania komputera według kraju/regionu, w którym się znajdują, na podstawie ich adresu IP:

Heartbeat 
| where TimeGenerated > ago(8h) 
| extend E2EIngestionLatency = ingestion_time() - TimeGenerated 
| extend AgentLatency = _TimeReceived - TimeGenerated 
| summarize percentiles(E2EIngestionLatency,50,95),percentiles(AgentLatency,50,95) by RemoteIPCountry 

Różne typy danych pochodzące z agenta mogą mieć inny czas opóźnienia pozyskiwania, więc poprzednie zapytania mogą być używane z innymi typami. Użyj następującego zapytania, aby zbadać czas pozyskiwania różnych usług platformy Azure:

AzureDiagnostics 
| where TimeGenerated > ago(8h) 
| extend E2EIngestionLatency = ingestion_time() - TimeGenerated 
| extend AgentLatency = _TimeReceived - TimeGenerated 
| summarize percentiles(E2EIngestionLatency,50,95), percentiles(AgentLatency,50,95) by ResourceProvider

Użyj tej samej logiki zapytań, aby zdiagnozować warunki opóźnienia dla danych usługi Application Insights:

// Classic Application Insights schema
let start=datetime("2023-08-21 05:00:00");
let end=datetime("2023-08-23 05:00:00");
requests
| where timestamp  > start and timestamp < end
| extend TimeEventOccurred = timestamp
| extend TimeRequiredtoGettoAzure = _TimeReceived - timestamp
| extend TimeRequiredtoIngest = ingestion_time() - _TimeReceived
| extend EndtoEndTime = ingestion_time() - timestamp
| project timestamp, TimeEventOccurred, _TimeReceived, TimeRequiredtoGettoAzure ,  ingestion_time(), TimeRequiredtoIngest, EndtoEndTime 
| sort by EndtoEndTime desc

// Workspace-based Application Insights schema
let start=datetime("2023-08-21 05:00:00");
let end=datetime("2023-08-23 05:00:00");
AppRequests
| where TimeGenerated  > start and TimeGenerated < end
| extend TimeEventOccurred = TimeGenerated
| extend TimeRequiredtoGettoAzure = _TimeReceived - TimeGenerated
| extend TimeRequiredtoIngest = ingestion_time() - _TimeReceived
| extend EndtoEndTime = ingestion_time() - TimeGenerated
| project TimeGenerated, TimeEventOccurred, _TimeReceived, TimeRequiredtoGettoAzure ,  ingestion_time(), TimeRequiredtoIngest, EndtoEndTime 
| sort by EndtoEndTime desc

Dwa powyższe zapytania można sparować z dowolną inną tabelą usługi Application Insights inną niż "requests".

Zasoby, które przestają odpowiadać

W niektórych przypadkach zasób może przestać wysyłać dane. Aby dowiedzieć się, czy zasób wysyła dane, zapoznaj się z najnowszym rekordem, który można zidentyfikować za pomocą pola standardowego TimeGenerated .

Heartbeat Użyj tabeli, aby sprawdzić dostępność maszyny wirtualnej, ponieważ puls jest wysyłany raz na minutę przez agenta. Użyj następującego zapytania, aby wyświetlić listę aktywnych komputerów, które ostatnio nie zgłosiły pulsu:

Heartbeat  
| where TimeGenerated > ago(1d) //show only VMs that were active in the last day 
| summarize NoHeartbeatPeriod = now() - max(TimeGenerated) by Computer  
| top 20 by NoHeartbeatPeriod desc 

Następne kroki

Przeczytaj umowę dotyczącą poziomu usług dla usługi Azure Monitor.