Protokolování výstrah v Azure Monitor

Přehled

Výstrahy protokolu jsou jedním z typů výstrah, které jsou podporovány v upozorněních Azure. Výstrahy protokolu umožňují uživatelům pomocí log Analyticsho dotazu vyhodnotit protokoly prostředků každou nastavenou frekvencí a vyvolat výstrahu na základě výsledků. Pravidla mohou aktivovat jednu nebo více akcí pomocí skupin akcí.

Poznámka

Data protokolu z Log Analytics pracovního prostoru lze odeslat do úložiště metrik Azure monitor. Výstrahy metrik mají různé chování, což může být více žádoucí v závislosti na datech, se kterými pracujete. Informace o tom, co a jak můžete směrovat protokoly do metrik, najdete v tématu Upozornění na metriky pro protokoly.

Požadavky

Výstrahy protokolu spouštějí dotazy na Log Analytics data. Nejdřív byste měli začít shromažďovat data protokolu a dotazovat se na data protokolu. Pomocí článku příklady dotazů na výstrahy v Log Analytics můžete pochopit, co můžete zjistit nebo začít psát vlastní dotaz.

Přispěvatel monitorování Azure je společná role, která je nutná k vytváření, úpravám a aktualizaci výstrah protokolu. Pro protokoly prostředků je taky potřeba mít přístup & oprávnění k provádění dotazů. Částečný přístup k protokolům prostředků může selhat s dotazy nebo vracet částečné výsledky. Přečtěte si další informace o konfiguraci upozornění protokolu v Azure.

Poznámka

Výstrahy protokolu pro Log Analytics používané ke správě pomocí rozhraní API pro upozorněnína starší verzi Log Analytics. Přečtěte si další informace o přepnutí na aktuální rozhraní ScheduledQueryRules API.

Definice vyhodnocení dotazu

Definice podmínky pravidel hledání protokolu začíná na:

  • Který dotaz se má spustit?
  • Jak používat výsledky?

V následujících částech jsou popsány různé parametry, které můžete použít k nastavení výše uvedené logiky.

Dotaz protokolu

Log Analytics dotaz použitý k vyhodnocení pravidla Výsledky vrácené tímto dotazem slouží k určení, zda má být výstraha aktivována. Dotaz může být vymezen na:

  • Konkrétní prostředek, jako je třeba virtuální počítač.
  • Škálování prostředku, jako je například předplatné nebo skupina prostředků.
  • Více prostředků s použitím dotazu mezi prostředky.

Důležité

Dotazy na výstrahy mají omezení pro zajištění optimálního výkonu a relevance výsledků. Další informace najdete tady.

Důležité

Dotaz orientovaný na prostředky a mezi prostředky se podporují jenom pomocí aktuálního rozhraní scheduledQueryRules API. Pokud používáte starší rozhraní API Log Analytics výstrah, budete muset přepnout. Další informace o přepínání

Časový rozsah dotazu

V definici podmínky pravidla je nastaven časový rozsah. v pracovních prostorech a Application Insights se říká perioda. Ve všech ostatních typech prostředků se nazývá časový rozsah pro přepis dotazů.

Podobně jako v Log Analytics časový rozsah omezuje data dotazu na zadaný rozsah. I v případě, že se v dotazu používá příkaz, bude platit časový rozsah.

Například dotaz vyhledává 60 minut, pokud je časový rozsah 60 minut, a to i v případě, že text obsahuje hodnotu před (1d). Časový rozsah a filtrování času dotazu se musí shodovat. V ukázkovém případě bude změna / rozsahu času dotazu přepisu období na jeden den fungovat podle očekávání.

Measure

Výstrahy protokolu zapínají protokol na číselné hodnoty, které lze vyhodnotit. Můžete změřit dvě různé věci:

Počet řádků tabulky výsledků

Počet výsledků je výchozí míra. ideální pro práci s událostmi, jako jsou protokoly událostí Windows, syslog, výjimky aplikací. Aktivuje se v případě, že dojde k záznamu protokolu nebo k němu nedochází v okně vyhodnoceného času.

Výstrahy protokolu fungují nejlépe, když se pokusíte detekovat data v protokolu. Funguje méně dobře, když se pokusíte detekovat chybějící data v protokolech. Například upozornění na prezenční signál virtuálního počítače.

