ElasticSearch Nastavení
Index Šablony
Než se data nahrají do ElasticSearch, měla by být přítomna index šablona, aby byly správné datové typy přiřazeny každému poli.
Toto je obzvláště nutné pro časová pole, která by bez index šablony nefungovala a nemohla by být použita pro třídění a vytváření index vzorů v Kibana.
ElasticSearch index šablona by měla být přítomna v repozitáři site-
pod názvem es_index_template.json
.
Pro vložení index šablony pomocí PostMan nebo Kibana, vytvořte následující HTTP požadavek na instanci ElasticSearch, kterou používáte:
PUT _template/lmio-
{
// Nasadit na <SPECIFY_WHERE_TO_DEPLOY_THE_TEMPLATE>
"index_patterns" : ["lmio-*"],
"version": 200721, // Zvýšení při každém vydání
"order" : 9999998, // Snížení při každém vydání
"settings": {
"index": {
"lifecycle": {
"name": "lmio-",
"rollover_alias": "lmio-"
}
}
},
"mappings": {
"properties": {
"@timestamp": { "type": "date", "format": "strict_date_optional_time||epoch_millis" },
"rt": { "type": "date", "format": "strict_date_optional_time||epoch_second" },
...
}
}
Tělo požadavku je obsah es_index_template.json
.
Index Životní cyklus Správa
Index Životní cyklus Správa (ILM) v ElasticSearch slouží k automatickému uzavření nebo smazání starých indexů (např. s daty staršími tří měsíců), takže je zachován výkon vyhledávání a datové úložiště je schopné ukládat současná data. Nastavení je přítomno v tzv. ILM politice.
ILM by mělo být nastaveno předtím, než jsou data posílána do ElasticSearch, takže nový index najde a spojí se s příslušnou ILM politikou. Pro více informací odkazujeme na oficiální dokumentaci: https://www.elastic.co/guide/en/elasticsearch/reference/current/getting-started-index-lifecycle-management.html
LogMan.io komponenty jako Dispatcher pak používají specifikovaný ILM alias (lm_) a ElasticSearch automaticky vkládá data do příslušného indexu přiřazeného k ILM politice.
Nastavení by mělo být provedeno následujícím způsobem:
Vytvořit ILM politiku
Kibana
Kibana verze 7.x může být použita pro vytvoření ILM politiky v ElasticSearch.
1.) Otevřete Kibana
2.) Klikněte na Správa v levém menu
3.) V sekci ElasticSearch klikněte na Index Životní cyklus Politiky
4.) Klikněte na Modré tlačítko Vytvořit politiku
5.) Zadejte její název, který by měl být stejný jako prefix indexu, např. lm_
6.) Nastavte maximální velikost indexu na požadovanou rollover velikost, např. 25 GB (velikost rollover)
7.) Nastavte maximální věk indexu, např. 10 dní (čas rollover)
8.) Klikněte na přepínač na dolním obrazovce ve fázi Smazání, a zadejte dobu po které by měl být index smazán, např. 120 dní od rollover
9.) Klikněte na Zelené tlačítko Uložit politiku
Použijte politiku v index šabloně
Upravte index šablonu(y)
Přidejte následující řádky do JSON index šablony:
"settings": {
"index": {
"lifecycle": {
"name": "lmio-",
"rollover_alias": "lmio-"
}
}
},
Kibana
Kibana verze 7.x může být použita pro propojení ILM politiky s index šablonou ElasticSearch.
1.) Otevřete Kibana
2.) Klikněte na Správa v levém menu
3.) V sekci ElasticSearch klikněte na Správa Indexu
4.) Nahoře vyberte Index Šablona
5.) Vyberte požadovanou index šablonu, např. lmio-
6.) Klikněte na Upravit
7.) Na obrazovce Nastavení přidejte:
{
"index": {
"lifecycle": {
"name": "lmio-",
"rollover_alias": "lmio-"
}
}
}
8.) Klikněte na Uložit
Vytvořte nový index, který bude využívat nejnovější index šablonu
Pomocí PostMan nebo Kibana vytvořte následující HTTP požadavek na instanci ElasticSearch, kterou používáte:
PUT lmio-tenant-events-000001
{
"aliases": {
"lmio-tenant-events": {
"is_write_index": true
}
}
}
Alias pak bude použit ILM politikou k distribuci dat do příslušného ElasticSearch indexu, takže pumpy se nebudou muset starat o číslo indexu.
//Poznámka: Prefix a číslo indexu pro ILM rollover musí být odděleno -
000001, ne _
000001!//
Konfigurujte ostatní LogMan.io komponenty
Pumpy nyní mohou používat ILM politiku prostřednictvím vytvořeného aliasu, který je v příkladu výše lm_tenant
. Konfigurační soubor by tedy měl vypadat takto:
[pipeline:<PIPELINE>:ElasticSearchSink]
index_prefix=lm_tenant
doctype=_doc
Pumpa vždy vloží data do aliasu lm_tenant
, kde se ILM postará o správné přiřazení k indexu, např. lm_-000001
.
//Poznámka: Ujistěte se, že v konfiguraci není žádný index prefix v source, jako v ElasticSearchSink v pipeline. Konfigurace kódu by nahradila konfiguraci souboru.//
Hot-Warm-Cold architektura (HWC)
HWC je rozšířením standardní rotace indexů poskytované ELASTICSEARCH ILM a je to dobrý nástroj pro správu datových časových řad. HWC architektura nám umožňuje přiřadit specifické uzly k jedné z fází. Při správném použití, spolu s architekturou clusteru, to umožní maximální výkon, využívající dostupný hardware na plný potenciál.
Hot
Obvykle je nějaké období (týden, měsíc, atd.), kdy chceme dotazovat indexy intenzivně, zaměřujíc se na rychlost, spíše než na paměť (a další zdroje) šetření. Právě tehdy přijde vhod fáze „Hot“, která nám umožní mít index s více replikami, rozmístěnými a přístupnými na více uzlech pro optimální uživatelskou zkušenost.
Hot uzly
Hot uzly by měly používat rychlé části dostupného hardwaru, využívající většinu CPU a rychlejší IO.
Warm
Jakmile toto období skončí a indexy nejsou již tak často dotazovány, budeme mít prospěch z přesunu do fáze „Warm“, která nám umožní snížit počet uzlů (nebo přesunout na uzly s méně dostupnými zdroji) a repliky indexů, čímž se sníží zatížení hardwaru, zatímco stále zůstává možnost rozumně rychle vyhledávat data.
Warm uzly
Warm uzly, jak již název napovídá, stojí na křižovatce mezi použitím pouze pro účely úložiště, zatímco stále zachovávají nějakou CPU sílu pro zvládnutí občasného dotazu.
Cold
Někdy existují důvody pro ukládání dat na delší období (diktováno zákonem nebo nějakým interním pravidlem). Data nejsou očekávána, že budou dotazována, ale zároveň nemohou být dosud smazána.
Cold uzly
To je místo, kde přichází Cold uzly, může jich být málo, s malými CPU zdroji, nemají potřebu používat SSD disky, být naprosto v pořádku s pomalejším (a případně větším) úložištěm.
Závěr
Použití HWC ILM funkce na plný efekt vyžaduje určitou přípravu, mělo by být zváženo při stavbě produkčního ElasticSearch clusteru. Přidaná hodnota však může být velmi vysoká, v závislosti na konkrétních případech použití.