Jegyzet
Az oldalhoz való hozzáférés engedélyezést igényel. Próbálhatod be jelentkezni vagy könyvtárat váltani.
Az oldalhoz való hozzáférés engedélyezést igényel. Megpróbálhatod a könyvtár váltását.
Az Azure Monitor egy nagy léptékű adatszolgáltatás több ezer ügyfél számára, akik havonta terabájtnyi adatot küldenek, és folyamatosan növekednek. A cikk ismerteti, hogy mennyi időbe telik, amíg a naplóadatok elérhetővé válnak a begyűjtése után, és hogy milyen tényezők befolyásolják ezt a késést.
Á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.
- Feldolgozási idő: A beviteli csatorna 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ök adatgyűjtés 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 20 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 3–10 percen belül érhetők el a szolgáltatás összetettségétől és az érintett Azure-szolgáltatásoktól függően. Az Azure SQL Database és az Azure Virtual Network például jelenleg 5 percenként adja meg a naplóikat. 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 elemzéshez és riasztáshoz 3–20 perc alatt érhetők el.
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 Windows Analytics megoldások (például a Frissítési Megfelelőség) napi rendszerességgel gyűjtik az adatokat.
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 (ahogyan a _TimeReceived tulajdonság azonosítja), ideiglenes tárolóba kerülnek a bérlők elkülönítésének biztosítása és az adatok elvesztésének megakadályozá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 metrikát naplókon keresztüli átalakítás időtartama per perc.
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 ellátása
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 lesz a struktúrák 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.
Beviteli idő ellenőrzése
A feldolgozási idő különböző körülmények között eltérhet a különböző erőforrások esetében. 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. A napló lekérdezésekkel kapcsolatos további információkért lásd a Log Analytics áttekintését.
Figyelmeztetés
Amikor naplókat tölt be az Azure Monitor kiegészítő rétegébe, ne küldjön be egyetlen csomagot, amely egy API-hívásban 30 percnél hosszabb időtartamra vonatkozó TimeGenerated időbélyegeket tartalmaz. Ez az API-hívás a következő betöltési hibakódhoz RecordsTimeRangeIsMoreThan30Minutesvezethet. Ez egy ismert korlátozás , amelyet el kell távolítani.
Ez a korlátozás nem vonatkozik az átalakításokat használó segédnaplókra.
| Lépés | Tulajdonság vagy függvény | Megjegyzések |
|---|---|---|
| Adatforrásban létrehozott rekord | TimeGenerated | A TimeGenerated érték nem lehet több, mint két nappal a kapott idő előtt, vagy egy napnál több a jövőben. Ellenkező esetben az Azure Monitor-naplók a TimeGenerated értéket a tényleges fogadott időre cserélik. Ha az adatforrás nem állítja be ezt az értéket, az Azure Monitor-naplók az értéket a _TimeReceived azonos időpontra állítják be. |
| 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, hogy ingestion_time()-t használjon, ha csak azokat a rekordokat kell szűrni, 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 feldolgozási idő némely percentilisét, hogy betekintést nyerjen a nagy mennyiségű adatok elemzéséhez.
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 .