u pracovních prostorů a Application Insights se říká na základě výběru počtu výsledků. Ve všech ostatních typech prostředků se nazývá Measure s řádky tabulky výběru.

Poznámka

Vzhledem k tomu, že protokoly jsou částečně strukturovaná data, jsou ve své podstatě více latentních, než je metrika, při pokusu o detekci chybějících dat v protokolech může docházet k výpadkům a měli byste zvážit použití výstrah metrik. Data můžete do úložiště metrik odesílat z protokolů pomocí výstrah metrik pro protokoly.

Příklad případu použití počtu řádků tabulky výsledků

Chcete zjistit, kdy vaše aplikace odpověděla s kódem chyby 500 (interní chyba serveru). Vytvořili byste pravidlo výstrahy s následujícími podrobnostmi:

  • Dotaz:
requests
| where resultCode == "500"
  • Časové období/členitost agregace: 15 minut
  • Frekvence upozornění: 15 minut
  • Prahová hodnota: Větší než 0

Pravidla výstrah se pak monitorují pro všechny požadavky končící kódem chyby 500. Dotaz se spouští každých 15 minut za posledních 15 minut. Pokud je nalezen i jeden záznam, aktivuje výstrahu a aktivuje nakonfigurované akce.

Výpočet míry na základě číselného sloupce (například hodnota čítače CPU)

u pracovních prostorů a Application Insights se říká na základě měření metriky výběru. Ve všech ostatních typech prostředků se tento název nazývá míra s výběrem libovolného číselného sloupce s čísly.

Typ agregace

Výpočet, který je proveden na více záznamech pro agregaci na jednu číselnou hodnotu. Například:

  • Count vrátí počet záznamů v dotazu.
  • Funkce Average Vrátí průměrnou hodnotu definování členitosti sloupce měr.

v pracovních prostorech a Application Insights je podporováno pouze v typu míry měření metrik . Výsledek dotazu musí obsahovat sloupec s názvem AggregatedValue, který poskytuje číselnou hodnotu po uživatelsky definované agregaci. Ve všech ostatních typech prostředků je typ agregace vybraný z pole s tímto názvem.

Členitost agregace

Určuje interval, který se použije k agregaci několika záznamů na jednu číselnou hodnotu. Pokud jste například zadali 5 minut, záznamy by byly seskupeny o 5 minut pomocí zadaného typu agregace .

v pracovních prostorech a Application Insights je podporováno pouze v typu míry měření metrik . Výsledek dotazu musí obsahovat bin () , který nastavuje interval ve výsledcích dotazu. U všech ostatních typů prostředků se pole, které řídí toto nastavení, nazývá členitost agregace.

Poznámka

Funkce AS bin () může mít za následek nerovnoměrné časové intervaly, služba Alert automaticky převede funkci bin () na bin_at () s odpovídajícím časem za běhu, aby se zajistilo, že výsledky budou s pevným bodem.

Rozdělit podle dimenzí výstrahy

Oddělte výstrahy podle číselných nebo řetězcových sloupců na samostatné výstrahy seskupením do jedinečných kombinací. Když vytváříte výstrahy orientované na prostředky ve velkém měřítku (předplatné nebo obor skupiny prostředků), můžete rozdělit podle sloupce Azure Resource ID. Rozdělením do sloupce Azure Resource ID se změní cíl výstrahy na zadaný prostředek.

Rozdělení podle sloupce ID prostředku Azure se doporučuje, když chcete monitorovat stejnou podmínku u více prostředků Azure. Například monitorování všech virtuálních počítačů s využitím procesoru nad 80%. Můžete se také rozhodnout, že nebudete muset rozdělovat, pokud chcete podmínku na více prostředků v oboru. Například monitorování, že nejméně pět počítačů v oboru skupiny prostředků má využití CPU více než 80%.

v pracovních prostorech a Application Insights je podporováno pouze v typu míry měření metrik . Pole se nazývá agregace. Je omezeno na tři sloupce. Více než tři skupiny podle sloupců v dotazu by mohly vést k neočekávaným výsledkům. Ve všech ostatních typech prostředků se konfiguruje v části podmínky Rozdělit podle dimenzí (omezeno na šest rozdělení).

Příklad rozdělení podle dimenzí upozornění

