A rugalmasság növelése a Log Analytics-munkaterület régiók közötti replikálásával

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 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 egy "árnyék" munkaterület, amely csak rugalmassági célokra használható. 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. Azokat a naplókat, amelyeket a munkaterületre helyezel, mielőtt engedélyezed a munkaterület replikációját, nem másolja át a rendszer.

Megjegyzés

A munkaterület-replikáció teljes mértékben replikálja az összes táblasémát, de csak a replikáció aktiválása óta betöltött új naplókat küld. A naplókat, amelyeket a munkaterületen a replikáció engedélyezése előtt töltöttek be, a rendszer nem másolja át.

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 az adatbeviteli késleltetést.

Megjegyzés

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 ismételten próbálja meg replikálni az adatokat.

Az átvitel közbeni adatvesztés elleni védelem regionális hiba esetén

Az Azure Monitor számos mechanizmussal rendelkezik annak biztosítására, hogy az átvitel alatt lévő adatok ne vesszenek el, ha hiba történik az elsődleges régióban.

Az Azure Monitor megvédi azokat az adatokat, amelyek elérik az elsődleges régió betöltési végpontját, amikor az elsődleges régió adatfeldolgozási folyamata nem elérhető. Amikor a folyamat elérhetővé válik, tovább dolgozza fel az átvitel alatt álló adatokat, és az Azure Monitor betölti és replikálja az adatokat a másodlagos régióba.

Ha az elsődleges régió betöltési végpontja nem érhető el, az Azure Monitor Agent rendszeresen újra elküldi a naplóadatokat a végpontnak. A másodlagos régió adatbetöltési végpontja néhány perccel az átállás aktiválása után elkezd adatokat fogadni az ügynököktől.

Ha saját kliensprogramot ír, hogy naplóadatokat küldjön a Log Analytics-munkaterületre, győződjön meg arról, hogy a kliensprogram kezeli a sikertelen adatbeviteli kérelmeket.

Telepítési szempontok

Megjegyzés

A munkaterület-replikáció jelenleg nem támogatja a kiegészítő táblák replikálását, és nem szabad engedélyezni a segédtáblákat tartalmazó munkaterületeken. A segédtáblák nem replikálódnak, ezért regionális hiba esetén nem lesznek védve az adatvesztés ellen, és nem érhetők el a másodlagos munkaterületre való váltáskor.

• A munkaterület-felügyeleti műveletek nem indíthatók el az átállás során, beleértve a következőket:

  • A munkaterület-megőrzés, a tarifacsomag, a napi korlát stb. módosítása
  • A hálózati beállítások módosítása
  • Séma módosítása új egyéni naplókon keresztül, vagy platformnaplók csatlakoztatása új erőforrás-szolgáltatóktól, például diagnosztikai naplók küldése új erőforrástípusból

• 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ítések átvétele. Az átállás során előfordulhat, hogy ezek az ügyfelek egy ideig megpróbálják összegyűjteni a naplókat az elsődleges régiót használva. Előfordulhat, hogy a naplókat az elsődleges munkaterületre különböző ügyfelek használatával továbbítja, beleértve az örökölt Log Analytics-ügynököt, az Azure Monitor-ügynököt, a kódot (a Logs Ingestion API vagy az örökölt HTTP-adatgyűjtési API használatával) és más szolgáltatásokat, például a Microsoft Sentinelt.

Fontos

A naplókeresési riasztási szabályok 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. Ez például akkor fordulhat elő, ha a riasztási szabályok létrehozásának régiója teljesen le van állítva. A riasztási szabályok régiók közötti replikálása nem történik meg automatikusan a munkaterület replikációjának részeként, hanem a felhasználó végezheti el (például az elsődleges régióból való exportálással és a másodlagos régióba való importálással).

• 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 sikertelen lesz.

• A replikált munkaterületek nem törölhetők. Munkaterület megfelelő törléséhez először tiltsa le a replikációt.

• A Microsoft Sentinel a Naplókat 12 naponta frissíti a Figyelőlista és a Fenyegetésintelligencia táblákban. Mivel tehát csak az új naplók vannak betöltve a replikált munkaterületre, akár 12 napig is eltarthat a Watchlist és a Threat Intelligence adatainak teljes replikálása a másodlagos helyre.

