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ńcowegozbierania 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 15 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 w ciągu od 3 do 10 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 aplikacja Szczegółowe informacje 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 bufory 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 Jeśli źródło danych nie ustawi tej wartości, zostanie ono ustawione na taki sam czas, jak _TimeReceived. |
Jeśli w czasie przetwarzania wartość Wygenerowana godzina jest starsza niż dwa dni, wiersz zostanie porzucony. |
| 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 Szczegółowe informacje:
// 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 mogą być sparowane z dowolną inną tabelą Application Szczegółowe informacje 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.