# Jak udržet Logmanager v optimální kondici

Pravidelná kontrola klíčových metrik týkajících se zdraví a výkonu Logmanageru je ideální způsob jak udržet systém v optimální kondici. V tomto průvodci se podíváme na nejčastější příčiny a řešení problémů, se kterými se setkáváme při řešení zákaznických požadavků.

V tomto průvodci se dozvíte, jak:

- Udržovat hardware appliance v dobrém stavu a aktualizovaný
- Monitorovat fronty událostí a trendy EPS
- Odhalovat problémy způsobené DNS latencí
- Spravovat diskový prostor a retenci dat
- Kontrolovat stav Elasticsearch a využití systémových prostředků
- Optimalizovat počet databázových polí
- Sledovat vytížení parsing enginu
- Identifikovat neefektivní nebo pomalé parsery
- Odhalovat zdroje logů, které nadměrně zatěžují systém

Dodržováním následujících doporučení můžete potenciální problémy odhalit dříve, než ovlivní výkon systému, zpracování logů nebo dostupnost historických dat.

## Hardware

Závažné hardwarové problémy jsou poměrně vzácné. Pokud však nastanou, mohou mít na provoz Logmanageru nepoměrně větší dopad, než kolik úsilí je potřeba k jejich prevenci.

Začněte přihlášením do iDRACu, management platformy serveru dostupné prostřednictvím dedikovaného management rozhraní. Přihlašovací údaje naleznete na výsuvném štítku umístěném na přední straně serveru.

### Aktualizace firmwaru

Prvním krokem by měla být kontrola aktuálně nainstalovaných verzí firmwaru a jejich porovnání s nejnovějšími verzemi dostupnými od výrobce.

Kontrolu provedete v nabídce **Maintenance → System Update → Manual Update**. Po zaškrtnutí volby **Use Default Address** se iDRAC připojí přímo k repozitáři firmwarů společnosti Dell, vyhledá dostupné aktualizace a navrhne optimální pořadí aktualizace jednotlivých komponent.

Pravidelné aktualizace firmwaru pomáhají minimalizovat riziko problémů způsobených známými chybami a přispívají k celkové stabilitě systému.