• Az örökölt Log Analytics-ügynök megoldásmegcélzási képessége az átállás során nem támogatott. Az átállás során a megoldásadatokat minden ügynöktől beépítik.

• Ezek a funkciók jelenleg nem támogatottak, vagy csak részben támogatottak:

  Funkció	Támogatás
  Kiegészítő táblatervek	Nem támogatott. Az Azure Monitor nem replikálja a Kiegészítő naplóterv alá tartozó táblák adatait 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.
  Az Application Insights a Log Analytics munkaterületeken	Nem támogatott
  Virtuálisgép-elemzések	Nem támogatott
  Konténer Áttekintések	Nem támogatott
  Privát kapcsolatok	Az átkapcsolás során nem támogatott

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	Elsődleges régiók	Másodlagos régiók (replikációs helyek)
Észak-Amerika	Kanada középső régiója Kelet-Kanada Usa középső régiója USA keleti régiója* USA 2. keleti régiója* USA északi középső régiója USA déli középső régiója* USA nyugati középső régiója USA nyugati régiója Nyugat-USA 2 USA 3. nyugati régiója	Kanada középső régiója Usa középső régiója USA keleti régiója* USA 2. keleti régiója* USA nyugati régiója Nyugat-USA 2 USA 3. nyugati régiója
Dél-Amerika	Dél-Brazília Délkelet-Brazília	Dél-Brazília Délkelet-Brazília
Európa	Közép-Franciaország Dél-Franciaország Észak-Németország Németország nyugati középső régiója Észak-Olaszország Észak-Európa Kelet-Norvégia Nyugat-Norvégia Lengyelország középső régiója Dél-Uk Spanyolország középső régiója Svédország középső régiója Dél-Svédország Észak-Svájc Nyugat-Svájc Nyugat-Európa Nyugat-Uk	Közép-Franciaország Németország nyugati középső régiója Észak-Európa Dél-Uk Nyugat-Európa Nyugat-Uk
Közel-Kelet	Qatar Central Egyesült Arab Emírségek központi régiója Egyesült Arab Emírségek északi régiója	Qatar Central Egyesült Arab Emírségek központi régiója Egyesült Arab Emírségek északi régiója
India	Közép-India Jio India középső régiója Jio India nyugati régiója Dél-India	Közép-India Jio India nyugati régiója Dél-India
Ázsia és a Csendes-óceáni térség	Kelet-Ázsia Kelet-Japán Nyugat-Japán Korea középső régiója Dél-Korea Délkelet-Ázsia	Kelet-Ázsia Kelet-Japán Nyugat-Japán Korea középső régiója Délkelet-Ázsia
Óceánia	Ausztrália középső régiója Ausztrália középső régiója 2 Kelet-Ausztrália Délkelet-Ausztrália	Ausztrália középső régiója Kelet-Ausztrália Délkelet-Ausztrália
Afrika	Észak-Afrika déli régiója Dél-Afrika nyugati régiója	Észak-Afrika déli régiója Dél-Afrika nyugati régiója

Megjegyzés

Az USA keleti régiójában, az USA 2. keleti régiójában és az USA déli középső régiójában található munkaterületek csak a három csoporton kívüli másodlagos régiókba replikálhatók. Válasszon egy másik másodlagos helyet az Észak-Amerika régiócsoportból.

Adatrezidencia 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 Microsoft 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 funkciók 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 Microsoft 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 lista az üzembe helyezéssel kapcsolatos szempontokat tartalmazza.

Díjszabási modell

Ha engedélyezi a munkaterület replikációját, a munkaterületre betöltött összes adat replikálásáért díjat kell fizetnie.

Fontos

Ha adatokat küld a munkaterületre az Azure Monitor-ügynök, a Logs Ingestion API, az Azure Event Hubs vagy más, adatgyűjtési szabályokat használó adatforrások használatával, győződjön meg arról, hogy az adatgyűjtési szabályokat a munkaterület adatgyűjtési végpontjához társítja. Ez a társítás biztosítja, hogy a betöltött adatok replikálódjanak a másodlagos munkaterületre. Ha nem társítja az adatgyűjtési szabályokat a munkaterület adatgyűjtési végpontjához, akkor is fizetnie kell a munkaterületre beszedendő összes adatért, annak ellenére, hogy az adatok replikálása nem történik meg.

