Přeskočit obsah

Manuál pro profylaktické kontroly

Profylaktická kontrola je systematické preventivní hodnocení pro ověření, že systém funguje správně, a pro identifikaci a zmírnění potenciálních problémů, než se eskalují do závažnějších nebo kritických problémů. Pravidelným prováděním profylaktických kontrol můžete proaktivně udržovat integritu, spolehlivost a efektivitu svého systému TeskaLabs LogMan.io a minimalizovat riziko neočekávaných selhání nebo přerušení, které by mohly nastat, pokud by se nechaly nevyřešené.

Podpora

Pokud potřebujete další informace nebo podporu nad rámec toho, co zde vidíte, kontaktujte svůj Slack kanál podpory TeskaLabs LogMan.io nebo pošlete e-mail na support@teskalabs.com. Rádi vám pomůžeme.

Provádění profylaktických kontrol

Důležité

Provádějte profylaktické kontroly v konzistentních intervalech, ideálně ve stejný den v týdnu a přibližně ve stejnou dobu. Pamatujte, že objem a načasování příchozích událostí se mohou lišit v závislosti na dni v týdnu, pracovní době a svátcích.

Během profylaktických kontrol se ujistěte, že provedete komplexní přehled všech dostupných tenantů.

Prozkoumejte každý z následujících komponent vašeho instalace TeskaLabs LogMan.io podle našich doporučení a v případě potřeby hlaste problémy.

Funkčnosti TeskaLabs LogMan.io

Umístění: Postranní panel TeskaLabs LogMan.io

Cíl: Zajištění, že každá funkčnost aplikace TeskaLabs LogMan.io funguje správně

V rámci přiřazeného tenantu důkladně prozkoumejte každý komponent uvedený v postranním panelu (Průzkumník, Dashboardy, Exporty, Vyhledávání, Reporty atd.), abyste zajistili jejich správný provoz. Problémy zjištěné v této části by měly být hlášeny vašemu kanálu podpory TeskaLabs. To může zahrnovat problémy jako vyskakovací chyby při otevírání sekce z postranního panelu, ztrátu dostupnosti některých nástrojů nebo například nemožnost otevřít Dashboardy.

Hlášení problémů: Pro obecné hlášení použijte Slack kanál podpory.

Monitorování zdroje logů

Umístění: Obrazovka Průzkumník TeskaLabs LogMan.io nebo dedikovaný dashboard

Cíl: Zajištění, že každý zdroj logů je aktivní a funguje podle očekávání a že nejsou nalezeny žádné anomálie (například výpadek, špice nebo něco neobvyklého). Toto je také zásadní pro viditelnost zdroje logů.

Poznámka: Zvažte začlenění základních linií jako další možnost pro kontrolu zdrojů logů.

Monitorování zdroje logů lze provádět individuálním přezkoumáním každého zdroje logu nebo vytvořením přehledového dashboardu vybaveného widgety pro vizuální sledování aktivity každého zdroje logu. Doporučujeme vytvoření dashboardu s čárovými grafy.

Vyšetřování by mělo vždy pokryt vzorek dat mezi každou profylaktickou kontrolou.

Hlášení problémů: V případě neaktivního zdroje logů proveďte další šetření a nahlaste to na kanál podpory TeskaLabs LogManio Slack.

Časová pásma logů

Umístění: Obrazovka Průzkumník TeskaLabs LogMan.io

Cíl: Zajištění, že nejsou žádné nesrovnalosti mezi vaším časovým pásmem a časovým pásmem přítomným v logách

Zjistěte, zda se v logách nacházejí nějaké s hodnotou @timestamp, která je časově budoucí. To můžete provést filtrováním časového rozsahu od současnosti do 2 hodin (nebo více) od současnosti.

Hlášení problémů: Pro obecné hlášení použijte Slack podporu projektu.

Pokud se problém jeví jako spojený s nastavením logovacího zařízení, prosím prozkoumejte to dále ve své vlastní síti.

Ostatní události

Umístění: Obrazovka Průzkumník TeskaLabs LogMan.io, index lmio-others-events

Cíl: Zajištění, že všechny události jsou správně parsovány pomocí Parsec nebo Parser.

Ve většině instalací shromažďujeme chybové logy z následujících oblastí:

  • Parser

  • Parsec

  • Dispatcher

  • Depositor

  • Nestrukturované logy

Logy, které nejsou správně parsovány, spadají do others index. Ideálně by žádné logy neměly být přítomny v others index.

Hlášení problémů: Pokud jsou v others index nalezeny nějaké logy, jako jsou ty, které indikují chyby nesprávného parsování, obecně to není závažný problém vyžadující okamžitou pozornost. Prozkoumejte tyto logy dále a hlaste to na kanál podpory TeskaLabs LogMan.io Slack.

Systémové logy

Umístění: TeskaLabs LogMan.io - Systémový tenant, index Události & Ostatní.

Cíl: Zajištění, že systém funguje správně a že nejsou žádné neobvyklé nebo kritické systémové logy, které by mohly signalizovat interní problém

Hlášení problémů: V této sekci může být nalezena řada typů logů. Hlášení může být provedeno buď prostřednictvím Slack kanálu podpory TeskaLabs LogMan.io nebo ve vaší infrastruktuře.

Baseliner

Note

