A rugalmasság növelése a Log Analytics-munkaterület régiók közötti replikálásával (előzetes verzió)
A Log Analytics-munkaterület régiók közötti replikálása növeli a rugalmasságot, mivel lehetővé teszi a replikált munkaterületre való váltást, és regionális hiba esetén a műveletek folytatását. Ez a cikk bemutatja, hogyan működik a Log Analytics-munkaterület replikációja, hogyan replikálhatja a munkaterületet, hogyan válthat át és válthat vissza, és hogyan döntheti el, hogy mikor váltson a replikált munkaterületek között.
Az alábbi videó gyors áttekintést nyújt a Log Analytics-munkaterület replikációjának működéséről:
Fontos
Bár néha a feladatátvétel kifejezést használjuk, például az API-hívásban, a feladatátvételt gyakran használják az automatikus folyamat leírására is. Ezért ez a cikk a váltás kifejezéssel hangsúlyozza, hogy a replikált munkaterületre történő váltás manuálisan aktiválható művelet.
A szükséges engedélyek
| Művelet | A szükséges engedélyek |
|---|---|
| Munkaterület-replikáció engedélyezése | Microsoft.OperationalInsights/workspaces/writeés Microsoft.Insights/dataCollectionEndpoints/write a monitorozási közreműködő beépített szerepköre által biztosított engedélyeket, például |
| Váltás és visszaváltás (feladatátvétel és feladat-visszavétel aktiválása) | Microsoft.OperationalInsights/locations/workspaces/failover, Microsoft.OperationalInsights/workspaces/failbackés Microsoft.Insights/dataCollectionEndpoints/triggerFailover/action a monitorozási közreműködő beépített szerepköre által biztosított engedélyeket, például |
| Munkaterület állapotának ellenőrzése | Microsoft.OperationalInsights/workspaces/reada Log Analytics-munkaterületre vonatkozó engedélyek, például a Monitorozási közreműködő beépített szerepköre |
A naplóelemzési munkaterület replikációjának működése
Az eredeti munkaterületet és régiót elsődlegesnek nevezzük. A replikált munkaterületet és a másodlagos régiót másodlagosnak nevezzük.
A munkaterület replikációs folyamata létrehozza a munkaterület egy példányát a másodlagos régióban. A folyamat az elsődleges munkaterületével megegyező konfigurációval hozza létre a másodlagos munkaterületet, az Azure Monitor pedig automatikusan frissíti a másodlagos munkaterületet az elsődleges munkaterület konfigurációjának jövőbeli módosításaival.
A másodlagos munkaterület "árnyék" munkaterület csak rugalmassági célokra. A másodlagos munkaterület nem látható az Azure Portalon, és nem kezelheti vagy nem érheti el közvetlenül.
A munkaterület replikációjának engedélyezésekor az Azure Monitor új naplókat küld az elsődleges munkaterületre a másodlagos régióba is. A rendszer nem másolja át a munkaterületre a munkaterület replikációjának engedélyezése előtt betöltött naplókat.
Ha egy kimaradás hatással van az elsődleges régióra, átállíthatja és átirányíthatja az összes betöltési és lekérdezési kérést a másodlagos régióba. Miután az Azure enyhíti a leállást, és az elsődleges munkaterület ismét kifogástalan állapotban van, átválthat az elsődleges régióra.
Váltáskor a másodlagos munkaterület aktívvá válik, és az elsődleges inaktívvá válik. Az Azure Monitor ezután az elsődleges régió helyett a másodlagos régióban lévő betöltési folyamaton keresztül betölti az új adatokat. Amikor a másodlagos régióra vált, az Azure Monitor a másodlagos régióból az elsődleges régióba betöltendő összes adatot replikálja. A folyamat aszinkron, és nem befolyásolja a betöltési késést.
Fontos
Miután átvált a másodlagos régióra, ha az elsődleges régió nem tudja feldolgozni a bejövő naplóadatokat, az Azure Monitor legfeljebb 11 napig puffereli az adatokat a másodlagos régióban. Az első négy napban az Azure Monitor automatikusan újra megismétli az adatokat, hogy rendszeresen replikálja az adatokat.
Támogatott régiók
A munkaterületek replikációja jelenleg korlátozott számú régióban támogatott, régiócsoportok (földrajzilag szomszédos régiók csoportjai) szerint rendezve. A replikáció engedélyezésekor válasszon egy másodlagos helyet a támogatott régiók listájából, ugyanabban a régiócsoportban, mint a munkaterület elsődleges helye. Egy nyugat-európai munkaterület például replikálható Észak-Európában, az USA 2. nyugati régiójában azonban nem, mivel ezek a régiók különböző régiócsoportokban találhatók.
Ezek a régiócsoportok és régiók jelenleg támogatottak:
| Régiócsoport | Régiók | Jegyzetek |
|---|---|---|
| Észak-Amerika | USA keleti régiója | A replikáció nem támogatott az USA 2. keleti régiójába vagy onnan. |
| USA 2. keleti régiója | A replikáció nem támogatott az USA keleti régiójába vagy onnan. | |
| USA nyugati régiója | ||
| USA 2. nyugati régiója | ||
| Az USA középső régiója | ||
| USA déli középső régiója | ||
| Közép-Kanada | ||
| Európa | Nyugat-Európa | |
| Észak-Európa | ||
| Dél-Uk | ||
| Nyugat-Uk | ||
| Középnyugat-Németország | ||
| Közép-Franciaország |
Adattárolási követelmények
A különböző ügyfelek eltérő adattárolási követelményekkel rendelkeznek, ezért fontos szabályozni az adatok tárolásának helyét. Az Azure Monitor a kiválasztott elsődleges és másodlagos régiókban dolgozza fel és tárolja a naplókat. További információ: Támogatott régiók.
A Sentinel és más szolgáltatások támogatása
A Log Analytics-munkaterületeket használó különböző szolgáltatások és szolgáltatások kompatibilisek a munkaterület replikációjával és az átállással. Ezek a szolgáltatások és szolgáltatások továbbra is működnek, amikor a másodlagos munkaterületre vált.
A naplóbetöltés késését okozó regionális hálózati problémák például hatással lehetnek a Sentinel ügyfeleire. A replikált munkaterületeket használó ügyfelek áttérhetnek a másodlagos régiójukra, hogy továbbra is működjenek a Log Analytics-munkaterületükkel és a Sentinellel. Ha azonban a hálózati probléma hatással van a Sentinel szolgáltatás állapotára, a másik régióra való váltás nem csökkenti a problémát.
Egyes Azure Monitor-szolgáltatások, például az Application Insights és a VM Insights jelenleg csak részben kompatibilisek a munkaterület replikációjával és az átállással. A teljes listát a Korlátozások és korlátozások című témakörben találja.
Munkaterület-replikáció engedélyezése és letiltása
A munkaterület-replikációt REST-paranccsal engedélyezheti és tilthatja le. A parancs egy hosszú ideig futó műveletet aktivál, ami azt jelenti, hogy az új beállítások alkalmazása eltarthat néhány percig. A replikáció engedélyezése után akár egy órát is igénybe vehet, amíg az összes tábla (adattípus) elkezdi a replikálást, és egyes adattípusok elkezdhetnek replikálni mások előtt. A munkaterület-replikáció engedélyezése után a táblázatsémákon végzett módosítások – például új egyéni naplótáblák vagy létrehozott egyéni mezők, vagy új erőforrástípusokhoz beállított diagnosztikai naplók – akár egy órát is igénybe vehet a replikálás megkezdéséhez.
Fontos
A dedikált fürthöz társított Log Analytics-munkaterületek replikálása jelenleg nem támogatott.
Munkaterület-replikáció engedélyezése
Ha engedélyezni szeretné a replikációt a Log Analytics-munkaterületen, használja ezt a PUT parancsot:
PUT
https://management.azure.com/subscriptions/<subscription_id>/resourcegroups/<resourcegroup_name>/providers/microsoft.operationalinsights/workspaces/<workspace_name>?api-version=2023-01-01-preview
body:
{
"properties": {
"replication": {
"enabled": true,
"location": "<secondary_region>"
}
},
"location": "<primary_region>"
}
Ahol:
<subscription_id>: A munkaterülethez kapcsolódó előfizetés-azonosító.<resourcegroup_name>: A Log Analytics-munkaterület erőforrását tartalmazó erőforráscsoport.<workspace_name>: A munkaterület neve.<primary_region>: A Log Analytics-munkaterület elsődleges régiója.<secondary_region>: Az a régió, amelyben az Azure Monitor létrehozza a másodlagos munkaterületet.
A támogatott location értékekért lásd : Támogatott régiók.
A PUT parancs egy hosszú ideig futó művelet, amely eltarthat egy ideig. A sikeres hívás egy állapotkódot ad 200 vissza. Nyomon követheti a kérés kiépítési állapotát a Kérések kiépítési állapotának ellenőrzése című szakaszban leírtak szerint.
Kérelem kiépítési állapotának ellenőrzése
A kérés kiépítési állapotának ellenőrzéséhez futtassa ezt a GET parancsot:
GET
https://management.azure.com/subscriptions/<subscription_id>/resourceGroups/<resourcegroup_name>/providers/Microsoft.OperationalInsights/workspaces/<workspace_name>?api-version=2023-01-01-preview
Ahol:
<subscription_id>: A munkaterülethez kapcsolódó előfizetés-azonosító.<resourcegroup_name>: A Log Analytics-munkaterület erőforrását tartalmazó erőforráscsoport.<workspace_name>: A Log Analytics-munkaterület neve.
GET A paranccsal ellenőrizze, hogy a munkaterület kiépítési állapota a várt módon változik-e Updating Succeeded, és hogy a másodlagos régió a várt módon van-e beállítva.
Feljegyzés
Ha engedélyezi a replikációt a Sentinellel kommunikáló munkaterületeken, akár 12 napig is eltarthat, amíg a Watchlist és a Threat Intelligence adatait teljes mértékben replikálja a másodlagos munkaterületre.
Adatgyűjtési szabályok társítása a rendszer adatgyűjtési végpontjával
Az adatgyűjtési szabályok (DCR) használatával naplóadatokat gyűjthet az Azure Monitor Agent és a Logs Ingestion API használatával.
Ha olyan adatgyűjtési szabályokkal rendelkezik, amelyek adatokat küldenek az elsődleges munkaterületre, a szabályokat egy rendszeradat-gyűjtési végponthoz (DCE) kell társítania, amelyet az Azure Monitor hoz létre a munkaterület replikációjának engedélyezésekor. A rendszeradat-gyűjtési végpont neve megegyezik a munkaterület azonosítójával. Csak a munkaterület rendszeradat-gyűjtési végponthoz társított adatgyűjtési szabályok engedélyezik a replikációt és az átállást. Ez a viselkedés lehetővé teszi a replikálni kívánt naplóstreamek készletének megadását, ami segít szabályozni a replikációs költségeket.
Az adatgyűjtési szabályok használatával gyűjtött adatok replikálásához társítsa az adatgyűjtési szabályokat a Log Analytics-munkaterület rendszeradat-gyűjtési végpontjához:
Az Azure Portalon válassza az Adatgyűjtési szabályokat.
Az Adatgyűjtési szabályok képernyőn válasszon ki egy adatgyűjtési szabályt, amely adatokat küld az elsődleges Log Analytics-munkaterületre.
Az adatgyűjtési szabály áttekintési lapján válassza a DCE konfigurálása lehetőséget, és válassza ki a rendszeradat-gyűjtési végpontot az elérhető listából:
A rendszer DCE-jének részleteiért tekintse meg a munkaterület objektumtulajdonságokat.
Fontos
A munkaterület rendszeradat-gyűjtési végpontjaihoz kapcsolódó adatgyűjtési szabályok csak az adott munkaterületet célozhatják meg. Az adatgyűjtési szabályok nem célozhatók meg más célhelyeket, például más munkaterületeket vagy Azure Storage-fiókokat.
Munkaterület-replikáció letiltása
A munkaterület replikációjának letiltásához használja ezt a PUT parancsot:
PUT
https://management.azure.com/subscriptions/<subscription_id>/resourcegroups/<resourcegroup_name>/providers/microsoft.operationalinsights/workspaces/<workspace_name>?api-version=2023-01-01-preview
body:
{
"properties": {
"replication": {
"enabled": false
}
},
"location": "<primary_region>"
}
Ahol:
<subscription_id>: A munkaterülethez kapcsolódó előfizetés-azonosító.<resourcegroup_name>: A munkaterület erőforrását tartalmazó erőforráscsoport.<workspace_name>: A munkaterület neve.<primary_region>: A munkaterület elsődleges régiója.
A PUT parancs egy hosszú ideig futó művelet, amely eltarthat egy ideig. A sikeres hívás egy állapotkódot ad 200 vissza. Nyomon követheti a kérés kiépítési állapotát a Kérések kiépítési állapotának ellenőrzése című szakaszban leírtak szerint.
Munkaterület és szolgáltatás állapotának figyelése
A betöltési késés vagy a lekérdezési hibák olyan problémák, amelyek gyakran kezelhetők a másodlagos régióba történő feladatátvétellel. Ezek a problémák Service Health-értesítések és napló lekérdezések használatával észlelhetők.
A Szolgáltatásállapot-értesítések szolgáltatással kapcsolatos problémák esetén hasznosak. Az adott munkaterületet (és valószínűleg nem a teljes szolgáltatást) érintő problémák azonosításához más mértékeket is használhat:
- Riasztások létrehozása a munkaterület erőforrás-állapota alapján
- Saját küszöbértékek beállítása a munkaterület állapotmetrikáihoz
- Saját monitorozási lekérdezéseket hozhat létre, amelyek egyéni állapotjelzőkként szolgálnak a munkaterülethez a munkaterület teljesítményének lekérdezésekkel történő figyelésében a következőkhöz:
- A betöltési késés mérése táblánként
- Annak azonosítása, hogy a késés forrása a gyűjteményügynökök vagy a betöltési folyamat
- A betöltési kötet rendellenességeinek figyelése táblánként és erőforrásonként
- Lekérdezések sikerességi arányának figyelése táblánként, felhasználónként vagy erőforrásonként
- Riasztások létrehozása a lekérdezések alapján
Feljegyzés
Napló lekérdezésekkel is monitorozhatja a másodlagos munkaterületet, de ne feledje, hogy a naplók replikációja kötegelt műveletekben történik. A mért késés ingadozhat, és nem jelez semmilyen állapotproblémát a másodlagos munkaterületen. További információ: Az inaktív munkaterület naplózása.
Átváltás a másodlagos munkaterületre
Az átállás során a legtöbb művelet ugyanúgy működik, mint az elsődleges munkaterület és régió használatakor. Egyes műveletek viselkedése azonban kissé eltérő, vagy le van tiltva. További információ: Korlátozások és korlátozások.
Mikor váltsak át?
Ön dönti el, hogy mikor vált át a másodlagos munkaterületre, és a folyamatos teljesítmény- és állapotfigyelés, valamint a rendszerszabványok és követelmények alapján váltson vissza az elsődleges munkaterületre.
Az átállási tervben több szempontot is figyelembe kell venni, az alábbi alszakaszokban leírtak szerint.
Probléma típusa és hatóköre
Az átállási folyamat a betöltési és lekérdezési kérelmeket a másodlagos régióba irányítja, amely általában átmegy minden olyan hibás összetevőn, amely késést vagy hibát okoz az elsődleges régióban. Ennek eredményeképpen az átállás nem valószínű, hogy segít, ha:
- Egy mögöttes erőforrás régiók közötti problémája van. Ha például ugyanazok az erőforrástípusok az elsődleges és a másodlagos régióban is meghiúsulnak.
- A munkaterület-kezeléssel kapcsolatos problémákat tapasztal, például a munkaterület megőrzésének módosítását. A munkaterület-kezelési műveleteket mindig az elsődleges régióban kezeli a rendszer. Az átállás során a munkaterület-kezelési műveletek le lesznek tiltva.
A probléma időtartama
Az átállás nem azonnali. A kérések átirányításának folyamata a DNS-frissítésekre támaszkodik, amelyeket egyes ügyfelek perceken belül felvesznek, míg mások több időt is igénybe vehetnek. Ezért hasznos megérteni, hogy a probléma néhány percen belül megoldható-e. Ha a megfigyelt probléma konzisztens vagy folyamatos, ne várjon a váltásra. Íme néhány példa:
Betöltés: Az elsődleges régióban a betöltési folyamattal kapcsolatos problémák hatással lehetnek a másodlagos munkaterületre irányuló adatreplikálásra. Az átállás során a rendszer ehelyett elküldi a naplókat a másodlagos régió betöltési folyamatának.
Lekérdezés: Ha az elsődleges munkaterületen lévő lekérdezések meghiúsulnak vagy időtúllépést eredményeznek, a naplókeresési riasztások hatással lehetnek. Ebben az esetben váltson át a másodlagos munkaterületre, hogy az összes riasztás megfelelően aktiválódjon.
Másodlagos munkaterület adatai
A replikáció engedélyezése előtt az elsődleges munkaterületre betöltött naplók nem lesznek átmásolva a másodlagos munkaterületre. Ha három órával ezelőtt engedélyezte a munkaterület replikációját, és most átvált a másodlagos munkaterületre, a lekérdezések csak az elmúlt három órából tudnak adatokat visszaadni.
A régiók váltása előtt a másodlagos munkaterületnek hasznos mennyiségű naplót kell tartalmaznia. Javasoljuk, hogy az átállás aktiválása előtt legalább egy héttel várja meg a replikáció engedélyezését. A hét nap lehetővé teszi, hogy elegendő adat legyen elérhető a másodlagos régióban.
Eseményindító váltása
A váltás előtt győződjön meg arról, hogy a munkaterület replikációs művelete sikeresen befejeződött. Az átállás csak akkor sikeres, ha a másodlagos munkaterület megfelelően van konfigurálva.
A másodlagos munkaterületre való váltáshoz használja ezt a POST parancsot:
POST
https://management.azure.com/subscriptions/<subscription_id>/resourceGroups/<resourcegroup_name>/providers/Microsoft.OperationalInsights/locations/<secondary_region>/workspaces/<workspace_name>/failover?api-version=2023-01-01-preview
Ahol:
<subscription_id>: A munkaterülethez kapcsolódó előfizetés-azonosító.<resourcegroup_name>: A munkaterület erőforrását tartalmazó erőforráscsoport.<secondary_region>: Az átállás során átváltani kívánt régió.<workspace_name>: Annak a munkaterületnek a neve, amelyre váltáskor váltani szeretne.
A POST parancs egy hosszú ideig futó művelet, amely eltarthat egy ideig. A sikeres hívás egy állapotkódot ad 202 vissza. Nyomon követheti a kérés kiépítési állapotát a Kérések kiépítési állapotának ellenőrzése című szakaszban leírtak szerint.
Visszaváltás az elsődleges munkaterületre
A visszaváltási folyamat megszakítja a lekérdezések és naplóbetöltési kérelmek átirányítását a másodlagos munkaterületre. Amikor visszaáll, az Azure Monitor visszaáll az útválasztási lekérdezésekre és a naplóbetöltési kérelmekre az elsődleges munkaterületre.
Amikor a másodlagos régióra vált, az Azure Monitor replikálja a naplókat a másodlagos munkaterületről az elsődleges munkaterületre. Ha egy üzemkimaradás hatással van a naplóbetöltési folyamatra az elsődleges régióban, időbe telhet, amíg az Azure Monitor végrehajtja a replikált naplók betöltését az elsődleges munkaterületre.
Mikor érdemes visszakapcsolnom?
A visszaváltási tervben több szempontot is figyelembe kell venni, az alábbi alszakaszokban leírtak szerint.
Naplóreplikációs állapot
A visszaváltás előtt ellenőrizze, hogy az Azure Monitor befejezte-e az elsődleges régióra való váltás során betöltött összes napló replikálását. Ha az összes napló az elsődleges munkaterületre való replikálása előtt vált vissza, előfordulhat, hogy a lekérdezések részleges eredményeket adnak vissza, amíg a naplóbetöltés befejeződik.
Az inaktív régióhoz tartozó elsődleges munkaterületet az Azure Portalon kérdezheti le, az inaktív munkaterület naplózása című szakaszban leírtak szerint.
Elsődleges munkaterület állapota
Két fontos állapotelemet kell ellenőriznie az elsődleges munkaterületre való visszaváltás előkészítéséhez:
- Győződjön meg arról, hogy az elsődleges munkaterületre és régióra vonatkozóan nincsenek függőben lévő Service Health-értesítések.
- Győződjön meg arról, hogy az elsődleges munkaterület a naplókat betölti és a lekérdezéseket a várt módon dolgozza fel.
Ha például lekérdezi az elsődleges munkaterületet, amikor a másodlagos munkaterület aktív, és megkerüli a kérések átirányítását a másodlagos munkaterületre, olvassa el az inaktív munkaterület naplózása című témakört.
Trigger visszaváltása
A visszaváltás előtt ellenőrizze az elsődleges munkaterület állapotát és a naplók teljes replikációját.
A visszaváltási folyamat frissíti a DNS-rekordokat. A DNS-rekordok frissítése után az összes ügyfél megkapja a frissített DNS-beállításokat, és folytathatja az útválasztást az elsődleges munkaterületre.
Az elsődleges munkaterületre való visszaváltáshoz használja ezt a POST parancsot:
POST
https://management.azure.com/subscriptions/<subscription_id>/resourceGroups/<resourcegroup_name>/providers/Microsoft.OperationalInsights/workspaces/<workspace_name>/failback?api-version=2023-01-01-preview
Ahol:
<subscription_id>: A munkaterülethez kapcsolódó előfizetés-azonosító.<resourcegroup_name>: A munkaterület erőforrását tartalmazó erőforráscsoport.<workspace_name>: Annak a munkaterületnek a neve, amelyre váltáskor váltani szeretne.
A POST parancs egy hosszú ideig futó művelet, amely eltarthat egy ideig. A sikeres hívás egy állapotkódot ad 202 vissza. Nyomon követheti a kérés kiépítési állapotát a Kérések kiépítési állapotának ellenőrzése című szakaszban leírtak szerint.
Az inaktív munkaterület naplózása
Alapértelmezés szerint a munkaterület aktív régiója az a régió, ahol létrehozza a munkaterületet, az inaktív régió pedig a másodlagos régió, ahol az Azure Monitor létrehozza a replikált munkaterületet.
A feladatátvétel aktiválásakor ez átvált – a másodlagos régió aktiválódik, és az elsődleges régió inaktívvá válik. Azt mondjuk, hogy inaktív, mert nem a naplóbetöltés és a lekérdezési kérelmek közvetlen célja.
Hasznos, ha lekérdezi az inaktív régiót, mielőtt régiók között vált, hogy ellenőrizze, hogy az inaktív régió munkaterülete rendelkezik-e az ott látható naplókkal.
Inaktív régió lekérdezése
Az inaktív régió naplóadatainak lekérdezéséhez használja ezt a GET parancsot:
GET
api.loganalytics.azure.com/v1/workspaces/<workspace id>/query?query=<query>×pan=<timespan-in-ISO8601-format>&overrideWorkspaceRegion=<primary|secondary>
Ha például egy egyszerű lekérdezést szeretne futtatni a másodlagos régióban az elmúlt naphoz hasonlóan Perf | count , használja a következőt:
GET
api.loganalytics.azure.com/v1/workspaces/<workspace id>/query?query=Perf%20|%20count×pan=P1D&overrideWorkspaceRegion=secondary
Ellenőrizheti, hogy az Azure Monitor a kívánt régióban futtatja-e a lekérdezést a tábla ezen mezőinek LAQueryLogs ellenőrzésével, amely akkor jön létre, amikor engedélyezi a lekérdezések naplózását a Log Analytics-munkaterületen:
isWorkspaceInFailover: Azt jelzi, hogy a munkaterület váltási módban volt-e a lekérdezés során. Az adattípus logikai (Igaz, Hamis).workspaceRegion: A lekérdezés által megcélzott munkaterület régiója. Az adattípus sztring.
Munkaterület teljesítményének figyelése lekérdezésekkel
Javasoljuk, hogy az ebben a szakaszban található lekérdezésekkel hozzon létre riasztási szabályokat, amelyek értesítik a munkaterület esetleges állapotával vagy teljesítményével kapcsolatos problémákról. Az átálláshoz azonban körültekintően kell eljárni, és nem szabad automatikusan elvégezni.
A lekérdezési szabályban megadhatja azt a feltételt, amely adott számú szabálysértés után átvált a másodlagos munkaterületre. További információ: Naplókeresési riasztási szabály létrehozása vagy szerkesztése.
A munkaterület teljesítményének két jelentős mérése a betöltési késés és a betöltési kötet. A következő szakaszok ezeket a figyelési lehetőségeket ismertetik.
A végpontok közötti betöltési késés monitorozása
A betöltési késés a naplók munkaterületre való betöltéséhez szükséges időt méri. Az időmérés akkor kezdődik, amikor a kezdeti naplózott esemény bekövetkezik, és a napló a munkaterületen való tárolásakor ér véget. A teljes betöltési késés két részből áll:
- Ügynök késése: Az ügynök által az esemény jelentéséhez szükséges idő.
- Betöltési folyamat (háttérrendszer) késése: A betöltési folyamatnak a naplók feldolgozásához és a munkaterületre való írásához szükséges idő.
A különböző adattípusok eltérő betöltési késéssel rendelkeznek. Az egyes adattípusok betöltését külön-külön mérheti meg, vagy létrehozhat egy általános lekérdezést minden típushoz, valamint egy részletesebb lekérdezést az ön számára nagyobb jelentőséggel bíró bizonyos típusokhoz. Javasoljuk, hogy mérje meg a betöltési késés 90. percentilisét, amely érzékenyebb a változásra, mint az átlag vagy az 50. percentilis (medián).
Az alábbi szakaszok bemutatják, hogyan lehet lekérdezésekkel ellenőrizni a munkaterület betöltési késését.
Adott táblák alapkonfigurációs betöltési késésének kiértékelése
Először határozza meg az adott táblák több napon keresztüli alapkésését.
Ez a példa lekérdezés létrehoz egy diagramot a betöltési késés 90. percentiliséről a Perf táblában:
// Assess the ingestion latency baseline for a specific data type
Perf
| where TimeGenerated > ago(3d)
| project TimeGenerated,
IngestionDurationSeconds = (ingestion_time()-TimeGenerated)/1s
| summarize LatencyIngestion90Percentile=percentile(IngestionDurationSeconds, 90) by bin(TimeGenerated, 1h)
| render timechart
A lekérdezés futtatása után tekintse át az eredményeket és a renderelt diagramot a tábla várható késésének meghatározásához.
Figyelés és riasztás az aktuális betöltési késésről
Miután meghatározta egy adott tábla alapkonfigurációs betöltési késését, hozzon létre egy naplókeresési riasztási szabályt a táblához a késés rövid időn belüli változásai alapján.
Ez a lekérdezés kiszámítja a betöltési késést az elmúlt 20 percben:
// Track the recent ingestion latency (in seconds) of a specific table
Perf
| where TimeGenerated > ago(20m)
| extend IngestionDurationSeconds = (ingestion_time()-TimeGenerated)/1s
| summarize Ingestion90Percent_seconds=percentile(IngestionDurationSeconds, 90)
Mivel némi ingadozásra számíthat, hozzon létre egy riasztási szabályfeltételt, amely ellenőrzi, hogy a lekérdezés az alaptervnél lényegesen nagyobb értéket ad-e vissza.
A betöltési késés forrásának meghatározása
Amikor a teljes betöltési késést észleli, lekérdezésekkel megállapíthatja, hogy a késés forrása az ügynökök vagy a betöltési folyamat.
Ez a lekérdezés az ügynökök és a folyamat 90. percentilis késését külön diagramon ábrázolja:
// Assess agent and pipeline (backend) latency
Perf
| where TimeGenerated > ago(1h)
| extend AgentLatencySeconds = (_TimeReceived-TimeGenerated)/1s,
PipelineLatencySeconds=(ingestion_time()-_TimeReceived)/1s
| summarize percentile(AgentLatencySeconds,90), percentile(PipelineLatencySeconds,90) by bin(TimeGenerated,5m)
| render columnchart
Feljegyzés
Bár a diagram halmozott oszlopként jeleníti meg a 90. percentilisadatokat, a két diagram adatainak összege nem egyenlő a teljes betöltési 90. percentilisével.
Betöltési kötet figyelése
A betöltési kötet mérései segíthetnek azonosítani a munkaterület teljes vagy táblázatspecifikus betöltési kötetének váratlan változásait. A lekérdezési kötet mérései segíthetnek azonosítani a naplóbetöltés teljesítményproblémáit. Néhány hasznos kötetmérés:
- Teljes betöltési kötet táblánként
- Állandó betöltési kötet (álló)
- Betöltési anomáliák – tüskék és visszaesések a betöltési kötetben
Az alábbi szakaszok bemutatják, hogyan használhat lekérdezéseket a munkaterület betöltési kötetének ellenőrzéséhez.
Teljes betöltési kötet figyelése táblánként
Megadhat egy lekérdezést a munkaterület táblánkénti betöltési kötetének figyeléséhez. A lekérdezés tartalmazhat egy riasztást, amely ellenőrzi a teljes vagy táblaspecifikus kötetek váratlan változásait.
Ez a lekérdezés kiszámítja a teljes betöltési kötetet az elmúlt egy órában táblánként megabájt/másodpercben (MB):
// Calculate total ingestion volume over the past hour per table
Usage
| where TimeGenerated > ago(1h)
| summarize BillableDataMB = sum(_BilledSize)/1.E6 by bin(TimeGenerated,1h), DataType
A betöltési leállási állapot ellenőrzése
Ha a naplókat ügynökökön keresztül használja, az ügynök szívverésével észlelheti a kapcsolatot. A még mindig szívverések a munkaterület naplóbetöltésének leállását okozhatják. Amikor a lekérdezési adatok betöltési leállást mutatnak, meghatározhat egy feltételt a kívánt válasz aktiválásához.
A következő lekérdezés ellenőrzi az ügynök szívverését a csatlakozási problémák észleléséhez:
// Count agent heartbeats in the last ten minutes
Heartbeat
| where TimeGenerated>ago(10m)
| count
Betöltési anomáliák monitorozása
A munkaterület betöltési kötetadataiban különböző módokon azonosíthatja a kiugró értékeket és a kiugró értékeket. A series_decompose_anomalies() függvénnyel a rendellenességek kinyerhetők a munkaterületen figyelt betöltési kötetekből, vagy létrehozhat saját anomáliadetektort az egyedi munkaterületi forgatókönyvek támogatásához.
A rendellenességek azonosítása series_decompose_anomalies használatával
A series_decompose_anomalies() függvény adatértékek sorozatában azonosítja az anomáliákat. Ez a lekérdezés kiszámítja a Log Analytics-munkaterület egyes tábláinak óránkénti betöltési mennyiségét, és az anomáliák azonosítására használja series_decompose_anomalies() :
// Calculate hourly ingestion volume per table and identify anomalies
Usage
| where TimeGenerated > ago(24h)
| project TimeGenerated, DataType, Quantity
| summarize IngestionVolumeMB=sum(Quantity) by bin(TimeGenerated, 1h), DataType
| summarize
Timestamp=make_list(TimeGenerated),
IngestionVolumeMB=make_list(IngestionVolumeMB)
by DataType
| extend series_decompose_anomalies(IngestionVolumeMB)
| mv-expand
Timestamp,
IngestionVolumeMB,
series_decompose_anomalies_IngestionVolumeMB_ad_flag,
series_decompose_anomalies_IngestionVolumeMB_ad_score,
series_decompose_anomalies_IngestionVolumeMB_baseline
| where series_decompose_anomalies_IngestionVolumeMB_ad_flag != 0
További információ a series_decompose_anomalies() naplóadatok rendellenességeinek észleléséről: A rendellenességek észlelése és elemzése KQL gépi tanulási képességekkel az Azure Monitorban.
Saját anomáliadetektor létrehozása
Létrehozhat egy egyéni anomáliadetektort, amely támogatja a munkaterület konfigurációjának forgatókönyv-követelményeit. Ez a szakasz egy példa a folyamat bemutatására.
A következő lekérdezés kiszámítja:
- Várt betöltési mennyiség: Óránként, táblázat szerint (a mediánok mediánja alapján, de testre szabhatja a logikát)
- Tényleges betöltési mennyiség: Óránként, táblázat szerint
A várt és a tényleges betöltési kötet közötti jelentéktelen különbségek kiszűréséhez a lekérdezés két szűrőt alkalmaz:
- Változási arány: A várt mennyiség több mint 150%-a vagy 66%-a alatt, táblázatonként
- Változás mennyisége: Azt jelzi, hogy a megnövekedett vagy csökkent kötet meghaladja-e a tábla havi mennyiségének 0,1%-át
// Calculate expected vs actual hourly ingestion per table
let TimeRange=24h;
let MonthlyIngestionByType=
Usage
| where TimeGenerated > ago(30d)
| summarize MonthlyIngestionMB=sum(Quantity) by DataType;
// Calculate the expected ingestion volume by median of hourly medians
let ExpectedIngestionVolumeByType=
Usage
| where TimeGenerated > ago(TimeRange)
| project TimeGenerated, DataType, Quantity
| summarize IngestionMedian=percentile(Quantity, 50) by bin(TimeGenerated, 1h), DataType
| summarize ExpectedIngestionVolumeMB=percentile(IngestionMedian, 50) by DataType;
Usage
| where TimeGenerated > ago(TimeRange)
| project TimeGenerated, DataType, Quantity
| summarize IngestionVolumeMB=sum(Quantity) by bin(TimeGenerated, 1h), DataType
| join kind=inner (ExpectedIngestionVolumeByType) on DataType
| extend GapVolumeMB = round(IngestionVolumeMB-ExpectedIngestionVolumeMB,2)
| where GapVolumeMB != 0
| extend Trend=iff(GapVolumeMB > 0, "Up", "Down")
| extend IngestedVsExpectedAsPercent = round(IngestionVolumeMB * 100 / ExpectedIngestionVolumeMB, 2)
| join kind=inner (MonthlyIngestionByType) on DataType
| extend GapAsPercentOfMonthlyIngestion = round(abs(GapVolumeMB) * 100 / MonthlyIngestionMB, 2)
| project-away DataType1, DataType2
// Determine whether the spike/deep is substantial: over 150% or under 66% of the expected volume for this data type
| where IngestedVsExpectedAsPercent > 150 or IngestedVsExpectedAsPercent < 66
// Determine whether the gap volume is significant: over 0.1% of the total monthly ingestion volume to this workspace
| where GapAsPercentOfMonthlyIngestion > 0.1
| project
Timestamp=format_datetime(todatetime(TimeGenerated), 'yyyy-MM-dd HH:mm:ss'),
Trend,
IngestionVolumeMB,
ExpectedIngestionVolumeMB,
IngestedVsExpectedAsPercent,
GapAsPercentOfMonthlyIngestion
A lekérdezés sikerességének és sikertelenségének monitorozása
Minden lekérdezés egy sikeres vagy sikertelen válaszkódot ad vissza. Ha a lekérdezés sikertelen, a válasz a hibatípusokat is tartalmazza. A hibák nagy száma a munkaterület rendelkezésre állásával vagy a szolgáltatás teljesítményével kapcsolatos problémát jelezhet.
Ez a lekérdezés megszámolja, hogy hány lekérdezés adott vissza kiszolgálói hibakódot:
// Count query errors
LAQueryLogs
| where ResponseCode>=500 and ResponseCode<600
| count
Korlátozások
A dedikált fürthöz társított Log Analytics-munkaterületek replikálása jelenleg nem támogatott.
A törlési művelet, amely rekordokat töröl egy munkaterületről, eltávolítja a releváns rekordokat az elsődleges és a másodlagos munkaterületről is. Ha a munkaterület egyik példánya nem érhető el, a törlési művelet meghiúsul.
A riasztási szabályok régiók közötti replikálása jelenleg nem támogatott. Mivel az Azure Monitor támogatja az inaktív régió lekérdezését, a lekérdezésalapú riasztások továbbra is működnek a régiók közötti váltáskor, kivéve, ha az aktív régió riasztási szolgáltatása nem működik megfelelően, vagy a riasztási szabályok nem érhetők el.
Ha engedélyezi a replikációt a Sentinellel kommunikáló munkaterületeken, akár 12 napig is eltarthat, amíg a Watchlist és a Threat Intelligence adatait teljes mértékben replikálja a másodlagos munkaterületre.
Az átállás során a munkaterület-felügyeleti műveletek nem támogatottak, beleértve a következőket:
- Munkaterület-megőrzés, tarifacsomag, napi korlát stb. módosítása
- Hálózati beállítások módosítása
- Séma módosítása új egyéni naplókkal vagy új erőforrás-szolgáltatók platformnaplóinak összekapcsolásával, például diagnosztikai naplók küldése új erőforrástípusból
Az örökölt Log Analytics-ügynök megoldásmegcélzási képessége az átállás során nem támogatott. Ezért az átállás során a megoldásadatok minden ügynöktől be lesznek építve.
A feladatátvételi folyamat frissíti a tartománynévrendszer (DNS) rekordjait, hogy az összes betöltési kérést átirányíthassa a másodlagos régióba feldolgozás céljából. Egyes HTTP-ügyfelek "ragadós kapcsolatokkal" rendelkeznek, és hosszabb időt is igénybe vehet a DNS frissített DNS-ének átvétele. Az átállás során előfordulhat, hogy ezek az ügyfelek egy ideig megpróbálják beszedni a naplókat az elsődleges régión keresztül. Előfordulhat, hogy a naplókat különböző ügyfelekkel, például az örökölt Log Analytics-ügynökkel, az Azure Monitor-ügynökkel, a kóddal (a Logs Ingestion API-val vagy az örökölt HTTP-adatgyűjtési API-val) és más szolgáltatásokkal, például a Sentinelrel betölti.
Ezek a funkciók jelenleg nem támogatottak, vagy csak részben támogatottak:
Szolgáltatás Támogatás Kiegészítő táblatervek Nem támogatott. Az Azure Monitor nem replikál adatokat a táblákban a kiegészítő naplótervvel a másodlagos munkaterületre. Ezért ezek az adatok regionális hiba esetén nem védve lesznek az adatvesztés ellen, és nem érhetők el a másodlagos munkaterületre való váltáskor. Keresési feladatok, visszaállítás Részben támogatott – A keresési feladatok és a visszaállítási műveletek táblákat hoznak létre, és feltöltik őket keresési eredményekkel vagy visszaállított adatokkal. A munkaterület replikációjának engedélyezése után a műveletekhez létrehozott új táblák replikálódnak a másodlagos munkaterületre. A replikáció engedélyezése előtt feltöltött táblák nem lesznek replikálva. Ha ezek a műveletek a váltáskor folyamatban vannak, az eredmény váratlan. A munkaterület állapotától és a pontos időzítéstől függően előfordulhat, hogy sikeresen befejeződik, de nem replikálja, vagy sikertelen lehet. Application Insights a Log Analytics-munkaterületeken Nem támogatott Virtuálisgép-elemzések Nem támogatott Container Insights Nem támogatott Privát kapcsolatok A feladatátvétel során nem támogatott