A szükséges engedélyek

Művelet	A szükséges engedélyek
Munkaterület replikációjának engedélyezése	Microsoft.OperationalInsights/workspaces/write és Microsoft.Insights/dataCollectionEndpoints/write engedélyeket, amelyeket a monitorozási közreműködő beépített szerepköre biztosít, például
Kapcsolás és visszakapcsolás (átviteli- és visszaállási aktiválás)	Microsoft.OperationalInsights/locations/workspaces/failover, Microsoft.OperationalInsights/workspaces/failback, Microsoft.Insights/dataCollectionEndpoints/triggerFailover/action, és Microsoft.Insights/dataCollectionEndpoints/triggerFailback/action engedélyeket, amelyeket a Monitorozási Közreműködő beépített szerepkör biztosít, például
Munkaterület állapotának ellenőrzése	Microsoft.OperationalInsights/workspaces/read a Log Analytics-munkaterület engedélyei, amelyeket a Megfigyelési közreműködő beépített szerepkör biztosít, például

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.

Ön dedikált klasztert használ?

Ha a munkaterület egy dedikált fürthöz van csatolva, először engedélyeznie kell a replikációt a fürtön, és csak ezután a munkaterületen. Ez a művelet létrehoz egy második fürtöt a másodlagos régióban (a replikációs díjakon felüli felár nélkül), hogy a munkaterület továbbra is használhasson dedikált fürtöt, még akkor is, ha átállás történik. Ez azt is jelenti, hogy a fürt által felügyelt kulcsok (CMK) változatlanul működnek (ugyanazzal a kulccsal) a feladatátvétel ideje alatt. Ha engedélyezve van a régiók közötti replikáció, engedélyezze a replikációt egy vagy több, ehhez a fürthöz társított munkaterületen.

Fontos

A fürtreplikálás engedélyezése után a replikációs célhely módosításához le kell tiltani a replikációt, és újra engedélyezni kell azt egy másik helyen.

A saját dedikált fürtöd replikációjának engedélyezéséhez használja a következő PUT parancsot. Ez a hívás a 202-et adja vissza. Ez egy hosszú ideig futó művelet, amelynek befejezése időbe telhet, és pontos állapotát nyomon követheti a Fürt kiépítési állapotának ellenőrzése című témakörben leírtak szerint.

A klaszterreplikáció engedélyezéséhez használja a következő PUT parancsot:

PUT 

https://management.azure.com/subscriptions/<subscription_id>/resourcegroups/<resourcegroup_name>/providers/microsoft.operationalinsights/clusters/<cluster_name>?api-version=2025-02-01

body:
{
    "properties": {
        "replication": {
            "enabled": true,
            "location": "<secondary_region>"
        }
    },
    "location": "<primary_region>"
}

Ahol:

• <subscription_id>: A fürthöz tartozó előfizetés azonosítószáma
• <resourcegroup_name> : Az erőforráscsoport, amely tartalmazza a Log Analytics klaszter erőforrását
• <cluster_name>: A dedikált fürt neve
• <primary_region>: A dedikált Log Analytics-fürt elsődleges régiója
• <secondary_region>: Az a régió, amelyben az Azure Monitor a másodlagos dedikált fürtöt létrehozza

Ellenőrizze a fürt kiépítési állapotát

A fürt kiépítési állapotának ellenőrzéséhez futtassa a következő GET parancsot:

GET

https://management.azure.com/subscriptions/<subscription_id>/resourceGroups/<resourcegroup_name>/providers/Microsoft.OperationalInsights/clusters/<cluster_name>?api-version=2025-02-01

Ahol:

• <subscription_id>: A fürthöz tartozó előfizetés azonosítószáma
• <resourcegroup_name>: A Log Analytics-fürt erőforrását tartalmazó erőforráscsoport
• <cluster_name>: A Log Analytics-fürt neve

GET parancs használatával ellenőrizze, hogy a fürt kiépítési állapota Updating-ről Succeeded-re változik-e, és hogy a másodlagos régió a várakozásoknak megfelelően van-e beállítva.

Megjegyzés

