Profylaktická kontrola

Úvod

Profylaktické kontroly MUSÍ být prováděny pravidelně (týdně, měsíčně atd.), ideálně ve stejný den v týdnu a v konzistentní čas. Je zásadní zohlednit variace v množství a frekvenci příchozích událostí, které mohou kolísat na základě dne v týdnu, pracovní doby a státních svátků.

Doporučená periodicita profylaktických kontrol:

• 1x týdně v období "hypercare"; období hypercare je stabilizační období po počáteční instalaci produktu, trvající přibližně 3 měsíce.
• 1x měsíčně

Výsledky profylaktických kontrol by měly být zdokumentovány ve dvou samostatných reportech:

• Report dodavatele – Udržován pro interní sledování v systému dodavatele (TeskaLabs).
• Report klienta – Sdílen s koncovým uživatelem prostřednictvím jejich podpůrného Slack kanálu nebo jiného podpůrného kanálu.

Note

Dbejte na to, abyste jasně vysvětlili a popsali zjištění, a zajistěte, že závažné problémy jsou již interně řešeny. Pokud je řešení na cestě, vždy to v reportu komunikujte.

Přerozdělení podpory

Seznam jednotlivců zapojených do konkrétních projektů lze nalézt v interní dokumentaci. Pokud nastane problém, eskalujte ho vhodně na základě zapojeného klienta, partnera nebo zákazníka.

Postup profylaktické kontroly

Požadavky

• Přístup (HTTPS, SSH) k příslušné instalaci TeskaLabs LogMan.io.
• Ujistěte se, že všechny tenanty, které máte k dispozici, jsou během těchto kontrol přezkoumány.

Funkčnosti TeskaLabs LogMan.io

Kontrola navigace a funkčnosti

1. Prozkoumejte každý přiřazený tenant kontrolou všech komponent v postranním panelu:
2. Objev: Ověřte přístupnost logů, výkon vyhledávání a provádění dotazů. Ujistěte se, že jsou logy správně indexovány a dostupné.
3. Dashboardy: Zkontrolujte správnost vizualizace dat, aktualizované widgety a správné filtrování. Ujistěte se, že grafy a diagramy odrážejí očekávané metriky.
4. Reporty: Ověřte generování reportů, jejich formátování a přesnost dat. Ujistěte se, že naplánované reporty jsou doručovány správně.
5. Export: Otestujte extrakci dat a ujistěte se, že exportované soubory jsou správně formátovány a obsahují očekávaný obsah.
6. Archiv: Ověřte, že archivované logy jsou dostupné a uloženy podle očekávání.
7. Zdroje logů:
   • Sběrače: Ujistěte se, že všechny sběrače jsou aktivní, přijímají data a jsou správně nakonfigurovány.
   • Event Lanes: Ověřte správnou klasifikaci událostí a potvrďte, že nedochází k anomáliím v zpracování.
8. Základní linie: Zkontrolujte základní metriky, abyste zajistili, že odpovídají očekávaným prahům, a přezkoumejte změny.
9. Upozornění: Potvrďte, že mechanismy upozornění fungují, otestujte spouštěče upozornění a přezkoumejte eskalace.
10. Nástroje: Ujistěte se, že vestavěné nástroje (např. Grafana, Kibana) fungují podle očekávání.
11. Vyhledávání: Ověřte tabulky pro vyhledávání na přesnost a ujistěte se, že jsou správně odkazovány v zpracování událostí.
12. Knihovna: Potvrďte dostupnost a správné verze sdílených zdrojů a obsahu.
13. Údržba:
    • Konfigurace: Ujistěte se, že systémová nastavení a konfigurace jsou správně udržovány a aktualizovány.
    • Služby: Ověřte, že backendové služby jsou funkční a běží hladce.

14. Autentizace a role:

    • Přihlašovací údaje: Zkontrolujte dostupné přihlašovací údaje a udržujte je aktuální.
    • Tenanty: Potvrďte přístup k tenantům a zajistěte správnou izolaci dat.
    • Relace: Přezkoumejte logy relací na anomálie nebo pokusy o neoprávněný přístup.
    • Role: Ujistěte se, že kontroly přístupu na základě rolí jsou správně vynucovány.
    • Zdroje: Ověřte dostupnost sdílených systémových zdrojů.
    • Klienti: Ujistěte se, že konfigurace klientů jsou správně udržovány a aktuální.

15. Poznámka: Pokud nejste superuživatel, nemusíte vidět každou sekci uvedenou výše.

ASAB-IRIS - Testování šablon

• Otestujte odeslání e-mailu a zprávy na Slack prostřednictvím knihovny.
• Jakékoli problémy v této části by měly být hlášeny interně.

Monitorování zdrojů logů

Časové zóny logů

• Kde zkontrolovat: Obrazovka Objev TeskaLabs LogMan.io
• Zkontrolujte logy s @timestamp v budoucnosti (nyní+2H nebo více)
• Hlášení problémů:
• Nesprávné časové zóny by měly být hlášeny interně.
• Pokud je problém způsoben nesprávnými nastaveními logovacího zařízení, hlaste to do podpůrného Slack kanálu klienta.
• Analyzujte zdroj (host.hostname, lmio.source nebo IP adresa) a zahrňte to do profylaktického reportu.

Zdroje logů

• Kde zkontrolovat: Obrazovka Objev – Event Lanes, obrazovka Event lane a Baseliner
• Cíl: Zajistit, aby každý připojený zdroj logů byl aktuálně aktivní, prozkoumat všechny výpadky a anomálie v logování.
• Hlášení problémů:
• Interně a do podpůrného Slack kanálu klienta/partnera.

