Elasticsearch vo výrobe - osvedčené postupy zavádzania

Elasticsearch je vysoko optimalizovaný vyhľadávací nástroj pre modernú analýzu dát.

Elasticsearch je úžasný vyhľadávací a analytický nástroj v reálnom čase. Je postavený na Apache Lucene. Je distribuovaný, RESTful, ľahko sa používa a je vysoko dostupný. Medzi prípady použitia Elasticsearch patrí napájanie vyhľadávania, sledovanie transakcií a detekcia chýb, zisťovanie obsahu, analýza protokolov, fuzzy vyhľadávanie, agregácia údajov o udalostiach, vizualizácia údajov. Elasticsearch a zvyšok pružného zväzku sa ukázali byť mimoriadne všestrannými, a ako vidíte vyššie uvedené prípady použitia, existuje niekoľko spôsobov, ako integrovať Elasticsearch do toho, čo váš produkt dodáva dnes, a pridať k nemu ďalšie informácie.

Využívame ho vo veľkej miere na vyhľadávanie a analytiku v spoločnosti Botmetric, indexujeme približne miliardu dokumentov denne a na vizualizáciu údajov v reálnom čase používame veľmi zložité agregácie.

To znamená, že bootstrapping aplikácie oproti spusteniu vo výrobe a údržbe je úplne odlišný. Tento článok pokrýva mnoho z týchto faktorov zo skutočných životných skúseností a predstavuje základné bežné položky, ktoré by ste mali zvážiť pri spustení Elasticsearch vo výrobe.

Pamäť:

Elasticsearch a Lucene sú napísané v jazyku Java, čo znamená, že musíte dávať pozor na štatistiku heapspace a JVM. Čím viac haldy je k dispozícii pre Elasticsearch, tým viac pamäte môže použiť na filtrovanie a ďalšie ukladanie do pamäte cache na zvýšenie výkonu dotazov. Pamätajte však, že príliš veľa haldy vás môže vystaviť dlhým prestávkam na odvoz odpadu. Nenastavujte Xmx nad medznú hodnotu, ktorú JVM používa pre ukazovatele komprimovaných objektov (komprimované oops); presný limit sa líši, ale je blízko 32 GB.

Bežným problémom je konfigurácia haldy, ktorá je príliš veľká. Máte stroj s kapacitou 64 GB - a hlavne, chcete dať spoločnosti Elasticsearch všetkých 64 GB pamäte. Viac je lepšie! Halda je pre Elasticsearch určite dôležitá. Používa sa veľa dátových štruktúr v pamäti na zabezpečenie rýchlej prevádzky. Ale s tým povedal, tam je ďalší hlavný užívateľ pamäte, ktorá je mimo haldy: OS súbor cache.

Zariadenie Lucene je navrhnuté tak, aby využívalo základný operačný systém na ukladanie štruktúr údajov do pamäte cache. Segmenty Lucene sa ukladajú do jednotlivých súborov. Pretože segmenty sú nemenné, tieto súbory sa nikdy nezmenia. Vďaka tomu sú veľmi priateľské na ukladanie do vyrovnávacej pamäte a operačný systém, na ktorom sa nachádza operačný systém, šťastne udržiava horúce segmenty v pamäti pre rýchlejší prístup. Tieto segmenty zahŕňajú obrátený index (pre fulltextové vyhľadávanie) a hodnoty doc (pre agregácie). Výkon spoločnosti Lucene sa spolieha na túto interakciu s operačným systémom. Ale ak dáte všetku dostupnú pamäť do haldy Elasticsearch, nezostane tu žiadna medzipamäť súborov OS. Môže to vážne ovplyvniť výkon. Štandardným odporúčaním je poskytnúť 50% dostupnej pamäte haldy Elasticsearch, zatiaľ čo zvyšných 50% zostáva voľných. Nevyužije sa to; Lucene šťastne skonzumuje všetko, čo zostane pre vyrovnávaciu pamäť súborov. Hromadu Elasticsearch možno nakonfigurovať nasledujúcimi spôsobmi,

export ES_HEAP_SIZE = 10 g

alebo

ES_JAVA_OPTS = "- Xms10g -Xmx10g" ./bin/elasticsearch

CPU:

Elasticsearch podporuje agregácie a filtrované dotazy. Spúšťanie zložitých filtrovaných dopytov, intenzívne indexovanie, perkolácia a dotazy proti indexom si vyžadujú ťažké CPU, takže výber správneho je kritický. Jeden musí pochopiť špecifikácie CPU a ako sa správajú s Java, keď dotazy bežia na JVM.

