Hallo almal, my naam is Alexander, ek werk by CIAN as ingenieur en is betrokke by stelsel administrasie en outomatisering van infrastruktuur prosesse. In die kommentaar op een van die vorige artikels is ons gevra om te vertel waar ons 4 TB logs per dag kry en wat ons daarmee doen. Ja, ons het baie logs, en 'n aparte infrastruktuurgroepering is geskep om dit te verwerk, wat ons in staat stel om probleme vinnig op te los. In hierdie artikel sal ek praat oor hoe ons dit oor die loop van 'n jaar aangepas het om met 'n steeds groeiende vloei van data te werk.
Waar het ons begin
Oor die afgelope paar jaar het die las op cian.ru baie vinnig gegroei, en teen die derde kwartaal van 2018 het hulpbronverkeer 11.2 miljoen unieke gebruikers per maand bereik. Op daardie tydstip het ons op kritieke oomblikke tot 40% van die logs verloor, en daarom kon ons nie vinnig insidente hanteer nie en het ons baie tyd en moeite spandeer om dit op te los. Ons kon ook dikwels nie die oorsaak van die probleem vind nie, en dit sou na 'n geruime tyd herhaal. Dit was hel en iets moes daaromtrent gedoen word.
Op daardie tydstip het ons 'n groep van 10 data nodusse met ElasticSearch weergawe 5.5.2 met standaard indeks instellings gebruik om logs te stoor. Dit is meer as 'n jaar gelede bekendgestel as 'n gewilde en bekostigbare oplossing: toe was die vloei van stompe nie so groot nie, dit was geen sin om met nie-standaard konfigurasies vorendag te kom nie.
Verwerking van inkomende logs is verskaf deur Logstash op verskillende poorte op vyf ElasticSearch-koördineerders. Een indeks, ongeag die grootte, het uit vyf skerwe bestaan. 'n Uurlikse en daaglikse rotasie is georganiseer, gevolglik het ongeveer 100 nuwe skerwe elke uur in die groep verskyn. Alhoewel daar nie baie logs was nie, het die groep dit goed hanteer en niemand het aandag aan sy instellings gegee nie.
Die uitdagings van vinnige groei
Die volume gegenereerde logs het baie vinnig gegroei, aangesien twee prosesse mekaar oorvleuel. Aan die een kant het die aantal gebruikers van die diens gegroei. Aan die ander kant het ons aktief begin oorskakel na 'n mikrodiensargitektuur en ons ou monoliete in C# en Python opgesaag. Etlike dosyn nuwe mikrodienste wat dele van die monoliet vervang het, het aansienlik meer logs vir die infrastruktuurgroepering gegenereer.
Dit was skaal wat ons gelei het tot die punt waar die groepering feitlik onhanteerbaar geword het. Toe die logs begin aankom teen 'n tempo van 20 duisend boodskappe per sekonde, het gereelde nuttelose rotasie die aantal skerwe tot 6 duisend verhoog, en daar was meer as 600 skerwe per nodus.
Dit het gelei tot probleme met die toewysing van RAM, en toe 'n nodus neergestort het, het alle skerwe gelyktydig begin beweeg, verkeer vermenigvuldig en ander nodusse gelaai, wat dit byna onmoontlik gemaak het om data na die groepie te skryf. En gedurende hierdie tydperk is ons sonder hout gelaat. En as daar 'n probleem met die bediener was, het ons basies 1/10 van die groep verloor. 'n Groot aantal klein indekse het kompleksiteit bygevoeg.
Sonder logs het ons nie die redes vir die voorval verstaan nie en kon ons vroeër of later weer op dieselfde hark trap, en in die ideologie van ons span was dit onaanvaarbaar, aangesien al ons werkmeganismes ontwerp is om net die teenoorgestelde te doen - nooit herhaal nie dieselfde probleme. Om dit te kan doen, het ons die volle volume logs en hul aflewering amper intyds nodig gehad, aangesien 'n span aan diens ingenieurs waarskuwings nie net vanaf statistieke gemonitor het nie, maar ook vanaf logs. Om die omvang van die probleem te verstaan, was die totale volume stompe op daardie stadium ongeveer 2 TB per dag.
Ons het 'n doelwit gestel om die verlies van stompe heeltemal uit te skakel en die tyd van hul aflewering aan die ELK-groepering te verminder tot 'n maksimum van 15 minute tydens force majeure (ons het later op hierdie syfer as 'n interne KPI staatgemaak).
Nuwe rotasiemeganisme en warm-warm nodusse
Ons het die groepomskakeling begin deur die ElasticSearch-weergawe van 5.5.2 na 6.4.3 op te dateer. Weereens het ons weergawe 5-kluster gesterf, en ons het besluit om dit af te skakel en dit heeltemal op te dateer - daar is steeds geen logs nie. So ons het hierdie oorgang in net 'n paar uur gemaak.
Die mees grootskaalse transformasie op hierdie stadium was die implementering van Apache Kafka op drie nodusse met 'n koördineerder as 'n tussenbuffer. Die boodskapmakelaar het ons gered om logs te verloor tydens probleme met ElasticSearch. Terselfdertyd het ons 2 nodusse by die groep gevoeg en oorgeskakel na 'n warm-warm argitektuur met drie "warm" nodusse wat in verskillende rakke in die datasentrum geleë is. Ons het logs na hulle herlei met behulp van 'n masker wat onder geen omstandighede verlore mag gaan nie - nginx, sowel as toepassingsfoutlogboeke. Klein logs is na die oorblywende nodusse gestuur - ontfouting, waarskuwing, ens., en na 24 uur is "belangrike" logs van "warm" nodusse oorgedra.
Om nie die aantal klein indekse te verhoog nie, het ons van tydrotasie na die omrolmeganisme oorgeskakel. Daar was baie inligting op die forums dat rotasie volgens indeksgrootte baie onbetroubaar is, daarom het ons besluit om rotasie volgens die aantal dokumente in die indeks te gebruik. Ons het elke indeks ontleed en die aantal dokumente aangeteken waarna rotasie behoort te werk. Ons het dus die optimale skerfgrootte bereik - nie meer as 50 GB nie.
Cluster optimering
Ons het egter nie heeltemal van die probleme ontslae geraak nie. Ongelukkig het klein indekse steeds verskyn: hulle het nie die gespesifiseerde volume bereik nie, is nie geroteer nie en is uitgevee deur globale skoonmaak van indekse ouer as drie dae, aangesien ons rotasie volgens datum verwyder het. Dit het gelei tot dataverlies as gevolg van die feit dat die indeks van die cluster heeltemal verdwyn het, en 'n poging om na 'n nie-bestaande indeks te skryf, het die logika van die kurator wat ons vir bestuur gebruik het, gebreek. Alias vir skryf is omgeskakel in 'n indeks en het die oorrollogika verbreek, wat onbeheerde groei van sommige indekse tot 600 GB veroorsaak het.
Byvoorbeeld, vir die rotasie-konfigurasie:
с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
As daar geen oorrol-alias was nie, het 'n fout voorgekom:
ERROR alias "nginx_write" not found.
ERROR Failed to complete action: rollover. <type 'exceptions.ValueError'>: Unable to perform index rollover with alias "nginx_write".
Ons het die oplossing vir hierdie probleem vir die volgende herhaling gelaat en nog 'n kwessie aangepak: ons het oorgeskakel na die treklogika van Logstash, wat inkomende logs verwerk (onnodige inligting verwyder en verryk). Ons het dit in docker geplaas, wat ons via docker-compose begin, en ons het ook logstash-exporter daar geplaas, wat statistieke na Prometheus stuur vir operasionele monitering van die logstroom. Op hierdie manier het ons onsself die geleentheid gegee om die aantal logstash-gevalle wat verantwoordelik is vir die verwerking van elke tipe log, glad te verander.
Terwyl ons besig was om die groepie te verbeter, het cian.ru se verkeer tot 12,8 miljoen unieke gebruikers per maand toegeneem. As gevolg hiervan het dit geblyk dat ons transformasies 'n bietjie agter die veranderinge in produksie was, en ons het gekonfronteer met die feit dat die "warm" nodusse nie die vrag kon hanteer nie en die hele aflewering van stompe vertraag het. Ons het "warm" data sonder mislukkings ontvang, maar ons moes ingryp in die lewering van die res en 'n handomdraai doen om die indekse eweredig te versprei.
Terselfdertyd is die skaal en verandering van die instellings van logstash-gevalle in die cluster bemoeilik deur die feit dat dit 'n plaaslike docker-compose was, en alle aksies is met die hand uitgevoer (om nuwe eindes by te voeg, was dit nodig om handmatig deur alle die bedieners en doen docker-compose up -d oral).
Log herverdeling
In September vanjaar was ons steeds besig om die monoliet op te sny, die las op die groep het toegeneem en die vloei van logs het 30 duisend boodskappe per sekonde benader.
Ons het die volgende herhaling begin met 'n hardeware-opdatering. Ons het van vyf koördineerders na drie oorgeskakel, datanodes vervang en gewen in terme van geld en stoorspasie. Vir nodusse gebruik ons twee konfigurasies:
- Vir “warm” nodusse: E3-1270 v6 / 960 Gb SSD / 32 Gb x 3 x 2 (3 vir Hot1 en 3 vir Hot2).
- Vir "warm" nodusse: E3-1230 v6 / 4Tb SSD / 32 Gb x 4.
By hierdie herhaling het ons die indeks met toegangslogboeke van mikrodienste, wat dieselfde spasie as voorlyn nginx-logboeke in beslag neem, na die tweede groep van drie "warm" nodusse verskuif. Ons stoor nou data op "warm" nodusse vir 20 uur, en dra dit dan oor na "warm" nodusse na die res van die logs.
Ons het die probleem opgelos dat klein indekse verdwyn deur hul rotasie te herkonfigureer. Nou word die indekse in elk geval elke 23 uur geroteer, selfs al is daar min data daar. Dit het die aantal skerwe effens verhoog (daar was ongeveer 800 van hulle), maar uit die oogpunt van trosprestasie is dit draaglik.
As gevolg hiervan was daar ses "warm" en slegs vier "warm" nodusse in die groep. Dit veroorsaak 'n effense vertraging op versoeke oor lang tydintervalle, maar die verhoging van die aantal nodusse in die toekoms sal hierdie probleem oplos.
Hierdie herhaling het ook die probleem van die gebrek aan semi-outomatiese skaal opgelos. Om dit te doen, het ons 'n infrastruktuur Nomad-kluster ontplooi - soortgelyk aan wat ons reeds in produksie ontplooi het. Vir nou verander die hoeveelheid Logstash nie outomaties na gelang van die vrag nie, maar ons sal hierby uitkom.
Planne vir die toekoms
Die geïmplementeerde konfigurasie skaal perfek, en nou stoor ons 13,3 TB data - alle logs vir 4 dae, wat nodig is vir noodontleding van waarskuwings. Ons omskep sommige van die logs in metrieke, wat ons by Graphite voeg. Om die werk van ingenieurs makliker te maak, het ons maatstawwe vir die infrastruktuurgroepering en skrifte vir semi-outomatiese herstel van algemene probleme. Na die verhoging van die aantal data nodusse, wat beplan word vir volgende jaar, sal ons oorskakel na data stoor van 4 tot 7 dae. Dit sal genoeg wees vir operasionele werk, aangesien ons altyd probeer om voorvalle so gou moontlik te ondersoek, en vir langtermynondersoeke is daar telemetriedata.
In Oktober 2019 het die verkeer na cian.ru reeds gegroei tot 15,3 miljoen unieke gebruikers per maand. Dit het 'n ernstige toets geword van die argitektoniese oplossing vir die lewering van stompe.
Nou berei ons voor om ElasticSearch op te dateer na weergawe 7. Hiervoor sal ons egter die kartering van baie indekse in ElasticSearch moet opdateer, aangesien hulle van weergawe 5.5 geskuif is en verklaar is as verouderd in weergawe 6 (hulle bestaan eenvoudig nie in weergawe nie) 7). Dit beteken dat daar tydens die opdateringsproses beslis 'n soort force majeure sal wees, wat ons sonder logboeke sal laat terwyl die probleem opgelos word. Van weergawe 7 sien ons die meeste uit na Kibana met 'n verbeterde koppelvlak en nuwe filters.
Ons het ons hoofdoelwit bereik: ons het opgehou om logs te verloor en die stilstandtyd van die infrastruktuurgroepering van 2-3 ongelukke per week tot 'n paar uur se instandhoudingswerk per maand verminder. Al hierdie werk in produksie is amper onsigbaar. Nou kan ons egter presies bepaal wat met ons diens gebeur, ons kan dit vinnig in 'n stil modus doen en nie bekommerd wees dat die logs verlore gaan nie. Oor die algemeen is ons tevrede, gelukkig en berei ons voor vir nuwe uitbuitings, waaroor ons later sal praat.
Bron: will.com