Elasticsearch klaster 200 TB+

Elasticsearch on paljude jaoks tuttav. Kuid mis juhtub, kui soovid selle abil salvestada logisid «suures mahus»? Ja veel, kuidas taluda kõigi mitme andmekeskuse tõrkeid? Milline arhitektuur peaks olema, ja milliste peidetud probleemide ees seisad?

Me Odnoklassnikis otsustasime, et kasutame elasticsearchi, et lahendada logihalduse jautet, ja nüüd jagame oma kogemusi Habros: nii arhitektuuri kui ka peidetud probleemide kohta.

Mina olen Pjotr Zaitsev, töötan süsteemiadministraatorina Odnoklassnikis. Enne seda olin samuti admin ja töötasin Manticore Searchi, Sphinx Searchi ja Elasticsearchiga. Võib-olla, kui ilmub jälle mõni ...search, töötan ka selle kallal. Osalen ka mitmetes avatud lähtekoodiga projektides vabatahtlikuna.

Kui ma tulin Odnoklassnikisse, ütlesin usinalt intervjuul, et oskan töötada Elasticsearchiga. Pärast sellega harjumist ja mõne lihtsa ülesande tegemist anti mulle suur ülesanne reformeerida tollane logihaldussüsteem.

Nõuded

Süsteemi nõuded formuleeriti järgmiselt:

• Frontendina pidi olema kasutusel Graylog. Sest ettevõttes oli juba selle toote kasutamise kogemus, arendajad ja testijad teadsid seda, see oli neile tuttav ja mugav.
• Andmemaht: keskmiselt 50-80 tuhat sõnumit sekundis, kuid kui midagi läheb katki, siis liiklus ei ole millegagi piiratud, see võib olla 2-3 miljonit rida sekundis.
• Kliendiga nõudlusi arutades jõudsime arusaamisele, et tüüpiline musternäide sellise süsteemi kasutamisest on järgmine: inimesed otsivad enda rakenduse logisid viima kahe päeva jooksul ja ei soovi, et ootavad rohkem kui ühe sekundi.
• Administraatorid rõhutasid, et süsteem peab olema vajadusel hõlpsasti skaleeritav, nõudmata sügavat arusaamist selle toimimisest.
• Ainus hooldusülesanne, mis nendele süsteemidele perioodiliselt vajalik oli, oli vahetada mõnd riistvara.
• Lisaks on Odnoklassnikis suurepärane tehniline traditsioon: iga teenus, mille me käivitame, peab taluma andmekeskuse tõrke (äkki, planeerimata ja igal ajal).

Selle projekti viimase nõude täitmine nõudis meilt kõige suuremat vaeva, millest räägin lähemalt.

Keskkond

Me töötame neljas andmekeskuses, samas võivad Elasticsearchi andmenood asuda ainult kolmes (mitmete mitte-tehniliste põhjuste tõttu).

Nendes neljas andmekeskuses asub umbes 18 tuhat erinevat logiallikat — riistvara, konteinerid, virtuaalmasinad.

Oluline omadus: klastrite käivitamine toimub konteinerites Podman mitte füüsilistel masinatel, vaid oma pilve tootel one-cloud. Korrustele garanteeritakse 2 tuuma, mis on võrdsed 2,0 GHz v4-ga, võimalusega kasutada ülejäänud tuumasid, kui need on vabad.

Teisisõnu:

Topoloogia

Lahendi üldine välimus nägi mulle algselt välja järgmine:

• 3-4 VIP-d seisavad domeeni Graylog A-kirje taga, sellele aadressile saadetakse logid.
• iga VIP esindab LVS-i koormuse tasakaalustajat.
• Pärast seda jõuavad logid Graylogi akusse, osa andmetest tuleb GELF formaadis, osa syslog formaadis.
• Edasi kirjutatakse kõik need suurtel partidel Elasticsearchi koordinaatorite akusse.
• Need, omakorda, saadavad kirjutamise ja lugemise päringud asjakohastele andmeoordadele.