Ostatní události

• Kde zkontrolovat: TeskaLabs LogMan.io - index lmio-others-events na obrazovce Objev
• Běžné zdroje chybových logů:
• Logy depository
• Nestrukturované logy
• Víceřádkové a fragmentované logy
• Hlášení problémů: Interně týmu parsec.

Systémové logy

• Kde zkontrolovat: TeskaLabs LogMan.io - Systémový tenant, index Události & Ostatní
• Hlášení problémů:
• Různé typy logů se mohou objevit zde; zaměřte se na chybové a varovné logy.
• Hlášení nálezů interně nebo do podpůrného Slack kanálu klienta, pokud je to nutné.

Baseliner

• Kde zkontrolovat: Obrazovka Baseliner TeskaLabs LogMan.io
• Zahrňte kontrolu přesměrování z obrazovky Objev na obrazovku Baseliner.
• Hlášení problémů: Pokud je Baseliner neaktivní, hlaste to interně.

Monitorování Elasticsearch

• Kde zkontrolovat: Grafana, dedikovaný dashboard – Monitorování ElasticSearch a Kibana Stack
• Kontrola vzorových dat za posledních 24 hodin
• Ukazatele k monitorování:
• Neaktivní uzly → Měly by být nula
• Zdraví systému → Mělo by být zelené; okamžitě eskalujte, pokud je žluté nebo červené.
• Nepřiřazené shardy → Měly by být nula a zelené; žluté nebo nenulové vyžaduje monitorování a hlášení.
• JVM Heap → Monitorujte využití heapu, aby zůstalo pod 75 %, aby se předešlo nadměrnému garbage collection, což může zpomalit provádění dotazů. Pokud využití heapu často překračuje 85 %, zvažte zvýšení přidělené paměti nebo optimalizaci dotazů a indexování.
• Přiřazené ILM → Zkontrolujte, že politiky ILM jsou správně aplikovány na indexy, aby se zajistilo, že data jsou přesunována podle definovaných strategií uchovávání a výkonu. Nesprávně nakonfigurované ILM může vést k vyšším nákladům na úložiště a zhoršenému výkonu vyhledávání.
• Hlášení problémů: Okamžitě eskalujte závažné problémy interně.

Přehled na systémové úrovni

• Kde zkontrolovat: Grafana, dedikovaný dashboard – Přehled na systémové úrovni
• Kontrola vzorových dat za posledních 24 hodin
• Metriky k monitorování:
• Využití disku: Nemělo by přesáhnout 80 % (kromě /boot, který by neměl přesáhnout 95 %).
• Zátěž: Neměla by přesáhnout 40 %; maximální zátěž by měla odpovídat počtu jader.
• CPU Nemělo by překročit 85 % využití po delší dobu.
• IOWait: Mělo by být pod 10 %; hodnoty nad 20 % naznačují významné zpoždění při čtení/zápisu na disk.
• Využití RAM: Nemělo by překročit 70 %; trvalé využití nad 80 % vyžaduje vyšetřování.
• Swap Měl by být minimální; časté nebo vysoké využití swapu naznačuje tlak na paměť a vyžaduje další analýzu.
• Hlášení problémů: Hlášení interně.

Přehled zpoždění Kafka

• Definice: Zpoždění v tomto kontextu se vztahuje na zpoždění mezi tím, kdy je zpráva vyprodukována do Kafka tématu, a kdy je zpracována příslušnou skupinou spotřebitelů. Vysoká hodnota zpoždění naznačuje, že spotřebitelé nezpracovávají zprávy dostatečně rychle, což může vést k potenciálním zpožděním zpracování dat a neefektivnostem systému.
• Kde zkontrolovat: Grafana, dedikovaný dashboard – Přehled zpoždění Kafka
• Skupiny k monitorování:
• lmio parsec
• lmio depositor
• lmio baseliner
• lmio correlator
• Klíčová metrika: Hodnota zpoždění by se neměla zvyšovat v průběhu času.
• Hlášení problémů:
• Pokud se zpoždění zvyšuje ve srovnání s předchozím týdnem, hlaste to v interním Slack kanálu.
• Závažné zvýšení zpoždění by mělo být okamžitě eskalováno.

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

• Kde zkontrolovat: Kibana, Monitorování stacku nebo Správa stacku
• Kroky:
• Klikněte na Indexy.
• Seřaďte sloupec Dat od největšího po nejmenší.
• Prozkoumejte indexy větší než 200 GB.
• Kontrola ILM:
• Pokud index postrádá číselný suffix, není připojen k ILM.
• Zkontrolujte, zda jsou indexy správně klasifikovány jako hot/warm/cold.
• Shardování:
• Shardování by nemělo překročit 500-600 shardů na uzel, aby se předešlo nadměrnému využití zdrojů.
• Ověřte alokaci shardů napříč uzly clusteru, abyste zajistili vyvážené rozložení.
• Hlášení problémů: Hlášení interně a okamžitě eskalujte.

Počítání EPS

• Definice: EPS se vztahuje na počet logových událostí přijatých za sekundu. Monitorování EPS pomáhá sledovat rychlost příjmu systému, detekovat anomálie a zajistit, aby systém mohl efektivně zvládat špičkové zatížení.
• Kde zkontrolovat: UI LogMan.io za posledních 7 dní
• Metriky k získání:
• PRŮMĚRNÁ hodnota
• MAXIMÁLNÍ hodnota