Paljud inimesed võitlevad Elasticsearchiga. Aga mis juhtub siis, kui soovite seda kasutada logide salvestamiseks "eriti suures mahus"? Ja kas mõne andmekeskuse rikke kogemine on valutu? Millist arhitektuuri peaksite tegema ja milliste lõksude otsa komistate?
Otsustasime Odnoklassnikis kasutada palgihalduse probleemi lahendamiseks elasticsearchi ja nüüd jagame Habriga oma kogemusi: nii arhitektuuri kui ka lõkse kohta.
Olen Pjotr Zaitsev, töötan Odnoklassnikis süsteemiadministraatorina. Enne seda olin ka admin, töötasin Manticore Searchi, Sphinxi otsinguga, Elasticsearchiga. Võib-olla, kui ilmub uus ...otsing, töötan tõenäoliselt ka sellega. Samuti osalen vabatahtlikult mitmetes avatud lähtekoodiga projektides.
Kui tulin Odnoklassnikisse, ütlesin intervjuul hoolimatult, et võiksin Elasticsearchiga koostööd teha. Pärast seda, kui olin asja selgeks saanud ja mõned lihtsad ülesanded täitnud, anti mulle suur ülesanne reformida tollal eksisteerinud logihaldussüsteem.
Nõuded
Süsteeminõuded on sõnastatud järgmiselt:
- Graylogi kavatseti kasutada esiküljena. Kuna ettevõttel oli selle toote kasutamise kogemus juba olemas, teadsid programmeerijad ja testijad seda, see oli neile tuttav ja mugav.
- Andmemaht: keskmiselt 50-80 tuhat sõnumit sekundis, aga kui midagi läheb katki, siis liiklust ei piira miski, võib olla 2-3 miljonit rida sekundis
- Arutanud klientidega otsingupäringute töötlemise kiiruse nõudeid, mõistsime, et tüüpiline sellise süsteemi kasutamise muster on järgmine: inimesed otsivad oma rakenduse viimase kahe päeva logisid ega taha oodata kauem kui teine formuleeritud päringu tulemuse jaoks.
- Administraatorid nõudsid, et süsteem oleks vajadusel kergesti skaleeritav, ilma et nad peaksid selle toimimisse süvitsi süvenema.
- Nii et ainus hooldusülesanne, mida need süsteemid perioodiliselt nõuavad, on riistvara vahetamine.
- Lisaks on Odnoklassnikil suurepärane tehniline traditsioon: iga meie käivitatav teenus peab andmekeskuse rikke üle elama (äkiline, planeerimata ja absoluutselt igal ajal).
Kõige rohkem läks meile maksma selle projekti elluviimisel viimane nõue, millest räägin lähemalt.
kolmapäev
Töötame neljas andmekeskuses, samas kui Elasticsearchi andmesõlmed võivad asuda ainult kolmes (mitmel mittetehnilisel põhjusel).
Need neli andmekeskust sisaldavad ligikaudu 18 tuhat erinevat logiallikat – riistvara, konteinerid, virtuaalmasinad.
Oluline funktsioon: klaster algab konteineritest mitte füüsilistel masinatel, vaid peal . Konteinerite jaoks on garanteeritud 2 südamikku, sarnaselt 2.0 GHz v4-ga, võimalusega ülejäänud tuumad taaskasutada, kui need on tühikäigul.
Teisisõnu:
Topoloogia
Algselt nägin lahenduse üldist vormi järgmiselt:
- Graylogi domeeni A-kirje taga on 3-4 VIP-i, see on aadress, kuhu logid saadetakse.
- iga VIP on LVS-i tasakaalustaja.
- Peale seda lähevad logid Graylogi akule, osa andmeid on GELF, osa syslogi formaadis.
- Seejärel kirjutatakse see kõik suurte partiidena Elasticsearchi koordinaatorite patareile.
- Ja nad omakorda saadavad vastavatele andmesõlmedele kirjutamis- ja lugemistaotlusi.
Terminoloogia
Võib-olla ei mõista kõik terminoloogiat üksikasjalikult, seega tahaksin sellel veidi peatuda.
Elasticsearchil on mitut tüüpi sõlme - juht-, koordinaator-, andmesõlm. Erinevate logiteisenduste ja erinevate klastrite vahelise suhtluse jaoks on veel kaks tüüpi, kuid kasutasime ainult loetletud.
meister
See pingib kõiki klastris olevaid sõlme, haldab ajakohast klastrikaarti ja jaotab selle sõlmede vahel, töötleb sündmuste loogikat ja teostab mitmesuguseid klastriüleseid majapidamistöid.
Koordineerija
Täidab ühte ülesannet: võtab vastu klientide lugemis- või kirjutamistaotlusi ja suunab selle liikluse. Kui on olemas kirjutamistaotlus, küsib see suure tõenäosusega kaptenilt, millisesse vastava indeksi kildu ta selle peaks panema, ja suunab päringu edasi.
Andmesõlm
Salvestab andmeid, sooritab väljast saabuvaid otsingupäringuid ja teostab toiminguid sellel asuvate kildudega.
Hallpall
See on midagi Kibana ja Logstashi sulandumist ELK virnas. Graylog ühendab endas nii kasutajaliidese kui ka logitöötluse konveieri. Kapoti all töötavad Graylogil Kafka ja Zookeeper, mis pakuvad ühenduvust Graylogiga kui klastrit. Graylog saab logisid vahemällu salvestada (Kafka), kui Elasticsearch pole saadaval, ja korrata ebaõnnestunud lugemis- ja kirjutamistaotlusi, rühmitada ja märkida logid vastavalt määratud reeglitele. Nagu Logstash, on ka Graylogil võimalus ridu enne Elasticsearchi kirjutamist muuta.
Lisaks on Graylogil sisseehitatud teenusetuvastus, mis võimaldab ühe saadaoleva Elasticsearchi sõlme põhjal hankida kogu klastrikaardi ja filtreerida seda kindla sildi järgi, mis võimaldab suunata päringuid konkreetsetesse konteineritesse.
Visuaalselt näeb see välja umbes selline:
See on ekraanipilt konkreetsest juhtumist. Siin koostame otsingupäringu põhjal histogrammi ja kuvame asjakohased read.
Indeksid
Naastes süsteemiarhitektuuri juurde, tahaksin pikemalt peatuda sellel, kuidas me indeksimudeli üles ehitasime nii, et see kõik õigesti töötaks.
Ülaltoodud diagrammil on see madalaim tase: Elasticsearchi andmesõlmed.
Indeks on suur virtuaalne üksus, mis koosneb Elasticsearchi kildudest. Iseenesest pole kõik killud midagi muud kui Lucene'i indeks. Ja iga Lucene'i indeks koosneb omakorda ühest või mitmest segmendist.
Kavandamisel leidsime, et suure andmehulga lugemiskiiruse nõude täitmiseks peame need andmed andmesõlmede vahel ühtlaselt "hajutama".
Selle tulemuseks oli tõsiasi, et kildude arv indeksi kohta (koos koopiatega) peaks olema rangelt võrdne andmesõlmede arvuga. Esiteks selleks, et tagada kahega võrdne replikatsioonitegur (see tähendab, et võime kaotada poole klastrist). Ja teiseks selleks, et töödelda lugemis- ja kirjutamistaotlusi vähemalt pooles klastris.
Esmalt määrasime säilitusajaks 30 päeva.
Kildude jaotust saab graafiliselt kujutada järgmiselt:
Kogu tumehall ristkülik on indeks. Selle vasakpoolne punane ruut on esmane kild, indeksis esimene. Ja sinine ruut on koopiakild. Need asuvad erinevates andmekeskustes.
Kui lisame veel ühe killu, läheb see kolmandasse andmekeskusesse. Ja lõpuks saame selle struktuuri, mis võimaldab kaotada alalisvoolu ilma andmete järjepidevust kaotamata:
Indeksite rotatsioon, s.o. uue indeksi loomisel ja vanima kustutamisel tegime selle võrdseks 48 tunniga (vastavalt indeksi kasutamise mustrile: kõige sagedamini otsitakse viimast 48 tundi).
See indeksi pööramise intervall on tingitud järgmistest põhjustest.
Kui otsingupäring saabub konkreetsesse andmesõlme, on jõudluse seisukohalt tulusam, kui päringut tehakse ühe killu kohta, kui selle suurus on võrreldav sõlme puusa suurusega. See võimaldab teil hoida indeksi kuuma osa hunnikus ja sellele kiiresti juurde pääseda. Kui "kuumaid osi" on palju, väheneb indeksotsingu kiirus.
Kui sõlm hakkab ühel killul otsingupäringut täitma, eraldab see füüsilise masina hüperlõimede tuumade arvuga võrdse arvu lõime. Kui otsingupäring mõjutab suurt hulka kilde, kasvab lõimede arv proportsionaalselt. Sellel on negatiivne mõju otsingukiirusele ja uute andmete indekseerimisele.
Vajaliku otsingu latentsuse tagamiseks otsustasime kasutada SSD-d. Taotluste kiireks töötlemiseks pidi neid konteinereid majutanud masinatel olema vähemalt 56 südamikku. Arv 56 valiti tingimuslikult piisavaks väärtuseks, mis määrab lõimede arvu, mida Elasticsearch töö ajal genereerib. Elasitcsearchis sõltuvad paljud lõimekogumi parameetrid otseselt saadaolevate tuumade arvust, mis omakorda mõjutab otseselt klastris vajalikku sõlmede arvu vastavalt põhimõttele "vähem südamikke - rohkem sõlme".
Selle tulemusel leidsime, et kild kaalub keskmiselt umbes 20 gigabaiti ja indeksi kohta on 1 kildu. Seega, kui me pöörame neid üks kord iga 360 tunni järel, on meil neid 48. Iga indeks sisaldab 15 päeva andmeid.
Andmete kirjutamise ja lugemise ahelad
Mõelgem välja, kuidas selles süsteemis andmeid salvestatakse.
Oletame, et Graylogilt saabub koordinaatorile mõni taotlus. Näiteks tahame indekseerida 2-3 tuhat rida.
Graylogilt päringu saanud koordinaator küsitleb kaptenit: "Indekseerimistaotluses täpsustasime konkreetselt indeksi, kuid millisesse kildu see kirjutada ei olnud."
Ülem vastab: "Kirjutage see teave killunumbrile 71", misjärel saadetakse see otse vastavasse andmesõlme, kus asub primaarne killu number 71.
Pärast seda kopeeritakse tehingulogi replikakildu, mis asub teises andmekeskuses.
Graylogist saabub koordinaatorile otsingupäring. Koordinaator suunab selle indeksi järgi ümber, samal ajal kui Elasticsearch jagab päringud primaar- ja replikakildude vahel, kasutades ümbertöötamise põhimõtet.
180 sõlme reageerivad ebaühtlaselt ja nende reageerimise ajal kogub koordinaator teavet, mille kiiremad andmesõlmed on juba "välja sülitanud". Pärast seda, kui kogu teave on saabunud või päring on aegunud, annab see kõik otse kliendile.
Kogu see süsteem töötleb viimase 48 tunni otsingupäringuid keskmiselt 300–400 ms jooksul, välja arvatud need päringud, millel on eesmine metamärk.
Elasticsearchiga lilled: Java häälestus
Et see kõik toimiks nii, nagu me algselt soovisime, kulutasime väga kaua aega klastris mitmesuguste asjade silumiseks.
Esimene osa avastatud probleemidest oli seotud sellega, kuidas Java on Elasticsearchis vaikimisi eelkonfigureeritud.
Probleem üks
Oleme täheldanud väga palju aruandeid, mille kohaselt Lucene'i tasemel, kui taustatööd töötavad, ebaõnnestuvad Lucene'i segmendi liitmised veaga. Samas oli logides selgelt näha, et tegu on OutOfMemoryError veaga. Telemeetria abil nägime, et puus on vaba ja polnud selge, miks see operatsioon ebaõnnestus.
Selgus, et Lucene'i indeksi ühinemised toimuvad väljaspool puusa. Ja konteinerid on tarbitavate ressursside osas üsna rangelt piiratud. Nendesse ressurssidesse mahtus ainult kuhja (heap.size väärtus oli ligikaudu võrdne RAM-iga) ja mõned kuhjavälised toimingud jooksid mälujaotusveaga kokku, kui need mingil põhjusel ei mahtunud enne limiiti jäänud ~500 MB hulka.
Parandus oli üsna triviaalne: suurendati konteineri jaoks saadaolevat RAM-i mahtu, misjärel unustasime, et meil on isegi selliseid probleeme.
Probleem kaks
4-5 päeva pärast klastri käivitamist märkasime, et andmesõlmed hakkasid perioodiliselt klastrist välja kukkuma ja sisenema sellesse 10-20 sekundi pärast.
Kui me seda välja mõtlema hakkasime, selgus, et seda kuhjavälist mälu Elasticsearchis ei kontrollita kuidagi. Kui andsime konteinerile rohkem mälu, suutsime täita otsesed puhverkogumid erineva teabega ja see kustutati alles pärast selgesõnalise GC käivitamist Elasticsearchist.
Mõnel juhul võttis see toiming üsna kaua aega ja selle aja jooksul suutis klaster märkida selle sõlme juba väljutuks. See probleem on hästi kirjeldatud .
Lahendus oli järgmine: piirasime Java võimalust kasutada nende toimingute jaoks suuremat osa mälust väljaspool kuhja. Piirasime selle 16 gigabaidiga (-XX:MaxDirectMemorySize=16g), tagades, et selgesõnalist GC-d kutsutakse palju sagedamini ja töödeldakse palju kiiremini, mis ei destabiliseeri enam klastrit.
Kolmas probleem
Kui arvate, et probleemid "sõlmedega, mis lahkuvad klastrist kõige ootamatumal hetkel" on möödas, siis eksite.
Kui konfigureerisime tööd indeksitega, valisime mmapfs to värsketel kildudel, millel on suur segmentatsioon. See oli paras prohmakas, sest mmapfsi kasutamisel kaardistatakse fail RAM-i ja seejärel töötame kaardistatud failiga. Seetõttu selgub, et kui GC üritab rakenduses lõime peatada, läheme väga pikaks ajaks turvapunkti ja teel sinna ei vasta rakendus kapteni päringutele, kas ta on elus. . Sellest lähtuvalt usub kapten, et sõlme pole enam klastris. Pärast seda, 5-10 sekundi pärast, töötab prügikoguja, sõlm ärkab ellu, siseneb uuesti klastrisse ja alustab kildude lähtestamist. See kõik tundus väga nagu "lavastus, mida me väärisime" ega sobinud millekski tõsiseks.
Sellest käitumisest vabanemiseks läksime esmalt üle standardsetele niofidele ja seejärel Elasticu viiendalt versioonilt kuuendale üle minnes proovisime hübriidseid, kus seda probleemi ei korratud. Lisateavet salvestustüüpide kohta saate lugeda .
Probleem neli
Siis tekkis veel üks väga huvitav probleem, mida käsitlesime rekordaega. Püüdsime seda 2-3 kuud, sest selle muster oli täiesti arusaamatu.
Mõnikord läksid meie koordinaatorid Full GC-sse, tavaliselt pärast lõunat, ega tulnud sealt enam tagasi. Samal ajal GC viivituse logimisel nägi see välja nii: kõik läheb hästi, hästi, hästi ja siis järsku läheb kõik väga halvasti.
Alguses arvasime, et meil on kuri kasutaja, kes käivitas mingisuguse päringu, mis koordinaatori töörežiimist välja lõi. Logisime taotlusi väga pikka aega, püüdes aru saada, mis toimub.
Selle tulemusena selgus, et hetkel, kui kasutaja käivitab tohutu päringu ja see jõuab konkreetse Elasticsearchi koordinaatorini, reageerivad mõned sõlmed kauem kui teised.
Ja samal ajal kui koordinaator ootab kõikidelt sõlmedelt vastust, kogub ta juba vastanud sõlmedest saadetud tulemused. GC puhul tähendab see, et meie hunniku kasutusmustrid muutuvad väga kiiresti. Ja meie kasutatud GC ei saanud selle ülesandega hakkama.
Ainus parandus, mille leidsime klastri käitumise muutmiseks selles olukorras, on üleminek JDK13-le ja Shenandoah prügikoguja kasutamine. See lahendas probleemi, meie koordinaatorid lõpetasid kukkumise.
Siin lõppesid probleemid Javaga ja algasid ribalaiusega seotud probleemid.
"Marjad" koos Elasticsearchiga: läbilaskevõime
Läbilaskevõimega seotud probleemid tähendavad, et meie klaster töötab stabiilselt, kuid indekseeritud dokumentide arvu tipptasemel ja manöövrite ajal on jõudlus ebapiisav.
Esimene ilmnenud sümptom: mõne tootmise plahvatuse ajal, kui järsku genereeritakse väga palju logisid, hakkab Graylogis sageli vilkuma indekseerimisviga es_rejected_execution.
Selle põhjuseks oli asjaolu, et thread_pool.write.queue ühes andmesõlmes, kuni hetkeni, mil Elasticsearch suudab indekseerimistaotlust töödelda ja teabe kettal olevale killule üles laadida, suudab vaikimisi vahemällu salvestada vaid 200 päringut. Ja sisse Selle parameetri kohta räägitakse väga vähe. Näidatud on ainult maksimaalne niitide arv ja vaikesuurus.
Muidugi läksime seda väärtust väänama ja saime teada järgmise: konkreetselt on meie seadistuses kuni 300 päringut üsna hästi vahemällu salvestatud ja suurem väärtus on täis tõsiasja, et lendame taas Full GC-sse.
Lisaks, kuna tegemist on ühe päringu jooksul saabuvate sõnumite partiidega, tuli Graylogi muuta nii, et see ei kirjutaks sageli ja väikeste partiidena, vaid suurte partiidena või kord 3 sekundi jooksul, kui partii pole ikka veel valmis. Sel juhul selgub, et teave, mida me Elasticsearchis kirjutame, muutub kättesaadavaks mitte kahe sekundi, vaid viie sekundiga (mis sobib meile üsna hästi), kuid mitu kordamist tuleb teha, et suurest läbi suruda. teabepakk väheneb.
See on eriti oluline nendel hetkedel, kui midagi on kuskil kokku jooksnud ja sellest raevukalt teatab, et mitte saada täiesti rämpspostiga Elasticut ja mõne aja pärast - hallid sõlmed, mis ei tööta ummistunud puhvrite tõttu.
Lisaks, kui meil olid samad plahvatused tootmises, saime programmeerijatelt ja testijatelt kaebusi: hetkel, kui neil neid palke väga vaja oli, anti neile need väga aeglaselt kätte.
Nad hakkasid seda välja mõtlema. Ühest küljest oli selge, et nii otsingu- kui ka indekseerimispäringuid töödeldi sisuliselt samades füüsilistes masinates ja nii või teisiti tekivad teatud miinused.
Kuid sellest saab osaliselt mööda hiilida, kuna Elasticsearchi kuuendas versioonis ilmus algoritm, mis võimaldab jaotada päringuid asjakohaste andmesõlmede vahel mitte juhusliku ümmarguse kontrolli põhimõttel (konteiner, mis indekseerib ja hoiab esmast -shard võib olla väga hõivatud, ei ole võimalik kiiresti vastata), kuid edastada see päring vähem koormatud konteinerisse koos replika-shardiga, mis reageerib palju kiiremini. Teisisõnu, jõudsime väärtuseni use_adaptive_replica_selection: true.
Lugemispilt hakkab välja nägema järgmine:
Sellele algoritmile üleminek võimaldas oluliselt parandada päringuaega nendel hetkedel, mil meil oli kirjutada suur logide voog.
Lõpuks oli põhiprobleemiks andmekeskuse valutu eemaldamine.
Mida me klastrist tahtsime kohe pärast ühenduse kaotamist ühe alalisvooluga:
- Kui meil on ebaõnnestunud andmekeskuses praegune ülemseade, valitakse see uuesti ja teisaldatakse rollina teise DC-i teise sõlme.
- Ülem eemaldab kiiresti kõik ligipääsmatud sõlmed klastrist.
- Ülejäänute põhjal saab ta aru: kadunud andmekeskuses olid meil sellised ja sellised esmased killud, ülejäänud andmekeskustes promob ta kiiresti täiendavaid koopiakilde ja jätkame andmete indekseerimist.
- Selle tulemusena väheneb klastri kirjutamis- ja lugemisvõime järk-järgult, kuid üldiselt töötab kõik, kuigi aeglaselt, kuid stabiilselt.
Nagu selgus, tahtsime midagi sellist:
Ja saime järgmise:
Kuidas see juhtus?
Kui andmekeskus kukkus, sai kitsaskohaks meie peremees.
Miks?
Fakt on see, et kaptenil on TaskBatcher, mis vastutab teatud ülesannete ja sündmuste levitamise eest klastris. Mis tahes sõlmest väljumine, killu üleviimine koopiast esmaseks, mis tahes ülesanne kuskil killu loomiseks – kõik see läheb kõigepealt TaskBatcherisse, kus seda töödeldakse järjestikku ja ühes lõimes.
Ühe andmekeskuse äravõtmisel selgus, et kõik säilinud andmekeskuste andmesõlmed pidasid oma kohuseks peremeest teavitada “me oleme kaotanud sellised ja sellised killud ja sellised ja sellised andmesõlmed”.
Samal ajal saatsid säilinud andmesõlmed kogu selle teabe praegusele ülemale ja püüdsid oodata kinnitust, et ta seda aktsepteerib. Nad ei oodanud seda, kuna meister sai ülesandeid kiiremini, kui ta suutis vastata. Sõlmed aegusid korduvate päringute puhul ja kapten ei püüdnud sel ajal neile isegi vastata, vaid oli päringute prioriteedi järgi sorteerimise ülesandest täielikult sisse võetud.
Terminali kujul selgus, et andmesõlmed saatsid masteri spämmi niivõrd, et see läks täielikku GC-sse. Peale seda kolis meie meistriroll mõnda järgmisse sõlme, sellega juhtus absoluutselt sama asi ja selle tulemusena kukkus klaster täielikult kokku.
Tegime mõõtmised ja enne versiooni 6.4.0, kus see parandati, piisas sellest, et klastri täielikuks väljalülitamiseks väljastasime korraga vaid 10 andmesõlme 360-st.
See nägi välja umbes selline:
Pärast versiooni 6.4.0, kus see kohutav viga parandati, lõpetasid andmesõlmed kapteni tapmise. Kuid see ei teinud teda "targemaks". Nimelt: kui me väljastame 2, 3 või 10 (mis tahes arvu peale ühe) andmesõlme, saab ülem mingi esimese teate, mis ütleb, et sõlm A on lahkunud, ja üritab sõlmele B, sõlmele C, sõlmele D öelda.
Ja hetkel saab sellega hakkama vaid nii, et määrates katsetele kellelegi millestki rääkida ajalõpu, mis on võrdne umbes 20-30 sekundiga ja seeläbi kontrollida andmekeskuse klastrist väljakolimise kiirust.
Põhimõtteliselt sobib see nõuetega, mis projekti raames algselt lõpptootele esitati, kuid “puhta teaduse” seisukohalt on tegemist veaga. Mille, muide, parandasid arendajad versioonis 7.2 edukalt.
Veelgi enam, kui teatud andmesõlm kustus, selgus, et selle väljumise kohta teabe levitamine oli olulisem kui kogu klastrile rääkimine, et sellel on sellised ja sellised esmased killud (et edendada koopiakildu teistes andmetes keskus esmases ja nendele võiks kirjutada teabe).
Seega, kui kõik on juba vaibunud, ei märgita vabastatud andmesõlmed kohe aegunuks. Sellest tulenevalt oleme sunnitud ootama, kuni kõik pingid on vabastatud andmesõlmedesse aegunud, ja alles pärast seda hakkab meie klaster meile ütlema, et seal, seal ja seal peame jätkama teabe salvestamist. Selle kohta saate rohkem lugeda .
Seetõttu kulub meil täna tipptunnil andmekeskuse eemaldamise toiming umbes 5 minutit. Nii suure ja kohmaka kolossi kohta on see päris hea tulemus.
Selle tulemusena jõudsime järgmise otsuseni:
- Meil on 360 andmesõlme 700 gigabaidise ketastega.
- 60 koordinaatorit liikluse suunamiseks läbi samade andmesõlmede.
- 40 meistrit, mille oleme omamoodi pärandina jätnud alates versioonidest enne 6.4.0 - andmekeskuse väljaviimise üleelamiseks olime vaimselt valmis kaotama mitu masinat, et oleksime garanteeritud meistrite kvoorumi olemasolu ka aastal. halvimal juhul
- Kõik katsed ühendada ühe konteineri rolle tulid vastu tõsiasjaga, et varem või hiljem purunes sõlm koormuse all.
- Kogu klaster kasutab 31 gigabaidist kuhja suurust: kõik katsed suurust vähendada lõppesid raskete otsingupäringute puhul mõne sõlme tapmisega juhtiva metamärgiga või Elasticsearchi enda kaitselüliti hankimiseni.
- Lisaks püüdsime otsingu jõudluse tagamiseks hoida klastris olevate objektide arvu võimalikult väikesena, et masteris saadud pudelikaelas võimalikult vähe sündmusi töödelda.
Lõpuks jälgimisest
Tagamaks, et see kõik toimiks ettenähtud viisil, jälgime järgmist.
- Iga andmesõlm teatab meie pilvele, et ta on olemas ja sellel on selliseid ja selliseid kilde. Kui me kuskil midagi kustutame, teatab klaster 2-3 sekundi pärast, et keskuses A kustutasime sõlmed 2, 3 ja 4 – see tähendab, et teistes andmekeskustes ei saa me mingil juhul kustutada neid sõlmi, millel on ainult üks kild. vasakule.
- Teades kapteni käitumise olemust, vaatame väga hoolikalt ootelolevate ülesannete arvu. Sest isegi üks takerdunud ülesanne, kui see õigel ajal ei aegu, võib teoreetiliselt mõnes hädaolukorras saada põhjuseks, miks näiteks replica shardi reklaamimine esmases ei toimi, mistõttu indekseerimine lakkab töötamast.
- Vaatame väga tähelepanelikult ka prügikorjajate viivitusi, sest optimeerimise käigus on meil sellega juba suuri raskusi olnud.
- Lükkab niidi järgi tagasi, et eelnevalt aru saada, kus on kitsaskoht.
- Noh, standardsed mõõdikud, nagu hunnik, RAM ja I/O.
Järelevalve ehitamisel peate arvestama Elasticsearchi Thread Pooli funktsioonidega. kirjeldab otsingu ja indekseerimise seadistusvalikuid ja vaikeväärtusi, kuid vaikib täielikult teemast thread_pool.management. Need lõimed töötlevad eelkõige selliseid päringuid nagu _cat/shards ja muud sarnased, mida on mugav kasutada jälgimise kirjutamisel. Mida suurem on klaster, seda rohkem selliseid päringuid ajaühikus täidetakse ja ülalnimetatud thread_pool.managementi ametlikus dokumentatsioonis mitte ainult ei esitata, vaid see on vaikimisi piiratud 5 lõimega, mis pärast seda kõrvaldatakse väga kiiresti. mis monitooring lakkab õigesti töötamast.
Mida ma lõpetuseks öelda tahan: saime hakkama! Saime oma programmeerijatele ja arendajatele anda tööriista, mis suudab peaaegu igas olukorras kiiresti ja usaldusväärselt anda teavet tootmises toimuva kohta.
Jah, see osutus üsna keeruliseks, kuid sellegipoolest suutsime oma soovid sobitada olemasolevatesse toodetesse, mida me ei pidanud ise lappima ja ümber kirjutama.
Allikas: www.habr.com