Veel mensen worstelen met Elasticsearch. Maar wat gebeurt er als u het wilt gebruiken om logbestanden “in een bijzonder groot volume” op te slaan? En is het ook pijnloos om te ervaren dat een van de verschillende datacenters uitvalt? Wat voor architectuur moet je maken en welke valkuilen kom je tegen?
Wij bij Odnoklassniki hebben besloten om elasticsearch te gebruiken om het probleem van logbeheer op te lossen, en nu delen we onze ervaringen met Habr: zowel over architectuur als over valkuilen.
Ik ben Pyotr Zaitsev, ik werk als systeembeheerder bij Odnoklassniki. Daarvoor was ik ook beheerder en werkte ik met Manticore Search, Sphinx search, Elasticsearch. Misschien, als er een andere ...zoekopdracht verschijnt, zal ik er waarschijnlijk ook mee werken. Daarnaast neem ik op vrijwillige basis deel aan een aantal open source projecten.
Toen ik bij Odnoklassniki kwam, zei ik roekeloos tijdens het interview dat ik met Elasticsearch kon werken. Nadat ik het onder de knie had en enkele eenvoudige taken had voltooid, kreeg ik de grote taak om het logbeheersysteem dat toen bestond, te hervormen.
Eisen
De systeemeisen zijn als volgt geformuleerd:
- Graylog zou als frontend worden gebruikt. Omdat het bedrijf al ervaring had met het gebruik van dit product, wisten programmeurs en testers het, het was vertrouwd en handig voor hen.
- Datavolume: gemiddeld 50-80 duizend berichten per seconde, maar als er iets kapot gaat, wordt het verkeer nergens door beperkt, het kan 2-3 miljoen regels per seconde zijn
- Nadat we met klanten de vereisten voor de snelheid van het verwerken van zoekopdrachten hadden besproken, realiseerden we ons dat het typische patroon bij het gebruik van een dergelijk systeem dit is: mensen zoeken naar logbestanden van hun applicatie van de afgelopen twee dagen en willen niet langer dan een paar dagen wachten. ten tweede voor het resultaat van een geformuleerde vraag.
- De beheerders stonden erop dat het systeem indien nodig eenvoudig schaalbaar zou zijn, zonder dat ze zich diep hoefden te verdiepen in de werking ervan.
- Zodat de enige onderhoudstaak die deze systemen periodiek nodig hebben, het vervangen van bepaalde hardware is.
- Bovendien heeft Odnoklassniki een uitstekende technische traditie: elke dienst die we lanceren moet een datacenterstoring overleven (plotseling, ongepland en absoluut op elk moment).
De laatste vereiste bij de implementatie van dit project kostte ons het meeste, waarover ik meer in detail zal praten.
woensdag
We werken in vier datacenters, terwijl Elasticsearch-dataknooppunten zich slechts in drie datacentra kunnen bevinden (om een aantal niet-technische redenen).
Deze vier datacenters bevatten ongeveer 18 verschillende logbronnen: hardware, containers, virtuele machines.
Belangrijk kenmerk: het cluster start in containers niet op fysieke machines, maar op . Containers hebben gegarandeerd 2 cores, vergelijkbaar met 2.0Ghz v4, met de mogelijkheid om de resterende cores te recyclen als ze niet actief zijn.
Met andere woorden:
Topologie
Ik zag aanvankelijk de algemene vorm van de oplossing als volgt:
- Achter het A-record van het Graylog-domein staan 3-4 VIP’s, dit is het adres waar de logs naartoe worden gestuurd.
- elke VIP is een LVS-balancer.
- Hierna gaan de logs naar de Graylog-batterij, sommige gegevens zijn in GELF-formaat, sommige in syslog-formaat.
- Vervolgens wordt dit alles in grote batches naar een batterij Elasticsearch-coördinatoren geschreven.
- En zij sturen op hun beurt schrijf- en leesverzoeken naar de relevante dataknooppunten.
terminologie
Misschien begrijpt niet iedereen de terminologie in detail, dus ik wil er graag even bij stilstaan.
Elasticsearch heeft verschillende soorten knooppunten: master, coördinator, dataknooppunt. Er zijn twee andere typen voor verschillende logboektransformaties en communicatie tussen verschillende clusters, maar we hebben alleen de genoemde typen gebruikt.
Master
Het pingt alle knooppunten in het cluster, houdt een actuele clusterkaart bij en verdeelt deze tussen knooppunten, verwerkt gebeurtenislogica en voert verschillende soorten clusterbrede huishouding uit.
Coördinator
Voert één enkele taak uit: accepteert lees- of schrijfverzoeken van clients en routeert dit verkeer. Als er een schrijfverzoek is, zal het de master hoogstwaarschijnlijk vragen in welke shard van de relevante index het het verzoek moet plaatsen, en het verzoek verder doorsturen.
Gegevensknooppunt
Slaat gegevens op, voert zoekopdrachten uit die van buitenaf binnenkomen en voert bewerkingen uit op shards die zich daarop bevinden.
grijslog
Dit is zoiets als een fusie van Kibana met Logstash in een ELK-stack. Graylog combineert zowel een gebruikersinterface als een pijplijn voor logboekverwerking. Onder de motorkap draait Graylog Kafka en Zookeeper, die als cluster connectiviteit met Graylog bieden. Graylog kan logs (Kafka) in de cache opslaan voor het geval Elasticsearch niet beschikbaar is en mislukte lees- en schrijfverzoeken herhalen, logs groeperen en markeren volgens gespecificeerde regels. Net als Logstash heeft Graylog functionaliteit om rijen aan te passen voordat ze naar Elasticsearch worden geschreven.
Bovendien heeft Graylog een ingebouwde service-discovery waarmee, op basis van één beschikbaar Elasticsearch-knooppunt, de volledige clusterkaart kan worden verkregen en deze kan worden gefilterd op een specifieke tag, waardoor verzoeken naar specifieke containers kunnen worden gericht.
Visueel ziet het er ongeveer zo uit:
Dit is een screenshot van een specifiek exemplaar. Hier bouwen we een histogram op basis van de zoekopdracht en geven we relevante rijen weer.
Index
Terugkerend naar de systeemarchitectuur zou ik graag dieper willen ingaan op de manier waarop we het indexmodel hebben gebouwd, zodat het allemaal correct werkte.
In het bovenstaande diagram is dit het laagste niveau: Elasticsearch-dataknooppunten.
Een index is een grote virtuele entiteit die bestaat uit Elasticsearch-shards. Op zichzelf is elk van de scherven niets meer dan een Lucene-index. En elke Lucene-index bestaat op zijn beurt uit een of meer segmenten.
Bij het ontwerpen bedachten we dat we, om aan de eis van leessnelheid voor een grote hoeveelheid gegevens te voldoen, deze gegevens gelijkmatig over de dataknooppunten moesten ‘verspreiden’.
Dit resulteerde in het feit dat het aantal shards per index (bij replica’s) strikt gelijk moest zijn aan het aantal dataknooppunten. Ten eerste om een replicatiefactor gelijk aan twee te garanderen (dat wil zeggen dat we de helft van het cluster kunnen verliezen). En ten tweede om lees- en schrijfverzoeken op ten minste de helft van het cluster te verwerken.
We hebben eerst de bewaartijd vastgesteld op 30 dagen.
De verdeling van scherven kan als volgt grafisch worden weergegeven:
De gehele donkergrijze rechthoek is een index. Het linker rode vierkant daarin is de primaire scherf, de eerste in de index. En het blauwe vierkant is een replica van een scherf. Ze bevinden zich in verschillende datacenters.
Wanneer we nog een scherf toevoegen, gaat deze naar het derde datacenter. En uiteindelijk krijgen we deze structuur, die het mogelijk maakt om DC te verliezen zonder de dataconsistentie te verliezen:
Rotatie van indexen, d.w.z. Door een nieuwe index te maken en de oudste te verwijderen, hebben we deze gelijk gemaakt aan 48 uur (volgens het patroon van indexgebruik: de laatste 48 uur worden het vaakst doorzocht).
Dit indexrotatie-interval heeft de volgende redenen:
Wanneer een zoekopdracht bij een specifiek dataknooppunt terechtkomt, is het vanuit prestatieoogpunt winstgevender wanneer één shard wordt opgevraagd, als de grootte ervan vergelijkbaar is met de grootte van de heup van het knooppunt. Hierdoor kunt u het ‘hot’ deel van de index op een hoop houden en er snel toegang toe krijgen. Als er veel ‘hot parts’ zijn, neemt de snelheid van het zoeken naar indexen af.
Wanneer een knooppunt een zoekopdracht op één shard begint uit te voeren, wijst het een aantal threads toe dat gelijk is aan het aantal hyperthreading-kernen van de fysieke machine. Als een zoekopdracht een groot aantal shards beïnvloedt, groeit het aantal threads proportioneel. Dit heeft een negatieve invloed op de zoeksnelheid en heeft een negatieve invloed op het indexeren van nieuwe gegevens.
Om de nodige zoeklatentie te bieden, hebben we besloten een SSD te gebruiken. Om verzoeken snel te kunnen verwerken, moesten de machines die deze containers hostten minimaal 56 cores hebben. Het getal 56 werd gekozen als een voorwaardelijk voldoende waarde die het aantal threads bepaalt dat Elasticsearch tijdens bedrijf zal genereren. In Elasitcsearch zijn veel threadpoolparameters rechtstreeks afhankelijk van het aantal beschikbare kernen, wat op zijn beurt rechtstreeks van invloed is op het vereiste aantal knooppunten in het cluster volgens het principe “minder kernen - meer knooppunten”.
Als gevolg hiervan ontdekten we dat een scherf gemiddeld ongeveer 20 gigabyte weegt, en dat er 1 scherven per index zijn. Als we ze dus eens in de 360 uur rouleren, dan hebben we er 48. Elke index bevat gegevens voor 15 dagen.
Circuits voor het schrijven en lezen van gegevens
Laten we eens kijken hoe gegevens in dit systeem worden vastgelegd.
Stel dat er een verzoek van Graylog bij de coördinator binnenkomt. We willen bijvoorbeeld 2-3 duizend rijen indexeren.
De coördinator, die een verzoek van Graylog heeft ontvangen, ondervraagt de meester: "In het indexeringsverzoek hebben we specifiek een index gespecificeerd, maar in welke scherf deze moest worden geschreven, was niet gespecificeerd."
De master antwoordt: “Schrijf deze informatie naar shardnummer 71”, waarna deze direct naar het betreffende dataknooppunt wordt gestuurd, waar primair-shardnummer 71 zich bevindt.
Waarna het transactielogboek wordt gerepliceerd naar een replica-shard, die zich in een ander datacenter bevindt.
Er komt een zoekopdracht van Graylog binnen bij de coördinator. De coördinator stuurt het om volgens de index, terwijl Elasticsearch verzoeken verdeelt tussen de primaire shard en de replica-shard met behulp van het round-robin-principe.
De 180 knooppunten reageren ongelijkmatig, en terwijl ze reageren, verzamelt de coördinator informatie die al is ‘uitgespuugd’ door snellere dataknooppunten. Hierna, wanneer alle informatie is aangekomen of het verzoek een time-out heeft bereikt, wordt alles rechtstreeks aan de klant gegeven.
Dit hele systeem verwerkt zoekopdrachten van de afgelopen 48 uur gemiddeld in 300-400 ms, met uitzondering van zoekopdrachten met een leidend jokerteken.
Bloemen met Elasticsearch: Java-installatie
Om het allemaal te laten werken zoals we oorspronkelijk wilden, hebben we heel veel tijd besteed aan het debuggen van een grote verscheidenheid aan dingen in het cluster.
Het eerste deel van de ontdekte problemen had te maken met de manier waarop Java standaard vooraf is geconfigureerd in Elasticsearch.
Probleem één
We hebben een zeer groot aantal rapporten waargenomen dat op Lucene-niveau, wanneer achtergrondtaken worden uitgevoerd, de samenvoeging van Lucene-segmenten mislukt met een fout. Tegelijkertijd was het duidelijk in de logboeken dat dit een OutOfMemoryError-fout was. Uit telemetrie zagen we dat de heup vrij was en het was niet duidelijk waarom deze operatie mislukte.
Het bleek dat de samenvoegingen van de Lucene-index buiten de heup plaatsvinden. En containers zijn vrij strikt beperkt in termen van verbruikte hulpbronnen. Alleen heap kon in deze bronnen passen (de waarde heap.size was ongeveer gelijk aan RAM), en sommige off-heap-bewerkingen crashten met een geheugentoewijzingsfout als ze om de een of andere reden niet pasten in de ~500 MB die vóór de limiet bleef.
De oplossing was vrij triviaal: de hoeveelheid RAM die beschikbaar was voor de container werd vergroot, waarna we vergaten dat we zelfs dergelijke problemen hadden.
Probleem twee
4-5 dagen na de lancering van het cluster merkten we dat dataknooppunten periodiek uit het cluster begonnen te vallen en deze na 10-20 seconden binnenkwamen.
Toen we het begonnen uit te zoeken, bleek dat dit off-heap-geheugen in Elasticsearch op geen enkele manier wordt beheerd. Toen we meer geheugen aan de container gaven, konden we de directe bufferpools vullen met verschillende informatie, en deze werd pas gewist nadat de expliciete GC vanuit Elasticsearch was gelanceerd.
In sommige gevallen duurde deze bewerking behoorlijk lang en gedurende deze tijd slaagde het cluster erin dit knooppunt als al verlaten te markeren. Dit probleem is goed beschreven .
De oplossing was als volgt: we beperkten de mogelijkheden van Java om het grootste deel van het geheugen buiten de heap voor deze bewerkingen te gebruiken. We hebben dit beperkt tot 16 gigabyte (-XX:MaxDirectMemorySize=16g), waardoor expliciete GC veel vaker werd aangeroepen en veel sneller werd verwerkt, waardoor het cluster niet langer werd gedestabiliseerd.
Probleem drie
Als je denkt dat de problemen met “nodes die op het meest onverwachte moment het cluster verlaten” voorbij zijn, heb je het mis.
Toen we het werk met indexen configureerden, kozen we voor mmapfs op verse scherven met grote segmentatie. Dit was een behoorlijke blunder, want bij het gebruik van mmapfs wordt het bestand in het RAM toegewezen, en dan werken we met het toegewezen bestand. Hierdoor blijkt dat wanneer de GC threads in de applicatie probeert te stoppen, we heel lang naar het safepoint gaan, en op weg ernaartoe stopt de applicatie met reageren op de verzoeken van de master of deze nog leeft . Dienovereenkomstig is de master van mening dat het knooppunt niet langer aanwezig is in het cluster. Hierna, na 5-10 seconden, werkt de garbage collector, komt het knooppunt tot leven, komt het cluster weer binnen en begint met het initialiseren van shards. Het voelde allemaal heel erg als “de productie die we verdienden” en was niet geschikt voor iets serieus.
Om van dit gedrag af te komen, zijn we eerst overgestapt op standaard niofs, en toen we van de vijfde versie van Elastic naar de zesde migreerden, probeerden we hybridfs, waarbij dit probleem niet werd gereproduceerd. U kunt meer lezen over opslagtypen .
Probleem vier
Dan was er nog een heel interessant probleem dat we in recordtijd hebben behandeld. We hebben hem 2-3 maanden gevangen omdat het patroon absoluut onbegrijpelijk was.
Soms gingen onze coördinatoren naar Full GC, meestal ergens na de lunch, en kwamen daar nooit meer terug. Tegelijkertijd zag het er bij het loggen van de GC-vertraging zo uit: alles gaat goed, nou, nou, en dan gaat alles opeens heel slecht.
In eerste instantie dachten we dat we te maken hadden met een kwaadaardige gebruiker die een verzoek lanceerde waardoor de coördinator uit de werkmodus werd gehaald. We hebben heel lang verzoeken geregistreerd, in een poging erachter te komen wat er aan de hand was.
Als gevolg hiervan bleek dat op het moment dat een gebruiker een groot verzoek lanceert en dit bij een specifieke Elasticsearch-coördinator terechtkomt, sommige knooppunten langer reageren dan andere.
En terwijl de coördinator wacht op een antwoord van alle knooppunten, verzamelt hij de resultaten die zijn verzonden door de knooppunten die al hebben gereageerd. Voor GC betekent dit dat onze heapgebruikspatronen zeer snel veranderen. En de GC die we gebruikten kon deze taak niet aan.
De enige oplossing die we hebben gevonden om het gedrag van het cluster in deze situatie te veranderen, is migratie naar JDK13 en het gebruik van de Shenandoah garbage collector. Dit loste het probleem op, onze coördinatoren stopten met vallen.
Dit is waar de problemen met Java eindigden en de bandbreedteproblemen begonnen.
"Bessen" met Elasticsearch: doorvoer
Problemen met de doorvoer zorgen ervoor dat ons cluster stabiel werkt, maar bij pieken in het aantal geïndexeerde documenten en tijdens manoeuvres is de prestatie onvoldoende.
Het eerste symptoom dat we tegenkwamen: tijdens sommige “explosies” in de productie, wanneer er plotseling een zeer groot aantal logs wordt gegenereerd, begint de indexeringsfout es_rejected_execution regelmatig te knipperen in Graylog.
Dit was te wijten aan het feit dat thread_pool.write.queue op één gegevensknooppunt, tot het moment waarop Elasticsearch het indexeringsverzoek kan verwerken en de informatie naar de shard op schijf kan uploaden, standaard slechts 200 verzoeken in de cache kan opslaan. En in Er wordt heel weinig over deze parameter gezegd. Alleen het maximale aantal draden en de standaardgrootte worden aangegeven.
Natuurlijk hebben we deze waarde verdraaid en ontdekten we het volgende: in onze configuratie worden tot 300 verzoeken behoorlijk goed in de cache opgeslagen, en een hogere waarde is beladen met het feit dat we opnieuw naar Full GC vliegen.
Omdat dit batches berichten zijn die binnen één verzoek binnenkomen, was het bovendien nodig om Graylog zo aan te passen dat het niet vaak en in kleine batches schrijft, maar in grote batches of eenmaal per 3 seconden als de batch nog steeds niet compleet is. In dit geval blijkt dat de informatie die we in Elasticsearch schrijven niet in twee seconden beschikbaar komt, maar in vijf (wat ons goed uitkomt), maar het aantal retrays dat moet worden gemaakt om een grote stapel informatie wordt verminderd.
Dit is vooral belangrijk op die momenten dat er ergens iets is gecrasht en er woedend over rapporteert, om niet een volledig gespamde Elastic te krijgen, en na enige tijd - Graylog-knooppunten die onbruikbaar zijn vanwege verstopte buffers.
Bovendien ontvingen we, toen we dezelfde explosies in de productie hadden, klachten van programmeurs en testers: op het moment dat ze deze logs echt nodig hadden, kregen ze ze heel langzaam.
Ze begonnen het uit te zoeken. Aan de ene kant was het duidelijk dat zowel zoekopdrachten als indexquery's in wezen op dezelfde fysieke machines werden verwerkt, en dat er op de een of andere manier bepaalde vertragingen zouden optreden.
Maar dit kon gedeeltelijk worden omzeild vanwege het feit dat in de zesde versie van Elasticsearch een algoritme verscheen waarmee je zoekopdrachten kunt verdelen tussen relevante dataknooppunten, niet volgens het willekeurige round-robin-principe (de container die indexeert en de primaire gegevens bevat). -shard kan erg druk zijn, er is geen manier om snel te reageren), maar om dit verzoek door te sturen naar een minder geladen container met een replica-shard, die veel sneller zal reageren. Met andere woorden, we zijn aangekomen bij use_adaptive_replica_selection: true.
Het leesbeeld begint er als volgt uit te zien:
De overstap naar dit algoritme maakte het mogelijk om de querytijd aanzienlijk te verbeteren op de momenten dat we een grote stroom aan logs moesten schrijven.
Het grootste probleem ten slotte was de pijnloze verwijdering van het datacenter.
Wat we wilden van het cluster onmiddellijk nadat de verbinding met één DC was verbroken:
- Als we een huidige master in het defecte datacenter hebben, wordt deze opnieuw geselecteerd en als rol verplaatst naar een ander knooppunt in een ander DC.
- De master verwijdert snel alle ontoegankelijke knooppunten uit het cluster.
- Op basis van de overgebleven data zal hij het begrijpen: in het verloren datacenter hadden we zulke en die primaire scherven, hij zal snel complementaire replica-scherven promoten in de resterende datacentra, en we zullen doorgaan met het indexeren van de gegevens.
- Als gevolg hiervan zal de schrijf- en leesdoorvoer van het cluster geleidelijk afnemen, maar over het algemeen zal alles werken, zij het langzaam maar stabiel.
Het bleek dat we zoiets als dit wilden:
En wij kregen het volgende:
Hoe is het gebeurd?
Toen het datacenter viel, werd onze meester het knelpunt.
Waarom?
Feit is dat de master een TaskBatcher heeft, die verantwoordelijk is voor het distribueren van bepaalde taken en gebeurtenissen in het cluster. Elke knooppuntuitgang, elke promotie van een scherf van replica naar primair, elke taak om ergens een scherf te maken - dit alles gaat eerst naar TaskBatcher, waar het opeenvolgend en in één thread wordt verwerkt.
Op het moment dat één datacenter werd teruggetrokken, bleek dat alle dataknooppunten in de overgebleven datacentra het als hun plicht beschouwden om de meester te informeren “we zijn die en die scherven en die en die dataknooppunten kwijtgeraakt.”
Tegelijkertijd stuurden de overgebleven dataknooppunten al deze informatie naar de huidige master en probeerden te wachten op bevestiging dat hij deze accepteerde. Ze wachtten hier niet op, omdat de meester sneller taken ontving dan hij kon beantwoorden. De knooppunten hadden een time-out voor herhaalde verzoeken, en de master probeerde op dat moment niet eens ze te beantwoorden, maar ging volledig op in de taak om verzoeken op prioriteit te sorteren.
In terminalvorm bleek dat de dataknooppunten de master zodanig spamden dat deze in volledige GC terechtkwam. Daarna verhuisde onze meesterrol naar een volgend knooppunt, er gebeurde absoluut hetzelfde en als gevolg daarvan stortte het cluster volledig in.
We hebben metingen gedaan en vóór versie 6.4.0, waarin dit was opgelost, was het voor ons voldoende om tegelijkertijd slechts 10 dataknooppunten van de 360 uit te voeren om het cluster volledig uit te schakelen.
Het zag er ongeveer zo uit:
Na versie 6.4.0, waarin deze vreselijke bug was opgelost, stopten dataknooppunten met het doden van de master. Maar dat maakte hem niet ‘slimmer’. Namelijk: wanneer we 2, 3 of 10 (een ander aantal dan één) dataknooppunten uitvoeren, ontvangt de master een eerste bericht dat zegt dat knooppunt A is vertrokken, en probeert hij knooppunt B, knooppunt C hierover te vertellen, knooppunt D.
En op dit moment kan dit alleen worden aangepakt door een time-out in te stellen voor pogingen om iemand iets over iets te vertellen, ongeveer 20-30 seconden, en zo de snelheid te controleren van het datacenter dat het cluster verlaat.
In principe past dit in de eisen die in eerste instantie aan het eindproduct werden gesteld als onderdeel van het project, maar vanuit het oogpunt van “puur wetenschap” is dit een bug. Wat overigens met succes door de ontwikkelaars is opgelost in versie 7.2.
Bovendien bleek, toen een bepaald dataknooppunt uitviel, het verspreiden van informatie over het verlaten ervan belangrijker was dan het vertellen aan het hele cluster dat er zulke en die primaire shards op stonden (om een replica-shard in een ander dataknooppunt te promoten). centraal in de basisschool, en er zou informatie op geschreven kunnen worden).
Wanneer alles al is uitgestorven, worden de vrijgegeven dataknooppunten daarom niet onmiddellijk als verouderd gemarkeerd. Dienovereenkomstig zijn we gedwongen te wachten tot alle pings naar de vrijgegeven dataknooppunten zijn verlopen, en pas daarna begint ons cluster ons te vertellen dat we daar, daar en daar door moeten gaan met het opnemen van informatie. Hier kunt u meer over lezen .
Als gevolg hiervan kost het terugtrekken van een datacenter vandaag de dag tijdens de spits ongeveer 5 minuten. Voor zo'n groot en onhandig gevaarte is dit een behoorlijk goed resultaat.
Naar aanleiding hiervan zijn wij tot het volgende besluit gekomen:
- We hebben 360 dataknooppunten met 700 gigabyte schijven.
- 60 coördinatoren voor het routeren van verkeer via dezelfde dataknooppunten.
- 40 masters die we als een soort erfenis hebben achtergelaten sinds versies vóór 6.4.0 - om de terugtrekking van het datacenter te overleven, waren we mentaal voorbereid om verschillende machines te verliezen om gegarandeerd te zijn van een quorum van masters, zelfs in het worstcasescenario
- Elke poging om rollen op één container te combineren stuitte op het feit dat het knooppunt vroeg of laat onder belasting kapot zou gaan.
- Het hele cluster gebruikt een heap.size van 31 gigabyte: alle pogingen om de grootte te verkleinen resulteerden in het uitschakelen van enkele knooppunten bij zware zoekopdrachten met de leidende wildcard, of in het verkrijgen van de stroomonderbreker in Elasticsearch zelf.
- Om de zoekprestaties te garanderen, hebben we bovendien geprobeerd het aantal objecten in het cluster zo klein mogelijk te houden, om zo min mogelijk gebeurtenissen te verwerken in het knelpunt dat we in de master kregen.
Tenslotte over het toezicht
Om ervoor te zorgen dat dit allemaal werkt zoals bedoeld, monitoren wij het volgende:
- Elk dataknooppunt rapporteert aan onze cloud dat het bestaat, en dat er zulke en die scherven op zitten. Wanneer we ergens iets doven, meldt het cluster na 2-3 seconden dat we in centrum A knooppunten 2, 3 en 4 hebben gedoofd - dit betekent dat we in andere datacentra onder geen beding die knooppunten kunnen doven waarop zich slechts één scherf bevindt links.
- Omdat we de aard van het gedrag van de meester kennen, kijken we heel zorgvuldig naar het aantal openstaande taken. Omdat zelfs één vastgelopen taak, als deze niet op tijd wordt onderbroken, theoretisch in een noodsituatie de reden kan worden waarom bijvoorbeeld de promotie van een replica-scherf in de primaire niet werkt, en daarom zal het indexeren niet meer werken.
- We kijken ook heel goed naar vertragingen bij de garbage collector, omdat we hier tijdens de optimalisatie al grote problemen mee hebben gehad.
- Weigert per thread om vooraf te begrijpen waar het knelpunt zit.
- Nou ja, standaardstatistieken zoals heap, RAM en I/O.
Bij het bouwen van monitoring moet je rekening houden met de features van Thread Pool in Elasticsearch. beschrijft configuratieopties en standaardwaarden voor zoeken en indexeren, maar zwijgt volledig over thread_pool.management. Deze threads verwerken met name queries zoals _cat/shards en andere soortgelijke, die handig zijn om te gebruiken bij het schrijven van monitoring. Hoe groter het cluster, hoe meer van dergelijke verzoeken per tijdseenheid worden uitgevoerd, en het eerder genoemde thread_pool.management wordt niet alleen niet weergegeven in de officiële documentatie, maar is ook standaard beperkt tot 5 threads, wat zeer snel wordt verwijderd nadat welke monitoring niet meer correct werkt.
Wat ik tot slot wil zeggen: het is ons gelukt! We hebben onze programmeurs en ontwikkelaars een tool kunnen geven die in vrijwel elke situatie snel en betrouwbaar informatie kan geven over wat er in de productie gebeurt.
Ja, het bleek behoorlijk ingewikkeld, maar toch zijn we erin geslaagd onze wensen in bestaande producten in te passen, die we niet zelf hoefden te patchen en herschrijven.
Bron: www.habr.com