Terminoloogia

Võib-olla ei tunne kõik terminoloogiat kuigi hästi, seetõttu tahaksin sellega pisut peatuda.

Elasticsearchis on mitmeid tüüpe noode — master, koordinaator, andmenood. On veel kaks muud tüüpi erinevate logide muutmiseks ja erinevate klastrite omavaheliseks sidumiseks, kuid me kasutasime ainult loetletud.

Master
Pingib kõik klastris olevad nood, toetab kehtivat klastrikaarti ja levitab seda noode vahel, käsitleb sündmuse loogikat, tegeleb igasuguse klastrisisese hooldusega.

Koordinaator
Täidab ühte ainukest ülesannet: aktsepteerib kliendipäringuid lugemise või kirjutamise jaoks ja suunab selle liikluse. Kui päring on kirjutamise kohta, siis küsib see tõenäoliselt masterilt, millisesse sobivasse indeksi shard'i seda paigutada, ja suunab päringu edasi.

Andmenood
Hoidab andmeid, täidab väljastpoolt saabuvaid otsingupäringuid ja teoseid asuvatelt shardidelt.

Graylog
See, this is somewhat like a blend of Kibana with Logstash in the ELK stack. Graylog combines both UI and log processing pipeline. Under the hood, Kafka and Zookeeper work within Graylog, providing connectivity for Graylog as a cluster. Graylog can cache logs (Kafka) in case Elasticsearch becomes unavailable and retry failed read and write requests, grouping and tagging logs according to specified rules. Similar to Logstash, Graylog has functionality for modifying strings before writing them to Elasticsearch.

Additionally, Graylog features built-in service discovery, allowing you to obtain the entire cluster map based on one available Elasticsearch node and filter it by a specific tag, enabling requests to be directed to specific containers.

Visually, it looks something like this:

This is a screenshot from a specific instance. Here we build a histogram based on a search query, displaying relevant entries.

Indeksid

Returning to the system architecture, I would like to take a closer look at how we constructed the index model to ensure everything operates correctly.

In the previously provided diagram, this is the lowest level: Elasticsearch data nodes.

An index is a large virtual entity consisting of Elasticsearch shards. Each of these shards is, in fact, a Lucene index. And each Lucene index, in turn, consists of one or more segments.

During the design phase, we estimated that to meet the requirement for read speed on a large volume of data, we needed to evenly 'spread' this data across the data nodes.

This led to the fact that the number of shards per index (with replicas) should be strictly equal to the number of data nodes. Firstly, to ensure a replication factor of two (meaning we can lose half of the cluster). Secondly, to handle read and write requests on at least half of the cluster.

We initially defined the retention time as 30 days.

The distribution of shards can be graphically represented as follows:

The entire dark gray rectangle is the index. The left red square in it is the primary shard, the first one in the index. And the blue square is the replica shard. They are located in different data centers.

Kui me lisame veel ühe shard'i, läheb see kolmandasse andmekeskusesse. Lõpuks saame sellise struktuuri, mis tagab andmete järjepidevuse, isegi kui üks andmekeskus kaob.

Indeksite roteerimine, st uue indeksi loomine ja kõige vanema kustutamine, on seatud 48 tunni peale (indeksi kasutusmuster: viimase 48 tunni jooksul otsitakse kõige sagedamini).

Sellise indeksi roteerimise intervalliga seonduvad järgmised põhjused:

Kui konkreetne andmenood saadab otsingupäringu, on jõudluse seisukohalt kasulikum küsida ühte shard'i, kui selle suurus on võrdsustatav sõlme mälu suurusega. See võimaldab hoida indeksi "kuuma" osa mälu ja kiiresti sellele pääseda. Kui "kuumi osi" on liiga palju, halveneb indeksi otsingu kiirus.

