Saluton al ĉiuj, mia nomo estas Aleksandro, mi laboras ĉe CIAN kiel inĝeniero kaj okupiĝas pri sistema administrado kaj aŭtomatigo de infrastrukturaj procezoj. En la komentoj al unu el la antaŭaj artikoloj, ni estis petitaj diri kie ni ricevas 4 TB da ŝtipoj tage kaj kion ni faras per ili. Jes, ni havas multajn protokolojn, kaj aparta infrastrukturo estis kreita por prilabori ilin, kio ebligas al ni rapide solvi problemojn. En ĉi tiu artikolo mi parolos pri kiel ni adaptis ĝin dum jaro por labori kun ĉiam kreskanta fluo de datumoj.
De kie ni komencis?
Dum la lastaj jaroj, la ŝarĝo de cian.ru kreskis tre rapide, kaj ĝis la tria trimonato de 2018, rimedtrafiko atingis 11.2 milionojn da unikaj uzantoj monate. Tiutempe, en kritikaj momentoj ni perdis ĝis 40% de la protokoloj, tial ni ne povis rapide trakti incidentojn kaj pasigis multan tempon kaj penon solvi ilin. Ni ankaŭ ofte ne povis trovi la kaŭzon de la problemo, kaj ĝi ripetiĝus post iom da tempo. Estis infero kaj io devis esti farita pri tio.
Tiutempe, ni uzis aron de 10 datumnodoj kun ElasticSearch-versio 5.5.2 kun normaj indeksaj agordoj por stoki protokolojn. Ĝi estis enkondukita antaŭ pli ol unu jaro kiel populara kaj malaltekosta solvo: tiam la fluo de ŝtipoj ne estis tiom granda, ne havis signifon elpensi ne-normajn agordojn.
Prilaborado de envenantaj protokoloj estis disponigita fare de Logstash sur malsamaj havenoj sur kvin ElasticSearch-kunordigantoj. Unu indekso, sendepende de grandeco, konsistis el kvin pecetoj. Hora kaj ĉiutaga rotacio estis organizita, kiel rezulto, ĉirkaŭ 100 novaj pecetoj aperis en la areto ĉiun horon. Kvankam ne estis tre multaj protokoloj, la areto bone eltenis kaj neniu atentis ĝiajn agordojn.
La defioj de rapida kresko
La volumeno de generitaj tagaloj kreskis tre rapide, ĉar du procezoj interkovris unu la alian. Unuflanke, la nombro da uzantoj de la servo kreskis. Aliflanke, ni komencis aktive ŝanĝi al mikroserva arkitekturo, segante niajn malnovajn monolitojn en C# kaj Python. Pluraj dekduoj da novaj mikroservoj, kiuj anstataŭigis partojn de la monolito, generis signife pli da ŝtipoj por la infrastruktura areto.
Ĝi estis skalo kiu kondukis nin al la punkto kie la areto iĝis preskaŭ neregebla. Kiam la protokoloj komencis alveni kun rapideco de 20 mil mesaĝoj sekundo, ofta senutila rotacio pliigis la nombron da pecetoj al 6 mil, kaj estis pli ol 600 pecetoj por nodo.
Ĉi tio kaŭzis problemojn kun la atribuo de RAM, kaj kiam nodo kraŝis, ĉiuj pecetoj komencis moviĝi samtempe, multobligante trafikon kaj ŝarĝante aliajn nodojn, kio faris preskaŭ neeble skribi datumojn al la areto. Kaj dum ĉi tiu periodo ni restis sen ŝtipoj. Kaj se estis problemo kun la servilo, ni esence perdis 1/10 de la areto. Granda nombro da malgrandaj indeksoj aldonis kompleksecon.
Sen ŝtipoj, ni ne komprenis la kialojn de la okazaĵo kaj povus pli aŭ malpli frue treti sur la saman rastilon denove, kaj en la ideologio de nia teamo tio estis neakceptebla, ĉar ĉiuj niaj labormekanismoj estas dezajnitaj por fari ĝuste la malon - neniam ripeti la samaj problemoj. Por fari tion, ni bezonis la plenan volumon de ŝtipoj kaj ilian liveron preskaŭ en reala tempo, ĉar teamo de deĵorantaj inĝenieroj monitoris atentigojn ne nur de metrikoj, sed ankaŭ de ŝtipoj. Por kompreni la skalon de la problemo, tiutempe la totala volumo de ŝtipoj estis ĉirkaŭ 2 TB tage.
Ni fiksis celon tute forigi la perdon de ŝtipoj kaj redukti la tempon de ilia livero al la ELK-areto ĝis maksimume 15 minutoj dum forto-majoro (ni poste fidis ĉi tiun ciferon kiel interna KPI).
Nova rotacia mekanismo kaj varma-varmaj nodoj
Ni komencis la grapolkonverton ĝisdatigante la ElasticSearch-version de 5.5.2 al 6.4.3. Denove nia versio 5-grupo mortis, kaj ni decidis malŝalti ĝin kaj tute ĝisdatigi ĝin - ankoraŭ mankas protokoloj. Do ni faris ĉi tiun transiron en nur kelkaj horoj.
La plej grandskala transformo en ĉi tiu etapo estis la efektivigo de Apache Kafka sur tri nodoj kun kunordiganto kiel meza bufro. La mesaĝmakleristo savis nin de perdi protokolojn dum problemoj kun ElasticSearch. Samtempe, ni aldonis 2 nodojn al la areto kaj ŝanĝis al varma-varma arkitekturo kun tri "varmaj" nodoj situantaj en malsamaj rakoj en la datumcentro. Ni redirektis protokolojn al ili uzante maskon, kiu ne devus esti perdita sub neniu cirkonstanco - nginx, same kiel aplikajn erarprotilojn. Malgrandaj protokoloj estis senditaj al la ceteraj nodoj - sencimigo, averto, ktp., kaj post 24 horoj, "gravaj" protokoloj de "varmaj" nodoj estis translokigitaj.
Por ne pliigi la nombron da malgrandaj indeksoj, ni ŝanĝis de temporotacio al la ruliĝa mekanismo. Estis multe da informoj pri la forumoj, ke rotacio laŭ indeksa grandeco estas tre nefidinda, do ni decidis uzi rotacion laŭ la nombro da dokumentoj en la indekso. Ni analizis ĉiun indekson kaj registris la nombron da dokumentoj post kiuj rotacio devus funkcii. Tiel, ni atingis la optimuman breĉetan grandecon - ne pli ol 50 GB.
Optimumigo de areto
Tamen ni ne tute forigis la problemojn. Bedaŭrinde ankoraŭ aperis malgrandaj indeksoj: ili ne atingis la specifitan volumon, ne estis turnitaj, kaj estis forigitaj per tutmonda purigado de indeksoj pli malnovaj ol tri tagoj, ĉar ni forigis rotacion laŭ dato. Ĉi tio kaŭzis perdon de datumoj pro la fakto, ke la indekso de la areto tute malaperis, kaj provo skribi al neekzistanta indekso rompis la logikon de la kuratoro, kiun ni uzis por administrado. Kaŝnomo por skribado estis konvertita en indekson kaj rompis la logikon de ruliĝo, kaŭzante senbridan kreskon de iuj indeksoj ĝis 600 GB.
Ekzemple, por la rotacia agordo:
сurator-elk-rollover.yaml
---
actions:
1:
action: rollover
options:
name: "nginx_write"
conditions:
max_docs: 100000000
2:
action: rollover
options:
name: "python_error_write"
conditions:
max_docs: 10000000
Se ne estis transpasa kaŝnomo, okazis eraro:
ERROR alias "nginx_write" not found.
ERROR Failed to complete action: rollover. <type 'exceptions.ValueError'>: Unable to perform index rollover with alias "nginx_write".
Ni lasis la solvon de ĉi tiu problemo por la sekva ripeto kaj prenis alian aferon: ni ŝanĝis al la tira logiko de Logstash, kiu prilaboras envenantajn protokolojn (forigante nenecesajn informojn kaj riĉigante). Ni metis ĝin en docker, kiun ni lanĉas per docker-compose, kaj ni ankaŭ metis tie logstash-exporter, kiu sendas metrikojn al Prometheus por funkcia monitorado de la logfluo. Tiel ni donis al ni la ŝancon glate ŝanĝi la nombron da logstash-instancoj respondecaj pri prilaborado de ĉiu tipo de ŝtipo.
Dum ni plibonigis la areton, la trafiko de cian.ru pliiĝis al 12,8 milionoj da unikaj uzantoj monate. Rezulte, montriĝis, ke niaj transformoj estis iomete malantaŭ la ŝanĝoj en produktado, kaj ni alfrontis la fakton, ke la "varmaj" nodoj ne povis elteni la ŝarĝon kaj malrapidigis la tutan liveron de ŝtipoj. Ni ricevis "varmajn" datumojn sen misfunkciadoj, sed ni devis interveni en la livero de la ceteraj kaj fari manan transdonon por egale distribui la indeksojn.
Samtempe, grimpi kaj ŝanĝi la agordojn de logstash-kazoj en la areto estis malfaciligita pro la fakto, ke ĝi estis loka docker-komponaĵo, kaj ĉiuj agoj estis faritaj permane (por aldoni novajn finaĵojn, estis necese permane trarigardi ĉiujn. la serviloj kaj faru docker-komponi -d ĉie).
Log-redistribuo
En septembro de ĉi tiu jaro, ni ankoraŭ tranĉis la monoliton, la ŝarĝo sur la areto pliiĝis, kaj la fluo de ŝtipoj alproksimiĝis al 30 mil mesaĝoj sekundo.
Ni komencis la sekvan ripeton per aparataro ĝisdatigo. Ni ŝanĝis de kvin kunordigantoj al tri, anstataŭigis datumnodojn kaj venkis laŭ mono kaj stokado. Por nodoj ni uzas du agordojn:
- Por "varmaj" nodoj: E3-1270 v6 / 960Gb SSD / 32 Gb x 3 x 2 (3 por Hot1 kaj 3 por Hot2).
- Por "varmaj" nodoj: E3-1230 v6 / 4Tb SSD / 32 Gb x 4.
Ĉe ĉi tiu ripeto, ni movis la indekson kun alirprotokoloj de mikroservoj, kiuj okupas la saman spacon kiel frontliniaj nginx-protokoloj, al la dua grupo de tri "varmaj" nodoj. Ni nun stokas datumojn sur "varmaj" nodoj dum 20 horoj, kaj poste transdonas ilin al "varmaj" nodoj al la resto de la protokoloj.
Ni solvis la problemon de malaperantaj malgrandaj indeksoj per reagordo de ilia rotacio. Nun la indeksoj ĉiuokaze turniĝas ĉiujn 23 horojn, eĉ se estas malmulte da datumoj tie. Ĉi tio iomete pliigis la nombron da pecetoj (estis ĉirkaŭ 800 da ili), sed el la vidpunkto de la agado de grapo ĝi estas tolerebla.
Kiel rezulto, estis ses "varmaj" kaj nur kvar "varmaj" nodoj en la areto. Ĉi tio kaŭzas etan prokraston pri petoj dum longaj intervaloj, sed pligrandigi la nombron da nodoj estonte solvos ĉi tiun problemon.
Ĉi tiu ripeto ankaŭ riparis la problemon de la manko de duonaŭtomata skalado. Por fari tion, ni deplojis infrastrukturon Nomad-grupon - similan al tio, kion ni jam disfaldis en produktado. Nuntempe, la kvanto de Logstash ne aŭtomate ŝanĝiĝas depende de la ŝarĝo, sed ni venos al ĉi tio.
Planoj por la estonteco
La efektivigita agordo skalas perfekte, kaj nun ni stokas 13,3 TB da datumoj - ĉiuj protokoloj dum 4 tagoj, kio estas necesa por kriz-analizo de alarmoj. Ni konvertas kelkajn el la protokoloj en metrikojn, kiujn ni aldonas al Grafito. Por faciligi la laboron de inĝenieroj, ni havas metrikojn por la infrastruktura aro kaj skriptojn por duonaŭtomata riparo de oftaj problemoj. Post pliigo de la nombro da datumnodoj, kiu estas planita por la venonta jaro, ni ŝanĝos al datumstokado de 4 ĝis 7 tagoj. Ĉi tio sufiĉos por operacia laboro, ĉar ni ĉiam provas esplori okazaĵojn kiel eble plej baldaŭ, kaj por longdaŭraj esploroj estas telemetriaj datumoj.
En oktobro 2019, trafiko al cian.ru jam kreskis al 15,3 milionoj da unikaj uzantoj monate. Tio iĝis serioza testo de la arkitektura solvo por liverado de tagaloj.
Nun ni preparas ĝisdatigi ElasticSearch al versio 7. Tamen, por tio ni devos ĝisdatigi la mapadon de multaj indeksoj en ElasticSearch, ĉar ili moviĝis de versio 5.5 kaj estis deklaritaj kiel malrekomenditaj en versio 6 (ili simple ne ekzistas en versio). 7). Ĉi tio signifas, ke dum la ĝisdatiga procezo certe okazos ia forto-majoro, kiu lasos nin sen protokoloj dum la problemo estas solvita. De la versio 7, ni plej antaŭĝojas pri Kibana kun plibonigita interfaco kaj novaj filtriloj.
Ni atingis nian ĉefan celon: ni ĉesis perdi protokolojn kaj reduktis la malfunkcion de la infrastruktura aro de 2-3 kraŝoj semajne al kelkaj horoj da bontenado laboro monate. Ĉio ĉi tiu laboro en produktado estas preskaŭ nevidebla. Tamen, nun ni povas determini ĝuste kio okazas kun nia servo, ni povas rapide fari ĝin en trankvila reĝimo kaj ne zorgi, ke la protokoloj estos perditaj. Ĝenerale, ni estas kontentaj, feliĉaj kaj prepariĝas por novaj heroaĵoj, pri kiuj ni parolos poste.
fonto: www.habr.com