![Enabling Dell firmware updates at Logmanager](https://logmanager.com/wp-content/uploads/2026/06/default-address-option-idrac-1024x212.png)*Fig. 1: Nastavení updatů firmwaru Dell*.### Kontrola hardwarových chyb

Dalším krokem je kontrola hardwarových chyb.

Logmanager automaticky generuje upozornění na nejzávažnější hardwarové problémy. Důležité notifikace však mohou někdy zapadnout mezi ostatní e-maily nebo být přehlédnuty. Proto doporučujeme pravidelně kontrolovat vestavěné přehledy o stavu systému v iDRACu a ověřovat, že se v nich nevyskytují žádné chyby ani varování.

![Hardware errors check in Logmanager](https://logmanager.com/wp-content/uploads/2026/06/hardware-errors-check-logmanager-1024x737.png)*Fig. 2: Upozornění na hardwarové problémy v Logmanageru*.## Software

Aplikační stack Logmanageru nabízí několik způsobů, jak sledovat stav systému prostřednictvím webového rozhraní. Mezi nejdůležitější přehledy patří **System Status**, **Database Status** a **Parsing Engine Metrics**.

## Stav systému

### Kontrola fronty událostí (Event Queue)

Fronta příchozích událostí obsahuje logy, které čekají na zaindexování do Elasticsearch. Pokud velikost fronty roste, znamená to, že se někde v procesu zpracování vytvořilo úzké hrdlo.

V ideálním případě zůstává fronta většinu času prázdná. Krátkodobě může narůst během špiček v objemu příchozích dat, po jejich odeznění by se však měla rychle vrátit na běžnou úroveň.

Pokud fronta delší dobu roste a nevykazuje známky poklesu, může dosáhnout limitu 50 GB. Po jeho překročení začne systém data ve frontě automaticky odstraňovat.

![event queue check in Logmanager](https://logmanager.com/wp-content/uploads/2026/06/event-queue-check-logmanager-1024x362.png)*Fig. 3: Graf fronty událostí v Logmanageru.*### Kontrola trendu EPS

Rychlost indexace databáze, měřená v EPS (Events Per Second), je důležitým ukazatelem jejího zatížení.

Jednotlivé tiery Logmanageru zvládnou zpracovávat rozdílné objemy událostí. Doporučené limity EPS pro jednotlivé modely naleznete v [produktovém datasheetu](https://logmanager.com/wp-content/uploads/2026/05/Logmanager-Datasheet-04-26-CZ.pdf).

Krátkodobé špičky zpravidla nepředstavují problém. Pokud však Logmanager dlouhodobě zpracovává více událostí, než pro jaké byl dimenzován, začne růst fronta příchozích událostí a může dojít ke ztrátě dat.

V takovém případě doporučujeme snížit objem příchozích logů již na jejich zdroji. Ve většině prostředí bývají největším producentem logů firewally, a proto představují vhodný výchozí bod pro optimalizaci.

![EPS trend check in Logmanager](https://logmanager.com/wp-content/uploads/2026/06/eps-trend-check-logmanager-1024x403.png)*Fig. 4: EPS trend v Logmanageru.*### Kontrola odezvy DNS

DNS latence má na výkon Logmanageru velký vliv.

Pokud je zapnut DNS překlad, může být zpracování každé události zpomaleno čekáním na odpověď DNS serveru. Po dobu čekání je navíc zpracovávání dalších logů blokováno a systém je nemůže obsloužit.

V důsledku toho se může stát, že jinak zdravý Logmanager bude zpracovávat pouze zlomek očekávaného počtu EPS.

Abyste podobným situacím předešli, pravidelně kontrolujte odezvu DNS serverů a sledujte, zda se pohybuje v doporučených hodnotách.

Pokud jsou odezvy dlouhodobě vysoké, zvažte dočasné vypnutí DNS překladu v nabídce **Network → DNS → Resolve Hostnames**, dokud nebude příčina problému odstraněna.

![DNS response times check in Logmanager](https://logmanager.com/wp-content/uploads/2026/06/dns-response-times-check-logmanager.png)*Fig. 5: Graf určený pro monitoring odezvy DNS serveru v Logmanageru.*### Kontrola dostupného diskového prostoru

Přestože Logmanager obsahuje mechanismy, které diskový prostor spravují automaticky, je dobré mít přehled o aktuálním stavu.

Pokud začne docházet volné místo na disku, systém začne odstraňovat nejstarší indexy, aby uvolnil prostor potřebný pro provoz Elasticsearch.

Pokud jste například původně ukládali pouze desítky gigabajtů dat denně a postupně jste se dostali na stovky gigabajtů nebo jednotky terabajtů, může docházet k mazání více indexů během jednoho dne.

Pravidelná kontrola dostupného diskového prostoru vám pomůže se informovaně rozhodovat o případném rozšíření kapacity úložiště.

![Available disk space check in Logmanager](https://logmanager.com/wp-content/uploads/2026/06/available-disk-space-check-logmanager-1024x575.png)*Fig. 6: Graf vývoje dostupného prostoru na disku Logmanageru.*## Stav databáze

### Kontrola stavu databáze (DB State)

Stav vyhledávacího enginu představuje jednoduchý indikátor toho, zda databáze funguje správně.

Jeho hodnoty mohou být **zelená**, **žlutá** nebo **červená**.

Pokud je stav zelený nebo žlutý, zpravidla není důvod k obavám. Červený stav by se měl objevovat pouze krátkodobě. Pokud červený stav přetrvává delší dobu, doporučujeme kontaktovat technickou podporu.

![Database status check in Logmanager](https://logmanager.com/wp-content/uploads/2026/06/database-status-check-logmanager-1024x540.png)*Fig. 7: Kontrola stavu databáze v Logmanageru.*### Kontrola otevřených indexů

Provoz Elasticsearch je relativně náročný na systémové prostředky a ideální stav je takový, kdy jsou otevřené pouze skutečně potřebné indexy. Každý otevřený index totiž spotřebovává nezanedbatelné množství operační paměti.

Pokud se množství dostupné paměti blíží nule, začne se výkon systému zhoršovat a v krajním případě může dojít až k nestabilitě.

Těmto situacím lze předejít pravidelnou kontrolou seznamu indexů a uzavíráním těch, které nejsou aktuálně potřeba. Specifickým případem jsou obnovené zálohy. Ty nelze odstranit automaticky a mohou zbytečně spotřebovávat systémové prostředky, pokud je nesmažete ručně.

![Open indices check in Logmanager](https://logmanager.com/wp-content/uploads/2026/06/open-indices-check-logmanager-1024x684.png)*Fig. 8: Tabulka indexů v Logmanageru.*### Kontrola počtu databázových polí

Počet polí lze přirovnat k počtu sloupců v klasické relační databázi. Čím více polí databáze obsahuje, tím pomalejší budou vyhledávací dotazy.

Doporučujeme nepřekračovat hranici **1 000 polí**, která je dostatečná pro většinu scénářů a zároveň nepředstavuje riziko z pohledu výkonu.

Počet polí zjistíte otevřením dashboardu **Log Overview** a sjetím na jeho konec do sekce **All Events**. Pokud se číslo uvedené v závorce vedle položky **All** blíží hodnotě 1 000, doporučujeme prověřit parsery, které mohou vytvářet příliš mnoho databázových polí.

K dispozici jsou také takzvané **lite parsery**, které lze aktivovat v nabídce **Parser → Lookup Tables → Lite-Parsing Settings**. Tyto parsery snižují počet polí vytvářených pro jednotlivé zdroje logů.

![Database field count check in Logmanager](https://logmanager.com/wp-content/uploads/2026/06/database-field-count-check-logmanager.png)*Fig. 9: Kontrola počtu databázových polí.*## Parsing Engine

Dashboard **Parsing Engine Metrics** patří mezi nejdůležitější nástroje při řešení výkonnostních problémů Logmanageru.

Dostanete se k němu otevřením **System Status**, kliknutím na **General / System Status** v levém horním rohu a následným výběrem dashboardu **Parsing Engine Metrics**.

### Kontrola vytížení parsing enginu

První metrikou, kterou byste měli sledovat, je kapacita parsing enginu.

Pro klasifikaci, parsování a generování alertů je k dispozici omezené množství výpočetních prostředků. Pokud je kapacita plně vyčerpána a do systému zároveň přicházejí další logy, začne klesat hodnota EPS a může se začít plnit fronta událostí.

V grafu **Total Parser Usage** ověřte, zda máte dostatečnou rezervu výkonu. Obecně lze za bezpečnou zónu považovat zelenou část grafu, která odpovídá přibližně 75 % celkové kapacity.

Pokud se systém dlouhodobě pohybuje ve žluté nebo červené části grafu, doporučujeme prozkoumat další metriky dostupné na dashboardu a identifikovat zdroj problému.

![Total parser usage check in Logmanager](https://logmanager.com/wp-content/uploads/2026/06/parsing-capacity-threshold-check-logmanager-1024x420.png)*Fig. 10: Graf vývoje kapacity parsing enginu*.### Měření času stráveného zpracováním parserů

Vestavěné klasifikátory, parsery i alerty procházejí před vydáním důkladným testováním a výkonnostními benchmarky. Vlastní, custom parsery však často vznikají organicky a bez hlubší optimalizace. Je tedy možné, že některý z vašich custom parserů obsahuje problematickou smyčku nebo jinou konstrukci, která negativně ovlivňuje výkon.

Takové problémy bývá obtížné odhalit bez vhodných metrik.

Právě k tomu slouží grafy **Time Spent Processing X**, které pomáhají identifikovat parsery s neobvykle dlouhou dobou zpracování.

Pokud některý parser vykazuje výrazně delší dobu zpracování než ostatní, doporučujeme zkontrolovat jeho implementaci a zaměřit se na případné redundantní nebo neoptimalizované části kódu.

### Monitoring nejvíce vytěžujících zdrojů (Top Logging Hosts)

S rostoucím počtem zdrojů logů se snadno stane, že některý z nich začne generovat výrazně větší objem dat, než je obvyklé, a zatěžovat tak systémové prostředky.

Takové zdroje lze snadno identifikovat pomocí grafu **Top Logging Hosts**.

Graf umožňuje sledovat objem logů v čase, určit konkrétní okamžik, kdy k nárůstu došlo, a následně dohledat související změny konfigurace nebo jiné příčiny zvýšeného objemu logovaných událostí.

![Top logging hosts chart in Logmanager](https://logmanager.com/wp-content/uploads/2026/06/top-logging-hosts-check-logmanager-1024x295.png)*Fig. 11: Graf poskytující přehled o nejvýznamnějších zdrojích dat.*## **Závěr**

Pravidelná kontrola stavu Logmanageru patří mezi nejjednodušší způsoby, jak dlouhodobě zajistit jeho bezproblémový provoz.

Sledováním stavu hardwarovu, front událostí, výkonu databáze, vytížení parsing enginu a dostupné kapacity úložiště a dalších metrik můžete odhalit potenciální problémy dříve, než ovlivní zpracování logů, vyhledávání nebo retenci dat.

Většinu problémů popsaných v tomto průvodci lze odhalit včas a vyřešit s minimálními náklady. Pokud se tyto kontroly stanou součástí vaší pravidelné provozní rutiny, pomohou vám udržet Logmanager ve špičkové kondici i při rostoucím objemu dat a nárocích na výkon.