200TB+ Elasticsearch Cluster

Mange mennesker kæmper med Elasticsearch. Men hvad sker der, når du vil bruge det til at gemme logfiler "i en særlig stor mængde"? Og er det også smertefrit at opleve svigt i nogle af flere datacentre? Hvilken slags arkitektur skal du lave, og hvilke faldgruber vil du falde over?

Vi hos Odnoklassniki besluttede at bruge elasticsearch til at løse problemet med logstyring, og nu deler vi vores erfaring med Habr: både om arkitektur og om faldgruber.

Jeg hedder Pyotr Zaitsev, jeg arbejder som systemadministrator hos Odnoklassniki. Før det var jeg også admin, arbejdede med Manticore Search, Sphinx search, Elasticsearch. Måske, hvis der dukker endnu en ...søgning op, vil jeg nok også arbejde med den. Jeg deltager også i en række open source-projekter på frivillig basis.

Da jeg kom til Odnoklassniki, sagde jeg hensynsløst ved interviewet, at jeg kunne arbejde med Elasticsearch. Efter at jeg havde vænnet mig til det og lavet nogle simple opgaver, blev jeg præsenteret for en stor opgave med at reformere det logstyringssystem, der eksisterede på det tidspunkt.

Krav

Kravene til systemet var formuleret som følger:

• Graylog skulle bruges som frontend. Fordi virksomheden allerede havde erfaring med at bruge dette produkt, vidste programmører og testere det, det var velkendt og praktisk for dem.
• Datavolumen: i gennemsnit 50-80 tusinde beskeder i sekundet, men hvis noget går i stykker, så er trafikken ikke begrænset af noget, den kan være 2-3 millioner linjer i sekundet
• Efter at have diskuteret kravene til hastigheden for behandling af søgeforespørgsler med kunderne, indså vi, at det typiske mønster for at bruge et sådant system er dette: folk leder efter logfiler for deres ansøgning for de sidste to dage og ønsker ikke at vente mere end en anden for resultatet af en formuleret forespørgsel.
• Administratorerne insisterede på, at systemet var let skalerbart, hvis det var nødvendigt, uden at de skulle dykke dybt ned i, hvordan det fungerer.
• Så den eneste vedligeholdelsesopgave, som disse systemer havde brug for med jævne mellemrum, var at ændre en form for hardware.
• Derudover har Odnoklassniki en stor teknisk tradition: enhver tjeneste, vi lancerer, skal overleve en datacenterfejl (pludselig, uplanlagt og absolut til enhver tid).

Det sidste krav i implementeringen af ​​dette projekt kostede os mest, hvilket jeg vil tale mere detaljeret om.

onsdag

Vi arbejder i fire datacentre, mens Elasticsearch-dataknudepunkter kun kan placeres i tre (af en række ikke-tekniske årsager).

I disse fire datacentre er der cirka 18 tusinde forskellige kilder til logfiler - jernstykker, containere, virtuelle maskiner.

Vigtig funktion: klyngen starter i containere Podman ikke på fysiske maskiner, men på eget one-cloud cloud-produkt. Containere er garanteret 2 kerner, svarende til 2.0Ghz v4, med mulighed for at genbruge de resterende kerner, hvis de er inaktive.

Med andre ord:

Topologi

Den generelle opfattelse af løsningen så jeg oprindeligt som følger:

• 3-4 VIP'er står bag A-recorden for Graylog-domænet, det er den adresse, logfilerne sendes til.
• hver VIP er en LVS balancer.
• Efter det går logfilerne til Graylog-batteriet, nogle af dataene er i GELF-format, nogle i syslog-format.
• Så er alt dette skrevet i store partier til batteriet fra Elasticsearch-koordinatorerne.
• Og de sender til gengæld skrive- og læseanmodninger til de relevante dataknudepunkter.

terminologi

Det er måske ikke alle, der forstår terminologien i detaljer, så jeg vil gerne dvæle lidt ved det.

Elasticsearch har flere typer noder - master, koordinator, data node. Der er to andre typer til forskellige transformationer af logfiler og tilslutning af forskellige klynger med hinanden, men vi brugte kun de anførte.

Mestre
Den pinger alle noder, der er til stede i klyngen, vedligeholder et opdateret klyngekort og distribuerer det mellem noder, behandler hændelseslogik og udfører forskellige former for klyngeomfattende husholdning.

