Veliko ljudi ima težave z Elasticsearch. Toda kaj se zgodi, ko ga želite uporabiti za shranjevanje dnevnikov »v posebej velikem obsegu«? In ali je tudi neboleče doživeti odpoved katerega koli od več podatkovnih centrov? Kakšno arhitekturo bi morali izdelati in na katere pasti se boste spotaknili?
V Odnoklassniki smo se odločili, da bomo z elastičnim iskanjem rešili vprašanje upravljanja dnevnikov, zdaj pa s Habrom delimo svoje izkušnje: tako o arhitekturi kot o pasteh.
Sem Pjotr Zajcev, delam kot sistemski skrbnik pri Odnoklassniki. Pred tem sem bil tudi admin, delal z Manticore Search, Sphinx search, Elasticsearch. Mogoče, če se pojavi še kakšno ... iskanje, bom verjetno tudi jaz delal z njim. Prostovoljno sodelujem tudi pri številnih odprtokodnih projektih.
Ko sem prišel v Odnoklassniki, sem na razgovoru nepremišljeno rekel, da lahko delam z Elasticsearch. Ko sem se tega naučil in opravil nekaj preprostih nalog, sem dobil veliko nalogo reforme sistema upravljanja dnevnikov, ki je obstajal v tistem času.
Zahteve
Sistemske zahteve so bile oblikovane na naslednji način:
- Graylog naj bi bil uporabljen kot frontend. Ker je podjetje že imelo izkušnje z uporabo tega izdelka, programerji in preizkuševalci so ga poznali, jim je bil znan in priročen.
- Obseg podatkov: v povprečju 50-80 tisoč sporočil na sekundo, če pa se kaj pokvari, potem promet ni omejen z ničemer, lahko je 2-3 milijone vrstic na sekundo
- Po razpravi s strankami o zahtevah glede hitrosti obdelave iskalnih poizvedb smo ugotovili, da je tipičen vzorec uporabe takšnega sistema naslednji: ljudje iščejo dnevnike svoje aplikacije za zadnja dva dni in ne želijo čakati več kot en drugič za rezultat oblikovane poizvedbe.
- Administratorji so vztrajali, da je sistem po potrebi enostavno nadgradljiv, ne da bi se morali poglobiti v njegovo delovanje.
- Tako je edina vzdrževalna naloga, ki jo ti sistemi občasno zahtevajo, menjava določene strojne opreme.
- Poleg tega ima Odnoklassniki odlično tehnično tradicijo: vsaka storitev, ki jo lansiramo, mora preživeti okvaro podatkovnega centra (nenadno, nenačrtovano in popolnoma kadar koli).
Največ nas je stala zadnja zahteva pri izvedbi tega projekta, o kateri bom podrobneje spregovoril.
Sreda
Delujemo v štirih podatkovnih centrih, podatkovna vozlišča Elasticsearch pa se lahko nahajajo le v treh (zaradi številnih netehničnih razlogov).
Ti štirje podatkovni centri vsebujejo približno 18 tisoč različnih virov dnevnikov – strojna oprema, vsebniki, virtualni stroji.
Pomembna lastnost: gruča se začne v vsebnikih ne na fizičnih strojih, ampak na . Zabojniki imajo zagotovljeno 2 jedri, podobno kot 2.0 Ghz v4, z možnostjo recikliranja preostalih jeder, če so v mirovanju.
Z drugimi besedami:
Topologija
Sprva sem videl splošno obliko rešitve, kot sledi:
- Za A-zapisom domene Graylog stojijo 3-4 VIP osebe, to je naslov na katerega se pošiljajo logi.
- vsak VIP je uravnoteženje LVS.
- Za njim gredo dnevniki v baterijo Graylog, nekaj podatkov je v formatu GELF, nekaj v formatu syslog.
- Nato se vse to v velikih serijah zapiše v skupino koordinatorjev Elasticsearch.
- Ti pa pošiljajo zahteve za pisanje in branje ustreznim podatkovnim vozliščem.
Terminologija
Morda vsi ne razumejo podrobno terminologije, zato bi se rad malo ustavil.
Elasticsearch ima več vrst vozlišč - glavno, koordinatorsko, podatkovno vozlišče. Obstajata še dve vrsti za različne transformacije dnevnikov in komunikacijo med različnimi gručami, vendar smo uporabili le te.
Mojster
Izvaja ping za vsa vozlišča, prisotna v gruči, vzdržuje posodobljen zemljevid gruče in ga distribuira med vozlišči, obdeluje logiko dogodkov in izvaja različne vrste vzdrževanja celotne gruče.
Koordinator
Izvaja eno samo nalogo: sprejema zahteve za branje ali pisanje od strank in usmerja ta promet. V primeru, da pride do zahteve za pisanje, bo najverjetneje vprašal masterja, v kateri delček ustreznega indeksa naj jo da, in bo zahtevo preusmeril naprej.
Podatkovno vozlišče
Shranjuje podatke, izvaja iskalne poizvedbe, ki prihajajo od zunaj, in izvaja operacije na drobcih, ki se nahajajo na njem.
Greylog
To je nekaj podobnega fuziji Kibane z Logstashom v skladu ELK. Graylog združuje uporabniški vmesnik in cevovod za obdelavo dnevnikov. Pod pokrovom Graylog poganja Kafka in Zookeeper, ki zagotavljata povezljivost z Graylogom kot gručo. Graylog lahko predpomni dnevnike (Kafka), če Elasticsearch ni na voljo, in ponovi neuspešne zahteve za branje in pisanje, združi in označi dnevnike v skladu z določenimi pravili. Tako kot Logstash ima Graylog funkcijo za spreminjanje vrstic, preden jih zapiše v Elasticsearch.
Poleg tega ima Graylog vgrajeno storitev odkrivanja, ki omogoča, da na podlagi enega razpoložljivega vozlišča Elasticsearch pridobi celotno mapo gruče in jo filtrira po določeni oznaki, kar omogoča usmerjanje zahtevkov na določene vsebnike.
Vizualno izgleda nekako takole:
To je posnetek zaslona iz določenega primerka. Tukaj zgradimo histogram na podlagi iskalne poizvedbe in prikažemo ustrezne vrstice.
Indeksi
Če se vrnem k sistemski arhitekturi, bi se rad podrobneje posvetil temu, kako smo zgradili model indeksa, tako da je vse delovalo pravilno.
V zgornjem diagramu je to najnižja raven: podatkovna vozlišča Elasticsearch.
Indeks je velika virtualna entiteta, sestavljena iz drobcev Elasticsearch. Vsak od drobcev sam po sebi ni nič drugega kot indeks Lucene. Vsak indeks Lucene pa je sestavljen iz enega ali več segmentov.
Pri načrtovanju smo ugotovili, da moramo za izpolnitev zahteve po hitrosti branja velike količine podatkov te podatke enakomerno »razporediti« po podatkovnih vozliščih.
Posledica tega je dejstvo, da mora biti število drobcev na indeks (z replikami) strogo enako številu podatkovnih vozlišč. Prvič, da zagotovimo replikacijski faktor, ki je enak dvema (to pomeni, da lahko izgubimo polovico grozda). In drugič, da lahko obdelamo zahteve za branje in pisanje na vsaj polovici gruče.
Najprej smo določili čas skladiščenja 30 dni.
Porazdelitev drobcev lahko grafično predstavimo na naslednji način:
Celoten temno siv pravokotnik je indeks. Levi rdeči kvadrat v njem je primarni drobec, prvi v indeksu. In modri kvadrat je replika drobca. Nahajajo se v različnih podatkovnih centrih.
Ko dodamo še en shard, gre ta v tretji podatkovni center. In na koncu dobimo to strukturo, ki omogoča izgubo DC brez izgube konsistentnosti podatkov:
Vrtenje indeksov, tj. ustvarjanje novega indeksa in brisanje najstarejšega, smo ga izenačili z 48 urami (glede na vzorec uporabe indeksa: najpogosteje se išče zadnjih 48 ur).
Ta interval vrtenja indeksa je posledica naslednjih razlogov:
Ko iskalna zahteva prispe na določeno podatkovno vozlišče, je z vidika zmogljivosti bolj donosno, če se poizveduje en delček, če je njegova velikost primerljiva z velikostjo kolka vozlišča. To vam omogoča, da "vroč" del indeksa obdržite na kupu in hitro dostopate do njega. Ko je "vročih delov" veliko, se hitrost iskanja po indeksu zmanjša.
Ko vozlišče začne izvajati iskalno poizvedbo na enem drobcu, dodeli število niti, ki je enako številu hipernitnih jeder fizičnega stroja. Če iskalna poizvedba vpliva na veliko število drobcev, potem število niti sorazmerno raste. To negativno vpliva na hitrost iskanja in negativno vpliva na indeksiranje novih podatkov.
Da bi zagotovili potrebno zakasnitev iskanja, smo se odločili za uporabo SSD. Za hitro obdelavo zahtev so morali stroji, ki so gostili te vsebnike, imeti vsaj 56 jeder. Številka 56 je bila izbrana kot pogojno zadostna vrednost, ki določa število niti, ki jih bo Elasticsearch ustvaril med delovanjem. V Elasitcsearch so številni parametri bazena niti neposredno odvisni od števila razpoložljivih jeder, kar posledično neposredno vpliva na zahtevano število vozlišč v gruči po načelu "manj jeder - več vozlišč".
Posledično smo ugotovili, da delček v povprečju tehta približno 20 gigabajtov, na indeks pa je 1 drobcev. V skladu s tem, če jih zavrtimo enkrat na 360 ur, jih imamo 48. Vsak indeks vsebuje podatke za 15 dni.
Vezja za pisanje in branje podatkov
Ugotovimo, kako se podatki beležijo v tem sistemu.
Recimo, da neka zahteva prispe od Grayloga do koordinatorja. Na primer, želimo indeksirati 2-3 tisoč vrstic.
Koordinator, ki je prejel zahtevo od Grayloga, vpraša poveljnika: "V zahtevi za indeksiranje smo posebej določili indeks, vendar ni bilo določeno, v kateri delček naj ga zapišemo."
Glavni odgovori: »Zapišite te informacije v delček številka 71,« nakar se pošljejo neposredno v ustrezno podatkovno vozlišče, kjer se nahaja primarni delček številka 71.
Po tem se transakcijski dnevnik replicira na repliko-shard, ki se nahaja v drugem podatkovnem centru.
Zahteva za iskanje prispe od Grayloga do koordinatorja. Koordinator ga preusmeri glede na indeks, medtem ko Elasticsearch porazdeli zahteve med primarni-shard in replika-shard po principu krožnega dela.
180 vozlišč se odziva neenakomerno, med odzivom pa koordinator nabira informacije, ki so jih že »izpljunila« hitrejša podatkovna vozlišča. Po tem, ko so prispele vse informacije ali je zahteva dosegla časovno omejitev, vse posreduje neposredno stranki.
Ta celoten sistem v povprečju obdela iskalne poizvedbe za zadnjih 48 ur v 300–400 ms, razen tistih poizvedb z začetnim nadomestnim znakom.
Rože z Elasticsearch: nastavitev Jave
Da bi vse delovalo tako, kot smo prvotno želeli, smo porabili zelo dolgo časa za razhroščevanje najrazličnejših stvari v gruči.
Prvi del odkritih težav je bil povezan z načinom, kako je Java privzeto vnaprej konfigurirana v Elasticsearch.
Problem ena
Opazili smo zelo veliko poročil, da na ravni Lucene, ko se izvajajo opravila v ozadju, spajanje segmentov Lucene ne uspe z napako. Hkrati je bilo v dnevnikih razvidno, da gre za napako OutOfMemoryError. Iz telemetrije smo videli, da je kolk prost, in ni bilo jasno, zakaj je ta operacija neuspešna.
Izkazalo se je, da se združitve indeksa Lucene pojavijo zunaj kolka. In kontejnerji so glede porabljenih virov precej strogo omejeni. Samo kopica se je lahko prilegala tem virom (vrednost heap.size je bila približno enaka RAM-u), nekatere operacije zunaj kopice pa so se zrušile z napako pri dodelitvi pomnilnika, če se iz nekega razloga niso prilegale ~500 MB, ki so ostali pred omejitvijo.
Popravek je bil precej trivialen: količina RAM-a, ki je bila na voljo za vsebnik, je bila povečana, nakar smo pozabili, da sploh imamo takšne težave.
Drugi problem
4-5 dni po zagonu gruče smo opazili, da so podatkovna vozlišča začela občasno izpadati iz gruče in vstopiti vanj po 10-20 sekundah.
Ko smo začeli ugotavljati, se je izkazalo, da ta pomnilnik izven kopice v Elasticsearch ni na noben način nadzorovan. Ko smo vsebniku dali več pomnilnika, smo lahko napolnili neposredna področja vmesnega pomnilnika z različnimi informacijami, ki so bile počiščene šele, ko je bil eksplicitni GC zagnan iz Elasticsearch.
V nekaterih primerih je ta operacija trajala precej dolgo in v tem času je gruča uspela to vozlišče označiti kot že izključeno. Ta problem je dobro opisan .
Rešitev je bila naslednja: omejili smo zmožnost Jave, da za te operacije uporablja večino pomnilnika zunaj kopice. Omejili smo ga na 16 gigabajtov (-XX:MaxDirectMemorySize=16g), s čimer smo zagotovili, da je bil eksplicitni GC klican veliko pogosteje in obdelan veliko hitreje, s čimer ni več destabiliziral gruče.
Problem tri
Če mislite, da je težav z "vozlišči, ki zapustijo gručo v najbolj nepričakovanem trenutku" konec, se motite.
Ko smo konfigurirali delo z indeksi, smo izbrali mmapfs na svežih drobcih z veliko segmentacijo. To je bila precejšnja napaka, ker se pri uporabi mmapfs datoteka preslika v RAM, nato pa delamo s preslikano datoteko. Zaradi tega se izkaže, da ko GC poskuša ustaviti niti v aplikaciji, gremo na varno točko za zelo dolgo časa, na poti do nje pa se aplikacija neha odzivati na zahteve masterja o tem, ali je živa . V skladu s tem master meni, da vozlišče ni več prisotno v gruči. Po tem, po 5-10 sekundah, zbiralnik smeti deluje, vozlišče oživi, znova vstopi v gručo in začne inicializirati drobce. Vse skupaj je bilo zelo podobno "produkciji, ki smo si jo zaslužili" in ni bilo primerno za kaj resnega.
Da bi se znebili tega vedenja, smo najprej preklopili na standardne niofs, nato pa smo, ko smo prešli s pete različice Elastic na šesto, poskusili s hybridfs, kjer ta težava ni bila ponovljena. Več o vrstah shranjevanja lahko preberete .
Problem štiri
Potem je bil tu še en zelo zanimiv problem, ki smo ga obravnavali rekordno dolgo. Ujeli smo ga 2-3 mesece, ker je bil njegov vzorec popolnoma nerazumljiv.
Včasih so naši koordinatorji odšli na Full GC, običajno nekje po kosilu, in se od tam nikoli več niso vrnili. Hkrati je pri beleženju zamude GC izgledalo takole: vse gre dobro, dobro, dobro, potem pa gre nenadoma vse zelo slabo.
Sprva smo mislili, da imamo zlobnega uporabnika, ki sproži nekakšno zahtevo, ki koordinatorja vrže iz delovnega načina. Zelo dolgo smo beležili zahteve in poskušali ugotoviti, kaj se dogaja.
Posledično se je izkazalo, da v trenutku, ko uporabnik sproži veliko zahtevo in pride do določenega koordinatorja Elasticsearch, se nekatera vozlišča odzovejo dlje kot druga.
In medtem ko koordinator čaka na odgovor vseh vozlišč, zbira rezultate, poslane iz vozlišč, ki so se že odzvala. Za GC to pomeni, da se naši vzorci uporabe kopice spreminjajo zelo hitro. In GC, ki smo ga uporabili, ni bil kos tej nalogi.
Edini popravek, ki smo ga našli za spremembo obnašanja gruče v tej situaciji, je selitev na JDK13 in uporaba zbiralnika smeti Shenandoah. To je rešilo problem, naši koordinatorji so prenehali padati.
Tu so se težave z Javo končale in začele so se težave s pasovno širino.
"Jagode" z Elasticsearch: prepustnost
Težave s prepustnostjo pomenijo, da naša gruča deluje stabilno, vendar je ob konicah števila indeksiranih dokumentov in med manevri zmogljivost nezadostna.
Prvi simptom, na katerega naletimo: med nekaterimi "eksplozijami" v proizvodnji, ko se nenadoma ustvari zelo veliko število dnevnikov, začne napaka pri indeksiranju es_rejected_execution pogosto utripati v Graylogu.
To je bilo posledica dejstva, da lahko thread_pool.write.queue na enem podatkovnem vozlišču, do trenutka, ko je Elasticsearch sposoben obdelati zahtevo za indeksiranje in naložiti informacije na delček na disku, privzeto predpomni le 200 zahtev. In v O tem parametru se govori zelo malo. Navedeni sta samo največje število niti in privzeta velikost.
Seveda smo šli zasukati to vrednost in ugotovili naslednje: natančneje, v naši nastavitvi je do 300 zahtev precej dobro predpomnjenih, višja vrednost pa je polna dejstva, da spet letimo v Full GC.
Poleg tega, ker so to paketi sporočil, ki prispejo znotraj ene zahteve, je bilo treba Graylog prilagoditi tako, da ne piše pogosto in v majhnih paketih, ampak v velikih paketih ali enkrat na 3 sekunde, če paket še ni popoln. V tem primeru se izkaže, da informacije, ki jih zapišemo v Elasticsearch, ne postanejo na voljo v dveh sekundah, ampak v petih (kar nam zelo ustreza), vendar je število ponovnih vnosov, ki jih je treba narediti, da se prebijemo skozi veliko kopica informacij se zmanjša.
To je še posebej pomembno v tistih trenutkih, ko se je nekje nekaj zrušilo in o tem besno poroča, da ne bi dobili popolnoma nezaželene Elastic in čez nekaj časa - vozlišča Graylog, ki so neuporabna zaradi zamašenih medpomnilnikov.
Poleg tega, ko smo imeli te iste eksplozije v proizvodnji, smo prejeli pritožbe programerjev in preizkuševalcev: v trenutku, ko so res potrebovali te dnevnike, so jih dobili zelo počasi.
Začeli so ugotavljati. Po eni strani je bilo jasno, da so bile tako iskalne poizvedbe kot poizvedbe za indeksiranje v bistvu obdelane na istih fizičnih strojih in tako ali drugače bo prišlo do določenih izpadov.
Toda temu bi se lahko delno izognili zaradi dejstva, da se je v šesti različici Elasticsearch pojavil algoritem, ki vam omogoča porazdelitev poizvedb med ustreznimi podatkovnimi vozlišči ne po načelu naključnega krožnega dela (vsebnik, ki indeksira in hrani primarni -shard je lahko zelo zaseden, ne bo mogoče hitro odgovoriti), ampak posredovati to zahtevo v manj obremenjen vsebnik z repliko-shard, ki se bo odzval veliko hitreje. Z drugimi besedami, prišli smo do use_adaptive_replica_selection: true.
Bralna slika začne izgledati takole:
Prehod na ta algoritem je omogočil bistveno izboljšanje časa poizvedb v tistih trenutkih, ko smo imeli velik pretok dnevnikov za pisanje.
Končno je bila glavna težava neboleča odstranitev podatkovnega centra.
Kaj smo želeli od gruče takoj po izgubi povezave z enim DC:
- Če imamo trenutnega glavnega v neuspelem podatkovnem centru, bo ta znova izbran in kot vloga premaknjen v drugo vozlišče v drugem DC.
- Master bo hitro odstranil vsa nedostopna vozlišča iz gruče.
- Na podlagi preostalih bo razumel: v izgubljenem podatkovnem centru smo imeli takšne in drugačne primarne sharde, v preostalih podatkovnih centrih bo hitro promoviral komplementarne replike shardov, mi pa bomo nadaljevali z indeksiranjem podatkov.
- Zaradi tega se bo prepustnost pisanja in branja grozda postopoma poslabšala, vendar bo na splošno vse delovalo, čeprav počasi, a stabilno.
Kot se je izkazalo, smo želeli nekaj takega:
In dobili smo naslednje:
Kako se je to zgodilo?
Ko je podatkovni center padel, je naš gospodar postal ozko grlo.
Zakaj?
Dejstvo je, da ima master TaskBatcher, ki je odgovoren za distribucijo določenih nalog in dogodkov v gruči. Vsak izhod vozlišča, kakršno koli napredovanje drobca iz replike v primarno, vsaka naloga za ustvarjanje drobca nekje - vse to gre najprej v TaskBatcher, kjer se obdela zaporedno in v eni niti.
Ob umiku enega podatkovnega centra se je izkazalo, da so vsa podatkovna vozlišča v preživelih podatkovnih centrih menila za svojo dolžnost obvestiti gospodarja »izgubili smo takšne in take šarde in takšna in drugačna podatkovna vozlišča«.
Hkrati so preživela podatkovna vozlišča poslala vse te informacije trenutnemu glavnemu in poskušala počakati na potrditev, da jih je sprejel. Na to niso čakali, saj je mojster prejel naloge hitreje, kot je lahko odgovoril. Vozlišča so potekla pri ponavljajočih se zahtevah, glavni pa v tem trenutku ni niti poskušal odgovoriti nanje, ampak je bil popolnoma zatopljen v nalogo razvrščanja zahtev po prioriteti.
V terminalski obliki se je izkazalo, da so podatkovna vozlišča pošiljala neželeno pošto masterju do te mere, da je prešel v polni GC. Po tem se je naša glavna vloga premaknila na neko naslednje vozlišče, zgodilo se mu je popolnoma isto in posledično se je gruča popolnoma sesula.
Izvedli smo meritve in pred verzijo 6.4.0, kjer je bilo to popravljeno, je bilo dovolj, da smo hkrati izpisali le 10 podatkovnih vozlišč od 360, da smo popolnoma zaustavili gručo.
Videti je bilo nekako takole:
Po različici 6.4.0, kjer je bila ta strašna napaka odpravljena, so podatkovna vozlišča prenehala ubijati glavnega. Toda to ga ni naredilo "pametnejšega". Namreč: ko izpišemo 2, 3 ali 10 (poljubno število razen enega) podatkovnih vozlišč, master prejme neko prvo sporočilo, ki pravi, da je vozlišče A zapustilo, in poskuša to sporočiti vozlišču B, vozlišču C, vozlišču D.
In trenutno je to mogoče rešiti le z nastavitvijo časovne omejitve za poskuse, da bi nekomu povedali nekaj, kar je približno 20-30 sekund, in tako nadzirati hitrost premikanja podatkovnega centra iz gruče.
Načeloma se to ujema z zahtevami, ki so bile prvotno predstavljene h končnemu izdelku v okviru projekta, a z vidika »čiste znanosti« je to napaka. Kar so, mimogrede, razvijalci uspešno popravili v različici 7.2.
Še več, ko je določeno podatkovno vozlišče ugasnilo, se je izkazalo, da je razširjanje informacij o njegovem izstopu pomembnejše od sporočanja celotnemu grozdu, da so na njem takšni in drugačni primarni-shard-i (da bi promovirali repliko-shard v drugih podatkih). center v primarnem in na njih bi lahko zapisali informacije).
Zato, ko je vse že zamrlo, sproščena podatkovna vozlišča niso takoj označena kot zastarela. V skladu s tem smo prisiljeni počakati, da potečejo vsi pingi do sproščenih podatkovnih vozlišč, in šele po tem nam začne naš grozd sporočati, da moramo tam, tam in tam nadaljevati s snemanjem informacij. Več o tem si lahko preberete .
Posledično nam operacija umika podatkovnega centra danes v prometni konici vzame približno 5 minut. Za tako velikega in okornega kolosa je to kar dober rezultat.
Posledično smo prišli do naslednje odločitve:
- Imamo 360 podatkovnih vozlišč s 700 gigabajtnimi diski.
- 60 koordinatorjev za usmerjanje prometa skozi ta ista podatkovna vozlišča.
- 40 masterjev, ki so nam ostali kot nekakšna dediščina od različic pred 6.4.0 - da bi preživeli umik podatkovnega centra, smo bili psihično pripravljeni izgubiti več strojev, da bi imeli zagotovljen kvorum masterjev tudi v najslabši možni scenarij
- Vsi poskusi združevanja vlog na enem vsebniku so naleteli na dejstvo, da bi se vozlišče prej ali slej pod obremenitvijo zlomilo.
- Celotna gruča uporablja heap.size 31 gigabajtov: vsi poskusi zmanjšanja velikosti so privedli do uničenja nekaterih vozlišč pri težkih iskalnih poizvedbah z vodilnim nadomestnim znakom ali do odklopnika v samem Elasticsearch.
- Poleg tega smo za zagotavljanje zmogljivosti iskanja poskušali ohraniti čim manjše število objektov v gruči, da bi obdelali čim manj dogodkov v ozkem grlu, ki smo ga dobili v masterju.
Končno o spremljanju
Da bi zagotovili, da vse to deluje, kot je predvideno, spremljamo naslednje:
- Vsako podatkovno vozlišče sporoči našemu oblaku, da obstaja, in na njem so takšni in drugačni drobci. Ko nekje nekaj ugasnemo, grozd po 2-3 sekundah sporoči, da smo v centru A ugasnili vozlišča 2, 3 in 4 - to pomeni, da v drugih podatkovnih centrih pod nobenim pogojem ne moremo ugasniti tistih vozlišč, na katerih je samo en shard. levo.
- Ker poznamo naravo gospodarjevega vedenja, zelo natančno pogledamo število čakajočih nalog. Kajti celo ena zataknjena naloga, če ne poteče pravočasno, lahko teoretično v nekaterih izrednih razmerah postane razlog, da na primer promocija replike shard v primarni ne deluje, zaradi česar bo indeksiranje prenehalo delovati.
- Zelo pozorno spremljamo tudi zamude zbiralnika smeti, saj smo imeli s tem velike težave že med optimizacijo.
- Zavrne po niti, da vnaprej razume, kje je ozko grlo.
- No, standardne metrike, kot so kopica, RAM in V/I.
Pri gradnji nadzora morate upoštevati funkcije Thread Pool v Elasticsearch. opisuje konfiguracijske možnosti in privzete vrednosti za iskanje in indeksiranje, vendar je popolnoma tiho o thread_pool.management Te niti obdelujejo zlasti poizvedbe, kot so _cat/shards in druge podobne, ki so priročne za uporabo pri pisanju nadzora. Večja kot je gruča, več takšnih zahtev se izvede na časovno enoto, prej omenjeni thread_pool.management pa ne samo da ni predstavljen v uradni dokumentaciji, ampak je tudi privzeto omejen na 5 niti, kar se zelo hitro odstrani, potem ko kateri nadzor preneha delovati pravilno.
Za konec bi rad povedal: uspelo nam je! Našim programerjem in razvijalcem smo lahko dali orodje, ki lahko v skoraj vsaki situaciji hitro in zanesljivo zagotovi informacije o tem, kaj se dogaja v proizvodnji.
Da, izkazalo se je za precej zapleteno, a kljub temu smo svoje želje uspeli umestiti v obstoječe produkte, ki nam jih ni bilo treba sami krpati in prepisovati.
Vir: www.habr.com