Elasticsearch is deur baie gebruik. Maar wat gebeur wanneer jy dit wil gebruik om logs "in 'n besonder groot volume" te stoor? Ja, en pynloos die mislukking van enige van verskeie datasentrums oorleef? Watter soort argitektuur moet gedoen word, en op watter slaggate sal jy struikel?
Ons by Odnoklassniki het besluit om die kwessie van logbestuur op te los met behulp van elasticsearch, en nou deel ons ons ervaring met Habr: beide oor argitektuur en oor slaggate.
Ek is Pyotr Zaitsev, ek werk as 'n stelseladministrateur by Odnoklassniki. Voor dit was hy ook 'n admin, het saam met Manticore Search, Sphinx search, Elasticsearch gewerk. Miskien as 'n ander … soektog verskyn, sal ek waarskynlik ook daarmee werk. Ek neem ook op 'n vrywillige basis deel aan 'n aantal oopbronprojekte.
Toe ek by Odnoklassniki kom, het ek roekeloos tydens die onderhoud gesê dat ek met Elasticsearch kan werk. Nadat ek daaraan gewoond geraak het en 'n paar eenvoudige take gedoen het, het ek 'n groot taak gekry om die logbestuurstelsel wat op daardie stadium bestaan het, te hervorm.
Vereistes
Die vereistes vir die stelsel is soos volg geformuleer:
- Graylog was veronderstel om as 'n frontend gebruik te word. Omdat die maatskappy reeds ervaring gehad het met die gebruik van hierdie produk, het programmeerders en toetsers dit geweet, dit was vir hulle bekend en gerieflik.
- Datavolume: gemiddeld 50-80 duisend boodskappe per sekonde, maar as iets breek, word die verkeer deur niks beperk nie, dit kan 2-3 miljoen reëls per sekonde wees
- Nadat ons die vereistes vir die spoed van verwerking van soeknavrae met kliënte bespreek het, het ons besef dat 'n tipiese patroon vir die gebruik van so 'n stelsel dit is: mense soek hul aansoeklogboeke vir die laaste twee dae en wil nie meer as 'n sekonde wag vir 'n resultaat vir 'n geformuleerde navraag.
- Die administrateurs het daarop aangedring dat die stelsel maklik afgeskaal moet word indien nodig, sonder dat hulle nodig het om diep te verstaan hoe dit werk.
- Sodat die enigste instandhoudingstaak wat hierdie stelsels van tyd tot tyd nodig gehad het, was om een of ander soort hardeware te verander.
- Daarbenewens het Odnoklassniki 'n wonderlike tegniese tradisie: enige diens wat ons begin, moet 'n datasentrumfout oorleef (skielik, onbeplan en absoluut te eniger tyd).
Die laaste vereiste in die implementering van hierdie projek is met die grootste bloedvergieting aan ons gegee, waaroor ek in meer besonderhede sal praat.
Woensdag
Ons werk op vier datasentrums, terwyl Elasticsearch-datanodusse slegs in drie geleë kan wees (vir 'n aantal nie-tegniese redes).
In hierdie vier datasentrums is daar ongeveer 18 duisend verskillende bronne van logs - stukke yster, houers, virtuele masjiene.
'n Belangrike kenmerk: die groep word in houers gelanseer nie op fisiese masjiene nie, maar op . Houers word gewaarborg 2 kerns soortgelyk aan 2.0Ghz v4 met die vermoë om die res van die kerns te herwin as hulle ledig is.
Met ander woorde:
Topologie
Die algemene siening van die oplossing het ek aanvanklik soos volg gesien:
- 3-4 BBP's staan agter die A-rekord van die Graylog-domein, dit is die adres waarheen die logs gestuur word.
- elke VIP is 'n LVS-balanseerder.
- Daarna gaan die logs na die Graylog-battery, sommige van die data gaan in die GELF-formaat, sommige in die syslog-formaat.
- Dan word dit alles in groot bondels na die battery van die Elasticsearch-koördineerders geskryf.
- En hulle stuur op hul beurt versoeke vir skryf en lees na die relevante data nodusse.
terminologie
Miskien verstaan nie almal die terminologie in besonderhede nie, daarom wil ek 'n bietjie daaroor stilstaan.
Daar is verskeie tipes nodusse in Elasticsearch - meester, koördineerder, datanodus. Daar is twee ander tipes vir verskillende transformasies van logs en die verbinding van verskillende trosse met mekaar, maar ons het slegs dié wat gelys is, gebruik.
Meester
Dit ping alle nodusse teenwoordig in die groepering, hou 'n bygewerkte troskaart in stand en versprei dit tussen nodusse, verwerk gebeurtenislogika, en doen verskeie soorte troswye huishouding.
Koördineerder
Dit voer een enkele taak uit: dit ontvang versoeke van kliënte vir lees of skryf en lei hierdie verkeer. Indien daar 'n skryfversoek is, sal dit heel waarskynlik vir meester vra watter skerf van die betrokke indeks om dit in te plaas, en die versoek verder herlei.
data nodus
Dit stoor data, voer soeknavrae en bewerkings uit op die skerwe wat daarop geleë is, wat van buite af aankom.
Greylog
Dit is soort van om Kibana met Logstash in die ELK-stapel saam te voeg. Graylog kombineer beide die UI en die logverwerkingspyplyn. Onder die enjinkap bestuur Graylog Kafka en Zookeeper, wat verbinding met Graylog as 'n groep bied. Graylog kan logs (Kafka) kas in die geval van Elasticsearch nie beskikbaar is nie en herhaal onsuksesvolle lees- en skryfversoeke, groepeer en merk logs volgens gespesifiseerde reëls. Soos Logstash, het Graylog die funksionaliteit om stringe te verander voordat dit na Elasticsearch geskryf word.
Daarbenewens het Graylog 'n ingeboude diensontdekking wat dit moontlik maak om, gebaseer op een beskikbare Elasticsearch-nodus, die hele groepkaart te kry en dit deur 'n spesifieke merker te filter, wat dit moontlik maak om versoeke na spesifieke houers te stuur.
Visueel lyk dit so:
Dit is 'n skermskoot van 'n spesifieke geval. Hier bou ons 'n histogram gebaseer op die soeknavraag en vertoon relevante lyne.
Indekse
Om terug te keer na die argitektuur van die stelsel, wil ek in meer besonderhede stilstaan oor hoe ons die indeksmodel gebou het sodat dit alles reg werk.
In die diagram hierbo is dit die laagste vlak: Elasticsearch data nodusse.
'n Indeks is 'n groot virtuele entiteit wat uit Elasticsearch-skerwe bestaan. Op sigself is elkeen van die skerwe niks meer as 'n Lucene-indeks nie. En elke Lucene-indeks bestaan op sy beurt uit een of meer segmente.
Met die ontwerp het ons gereken dat om aan die vereistes vir leesspoed op 'n groot hoeveelheid data te voldoen, ons hierdie data eweredig oor datanodusse moet "smeer".
Dit het daartoe gelei dat die aantal skerwe per indeks (met replikas) streng gelyk moet wees aan die aantal data nodusse. Eerstens, om 'n replikasiefaktor van twee te verseker (dit wil sê, ons kan die helfte van die groep verloor). En, tweedens, om lees- en skryfversoeke op ten minste die helfte van die groep te verwerk.
Ons het die stoortyd eers as 30 dae bepaal.
Die verspreiding van skerwe kan grafies soos volg voorgestel word:
Die hele donkergrys reghoek is die indeks. Die linkerrooi vierkant daarin is die primêre skerf, die eerste in die indeks. En die blou vierkant is 'n replika skerf. Hulle is in verskillende datasentrums geleë.
Wanneer ons nog 'n skerf byvoeg, gaan dit na die derde datasentrum. En op die ou end kry ons so 'n struktuur wat die moontlikheid bied om 'n GS te verloor sonder om datakonsekwentheid te verloor:
Indeksrotasie, m.a.w. deur 'n nuwe indeks te skep en die oudste een uit te vee, het ons dit gelyk aan 48 uur gemaak (volgens die indeksgebruikspatroon: die laaste 48 uur word die meeste gesoek).
Hierdie indeksrotasie-interval is as gevolg van die volgende redes:
Wanneer 'n soekversoek by 'n spesifieke datanodus aankom, dan, uit die oogpunt van prestasie, is dit meer winsgewend wanneer een skerf gepols word as die grootte vergelykbaar is met die grootte van die nodus se heup. Dit laat jou toe om die "warm" deel van die indeks in die hoop te hou en vinnig toegang daartoe te kry. Wanneer daar baie "warm dele" is, verminder die indekssoekspoed.
Wanneer 'n nodus begin om 'n soeknavraag op een skerf uit te voer, ken dit 'n aantal drade toe gelykstaande aan die aantal hiper-gedraaide kerne van die fisiese masjien. As die soeknavraag 'n groot aantal skerwe raak, dan groei die aantal drade proporsioneel. Dit het 'n slegte uitwerking op soekspoed en beïnvloed die indeksering van nuwe data negatief.
Om die nodige soektydperk te verskaf, het ons besluit om 'n SSD te gebruik. Om versoeke vinnig te verwerk, moes die masjiene wat hierdie houers gehuisves het ten minste 56 kerns hê. Die getal 56 word gekies as 'n voorwaardelik voldoende waarde wat die aantal drade bepaal wat Elasticsearch tydens werking sal genereer. In Elasitcsearch is baie draadpoel-parameters direk afhanklik van die aantal beskikbare kerns, wat op sy beurt die vereiste aantal nodusse in die cluster direk beïnvloed volgens die "minder cores - more nodes"-beginsel.
As gevolg hiervan het ons gevind dat 'n skerf gemiddeld ongeveer 20 gigagrepe weeg, en daar is 1 skerwe per 360-indeks. Gevolglik, as ons hulle elke 48 uur roteer, dan het ons 15 van hulle. Elke indeks bevat data vir 2 dae.
Skemas vir die skryf en lees van data
Kom ons kyk hoe data in hierdie stelsel aangeteken word.
Kom ons sê 'n versoek kom van Graylog na die koördineerder. Byvoorbeeld, ons wil 2-3 duisend rye indekseer.
Die koördineerder, nadat hy 'n versoek van Graylog ontvang het, vra die meester: "In die versoek vir indeksering het ons spesifiek die indeks gespesifiseer, maar dit is nie gespesifiseer in watter skerf om dit te skryf nie."
Die meester antwoord: “Skryf hierdie inligting in skerf nommer 71”, waarna dit direk na die betrokke datanodus gestuur word, waar primêre skerf nommer 71 geleë is.
Daarna word die transaksielog na replica-shard gerepliseer, wat reeds in 'n ander datasentrum geleë is.
'n Soekversoek kom van Graylog na die koördineerder. Die koördineerder herlei dit volgens indeks, terwyl Elasticsearch versoeke tussen primêre-skerf en replika-skerf versprei volgens die round-robin-beginsel.
Nodusse in die hoeveelheid van 180 reageer oneweredig, en terwyl hulle reageer, versamel die koördineerder inligting wat vinniger data nodusse reeds daarin "uitgespoeg" het. Daarna, wanneer óf al die inligting opgedaag het, óf 'n time-out op die versoek bereik is, gee dit alles direk aan die kliënt.
Hierdie hele stelsel voldoen gemiddeld aan soekversoeke vir die laaste 48 uur in 300-400ms, uitgesluit die versoeke wat met die voorste jokerteken is.
Blomme met Elasticsearch: Stel Java op
Om dit alles te laat werk soos ons oorspronklik wou hê, het ons baie lank spandeer om 'n wye verskeidenheid dinge in die groep te ontfout.
Die eerste deel van die ontdekte probleme was verwant aan hoe Java by verstek vooraf in Elasticsearch opgestel is.
Probleem een
Ons het 'n baie groot aantal verslae gesien wat ons op die Lucene-vlak het, wanneer agtergrondtake aan die gang is, misluk Lucene-segmentsamesmeltings. Terselfdertyd was dit duidelik in die logs dat dit 'n OutOfMemoryError-fout was. Van telemetrie het ons gesien dat die heup vry was, en dit was nie duidelik hoekom hierdie operasie val nie.
Dit het geblyk dat Lucene-indeksversmeltings buite die heup voorkom. En houers is redelik beperk in terme van verbruikte hulpbronne. Slegs die hoop het in hierdie hulpbronne gepas (die waarde van heap.size was ongeveer gelyk aan RAM), en sommige off-heap-bewerkings het met 'n geheuetoewysingsfout geval as hulle om een of ander rede nie by daardie ~ 500MB pas wat voor die limiet gebly het nie .
Die oplossing was nogal onbenullig: die hoeveelheid RAM beskikbaar vir die houer is verhoog, waarna hulle vergeet het dat ons hoegenaamd sulke probleme het.
Probleem twee
4-5 dae na die bekendstelling van die cluster, het ons opgemerk dat die data nodusse periodiek uit die cluster begin val en dit na 10-20 sekondes binnegaan.
Toe hulle klim om dit uit te vind, het dit geblyk dat hierdie baie af-hoop geheue in Elasticsearch feitlik op geen manier beheer word nie. Toe ons meer geheue aan die houer gegee het, het ons die geleentheid gekry om direkte bufferpoele met verskeie inligting te vul, en dit is eers uitgevee nadat die eksplisiete GC deur Elasticsearch bekendgestel is.
In sommige gevalle het hierdie operasie nogal lank geneem, en gedurende hierdie tyd het die groep daarin geslaag om hierdie nodus as reeds vrygestel te merk. Hierdie kwessie is goed beskryf. .
Die oplossing was soos volg: ons het Java se vermoë beperk om die grootste deel van die geheue buite die hoop vir hierdie bewerkings te gebruik. Ons het dit beperk tot 16 gigagrepe (-XX:MaxDirectMemorySize=16g), om te verseker dat eksplisiete GC baie meer gereeld geroep is, en baie vinniger uitgewerk is, en daardeur ophou om die groep te destabiliseer.
Probleem drie
As jy dink dat die probleme met "nodes wat die groep op die mees onverwagte oomblik verlaat" verby is, is jy verkeerd.
Toe ons die werk met indekse gekonfigureer het, het ons gekies vir mmapfs om dit te doen op vars skerwe met hoë segmentasie. Dit was 'n nogal growwe fout, want wanneer mmapfs gebruik word, word die lêer in RAM gekarteer, en dan werk ons met die gekarteerde lêer. As gevolg hiervan, blyk dit dat wanneer die GC die drade in die toepassing probeer stop, ons vir 'n baie lang tyd na safepoint gaan, en op pad daarna, hou die toepassing op om op die towenaar se versoeke te reageer oor of dit lewendig is. . Gevolglik glo meester dat die nodus nie meer in ons groepie teenwoordig is nie. Daarna, na 5-10 sekondes, werk die vullisverwyderaar uit, die nodus word lewendig, gaan weer die groep binne en begin die skerwe inisialiseer. Dit alles het sterk gelyk na die “produksie wat ons verdien” en was nie geskik vir enigiets ernstigs nie.
Om van hierdie gedrag ontslae te raak, het ons eers oorgeskakel na die standaard niofs, en toe, toe ons van die vyfde weergawes van Elastic na die sesde migreer, het ons hybridfs probeer, waar hierdie probleem nie gereproduseer is nie. Jy kan meer lees oor tipes berging .
Probleem vier
Dan was daar nog 'n baie vermaaklike probleem wat ons vir 'n rekord lank behandel het. Ons het haar vir 2-3 maande gevang, want haar patroon was absoluut onverstaanbaar.
Soms het ons koördineerders na Full GC gegaan, gewoonlik iewers in die middag, en nooit daarvandaan teruggekeer nie. Terselfdertyd, toe die GC-vertraging aangeteken is, het dit so gelyk: alles gaan goed met ons, wel, wel, en dan een keer - en alles is skerp sleg.
Aanvanklik het ons gedink dat ons 'n bose gebruiker het wat 'n soort versoek loods wat die koördineerder uit die werkmodus slaan. Ons het versoeke vir 'n baie lang tyd aangeteken en probeer uitvind wat gebeur het.
As gevolg hiervan het dit geblyk dat sommige nodusse langer reageer as ander op die oomblik wanneer sommige gebruiker 'n groot versoek loods, en dit 'n spesifieke Elasticsearch-koördineerder tref.
En terwyl die koördineerder wag vir die reaksie van al die nodusse, versamel hy in homself die resultate wat gestuur word vanaf die nodusse wat reeds gereageer het. Vir die GC beteken dit dat ons heupgebruikspatroon baie vinnig verander. En die GC wat ons gebruik het kon nie hierdie taak hanteer nie.
Die enigste oplossing wat ons gevind het om die gedrag van die groepie in hierdie situasie te verander, is om na JDK13 te migreer en die Shenandoah-vullisverwyderaar te gebruik. Dit het die probleem opgelos, ons koördineerders het opgehou val.
Dit is waar die probleme met Java geëindig het en die probleme met bandwydte begin het.
"Berries" met Elasticsearch: deurset
Deurvloeiprobleme beteken dat ons groep stabiel is, maar op die hoogtepunt van die aantal geïndekseerde dokumente en ten tye van maneuvers is die prestasie onvoldoende.
Die eerste simptoom wat ek teëgekom het: tydens 'n soort "ontploffings" in produksie, wanneer 'n baie groot aantal logs skielik gegenereer word, flits die es_rejected_execution indekseringsfout dikwels in Graylog.
Dit was te wyte aan die feit dat die thread_pool.write.queue op een data nodus totdat Elasticsearch in staat is om die indeksversoek te verwerk en die inligting in die skerf op skyf te gooi, by verstek slegs 200 versoeke kan kas. En in baie min word oor hierdie parameter gesê. Slegs die limiet aantal drade en die verstekgrootte word aangedui.
Natuurlik het ons hierdie waarde gaan draai en die volgende uitgevind: spesifiek, in ons opstelling, is tot 300 versoeke redelik goed gekas, en 'n groter waarde is belaai met die feit dat ons weer wegvlieg na Full GC.
Daarbenewens, aangesien dit bondels boodskappe is wat binne 'n enkele versoek aankom, was dit ook nodig om Graylog aan te pas sodat dit nie gereeld en in klein bondels skryf nie, maar in groot bondels of elke 3 sekondes as die bondel nog nie vol is nie. In hierdie geval blyk dit dat die inligting wat ons in Elasticsearch skryf nie na twee sekondes beskikbaar word nie, maar na vyf (wat ons baie goed pas), maar die aantal terugtrekkings wat gedoen moet word om 'n groot bondel inligting te stoot afneem.
Dit is veral belangrik op daardie oomblikke wanneer iets iewers neergestort het en woedend daaroor berig, om nie Elastic heeltemal gespam te kry nie, en na 'n rukkie - Graylog-nodusse wat nie werk nie as gevolg van verstopte buffers.
Daarbenewens, toe ons hierdie einste ontploffings in produksie gehad het, het ons klagtes van programmeerders en toetsers ontvang: op die oomblik wanneer hulle hierdie logs regtig nodig het, word dit baie stadig aan hulle uitgereik.
Hulle het begin verstaan. Aan die een kant was dit duidelik dat beide soeknavrae en indekseringsnavrae verwerk word, in werklikheid op dieselfde fisiese masjiene, en op een of ander manier sal daar sekere onttrekkings wees.
Maar dit kan gedeeltelik omseil word as gevolg van die feit dat in die sesde weergawes van Elasticsearch 'n algoritme verskyn het wat jou toelaat om versoeke te versprei tussen relevante data nodusse nie volgens die ewekansige round-robin beginsel (die houer wat die primêre skerf indekseer en hou) baie besig kan wees, sal daar geen manier wees om vinnig te reageer nie), maar om hierdie versoek na 'n minder gelaaide houer met replika-skerf te stuur, wat aansienlik vinniger sal reageer. Met ander woorde, ons het geëindig met use_adaptive_replica_selection: true.
Die leesprent begin so lyk:
Die oorgang na hierdie algoritme het ons in staat gestel om die navraagtyd merkbaar te verbeter in daardie oomblikke toe ons 'n groot stroom logboeke gehad het om te skryf.
Ten slotte was die hoofprobleem die pynlose verwydering van die datasentrum.
Wat ons van die groep wou hê onmiddellik na die verlies van kommunikasie met een DC:
- As ons die huidige meester in die gevalle datasentrum het, sal dit herkies word en as 'n rol na 'n ander nodus in 'n ander DC geskuif word.
- Die meester sal vinnig alle ontoeganklike nodusse uit die groep uitskop.
- Op grond van die res sal hy verstaan: in die verlore datasentrum het ons sulke en sulke primêre skerwe gehad, hy sal vinnig komplementêre replika-skerwe in die oorblywende datasentrums bevorder, en ons sal voortgaan om data te indekseer.
- As gevolg hiervan sal die groepbandwydte vir skryf en lees glad afneem, maar oor die algemeen sal alles werk, alhoewel stadig, maar bestendig.
Soos dit geblyk het, wou ons iets soos hierdie hê:
En het die volgende gekry:
Hoe het dit gebeur?
Ten tyde van die val van die datasentrum het die meester die bottelnek vir ons geword.
Hoekom?
Die feit is dat die towenaar 'n TaskBatcher het wat verantwoordelik is vir die verspreiding van sekere take en gebeure in die groepering. Enige nodus-uitset, enige bevordering van 'n skerf van replika na primêre, enige taak om 'n soort skerf iewers te skep - dit alles kom eers in die TaskBatcher, waar dit opeenvolgend en in een draad verwerk word.
Ten tyde van die onttrekking van een datasentrum, het dit geblyk dat alle data nodusse in die oorlewende datasentrums dit hul plig beskou het om die meester in te lig "ons het sulke en sulke skerwe en sulke en sulke data nodusse verloor."
Terselfdertyd het die oorlewende data nodusse al hierdie inligting na die huidige meester gestuur en probeer wag vir bevestiging dat hy dit aanvaar het. Hulle het dit nie verwag nie, aangesien die meester take vinniger ontvang het as wat hy tyd gehad het om te beantwoord. Die nodusse het versoeke herhaal volgens time-out, en die meester op daardie tydstip het nie eers probeer om dit te beantwoord nie, maar was heeltemal opgeneem in die taak om versoeke volgens prioriteit te sorteer.
In die terminale vorm het dit geblyk dat die data nodusse die meester gestrooi het tot die punt dat hy in volle GC ingegaan het. Daarna het die rol van die meester na 'n volgende nodus verskuif, absoluut dieselfde ding het daarmee gebeur, en as gevolg daarvan het die groep heeltemal uitmekaar geval.
Ons het metings gedoen, en voor weergawe 6.4.0, waar dit reggestel is, was dit genoeg vir ons om terselfdertyd slegs 10 uit 360 data nodusse te onttrek om die groep heeltemal te plaas.
Dit het so iets gelyk:
Na weergawe 6.4.0, waar hierdie vreemde fout reggestel is, het die data nodusse opgehou om die meester dood te maak. Maar dit het hom nie slimmer gemaak nie. Naamlik: wanneer ons 2, 3 of 10 (enige getal anders as een) data nodusse uitvoer, ontvang die meester een of ander eerste boodskap wat sê dat nodus A verlaat het, en probeer om node B, node C, node D te vertel.
En op die oomblik kan dit net hanteer word deur 'n tydsduur te stel vir pogings om iemand van iets te vertel, gelykstaande aan iewers rondom 20-30 sekondes, en sodoende die spoed van die onttrekking van die datasentrum uit die groepering te beheer.
In beginsel pas dit in by die vereistes wat oorspronklik binne die raamwerk van die projek vir die finale produk gestel is, maar vanuit die oogpunt van "suiwer wetenskap" is dit 'n gogga. Wat, terloops, suksesvol deur die ontwikkelaars in weergawe 7.2 reggestel is.
Boonop, toe 'n sekere datanodus uitgekom het, het dit geblyk dat die verspreiding van inligting oor sy uitgang belangriker was as om die hele groepie te vertel dat dit so en so 'n primêre skerf het (om 'n replika-skerf in 'n ander datasentrum te bevorder in die primêre, en in hulle kon inligting skryf).
Daarom, wanneer alles reeds dood is, word die vrygestelde data nodusse nie onmiddellik as verouderd gemerk nie. Gevolglik word ons gedwing om te wag totdat alle pings uitgetel is voordat die data nodusse vrygestel word, en eers daarna begin ons cluster praat oor die feit dat daar, daar en daar dit nodig is om voort te gaan om inligting op te neem. Jy kan meer hieroor lees .
Gevolglik neem die operasie om die datasentrum vandag te onttrek ons ongeveer 5 minute in spitstyd. Vir so 'n groot en lomp kolos is dit 'n redelik goeie resultaat.
As gevolg hiervan het ons tot die volgende oplossing gekom:
- Ons het 360 data nodusse met 700 gigagreep skywe.
- 60 koördineerders vir die roetering van verkeer op dieselfde data nodusse.
- 40 meesters wat ons nagelaat het as 'n soort nalatenskap uit die tyd van weergawes voor 6.4.0 - om die onttrekking van die datasentrum te oorleef, was ons geestelik voorbereid om verskeie masjiene te verloor om 'n kworum van meesters te waarborg, selfs in die ergste scenario
- Enige pogings om rolle op een houer saam met ons te kombineer het berus op die feit dat vroeër of later die nodus onder vrag gebreek het.
- Die hele groepering gebruik heap.size gelykstaande aan 31 gigagrepe: alle pogings om die grootte te verminder het gelei tot die feit dat swaar soeknavrae met 'n leidende jokerteken óf sommige nodusse doodgemaak het óf 'n stroombreker in Elasticsearch self doodgemaak het.
- Daarbenewens, om soekprestasie te verseker, het ons probeer om die aantal voorwerpe in die groep so klein as moontlik te hou om so min moontlik gebeure by die bottelnek wat ons in die towenaar gekry het, te verwerk.
Een laaste ding oor monitering
Om dit alles te laat werk soos bedoel, monitor ons die volgende:
- Elke datanodus rapporteer aan ons wolk dat dit bestaan, en daar is sulke en sulke skerwe daarop. Wanneer ons iets iewers blus, rapporteer die groepie na 2-3 sekondes dat ons in sentrum A nodus 2, 3 en 4 geblus het - dit beteken dat ons in ander datasentrums nie daardie nodusse met net een skerf oor kan blus nie.
- As ons die gedrag van die meester ken, kyk ons baie noukeurig na die aantal hangende take. Want selfs een opgehang taak, as dit nie betyds uittel nie, kan teoreties, in een of ander noodsituasie, die rede word waarom, byvoorbeeld, die bevordering van 'n replika-skerf in die primêre nie vir ons werk nie, wat sal stop. indeksering.
- Ons kyk ook baie mooi na die vertragings van die vullisverwyderaar, want ons het reeds groot probleme hiermee gehad met die optimalisering.
- Ryg verwerpings om vooraf te verstaan waar die "bottelnek" is.
- Wel, standaard statistieke soos heap, RAM en I/O.
Wanneer u monitering bou, moet u die kenmerke van die Thread Pool in Elasticsearch in ag neem. beskryf die instellings en verstekwaardes vir soek, indeksering, maar is heeltemal stil oor thread_pool.management. Hierdie drade verwerk veral versoeke soos _cat/shards en ander soortgelyke wat gerieflik is om te gebruik wanneer monitering geskryf word. Hoe groter die cluster, hoe meer word sulke versoeke per tydseenheid uitgevoer, en die voorgenoemde thread_pool.management word nie net nie in die amptelike dokumentasie aangebied nie, maar word ook by verstek beperk tot 5 drade, wat baie vinnig benut word, waarna die monitering hou op om korrek te werk.
Wat ek ten slotte wil sê: ons het geslaag! Ons het daarin geslaag om ons programmeerders en ontwikkelaars 'n instrument te gee wat vinnig en betroubaar inligting kan verskaf oor wat in produksie in byna enige situasie gebeur.
Ja, dit blyk nogal moeilik te wees, maar ons het nietemin daarin geslaag om ons wenslys in bestaande produkte in te pas, wat terselfdertyd nie vir onsself gelap en herskryf hoef te word nie.
Bron: will.com