Kui sõlm hakkab mõnel shard'il otsingupäringut täitma, eraldab ta niipalju lõime, kui palju on füüsilise masina hüper-töötleva tuuma. Kui otsingupäring puudutab palju shard'e, suureneb lõimede arv proportsionaalselt. See mõjutab negatiivselt otsingukiirus ja halvendab uute andmete indekseerimist.

Otsingu vajaliku latentsuse tagamiseks otsustasime kasutada SSD-sid. Kiirete päringute töötlemiseks pidid need konteinerid asuvad masinad omama vähemalt 56 tuuma. Number 56 on valitud kui tinglikult piisav kogus, mis määrab, kui palju lõime Elasticsearch töös kasvatab. Elasticsearchis sõltuvad paljusid thread pool'i parameetreid otseselt kättesaadavate tuumade arvust, mis omakorda mõjutab otse klastis vajalike sõlmede arvu põhimõttel "vähem tuumasid — rohkem sõlmi".

Kokkuvõttes selgus, et keskmine shard kaalub umbes 20 gigabaiti, ja 1 indeksi kohta on 360 shard'i. Seega, kui me neid roteerime iga 48 tunni järel, on meil neid 15 tükki. Iga indeks sisaldab andmeid 2 päeva jooksul.

Andmete kirjutamise ja lugemise skeemid

Vaatame, kuidas selles süsteemis andmeid kirjutatakse.

Oletame, et meil on Graylogist koordinaatorisse saabumas mõni päring. Näiteks soovime indekseerida 2-3 tuhat rida.

Koordinaator, saades Graylogilt päringu, küsib mestérit: "Indekseerimise päringus oli meil konkreetselt määratud indeks, kuid kuhu shard'i see kirjutada - ei olnud märgitud."

Meister vastab: "Salvesta see teave shard'i numero 71", mille järel see suunatakse otse asjakohasesse andme-Node'i, kus asub primary-shard numero 71.

Seejärel kopeeritakse tehingu logi replica-shard'ile, mis asub juba teises andmepunktis.

Graylogist tuleb koordinaatorisse otsingupäring. Koordinaator suunab selle indeksi kaudu, samas kui Elasticsearch jagab päringud round-robin põhimõttel primary-shard'i ja replica-shard'i vahel.

180 Node'i vastavad ebaühtlaselt ja seni, kuni nad vastavad, kogub koordinaator teavet, mille juba "välja sülitasid" kiiremad andme-Node'id. Pärast seda, kui kogu teave on saabunud või päringu puhul on saavutatud timeout, edastab ta kõik otse kliendile.

Kogu see süsteem töötleb keskmiselt viimase 48 tunni otsingupäringud 300-400 ms jooksul, välja arvatud need päringud, kus on leading wildcard.

"Lilled" Elasticsearchiga: Java seadistamine

Kuna kõik see tööle hakkaks nagu me algselt soovisime, seadistasime me väga kaua erinevaid asju klastris.

Esimene osa avastatud probleemidest oli seotud sellega, kuidas Elasticsearchis on vaikimisi eelnevalt seadistatud Java.

Esimene probleem
Me nägime väga suurt hulka teateid selle kohta, et meil on Lucene tasemel, kui taustatööd on käivitunud, Lucene segmentide merge'id lõppevad tõrke tõttu. Samal ajal oli logides näha, et see oli OutOfMemoryError-error. Telemeetria kaudu nägime, et heap on vaba, ja polnud selge, miks see operatsioon kukkus.

Selgus, et Lucene indeksi merge toimub väljaspool heap'i. Ja konteinerid on üsna rangeid piiranguid tarbitavatele ressurssidele. Nendesse ressurssidesse mahtus ainult heap (heap.size väärtus oli ligikaudu sama kui RAM), samas kui teatud off-heap'i operatsioonid kukkusid mälu jaotamise tõrkega, kui nad mingil põhjusel ei mahtunud nendesse ~500 MB, mis jäid piirangust.