Koordinator
Udfører én enkelt opgave: accepterer læse- eller skriveanmodninger fra klienter og dirigerer denne trafik. I tilfælde af at der er en skriveanmodning, vil den højst sandsynligt spørge master, hvilken shard af det relevante indeks den skal placere den i, og vil omdirigere anmodningen yderligere.

Data node
Gemmer data, udfører søgeforespørgsler, der kommer udefra, og udfører operationer på shards placeret på det.

grålog
Det er lidt som at fusionere Kibana med Logstash i ELK-stakken. Graylog kombinerer både brugergrænsefladen og logbehandlingspipelinen. Under motorhjelmen kører Graylog Kafka og Zookeeper, som giver forbindelse til Graylog som en klynge. Graylog kan cache logfiler (Kafka) i tilfælde af at Elasticsearch ikke er tilgængelig og gentage mislykkede læse- og skriveanmodninger, gruppere og markere logfiler i henhold til specificerede regler. Ligesom Logstash har Graylog funktionaliteten til at ændre strenge, før du skriver til Elasticsearch.

Derudover har Graylog en indbygget service discovery, der giver mulighed for, baseret på én tilgængelig Elasticsearch node, at hente hele klyngekortet og filtrere det efter et specifikt tag, hvilket gør det muligt at sende forespørgsler til bestemte containere.

Visuelt ser det sådan ud:

Dette er et skærmbillede fra en bestemt instans. Her bygger vi et histogram baseret på søgeforespørgslen og viser relevante rækker.

Indekser

For at vende tilbage til systemets arkitektur, vil jeg gerne dvæle mere detaljeret ved, hvordan vi byggede indeksmodellen, så det hele fungerer korrekt.

I diagrammet ovenfor er dette det laveste niveau: Elasticsearch-dataknudepunkter.

Et indeks er en stor virtuel enhed, der består af Elasticsearch shards. Hvert af skårene er i sig selv intet andet end et Lucene-indeks. Og hvert Lucene-indeks består til gengæld af et eller flere segmenter.

Ved design regnede vi med, at for at opfylde kravet om læsehastighed på en stor mængde data, var vi nødt til at "sprede" disse data jævnt på tværs af dataknudepunkter.

Dette resulterede i, at antallet af shards pr. indeks (med replikaer) skulle være strengt lig med antallet af dataknuder. For det første for at sikre en replikationsfaktor lig med to (det vil sige, at vi kan miste halvdelen af ​​klyngen). Og for det andet for at behandle læse- og skriveanmodninger på mindst halvdelen af ​​klyngen.

Vi bestemte først opbevaringstiden til 30 dage.

Fordelingen af ​​skår kan repræsenteres grafisk som følger:

Hele det mørkegrå rektangel er indekset. Den venstre røde firkant i den er den primære skærv, den første i indekset. Og den blå firkant er et replika-skår. De er placeret i forskellige datacentre.

Når vi tilføjer endnu et shard, går det til det tredje datacenter. Og i sidste ende får vi en sådan struktur, der giver mulighed for at miste en DC uden at miste datakonsistens:

Rotation af indekser, dvs. ved at oprette et nyt indeks og slette det ældste, gjorde vi det lig med 48 timer (ifølge mønsteret for indeksbrug: de sidste 48 timer søges oftest).

Dette indeksrotationsinterval skyldes følgende årsager:

Når en søgeanmodning ankommer til en specifik dataknude, så er det, set fra et ydeevnesynspunkt, mere rentabelt, når der forespørges på et shard, hvis størrelsen er sammenlignelig med størrelsen på knudepunktets hofte. Dette giver dig mulighed for at holde den "varme" del af indekset i en bunke og hurtigt få adgang til det. Når der er mange "varme dele", forringes indekssøgningens hastighed.

Når en node begynder at udføre en søgeforespørgsel på et shard, allokerer den et antal tråde svarende til antallet af hypertrådede kerner på den fysiske maskine. Hvis søgeforespørgslen påvirker et stort antal shards, så vokser antallet af tråde proportionalt. Dette har en dårlig effekt på søgehastigheden og påvirker indekseringen af ​​nye data negativt.

For at give den nødvendige søgeforsinkelse besluttede vi at bruge en SSD. For hurtigt at kunne behandle anmodninger skulle maskinerne, der var vært for disse containere, have mindst 56 kerner. Tallet 56 blev valgt som en betinget tilstrækkelig værdi, der bestemmer antallet af tråde, som Elasticsearch vil generere under drift. I Elasitcsearch afhænger mange trådpuljeparametre direkte af antallet af tilgængelige kerner, hvilket igen direkte påvirker det nødvendige antal noder i klyngen i henhold til princippet "færre kerner - flere noder".