Chcete například monitorovat chyby u několika virtuálních počítačů, na které běží váš web nebo aplikace v konkrétní skupině prostředků. Můžete to provést pomocí pravidla upozornění protokolu následujícím způsobem:

  • Dotaz:

    // Reported errors
    union Event, Syslog // Event table stores Windows event records, Syslog stores Linux records
    | where EventLevelName == "Error" // EventLevelName is used in the Event (Windows) records
    or SeverityLevel== "err" // SeverityLevel is used in Syslog (Linux) records
    

    Pokud používáte pracovní prostory a aplikační Přehledy s logikou upozornění na měření metriky, je potřeba do textu dotazu přidat tento řádek:

    | summarize AggregatedValue = count() by Computer, bin(TimeGenerated, 15m)
    
  • Sloupec ID prostředku: _ResourceId (rozdělení podle ID prostředku v pravidlech upozornění je aktuálně k dispozici pouze pro předplatná a skupiny prostředků).

  • Dimenze / Agregované v:

    • Počítač = VM1, VM2 (filtrování hodnot v definici pravidel upozornění není aktuálně k dispozici pro pracovní prostory a Přehledy. Vyfiltrujte text dotazu.)
  • Časové období / Úroveň agregace: 15 minut

  • Frekvence upozornění: 15 minut

  • Prahová hodnota: Větší než 0

Toto pravidlo monitoruje, jestli u jakéhokoli virtuálního počítače během posledních 15 minut došlo k chybám. Každý virtuální počítač se monitoruje samostatně a aktivuje akce jednotlivě.

Poznámka

Rozdělení podle dimenzí upozornění je k dispozici pouze pro aktuální rozhraní SCHEDULEDQueryRules API. Pokud používáte starší verzi rozhraní API pro upozornění Log Analytics,budete muset přepnout. Přečtěte si další informace o přepínání. Upozornění zaměřené na prostředky ve velkém měřítku se podporuje pouze ve verzi rozhraní API a 2020-08-01 vyšší.

Definice logiky upozornění

Jakmile definujete dotaz, který se má spustit, a vyhodnocení výsledků, musíte definovat logiku upozornění a kdy se mají akce spustit. Následující části popisují různé parametry, které můžete použít:

Prahová hodnota a operátor

Výsledky dotazu se transformují na číslo, které se porovnává s prahovou hodnotou a operátorem.

Frekvence

Poznámka

V současné době se za upozornění protokolu četnosti na 1 minutu ve verzi Preview neplatí žádné další poplatky. Ceny funkcí, které jsou ve verzi Preview, budou oznámeny v budoucnu a před zahájením fakturace budou oznámeny oznámení. Pokud se rozhodnete pokračovat v používání upozornění protokolu četnosti 1 minuty po uplynutí období oznámení, budou se vám účtovat příslušné sazby.

Interval, ve kterém se dotaz spustí. Je možné nastavit od minuty do dne. Aby se záznamy protokolu nezmešká, musí být stejný jako nebo menší než časový rozsah dotazu.

Pokud například nastavíte časové období na 30 minut a frekvenci na 1 hodinu. Pokud se dotaz spustí v 00:00, vrátí záznamy mezi 23:30 a 00:00. Při příštím spuštění dotazu je 01:00, který vrátí záznamy v rozmezí od 00:30 do 1:00. Žádné záznamy vytvořené v rozmezí 00:00 až 00:30 by se nikdy nevyhodnotili.

Počet porušení pro aktivaci upozornění

Můžete zadat období vyhodnocení výstrahy a počet selhání potřebných k aktivaci výstrahy. Umožňuje vám lépe definovat dobu dopadu aktivace upozornění.

Pokud je například vaše pravidlo Úroveň agregace definované jako 5 minut, můžete upozornění aktivovat pouze v případě, že došlo ke třem selháním (15 minut) za poslední hodinu. Toto nastavení definuje vaše firemní zásada aplikace.

Stav a řešení výstrah

Upozornění protokolu mohou být buď stavová, nebo stavová (aktuálně ve verzi Preview).

Bezvýcová upozornění se pokaždé, když je podmínka splněná, i když se aktivila dříve. Po vyřešení instance výstrahy můžete výstrahu označit jako uzavřenou. Akce můžete také ztlumit, abyste zabránili jejich aktivaci po určité období po aktivaci pravidla upozornění. V pracovních prostorech Log Analytics a Přehledy se nazývá Potlačit upozornění. Ve všech ostatních typech prostředků se mu říká Mute Actions (Ztlumit akce).