Každý fond prevádzkuje niekoľko vlákien, ktoré je možné nakonfigurovať a má front. Zmena sa neodporúča, pokiaľ nemáte veľmi špecifickú požiadavku, pretože Elasticsearch dynamicky prideľuje jadrá.

Typy vlákien v závite:

Elasticsearch má 3 typy vláknových fondov.

  1. Archív vyrovnávacej pamäte: Oblasť vláknovej vyrovnávacej pamäte je vyrovnávacia oblasť vláknovej vyrovnávacej pamäte, ktorá v prípade nevybavených požiadaviek vytvorí vlákno. Táto oblasť vlákien sa používa na zabránenie blokovaniu alebo zamietnutiu žiadostí predložených do tejto oblasti. Nepoužité vlákna v tejto oblasti vlákien sa ukončia po vypršaní platnosti udržania (predvolené hodnoty sú päť minút). Spoločná oblasť vlákien v pamäti cache je vyhradená pre všeobecnú oblasť vlákien.
  2. Opravené: Oblasť pevných vlákien má pevnú veľkosť vlákien, aby spracovávala požiadavky s frontom (voliteľne ohraničeným) pre čakajúce žiadosti, ktoré nemajú vlákna, ktoré ich obsluhujú. Parameter size riadi počet vlákien a predvolene počet krát 5 jadier.
  3. Škálovanie: Oblasť škálovania podprocesov obsahuje dynamický počet vlákien. Toto číslo je úmerné pracovnému zaťaženiu a pohybuje sa medzi 1 a hodnotou parametra size.

Elasticsearch rozdeľuje využitie procesora do skupín podprocesov rôznych typov:

  • generické: pre štandardné operácie, ako je zisťovanie a typ fondu vlákien, sa ukladá do vyrovnávacej pamäte.
  • index: pre operácie indexovania / mazania. Typ oblasti vlákien je pevný.
  • vyhľadávanie: pre počet / operácie vyhľadávania. Typ oblasti vlákien je pevný.
  • get: na získanie operácií. Typ oblasti vlákien je pevný.
  • hromadne: pre hromadné operácie, ako je hromadné indexovanie. Typ oblasti vlákien je pevný. Najlepšia konfigurácia hromadných dokumentov závisí od konfigurácie klastra, ktorú možno identifikovať vyskúšaním viacerých hodnôt.
  • perkolát: na presakovanie. Typ oblasti vlákien je pevný.
  • Obnoviť: Na obnovovacie operácie. Typ oblasti vlákien je škálovateľný.

Zmena špecifickej oblasti vlákien sa dá vykonať nastavením jej špecifických parametrov.

Prečítajte si viac https://www.elastic.co/guide/en/elasticsearch/reference/2.2/modules-threadpool.html#types

Veľkosť črepu:

Črep je jednotka, v ktorej Elasticsearch distribuuje údaje v klastri. Rýchlosť, s ktorou môže Elasticsearch pohybovať úlomky pri opätovnom vyvážení údajov, napr. po zlyhaní bude závisieť od veľkosti a počtu úlomkov, ako aj od výkonu siete a disku.

V Elasticsearch sa každý dotaz vykonáva v jednom vlákne na jeden zlomok. Viaceré úlomky sa však môžu spracovávať paralelne, ako aj viacero otázok a agregácií proti rovnakému úlomku.

To znamená, že minimálna latencia dotazu, ak nie je použitá vyrovnávacia pamäť, bude závisieť od údajov, typu dotazu, ako aj od veľkosti črepu. Dotaz na veľa malých črepov urýchli spracovanie na jeden črep, ale keďže sa musí radiť do radu a spracovávať oveľa viac úloh postupne, nemusí to byť rýchlejšie ako zisťovanie menšieho počtu väčších črepov. Ak existuje viac súbežných dopytov, môže mať veľa malých úlomkov tiež zníženú priepustnosť dotazu.

