Naplókeresési riasztások hibaelhárítása az Azure Monitorban
Ez a cikk azt ismerteti, hogyan oldhatja meg a naplókeresési riasztásokkal kapcsolatos gyakori problémákat az Azure Monitorban. Emellett megoldást kínál a naplóriasztások funkciójával és konfigurációjával kapcsolatos gyakori problémákra.
Naplóriasztások használatával kiértékelheti az erőforrások naplóit minden beállított gyakorisággal Egy Log Analytics-lekérdezés használatával, és az eredmények alapján riasztást állíthat be. A szabályok egy vagy több műveletet aktiválhatnak műveletcsoportok használatával. A naplókeresési riasztások funkciójáról és terminológiájáról további információt az Azure Monitor naplóriasztásai című témakörben talál.
Feljegyzés
Ez a cikk nem tárgyalja azokat az eseteket, amikor a riasztási szabály aktiválódott, az Azure Portalon látható, de az értesítés nem lett elküldve. Tekintse meg az ilyen esetek hibaelhárítási riasztását .
A naplókeresési riasztás nem aktiválódott, amikor kellett volna
Ha a naplókeresési riasztás nem aktiválódott, amikor kellett volna, ellenőrizze a következő elemeket:
A riasztási szabály csökkentett vagy nem elérhető állapotban van?
A naplókeresési riasztási szabály állapotának megtekintése:
A portálon válassza a Figyelés, majd a Riasztások lehetőséget.
A felső parancssávon válassza a Riasztási szabályok lehetőséget. Az oldalon az összes előfizetésre vonatkozó összes riasztási szabály látható.
Válassza ki a figyelni kívánt naplókeresési riasztási szabályt.
A bal oldali panel Súgó területén válassza az Erőforrás állapota lehetőséget.
További információ: Naplókeresési riasztási szabályok állapotának figyelése.
Ellenőrizze a naplóbetöltés késését.
Az Azure Monitor több terabájtnyi ügyfélnaplót dolgoz fel a világ minden részéről, ami a naplók betöltési késését okozhatja.
A naplók részben strukturált adatok, és eredendően több látensek, mint a metrikák. Ha több mint 4 perces késést tapasztal az aktivált riasztásokban, érdemes megfontolnia a metrikariasztások használatát. Naplókból adatokat küldhet a metrikatárolóba a naplók metrikariasztásaival.
A késés csökkentése érdekében a rendszer többször újrapróbálkozza a riasztás kiértékelését. Az adatok beérkezése után a riasztás kigyullad, ami a legtöbb esetben nem egyenlő a naplórekord időével.
A műveletek elnémítva vannak, vagy a riasztási szabály automatikus feloldásra lett konfigurálva?
Gyakori probléma, hogy úgy gondolja, hogy a riasztás nem aktiválódott, de a szabály úgy lett konfigurálva, hogy a riasztás ne aktiválódik. Tekintse meg a naplókeresési riasztási szabály speciális beállításait annak ellenőrzéséhez, hogy nincs-e bejelölve az alábbiak egyike:
- A Műveletek elnémítása jelölőnégyzet: lehetővé teszi az aktivált riasztási műveletek meghatározott ideig történő elnémítását.
- Riasztások automatikus feloldása: úgy konfigurálja a riasztást, hogy feltételenként csak egyszer aktiválódjon.
Áthelyezték vagy törölték a riasztási szabály erőforrását?
Ha egy riasztási szabály erőforrása áthelyeződik, átneveződik vagy törlődik, az adott erőforrásra hivatkozó összes naplóriasztási szabály meg fog szakadni. A probléma megoldásához a riasztási szabályokat újra létre kell hozni a hatókör érvényes célerőforrásával.
A riasztási szabály rendszer által hozzárendelt felügyelt identitást használ?
Ha rendszer által hozzárendelt felügyelt identitással hoz létre naplóriasztási szabályt, az identitás engedély nélkül jön létre. A szabály létrehozása után hozzá kell rendelnie a megfelelő szerepköröket a szabály identitásához, hogy hozzáférhessen a lekérdezni kívánt adatokhoz. Előfordulhat például, hogy olvasói szerepkört kell adni neki a megfelelő Log Analytics-munkaterületekhez, vagy egy Olvasó szerepkört és egy Adatbázis-megjelenítő szerepkört a megfelelő ADX-fürthöz. A felügyelt identitások naplóriasztásokban való használatával kapcsolatos további információkért tekintse meg a felügyelt identitásokat.
Érvényes a naplókeresési riasztási szabályban használt lekérdezés?
Naplóriasztási szabály létrehozásakor a rendszer ellenőrzi a lekérdezés helyes szintaxisát. Néha azonban a naplóriasztási szabályban megadott lekérdezés meghiúsulhat. Néhány gyakori ok:
- A szabályok az API-val lettek létrehozva, és a felhasználó kihagyta az ellenőrzést.
- A lekérdezés több erőforráson fut, és egy vagy több erőforrást töröltek vagy áthelyeztek.
- A lekérdezés meghiúsul , mert:
- A naplózási megoldás nem lett üzembe helyezve a munkaterületen, így a táblák nem jönnek létre.
- Az adatok több mint 30 napig nem áramlanak a lekérdezés egyik táblája felé.
- Az egyéni naplótáblák nem lettek létrehozva, mert az adatfolyam nem indult el.
- A lekérdezés nyelvének változásai tartalmazzák a parancsok és függvények módosított formátumát, így a korábban megadott lekérdezés már nem érvényes.
Az Azure Service Health figyeli a felhőerőforrások állapotát, beleértve a naplókeresési riasztási szabályokat is. Ha a naplókeresési riasztási szabály kifogástalan állapotú, a szabály fut, és a lekérdezés sikeresen lefut. A naplókeresési riasztási szabályok erőforrás-állapotával megismerheti a naplókeresési riasztási szabályokat érintő problémákat.
Letiltotta a naplókeresési riasztási szabályt?
Ha egy naplókeresési riasztási szabály lekérdezése egy hétig nem tud folyamatosan kiértékelni, az Azure Monitor automatikusan letiltja azt.
Az alábbi szakaszok felsorolnak néhány okot, amelyek miatt az Azure Monitor letilthatja a naplókeresési riasztási szabályt. Emellett van egy példa a tevékenységnapló eseményére, amely akkor lesz elküldve, ha egy szabály le van tiltva.
Példa tevékenységnaplóra, ha a szabály le van tiltva
{
"caller": "Microsoft.Insights/ScheduledQueryRules",
"channels": "Operation",
"claims": {
"http://schemas.xmlsoap.org/ws/2005/05/identity/claims/spn": "Microsoft.Insights/ScheduledQueryRules"
},
"correlationId": "abcdefg-4d12-1234-4256-21233554aff",
"description": "Alert: test-bad-alerts is disabled by the System due to : Alert has been failing consistently with the same exception for the past week",
"eventDataId": "f123e07-bf45-1234-4565-123a123455b",
"eventName": {
"value": "",
"localizedValue": ""
},
"category": {
"value": "Administrative",
"localizedValue": "Administrative"
},
"eventTimestamp": "2019-03-22T04:18:22.8569543Z",
"id": "/SUBSCRIPTIONS/<subscriptionId>/RESOURCEGROUPS/<ResourceGroup>/PROVIDERS/MICROSOFT.INSIGHTS/SCHEDULEDQUERYRULES/TEST-BAD-ALERTS",
"level": "Informational",
"operationId": "",
"operationName": {
"value": "Microsoft.Insights/ScheduledQueryRules/disable/action",
"localizedValue": "Microsoft.Insights/ScheduledQueryRules/disable/action"
},
"resourceGroupName": "<Resource Group>",
"resourceProviderName": {
"value": "MICROSOFT.INSIGHTS",
"localizedValue": "Microsoft Insights"
},
"resourceType": {
"value": "MICROSOFT.INSIGHTS/scheduledqueryrules",
"localizedValue": "MICROSOFT.INSIGHTS/scheduledqueryrules"
},
"resourceId": "/SUBSCRIPTIONS/<subscriptionId>/RESOURCEGROUPS/<ResourceGroup>/PROVIDERS/MICROSOFT.INSIGHTS/SCHEDULEDQUERYRULES/TEST-BAD-ALERTS",
"status": {
"value": "Succeeded",
"localizedValue": "Succeeded"
},
"subStatus": {
"value": "",
"localizedValue": ""
},
"submissionTimestamp": "2019-03-22T04:18:22.8569543Z",
"subscriptionId": "<SubscriptionId>",
"properties": {
"resourceId": "/SUBSCRIPTIONS/<subscriptionId>/RESOURCEGROUPS/<ResourceGroup>/PROVIDERS/MICROSOFT.INSIGHTS/SCHEDULEDQUERYRULES/TEST-BAD-ALERTS",
"subscriptionId": "<SubscriptionId>",
"resourceGroup": "<ResourceGroup>",
"eventDataId": "12e12345-12dd-1234-8e3e-12345b7a1234",
"eventTimeStamp": "03/22/2019 04:18:22",
"issueStartTime": "03/22/2019 04:18:22",
"operationName": "Microsoft.Insights/ScheduledQueryRules/disable/action",
"status": "Succeeded",
"reason": "Alert has been failing consistently with the same exception for the past week"
},
"relatedEvents": []
}
A naplókeresési riasztás akkor aktiválódott, ha nem kellett volna
Előfordulhat, hogy az Azure Monitorban konfigurált naplóriasztási szabály váratlanul aktiválódik. Az alábbi szakaszok néhány gyakori okot ismertetnek.
Késési problémák miatt aktiválódott a riasztás?
Az Azure Monitor globálisan több terabájtnyi ügyfélnaplót dolgoz fel, ami a naplók betöltési késését okozhatja. Vannak beépített képességek a hamis riasztások megelőzésére, de továbbra is előfordulhatnak nagyon látens adatokon (több mint ~30 perc) és késési csúcsokkal rendelkező adatokon.
A naplók részben strukturált adatok, és eredendően több látensek, mint a metrikák. Ha sok hibát tapasztal az aktivált riasztásokban, fontolja meg a metrikariasztások használatát. Naplókból adatokat küldhet a metrikatárolóba a naplók metrikariasztásaival.
A naplókeresési riasztások akkor működnek a legjobban, ha konkrét adatokat próbál észlelni a naplókban. Kevésbé hatékonyak, ha a naplókban lévő adatok hiányát próbálja észlelni, például a virtuális gépek szívverésére vonatkozó riasztásokat.
Hibaüzenetek a naplókeresési riasztási szabályok konfigurálásakor
Az egyes hibaüzenetek és azok megoldásai a következő szakaszokban találhatók.
A lekérdezés nem érvényesíthető, mivel engedélyre van szüksége a naplókhoz
Ha ezt a hibaüzenetet kapja a riasztási szabály lekérdezésének létrehozásakor vagy szerkesztésekor, győződjön meg arról, hogy rendelkezik engedéllyel a célerőforrás-naplók olvasásához.
- A naplók munkaterület-környezetbeli hozzáférési módban való olvasásához szükséges engedélyek:
Microsoft.OperationalInsights/workspaces/query/read
. - A naplók erőforrás-környezetbeli hozzáférési módban való olvasásához szükséges engedélyek (beleértve a munkaterület-alapú Application Insights-erőforrást is):
Microsoft.Insights/logs/tableName/read
.
Az engedélyekről további információt a Log Analytics-munkaterületekhez való hozzáférés kezelése című témakörben talál.
Ez a lekérdezés nem támogatja az egyperces gyakoriságot
Az egyperces riasztási szabály gyakoriságának vannak bizonyos korlátai. Amikor a riasztási szabály gyakoriságát egy percre állítja be, a rendszer belső manipulációt hajt végre a lekérdezés optimalizálásához. Ez a manipuláció a lekérdezés sikertelenségét okozhatja, ha az nem támogatott műveleteket tartalmaz.
A nem támogatott forgatókönyvek listáját ebben a megjegyzésben találja.
Nem sikerült feloldani a nevesített skaláris kifejezést <>
Ez a hibaüzenet a riasztási szabály lekérdezésének létrehozásakor vagy szerkesztésekor adható vissza, ha:
- Olyan oszlopra hivatkozik, amely nem létezik a táblázatsémában.
- Olyan oszlopra hivatkozik, amelyet nem használtak a lekérdezés korábbi projekt záradékában.
Ennek csökkentése érdekében hozzáadhatja az oszlopot az előző projekt záradékhoz, vagy használhatja a columnifexists operátort.
Az ScheduledQueryRules API nem támogatott csak olvasási OMS-riasztásokhoz
Ez a hibaüzenet akkor jelenik meg, amikor az Örökölt API-verzióval létrehozott szabályokat próbálja frissíteni vagy törölni az Azure Portal használatával.
- Szerkessze vagy törölje a szabályt programozott módon a Log Analytics REST API használatával.
- Ajánlott: Frissítse a riasztási szabályokat az Ütemezett lekérdezési szabályok API használatára (az örökölt API elavult elérési úton van).
Elérte a riasztási szabály szolgáltatáskorlátját
Az előfizetésenkénti naplókeresési riasztási szabályok számával és az erőforrások maximális korlátjaival kapcsolatos részletekért tekintse meg az Azure Monitor szolgáltatáskorlátait. Tekintse meg a használatban lévő naplóriasztási szabályok teljes számának ellenőrzése című témakört, amelyből megtudhatja, hogy hány metrikariasztási szabály van jelenleg használatban. Ha elérte a kvótakorlátot, az alábbi lépések segíthetnek a probléma megoldásában.
Törölje vagy tiltsa le a már nem használt naplókeresési riasztási szabályokat.
A szabályok számának csökkentéséhez használja a dimenziók szerinti felosztást. Ha dimenziók szerinti felosztást használ, egy szabály számos erőforrást figyelhet.
Ha növelni szeretné a kvótakorlátot, nyisson meg egy támogatási kérelmet, és adja meg a következő információkat:
- Az előfizetés azonosítói és erőforrás-azonosítói, amelyekre a kvótakorlátot növelni kell
- A kvótanövelés oka
- A kvótanövelés erőforrástípusa, például a Log Analytics vagy az Application Insights
- A kért kvótakorlát
Hiányos időszűrés az ARG- és ADX-lekérdezésekben
Ha az Azure Data Explorer (ADX) vagy az Azure Resource Graph (ARG) lekérdezéseit naplókeresési riasztásokban használja, előfordulhat, hogy az "Összesítés részletessége" beállítás nem alkalmaz időszűrőt a lekérdezésekre. Ez váratlan eredményekhez és potenciális teljesítményproblémákhoz vezethet, mivel a lekérdezés a tervezett időtartomány helyett a piszkozat összes 30 napnyi adatát visszaadja.
A probléma megoldásához kifejezetten időszűrőket kell alkalmaznia az ARG- és ADX-lekérdezésekben. Az alábbiakban a következő lépéseket kell elvégeznie:
Megfelelő időszűrés: Az időtartomány azonosítása: Határozza meg a lekérdezni kívánt időtartományt. Ha például az elmúlt 24 órából szeretne adatokat lekérdezni, meg kell adnia ezt az időtartományt a lekérdezésben.
A lekérdezés módosítása: Adjon hozzá egy időszűrőt az ARG- vagy ADX-lekérdezéshez a kívánt időtartományba visszaadott adatok korlátozásához. Íme egy példa a lekérdezés módosítására:
// Original query without time filter
resources
| where type == "microsoft.compute/virtualmachines"
// Modified query with time filter
resources
| where type == "microsoft.compute/virtualmachines"
| where timestamp >= ago(24h)
- A lekérdezés tesztelése: Futtassa a módosított lekérdezést, és győződjön meg arról, hogy a várt eredményeket adja vissza a megadott időtartományon belül.
- Riasztások frissítése: Frissítse a naplókeresési riasztásokat a módosított lekérdezés explicit időszűrővel való használatára. Ez biztosítja, hogy a riasztások a megfelelő adatokon alapulnak, és ne tartalmazzanak szükségtelen előzményadatokat. Ha explicit időszűrőket alkalmaz az ARG- és ADX-lekérdezésekben, elkerülheti a túlzott adatok lekérésének problémáját, és biztosíthatja, hogy a naplókeresési riasztások pontosak és hatékonyak legyenek.
Következő lépések
- Tudnivalók az Azure-beli naplóriasztásokról.
- További információ a naplóriasztások konfigurálásáról.
- További információ a napló lekérdezéseiről.