Řešení problémů¶

Rady pro řešení nejčastěji se vyskytujících problémů:

Mnoho událostí končí u ostatních s HTTP 503 / `cluster_block_exception` / `no master`¶

To obvykle znamená, že Elasticsearch měl dočasný výpadek clusteru (například odpojení datového centra), nikoli že samotné události byly neplatné.

Vkladatel znovu zpracovává plnou hromadnou HTTP chybu 500, 502 a 503 na stejném kanálu a zpomaluje příjem při 503, dokud se zdraví clusteru neobnoví. Nesmí tyto chyby přesměrovávat na jiné.

Totéž platí, když zápis selže, protože primární shard cílového indexu je na nefunkčním místě (unavailable_shards_exception / HTTP 503): Depositor se pokusí znovu ve stejném pipeline (výchozí retry_errors zahrnuje unavailable_shards_exception) a tyto události neposílá jinam. Čekají v Kafce, dokud Elasticsearch nepřejde na repliku nebo se místo nevrátí. Viz Nastavení nouzového clusteru Elasticsearch.

Pokud toto stále vidíte po upgradu přes opravu, zkontrolujte verzi Depositor a [connection:ESConnection] retry_http_status / throttle_http_status.

Po přetočení trvá obvykle několik minut, než Elasticsearch zobrazí data.

Jakmile uplyne několik minut, zkontrolujte data lmio-tenant-others v sekci Discover v Kibana nebo v UI Discover v LogMan.io. Pokud žádná relevantní data nejsou, zkontrolujte téma others.tenant v Kafka UI. Chybové hlášky v logu by měly být dostatečně konkrétní, aby popsaly, proč nebylo možné data uložit do Elasticsearch. Obvykle to znamená, že je používáno nesprávné schéma. Viz sekce Event Lane nebo krok 8 v sekci Migrace.

Pro pokročilé uživatele: Když nastavíte prioritu šablony indexu v backup-lmio-tenant-events-eventlane-template (z kroku 4 v Migraci) z 0 na 2 nebo vyšší a provedete převrácení indexu, tato stará záložní šablona indexu bude použita k vytvoření nových indexů, zatímco nová šablona indexu vytvořená Depozitářem bude ignorována. To by vám mělo poskytnout více času na vyšetření problému v produkčních prostředích. Nezapomeňte potom snížit prioritu v backup-lmio-tenant-events-eventlane-template zpět na 0.

Úložiště SSD se kvůli Elasticsearchu plní¶

V tomto případě je potřeba upravit politiku životního cyklu v daném deklaraci event lane (například fortigate.yaml), aby se data přesunula z fáze hot do fáze warm dříve. Ve výchozím nastavení se data stávají teplými (warm) za 3 dny. Pro více informací o tom, jak nastavit vlastní politiku životního cyklu, viz sekce Event Lane.

Jaká je maximální velikost indexu a jak ji mohu změnit?¶

Výchozí životní politika selhání vkladatele má limit 16 GB na primární shard na index, takže výchozí maximální velikost indexu je tedy 1 shard * 16 GB * 2 pro repliku = 32 GB na index.

Chcete-li změnit maximální velikost indexu, musíte uvést vlastní životní cyklus v rámci deklarace event lane (například fortigate.yaml), kde specifikujete atribut max_primary_shard_size. Pro více informací o nastavení vlastního životního cyklu viz sekce Event Lane.

Existuje pouze index `lmio-tenant-events` bez číselného postfixu a není propojen s žádnou životním cyklem politiky¶

Každý index spravovaný vkladatelem musí končit na -00000x, například lmio-tenant-events-eventlane-000001.

Pokud tomu tak není, zkontrolujte prosím jak Docker logy, tak souborové logy (pokud jsou souborové logy nakonfigurovány). K Docker logům lze přistoupit pomocí následujícího příkazu:

docker logs -f -n 1000 <lmio-depositor>

Varování

Neexistuje jednoduchý způsob, jak přejmenovat existující index s názvem lmio-tenant-events, který nemá žádnou životní politiku, na lmio-tenant-events-eventlane-000001. Proto zastavte Depositor, smažte index lmio-tenant-events a poté znovu spusťte Depositor. Při každém restartu Depositoru vždy kontrolujte protokoly.

Existuje index s "Chybou životního cyklu indexu" a "no_node_available_exception", co se stalo?¶

Tento problém obvykle nastává, když je Elasticsearch restartován během fáze zmenšování indexu. Přesná zpráva je pak: NoNodeAvailableException[cidly se nenašel žádný uzel, na který by bylo možné přiřadit index [myindex] před zmenšením]

Aby bylo možné problém vyřešit:

V Kibana přejděte na Správa > Správa stacku > Správa indexů, poté na Indexy a vyberte svůj index kliknutím na jeho název.
V detailu indexu klikněte na Upravit nastavení.
Uvnitř nastavte následující hodnoty na null:

index.routing.allocation.require._name: null
index.routing.allocation.require._id: null

Klikněte na Uložit.
Přejděte na Správa > Nástroje pro vývojáře a spusťte následující příkaz, přičemž myindex nahraďte názvem svého indexu:

POST /myindex/_ilm/retry

Vraťte se do Správa stacku > Správa indexů, Indexy a zkontrolujte, zda chyba ILM u daného indexu zmizela.

V `others` je mnoho záznamů a nemohu najít ty, které mají atribut `interface`¶

Kafka Console Consumer lze použít k získávání událostí z více témat, zde ze všech témat začínajících na events.

Dále můžete vyhledat pole v uvozovkách:

/usr/bin/kafka-console-consumer --bootstrap-server localhost:9092 --whitelist "events.*" | grep '"interface"'

Tento příkaz vám poskytuje všechny příchozí záznamy s atributem interface ze všech témat events.