A fürtreplikációs szolgáltatás engedélyezésekor egy új fürt kerül kiépítésre a másodlagos helyen. Ez a folyamat 1-2 órát is igénybe vehet.

Munkaterület replikációjának 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=2025-02-01

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. A kérés kiépítési állapotát nyomon követheti a Munkaterület kiépítési állapotának ellenőrzése című szakaszban leírtak szerint.

Fontos

Ha a munkaterület egy dedikált fürthöz van csatolva, először engedélyezze a replikációt a fürtön. Kérjük, vegye figyelembe, hogy az Ön munkaterületének másodlagos helyének meg kell egyeznie a munkaterület dedikált fürtjének másodlagos helyével.

Munkaterület kiépítési állapotának ellenőrzése

A munkaterület kiépítési állapotának ellenőrzéséhez futtassa a következő GET parancsot:

GET

https://management.azure.com/subscriptions/<subscription_id>/resourceGroups/<resourcegroup_name>/providers/Microsoft.OperationalInsights/workspaces/<workspace_name>?api-version=2025-02-01

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.

A GET paranccsal ellenőrizze, hogy a munkaterület kiépítési állapota megváltozik-e Updating-ről Succeeded-re, és hogy a másodlagos régió megfelelően van beállítva.

Megjegyzé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.

Ellenőrizze, hogy engedélyezve van-e a replikáció egy munkaterületen

Ha ellenőrizni szeretné, hogy engedélyezve van-e a munkaterület replikációja, tekintse át ezeket a beállításokat.

Az Azure Portalon válassza ki a munkaterület >áttekintését. Ha a replikáció engedélyezve van, az Alapvető beállítások szakaszban megjelenik a másodlagos hely, amely a replikált munkaterület régióját jelzi.

Ugyanahhoz az Essentials-szakaszhoz tartozik egy JSON-nézet , amely JSON-objektumként jeleníti meg a replikáció részleteit, amely a REST/CLI használatával is elérhető.

Adatgyűjtési szabályok társítása a munkaterület adatgyűjtési végpontjával

Az Azure Monitor Agent, a Logs Ingestion API és az Azure Event Hubs adatokat gyűjt, és elküldi azokat az Ön által megadott célhelyre az adatgyűjtési szabályok (DCR) beállítása alapján.

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 munkaterület adatgyűjtési végpontjának neve megegyezik a munkaterület azonosítójával. Csak a munkaterület adatgyű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 munkaterület adatgyűjtési végpontjához:

1. Az Azure Portalon válassza az Adatgyűjtési szabályokat.

2. 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.

3. 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 munkaterület adatgyűjtési végpontját 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 adatgyű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.

Mi a teendő annak ellenőrzéséhez, hogy a munkaterület replikációja sikertelen-e

• A munkaterület egy dedikált klaszterhez van kapcsolva?
  • A replikációt engedélyezni kell a fürtön, mielőtt engedélyezhető lenne a munkaterületen.
  • A fürt- és a munkaterület-replikációt is ugyanarra a másodlagos helyszínre kell beállítani. Ha például a fürt Észak-Európába van replikálva, a hozzá társított munkaterületek szintén csak Észak-Európába replikálhatók.
• A REST API-t használta a replikáció engedélyezéséhez?
  • Ellenőrizze, hogy az API 2025-02-01-es vagy újabb verzióját használta-e.
• Az elsődleges munkaterület az USA keleti régiójában, az USA 2. keleti régiójában vagy az USA déli középső régiójában található?
  • Az USA keleti régiója, az USA 2. keleti régiója és az USA déli középső régiója nem replikálható egymással.
• Hol található az elsődleges munkaterület, és hol található a másodlagos munkaterület? Mindkét helynek ugyanabban a régiócsoportban kell lennie. Az USA régióiban található munkaterületek például nem rendelkezhetnek replikációval (másodlagos régióval) Európában, és fordítva. A régiócsoportok listájáért lásd: Támogatott régiók.
• Rendelkezik a szükséges engedélyekkel?
• Elegendő időt adott a replikációs művelet befejezéséhez? a replikáció egy hosszú ideig futó művelet. A művelet állapotának figyelése a Munkaterület kiépítési állapotának ellenőrzése című témakörben leírtak szerint.
• Megpróbálta újra engedélyezni a replikációt a munkaterület másodlagos helyének módosítása érdekében? A másodlagos munkaterület helyének módosításához először le kell tiltania a munkaterület replikációját, engedélyeznie kell a műveletet, majd engedélyeznie kell a replikációt egy másik másodlagos helyre.