Parandus oli üsna triviaalne: konteinerile saadaval olev RAM-i maht suurenes, pärast mida unustasime, et sellised probleemid olid meil kunagi olnud.

Teine probleem
Umbes 4-5 päeva pärast klastrite käivitamist märkasime, et andme-Node'id hakkavad perioodiliselt klastrist välja kukkuma ja tulema tagasi umbes 10-20 sekundi pärast.

Kui me süvenesime, selgus, et see off-heap mälu Elasticsearchis ei ole praktiliselt üldse kontrollitav. Kui andsime konteinerile rohkem mälu, saime võimaluse täita otsepuutepankade erinevat teavet ja see puhastati alles pärast seda, kui Elasticsearch käivitas selgesõnalise GC.

Mõnel juhul kestis see toiming üsna kaua ja selle aja jooksul märkis klaster selle sõlme juba välja langenuks. Probleem on hästi kirjeldatud. siin.

Lahendus oli järgmine: piirasime Java võimalust kasutada peamise osa mälu väljastpoolt heap'i nende operatsioonide jaoks. Piirasime seda kuni 16 gigabaidini (-XX:MaxDirectMemorySize=16g), saavutades nii, et selgesõnaline GC kutsuti välja märgatavalt sagedamini ning töötas märgatavalt kiiremini, lõpetades klastrit destabiliseerimise.

Kolmas probleem
Kui arvate, et probleemid "sõlmedega, mis lahkuvad klastrist kõige ettenämatumal hetkel" on sellega lahenenud, siis eksite.

Kui me konfigureerisime indekseerimist, valisime mmapfs, et lühendada otsinguaega värskete shardide kõrge segmentatsiooniga. See oli üsna tõsine viga, sest mmapfs-i kasutamisel kaardistatakse fail vahemälu, ja seejärel töötame juba kaardistatud failiga. Seetõttu osutame, et üritades GC-l peatada rakenduses niidid, kulus meil safepunkti jõudmiseks väga kaua aega, ja selles protsessis lakkas rakendus vastamast meistri päringutele, et kas see on veel elus. Vastavalt sellele arvab meister, et sõlm ei ole enam meie klastris kohal. Seejärel, umbes 5-10 sekundi pärast töötab garbage collector, sõlm taastub, siseneb taas klastrisse ja alustab shardide algatamist. Kõik see meenutas tugevalt "toodet, mille me väärisime" ja ei sobinud millekski tõsisemaks.

Sellest käitumisest vabanemiseks läksime esmalt üle standardsele niofs-ile ja hiljem, kui Elastic viiendatest versioonidest kuuesse migreerisime, proovisime hybridfs-i, kus see probleem ei kordunud. Tüüpide ladustamise kohta saab rohkem lugeda. siin.

Neljas probleem
Siis oli veel üks väga huvitav probleem, mida me ravisime rekordiliselt kaua. Kartsime seda 2-3 kuud, kuna selle mustrit oli täiesti võimatu mõista.

Mõnikord läksid meie koordinaatorid Full GC-sse, tavaliselt pärast lõunat, ja sealt nad enam ei naasnud. Samuti nägi GC viivituste logimisel välja nii: meil läheb kõik hästi, hästi, hästi, ja siis plaan — ja kõik muutub järsult halvemaks.

Alguses arvasime, et meil on kuri kasutaja, kes käivitab mingi päringu, mis tõukab koordinaatori töömoodulist välja. Logisime päringuid väga kaua, püüdes aru saada, mis toimub.

Kokkuvõttes selgus, et hetkel, kui mõni kasutaja käivitab väga suure päringu ja see satub mõnele konkreetsele Elasticsearchi koordinaatorile, vastavad mõned sõlmed kauem kui teised.

Ja see aeg, mille koordinaator ootab kõigi sõlmede vastuseid, kogub ta tulemused, mis on saadud juba vastanud sõlmedelt. GC jaoks tähendab see, et meie mälu kasutuse muster muutub väga kiiresti. Ja seda GC-d, mida me kasutasime, ei suutnud selle ülesandega toime tulla.