Som et resultat fik vi, at et skår i gennemsnit vejer omkring 20 gigabyte, og der er 1 skår pr. 360 indeks. Derfor, hvis vi roterer dem hver 48. time, så har vi 15 af dem. Hvert indeks indeholder data for 2 dage.

Dataskrive- og læsekredsløb

Lad os finde ud af, hvordan data registreres i dette system.

Lad os sige, at der kommer en anmodning fra Graylog til koordinatoren. For eksempel ønsker vi at indeksere 2-3 tusinde rækker.

Koordinatoren, efter at have modtaget en anmodning fra Graylog, stiller spørgsmålstegn ved mesteren: "I indekseringsanmodningen specificerede vi specifikt et indeks, men i hvilket shard det skulle skrives var det ikke specificeret."

Masteren svarer: "Skriv denne information ind i shard nummer 71", hvorefter den sendes direkte til den relevante data node, hvor primær shard nummer 71 er placeret.

Hvorefter transaktionsloggen replikeres til et replika-shard, som er placeret i et andet datacenter.

En søgeanmodning kommer fra Graylog til koordinatoren. Koordinatoren omdirigerer det efter indeks, mens Elasticsearch fordeler anmodninger mellem primær-shard og replika-shard i henhold til round-robin-princippet.

De 180 noder reagerer ujævnt, og mens de reagerer, akkumulerer koordinatoren information, som allerede er blevet "spyttet ud" af hurtigere dataknudepunkter. Efter dette, når enten alle oplysninger er ankommet, eller anmodningen har nået en timeout, giver den alt direkte til klienten.

Hele dette system opfylder i gennemsnit søgeanmodninger for de sidste 48 timer på 300-400 ms, eksklusive de anmodninger, der er med det førende jokertegn.

Blomster med Elasticsearch: Java-opsætning

For at få det hele til at fungere, som vi oprindeligt ønskede, brugte vi meget lang tid på at fejlsøge en lang række ting i klyngen.

Den første del af de opdagede problemer var relateret til, hvordan Java er forudkonfigureret i Elasticsearch som standard.

Problem et
Vi har set et meget stort antal rapporter, som vi har på Lucene-niveau, når baggrundsjob kører, mislykkes Lucene-segmentsammenlægninger. Samtidig var det tydeligt i loggene, at der var tale om en OutOfMemoryError fejl. Fra telemetri så vi, at hoften var fri, og det var ikke klart, hvorfor denne operation faldt.

Det viste sig, at Lucene-indeksfusioner forekommer uden for hoften. Og containere er ret strengt begrænsede med hensyn til forbrugte ressourcer. Kun heap kunne passe ind i disse ressourcer (heap.size-værdien var omtrent lig med RAM), og nogle off-heap-operationer styrtede ned med en hukommelsesallokeringsfejl, hvis de af en eller anden grund ikke passede ind i de ~500 MB, der var tilbage før grænsen.

Rettelsen var ret triviel: mængden af ​​tilgængelig RAM til containeren blev øget, hvorefter vi glemte, at vi endda havde sådanne problemer.

Problem to
4-5 dage efter lanceringen af ​​klyngen bemærkede vi, at dataknudepunkter med jævne mellemrum begyndte at falde ud af klyngen og gå ind i den efter 10-20 sekunder.

Da vi begyndte at finde ud af det, viste det sig, at denne off-heap-hukommelse i Elasticsearch ikke er styret på nogen måde. Da vi gav mere hukommelse til containeren, var vi i stand til at fylde de direkte bufferpuljer med forskellige oplysninger, og den blev først ryddet efter den eksplicitte GC blev lanceret fra Elasticsearch.

I nogle tilfælde tog denne operation ret lang tid, og i løbet af denne tid lykkedes det klyngen at markere denne node som allerede frigivet. Dette problem er godt beskrevet. her.

Løsningen var som følger: vi begrænsede Javas mulighed for at bruge hovedparten af ​​hukommelsen uden for heapen til disse operationer. Vi begrænsede det til 16 gigabyte (-XX:MaxDirectMemorySize=16g), hvilket sikrede, at eksplicit GC blev kaldt meget oftere, og arbejdede meget hurtigere, og derved holdt op med at destabilisere klyngen.

Opgave tre
Hvis du tror, ​​at problemerne med "noder, der forlader klyngen på det mest uventede tidspunkt" er overstået, tager du fejl.