Mi a teendő annak ellenőrzéséhez, hogy a munkaterület replikációja be van-e állítva, de a naplók nem replikálódnak?

• A replikáció akár egy órát is igénybe vehet az alkalmazás megkezdéséhez, és egyes adattípusok elkezdhetnek replikálni mások előtt.
• A replikáció engedélyezése előtt a munkaterületre betöltött naplók nem lesznek átmásolva a másodlagos munkaterületre. Csak a replikáció engedélyezése után betöltött naplók lesznek replikálva.
• Ha egyes naplók replikálva vannak, és mások nem – ellenőrizze, hogy a naplókat a munkaterületre streamelő összes adatgyűjtési szabály (DCR) megfelelően van-e konfigurálva. A munkaterületet megcélzó DCR-ek áttekintéséhez tekintse meg a Log Analytics Workspace Insights Adatgyűjtés lapját az Azure Portalon.

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=2025-02-01

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. A kérés kiépítési állapotát nyomon követheti a Munkaterület kiépítési állapotának ellenőrzése című szakaszban leírtak szerint.

Fontos

Ha dedikált fürtöt használ, a fürthöz társított összes munkaterület replikációjának letiltása után tiltsa le a fürtreplikálást.

Klaszter replikáció letiltása

A fürtreplikálás letiltása csak a fürthöz társított összes munkaterület replikációjának letiltása után végezhető el (ha korábban engedélyezve volt). 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/clusters/<cluster_name>?api-version=2025-02-01

body:
{
    "properties": {
        "replication": {
            "enabled": false
        }
    },
    "location": "<primary_region>"
}

Ahol:

• <subscription_id>: A clusterhez kapcsolódó előfizetés-azonosító.
• <resourcegroup_name> : Az erőforráscsoport, amely tartalmazza a klaszter erőforrást.
• <workspace_name>: A klaszter neve.
• <primary_region>: Az elsődleges régió a fürtöd számára.

A PUT parancs egy hosszú ideig futó művelet, amely eltarthat egy ideig. A sikeres hívás egy állapotkódot ad 200 vissza. A kérés kiépítési állapotát nyomon követheti a Munkaterület kiépítési állapotának ellenőrzése című szakaszban leírtak szerint.

Megjegyzés

Ha a replikáció le van tiltva, és a replikált fürt törlődik, a replikált naplók törlődnek, és nem lehet újra hozzáférni. Ebben a folyamatban az elsődleges helyszínen lévő eredeti példány nem változik.

Fontos

A fürtreplikálás eltávolításának folyamata 14 napot vesz igénybe. Ha a folyamat gyorsabb elvégzéséhez szüksége van erre a folyamatra, hozzon létre egy Azure-támogatási kérést.

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

• Hozzon létre saját monitorozási lekérdezéseket, amelyek egyéni állapotjelzőkként szolgálnak a munkaterület számára, amint az a munkaterület teljesítményének lekérdezésekkel történő figyelésében le van írva.

  • A betöltési késés mérése táblánként
  • Annak azonosítása, hogy a késleltetés forrása az adatrögzítő ügynökök vagy az adatbevitel folyamat.
  • A beviteli adatforgalom 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

Megjegyzé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ó: Üzembe helyezési szempontok.

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:

• A régiók közötti probléma mögöttes erőforrással kapcsolatos. 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 naplókat ehelyett a másodlagos régió feldolgozó folyamatának küldi a rendszer.

• Lekérdezés: Ha az elsődleges munkaterületen lévő lekérdezések meghiúsulnak vagy időtúllépést eredményeznek, az hatással lehet a naplókeresési riasztásokra. 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 a replikáció engedélyezése után legalább egy hetet várjon, mielőtt elindítja az átkapcsolást. A hét nap lehetővé teszi, hogy elegendő adat legyen elérhető a másodlagos régióban.

Indítókapcsoló átkapcsolá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=2025-02-01

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. A kérés kiépítési állapotát nyomon követheti a Munkaterület kiépítési állapotának ellenőrzése című szakaszban leírtak szerint.