Ainus parandamine, mille me leidsime, et muuta klastri käitumist sellises olukorras, oli migratsioon JDK13-le ja Shenandoah prügikogumise kasutamine. See lahendas probleemi, koordinaatorid ei kukkunud enam.

Sellega lõppesid Java probleemid, kuid algasid läbilaskevõime probleemid.

Elasticsearchi "marjad": läbilaskevõime

Läbilaskevõime probleemid tähendavad, et meie klaster töötab stabiilselt, kuid indeksite arvu tipphetkedel ja manööverdusmomentidel ei ole jõudlus piisav.

Esimene kohatud sümptom: tootmises toimuvate

snapshots Graylogis hakkab sageli ilmuma esitusville viga es_rejected_execution. See juhtus sellepärast, et thread_pool.write.queue ühel andmesõlmel, enne kui Elasticsearch suudab indekseerimise päringu töödelda ja informatsiooni diskile kirjutada, suudab vaikimisi vahemällu salvestada ainult 200 päringut. Ja

Elasticsearchi dokumentatsioonis sellest parameetrist räägitakse väga vähe. Käsitletakse ainult ekstreemne arv teid ja vaikimisi suurust. Loomulikult otsustasime seda väärtust muuta ja selgus, et meie seadistuses suudab vahemällu salvestada päris hästi kuni 300 päringut, samas kui suurem väärtus toob meid tagasi Full GC-sse.

Lisaks, kuna need on sõnumipaketid, mis saabuvad ühe päringu raames, pidime Graylogi seadistama nii, et see kirjutaks mitte sageli ja väikeste partiitena, vaid suurte partiitena või iga kolme sekundi järel, kui partii ei ole ikka veel täis. Sellisel juhul muutub teave, mille me Elasticsearch'i kirjutame, kättesaadavaks mitte kahe, vaid viie sekundi pärast (mis meid täiesti rahuldab), ent väheneb ka retrai arv, mida tuleb teha, et edastada suur partii teavet.

See on eriti oluline hetkedel, kui meil midagi kuskil kokku kukub ja sellest agaralt teatatakse, et mitte saada täielikult spämmitud Elasticut, ega saada hiljem — mitte töötavaid Graylogi node'e ummistunud puhvriketaste tõttu.

Lisaks, kui meil toimusid need plahvatused tootmises, saime kaebusi programmeerijatelt ja testijatelt: just siis, kui nad neid logisid väga vajavad, väljastatakse need neile väga aeglaselt.

Hakkasime uurima. Ühel poolt oli selge, et nii otsingupäringud kui ka indekseerimisperioodid töötavad põhimõtteliselt sama füüsilise riistvara peal, ja mingil moel on teatavad langused vältimatud.

Ent seda oli osaliselt võimalik vältida, kuna Elasticsearch'i kuuendas versioonis ilmus algoritm, mis võimaldab jagada päringud asjakohaste andmennodesse mitte juhuslikult round-robin (konteiner, mis tegeleb indekseerimisega ja hoiab primary-shardi, võib olla väga hõivatud, seal ei ole võimalust kiiresti vastata), vaid suunata see päring vähem hõivatud konteinerisse, millel on replica-shard, mis vastab oluliselt kiiremini. Teisisõnu, jõudsime user_adaptive_replica_selection: true juurde.

Lugemise pilt hakkab välja nägema nii:

Selle algoritmi kasutuselevõtt võimaldas oluliselt parandada päringuaega hetkedel, kui meil toimus suur logide kirjutamise voog.

Lõpuks seisnes peamine probleem andmekeskuse valutus väljalülitamises.

Mida me soovisime klastrilt kohe pärast ühenduse kaotamist ühe andmekeskusega:

