Assai genti luttanu cù Elasticsearch. Ma chì succede quandu vulete usà per almacenà logs "in un voluminu particularmente grande"? È hè ancu indolore per sperienze u fallimentu di qualsiasi di parechji centri di dati? Qualessu tipu d'architettura duvete fà, è chì trappule vi inciamparà?
Avemu à Odnoklassniki hà decisu d'utilizà elasticsearch per risolve u prublema di gestione di log, è avà spartemu a nostra sperienza cù Habr: sia nantu à l'architettura sia nantu à i pisculi.
Sò Pyotr Zaitsev, travagliu cum'è amministratore di sistema in Odnoklassniki. Prima di quessa, era ancu un amministratore, hà travagliatu cù Manticore Search, Sphinx search, Elasticsearch. Forse, s'ellu appare un'altra ... ricerca, prubabilmente travaglià ancu cun ella. Aghju participatu ancu in una quantità di prughjetti open source nantu à una basa vuluntaria.
Quandu sò ghjuntu à Odnoklassniki, aghju dettu imprudente à l'entrevista chì puderia travaglià cù Elasticsearch. Dopu ch'e aghju avutu u colpu di questu è cumpiitu certi travaglii simplici, mi hè statu datu u grande compitu di riformazione di u sistema di gestione di log chì esisteva à quellu tempu.
esigenze
I requisiti di u sistema sò stati formulati cum'è seguente:
- Graylog hà da esse usatu cum'è u frontend. Perchè a cumpagnia hà digià avutu una sperienza in usu di stu pruduttu, i programatori è i testatori sapianu, era familiar è cunvenutu per elli.
- Volumi di dati: in media 50-80 mila missaghji per seconda, ma se qualcosa si rompe, u trafficu ùn hè micca limitatu da nunda, pò esse 2-3 milioni di linee per seconda.
- Dopu avè discututu cù i clienti i requisiti per a rapidità di processà e dumande di ricerca, avemu capitu chì u mudellu tipicu di utilizà un tali sistema hè questu: e persone cercanu logs di a so applicazione per l'ultimi dui ghjorni è ùn volenu aspittà più di un seconda per u risultatu di una dumanda formulata.
- L'amministratori insistenu chì u sistema sia facilmente scalabile se ne necessariu, senza esigenza di sfondà in u funziunamentu.
- Cusì chì l'unicu compitu di mantenimentu chì questi sistemi necessitanu periodicamente hè di cambià qualchì hardware.
- Inoltre, Odnoklassniki hà una tradizione tecnica eccellente: ogni serviziu chì lanciamu deve sopravvive à un fallimentu di u centru di dati (suttatu, imprevisu è assolutamente in ogni mumentu).
L'ultima esigenza in l'implementazione di stu prughjettu ci costa u più, chì vi parleraghju in più detail.
U mercuri
Travagliemu in quattru centri di dati, mentre chì i nodi di dati Elasticsearch ponu esse situatu solu in trè (per una quantità di ragioni non tecniche).
Questi quattru centri di dati cuntenenu circa 18 mila fonti di log differenti - hardware, cuntenituri, macchine virtuali.
Funzione impurtante: u cluster principia in cuntenituri micca nantu à e macchine fisiche, ma nantu . I cuntenituri sò garantiti 2 core, simili à 2.0Ghz v4, cù a pussibilità di riciclà i nuclei rimanenti si sò inattivi.
In altre parolle:
Topulugia
Aghju vistu inizialmente a forma generale di a suluzione cum'è seguente:
- 3-4 VIP sò daretu à l'A-record di u duminiu Graylog, questu hè l'indirizzu à quale sò mandati i logs.
- ogni VIP hè un balancer LVS.
- Dopu à questu, i logs vanu à a bateria Graylog, alcuni di i dati sò in formatu GELF, alcuni in formatu syslog.
- Allora tuttu questu hè scrittu in grande lotte à una bateria di coordinatori Elasticsearch.
- È elli, à u turnu, mandanu richieste di scrittura è lettura à i nodi di dati pertinenti.
Terminologia
Forsi micca tutti capiscenu a terminologia in dettagliu, cusì mi piacerebbe aspittà un pocu.
Elasticsearch hà parechji tippi di nodi - master, coordinator, data node. Ci hè dui altri tippi di trasfurmazioni di log è cumunicazioni trà e diverse clusters, ma avemu usatu solu quelli listati.
Master
Piglia tutti i nodi prisenti in u cluster, mantene una mappa di cluster aghjurnata è u distribuisce trà i nodi, processa a logica di l'eventi, è eseguisce diversi tipi di pulizie in u cluster.
Coordinator
Esegue una sola operazione: accetta richieste di lettura o scrittura da i clienti è indirizza stu trafficu. In casu chì ci hè una dumanda di scrittura, assai prubabilmente, dumandarà à u maestru quale frammentu di l'indici pertinente deve mette, è redirigerà a dumanda in più.
Node di dati
Immagazzina dati, esegue e dumande di ricerca chì arrivanu da l'esternu è eseguisce operazioni nantu à i frammenti situati sopra.
greylog
Questu hè qualcosa cum'è una fusione di Kibana cù Logstash in una pila ELK. Graylog combina una UI è una pipeline di processazione di log. Sottu u cappucciu, Graylog gestisce Kafka è Zookeeper, chì furnisce a cunnessione à Graylog cum'è un cluster. Graylog pò cache logs (Kafka) in casu Elasticsearch ùn hè micca dispunibile è ripetite richieste di lettura è scrittura senza successu, raggruppate è marcate logs secondu e regule specificate. Cum'è Logstash, Graylog hà funziunalità per mudificà e fila prima di scrive à Elasticsearch.
Inoltre, Graylog hà una scuperta di serviziu integrata chì permette, basatu annantu à un nodu di Elasticsearch dispunibule, per ottene a mappa di u cluster sanu è filtrà per un tag specificu, chì permette di dirighje e dumande à cuntenituri specifichi.
Visualmente pare qualcosa cusì:
Questa hè una screenshot da un esempiu specificu. Quì custruemu un histogramma basatu annantu à a ricerca di ricerca è affissà e file pertinenti.
Indici
Riturnendu à l'architettura di u sistema, vogliu aspittà in più dettagliu nantu à cumu avemu custruitu u mudellu d'indici per chì tuttu hà travagliatu bè.
In u diagramma sopra, questu hè u livellu più bassu: Nodi di dati Elasticsearch.
Un indice hè una grande entità virtuale composta da shards Elasticsearch. In sè stessu, ognunu di i frammenti ùn hè nunda di più chè un indice Lucene. Et chaque indice Lucene, à son tour, consiste en un ou plusieurs segments.
Quandu u cuncepimentu, avemu pensatu chì per risponde à u requisitu di a velocità di lettura nantu à una grande quantità di dati, avemu bisognu di "sparghje" sta dati in modu uniforme in i nodi di dati.
Questu hà risultatu in u fattu chì u numeru di shards per indice (cù repliche) deve esse strettamente uguali à u numeru di nodi di dati. Prima, per assicurà un fattore di replicazione uguale à dui (vale à dì, pudemu perde a mità di u cluster). È, in segundu, per processà e dumande di lettura è scrittura nantu à almenu a mità di u cluster.
Prima avemu determinatu u tempu di almacenamiento cum'è 30 ghjorni.
A distribuzione di shards pò esse rapprisintata gràficamente cum'è seguente:
Tuttu u rettangulu grisgiu scuru hè un indice. U quadru rossu manca in questu hè u frammentu primariu, u primu in l'indici. È u quadru blu hè un frammentu di replica. Sò situati in diversi centri di dati.
Quandu aghjustemu un altru shard, và à u terzu centru di dati. È, à a fine, avemu sta struttura, chì permette di perde DC senza perde a cunsistenza di dati:
A rotazione di l'indici, i.e. criendu un novu indice è sguassate u più anticu, avemu fattu uguali à 48 ore (sicondu u mudellu di usu di l'indici: l'ultimi 48 ore sò cercati più spessu).
Stu intervallu di rotazione di l'indici hè dovutu à i seguenti motivi:
Quandu una dumanda di ricerca ghjunghje à un node di dati specificu, allora, da un puntu di vista di u rendiment, hè più prufittuosa quandu un shard hè interrugatu, se a so dimensione hè paragunabile à a dimensione di l'anca di u node. Questu permette di mantene a parte "calda" di l'indici in un munzeddu è accede rapidamente. Quandu ci sò assai "parti calde", a vitezza di ricerca di l'indici si degrada.
Quandu un node cumencia à eseguisce una ricerca di ricerca nantu à un shard, attribuisce un numeru di fili uguali à u numeru di core hyperthreading di a macchina fisica. Se una ricerca di ricerca affetta un gran numaru di shards, allora u numeru di filamenti cresce proporzionalmente. Questu hà un impattu negativu nantu à a veloce di ricerca è affetta negativamente l'indexazione di novi dati.
Per furnisce a latenza di ricerca necessaria, avemu decisu di utilizà un SSD. Per processà rapidamente e richieste, i machini chì allughjavanu questi cuntenituri avianu avutu almenu 56 core. A figura di 56 hè stata scelta cum'è un valore abbastanza cundizionale chì determina u numeru di fili chì Elasticsearch generarà durante l'operazione. In Elasitcsearch, parechji paràmetri di pool di thread dipendenu direttamente da u nùmeru di nuclei dispunibili, chì à u turnu affettanu direttamente u numeru necessariu di nodi in u cluster secondu u principiu "menu core - più nodi".
In u risultatu, avemu truvatu chì in media un shard pesa circa 20 gigabytes, è ci sò 1 shards per indice. In cunsiquenza, se li rotemu una volta ogni 360 ore, allora avemu 48 di elli. Ogni indice cuntene dati per 15 ghjorni.
Circuiti di scrittura è lettura di dati
Scupritemu cumu i dati sò registrati in stu sistema.
Diciamu chì una certa dumanda arriva da Graylog à u coordinatore. Per esempiu, vulemu indicà 2-3 mila fila.
U coordinatore, dopu avè ricevutu una dumanda da Graylog, dumanda à u maestru: "In a dumanda di indexazione, avemu specificatu specificamente un indice, ma in quale shard per scrive ùn era micca specificatu".
U maestru risponde: "Scrivi sta informazione à u numeru shard 71", dopu chì hè mandatu direttamente à u nodu di dati pertinenti, induve si trova u numeru primariu-shard 71.
Dopu chì u logu di transazzione hè replicatu à una replica-shard, chì si trova in un altru centru di dati.
Una dumanda di ricerca arriva da Graylog à u coordinatore. U coordinatore redirige secondu l'indici, mentri Elasticsearch distribuisce e dumande trà u primary-shard è replica-shard utilizendu u principiu round-robin.
I nodi 180 rispundenu di manera irregulare, è mentre rispundenu, u coordinatore accumula infurmazione chì hè digià stata "sputata" da i nodi di dati più veloci. Dopu questu, quandu o tutte l'infurmazioni sò ghjunti, o a dumanda hè ghjunta à un timeout, dà tuttu direttamente à u cliente.
Stu sistema tutale in media processa e dumande di ricerca per l'ultime 48 ore in 300-400 ms, escludendu e dumande cù un wildcard principali.
Fiori cù Elasticsearch: Configurazione Java
Per fà tuttu u funziunamentu di a manera chì vulemu inizialmente, avemu passatu assai tempu à debugging una larga varietà di cose in u cluster.
A prima parte di i prublemi scuperti era ligata à a manera chì Java hè pre-configuratu per automaticamente in Elasticsearch.
Prublemu unu
Avemu vistu un gran numaru di rapporti chì à u nivellu di Lucene, quandu i travaglii di fondo sò in esecuzione, u segmentu di Lucene fusiona falla cù un errore. À u listessu tempu, era chjaru in i logs chì questu era un errore OutOfMemoryError. Avemu vistu da a telemetria chì l'anca era libera, è ùn era micca chjaru perchè sta operazione era falluta.
Hè risultatu chì l'indici di Lucene si fusioni fora di l'anca. È i cuntenituri sò abbastanza strettamente limitati in termini di risorse cunsumate. Solu l'heap puderia inserisce in queste risorse (u valore di heap.size era apprussimatamente uguale à a RAM), è alcune operazioni off-heap s'hè lampatu cù un errore d'allocazione di memoria si per una certa ragione ùn sò micca inseriti in i ~ 500MB chì restanu prima di u limitu.
A correzione era abbastanza triviale: a quantità di RAM dispunibule per u cuntinuu hè stata aumentata, dopu chì avemu scurdatu chì avemu ancu avutu tali prublemi.
Prublemu dui
4-5 ghjorni dopu à u lanciamentu di u cluster, avemu nutatu chì i nodi di dati cuminciaru à cascà periodicamente fora di u cluster è entre dopu à 10-20 seconde.
Quandu avemu cuminciatu à calculà, hè risultatu chì sta memoria off-heap in Elasticsearch ùn hè micca cuntrullata in ogni modu. Quandu avemu datu più memoria à u cuntinuu, pudemu riempie i buffer pools diretti cù diverse informazioni, è hè stata sbulicata solu dopu chì u GC esplicitu hè stata lanciata da Elasticsearch.
In certi casi, sta operazione pigliò un bellu pezzu, è in questu tempu u cluster hà sappiutu per marcà stu node cum'è digià surtitu. Stu prublema hè ben descrittu .
A suluzione era a siguenti: avemu limitatu l'abilità di Java per utilizà a maiò parte di a memoria fora di u munzeddu per queste operazioni. L'avemu limitatu à 16 gigabytes (-XX: MaxDirectMemorySize = 16g), assicurendu chì u GC esplicitu hè statu chjamatu assai più spessu è processatu assai più veloce, cusì ùn destabilizeghja più u cluster.
Prublemu trè
Se pensate chì i prublemi cù "nodi chì abbandunonu u cluster à u mumentu più inesperu" sò finiti, vi sbagliate.
Quandu avemu cunfiguratu u travagliu cù indici, avemu sceltu mmapfs à nantu à frammenti freschi cù una grande segmentazione. Questu era abbastanza un sbagliu, perchè quandu si usa mmapfs, u schedariu hè mappatu in RAM, è dopu avemu travagliatu cù u schedariu mappatu. Per via di questu, si trova chì quandu u GC prova di piantà i fili in l'applicazione, andemu à u puntu di salvezza per un tempu assai longu, è nantu à a strada per questu, l'applicazione cessà di risponde à e dumande di u maestru nantu à s'ellu hè vivu. . Per quessa, u maestru crede chì u node ùn hè più presente in u cluster. Dopu à questu, dopu à 5-10 seconde, u cullettivu di basura travaglia, u node vene à a vita, entra in u cluster di novu è principia à inizializà shards. Tuttu si sentia assai cum'è "a pruduzzione chì meritavamu" è ùn era micca adattatu per qualcosa seriu.
Per sguassà stu cumpurtamentu, avemu prima cambiatu à niofs standard, è dopu, quandu avemu migratu da a quinta versione di Elastic à a sesta, avemu pruvatu hybridfs, induve stu prublema ùn hè micca ripruduciutu. Pudete leghje più nantu à i tipi di almacenamiento .
Prublemu quattru
Dopu ci era un altru prublema assai interessante chì avemu trattatu per un tempu record. L'avemu pigliatu per 2-3 mesi perchè u so mudellu era assolutamente incomprensibile.
Calchì volta i nostri coordinatori andavanu à Full GC, di solitu qualchì tempu dopu à pranzu, è ùn sò mai tornati da quì. À u listessu tempu, quandu u ritardu di u GC, pareva cusì: tuttu va bè, bè, bè, è poi di colpu tuttu va assai male.
À u principiu, avemu pensatu chì avemu avutu un utilizatore male chì lanciava un tipu di dumanda chì hà cacciatu u coordinatore fora di u modu di travagliu. Avemu registratu e dumande per un tempu assai longu, pruvendu à capisce ciò chì succede.
Per via di u risultatu, hè risultatu chì in u mumentu chì un utilizatore lancia una dumanda enormosa, è ghjunghje à un coordinatore specificu di Elasticsearch, certi nodi rispundenu più longu ca l'altri.
È mentre u coordinatore aspetta una risposta da tutti i nodi, accumula i risultati mandati da i nodi chì anu digià rispostu. Per GC, questu significa chì i nostri mudelli d'utilizazione di u munzeddu cambianu assai rapidamente. È u GC chì avemu usatu ùn pudia micca affruntà stu compitu.
L'unica correzione chì avemu trovu per cambià u cumpurtamentu di u cluster in questa situazione hè a migrazione à JDK13 è l'usu di u cullettivu di basura Shenandoah. Questu hà risoltu u prublema, i nostri coordinatori anu cessatu di cascà.
Hè quì chì i prublemi cù Java finiscinu è i prublemi di larghezza di banda cuminciaru.
"Bacche" cù Elasticsearch: throughput
I prublemi cù u throughput significanu chì u nostru cluster travaglia in modu stabile, ma à i picchi in u nùmeru di documenti indexati è durante e manuvre, u rendiment hè insufficiente.
U primu sintumu scontru: durante certi "esplosioni" in a pruduzzione, quandu un gran numaru di logs sò generati di colpu, l'errore d'indexazione es_rejected_execution cumencia à lampassi friquenti in Graylog.
Questu hè duvuta à u fattu chì thread_pool.write.queue nantu à un node di dati, finu à u mumentu Elasticsearch hè capaci di processà a dumanda di indexazione è carica l'infurmazioni à u shard in u discu, hè capaci di cache solu 200 richieste per automaticamente. È in Pocu hè dettu di stu paràmetru. Solu u numeru massimu di fili è a dimensione predeterminata sò indicati.
Di sicuru, andemu à torce stu valore è scupertu i seguenti: specificamente, in a nostra cunfigurazione, finu à 300 richieste sò in cache abbastanza bè, è un valore più altu hè pienu di u fattu chì vulemu di novu in Full GC.
Inoltre, postu chì questi sò batchs di messagi chì ghjunghjenu in una sola dumanda, era necessariu tweak Graylog in modu chì scrive micca spessu è in picculi lochi, ma in lotte enormi o una volta ogni 3 seconde se u batch ùn hè ancu cumpletu. In questu casu, risulta chì l'infurmazioni chì scrivimu in Elasticsearch diventanu dispunibuli micca in dui sicondi, ma in cinque (chì ci cunvene abbastanza bè), ma u numeru di retray chì deve esse fattu per spinghja un grande. a pila di informazioni hè ridutta.
Questu hè sopratuttu impurtante in quelli mumenti quandu qualcosa hà crashed in qualchì locu è furiously reports about it, per ùn avè micca un Elastic spammed cumplettamente, è dopu qualchì tempu - i nodi Graylog chì sò inoperabili per via di buffers intasati.
Inoltre, quandu avemu avutu sti stessi splusioni in a pruduzzione, avemu ricivutu lagnanza da i programatori è i testatori: in u mumentu quandu avianu veramente bisognu di sti logs, sò stati datu assai lentamente.
Anu cuminciatu à capisce. Per una banda, era chjaru chì e dumande di ricerca è e dumande di indexazione sò state trattate, essenzialmente, nantu à e stesse macchine fisiche, è in un modu o in l'altru ci saranu certi drawdowns.
Ma questu puderia esse parzialmente aggiratu per u fattu chì in a sesta versione di Elasticsearch, apparsu un algoritmu chì vi permette di distribuisce e dumande trà i nodi di dati pertinenti micca secondu u principiu di round-robin aleatoriu (u cuntinuu chì faci l'indexazione è tene u primariu). -shard pò esse assai occupatu, ùn ci sarà manera di risponde rapidamente), ma per rinvià sta dumanda à un containeru menu carricu cù una replica-shard, chì risponde assai più veloce. In altre parolle, avemu ghjuntu à use_adaptive_replica_selection: true.
A stampa di lettura cumencia à vede cusì:
A transizione à questu algoritmu hà permessu di migliurà significativamente u tempu di dumanda in quelli mumenti quandu avemu avutu un grande flussu di logs per scrive.
Infine, u prublema principali era a rimuzione indolore di u centru di dati.
Ciò chì vulemu da u cluster immediatamente dopu a perdita di cunnessione cù un DC:
- Se avemu un maestru attuale in u centru di dati fallutu, allora serà re-selettu è spustatu cum'è un rolu à un altru node in un altru DC.
- U maestru sguassà rapidamente tutti i nodi inaccessibili da u cluster.
- Basatu nantu à i restanti, hà da capisce: in u centru di dati persu avemu avutu tali è tali frammenti primari, hà da prumove rapidamente shards di replica cumplementarii in i centri di dati restanti, è avemu da cuntinuà à indexà i dati.
- In u risultatu di questu, u flussu di scrittura è di lettura di u cluster si degraderà gradualmente, ma in generale tuttu u travagliu, anche lentamente, ma stabile.
Cum'è hè risultatu, vulemu qualcosa cum'è questu:
È avemu avutu i seguenti:
Cumu hè accadutu questu?
Quandu u centru di dati hè cascatu, u nostru maestru hè diventatu u collu di buttiglia.
Perchè
U fattu hè chì u maestru hà un TaskBatcher, chì hè rispunsevule per a distribuzione di certi travaglii è avvenimenti in u cluster. Qualchese uscita di node, ogni prumuzione di un frammentu da a replica à u primariu, ogni compitu per creà un frammentu in un locu - tuttu questu va prima à TaskBatcher, induve hè processatu in sequenza è in un filu.
À l'ora di a retirazzione di un centru di dati, hè risultatu chì tutti i nodi di dati in i centri di dati sopravviventi anu cunsideratu u so duveru di informà u maestru "avemu persu tali è tali shards è tali è tali nodi di dati".
À u listessu tempu, i nodi di dati sopravviventi anu mandatu tutta questa informazione à u maestru attuale è pruvatu d'aspittà per a cunferma chì l'accetta. Ùn aspittàvanu micca per questu, postu chì u maestru hà ricivutu i travaglii più veloce ch'ellu puderia risponde. I nodi anu timeout ripetiri e dumande, è u maestru in questu tempu ùn hà mancu pruvatu à risponde à elli, ma era cumplettamente assorbutu in u compitu di sorte e dumande per priorità.
In a forma di terminale, hè risultatu chì i nodi di dati spammed u maestru à u puntu chì andò in GC pienu. Dopu à quessa, u nostru rolu di maestru si trasfirìu à qualchi node prossimu, assulutamente listessa cosa hè accaduta à ellu, è in u risultatu, u cluster hà colapsatu cumplettamente.
Avemu pigliatu e misurazioni, è prima di a versione 6.4.0, induve questu hè stata fissata, ci era abbastanza per noi di pruduce simultaneamente solu 10 nodi di dati da 360 per chjude cumpletamente u cluster.
Paria qualcosa cusì:
Dopu à a versione 6.4.0, induve stu terribili bug hè stata riparata, i nodi di dati cessanu di tumbà u maestru. Ma questu ùn l'hà micca fattu "più intelligente". Vale à dì: quandu avemu uscita 2, 3 o 10 (qualsiasi numeru altru ch'è unu) nodi di dati, u maestru riceve un primu messagiu chì dice chì u node A hè partutu, è prova à dì à u nodu B, u nodu C di questu, u nodu D.
È in u mumentu, questu pò esse trattatu solu per stabilisce un timeout per i tentativi di dì à qualchissia di qualcosa, uguali à circa 20-30 seconde, è cusì cuntrullà a velocità di u centru di dati chì si move fora di u cluster.
In principiu, questu si mette in i requisiti chì sò stati inizialmente presentati à u pruduttu finali cum'è parte di u prugettu, ma da u puntu di vista di "scienza pura" hè un bug. Chì, per via, hè stata corretta cù successu da i sviluppatori in a versione 7.2.
Inoltre, quandu un certu nodu di dati si n'andò, hè risultatu chì a diffusione di l'infurmazioni nantu à a so uscita era più impurtante ch'è dì à u cluster sanu chì ci era tali è tali frammenti primari nantu à ellu (per prumove una replica-shard in altre dati). centru in u primariu, è in infurmazione puderia esse scrittu annantu à elli).
Dunque, quandu tuttu hè digià mortu, i nodi di dati liberati ùn sò micca immediatamente marcati cum'è stale. In cunsiquenza, simu furzati à aspittà finu à chì tutti i pings anu timed out à i nodi di dati liberati, è solu dopu chì u nostru cluster cumencia à dì chì ci, quì, è quì avemu bisognu di cuntinuà à arregistrà l'infurmazioni. Pudete leghje più nantu à questu .
In u risultatu, l'operazione di ritirata un centru di dati oghje ci porta circa 5 minuti durante l'ora di punta. Per un colossu cusì grande è goffo, questu hè un risultatu bellu bellu.
In u risultatu, avemu ghjuntu à a seguente decisione:
- Avemu 360 nodi di dati cù dischi 700 gigabyte.
- 60 coordinatori per indirizzà u trafficu attraversu sti stessi nodi di dati.
- 40 maestri chì avemu lasciatu cum'è una sorta di eredità da e versioni prima di 6.4.0 - per sopravvive à a retirazzione di u centru di dati, avemu statu preparatu mentalmente per perde parechje macchine per esse garantitu per avè un quorum di maestri ancu in u peghju scenariu
- Ogni tentativu di cumminà roli nantu à un containeru hè statu scuntratu cù u fattu chì, prima o dopu, u node romperà sottu a carica.
- Tuttu u cluster usa un heap.size di 31 gigabyte: tutti i tentativi di riduce a dimensione anu risultatu sia in uccisione di alcuni nodi nantu à e dumande di ricerca pesanti cù u wildcard principali o ottene u circuit breaker in Elasticsearch stessu.
- Inoltre, per assicurà a prestazione di ricerca, avemu pruvatu à mantene u numeru di l'uggetti in u cluster u più chjucu pussibule, per processà quant'è pocu avvenimenti pussibule in u collu di bottiglia chì avemu avutu in u maestru.
Infine nantu à u monitoraghju
Per assicurà chì tuttu questu funziona cum'è previstu, monitoremu i seguenti:
- Ogni nodu di dati informa à u nostru nuvulu chì esiste, è ci sò tali è tali frammenti nantu à questu. Quandu sguassemu qualcosa in qualchì locu, u cluster raporta dopu à 2-3 seconde chì in u centru A avemu extinguitu i nodi 2, 3 è 4 - questu significa chì in altri centri di dati ùn pudemu micca sguassate quelli nodi nantu à quale ci hè solu un frammentu. manca.
- Sapendu a natura di u cumpurtamentu di u maestru, fighjemu assai attenti à u numeru di travaglii pendenti. Perchè ancu un compitu appiccicatu, s'ellu ùn hè micca tempu in u tempu, teoricamente in una situazione d'urgenza pò diventà u mutivu per quessa, per esempiu, a prumuzione di un frammentu di replica in u primariu ùn funziona micca, per quessa chì l'indexazione cesserà di travaglià.
- Fighjemu ancu assai attenti à i ritardi di u cullettivu di basura, perchè avemu digià avutu grandi difficultà cù questu durante l'ottimisazione.
- Rejects by thread per capisce in anticipu induve hè u bottleneck.
- Ebbè, metriche standard cum'è heap, RAM è I / O.
Quandu custruì u monitoraghju, duvete piglià in contu e caratteristiche di Thread Pool in Elasticsearch. descrive l'opzioni di cunfigurazione è i valori predeterminati per a ricerca è l'indicizzamentu, ma hè cumplettamente silenziu annantu à thread_pool.management.Questi filamenti processanu, in particulare, dumande cum'è _cat/shards è altri simili, chì sò cunvenuti à utilizà quandu scrive u monitoraghju. U più grande u cluster, u più tali richieste sò eseguite per unità di tempu, è u thread_pool.management sopra menzionatu ùn hè micca solu prisentatu in a ducumentazione ufficiale, ma hè ancu limitatu per difettu à i fili 5, chì hè assai prestu dispostu, dopu quale surviglianza ferma di travaglià bè.
Ciò chì vogliu dì in cunclusione : avemu fattu ! Pudemu dà à i nostri programatori è sviluppatori un strumentu chì, in quasi ogni situazione, pò furnisce rapidamente è affidabile infurmazione nantu à ciò chì succede in a produzzione.
Iè, hè diventatu abbastanza cumplicatu, ma, però, avemu riisciutu à mette i nostri desideri in i prudutti esistenti, chì ùn avemu micca bisognu di patch è riscrittura per noi stessi.
Source: www.habr.com