Podívejte se na tento příklad bezvýstradného vyhodnocení upozornění:

Čas Vyhodnocení podmínky protokolu Výsledek
00:05 FALSE Upozornění se nehodí. Nevolaly se žádné akce.
00:10 TRUE Upozornění se vyvolalo a volaly skupiny akcí. Stav nové výstrahy JE AKTIVNÍ.
00:15 TRUE Upozornění se vyvolalo a volaly skupiny akcí. Stav nové výstrahy JE AKTIVNÍ.
00:20 FALSE Upozornění se nehodí. Nevolaly se žádné akce. Stav výstrah yyschtivý zůstává AKTIVNÍ.

Stavová upozornění se pro každý incident shoví a vyřeší se jednou. Pravidlo upozornění se vyřeší, když není 30minutová podmínka výstrahy splněna pro konkrétní vyhodnocovací období (kvůli zohledňování zpoždění příjmu protokolů) a tři po sobě jdoucí vyhodnocení, aby se snížil šum v případě neoválových podmínek. Například s frekvencí 5 minut se výstraha vyřeší po 40 minutách nebo s frekvencí 1 minuta a výstraha se vyřeší po 32 minutách. Vyřešené oznámení se odesílá prostřednictvím webhooků nebo e-mailů. Stav instance upozornění (nazývaný stav monitorování) v Azure Portal je také nastaven na vyřešeno.

Stavová funkce upozornění je aktuálně ve verzi Preview ve veřejném cloudu Azure. Můžete to nastavit pomocí vyřešit automaticky výstrahy v části podrobnosti výstrahy.

Výběr umístění v upozorněních protokolu

Upozornění protokolu umožňují nastavit umístění pro pravidla upozornění. V pracovních prostorech Log Analytics musí umístění pravidla odpovídat umístění pracovního prostoru. Ve všech ostatních programech můžete vybrat libovolné z podporovaných umístění, které je v souladu se seznamem podporovaných oblastí služby Log Analytics.

Umístění ovlivňuje oblast, ve které se pravidlo upozornění vyhodnocuje. Dotazy se spouštěly s daty protokolu ve vybrané oblasti, ale služba upozornění je od konce globální. To znamená, že definice pravidla upozornění, aktivaná upozornění, oznámení a akce nejsou svázané s umístěním v pravidlu upozornění. Data se přenesou ze nastavené oblasti, protože Azure Monitor výstrah je neregionální služba.

Ceny a fakturace upozornění protokolu

Informace o cenách najdete na Azure Monitor stránce s cenami. Upozornění protokolu jsou uvedená v části Poskytovatel prostředků microsoft.insights/scheduledqueryrules s:

  • Upozornění protokolu na úrovni Přehledy se zobrazeným přesným názvem prostředku spolu se skupinou prostředků a vlastnostmi upozornění.
  • Upozornění protokolu v Log Analytics zobrazená s přesným názvem prostředku spolu se skupinami prostředků a vlastnostmi upozornění při vytváření pomocí scheduledQueryRules API.
  • Upozornění protokolu vytvořená ze starší verze rozhraní API Log Analytics se nesleduje v prostředcích Azure a nevynucuje jedinečné názvy prostředků. Tyto výstrahy se stále vytvářejí jako microsoft.insights/scheduledqueryrules skryté prostředky, které mají tuto strukturu pojmenování <WorkspaceName>|<savedSearchId>|<scheduleId>|<ActionId> prostředků. Upozornění protokolu ve starší verzi rozhraní API se zobrazují s výše uvedeným skrytým názvem prostředku společně se skupinami prostředků a vlastnostmi upozornění.

Poznámka

Nepodporované znaky prostředku, jako je , se ve skrytých názvech prostředků nahradí za , což se také odrazí <, >, %, &, \, ?, / _ ve fakturačních informacích.

Poznámka

Upozornění protokolu pro Log Analytics, která se používaná ke spravování pomocí staršího rozhraní API pro upozornění Log Analytics a starších šablon uložených hledání a upozornění Log Analytics Přečtěte si další informace o přepnutí na aktuální rozhraní ScheduledQueryRules API. Správa pravidel upozornění by se měla provést pomocí staršího rozhraní API Log Analytics, dokud se nerozhodnete přepnout a nemůžete používat skryté prostředky.

Další kroky