• Kui meie kadunud andmekeskuses asub praegune master, siis ta valitakse uuesti ja liigub rollina teisele node'ile teises andmekeskuses.
• Master viskab kiiresti kõik kättesaamatud node'id klastrist välja.
• Põhinedes allesjäänud infole, mõistab ta: kadunud andmekeskuses oli meil sellised primary-shardid, kiiresti promoverib ta komplementaarsed replica-shardid allesjäänud andmekeskustes, ja meie andmete indekseerimine jätkub.
• Selle tulemusena hakkab meie klastrite kirjutamis- ja lugemisvõimekus sujuvalt aeglustuma, kuid üldiselt töötab kõik aeglaselt, kuid stabiilselt.

Kuidas selgus, soovisime midagi sellist:

Ja saime järgmist:

Kuidas see juhtus?

Andmekeskuse hukkumise hetkel oli kitsaskohaks meie master.

Miks?

Asi on selles, et masteril on TaskBatcher, mis vastutab teatud ülesannete ja sündmuste levitamise eest klastris. Iga nodi väljalülitamine, iga shard'i edasiviimine replica'st primary'sse, iga ülesanne, mis puudutab shard'i loomist, jõuab esmalt TaskBatcherisse, kus see töödeldakse järjestikku ja ühes voos.

Andmekeskuse väljaviimisel tundus, et kõik ellujäänud andmenodid pidasid oma kohuseks teatada masterile, 'meil on kadunud sellised shardid ja sellised andmenodid'.

Samal ajal saatsid ellujäänud andmenodid kogu selle info senisele masterile ja üritasid oodata kinnitust, et ta oli selle vastu võtnud. Nad ei saanud seda oodata, kuna master sai ülesandeid kiiremini kui jõudis vastata. Noodid kordasid päringuid ajaülevahe tõttu ja samal ajal ei püüdnud master neile isegi vastata, olles täielikult hõivatud päringute prioriteetide järjestamise ülesandega.

Lõppkokkuvõttes tundus, et andmenod spammisid masterit piisavalt, et ta läks täielikku GC-d. Pärast seda kolis master järgmisele nodile, kellel juhtus täpselt sama, ja lõpuks lagunes klaster täielikult.

Me tegime mõõtmisi ja enne versiooni 6.4.0, kus see oli parandatud, piisab meile, kui viia korraga välja vaid 10 andmenodi 360-st, et klaster täielikult maapinda lükata.

See nägi välja umbes nii:

Pärast versiooni 6.4.0, kus see ebameeldiv viga parandati, peatusid andmenod masteri tapmisest. Kuid "nutikam" ta sellest ei saanud. Nimelt: kui me viime välja 2, 3 või 10 (mis tahes arv, mis erineb ühest) andmenodist, saab master mingi esialgse sõnumi, mis ütleb, et nodi A on välja lülitatud, ja püüab rääkida nodist B, nodist C, nodist D.

Ja praegust on sellega võimalik toime tulla vaid seadmisega, kus kellaaegade vahe on 20-30 sekundit, et hallata andmekeskuse klastrist välja viimise kiirus.

Põhimõtteliselt vastab see algselt toodud nõuetele lõpptoote kohta projekti raames, kuid puhta teaduse seisukohalt on see viga. Mis, muide, on edukalt parandatud arendajate poolt versioonis 7.2.

Ja kui mingi andmenode väljus, selgus, et teavet tema väljumise kohta edastada on olulisem kui öelda kogu klastrile, et tal olid sellised primary-shard (et reklaamida replica-shard teises andmekeskuses primaarseks, et sinna saaks kirjutada teavet).

Seetõttu, kui kõik on juba «rahunenud», ei märgita väljunud andmenodeid kohe stale'iks. Seega peame ootama, kuni kõik pinged väljunud nodede peale aeganõudmiseks mööduvad, ja alles seejärel hakkab meie klaster rääkima, et seal, seal ja seal tuleb andmete kirjutamisega jätkata. Pikemalt saab sellest lugeda siin.