Každý črep obsahuje údaje, ktoré je potrebné uchovávať v pamäti a využíva haldy. To zahŕňa dátové štruktúry, ktoré uchovávajú informácie na úrovni strihu a tiež na úrovni segmentov, aby sa určilo, kde sa dáta nachádzajú na disku. Veľkosť týchto dátových štruktúr nie je pevná a bude sa líšiť v závislosti od prípadu použitia. Jednou z dôležitých charakteristík režijných nákladov súvisiacich so segmentom je však to, že nie je presne úmerné veľkosti segmentu. To znamená, že väčšie segmenty majú menšie režijné náklady na objem údajov v porovnaní s menšími segmentmi. Rozdiel môže byť značný. Výber správneho počtu úlomkov je komplikovaný, pretože nikdy neviete, koľko dokumentov dostanete skôr, ako začnete. Mať veľa črepov môže byť pre zhluk dobrý aj strašný. Správa indexov a úlomkov môže preťažiť hlavný uzol, ktorý by mohol prestať reagovať, čo môže viesť k nejakému zvláštnemu a škaredému správaniu. Priraďte svojim hlavným uzlom dostatok zdrojov na zvládnutie veľkosti klastra.

Zlá vec je, že počet úlomkov je nemenný a je definovaný pri vytváraní indexu. Po vytvorení indexu je jediným spôsobom, ako zmeniť počet úlomkov, vymazanie indexov, ich opätovné vytvorenie a opätovné indexovanie.

replikácie

Elasticsearch podporuje replikáciu, údaje sa replikujú medzi dátovými uzlami, takže strata uzlov by neviedla k strate údajov. V predvolenom nastavení je replikačný faktor 1, ale v závislosti od vašich požiadaviek na produkt sa môže zvýšiť. Čím viac replík bude, vaše dáta budú odolnejšie voči katastrofám. Ďalšou výhodou väčšieho počtu replík je to, že každý uzol má zlomok repliky, ktorý zvyšuje výkonnosť dotazu, pretože na dotazovanie sa používajú aj repliky.

Replikačný vzorec používaný konzistenciou spoločnosti Elasticsearch je,

(primárne + číslo_zobrazení) / 2 + 1

Optimalizácia alokácie

Na základe požiadaviek na údaje o produktoch môžeme údaje klasifikovať na horúce a studené. Indexom, ku ktorým sa pristupuje častejšie ako iným, je možné prideliť viac dátových uzlov, zatiaľ čo indexy, ktoré majú menej často prístupné indexy, môžu mať pridelené menej zdrojov. Táto stratégia je užitočná najmä na ukladanie údajov časových radov, ako sú denníky aplikácií (napr. ELK).

To možno dosiahnuť spustením príkazu cronjob, ktorý v pravidelných intervaloch posúva indexy do rôznych uzlov.

Horúci uzol je typ dátového uzla, ktorý vykonáva všetky indexácie v klastri. Držia tiež najaktuálnejšie indexy, pretože tieto tendencie sa zvyčajne zisťujú najčastejšie. Pretože indexovanie je operácia náročná na CPU a IO, tieto servery musia byť výkonné a podporované pripojeným úložiskom SSD. Pre vysokú dostupnosť odporúčame spustiť minimálne 3 horúce uzly. V závislosti od množstva nedávnych údajov, ktoré chcete zhromažďovať a dotazovať sa, možno budete musieť zvýšiť tento počet, aby ste dosiahli svoje výkonnostné ciele.

Teplý uzol je typ dátového uzla navrhnutého na spracovanie veľkého množstva indexov určených len na čítanie, ktoré nie sú také často vyhľadávané. Pretože tieto indexy sú určené iba na čítanie, teplý uzol má tendenciu využívať namiesto pripojených diskov SSD veľké pripojené disky (zvyčajne sa točiace disky). Rovnako ako v prípade horúcich uzlov, aj v prípade vysokej dostupnosti odporúčame minimálne 3 teplé uzly. A ako predtým, s výhradou, že väčšie množstvo údajov môže vyžadovať ďalšie uzly, aby splnili požiadavky na výkon. Všimnite si tiež, že konfigurácie CPU a pamäte budú často musieť odrážať konfigurácie vašich horúcich uzlov. Dá sa to zistiť iba testovaním s otázkami podobnými tým, ktoré by sa vyskytli vo výrobnej situácii.

Viac podrobností o horúcom a teplom uzle nájdete tu.

Ďalšou stratégiou, ktorú môžete prispôsobiť, je archivácia indexov na s3 a obnovenie, keď potrebujete údaje z týchto indexov. Viac sa o tom dočítate tu.

Topológia uzla:

Uzly Elasticsearch sa dajú rozdeliť do troch kategórií: hlavný uzol, dátový uzol, uzol klienta.

  1. Hlavný uzol: Hlavný uzol môže byť malý, ak nie je údajovým uzlom, pretože neukladá žiadne indexy / úlomky. Jeho zodpovednosťou je ukladať podrobné informácie o stave klastra a pomáhať údajom a iným uzlom v vyhľadávaní metaúdajov indexov / útržkov. Elasticsearch by mal mať viac hlavných uzlov, aby sa predišlo problému s rozdeleným mozgom.
  2. Dátový uzol: Dátový uzol je zodpovedný za ukladanie / dopytovanie skutočných indexových údajov.
  3. Klientsky uzol: Klientsky uzol sa používa ako proxy na indexovanie a vyhľadávanie. Toto sa dôrazne odporúča, ak sa agregácie intenzívne používajú. Toto sú špeciálne uzly ElasticSearch, ktoré nie sú vhodné pre dáta ani pre master. Klientske uzly si uvedomujú klastre, a preto môžu pôsobiť ako inteligentné vyvažovače záťaže. Svoje dotazy môžete poslať do klientskych uzlov, ktoré potom môžu prevziať nákladnú úlohu získavania odpovedí na výsledky dotazov z každého dátového uzla.

pridajte tieto nastavenia do súboru elasticsearch.yml pre príslušné uzly.

Hlavný uzol: node.master: true node.data:false
Dátový uzol: node.master: false node.data:true
Uzol klienta: node.master: false node.data:false

Tipy na riešenie problémov:

Výkon systému Elasticsearch silne závisí od stroja, na ktorom je nainštalovaný. CPU, využitie pamäte a disk I / O sú základné metriky operačného systému pre každý uzol Elasticsearch. Odporúča sa pozrieť sa na metriky Java Virtual Machine (JVM), keď sa zvýši využitie CPU. V nasledujúcom príklade bola príčinou špice vyššia aktivita pri zbere odpadu.

  1. Hromadný tlak: Vysoký tlak v pamäti pôsobí proti výkonu klastra dvoma spôsobmi: Keď sa tlak v pamäti zvyšuje na 75% a viac, zostáva k dispozícii menej pamäte a váš klaster teraz musí tiež minúť nejaké prostriedky CPU, aby získal späť pamäť prostredníctvom zbierania odpadu. Tieto cykly CPU nie sú k dispozícii na vybavovanie užívateľských požiadaviek, keď je zapnutý zber odpadu. Výsledkom je, že čas odozvy na požiadavky používateľov sa zvyšuje so zvyšujúcim sa obmedzením systému. Ak tlak v pamäti neustále stúpa a dosahuje takmer 100%, používa sa oveľa agresívnejšia forma zberu odpadu, čo zasa dramaticky ovplyvní čas odozvy klastra. Metrika Index Response Times ukazuje, že vysoký tlak v pamäti má významný vplyv na výkon.
  2. Rast v pamäti haldy spoločnosti JVM, konzumácia pamäte určenej na vyrovnávaciu pamäť stránky a pravdepodobne spôsobujúca skombinovanie OOM na úrovni jadra.
  3. Vyhnite sa rozdelenému mozgovému problému. Rozdelený mozog je scenár, v ktorom sa zhluk rozdeľuje. Napríklad máte klaster s 6 uzlami. Dva uzly sa odpojia od klastra, stále sa však môžu navzájom vidieť. Tieto 2 uzly potom vytvoria ďalší klaster. Medzi sebou si dokonca zvolia nového pána. Teraz máme dva klastre s rovnakým názvom, jeden so 4 uzlami a druhý s 2 uzlami. Každý má tiež hlavný uzol. Toto sa nazýva problém rozdeleného mozgu s klastrami ES. Aby ste tomu zabránili, nastavte parameter ES discovery.zen.minimum_master_nodes na polovicu počtu uzlov + 1.
  4. Pretože Elasticsearch používa úložné zariadenia vo veľkom rozsahu, monitorovanie vstupno-výstupných operácií na disku zaisťuje, že táto základná potreba bude splnená. Existuje veľa dôvodov pre znížené vstupno-výstupné disky, považuje sa to za kľúčovú metriku na predpovedanie mnohých druhov problémov. Je dobré kontrolovať efektívnosť indexovania a výkonnosti dotazov. Priama analýza operácií čítania a zápisu naznačuje, čo systém v konkrétnom prípade použitia najviac potrebuje. Nastavenia operačného systému pre diskové vstupy / výstupy sú základom všetkých ostatných optimalizácií, vyladením vstupno-výstupných diskov sa môžu vyhnúť potenciálnym problémom. Ak disk I / O stále nie je dostatočný, mali by sa vyhodnotiť protiopatrenia, ako je optimalizácia počtu úlomkov a ich veľkosti, škrtenie zlúčení, výmena pomalých diskov, prechod na SSD alebo pridanie ďalších uzlov podľa okolností spôsobujúcich I / O úzke miesta.
  5. V prípade aplikácií, ktoré sa spoliehajú na vyhľadávanie, je používateľská skúsenosť vysoko korelovaná s latenciou požiadaviek na vyhľadávanie. Existuje veľa vecí, ktoré môžu ovplyvniť výkon dotazu, ako sú vytvorené dotazy, nesprávne nakonfigurovaný klaster Elasticsearch, problémy s pamäťou JVM a zberom odpadkov, disk IO atď. Latencia dopytov je metrika, ktorá má priamy vplyv na používateľov, preto nezabudnite na to upozorniť.
  6. Väčšina filtrov v Elasticsearch je v predvolenom nastavení uložená do vyrovnávacej pamäte. To znamená, že počas prvého vykonávania filtrovaného dotazu Elasticsearch nájde dokumenty zodpovedajúce filtru a pomocou týchto informácií vytvorí štruktúru nazvanú „bitset“. Dáta uložené v množine bitov obsahujú identifikátor dokumentu a to, či sa daný dokument zhoduje s filtrom. Následné vykonanie dotazov, ktoré majú rovnaký filter, znova využije informácie uložené v bitovej sade, čím sa urýchli vykonávanie dotazov uložením I / O operácií a CPU cyklov. Odporúča sa použiť filter v dopyte. Viac informácií nájdete tu.
  7. Čas obnovenia a čas zlúčenia úzko súvisia s výkonom indexovania a navyše ovplyvňujú celkový výkon klastra. Čas obnovenia sa zvyšuje s počtom operácií so súbormi pre index Lucene (shard).
  8. Povolenie pomalého protokolovania dopytov pomôže pri zisťovaní, ktoré dopyty sú pomalé a čo je možné urobiť, aby sa zlepšili, zvlášť užitočné pri dopytoch so zástupnými znakmi.
  9. Zväčšite ulimitnú veľkosť, aby ste umožnili maximálny počet súborov.
  10. Výkon systému ElasticSearch môže utrpieť, keď sa operačný systém rozhodne vymeniť nevyužitú pamäť aplikácií. Zamedziť odkladanie nastavením nastavení na úrovni OS alebo nastaviť v ElasticSearch config bootstrap.mlockall: true
  11. Zakázať odstraňovanie všetkých indexov pomocou zástupných znakov. Ak chcete zaistiť, aby niekto nevydal operáciu DELETE vo všetkých indexoch (* alebo _all), nastavte action.destructive_requires_name na true.