Da vi konfigurerede arbejdet med indekser, valgte vi mmapfs for at reducere søgetiden på friske skår med høj segmentering. Dette var en ret grov fejl, for når man bruger mmapfs, bliver filen mappet ind i RAM, og så arbejder vi med den mappede fil. På grund af dette viser det sig, at når GC'en forsøger at stoppe trådene i applikationen, går vi til safepoint i meget lang tid, og på vej dertil holder applikationen op med at svare på guidens anmodninger om, hvorvidt den er i live . Derfor mener master, at noden ikke længere er til stede i vores klynge. Derefter, efter 5-10 sekunder, arbejder affaldssamleren, knudepunktet kommer til live, kommer ind i klyngen igen og begynder at initialisere skårene. Alt dette lignede stærkt "den produktion, vi fortjente" og var ikke egnet til noget seriøst.

For at slippe af med denne adfærd skiftede vi først til standard niofs, og derefter, da vi migrerede fra den femte version af Elastic til den sjette, prøvede vi hybridfs, hvor dette problem ikke blev reproduceret. Du kan læse mere om lagertyper her.

Opgave fire
Så var der et andet meget underholdende problem, som vi behandlede i rekordlang tid. Vi fangede hende i 2-3 måneder, for hendes mønster var helt uforståeligt.

Nogle gange gik vores koordinatorer til Full GC, normalt engang efter frokost, og vendte aldrig tilbage derfra. På samme tid, når du logger GC-forsinkelsen, så det sådan ud: alt går godt, godt, godt, og så går alt pludselig meget dårligt.

Først troede vi, at vi havde en ond bruger, der lancerede en form for anmodning, der slog koordinatoren ud af arbejdstilstand. Vi loggede anmodninger i meget lang tid for at finde ud af, hvad der skete.

Som et resultat viste det sig, at i det øjeblik, hvor en bruger lancerer en enorm anmodning, og den rammer en specifik Elasticsearch-koordinator, reagerer nogle noder længere end andre.

Og mens koordinatoren venter på et svar fra alle noderne, akkumulerer han resultaterne sendt fra de noder, der allerede har svaret. For GC betyder det, at vores hoftebrugsmønster ændrer sig meget hurtigt. Og den GC, vi brugte, kunne ikke klare denne opgave.

Den eneste rettelse, vi fandt for at ændre klyngens adfærd i denne situation, er migrering til JDK13 og brug af Shenandoah-affaldsopsamleren. Dette løste problemet, vores koordinatorer holdt op med at falde.

Det var her problemerne med Java sluttede, og båndbreddeproblemerne begyndte.

"Bær" med Elasticsearch: gennemløb

Problemer med gennemløbet betyder, at vores klynge fungerer stabilt, men ved spidsbelastninger i antallet af indekserede dokumenter og under manøvrer er ydeevnen utilstrækkelig.

Det første symptom, der opstod: under nogle "eksplosioner" i produktionen, når et meget stort antal logfiler pludselig genereres, begynder indekseringsfejlen es_rejected_execution at blinke ofte i Graylog.

Dette skyldtes det faktum, at thread_pool.write.queue på én dataknude indtil Elasticsearch er i stand til at behandle indeksanmodningen og smide informationen ind i shard på disken, som standard kun kan cache 200 anmodninger. Og i Elasticsearch dokumentation Der siges meget lidt om denne parameter. Kun det begrænsede antal tråde og standardstørrelsen er angivet.

Selvfølgelig gik vi for at fordreje denne værdi og fandt ud af følgende: Specifikt i vores opsætning cachelagres op til 300 anmodninger ganske godt, og en større værdi er fyldt med det faktum, at vi igen flyver væk til Full GC.

Derudover, da det er batches af beskeder, der kommer inden for en enkelt anmodning, var det også nødvendigt at justere Graylog, så den ikke skriver ofte og i små batches, men i store batches eller hvert 3. sekund, hvis batchen stadig ikke er fuld. I dette tilfælde viser det sig, at informationen, som vi skriver i Elasticsearch, bliver tilgængelig ikke efter to sekunder, men efter fem (hvilket passer os ret godt), men antallet af retraces, der skal gøres for at skubbe et stort bundt af information falder.

Dette er især vigtigt i de øjeblikke, hvor noget er styrtet et sted og rasende rapporterer om det, for ikke at få en fuldstændig spammet Elastic, og efter nogen tid - Graylog-noder, der er ubrugelige på grund af tilstoppede buffere.

