Mnoho ľudí bojuje s Elasticsearch. Čo sa však stane, keď ho chcete použiť na ukladanie protokolov „v obzvlášť veľkom objeme“? A je tiež bezbolestné zažiť zlyhanie niektorého z viacerých dátových centier? Akú architektúru by ste mali robiť a na aké úskalia narazíte?
My v Odnoklassniki sme sa rozhodli použiť elasticsearch na vyriešenie problému správy protokolov a teraz zdieľame naše skúsenosti s Habrom: o architektúre aj o úskaliach.
Som Pyotr Zaitsev, pracujem ako správca systému v Odnoklassniki. Predtým som bol aj admin, pracoval som s Manticore Search, Sphinx search, Elasticsearch. Možno, ak sa objaví ďalšie hľadanie, pravdepodobne s ním budem tiež pracovať. Dobrovoľne sa podieľam aj na množstve open source projektov.
Keď som prišiel do Odnoklassniki, na pohovore som neuvážene povedal, že môžem pracovať s Elasticsearch. Keď som to pochopil a dokončil niekoľko jednoduchých úloh, dostal som veľkú úlohu reformovať systém správy protokolov, ktorý v tom čase existoval.
Požiadavky
Systémové požiadavky boli formulované nasledovne:
- Graylog mal byť použitý ako frontend. Keďže spoločnosť už mala skúsenosti s používaním tohto produktu, programátori a testeri ho poznali, bol im známy a pohodlný.
- Objem dát: v priemere 50-80 tisíc správ za sekundu, ale ak sa niečo pokazí, potom nie je prevádzka ničím obmedzená, môže to byť 2-3 milióny riadkov za sekundu
- Po diskusii so zákazníkmi o požiadavkách na rýchlosť spracovania vyhľadávacích dopytov sme si uvedomili, že typický vzorec používania takéhoto systému je takýto: ľudia hľadajú denníky svojej aplikácie za posledné dva dni a nechcú čakať dlhšie ako druhý výsledok formulovaného dotazu.
- Administrátori trvali na tom, aby bol systém v prípade potreby ľahko škálovateľný bez toho, aby sa museli hlboko ponoriť do toho, ako funguje.
- Jedinou úlohou údržby, ktorú tieto systémy pravidelne vyžadujú, je výmena hardvéru.
- Okrem toho má Odnoklassniki vynikajúcu technickú tradíciu: každá služba, ktorú spustíme, musí prežiť zlyhanie dátového centra (náhle, neplánované a absolútne kedykoľvek).
Najviac nás stála posledná požiadavka pri realizácii tohto projektu, o ktorej poviem podrobnejšie.
streda
Pracujeme v štyroch dátových centrách, pričom dátové uzly Elasticsearch je možné umiestniť len v troch (z viacerých netechnických dôvodov).
Tieto štyri dátové centrá obsahujú približne 18 tisíc rôznych zdrojov protokolov – hardvér, kontajnery, virtuálne stroje.
Dôležitá vlastnosť: klaster začína v kontajneroch nie na fyzických strojoch, ale na . Kontajnery majú garantované 2 jadrá, podobne ako 2.0Ghz v4, s možnosťou recyklácie zvyšných jadier, ak sú nečinné.
Inými slovami:
Topológia
Na začiatku som videl všeobecnú formu riešenia takto:
- 3-4 VIP sú za A-rekordom domény Graylog, to je adresa, na ktorú sa posielajú logy.
- každý VIP je vyrovnávačom LVS.
- Potom protokoly idú do batérie Graylog, niektoré údaje sú vo formáte GELF, niektoré vo formáte syslog.
- Potom sa toto všetko vo veľkých dávkach zapíše do batérie koordinátorov Elasticsearch.
- A tie zase posielajú požiadavky na zápis a čítanie do príslušných dátových uzlov.
terminológie
Možno nie každý rozumie do detailov terminológii, preto by som sa pri nej rád trochu pozastavil.
Elasticsearch má niekoľko typov uzlov – hlavný, koordinátor, dátový uzol. Existujú dva ďalšie typy pre rôzne transformácie protokolov a komunikáciu medzi rôznymi klastrami, ale použili sme len tie, ktoré sú uvedené.
majster
Pinguje všetky uzly prítomné v klastri, udržiava aktuálnu mapu klastrov a distribuuje ju medzi uzly, spracováva logiku udalostí a vykonáva rôzne druhy správy celého klastra.
koordinátor
Vykonáva jednu jedinú úlohu: prijíma požiadavky na čítanie alebo zápis od klientov a nasmeruje túto prevádzku. V prípade, že existuje požiadavka na zápis, s najväčšou pravdepodobnosťou sa opýta majstra, do ktorého fragmentu príslušného indexu ho má vložiť a presmeruje požiadavku ďalej.
Dátový uzol
Ukladá dáta, vykonáva vyhľadávacie dopyty prichádzajúce zvonku a vykonáva operácie s úlomkami, ktoré sa na nich nachádzajú.
graylog
Toto je niečo ako fúzia Kibana s Logstash v ELK stacku. Graylog kombinuje používateľské rozhranie a potrubie na spracovanie protokolov. Pod kapotou Graylog prevádzkuje Kafka a Zookeeper, ktoré poskytujú pripojenie k Graylogu ako klastra. Graylog môže uchovávať protokoly (Kafka) v prípade, že Elasticsearch nie je k dispozícii a opakovať neúspešné požiadavky na čítanie a zápis, zoskupovať a označovať protokoly podľa špecifikovaných pravidiel. Rovnako ako Logstash, aj Graylog má funkciu na úpravu riadkov pred ich zapísaním do Elasticsearch.
Okrem toho má Graylog zabudované vyhľadávanie služieb, ktoré umožňuje na základe jedného dostupného uzla Elasticsearch získať celú mapu klastra a filtrovať ju podľa špecifického tagu, čo umožňuje nasmerovať požiadavky na konkrétne kontajnery.
Vizuálne to vyzerá asi takto:
Toto je snímka obrazovky z konkrétneho prípadu. Tu vytvoríme histogram založený na vyhľadávacom dopyte a zobrazíme relevantné riadky.
Indexy
Keď sa vrátim k architektúre systému, rád by som sa podrobnejšie venoval tomu, ako sme zostavili indexový model, aby všetko fungovalo správne.
Vo vyššie uvedenom diagrame je to najnižšia úroveň: dátové uzly Elasticsearch.
Index je veľká virtuálna entita tvorená úlomkami Elasticsearch. Každý z úlomkov sám o sebe nie je ničím iným ako lucenským indexom. A každý index Lucene zase pozostáva z jedného alebo viacerých segmentov.
Pri návrhu sme vychádzali z toho, že aby sme splnili požiadavku na rýchlosť čítania veľkého množstva dát, potrebovali sme tieto dáta „rozložiť“ rovnomerne medzi dátové uzly.
To viedlo k tomu, že počet zlomkov na index (s replikami) by sa mal presne rovnať počtu dátových uzlov. Po prvé, aby sme zabezpečili replikačný faktor rovný dvom (to znamená, že môžeme stratiť polovicu klastra). A po druhé, aby sa spracovali požiadavky na čítanie a zápis aspoň na polovici klastra.
Ako prvé sme určili dobu skladovania na 30 dní.
Rozloženie črepov možno graficky znázorniť takto:
Celý tmavosivý obdĺžnik je index. Ľavý červený štvorec v ňom je primárny črep, prvý v indexe. A modrý štvorec je replika črepu. Sú umiestnené v rôznych dátových centrách.
Keď pridáme ďalší úlomok, ide do tretieho dátového centra. A nakoniec získame túto štruktúru, ktorá umožňuje stratiť DC bez straty konzistencie údajov:
Rotácia indexov, t.j. vytvorením nového indexu a odstránením najstaršieho sme ho zrovnali na 48 hodín (podľa vzoru používania indexu: najčastejšie sa vyhľadáva posledných 48 hodín).
Tento interval rotácie indexu je spôsobený nasledujúcimi dôvodmi:
Keď požiadavka na vyhľadávanie dorazí do konkrétneho dátového uzla, potom je z hľadiska výkonu výhodnejšie, keď sa dopytuje jeden zlomok, ak je jeho veľkosť porovnateľná s veľkosťou bokov uzla. To vám umožňuje udržiavať „horúcu“ časť indexu na hromade a rýchlo k nej pristupovať. Keď existuje veľa „horúcich častí“, rýchlosť indexového vyhľadávania sa znižuje.
Keď uzol začne vykonávať vyhľadávací dotaz na jednom zlomku, pridelí počet vlákien rovný počtu hyperthreadingových jadier fyzického počítača. Ak vyhľadávací dopyt ovplyvňuje veľký počet zlomkov, počet vlákien úmerne rastie. To má negatívny vplyv na rýchlosť vyhľadávania a negatívne ovplyvňuje indexovanie nových údajov.
Aby sme zabezpečili potrebnú latenciu vyhľadávania, rozhodli sme sa použiť SSD. Na rýchle spracovanie požiadaviek museli mať počítače, ktoré hostili tieto kontajnery, aspoň 56 jadier. Číslo 56 bolo zvolené ako podmienečne postačujúca hodnota, ktorá určuje počet vlákien, ktoré Elasticsearch vygeneruje počas prevádzky. V Elasitcsearch veľa parametrov oblasti vlákien priamo závisí od počtu dostupných jadier, čo zase priamo ovplyvňuje požadovaný počet uzlov v klastri podľa princípu „menej jadier - viac uzlov“.
V dôsledku toho sme zistili, že v priemere jeden úlomok váži asi 20 gigabajtov a na jeden index pripadá 1 úlomkov. Ak ich teda otočíme raz za 360 hodín, tak ich máme 48. Každý index obsahuje údaje za 15 dni.
Obvody na zápis a čítanie údajov
Poďme zistiť, ako sa údaje zaznamenávajú v tomto systéme.
Povedzme, že príde nejaká požiadavka od Grayloga ku koordinátorovi. Napríklad chceme indexovať 2-3 tisíc riadkov.
Koordinátor, ktorý dostal žiadosť od Grayloga, sa pýta majstra: „V žiadosti o indexovanie sme špecificky špecifikovali index, ale nebolo špecifikované, do ktorého zlomku sa má zapísať.
Master odpovie: „Napíšte túto informáciu na črep číslo 71“, potom sa odošle priamo do príslušného dátového uzla, kde sa nachádza primárny črep číslo 71.
Potom sa protokol transakcií replikuje do repliky, ktorá sa nachádza v inom dátovom centre.
Od Grayloga príde koordinátorovi žiadosť o vyhľadávanie. Koordinátor ho presmeruje podľa indexu, zatiaľ čo Elasticsearch rozdelí požiadavky medzi primárny-shard a replika-shard pomocou princípu round-robin.
180 uzlov reaguje nerovnomerne a kým reagujú, koordinátor hromadí informácie, ktoré už „vypľuli“ rýchlejšie dátové uzly. Potom, keď buď prídu všetky informácie, alebo požiadavka dosiahne časový limit, odovzdá všetko priamo klientovi.
Celý tento systém v priemere spracováva vyhľadávacie dopyty za posledných 48 hodín za 300 – 400 ms, s výnimkou dopytov s hlavným zástupným znakom.
Kvety s Elasticsearch: nastavenie Java
Aby to všetko fungovalo tak, ako sme pôvodne chceli, strávili sme veľmi dlhý čas ladením širokej škály vecí v klastri.
Prvá časť objavených problémov súvisela so spôsobom, akým je Java štandardne predkonfigurovaná v Elasticsearch.
Problém jedna
Videli sme veľmi veľké množstvo správ, že na úrovni Lucene, keď bežia úlohy na pozadí, zlúčenie segmentov Lucene zlyhá s chybou. Zároveň bolo v protokoloch jasné, že ide o chybu OutOfMemoryError. Z telemetrie sme videli, že bedro je voľné a nebolo jasné, prečo táto operácia zlyhala.
Ukázalo sa, že zlúčenie indexu Lucene sa vyskytujú mimo bedra. A kontajnery sú dosť prísne obmedzené, pokiaľ ide o spotrebované zdroje. Do týchto zdrojov sa zmestila iba halda (hodnota heap.size bola približne rovná RAM) a niektoré operácie mimo haldy zlyhali s chybou alokácie pamäte, ak sa z nejakého dôvodu nezmestili do ~500 MB, ktoré zostalo pred limitom.
Oprava bola celkom triviálna: množstvo pamäte RAM dostupnej pre kontajner sa zvýšilo, po čom sme zabudli, že sme mali takéto problémy.
Problém dva
4-5 dní po spustení klastra sme si všimli, že dátové uzly začali periodicky vypadávať z klastra a vstupovať doň po 10-20 sekundách.
Keď sme to začali zisťovať, ukázalo sa, že táto mimo-hromadná pamäť v Elasticsearch nie je žiadnym spôsobom kontrolovaná. Keď sme dali kontajneru viac pamäte, mohli sme naplniť priame oblasti vyrovnávacej pamäte rôznymi informáciami a tie sa vyčistili až po spustení explicitného GC z Elasticsearch.
V niektorých prípadoch táto operácia trvala pomerne dlho a počas tejto doby sa klastru podarilo označiť tento uzol ako už ukončený. Tento problém je dobre popísaný .
Riešenie bolo nasledovné: obmedzili sme schopnosť Javy používať na tieto operácie veľkú časť pamäte mimo haldy. Obmedzili sme ho na 16 gigabajtov (-XX:MaxDirectMemorySize=16g), čím sme zaistili, že explicitné GC bolo volané oveľa častejšie a spracovávané oveľa rýchlejšie, čím sa už nedestabilizuje klaster.
Problém tri
Ak si myslíte, že problémy s „uzlami opúšťajúcimi klaster v najneočakávanejšom momente“ sú zažehnané, ste na omyle.
Keď sme konfigurovali prácu s indexmi, zvolili sme mmapfs na čerstvých črepoch s veľkou členitosťou. Bola to dosť veľká chyba, pretože pri použití mmapfs sa súbor namapuje do RAM a potom pracujeme s namapovaným súborom. Z tohto dôvodu sa ukázalo, že keď sa GC pokúsi zastaviť vlákna v aplikácii, ideme do bodu obnovy na veľmi dlhú dobu a na ceste k nemu aplikácia prestane reagovať na požiadavky majstra o tom, či je nažive. . V súlade s tým master verí, že uzol už nie je prítomný v klastri. Potom, po 5-10 sekundách, zberač odpadu funguje, uzol ožije, znova vstúpi do klastra a začne inicializovať úlomky. Všetko to vyzeralo ako „výroba, ktorú sme si zaslúžili“ a nehodilo sa to na nič vážne.
Aby sme sa tohto správania zbavili, najprv sme prešli na štandardné niofs a potom, keď sme migrovali z piatej verzie Elastic na šiestu, vyskúšali sme hybridfs, kde sa tento problém nereprodukoval. Môžete si prečítať viac o typoch úložiska .
Problém štyri
Potom tu bol ďalší veľmi zaujímavý problém, ktorý sme riešili rekordne dlho. Chytali sme ho 2-3 mesiace, pretože jeho vzor bol absolútne nepochopiteľný.
Niekedy naši koordinátori išli na Full GC, zvyčajne niekedy po obede, a už sa odtiaľ nevrátili. Zároveň to pri logovaní oneskorenia GC vyzeralo takto: všetko ide dobre, dobre, dobre a potom raz - a všetko je zrazu zle.
Najprv sme si mysleli, že máme zlého používateľa, ktorý spúšťa nejakú požiadavku, ktorá vyradí koordinátora z pracovného režimu. Žiadosti sme zaznamenávali veľmi dlho a snažili sme sa zistiť, čo sa deje.
Vo výsledku sa ukázalo, že v momente, keď používateľ spustí obrovskú požiadavku a tá sa dostane ku konkrétnemu koordinátorovi Elasticsearch, niektoré uzly reagujú dlhšie ako iné.
A kým koordinátor čaká na odpoveď od všetkých uzlov, zhromažďuje výsledky odoslané z uzlov, ktoré už odpovedali. Pre GC to znamená, že naše vzorce využívania haldy sa menia veľmi rýchlo. A GC, ktoré sme použili, sa s touto úlohou nedokázalo vyrovnať.
Jedinou opravou, ktorú sme našli na zmenu správania klastra v tejto situácii, je migrácia na JDK13 a použitie zberača odpadu Shenandoah. Tým sa problém vyriešil, naši koordinátori prestali padať.
Tu sa problémy s Javou skončili a začali problémy so šírkou pásma.
"Bobule" s Elasticsearch: priepustnosť
Problémy s priepustnosťou znamenajú, že náš klaster funguje stabilne, ale pri špičkách v počte indexovaných dokumentov a pri manévroch je výkon nedostatočný.
Prvý príznak: počas niektorých „výbuchov“ vo výrobe, keď sa náhle vygeneruje veľmi veľké množstvo protokolov, v Graylogu začne často blikať chyba indexovania es_rejected_execution.
Bolo to spôsobené tým, že thread_pool.write.queue na jednom dátovom uzle, kým Elasticsearch dokáže spracovať požiadavku na indexovanie a nahrať informácie na shard na disk, dokáže štandardne uložiť do cache iba 200 požiadaviek. A v O tomto parametri sa hovorí veľmi málo. Je uvedený iba maximálny počet vlákien a predvolená veľkosť.
Samozrejme, išli sme túto hodnotu prekrútiť a zistili sme nasledovné: konkrétne v našom nastavení je až 300 požiadaviek uložených do vyrovnávacej pamäte celkom dobre a vyššia hodnota je spojená so skutočnosťou, že opäť vletíme do Full GC.
Navyše, keďže ide o dávky správ, ktoré prídu v rámci jednej požiadavky, bolo potrebné Graylog vyladiť tak, aby nepísal často a v malých dávkach, ale vo veľkých dávkach alebo raz za 3 sekundy, ak dávka stále nie je kompletná. V tomto prípade sa ukazuje, že informácie, ktoré napíšeme do Elasticsearch, sa sprístupnia nie za dve sekundy, ale za päť (čo nám celkom vyhovuje), ale počet opakovaní, ktoré je potrebné vykonať, aby sme pretlačili veľký zásobník informácií je znížený.
To je dôležité najmä v tých chvíľach, keď sa niekde niečo zrútilo a zúrivo o tom hlási, aby sa nedostal úplne spamovaný Elastic a po nejakom čase - Graylog uzly, ktoré sú nefunkčné z dôvodu upchatých vyrovnávacích pamätí.
Navyše, keď sme mali rovnaké explózie vo výrobe, dostali sme sťažnosti od programátorov a testerov: v momente, keď tieto protokoly skutočne potrebovali, dostali ich veľmi pomaly.
Začali to zisťovať. Na jednej strane bolo jasné, že vyhľadávacie aj indexové dotazy sa spracovávali v podstate na rovnakých fyzických strojoch a tak či onak by došlo k určitým výpadkom.
To sa však dalo čiastočne obísť, pretože v šiestych verziách Elasticsearch sa objavil algoritmus, ktorý vám umožňuje distribuovať dopyty medzi relevantnými dátovými uzlami nie podľa princípu náhodného cyklovania (kontajner, ktorý indexuje a drží primárny shard môže byť veľmi zaneprázdnený, nebude možné rýchlo reagovať), ale preposlať túto požiadavku menej zaťaženému kontajneru s replikou-shard, ktorý bude reagovať oveľa rýchlejšie. Inými slovami, dospeli sme k use_adaptive_replica_selection: true.
Obrázok čítania začína vyzerať takto:
Prechod na tento algoritmus umožnil výrazne skrátiť čas dopytu v tých momentoch, keď sme museli zapisovať veľké množstvo protokolov.
Nakoniec hlavným problémom bolo bezbolestné odstránenie dátového centra.
Čo sme chceli od klastra ihneď po strate spojenia s jedným DC:
- Ak máme aktuálneho hlavného servera v neúspešnom dátovom centre, potom sa znova vyberie a presunie sa ako rola do iného uzla v inom DC.
- Master rýchlo odstráni všetky neprístupné uzly z klastra.
- Na základe tých zvyšných pochopí: v stratenom dátovom centre sme mali také a také primárne črepy, rýchlo presadí doplnkové replikové črepy v zostávajúcich dátových centrách a budeme pokračovať v indexovaní údajov.
- V dôsledku toho sa priepustnosť zápisu a čítania klastra postupne zníži, ale vo všeobecnosti bude všetko fungovať, aj keď pomaly, ale stabilne.
Ako sa ukázalo, chceli sme niečo takéto:
A dostali sme nasledovné:
Ako sa to stalo?
Keď padlo dátové centrum, prekážkou sa stal náš pán.
Prečo?
Faktom je, že master má TaskBatcher, ktorý je zodpovedný za distribúciu určitých úloh a udalostí v klastri. Akýkoľvek výstup z uzla, akékoľvek povýšenie fragmentu z repliky na primárny, akákoľvek úloha na vytvorenie niekde fragmentu - to všetko ide najskôr do aplikácie TaskBatcher, kde sa to spracuje postupne a v jednom vlákne.
V čase stiahnutia jedného dátového centra sa ukázalo, že všetky dátové uzly v zachovaných dátových centrách považovali za svoju povinnosť informovať majstra „stratili sme také a také úlomky a také a také dátové uzly“.
Preživšie dátové uzly zároveň poslali všetky tieto informácie súčasnému masterovi a pokúsili sa počkať na potvrdenie, že ich prijal. Nečakali na to, pretože majster dostával úlohy rýchlejšie, ako mohol odpovedať. Uzly vypršal časový limit opakujúcich sa požiadaviek a majster sa v tom čase ani nepokúsil na ne odpovedať, ale bol úplne pohltený úlohou triediť požiadavky podľa priority.
V terminálovej forme sa ukázalo, že dátové uzly spamovali master do tej miery, že prešiel do plnej GC. Potom sa naša hlavná rola presunula do nejakého ďalšieho uzla, stalo sa jej úplne to isté a v dôsledku toho sa klaster úplne zrútil.
Uskutočnili sme merania a pred verziou 6.4.0, kde to bolo opravené, nám na úplné vypnutie klastra stačilo súčasne vydať iba 10 dátových uzlov z 360.
Vyzeralo to asi takto:
Po verzii 6.4.0, kde bola táto hrozná chyba opravená, dátové uzly prestali zabíjať master. To ho však nerobilo „múdrejším“. Konkrétne: keď vydáme 2, 3 alebo 10 (ľubovoľné číslo iné ako jeden) dátových uzlov, master dostane nejakú prvú správu, ktorá hovorí, že uzol A odišiel, a pokúsi sa o tom povedať uzlu B, uzlu C, uzlu D.
A momentálne sa to dá riešiť len nastavením časového limitu na pokusy niekomu o niečom povedať, približne 20-30 sekúnd, a tým kontrolovať rýchlosť pohybu dátového centra z klastra.
V zásade to zapadá do požiadaviek, ktoré boli pôvodne prezentované na finálny produkt v rámci projektu, ale z pohľadu „čistej vedy“ ide o chybu. Čo, mimochodom, vývojári úspešne opravili vo verzii 7.2.
Navyše, keď zhasol určitý dátový uzol, ukázalo sa, že šírenie informácií o jeho výstupe je dôležitejšie ako povedať celému klastru, že na ňom sú také a také primárne črepy (s cieľom propagovať repliku črepov v iných údajoch centrum v primárnom a v informáciách by sa na ne dalo napísať).
Preto, keď už všetko utíchlo, uvoľnené dátové uzly nie sú okamžite označené ako zastarané. V súlade s tým sme nútení čakať, kým uplynú všetky pingy na uvoľnené dátové uzly, a až potom nám náš klaster začne oznamovať, že niekde, tam a tam musíme pokračovať v zaznamenávaní informácií. Môžete si o tom prečítať viac .
Výsledkom je, že operácia stiahnutia dátového centra nám dnes počas dopravnej špičky trvá približne 5 minút. Na taký veľký a nemotorný kolos je to celkom dobrý výsledok.
V dôsledku toho sme dospeli k nasledujúcemu rozhodnutiu:
- Máme 360 dátových uzlov so 700 gigabajtovými diskami.
- 60 koordinátorov pre smerovanie prevádzky cez tie isté dátové uzly.
- 40 masterov, ktoré nám zostali ako akési dedičstvo od verzií pred 6.4.0 - aby sme prežili stiahnutie dátového centra, boli sme psychicky pripravení prísť o niekoľko strojov, aby sme mali zaručené kvórum masterov aj v r. najhorší možný scenár
- Akékoľvek pokusy o spojenie rolí na jednom kontajneri sa stretli s tým, že skôr či neskôr sa uzol pri zaťažení zlomí.
- Celý klaster používa heap.size 31 gigabajtov: všetky pokusy o zmenšenie viedli buď k zabitiu niektorých uzlov pri ťažkých vyhľadávacích dopytoch pomocou vedúceho zástupného znaku, alebo k získaniu ističa v samotnom Elasticsearch.
- Navyše, aby sme zabezpečili výkon vyhľadávania, snažili sme sa, aby počet objektov v klastri bol čo najmenší, aby sme spracovali čo najmenej udalostí v úzkom mieste, ktoré sme dostali v masteri.
Nakoniec o monitorovaní
Aby sme sa uistili, že to všetko funguje podľa plánu, monitorujeme nasledovné:
- Každý dátový uzol hlási nášmu cloudu, že existuje a sú na ňom také a také čriepky. Keď niekde niečo uhasíme, klaster po 2-3 sekundách hlási, že v centre A sme uhasili uzly 2, 3 a 4 - to znamená, že v iných dátových centrách za žiadnych okolností nemôžeme uhasiť tie uzly, na ktorých je len jeden úlomok vľavo.
- Keďže poznáme povahu správania pána, veľmi pozorne sa pozeráme na počet čakajúcich úloh. Pretože aj jedna zaseknutá úloha, ak nestihne uplynúť časový limit, sa teoreticky v nejakej núdzovej situácii môže stať dôvodom, prečo nefunguje napríklad propagácia repliky shardu v primárke, a preto prestane fungovať indexovanie.
- Veľmi pozorne sa pozeráme aj na oneskorenia zberača odpadu, pretože s tým sme už počas optimalizácie mali veľké problémy.
- Odmieta podľa vlákna, aby ste vopred pochopili, kde je prekážka.
- No, štandardné metriky, ako je halda, RAM a I/O.
Pri budovaní monitoringu musíte brať do úvahy vlastnosti Thread Pool v Elasticsearch. popisuje možnosti konfigurácie a predvolené hodnoty pre vyhľadávanie a indexovanie, ale úplne mlčí o thread_pool.management. Tieto vlákna spracúvajú najmä dotazy ako _cat/shards a ďalšie podobné, ktoré je vhodné použiť pri zapisovaní monitoringu. Čím väčší je klaster, tým viac takýchto požiadaviek sa vykoná za jednotku času a spomínaný thread_pool.management nielenže nie je prezentovaný v oficiálnej dokumentácii, ale je tiež štandardne obmedzený na 5 vlákien, ktoré sa veľmi rýchlo likvidujú, po ktorý monitoring prestane správne fungovať.
Čo chcem povedať na záver: dokázali sme to! Našim programátorom a vývojárom sme mohli poskytnúť nástroj, ktorý takmer v každej situácii dokáže rýchlo a spoľahlivo poskytnúť informácie o dianí vo výrobe.
Áno, ukázalo sa to ako dosť komplikované, ale napriek tomu sa nám podarilo vtesnať naše priania do existujúcich produktov, ktoré sme si nemuseli prepisovať a prepisovať.
Zdroj: hab.com