Megosztás a következőn keresztül:

Naplóadatok feldolgozási ideje az Azure Monitorban

  • Cikk

Az Azure Monitor egy nagy léptékű adatszolgáltatás, amely több ezer ügyfelet szolgál ki, akik havonta több terabájtnyi adatot küldenek növekvő ütemben. Gyakran merül fel a kérdés, hogy mennyi időbe telik, mire a naplóadatok elérhetővé válnak az adatgyűjtés után. Ez a cikk a késést befolyásoló különböző tényezőket ismerteti.

Átlagos késés

A késés azt az időt jelenti, amikor az adatok létrejönnek a figyelt rendszeren, és azt az időpontot, amikor az adatok elérhetővé válnak elemzésre az Azure Monitorban. A naplóadatok betöltésének átlagos késése 20 másodperc és 3 perc között van. Az egyes adatok konkrét késése a cikkben ismertetett számos tényezőtől függően változhat.

A késést befolyásoló tényezők

Egy adott adathalmaz teljes betöltési ideje a következő magas szintű területekre bontható:

  • Ügynökidő: Az esemény felderítésének, gyűjtésének, majd az adatgyűjtési végpontnak való elküldésének ideje naplórekordként. A legtöbb esetben ezt a folyamatot egy ügynök kezeli. A hálózat nagyobb késést okozhat.
  • Folyamat ideje: A betöltési folyamat naplórekordjának feldolgozásához szükséges idő. Ez az időszak magában foglalja az esemény tulajdonságainak elemzését és a számított információk hozzáadását.
  • Indexelési idő: A naplórekord Azure Monitor big data-tárolóba való betöltésének ideje.

Az ebben a folyamatban bevezetett különböző késés részleteit az alábbi szakaszok ismertetik.

Az ügynökgyűjtemény késése

Az idő változó

Az ügynökök és a felügyeleti megoldások különböző stratégiákkal gyűjtenek adatokat egy virtuális gépről, ami befolyásolhatja a késést. Néhány konkrét példát az alábbi táblázat sorol fel.

Adatok típusa A gyűjtés gyakorisága Jegyzetek
Windows-események, Syslog-események és teljesítménymetrikák Azonnal összegyűjtve
Linux teljesítményszámlálók Lekérdezés 30 másodperces időközökkel
IIS-naplók és szöveges naplók Az időbélyeg módosítása után gyűjtött adatok Az IIS-naplók esetében ezt az ütemezést az IIS-en konfigurált átállási ütemezés befolyásolja.
Active Directory replikációs megoldás Értékelés öt naponta Az ügynök csak akkor gyűjti össze a naplókat, ha az értékelés befejeződött.
Active Directory Assessment-megoldás Az Active Directory-infrastruktúra heti értékelése Az ügynök csak akkor gyűjti össze a naplókat, ha az értékelés befejeződött.

Az ügynök feltöltési gyakorisága

1 perc alatt

A Log Analytics-ügynök egyszerűségének biztosítása érdekében az ügynök puffereli a naplókat, és rendszeresen feltölti őket az Azure Monitorba. A feltöltés gyakorisága az adatok típusától függően 30 másodperc és 2 perc között változik. A legtöbb adat feltöltése 1 perc alatt történik.

Network (Hálózat)

Változik

A hálózati feltételek negatívan befolyásolhatják az adatok késését az adatgyűjtési végpont eléréséhez.

Azure-metrikák, erőforrásnaplók, tevékenységnaplók

30 másodperc és 15 perc között

Az Azure-adatok több időt adnak arra, hogy elérhetővé váljanak egy adatgyűjtési végponton a feldolgozáshoz:

  • Az Azure-platform metrikái egy perc alatt elérhetők a metrikák adatbázisában, de további 3 percet vesz igénybe az adatgyűjtési végpontra való exportálásuk.
  • Az erőforrásnaplók általában 30–90 másodpercet adnak hozzá az Azure-szolgáltatástól függően. Egyes Azure-szolgáltatások (különösen az Azure SQL Database és az Azure Virtual Network) jelenleg 5 perces időközönként jelentik a naplóikat. Folyamatban van a munka, hogy továbbfejlessze ezt az időt. Ha meg szeretné vizsgálni ezt a késést a környezetben, tekintse meg az alábbi lekérdezést.
  • A tevékenységnaplók 3–20 perc alatt érhetők el elemzésre.

