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 célerőforrását áthelyezi, átnevezi vagy törli, az adott erőforrásra hivatkozó összes naplóriasztási szabály megszakad. 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:
- 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 Resource Health figyeli a felhőbeli 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.
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 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 kívánt időtartomány helyett az egész 30 napot 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.