Seega, andmekeskuse väljaviimise operatsioon kestab meil täna umbes 5 minutit tipptunnil. Sellise suure ja kohmakana on see üsna hea tulemus.

Seega jõudsime järgmise lahenduseni:

• Meil on 360 andmenode, kus on 700 gigabaidi kettad.
• 60 koordinaatorit liikluse suunamiseks nende andmenode vahel.
• 40 meistrit, mis on meile jäänud kui mingi pärand versioonidest enne 6.4.0 — et üle elada andmekeskuse väljaviimist, olime moraalselt valmis kaotama mõned masinad, et tagada isegi halva stsenaariumi korral meistrite kvoorum.
• Mistahes katsetused rollide ühendamiseks ühes konteineris lõppesid sellega, et varem või hiljem lakkas node koormuse all töötamast.
• Kogu klastris kasutatakse heap.size väärtuses 31 gigabaiti: kõik katsed vähendada suurust viisid selleni, et raskete otsingupäringute puhul, kus on leading wildcard, tapeti mõned nodede, või katkestati circuit breaker ise Elasticsearchis.
• Lisaks, et tagada otsingu jõudlus, püüdsime hoida klastris objektide arvu minimaalne, et töödelda võimalikult vähe sündmusi kitsas kohas, mis meil meistris tekkis.

Lõpetuseks vaatame jälgimist.

Kuna kõik see töötas nagu planeeritud, jälgime järgmist:

• Iga andmekeskuse node teatab meie pilve, et see on olemas ja et seal on sellised shardid. Kui me kustutame midagi kuskil, raporteerib klaster 2-3 sekundi pärast, et keskuses A kustutasime node 2, 3 ja 4 — see tähendab, et teistes andmekeskustes ei tohi mingil juhul kustutada neid node, millel on shardid ainukeses eksemplaris.
• Tundnud meistrite käitumise iseloomu, vaatame väga hoolikalt pending-ülesannete arvu. Sest isegi üks peatunud ülesanne, kui see õigeaegselt mitte ajutuks jääda, võib teoreetiliselt mingis äärmuslikus olukorras olla see põhjus, miks meie, näiteks, ei soorita replica-shardi tõstatamist primaarseks, millega seonduvalt seisab indekseerimine.
• Samuti vaatame väga täpselt garbage collector'i viivitusi, sest meil on olnud sellega juba suuri raskusi optimeerimisel.
• Threadide refuse, et eelnevalt mõista, kus asub „pudelikael”.
• Ja ka standardmõõdikud, nagu heap, RAM ja I/O.

Jälgimise seadmisel tuleb tingimata arvesse võtta Thread Pooli eripära Elasticsearch'is. Elasticsearchi dokumentatsioon kirjeldab seadistamise ja vaikeväärtuste võimalusi otsinguks, indekseerimiseks, kuid jätab täielikult tähelepanuta thread_pool.management. Need threadid töötlevad, sealhulgas, päringud nagu _cat/shards ja teised sarnased, mida on mugav kasutada jälgimise kirjutamisel. Mida suurem on klaster, seda rohkem selliseid päringuid täidetakse ajaühikus, ning eelnevalt mainitud thread_pool.management ei ole mitte ainult esitatud ametlikus dokumentatsioonis, vaid on ka vaikeväärtusena piiratud 5 threadiga, mis kaob väga kiiresti, pärast mida jälgimine lõpetab korrektselt töötamise.

Lõpetuseks tahaksin öelda: meil on see õnnestunud! Oleme suutnud anda meie programmeerijatele ja arendajatele tööriista, mis peaaegu igas olukorras suudab kiiresti ja usaldusväärselt pakkuda teavet selle kohta, mis toimub tootmises.

Jah, see osutus üsna keeruliseks, kuid ometi suutsime meie soovid paigutada juba olemasolevatesse toodetesse, mida ei olnud vaja oma vajadustele kohandada ega ümber kirjutada.

Allikas: habr.com