Felügyeleti megoldások gyűjteménye

Változik

Egyes megoldások nem gyűjtik az adataikat egy ügynöktől, és olyan gyűjtési módszert használhatnak, amely nagyobb késést eredményez. Egyes megoldások rendszeres időközönként gyűjtenek adatokat anélkül, hogy közel valós idejű adatgyűjtést kísérelnek meg. Konkrét példák:

  • A Microsoft 365-megoldás a Felügyeleti tevékenység API használatával kérdezi le a tevékenységnaplókat, amely jelenleg nem biztosít közel valós idejű késési garanciákat.
  • A Megoldás napi gyakorisággal gyűjti a Windows Analytics-megoldásokat (például frissítési megfelelőséget).

A megoldások gyűjtési gyakoriságának meghatározásához tekintse meg az egyes megoldások dokumentációját.

Folyamatfolyamat ideje

30–60 másodperc

Miután az adatok elérhetővé válnak az adatgyűjtési végponton, további 30–60 másodperc szükséges a lekérdezéshez.

Miután a naplórekordok bekerültek az Azure Monitor-folyamatba (a _TimeReceived tulajdonságban azonosítottak szerint), a rendszer ideiglenes tárolóba írja őket a bérlői elkülönítés biztosítása és az adatok elvesztésének biztosítása érdekében. Ez a folyamat általában 5–15 másodpercet ad hozzá.

Egyes megoldások nehezebb algoritmusokat implementálnak az adatok összesítésére és az elemzések kinyerésére, mivel az adatok streamelése folyamatban van. Az Application Insights például az alkalmazástérkép adatait számítja ki; Az Azure Network Performance Monitoring 3 perces időközönként összesíti a bejövő adatokat, ami 3 perces késést eredményez.

Ha az adatgyűjtés betöltési idejű átalakítást is tartalmaz, akkor ez némi késést ad a folyamathoz. Az átalakítási lekérdezés hatékonyságának figyeléséhez használja a metrikariasztációs naplók átalakítási időtartamát min .

Egy másik folyamat, amely késést ad hozzá, az egyéni naplókat kezelő folyamat. Bizonyos esetekben ez a folyamat néhány perc késést adhat az ügynök által a fájlokból gyűjtött naplókhoz.

Új egyéni adattípusok kiépítése

Amikor új típusú egyéni adat jön létre egy egyéni naplóból vagy a Data Collector API-ból, a rendszer létrehoz egy dedikált tárolót. Ez az egyszeri többletterhelés csak az adattípus első megjelenésekor jelentkezik.

Túlfeszültség-védelem

Általában kevesebb, mint 1 perc, de több is lehet

Az Azure Monitor elsődleges feladata annak biztosítása, hogy ne vesszenek el az ügyféladatok, így a rendszer beépített védelmet nyújt az adatingadozások ellen. Ez a védelem puffereket is tartalmaz, amelyek biztosítják, hogy még hatalmas terhelés esetén is a rendszer működjön. Normál terhelés esetén ezek a vezérlők kevesebb mint egy percet adnak hozzá. Szélsőséges körülmények között és hibák esetén jelentős időt adhatnak az adatok biztonságának biztosításához.

Indexelési idő

Legalább 5 perc

Minden big data platformhoz beépített egyensúly áll rendelkezésre az elemzés és a fejlett keresési képességek biztosítása között, nem pedig az adatokhoz való azonnali hozzáférés biztosítása között. Az Azure Monitorral több milliárd rekordon futtathat hatékony lekérdezéseket, és néhány másodpercen belül eredményeket kaphat. Ez a teljesítmény azért lehetséges, mert az infrastruktúra jelentősen átalakítja az adatokat a betöltés során, és egyedi kompakt struktúrákban tárolja. A rendszer puffereli az adatokat, amíg elegendő nem áll rendelkezésre ezeknek a struktúráknak a létrehozásához. Ezt a folyamatot be kell fejezni, mielőtt a naplórekord megjelenik a keresési eredményekben.