Pred dokončením je uvedený zoznam webových adries, ktoré sú užitočné na sledovanie metrík.

  • / _cluster / health? pretty: Pre indikátor zdravia klastra.
  • / _status? pretty: Pre všetky informácie o všetkých indexoch.
  • / _nodes? pretty: Pre všetky informácie o uzloch.
  • / _cat / master? pretty: Pre hlavný uzol.
  • / _stats? pretty: Na rozdelenie črepov, štatistiky indexov.
  • / _nodes / statistics? pretty: Pre štatistiku jednotlivých uzlov to zahŕňa štatistiku jvm, http, io pre uzol.

Agregácia metrík Elasticsearch je podporovaná väčšinou nástrojov na monitorovanie systému, ako sú Datadog, TICK. Odporúča sa použitie takýchto nástrojov a dôrazne sa odporúča vytvorenie lievika na nepretržité monitorovanie Elasticsearch.

záver:

Elasticsearch je distribuovaný fulltextový vyhľadávací a analytický nástroj, ktorý umožňuje viacerým nájomcom prehľadávať ich celé súbory údajov bez ohľadu na veľkosť bezprecedentnou rýchlosťou. Okrem možností fulltextového vyhľadávania sa ElasticSearch používa ako analytický systém a distribuovaná databáza. Služba ElasticSearch má na začiatku veľké predvolené hodnoty. Len čo ste však prekonali počiatočnú experimentálnu fázu, musíte stráviť nejaký čas vylepšením nastavení pre svoje potreby. Odporúča sa, aby ste svoju konfiguráciu vykonali neskôr spolu s oficiálnou dokumentáciou, aby ste sa uistili, že váš klaster je nakonfigurovaný tak, aby vyhovoval vašim potrebám.