Mnogi se ljudi muče s Elasticsearchom. Ali što se događa kada ga želite koristiti za pohranjivanje zapisa "u posebno velikom volumenu"? I je li također bezbolno doživjeti kvar bilo kojeg od nekoliko podatkovnih centara? Kakvu biste arhitekturu trebali napraviti i na koje ćete se zamke spotaknuti?
Mi u Odnoklassniki odlučili smo koristiti elasticsearch za rješavanje problema upravljanja zapisima, a sada dijelimo svoje iskustvo s Habrom: i o arhitekturi i o zamkama.
Ja sam Pyotr Zaitsev, radim kao sistemski administrator u Odnoklassniki. Prije toga sam također bio admin, radio sa Manticore Search, Sphinx search, Elasticsearch. Možda, ako se pojavi još koja ... pretraga, vjerojatno ću i ja raditi s njom. Također volonterski sudjelujem u nizu projekata otvorenog koda.
Kad sam došao u Odnoklassniki, na razgovoru sam nepromišljeno rekao da bih mogao raditi s Elasticsearchom. Nakon što sam se snašao i izvršio neke jednostavne zadatke, dobio sam veliki zadatak reforme sustava upravljanja zapisima koji je postojao u to vrijeme.
Zahtjevi
Zahtjevi sustava formulirani su na sljedeći način:
- Graylog je trebao biti korišten kao frontend. Budući da je tvrtka već imala iskustva s korištenjem ovog proizvoda, programeri i testeri su to znali, bio im je poznat i zgodan.
- Količina podataka: u prosjeku 50-80 tisuća poruka u sekundi, ali ako se nešto pokvari, onda promet nije ograničen ničim, može biti 2-3 milijuna redaka u sekundi
- Nakon što smo s korisnicima razgovarali o zahtjevima za brzinom obrade upita za pretraživanje, shvatili smo da je tipičan obrazac korištenja takvog sustava sljedeći: ljudi traže zapisnike svoje aplikacije za zadnja dva dana i ne žele čekati više od drugi za rezultat formuliranog upita.
- Administratori su inzistirali da sustav bude lako skalabilan ako je potrebno, bez potrebe da se dublje upuštaju u to kako funkcionira.
- Tako da je jedini zadatak održavanja koji ti sustavi povremeno zahtijevaju promjena nekog hardvera.
- Osim toga, Odnoklassniki ima izvrsnu tehničku tradiciju: svaka usluga koju pokrenemo mora preživjeti kvar podatkovnog centra (iznenadan, neplaniran i apsolutno u bilo kojem trenutku).
Najskuplje nas je koštao zadnji zahtjev u realizaciji ovog projekta, o kojem ću detaljnije govoriti.
Srijeda
Radimo u četiri podatkovna centra, dok se podatkovni čvorovi Elasticsearcha mogu nalaziti samo u tri (zbog niza netehničkih razloga).
Ova četiri podatkovna centra sadrže približno 18 tisuća različitih izvora zapisa - hardver, spremnike, virtualne strojeve.
Važna značajka: klaster počinje u spremnicima ne na fizičkim strojevima, nego na . Kontejneri imaju zajamčeno 2 jezgre, slično 2.0Ghz v4, uz mogućnost recikliranja preostalih jezgri ako miruju.
Drugim riječima:
Topologija
U početku sam vidio opći oblik rješenja kako slijedi:
- 3-4 VIP osobe stoje iza A-zapisa Graylog domene, ovo je adresa na koju se šalju dnevnici.
- svaki VIP je LVS balanser.
- Nakon toga, dnevnici idu u Graylog bateriju, neki od podataka su u GELF formatu, neki u syslog formatu.
- Zatim se sve to u velikim serijama zapisuje skupini Elasticsearch koordinatora.
- A oni zauzvrat šalju zahtjeve za pisanje i čitanje relevantnim podatkovnim čvorovima.
terminologija
Možda svi ne razumiju detaljno terminologiju, pa bih se želio malo zadržati na tome.
Elasticsearch ima nekoliko vrsta čvorova - master, koordinator, podatkovni čvor. Postoje još dvije vrste za različite transformacije dnevnika i komunikaciju između različitih klastera, ali koristili smo samo one navedene.
Majstorski
On pinguje sve čvorove prisutne u klasteru, održava ažurnu mapu klastera i distribuira je između čvorova, obrađuje logiku događaja i izvodi razne vrste održavanja cijelog klastera.
Koordinator
Obavlja samo jedan zadatak: prihvaća zahtjeve za čitanje ili pisanje od klijenata i usmjerava ovaj promet. U slučaju da postoji zahtjev za pisanje, najvjerojatnije će pitati mastera u koji shard relevantnog indeksa ga treba staviti i preusmjerit će zahtjev dalje.
Podatkovni čvor
Pohranjuje podatke, izvršava upite za pretraživanje koji dolaze izvana i izvodi operacije na krhotinama koje se nalaze na njemu.
Siva
Ovo je nešto poput fuzije Kibane s Logstashom u ELK stogu. Graylog kombinira UI i cjevovod za obradu dnevnika. Ispod haube, Graylog pokreće Kafku i Zookeeper, koji omogućuju povezivanje s Graylogom kao klasterom. Graylog može predmemorirati zapise (Kafka) u slučaju da je Elasticsearch nedostupan i ponavljati neuspješne zahtjeve za čitanje i pisanje, grupirati i označavati zapise prema određenim pravilima. Kao i Logstash, Graylog ima funkcionalnost za izmjenu redaka prije nego što ih zapiše u Elasticsearch.
Osim toga, Graylog ima ugrađenu uslugu otkrivanja koja omogućuje, na temelju jednog dostupnog Elasticsearch čvora, dobivanje cijele mape klastera i filtriranje prema određenoj oznaci, što omogućuje usmjeravanje zahtjeva na određene spremnike.
Vizualno to izgleda otprilike ovako:
Ovo je snimka zaslona iz određene instance. Ovdje gradimo histogram na temelju upita za pretraživanje i prikazujemo relevantne retke.
Indeksi
Vraćajući se na arhitekturu sustava, želio bih se detaljnije osvrnuti na to kako smo izgradili model indeksa tako da je sve ispravno radilo.
Na gornjem dijagramu ovo je najniža razina: podatkovni čvorovi Elasticsearch.
Indeks je veliki virtualni entitet sastavljen od Elasticsearch fragmenata. Sam po sebi, svaki od šardova nije ništa više od Lucene indeksa. A svaki Lucene indeks se pak sastoji od jednog ili više segmenata.
Prilikom projektiranja zaključili smo da, kako bismo ispunili zahtjev za brzinom čitanja velike količine podataka, te podatke moramo ravnomjerno "rasprostrijeti" po podatkovnim čvorovima.
To je rezultiralo činjenicom da bi broj shardova po indeksu (s replikama) trebao biti strogo jednak broju podatkovnih čvorova. Prvo, kako bismo osigurali faktor replikacije jednak dva (to jest, možemo izgubiti pola klastera). I, drugo, kako bi se obradili zahtjevi za čitanje i pisanje na barem polovici klastera.
Prvo smo odredili vrijeme skladištenja od 30 dana.
Raspodjela krhotina može se grafički prikazati na sljedeći način:
Cijeli tamno sivi pravokutnik je indeks. Lijevi crveni kvadrat u njemu je primarna krhotina, prva u indeksu. A plavi kvadrat je replika krhotine. Nalaze se u različitim podatkovnim centrima.
Kada dodamo još jedan shard, on ide u treći podatkovni centar. I, na kraju, dobivamo ovu strukturu, koja omogućuje gubitak DC-a bez gubitka dosljednosti podataka:
Rotacija indeksa, tj. stvaranjem novog indeksa i brisanjem najstarijeg, postavili smo ga na 48 sati (prema obrascu korištenja indeksa: zadnjih 48 sati se najčešće pretražuju).
Ovaj interval rotacije indeksa nastao je iz sljedećih razloga:
Kada zahtjev za pretraživanje stigne do određenog podatkovnog čvora, tada je, sa stajališta izvedbe, isplativije kada se postavlja upit za jedan shard, ako je njegova veličina usporediva s veličinom kuka čvora. To vam omogućuje da "vrući" dio indeksa držite na hrpi i brzo mu pristupite. Kada ima puno “vrućih dijelova”, brzina pretraživanja indeksa opada.
Kada čvor počne izvršavati upit za pretraživanje na jednom segmentu, on dodjeljuje broj niti jednak broju hiperthreading jezgri fizičkog stroja. Ako upit za pretraživanje utječe na veliki broj fragmenata, tada broj niti raste proporcionalno. To negativno utječe na brzinu pretraživanja i negativno utječe na indeksiranje novih podataka.
Kako bismo osigurali potrebnu latenciju pretraživanja, odlučili smo koristiti SSD. Kako bi brzo obradili zahtjeve, strojevi koji su ugostili te spremnike morali su imati najmanje 56 jezgri. Brojka 56 odabrana je kao uvjetno dovoljna vrijednost koja određuje broj niti koje će Elasticsearch generirati tijekom rada. U Elasitcsearchu, mnogi parametri skupa niti izravno ovise o broju dostupnih jezgri, što zauzvrat izravno utječe na potreban broj čvorova u klasteru prema principu "manje jezgri - više čvorova".
Kao rezultat toga, otkrili smo da u prosjeku shard teži oko 20 gigabajta, a po indeksu ima 1 shardova. Sukladno tome, ako ih rotiramo jednom svakih 360 sati, tada ih imamo 48. Svaki indeks sadrži podatke za 15 dana.
Sklopovi za upisivanje i čitanje podataka
Razmotrimo kako se podaci bilježe u ovom sustavu.
Recimo da neki zahtjev stigne od Grayloga koordinatoru. Na primjer, želimo indeksirati 2-3 tisuće redaka.
Koordinator, nakon što je primio zahtjev od Grayloga, postavlja pitanje gospodaru: "U zahtjevu za indeksiranje smo posebno naveli indeks, ali u koji shard da ga zapišemo nije navedeno."
Master odgovara: "Zapišite ovu informaciju na shard broj 71", nakon čega se šalje izravno u relevantni podatkovni čvor, gdje se nalazi primarni shard broj 71.
Nakon toga se zapisnik transakcija replicira na repliku-shard, koja se nalazi u drugom podatkovnom centru.
Zahtjev za pretragu stiže od Grayloga do koordinatora. Koordinator ga preusmjerava prema indeksu, dok Elasticsearch distribuira zahtjeve između primarnog-shard-a i replike-shard-a koristeći kružni princip.
180 čvorova reagira neujednačeno, a dok oni reagiraju, koordinator skuplja informacije koje su već “ispljunute” od bržih podatkovnih čvorova. Nakon toga, kada stignu sve informacije ili je zahtjevu isteklo vrijeme čekanja, sve daje izravno klijentu.
Cijeli ovaj sustav u prosjeku obrađuje upite pretraživanja za zadnjih 48 sati u 300-400 ms, isključujući one upite sa zamjenskim znakom na početku.
Cvijeće s Elasticsearchom: postavljanje Jave
Da bi sve funkcioniralo onako kako smo prvotno željeli, proveli smo jako dugo vremena otklanjajući pogreške raznih stvari u klasteru.
Prvi dio otkrivenih problema odnosio se na način na koji je Java unaprijed konfigurirana u Elasticsearchu.
Prvi problem
Vidjeli smo vrlo velik broj izvješća da na razini Lucene, kada se izvode pozadinski poslovi, spajanje Lucene segmenta ne uspijeva s pogreškom. Istodobno, u zapisnicima je bilo jasno da se radi o pogrešci OutOfMemoryError. Na telemetriji smo vidjeli da je kuk slobodan i nije bilo jasno zašto ova operacija ne uspijeva.
Ispostavilo se da se spajanja Lucene indeksa događaju izvan kuka. A spremnici su prilično strogo ograničeni u smislu utrošenih resursa. Samo je hrpa mogla stati u te resurse (vrijednost heap.size bila je približno jednaka RAM-u), a neke operacije izvan hrpe srušile su se s pogreškom dodjele memorije ako iz nekog razloga nisu stale u ~500 MB koliko je ostalo prije ograničenja.
Popravak je bio prilično trivijalan: povećana je količina RAM-a dostupna za spremnik, nakon čega smo zaboravili da uopće imamo takvih problema.
Drugi problem
4-5 dana nakon pokretanja klastera primijetili smo da su podatkovni čvorovi počeli povremeno ispadati iz klastera i ulaziti u njega nakon 10-20 sekundi.
Kad smo to počeli shvaćati, pokazalo se da se ova off-heap memorija u Elasticsearchu ne kontrolira ni na koji način. Kada smo spremniku dali više memorije, mogli smo ispuniti izravne međuspremnike različitim informacijama, a oni su izbrisani tek nakon što je eksplicitni GC pokrenut iz Elasticsearcha.
U nekim je slučajevima ova operacija trajala prilično dugo, a za to vrijeme klaster je uspio označiti ovaj čvor kao već izašao. Ovaj problem je dobro opisan .
Rješenje je bilo sljedeće: ograničili smo sposobnost Jave da za ove operacije koristi većinu memorije izvan hrpe. Ograničili smo ga na 16 gigabajta (-XX:MaxDirectMemorySize=16g), osiguravajući da se eksplicitni GC poziva mnogo češće i obrađuje mnogo brže, čime više ne destabilizira klaster.
Problem tri
Ako mislite da su problemi s “čvorovima koji napuštaju klaster u najneočekivanijem trenutku” gotovi, varate se.
Kada smo konfigurirali rad s indeksima, odabrali smo mmapfs da na svježim krhotinama s velikom segmentacijom. Ovo je bila poprilična greška, jer kada se koristi mmapfs datoteka se mapira u RAM, a onda radimo s mapiranom datotekom. Zbog toga se ispostavlja da kada GC pokuša zaustaviti niti u aplikaciji, idemo do sigurne točke jako dugo, a na putu do nje aplikacija prestaje odgovarati na zahtjeve mastera o tome je li živa . Sukladno tome, master vjeruje da čvor više nije prisutan u klasteru. Nakon toga, nakon 5-10 sekundi, sakupljač smeća radi, čvor oživljava, ponovno ulazi u klaster i počinje inicijalizirati šardove. Sve je izgledalo kao "produkcija kakvu zaslužujemo" i nije bilo prikladno za bilo što ozbiljno.
Da bismo se riješili ovog ponašanja, prvo smo se prebacili na standardne niofs, a zatim, kada smo migrirali s pete verzije Elastica na šestu, isprobali smo hybridfs, gdje se ovaj problem nije reproducirao. Možete pročitati više o vrstama pohrane .
Problem četvrti
Potom se pojavio još jedan vrlo zanimljiv problem koji smo tretirali rekordno vrijeme. Hvatali smo ga 2-3 mjeseca jer je njegov uzorak bio apsolutno nerazumljiv.
Ponekad su naši koordinatori odlazili na Full GC, obično nakon ručka, i nikad se nisu vraćali od tamo. U isto vrijeme, prilikom bilježenja kašnjenja GC-a, izgledalo je ovako: sve ide dobro, dobro, dobro, a onda odjednom sve ide jako loše.
Prvo smo mislili da imamo zlog korisnika koji je pokrenuo nekakav zahtjev koji je izbacio koordinatora iz radnog moda. Dugo smo zapisivali zahtjeve, pokušavajući shvatiti što se događa.
Kao rezultat toga, pokazalo se da u trenutku kada korisnik pokrene veliki zahtjev, a on dođe do određenog Elasticsearch koordinatora, neki čvorovi odgovaraju duže od drugih.
I dok koordinator čeka odgovor od svih čvorova, on akumulira rezultate poslane od čvorova koji su već odgovorili. Za GC to znači da se naši obrasci korištenja gomile mijenjaju vrlo brzo. A GC koji smo koristili nije se mogao nositi s ovim zadatkom.
Jedini popravak koji 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 problem riješen, naši koordinatori su prestali padati.
Ovdje su završili problemi s Javom i počeli problemi s propusnošću.
"Bobice" s Elasticsearchom: propusnost
Problemi s propusnošću znače da naš klaster radi stabilno, ali pri vrhuncu broja indeksiranih dokumenata i tijekom manevara, izvedba je nedovoljna.
Prvi simptom koji se susreće: tijekom nekih "eksplozija" u proizvodnji, kada se iznenada generira vrlo velik broj dnevnika, pogreška indeksiranja es_rejected_execution počinje često treperiti u Graylogu.
To je bilo zbog činjenice da thread_pool.write.queue na jednom podatkovnom čvoru, sve do trenutka kada Elasticsearch bude u mogućnosti obraditi zahtjev za indeksiranje i učitati informacije na shard na disku, prema zadanim postavkama može predmemorirati samo 200 zahtjeva. I u Vrlo malo se govori o ovom parametru. Naznačeni su samo najveći broj niti i zadana veličina.
Naravno, krenuli smo izvrtati ovu vrijednost i saznali sljedeće: konkretno, u našoj postavci, do 300 zahtjeva je prilično dobro predmemorirano, a veća vrijednost je prepuna činjenice da ponovno letimo u Full GC.
Osim toga, budući da se radi o serijama poruka koje stižu unutar jednog zahtjeva, bilo je potrebno podesiti Graylog tako da ne piše često i u malim serijama, već u velikim serijama ili jednom svake 3 sekunde ako serija još nije potpuna. U ovom slučaju ispada da informacije koje upisujemo u Elasticsearch postaju dostupne ne za dvije sekunde, već za pet (što nam sasvim odgovara), ali broj ponavljanja koji je potrebno napraviti da bismo progurali veliki hrpa informacija je smanjena.
Ovo je posebno važno u onim trenucima kada se negdje nešto srušilo i bijesno izvještava o tome, kako ne bi dobili potpuno spamirani Elastic, a nakon nekog vremena - Graylog čvorove koji su neoperativni zbog začepljenih međuspremnika.
Osim toga, kada smo imali te iste eksplozije u proizvodnji, primili smo pritužbe programera i testera: u trenutku kada su stvarno trebali te zapisnike, davali su ih vrlo sporo.
Počeli su shvaćati. S jedne strane, bilo je jasno da su i upiti za pretraživanje i upiti za indeksiranje obrađeni, u biti, na istim fizičkim strojevima, te će na ovaj ili onaj način doći do određenih smanjenja.
No to se može djelomično zaobići zbog činjenice da se u šestoj verziji Elasticsearcha pojavio algoritam koji vam omogućuje distribuciju upita između relevantnih podatkovnih čvorova ne prema načelu nasumičnog kruga (spremnik koji vrši indeksiranje i drži primarni- shard može biti vrlo zauzet, neće biti načina za brzi odgovor), ali proslijediti ovaj zahtjev manje opterećenom spremniku s replikom-shardom, koji će odgovoriti mnogo brže. Drugim riječima, došli smo do use_adaptive_replica_selection: true.
Slika čitanja počinje izgledati ovako:
Prijelaz na ovaj algoritam omogućio je značajno poboljšanje vremena upita u onim trenucima kada smo imali veliki protok zapisa za pisanje.
Konačno, glavni problem bilo je bezbolno uklanjanje podatkovnog centra.
Što smo htjeli od klastera odmah nakon gubitka veze s jednim DC-om:
- Ako imamo trenutačni glavni u pokvarenom podatkovnom centru, on će biti ponovno odabran i premješten kao uloga u drugi čvor u drugom DC-u.
- Master će brzo ukloniti sve nedostupne čvorove iz klastera.
- Na temelju preostalih shvatit će: u izgubljenom podatkovnom centru imali smo takve i takve primarne shardove, brzo će promovirati komplementarne replike shardova u preostalim podatkovnim centrima, a mi ćemo nastaviti s indeksiranjem podataka.
- Kao rezultat toga, propusnost pisanja i čitanja klastera postupno će se smanjivati, ali općenito će sve raditi, iako sporo, ali stabilno.
Kako se ispostavilo, htjeli smo nešto ovako:
I dobili smo sljedeće:
Kako se to dogodilo?
Kad je podatkovni centar pao, naš je gospodar postao usko grlo.
Zašto?
Činjenica je da master ima TaskBatcher, koji je odgovoran za distribuciju određenih zadataka i događaja u klasteru. Bilo koji izlaz iz čvora, bilo kakva promocija sharda iz replike u primarni, bilo koji zadatak da se negdje stvori shard - sve to prvo ide u TaskBatcher, gdje se obrađuje sekvencijalno i u jednoj niti.
U trenutku povlačenja jednog podatkovnog centra pokazalo se da su svi podatkovni čvorovi u preživjelim podatkovnim centrima smatrali svojom dužnošću obavijestiti gospodara “izgubili smo te i te šardove i te i te podatkovne čvorove”.
U isto vrijeme, preživjeli podatkovni čvorovi poslali su sve te informacije trenutnom gospodaru i pokušali pričekati potvrdu da ih je prihvatio. Nisu to čekali, jer je majstor primao zadatke brže nego što je mogao odgovoriti. Čvorovima je isteklo vrijeme za ponavljanje zahtjeva, a master u to vrijeme nije ni pokušao odgovoriti na njih, već je bio potpuno zaokupljen zadatkom sortiranja zahtjeva po prioritetu.
U terminalnom obliku, ispostavilo se da su podatkovni čvorovi spamali master do te mjere da je prešao na puni GC. Nakon toga, naša glavna uloga se preselila na neki sljedeći čvor, apsolutno ista stvar se dogodila s njom, i kao rezultat toga klaster se potpuno urušio.
Vršili smo mjerenja, a prije verzije 6.4.0, gdje je to bilo popravljeno, bilo nam je dovoljno simultano ispisati samo 10 podatkovnih čvorova od 360 kako bismo potpuno ugasili klaster.
Izgledalo je otprilike ovako:
Nakon verzije 6.4.0, u kojoj je ovaj užasni bug ispravljen, podatkovni čvorovi prestali su ubijati master. Ali to ga nije učinilo "pametnijim". Naime: kada ispišemo 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 o tome obavijestiti čvor B, čvor C, čvor D.
A trenutno se to može riješiti samo postavljanjem vremenskog ograničenja za pokušaje da se nekome nešto kaže, jednako otprilike 20-30 sekundi, i na taj način kontrolirati brzinu kretanja podatkovnog centra iz klastera.
U principu, to se uklapa u zahtjeve koji su inicijalno postavljeni na finalni proizvod kao dio projekta, ali sa stajališta “čiste znanosti” ovo je greška. Što su, usput rečeno, programeri uspješno popravili u verziji 7.2.
Štoviše, kada je određeni podatkovni čvor nestao, pokazalo se da je širenje informacija o njegovom izlasku bilo važnije nego reći cijelom klasteru da na njemu postoje takvi i takvi primarni-shardovi (kako bi se replika-shard promovirala u drugim podacima središte u primarnoj, a na njima bi se mogle pisati informacije).
Stoga, kada je sve već zamrlo, oslobođeni podatkovni čvorovi nisu odmah označeni kao ustajali. Sukladno tome, prisiljeni smo čekati dok svi pingovi ne isteknu do oslobođenih podatkovnih čvorova, a tek nakon toga naš nam klaster počinje govoriti da tamo, tamo i tamo trebamo nastaviti bilježiti informacije. Možete pročitati više o ovome .
Kao rezultat toga, operacija povlačenja podatkovnog centra danas traje oko 5 minuta tijekom špice. Za ovako velikog i nespretnog kolosa ovo je prilično dobar rezultat.
Kao rezultat toga, došli smo do sljedeće odluke:
- Imamo 360 podatkovnih čvorova s diskovima od 700 gigabajta.
- 60 koordinatora za usmjeravanje prometa kroz te iste podatkovne čvorove.
- 40 mastera koje smo ostavili kao svojevrsno nasljeđe od verzija prije 6.4.0 - da bismo preživjeli povlačenje podatkovnog centra, bili smo psihički spremni izgubiti nekoliko strojeva kako bismo imali zajamčen kvorum mastera čak i u najgori mogući scenarij
- Svaki pokušaj kombiniranja uloga na jednom spremniku naišao je na činjenicu da bi se čvor prije ili kasnije pokvario pod opterećenjem.
- Cijeli klaster koristi heap.size od 31 gigabajta: svi pokušaji smanjenja veličine rezultirali su ili ubijanjem nekih čvorova na teškim upitima pretraživanja s vodećim zamjenskim znakom ili dobivanjem prekidača strujnog kruga u samom Elasticsearchu.
- Osim toga, kako bismo osigurali performanse pretraživanja, nastojali smo zadržati što manji broj objekata u klasteru, kako bismo obradili što manje događaja u uskom grlu koje smo dobili u masteru.
Na kraju o praćenju
Kako bismo osigurali da sve ovo radi kako treba, pratimo sljedeće:
- Svaki podatkovni čvor javlja našem oblaku da postoji, a na njemu postoje ovakvi i onakvi šardovi. Kad negdje nešto ugasimo, klaster nakon 2-3 sekunde javlja da smo u centru A ugasili čvorove 2, 3 i 4 - to znači da u drugim podatkovnim centrima ni pod kojim uvjetima ne možemo ugasiti one čvorove na kojima postoji samo jedan shard lijevo.
- Poznavajući prirodu gospodarevog ponašanja, vrlo pažljivo promatramo broj zadataka na čekanju. Jer čak i jedan zaglavljeni zadatak, ako ne istekne na vrijeme, teoretski u nekoj hitnoj situaciji može postati razlog zašto, primjerice, promocija replike sharda u primarnoj ne radi, zbog čega će indeksiranje prestati raditi.
- Također pažljivo promatramo kašnjenja skupljača smeća, jer smo već imali velikih poteškoća s tim tijekom optimizacije.
- Odbija po niti kako bi se unaprijed razumjelo gdje je usko grlo.
- Pa, standardne metrike kao što su heap, RAM i I/O.
Prilikom izgradnje nadzora morate uzeti u obzir značajke skupa niti u Elasticsearchu. opisuje opcije konfiguracije i zadane vrijednosti za pretraživanje i indeksiranje, ali potpuno šuti o thread_pool.management. Ove niti obrađuju, posebno, upite kao što su _cat/shards i drugi slični, koji su prikladni za korištenje pri pisanju nadzora. Što je veći klaster, to se više takvih zahtjeva izvršava u jedinici vremena, a spomenuti thread_pool.management ne samo da nije predstavljen u službenoj dokumentaciji, već je standardno ograničen na 5 niti, što se vrlo brzo uklanja, nakon koji nadzor prestaje ispravno raditi.
Ono što želim reći na kraju: uspjeli smo! Uspjeli smo dati našim programerima i programerima alat koji, u gotovo svakoj situaciji, može brzo i pouzdano pružiti informacije o tome što se događa u proizvodnji.
Da, ispalo je dosta komplicirano, ali, ipak, uspjeli smo svoje želje uklopiti u postojeće proizvode, koje nismo morali sami krpati i prepisivati.
Izvor: www.habr.com