Ez a folyamat jelenleg körülbelül 5 percet vesz igénybe, ha kevés az adatmennyiség, de magasabb adatmennyiség esetén kevesebb időt vehet igénybe. Ez a viselkedés ellentétesnek tűnik, de ez a folyamat lehetővé teszi a késés optimalizálását a nagy mennyiségű éles számítási feladatok esetében.

Betöltési idő ellenőrzése

A betöltési idő különböző körülmények között eltérő lehet a különböző erőforrások esetében. A napló lekérdezésekkel azonosíthatja a környezet adott viselkedését. Az alábbi táblázat azt határozza meg, hogyan határozhatja meg egy rekord különböző időpontjait az Azure Monitornak való létrehozás és küldés során.

Lépés Tulajdonság vagy függvény Megjegyzések
Adatforrásban létrehozott rekord TimeGenerated
Ha az adatforrás nem állítja be ezt az értéket, akkor az _TimeReceived időpontra lesz állítva.		 Ha a feldolgozási időben a létrehozott időérték két napnál régebbi, a sor el lesz ejtve.
Az adatgyűjtési végpont által fogadott rekord _TimeReceived Ez a mező nincs tömeges feldolgozásra optimalizálva, és nem használható nagy adathalmazok szűrésére.
Munkaterületen tárolt és lekérdezésekhez elérhető rekord ingestion_time() Azt javasoljuk ingestion_time() , hogy csak azokat a rekordokat szűrje, amelyeket egy adott időablakban töltöttek be. Ilyen esetekben javasoljuk, hogy nagyobb tartományú szűrőt TimeGenerated is adjon hozzá.

Betöltési késések

Egy adott rekord késésének méréséhez hasonlítsa össze a ingestion_time() függvény eredményét a TimeGenerated tulajdonságtal. Ezek az adatok különböző aggregációkkal használhatók a betöltési késés működésének felderítésére. Vizsgálja meg a betöltési idő néhány százalékát, hogy nagy mennyiségű adathoz jusson elemzés.

A következő lekérdezés például megmutatja, hogy mely számítógépeken volt a legnagyobb betöltési idő az előző 8 órában:

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

Az előző percentilis ellenőrzések jóak a késés általános trendjeinek megállapításához. A késés rövid távú kiugró értékének azonosításához a maximális (max()) érték használata hatékonyabb lehet.

Ha le szeretné részletezni egy adott számítógép betöltési idejét egy adott időszakra vonatkozóan, használja a következő lekérdezést, amely az elmúlt nap adatait is megjeleníti egy grafikonon:

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

A következő lekérdezéssel megjelenítheti a számítógép betöltési idejét annak az országnak/régiónak a szerint, ahol találhatók, ami az IP-címük alapján történik:

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

Az ügynöktől származó különböző adattípusok eltérő betöltési késési idővel rendelkezhetnek, így az előző lekérdezések más típusokkal is használhatók. A következő lekérdezés segítségével megvizsgálhatja a különböző Azure-szolgáltatások betöltési idejét:

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

Használja ugyanazt a lekérdezési logikát az Application Insights-adatok késési feltételeinek diagnosztizálásához:

// 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

A fenti két lekérdezés a "kérések" kivételével bármely más Application Insights-táblával párosítható.

A válaszadást leállító erőforrások

Bizonyos esetekben előfordulhat, hogy egy erőforrás leállítja az adatok küldését. Annak megértéséhez, hogy egy erőforrás adatokat küld-e vagy sem, tekintse meg a legutóbbi rekordját, amelyet a standard TimeGenerated mező azonosít.

Heartbeat A táblázat segítségével ellenőrizheti a virtuális gép rendelkezésre állását, mert az ügynök percenként egyszer küld szívverést. A következő lekérdezés használatával listázhatja azokat az aktív számítógépeket, amelyek nem jelentettek szívverést a közelmúltban:

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

Következő lépések

Olvassa el az Azure Monitor szolgáltatásszintű szerződését .