Mi a teendő annak ellenőrzéséhez, hogy az átállás (feladatátvétel) sikertelen-e

• A REST API-t használta a kapcsolás (feladatátvétel) aktiválására?
  • Ellenőrizze, hogy az API 2025-02-01-es vagy újabb verzióját használta-e.
  • Ellenőrizze, hogy a feladatátvételi parancsban megadott másodlagos hely a munkaterület másodlagos helye-e. Ezek az információk a munkaterület Azure Portal nézetében és API-on keresztül érhetők el.
• A régiók közötti váltáshoz Log Analytics-közreműködői szerepkörre van szükség a munkaterület erőforráscsoportján, és nem csak a munkaterületen.

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ítja a beállításokat, az Azure Monitor ismét az elsődleges munkaterületre irányítja a lekérdezéseket és a naplóbetöltési kérelmeket.

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 még az előtt vált vissza, hogy az összes napló replikálódik az elsődleges munkaterületre, előfordulhat, hogy a lekérdezések részleges eredményeket adnak vissza, amíg a naplófeldolgozá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 fogadja be a naplókat, és dolgozza fel a lekérdezéseket a várt módon.

Ha példákat szeretne arról, hogyan lehet lekérdezni az elsődleges munkaterületet, amikor a másodlagos munkaterület aktív, és megkerülni a kérések átirányítását a másodlagos munkaterületre, tekintse meg az Az inaktív munkaterület ellenőrzése című témakört.

Visszaváltás indítá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 eltarthat egy ideig, amíg az összes ügyfél megkapja a frissített DNS-beállításokat, és folytatja 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=2025-02-01

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. A kérés kiépítési állapotát nyomon követheti a Munkaterület kiépítési állapotának ellenőrzése című szakaszban leírtak szerint.

Az inaktív munkaterület ellenőrzése

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 elindításakor a rendszer á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ületén megtalálhatók-e azok a naplók, amelyeket ott látni szeretne.

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>&timespan=<timespan-in-ISO8601-format>&overrideWorkspaceRegion=<primary|secondary>

Ha például egy rövid 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&timespan=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, hogy egy megadott számú szabályszegés után átkapcsoljon az ön másodlagos munkaterületére. 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ésleltetés és a betöltési mennyiség. 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

Az adatbevitel késleltetése 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 feldolgozá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 észreveszi, hogy az összesített adatbevitel késleltetése növekszik, lekérdezésekkel megállapíthatja, hogy a késleltetés forrása az ügynökök vagy az adatfeldolgozá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

Megjegyzé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.

Bevitel mennyiség figyelése

Az adatfeltöltési mennyiség mérései segíthetnek azonosítani a munkahely teljes vagy táblázatspecifikus adatfeltöltési mennyiségé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 térfogatmérést tartalmaznak:

• Teljes betöltési mennyiség táblánként
• Állandó felvételi mennyiség (állapot)
• Adatfeldolgozási anomáliák – tüskék és visszaesések az adatfeldolgozási mennyiségben

Az alábbi szakaszok bemutatják, hogyan használhat lekérdezéseket a munkaterület beviteli volumenének ellenőrzéséhez.

Táblánkénti teljes mennyiség figyelése

Meghatározhat egy lekérdezést a munkaterület tábláinak adatbevitel mennyiségének figyelésére. 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 az adatbevitel teljes nagyságát az elmúlt órában, táblánként, megabájt/másodpercben (MB/s).

// 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 viszi be, az ügynök szívverés segítségével észlelheti a kapcsolódást. Egy leállt szívverés jelezheti a naplók munkaterületre való betöltésének leállását. 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

Fogyasztási anomáliák ellenőrzése

A munkaterület adatbetöltési mennyiségeiben különböző módokon azonosíthatja a kiugrásokat és a csökkenéseket. A series_decompose_anomalies() függvénnyel kinyerheti a rendellenességeket a munkaterületen figyelt betöltésekből, vagy létrehozhat egy saját anomáliadetektort, hogy támogassa az egyedi munkaterületi forgatókönyveket.

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 mennyiség 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

Kapcsolódó tartalom

• Log Analytics-munkaterület állapotának figyelése
• Működési problémák monitorozása az Azure Monitor Log Analytics-munkaterületen