Derudover, da vi havde de samme eksplosioner i produktionen, modtog vi klager fra programmører og testere: i det øjeblik, hvor de virkelig havde brug for disse logfiler, fik de dem meget langsomt.

De begyndte at forstå. På den ene side var det tydeligt, at både søgeforespørgsler og indekseringsforespørgsler behandles, faktisk på de samme fysiske maskiner, og på en eller anden måde vil der være visse træk.

Men dette kunne delvist omgås på grund af det faktum, at der i den sjette version af Elasticsearch dukkede en algoritme op, der giver dig mulighed for at distribuere forespørgsler mellem relevante dataknudepunkter, der ikke er i overensstemmelse med det tilfældige round-robin-princip (den beholder, der foretager indeksering og holder den primære- shard kan være meget travlt, der vil ikke være nogen måde at reagere hurtigt på), men at videresende denne anmodning til en mindre fyldt container med en replika-shard, som vil reagere meget hurtigere. Med andre ord nåede vi frem til use_adaptive_replica_selection: sand.

Læsebilledet begynder at se sådan ud:

Overgangen til denne algoritme gjorde det muligt for os at forbedre forespørgselstiden mærkbart i de øjeblikke, hvor vi havde en stor strøm af logfiler til skrivning.

Endelig var hovedproblemet den smertefri fjernelse af datacentret.

Hvad vi ønskede fra klyngen umiddelbart efter tabet af kommunikation med en DC:

• Hvis vi har en aktuel master i det fejlbehæftede datacenter, så vil den blive genvalgt og flyttet som en rolle til en anden node i en anden DC.
• Masteren vil hurtigt fjerne alle utilgængelige noder fra klyngen.
• Baseret på de resterende vil han forstå: i det tabte datacenter havde vi sådanne og sådanne primære shards, han vil hurtigt fremme komplementære replika shards i de resterende datacentre, og vi vil fortsætte med at indeksere dataene.
• Som et resultat af dette vil klyngebåndbredden til skrivning og læsning jævnt forringes, men generelt vil alt fungere, omend langsomt, men støt.

Som det viste sig, ønskede vi noget som dette:

Og vi fik følgende:

Hvordan skete det?

På tidspunktet for datacentrets fald blev masteren flaskehalsen for os.

Hvorfor?

Faktum er, at masteren har en TaskBatcher, som er ansvarlig for at distribuere bestemte opgaver og begivenheder i klyngen. Enhver node-exit, enhver promovering af et shard fra replika til primært, enhver opgave for at skabe et shard et eller andet sted - alt dette går først til TaskBatcher, hvor det behandles sekventielt og i én tråd.

På tidspunktet for tilbagetrækningen af ​​et datacenter viste det sig, at alle dataknudepunkter i de overlevende datacentre betragtede det som deres pligt at informere masteren "vi har mistet sådan og sådan shards og sådan og sådan dataknudepunkter."

Samtidig sendte de overlevende dataknudepunkter alle disse oplysninger til den nuværende master og forsøgte at vente på bekræftelse af, at han havde accepteret den. Det forventede de ikke, da mesteren modtog opgaver hurtigere, end han havde tid til at besvare. Noderne gentog anmodninger efter timeout, og masteren på det tidspunkt forsøgte ikke engang at besvare dem, men var fuldstændig optaget af opgaven med at sortere anmodninger efter prioritet.

I terminalform viste det sig, at dataknuderne spammede masteren til det punkt, at den gik til fuld GC. Derefter flyttede vores mesterrolle til en næste knude, det samme skete med den, og som et resultat kollapsede klyngen fuldstændigt.

Vi foretog målinger, og før version 6.4.0, hvor det blev rettet, var det nok til, at vi på samme tid kun trak 10 ud af 360 dataknudepunkter tilbage for helt at sætte klyngen.

Det så nogenlunde sådan her ud:

Efter version 6.4.0, hvor denne mærkelige fejl blev rettet, holdt dataknuderne op med at dræbe masteren. Men det gjorde ham ikke klogere. Nemlig: når vi udsender 2, 3 eller 10 (et hvilket som helst andet antal end én) dataknudepunkter, modtager masteren en første besked, der siger, at node A er gået, og forsøger at fortælle node B, node C, node D.

Og i øjeblikket kan dette kun håndteres ved at sætte en timeout for forsøg på at fortælle nogen om noget, svarende til omkring 20-30 sekunder, og dermed styre hastigheden på datacentret, der bevæger sig ud af klyngen.