Baseliner je zahrnut pouze v pokročilých nasazeních LogMan.io. Pokud byste chtěli upgradovat LogMan.io, kontaktujte podporu a rádi vám pomůžeme.

Umístění: Obrazovka Průzkumník TeskaLabs LogMan.io filtrováním event.dataset:baseliner

Cíl: Zajištění, že funkce Baseliner funguje správně a detekuje odchylky od vypočítané základní aktivity.

Hlášení problémů: Pokud Baseliner není aktivní, ohlaste to na Slack kanál podpory TeskaLabs LogMan.io.

Elasticsearch

Umístění: Grafana, dedikovaný Elasticsearch dashboard

Cíl: Zajištění, že nejsou žádné poruchy spojené s Elasticsearch a službami s ním spojenými.

Hodnocení by mělo být vždy založeno na vzorku dat za posledních 24 hodin. Tento operační dashboard poskytuje indikaci správné funkce Elasticsearch.

Klíčové ukazatele:

  • Neaktivní uzly by měly být na nule.

  • Systémové zdraví by mělo být zelené. Jakýkoliv indikace žluté nebo červené by měla být okamžitě eskalována na Slack kanál podpory TeskaLabs LogMan.io.

  • Nepřiřazené shardy by měly být na nule a označeny zeleně. Jakákoli hodnota v žluté nebo vyšší si zaslouží monitorování a hlášení.

Hlášení problémů: Pokud jsou zjištěny nějaké problémy, zajistěte jejich rychlou eskalaci. Další šetření klastru Elastic může být provedeno v Kibana/Stack monitoringu.

Uzly

Podrobné informace o zdraví uzlů lze nalézt v Elasticsearch. JVM Heap monitoruje využití paměti.

Přehled

Aktuální EPS (události za sekundu) celého klastru Elastic je viditelný.

Monitorování velikosti indexů a životního cyklu

Umístění: Kibana, Stack monitoring nebo Stack management

Postupujte podle těchto kroků pro analýzu indexů ohledně abnormální velikosti:

  1. Přistupte k sekci "Indexy".
  2. Přistupte k filtrování sloupce "Data", řadící od největšího po nejmenší.
  3. Prozkoumejte indexy, abyste identifikovali ty, které vykazují výrazně větší velikost ve srovnání s ostatními.

Přijatelná velikost indexu je předmětem diskuse, ale obecně se za přijatelnou považují indexy do 200 GB.

Jakékoliv indexy přesahující 200 GB by měly být hlášeny.

V případě indexů spojených s ILM (index lifecycle management) je klíčové ověřit stav indexu. Pokud indexu chybí řetězec čísel na konci názvu, znamená to, že není propojen s ILM politikou a může růst bez automatického přehazování. K potvrzení toho, přezkoumejte vlastnosti indexu, abyste zjistili, zda spadá pod kategorii hot, warm nebo cold. Když indexy nejsou spojené s ILM, mají tendenci zůstávat ve stavu hot nebo vykazovat nepravidelné přesuny mezi stavy hot, cold a warm.

Mějte na paměti, že vyhledávání nemají ILM a měly by být vždy považovány za ve stavu hot.

Hlášení problémů: Hlášení na dedikovaný Slack kanál podpory projektu. Taková hlášení by měla být brána s nejvyšší vážností a okamžitě eskalována.

Přehled na systémové úrovni

Umístění: Grafana, dedikovaný System Level Overview dashboard

Hodnocení by mělo být vždy založeno na vzorku dat za posledních 24 hodin.

Klíčové metriky ke sledování:

  • Využití disku: Všechny hodnoty nesmí přesáhnout 80 %, kromě /boot, který by neměl přesáhnout 95 %.

  • Zátěž: Hodnoty nesmí přesáhnout 40 %, a maximální zatížení by mělo odpovídat počtu jader.

  • IOWait: Označuje zpracování dat a měla by pouze registrovat jako malé procento, což znamená, že zařízení čeká na načtení dat z disku.

  • Využití RAM: Další úvahy by měly být učiněny ohledně nastavení prahových hodnot vysoké hodnoty.

V případě více serverů zajistěte, že hodnoty jsou kontrolovány pro každý z nich.

Hlášení problémů: Hlášení na dedikovaný Slack kanál podpory projektu.

Burrow Consumer Lag

Umístění: Grafana, dedikovaný Burrow Consumer Lag dashboard

Pro monitorování Kafka, pečlivě přezkoumejte tento dashboard pro consumerGroup, se specifickým zaměřením na:

  • lmio dispatcher

  • lmio depositor

  • lmio baseliner

  • lmio correlator

  • lmio watcher

Rostoucí hodnota zpoždění v průběhu času signalizuje problém, který je potřeba okamžitě řešit.

Hlášení problémů: Pokud se zpoždění zvyšuje ve srovnání s předchozí profylaxe, okamžitě to nahlaste na Slack kanál podpory.

Monitorování Depositoru

Umístění: Grafana, dedikovaný Depositor dashboard.

Klíčové metriky ke sledování:

  • Neúspěšné bulky - Musí být zelené a rovné nule

  • Velikost výstupní fronty bulků

  • Pracovní cyklus

  • EPS IN & OUT

  • Úspěšné bulky

  • Neúspěšné bulky

Hlášení problémů: Hlášení na dedikovaný Slack kanál podpory projektu.