Elasticsearch se suočava sa mnogim ljudima. Ali šta se događa kada ga želite koristiti za pohranjivanje dnevnika "u posebno velikoj količini"? Da, i bezbolno preživjeti kvar bilo kojeg od nekoliko podatkovnih centara? Kakvu arhitekturu treba uraditi i na koje zamke ćete naići?
Mi u Odnoklassniki smo odlučili riješiti problem upravljanja dnevnikom uz pomoć elasticsearch-a, a sada dijelimo svoje iskustvo s Habrom: i o arhitekturi i o zamkama.
Ja sam Pyotr Zaitsev, radim kao sistem administrator u Odnoklassniki. Prije toga je bio i admin, radio je sa Manticore Search, Sphinx search, Elasticsearch. Možda ako se pojavi još jedna...potraga, vjerovatno ću i ja raditi s njom. Također učestvujem u brojnim open source projektima na dobrovoljnoj osnovi.
Kada sam došao u Odnoklassniki, nepromišljeno sam na intervjuu rekao da mogu da radim sa Elasticsearch. Nakon što sam se navikao i obavio nekoliko jednostavnih zadataka, dobio sam veliki zadatak da reformišem sistem upravljanja dnevnikom koji je postojao u to vrijeme.
zahtjevi
Zahtevi za sistem su formulisani na sledeći način:
- Graylog je trebao biti korišten kao frontend. Budući da je kompanija već imala iskustva u korištenju ovog proizvoda, programeri i testeri su to znali, bio im je poznat i pogodan.
- Obim podataka: u prosjeku 50-80 hiljada poruka u sekundi, ali ako se nešto pokvari, onda promet nije ničim ograničen, može biti 2-3 miliona linija u sekundi
- Nakon što smo razgovarali s kupcima o zahtjevima za brzinom obrade upita za pretraživanje, shvatili smo da je tipičan obrazac za korištenje ovakvog sistema sljedeći: ljudi traže svoje dnevnike aplikacija za posljednja dva dana i ne žele čekati više od sekunde za rezultat za formulirani upit.
- Administratori su insistirali na tome da se sistem lako skalira ako je potrebno, a da od njih nije potrebno da duboko razumeju kako funkcioniše.
- Tako da je jedini zadatak održavanja koji je tim sistemima bio potreban periodično bila promjena neke vrste hardvera.
- Osim toga, Odnoklassniki ima veliku tehničku tradiciju: bilo koja usluga koju pokrenemo mora preživjeti kvar podatkovnog centra (iznenadni, neplanirani i apsolutno u bilo kojem trenutku).
Posljednji zahtjev u realizaciji ovog projekta dat nam je uz najveće krvoproliće, o čemu ću detaljnije govoriti.
Životna sredina
Radimo na četiri data centra, dok Elasticsearch podatkovni čvorovi mogu biti locirani samo u tri (iz niza netehničkih razloga).
U ova četiri data centra postoji oko 18 hiljada različitih izvora dnevnika - komadi željeza, kontejneri, virtuelne mašine.
Važna karakteristika: klaster se pokreće u kontejnerima ne na fizičkim mašinama, već na . Kontejneri imaju zagarantovana 2 jezgra slična 2.0Ghz v4 sa mogućnošću recikliranja ostatka jezgara ako su u mirovanju.
Drugim riječima:
Topologija
Opšti pogled na rešenje sam u početku video ovako:
- 3-4 VIP osobe stoje iza A-zapisa Graylog domena, to je adresa na koju se šalju logovi.
- svaki VIP je LVS balanser.
- Nakon toga, dnevnici idu u Graylog bateriju, neki od podataka idu u GELF formatu, neki u syslog formatu.
- Zatim se sve to u velikim serijama zapisuje na bateriju od Elasticsearch koordinatora.
- A oni, zauzvrat, šalju zahtjeve za pisanje i čitanje relevantnim čvorovima podataka.
Terminologija
Možda ne razumiju svi detaljno terminologiju, pa bih se malo zadržao na tome.
Postoji nekoliko tipova čvorova u Elasticsearch-u - glavni, koordinator, podatkovni čvor. Postoje još dva tipa za različite transformacije dnevnika i međusobno povezivanje različitih klastera, ali mi smo koristili samo one navedene.
Majstor
Pinguje sve čvorove prisutne u klasteru, održava ažurnu mapu klastera i distribuira je između čvorova, obrađuje logiku događaja i obavlja razne vrste održavanja u cijelom klasteru.
Koordinator
Obavlja samo jedan zadatak: prima zahtjeve klijenata za čitanje ili pisanje i usmjerava ovaj promet. U slučaju da postoji zahtjev za pisanje, on će najvjerovatnije pitati mastera u koji dio relevantnog indeksa da ga stavi, i preusmjeriti zahtjev dalje.
data node
Pohranjuje podatke, izvršava upite za pretraživanje i operacije na dijelovima koji se nalaze na njemu, koji stižu izvana.
Greylog
To je kao spajanje Kibana sa Logstash-om u ELK steku. Graylog kombinuje i korisničko sučelje i cevovod za obradu dnevnika. Ispod haube, Graylog pokreće Kafku i Zookeeper, koji obezbjeđuju povezanost sa Graylogom kao klasterom. Graylog može keširati dnevnike (Kafka) u slučaju da Elasticsearch nije dostupan i ponoviti neuspješne zahtjeve za čitanje i pisanje, grupirati i označiti dnevnike prema određenim pravilima. Kao i Logstash, Graylog ima funkciju modifikacije stringova prije pisanja u Elasticsearch.
Osim toga, Graylog ima ugrađenu uslugu otkrivanja koja omogućava, na osnovu jednog dostupnog Elasticsearch čvora, da dobije cijelu mapu klastera i filtrira je prema određenoj oznaci, što omogućava slanje zahtjeva određenim kontejnerima.
Vizuelno to izgleda ovako:
Ovo je snimak ekrana iz određene instance. Ovdje gradimo histogram na osnovu upita za pretraživanje i prikazujemo relevantne linije.
Indeksi
Vraćajući se na arhitekturu sistema, želeo bih da se detaljnije zadržim na tome kako smo napravili indeksni model kako bi sve ispravno funkcionisalo.
U dijagramu iznad, ovo je najniži nivo: Elasticsearch čvorovi podataka.
Indeks je veliki virtuelni entitet sastavljen od Elasticsearch fragmenata. Sama po sebi, svaka od krhotina nije ništa drugo do Lucene indeks. A svaki Lucene indeks se zauzvrat sastoji od jednog ili više segmenata.
Prilikom dizajniranja, shvatili smo da, kako bismo ispunili zahtjeve za brzinom čitanja velike količine podataka, moramo ravnomjerno „razmazati“ te podatke po čvorovima podataka.
To je rezultiralo činjenicom da bi broj dijelova po indeksu (sa replikama) trebao biti striktno jednak broju čvorova podataka. Prvo, da bismo osigurali faktor replikacije dva (to jest, možemo izgubiti polovinu klastera). I, drugo, da bi se obrađivali zahtjevi za čitanje i pisanje na barem polovini klastera.
Vrijeme skladištenja prvo smo odredili na 30 dana.
Distribucija krhotina može se grafički prikazati na sljedeći način:
Cijeli tamno sivi pravougaonik je indeks. Lijevi crveni kvadrat u njemu je primarni dio, prvi u indeksu. A plavi kvadrat je replika krhotina. Nalaze se u različitim data centrima.
Kada dodamo još jednu dionicu, ona ide u treći podatkovni centar. I, na kraju, dobijamo takvu strukturu koja pruža mogućnost gubitka DC-a bez gubitka konzistentnosti podataka:
Rotacija indeksa, tj. kreiranjem novog indeksa i brisanjem najstarijeg, postavili smo ga jednakim 48 sati (prema obrascu korištenja indeksa: najčešće se pretražuju zadnjih 48 sati).
Ovaj interval rotacije indeksa je zbog sljedećih razloga:
Kada zahtjev za pretraživanje stigne do određenog čvora podataka, tada je, sa stanovišta performansi, isplativije kada se anketira jedna dionica ako je njena veličina uporediva sa veličinom kuka čvora. Ovo vam omogućava da zadržite "vrući" dio indeksa u hrpi i brzo mu pristupite. Kada ima puno “vrućih dijelova”, brzina pretraživanja indeksa opada.
Kada čvor počne da izvršava upit za pretragu na jednom segmentu, on dodeljuje broj niti jednak broju hiper-nitnih jezgara fizičke mašine. Ako upit za pretraživanje utječe na veliki broj dijelova, tada broj niti raste proporcionalno. Ovo loše utiče na brzinu pretraživanja i negativno utiče na indeksiranje novih podataka.
Kako bismo osigurali potrebnu latencije pretraživanja, odlučili smo koristiti SSD. Da bi brzo obradili zahtjeve, mašine koje su ugostile ove kontejnere trebale su da imaju najmanje 56 jezgara. Broj 56 je odabran kao uslovno dovoljna vrijednost koja određuje broj niti koje će Elasticsearch generirati tokom rada. U Elasitcsearch-u, mnogi parametri skupa niti direktno zavise od broja dostupnih jezgara, što zauzvrat direktno utiče na potreban broj čvorova u klasteru prema principu "manje jezgri - više čvorova".
Kao rezultat toga, dobili smo da je u prosjeku jedna šarda teška oko 20 gigabajta, a po 1 indeksu ima 360 shardova. Prema tome, ako ih rotiramo svakih 48 sati, onda ih imamo 15. Svaki indeks sadrži podatke za 2 dana.
Šeme za pisanje i čitanje podataka
Pogledajmo kako se podaci snimaju u ovom sistemu.
Recimo da od Grayloga stigne neki zahtjev koordinatoru. Na primjer, želimo indeksirati 2-3 hiljade redova.
Koordinator, nakon što je primio zahtjev od Graylog-a, pita mastera: "U zahtjevu za indeksiranje smo posebno naveli indeks, ali nije navedeno u koji šard da to napišemo."
Master odgovara: „Upišite ovu informaciju u šard broj 71“, nakon čega se šalje direktno u relevantni čvor podataka, gdje se nalazi primarni dio broj 71.
Nakon toga, dnevnik transakcija se replicira u repliku-shard, koja se već nalazi u drugom podatkovnom centru.
Od Graylog-a koordinatoru stiže zahtjev za pretragu. Koordinator ga preusmjerava po indeksu, dok Elasticsearch distribuira zahtjeve između primarnog-sharda i replike-sharda prema principu round-robin-a.
Čvorovi u količini od 180 reaguju neravnomjerno, a dok oni odgovaraju, koordinator akumulira informaciju koju su brži čvorovi podataka već "ispljunuli" u njega. Nakon toga, kada stignu sve informacije, ili dođe do isteka vremena na zahtjev, on sve daje direktno klijentu.
Ceo ovaj sistem u proseku ispunjava zahteve za pretragu u poslednjih 48 sati za 300-400ms, isključujući one zahteve koji su sa vodećim džoker znakom.
Cvijeće s Elasticsearch: Postavljanje Jave
Da bi sve funkcionisalo onako kako smo prvobitno želeli, proveli smo veoma dugo vremena na otklanjanju grešaka u velikom broju stvari u klasteru.
Prvi dio otkrivenih problema odnosio se na to kako je Java unaprijed konfigurisana u Elasticsearch-u po defaultu.
Problem jedan
Vidjeli smo vrlo veliki broj izvještaja koje imamo na nivou Lucene, kada se pozadinski poslovi izvode, spajanje Lucene segmenta ne uspijeva. U isto vrijeme, u evidenciji je bilo jasno da se radi o grešci OutOfMemoryError. Iz telemetrije smo vidjeli da je kuk slobodan, a nije bilo jasno zašto ova operacija pada.
Ispostavilo se da se spajanje Lucene indeksa događa izvan kuka. A kontejneri su prilično ograničeni u smislu utrošenih resursa. Samo se hrpa uklapa u ove resurse (vrijednost heap.size je bila približno jednaka RAM-u), a neke operacije van hrpe su pale uz grešku u dodjeli memorije ako se iz nekog razloga nisu uklapale u onih ~500MB koji su ostali prije ograničenja .
Popravka je bila sasvim trivijalna: povećana je količina RAM-a za kontejner, nakon čega su zaboravili da uopće imamo takvih problema.
Problem dva
4-5 dana nakon pokretanja klastera, primijetili smo da čvorovi podataka počinju periodično ispadati iz klastera i ulaziti u njega nakon 10-20 sekundi.
Kada su se popeli da to shvate, ispostavilo se da se ova vrlo off-heap memorija u Elasticsearchu praktički ne kontrolira ni na koji način. Kada smo dali više memorije kontejneru, dobili smo priliku da punimo direktne baferske bazene raznim informacijama, a ona je obrisana tek nakon što je Elasticsearch pokrenuo eksplicitni GC.
U nekim slučajevima, ova operacija je trajala dosta vremena, a za to vrijeme klaster je uspio označiti ovaj čvor kao već oslobođen. Ovo pitanje je dobro opisano. .
Rješenje je bilo sljedeće: ograničili smo Javinu sposobnost da koristi najveći dio memorije izvan hrpe za ove operacije. Ograničili smo ga na 16 gigabajta (-XX:MaxDirectMemorySize=16g), osiguravajući da se eksplicitni GC poziva mnogo češće i da radi mnogo brže, čime se prestaje destabilizirati klaster.
Problem tri
Ako mislite da su problemi sa “čvorovima koji napuštaju klaster u najneočekivanijem trenutku” završeni, varate se.
Kada smo konfigurisali rad sa indeksima, odlučili smo se za mmapfs kako bismo na svježim krhotinama sa visokom segmentacijom. Ovo je bila prilično velika greška, jer kada se koristi mmapfs, datoteka se mapira u RAM, a zatim radimo sa mapiranom datotekom. Zbog toga se ispostavlja da kada GC pokuša zaustaviti niti u aplikaciji, idemo na sigurnosnu točku jako dugo, a na putu do nje aplikacija prestaje da odgovara na zahtjeve čarobnjaka o tome da li je živa . U skladu s tim, master vjeruje da čvor više nije prisutan u našem klasteru. Nakon toga, nakon 5-10 sekundi, sakupljač smeća radi, čvor oživljava, ponovo ulazi u klaster i počinje inicijalizirati krhotine. Sve je to jako ličilo na “produkciju kakvu smo zaslužili” i nije odgovaralo ništa ozbiljno.
Da bismo se riješili ovog ponašanja, prvo smo prešli na standardne niof-ove, a onda, kada smo migrirali sa pete verzije Elastic-a na šestu, pokušali smo s hybridf-ovima, gdje se ovaj problem nije reprodukovao. Možete pročitati više o vrstama skladištenja .
Problem četiri
Zatim se pojavio još jedan vrlo zabavan problem koji smo tretirali rekordno dugo. Hvatali smo je 2-3 mjeseca, jer je njen obrazac bio apsolutno nerazumljiv.
Ponekad su naši koordinatori odlazili na Full GC, obično negdje poslijepodne, i nikada se odatle nisu vraćali. U isto vrijeme, prilikom evidentiranja kašnjenja GC-a, izgledalo je ovako: sve nam ide dobro, dobro, dobro, a onda jednom - i sve je oštro loše.
U početku smo mislili da imamo zlog korisnika koji pokreće neku vrstu zahtjeva koji izbacuje koordinatora iz radnog moda. Zahtjeve smo evidentirali jako dugo, pokušavajući saznati šta se dešava.
Kao rezultat toga, ispostavilo se da u trenutku kada neki korisnik pokrene veliki zahtjev, a on pogodi određeni Elasticsearch koordinator, neki čvorovi odgovaraju duže od drugih.
I dok koordinator čeka odgovor svih čvorova, on akumulira u sebi rezultate poslane od čvorova koji su već odgovorili. Za GC, to znači da se naš obrazac korištenja kuka vrlo brzo mijenja. A GC koji smo koristili nije se mogao nositi s ovim zadatkom.
Jedino rješenje koje smo pronašli za promjenu ponašanja klastera u ovoj situaciji je migracija na JDK13 i korištenje Shenandoah sakupljača smeća. Time je riješen problem, naši koordinatori su prestali da padaju.
Tu su završili problemi sa Javom i počeli problemi sa propusnim opsegom.
"Bobice" sa Elasticsearch: propusnost
Problemi sa propusnošću znače da je naš klaster stabilan, ali na vrhuncu broja indeksiranih dokumenata iu vrijeme manevara performanse su nedostatne.
Prvi simptom na koji sam naišao: tokom neke vrste „eksplozija“ u proizvodnji, kada se naglo generiše veoma veliki broj logova, greška indeksiranja es_rejected_execution često treperi u Graylogu.
To je bilo zbog činjenice da thread_pool.write.queue na jednom čvoru podataka dok Elasticsearch ne bude u stanju obraditi zahtjev za indeksiranje i baciti informacije u dio na disku, po defaultu može keširati samo 200 zahtjeva. I unutra vrlo malo se govori o ovom parametru. Naznačeni su samo ograničeni broj niti i zadana veličina.
Naravno, krenuli smo da izvrnemo ovu vrijednost i otkrili smo sljedeće: konkretno, u našoj postavci, do 300 zahtjeva se prilično dobro kešira, a veća vrijednost je bremenita činjenicom da opet letimo na Full GC.
Osim toga, pošto se radi o serijama poruka koje stižu u okviru jednog zahtjeva, bilo je potrebno i podesiti Graylog tako da ne piše često i u malim serijama, već u velikim serijama ili jednom u 3 sekunde ako serija još uvijek nije puna . U ovom slučaju ispada da informacije koje upišemo u Elasticsearch postaju dostupne ne nakon dvije sekunde, već nakon pet (što nam sasvim odgovara), ali broj ponovnih tragova koji se moraju obaviti da bi se pogurao veliki snop informacija smanjuje se.
Ovo je posebno važno u onim trenucima kada se nešto negdje srušilo i bijesno izvještava o tome, kako ne bi potpuno spamovali Elastic, a nakon nekog vremena - Graylog čvorovi koji ne rade zbog začepljenih bafera.
Osim toga, kada smo imali te iste eksplozije u proizvodnji, dobijali smo pritužbe od programera i testera: u trenutku kada im ovi dnevniki zaista trebaju, oni im se izdaju vrlo sporo.
Počeli su da shvataju. S jedne strane, bilo je jasno da se i upiti za pretraživanje i upiti za indeksiranje obrađuju, zapravo, na istim fizičkim mašinama, i na ovaj ili onaj način će doći do određenih povlačenja.
Ali to bi se moglo djelomično zaobići zbog činjenice da se u šestoj verziji Elasticsearch-a pojavio algoritam koji vam omogućava da distribuirate zahtjeve između relevantnih čvorova podataka ne prema principu slučajnog round-robin (kontejner koji indeksira i drži primarni dio). može biti vrlo zauzet, neće biti načina da se brzo odgovori), ali da se ovaj zahtjev usmjeri na manje opterećeni kontejner s replikom-shardom, koji će odgovoriti znatno brže. Drugim riječima, završili smo sa use_adaptive_replica_selection: true.
Slika za čitanje počinje izgledati ovako:
Prelazak na ovaj algoritam nam je omogućio da značajno poboljšamo vrijeme upita u onim trenucima kada smo imali veliki tok dnevnika za pisanje.
Konačno, glavni problem je bilo bezbolno uklanjanje data centra.
Ono što smo htjeli od klastera odmah nakon gubitka komunikacije s jednim DC-om:
- Ako imamo trenutnog mastera u palom centru podataka, onda će on biti ponovo izabran i premješten kao uloga na drugi čvor u drugom DC-u.
- Master će brzo izbaciti sve nedostupne čvorove iz klastera.
- Na osnovu ostalog, on će shvatiti: u izgubljenom data centru smo imali takve i takve primarne šardove, brzo će promovirati komplementarne replike šardove u preostalim podatkovnim centrima, a mi ćemo nastaviti indeksirati podatke.
- Kao rezultat toga, širina pojasa klastera za pisanje i čitanje će se glatko degradirati, ali općenito će sve raditi, iako sporo, ali postojano.
Kako se ispostavilo, željeli smo nešto ovako:
I dobio sljedeće:
Kako se to dogodilo?
U vrijeme pada data centra, master nam je postao usko grlo.
Zašto?
Činjenica je da čarobnjak ima TaskBatcher koji je odgovoran za distribuciju određenih zadataka i događaja u klasteru. Bilo koji izlaz čvora, bilo koja promocija šarda iz replike u primarni, bilo koji zadatak da se negdje stvori neka vrsta šarda - sve to prvo dolazi u TaskBatcher, gdje se obrađuje sekvencijalno i u jednoj niti.
U trenutku povlačenja jednog data centra ispostavilo se da su svi čvorovi podataka u preživjelim podatkovnim centrima smatrali svojom dužnošću obavijestiti gospodara „izgubili smo takve i takve krhotine i takve i takve čvorove podataka“.
U isto vrijeme, preživjeli čvorovi podataka poslali su sve ove informacije trenutnom masteru i pokušali čekati potvrdu da ih je prihvatio. Ovo nisu očekivali, jer je majstor dobijao zadatke brže nego što je imao vremena da odgovori. Čvorovi su ponavljali zahtjeve po isteku vremena, a master u to vrijeme nije ni pokušao odgovoriti na njih, već je bio potpuno zaokupljen zadatkom sortiranja zahtjeva po prioritetu.
U terminalnoj formi, ispostavilo se da su čvorovi podataka spamovali mastera do te mjere da je otišao u puni GC. Nakon toga, uloga mastera se preselila u neki sljedeći čvor, s njim se dogodilo apsolutno isto, i kao rezultat toga, klaster se potpuno raspao.
Napravili smo mjerenja, a prije verzije 6.4.0, gdje je to popravljeno, bilo nam je dovoljno da istovremeno povučemo samo 10 od 360 podatkovnih čvorova kako bismo kompletno postavili klaster.
Izgledalo je otprilike ovako:
Nakon verzije 6.4.0, gdje je ispravljena ova čudna greška, čvorovi podataka su prestali da ubijaju master. Ali to ga nije učinilo pametnijim. Naime: kada izbacimo 2, 3 ili 10 (bilo koji broj osim jednog) podatkovnih čvorova, master prima neku prvu poruku koja kaže da je čvor A otišao, i pokušava reći čvoru B, čvoru C, čvoru D.
A trenutno se to može riješiti samo postavljanjem timeout-a za pokušaje da se nekome nešto kaže, jednako negdje oko 20-30 sekundi, i na taj način kontroliše brzinu povlačenja data centra iz klastera.
U principu, ovo se uklapa u zahtjeve koji su prvobitno postavljeni za krajnji proizvod u okviru projekta, ali sa stanovišta "čiste nauke" ovo je greška. Što su, inače, programeri uspješno popravili u verziji 7.2.
Štoviše, kada se pojavio određeni podatkovni čvor, pokazalo se da je širenje informacija o njegovom izlasku važnije od toga da se cijelom klasteru kaže da ima takav i takav primarni-shard (kako bi promovirao repliku-shard u drugom podatkovnom centru u osnovnoj, a u njoj su mogli pisati informacije).
Stoga, kada je sve već zamrlo, pušteni čvorovi podataka se ne označavaju odmah kao zastarjeli. U skladu s tim, primorani smo čekati da svi pingovi isteku prije nego što se čvorovi podataka oslobode, a tek nakon toga naš klaster počinje govoriti o tome da je tamo, tamo i tamo potrebno nastaviti sa snimanjem informacija. Možete pročitati više o tome .
Kao rezultat toga, operacija povlačenja data centra danas nam traje oko 5 minuta u špicu. Za tako velikog i nespretnog kolosa, ovo je prilično dobar rezultat.
Kao rezultat, došli smo do sljedećeg rješenja:
- Imamo 360 podatkovnih čvorova sa diskovima od 700 gigabajta.
- 60 koordinatora za rutiranje saobraćaja na tim istim podatkovnim čvorovima.
- 40 mastera koje smo ostavili kao svojevrsno nasljeđe iz vremena verzija prije 6.4.0 - da bismo preživjeli povlačenje data centra, psihički smo bili spremni izgubiti nekoliko mašina kako bismo garantovali kvorum mastera čak iu najgori scenario
- Svaki pokušaj kombiniranja uloga na jednom kontejneru s nama počivao je na činjenici da se prije ili kasnije čvor pokvario pod opterećenjem.
- Cijeli klaster koristi heap.size jednaku 31 gigabajtu: svi pokušaji smanjenja veličine doveli su do činjenice da su teški upiti pretraživanja s vodećim zamjenskim znakom ili ubili neke čvorove ili ubili prekidač u samom Elasticsearch-u.
- Osim toga, kako bismo osigurali performanse pretraživanja, pokušali smo zadržati što manji broj objekata u klasteru kako bismo obradili što manje događaja na uskom grlu koje smo dobili u čarobnjaku.
Još jedna stvar o praćenju
Kako bi sve ovo funkcioniralo kako je predviđeno, pratimo sljedeće:
- Svaki podatkovni čvor javlja našem oblaku da postoji, a na njemu se nalaze takvi i takvi dijelovi. Kada negdje nešto ugasimo, klaster nakon 2-3 sekunde javlja da smo u centru A ugasili čvor 2, 3 i 4 - to znači da u drugim podatkovnim centrima ne možemo ugasiti te čvorove sa samo jednim ostatkom.
- Poznavajući ponašanje majstora, vrlo pažljivo gledamo na broj zadataka na čekanju. Jer i jedan obješeni zadatak, ako ne istekne na vrijeme, teoretski, u nekoj vanrednoj situaciji, može postati razlog zašto nam npr. promocija šarda replike u primarnoj ne funkcionira, što će prestati indeksiranje.
- Također, vrlo pažljivo pratimo kašnjenja sakupljača smeća, jer smo već imali velikih poteškoća s tim prilikom optimizacije.
- Odbacivanje niti da unapred shvatite gde je „usko grlo“.
- Pa, standardne metrike kao što su hrpa, RAM i I/O.
Kada nadgledate izgradnju, svakako uzmite u obzir karakteristike Thread Pool-a u Elasticsearch-u. opisuje postavke i zadane vrijednosti za pretragu, indeksiranje, ali potpuno ne govori o thread_pool.management.Ove niti obrađuju, posebno, zahtjeve poput _cat/shards i druge slične koje je zgodno koristiti prilikom pisanja monitoringa. Što je klaster veći, to se više takvih zahtjeva izvršava po jedinici vremena, a spomenuti thread_pool.management ne samo da nije predstavljen u službenoj dokumentaciji, već je i standardno ograničen na 5 niti, što se vrlo brzo koristi, nakon čega nadzor prestaje da radi ispravno.
Ono što želim da kažem u zaključku: uspeli smo! Uspjeli smo našim programerima i programerima dati alat koji može brzo i pouzdano pružiti informacije o tome šta se dešava u produkciji u gotovo svakoj situaciji.
Da, pokazalo se da je to prilično teško, ali ipak smo uspjeli uklopiti našu listu želja u postojeće proizvode, koje, u isto vrijeme, nismo morali sami krpiti i prepisivati.
izvor: www.habr.com