Dette passer i princippet ind i de krav, der oprindeligt blev stillet til det færdige produkt inden for projektets rammer, men set fra "ren videnskab" er der tale om en fejl. Hvilket i øvrigt blev rettet af udviklerne i version 7.2.

Da en bestemt datanode kom ud, viste det sig desuden, at det var vigtigere at sprede information om dens exit end at fortælle hele klyngen, at den havde sådan og sådan et primært shard (for at promovere et replika-shard i et andet datacenter i det primære, og i kunne de skrive information).

Derfor, når alt allerede er gået i stå, bliver de frigivne dataknuder ikke umiddelbart markeret som forældede. Derfor er vi tvunget til at vente, indtil alle ping har timeout til de frigivne dataknuder, og først efter det begynder vores klynge at fortælle os, at der, der og der, skal vi fortsætte med at registrere information. Du kan læse mere om dette her.

Som følge heraf tager operationen med at trække datacenteret tilbage i dag os omkring 5 minutter i myldretiden. For sådan en stor og klodset kolos er dette et ret godt resultat.

Som følge heraf kom vi til følgende beslutning:

• Vi har 360 dataknuder med 700 gigabyte diske.
• 60 koordinatorer til at dirigere trafik på de samme dataknudepunkter.
• 40 mastere, som vi har efterladt som en slags arv fra versionstiden før 6.4.0 - for at overleve tilbagetrækningen af ​​datacentret var vi mentalt forberedt på at miste flere maskiner for at garantere et kvorum af mestre selv i det værste scenarie
• Ethvert forsøg på at kombinere roller på én container blev mødt med det faktum, at knudepunktet før eller siden ville bryde under belastning.
• Hele klyngen bruger en heap.size på 31 gigabyte: alle forsøg på at reducere størrelsen resulterede i enten at dræbe nogle noder på tunge søgeforespørgsler med det førende jokertegn eller få afbryderen i selve Elasticsearch.
• Derudover forsøgte vi for at sikre søgeydelsen at holde antallet af objekter i klyngen så lavt som muligt, for at behandle så få hændelser som muligt i den flaskehals, som vi fik i masteren.

En sidste ting om overvågning

For at sikre, at alt dette fungerer efter hensigten, overvåger vi følgende:

• Hver dataknude rapporterer til vores sky, at den eksisterer, og der er sådanne og sådanne skår på den. Når vi slukker noget et eller andet sted, melder klyngen efter 2-3 sekunder, at vi i center A slukkede node 2, 3 og 4 - det betyder, at vi i andre datacentre ikke kan slukke de noder med kun ét skår tilbage.
• Når vi kender arten af ​​mesterens adfærd, ser vi meget omhyggeligt på antallet af afventende opgaver. Fordi selv en fastlåst opgave, hvis den ikke afbrydes i tide, teoretisk set i nogle nødsituationer kan blive årsagen til, at for eksempel promoveringen af ​​et replika-shard i den primære ikke virker, hvorfor indeksering vil holde op med at virke.
• Vi ser også meget nøje på forsinkelser ved skraldeopsamleren, for det har vi allerede haft store vanskeligheder med under optimering.
• Afviser i tråd for på forhånd at forstå, hvor flaskehalsen er.
• Nå, standardmålinger såsom heap, RAM og I/O.

Når du bygger overvågning, skal du sørge for at tage højde for funktionerne i trådpuljen i Elasticsearch. Elasticsearch dokumentation beskriver indstillingerne og standardværdierne for søgning, indeksering, men er helt stille om thread_pool.management. Disse tråde behandler især anmodninger som _cat/shards og andre lignende, der er praktiske at bruge, når man skriver overvågning. Jo større klyngen er, jo flere sådanne anmodninger eksekveres per tidsenhed, og førnævnte thread_pool.management er ikke blot ikke præsenteret i den officielle dokumentation, men er også som standard begrænset til 5 tråde, som meget hurtigt udnyttes, hvorefter overvågningen holder op med at fungere korrekt.

Hvad jeg vil sige afslutningsvis: vi gjorde det! Vi var i stand til at give vores programmører og udviklere et værktøj, der i næsten enhver situation hurtigt og pålideligt kan give information om, hvad der sker i produktionen.

Ja, det viste sig at være ret svært, men ikke desto mindre lykkedes det at passe vores ønskeliste ind i eksisterende produkter, som samtidig ikke skulle lappes og omskrives for os selv.

Kilde: www.habr.com