Tere, minu nimi on Aleksandr, ma töötan CIANis insenerina ja tegelema süsteemiadministreerimise ning infrastruktuuri protsesside automatiseerimisega. Ühes eelmises artiklis palusime kommenteerida, kust me võtame 4 TB logisid päevas ja mida nendega teeme. Jah, meil on palju logisid, ning nende töötlemiseks on loodud eraldi infrastruktuuri klaster, mis võimaldab meil kiiresti probleeme lahendada. Selles artiklis räägin, kuidas me aasta jooksul kohandasime seda pidevalt kasvava andmevooga toimetamiseks.
Kust me alustasime
Viimastel aastatel on cian.ru koormus kiiresti kasvanud ja 2018. aasta kolmandaks kvartaliks saavutas ressursi külastatavus 11,2 miljonit unikaalset kasutajat kuus. Tol ajal kaotasime kriitilistel hetkedel kuni 40% logidest, mistõttu ei suutnud me kiiresti juhtumeid lahendada ja kulutasime nende lahendamisele palju aega ja vaeva. Samuti ei suutnud me sageli leida probleemi põhjust, mistõttu see kordus mõne aja pärast. See oli põrgu, millega tuli midagi ette võtta.
Tollal kasutasime logide salvestamiseks 10 andmeklastri node'ist koosnevat klastrit ElasticSearch versioonis 5.5.2 tavaliste indeksiseadetega. See rakendati üle aasta tagasi populaarse ja kergesti kätte saadava lahendusena: siis ei olnud logide voog nii suur, et oleks olnud mõtet välja mõelda mittestandardseid konfiguratsioone.
Sissetulevate logide töötlemist tagas Logstash erinevatel portidel viiel ElasticSearchi koordinaatoril. Üks indeks, olenemata suurusest, koosnes viiest shardist. Oli korraldatud tunnine ja päevaste rotatsioonide süsteem, mille tulemuseks oli see, et klastris ilmus iga tunni jooksul umbes 100 uut shard'i. Kui logisid ei olnud veel palju, siis klaster suutis sellega toime tulla ning keegi ei pööranud tähelepanu selle seadistamisele.
Kiire kasvu probleemid
Genereeritud logide maht kasvas kiiresti, kuna kahel protsessil oli üksteisele mõju. Ühelt poolt kasvas teenuse kasutajate arv. Teiselt poolt hakkasime aktiivselt liikuma mikroteenuste arhitektuuri suunas, jagades meie vanu monoliite C# ja Pythoni peale. Mitmed tosinad uued mikroteenused, mis asendasid monoliidi osi, genereerisid infrastruktuuri klastri jaoks märgatavalt rohkem logisid.
Just scaling led us to the point where the cluster became almost unmanageable. When logs started coming in at a rate of 20,000 messages per second, frequent useless rotation increased the number of shards to 6,000, with more than 600 shards per node.
This caused issues with memory allocation, and when a node failed, all the shards would be moved simultaneously, multiplying traffic and burdening the remaining nodes, making it nearly impossible to write data to the cluster. During this time, we were without logs. And when there was an issue with serverilt we lost 1/10 of the cluster overall. The large number of small-sized indexes added complexity.
Without logs, we didn’t understand the causes of incidents and could sometime fall into the same traps again, which was unacceptable for our team’s ideology, as all our work mechanisms are set to avoid repeating the same problems. For this, we needed the complete volume of logs delivered almost in real time, since the on-call engineering team monitored alerts not only from metrics but also from logs. To understand the scale of the problem — at that time, the total volume of logs was about 2 TB per day.
We set the task to completely eliminate log loss and reduce the delivery time to the ELK cluster to a maximum of 15 minutes during emergencies (we later relied on this figure as an internal KPI).
New rotation mechanism and hot-warm nodes
We began transforming the cluster by updating the ElasticSearch version from 5.5.2 to 6.4.3. Our cluster of the 5th version crashed again, and we decided to shut it down and completely update it — after all, there were no logs. So we made this transition in just a couple of hours.
Selle etapi kõige ulatuslikumaks muudatuseks oli Apache Kafka juurutamine kolmes sõlmes koordinaatorina vahepealse puhvrina. Sõnumite vahendaja vabastas meid logide kadumise probleemist ElasticSearchiga. Samuti lisasime me klastrisse 2 sõlme ja ülemineku hot-warm arhitektuurile kolme „kuuma” sõlmega, paigutatuna erinevatesse aluskappidest andmekeskuses. Neile suunati logid, mida ei tohtinud mingil juhul kaotada — nginx ja rakenduste vealogid. Ülejäänud sõlmedele suunati vähemolulised logid — debug, warning jne., ja 24 tunni pärast viidi „olulised” logid „kuumadest” sõlmedest edasi.
Selleks, et mitte suurendada väikeste indeksite arvu, läksime ajapõhiselt pöördlöökide mehhanismile. Foorumites oli palju teavet selle kohta, et suuruse järgi pöördlöök on väga ebausaldusväärne, seetõttu otsustasime kasutada pöördlööki dokumentide arvu järgi indeksis. Analüüsisime iga indeksit ja määrasime dokumentide arvu, pärast mille ületamist pöördlöök peab toimuma. Nii saavutasime optimaalse shard'i suuruse — mitte üle 50 GB.
Klastri optimeerimine
Kuid täielikult probleemidest ei vabanenud. Kahjuks ilmnesid ikkagi väikesed indeksid: need ei saavutanud määratud mahtu, ei pöördlöökid ja eemaldati globaalsete indeksite puhastamise kaudu, mis on vanemad kui kolm päeva, kuna olime eemaldanud pöördlöögid kuupäeva järgi. See viis andmete kadumise probleemideni, kuna indeks kadus klastrist täielikult ning katse kirjutada mitteseksisteerivasse indeksisse rikkus meie halduse loogikat, milleks oli curator. Kirjutamine mõeldud alias muutus indeksiks ja rikkus pöördlöögiprotsessi, põhjustades mõnede indeksite kontrollimatut kasvu kuni 600 GB.
Näiteks pöördlöögi konfiguratsiooni jaoks:
curator-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
Rollover aliasi puudumisel tekkis viga:
ERROR alias "nginx_write" not found.
ERROR Failed to complete action: rollover. <type 'exceptions.ValueError'>: Unable to perform index rollover with alias "nginx_write".
Selle probleemi lahendamise jätame järgmisse iteratsiooni ja keskendume muule: oleme üle läinud pull-loogikale, mida haldab Logstash, mis tegeleb sisendlogide töötlemisega (liigse teabe eemaldamine ja rikastamine). Oleme selle paigutanud dockerisse, mida käivitame docker-compose kaudu, ning seal oleme paigutanud logstash-exporteri, mis edastab metrika Prometheusele logivoogude kiireks jälgimiseks. Nii oleme endale võimaldanud sujuvalt muuta logstashide instantside arvu, mis vastutavad iga logitüübi töötlemise eest.
Kuni me täiustasime klastrit, kasvas cian.ru külastatavus 12,8 miljoni unikaalse kasutajani kuus. Tulemuseks oli see, et meie muudatused ei jõudnud veidi produktsiooni muutustega sammu pidada ja seisime silmitsi olukorraga, kus „soe” nood ei suutnud koormusega toime tulla ning pidurdasid kogu logide edastamise. „Küpset” andmed saime probleemideta, kuid ülejäänud edastamisel tuli sekkuda ja teha käsitsi rollover, et jagada indeksid ühtlaselt.
Samas muutis logstashide instantside klastris skaleerimine ja seadistuste muutmine keeruliseks, kuna see oli lokaalne docker-compose ja kõik toimingud viidi läbi käsitsi (uute lõppude lisamiseks tuli kõik serverid käsitsi läbi käia ja igal pool teha docker-compose up -d).
Logide ümberjaotamine
Selle aasta septembris jätkasime endiselt monoliidi lõhkumist, klastrile avaldatud koormus kasvas ja logide voog jõudis 30 000 sõnumini sekundis.
Järgmise iteratsiooni alustasime riistvara värskendamisega. Viie koordinaatori asemel läksime kolme peale, vahetasime välja andme noodid ja võitsime raha ja salvestusmahtu. Noodide jaoks kasutame kahte konfiguratsiooni:
- „Kuumadele” nootidele: E3-1270 v6 / 960Gb SSD / 32 Gb x 3 x 2 (3 Hot1 ja 3 Hot2 jaoks).
- „Soovade” nootidele: E3-1230 v6 / 4Tb SSD / 32 Gb x 4.
Sel iteratsioonil viisime indeksi välja mikrosüsteemide juurdepääsulogidest, mis võtab sama palju ruumi kui esi-nginx logid, teise kolme „kuuma” noodi gruppi. Salvestame „kuumades” noodides andmeid nüüd 20 tundi ja seejärel viime need „soojadesse” teiste logide juurde.
Väikeste indeksite kadumise probleem lahendati nende rotatsiooni seadistamisega. Nüüd rotatsioon toimib igal juhul iga 23 tunni tagant, isegi kui andmeid on vähe. See on veidi suurendanud shardide arvu (nüüd on neid umbes 800), kuid klastrite jõudluse seisukohalt on see vastuvõetav.
Klastris on nüüd kuus „kuuma” ja vaid neli „soe” sõlme. See põhjustab väikest viivitust suure ajaintervalli päringutes, kuid sõlmede arvu suurenemine tulevikus lahendab selle probleemi.
Selles iteratsioonis lahendasime ka poolautomaatse skaleerimise puudumise probleemi. Selleks deploy'ime infrastruktuuri Nomad klastrit — analoogset sellele, mis meil juba tootmises on. Praegu Logstashi arv ei muutu automaatselt vastavalt koormusele, kuid jõuame ka sinna.
Tulevikuplaanid
Teostatud konfiguratsioon skaaleerub suurepäraselt ning praegu salvestame 13,3 TB andmeid — kõik logid nelja päeva jooksul, mis on vajalikud kiireks häirete analüüsiks. Osa logisid muundame meetrikateks, mida kogume Graphite'i. Töö hõlbustamiseks on meil meetrikad infrastruktuuri klastri jaoks ja skriptid tüüpiliste probleemide poolautomaatseks parandamiseks. Pärast järgmise aasta plaanitud andmesõlmede arvu suurenemist ülemineku andmete salvestamisele 4 päevast 7 päevani, mis on piisav operatiivseks tööks, kuna püüame alati uurida juhtumeid võimalikult kiiresti ning pikaajalisteks uurimiseks on hooldusteadlikkuse andmed.
Oktoobris 2019 kasvas cian.ru külastatavus juba 15,3 miljoni unikaalse külastaja kuus. See oli tõsine katse logide edastamise arhitektuurilisest lahendusest.
Praegu valmistume ElasticSearchi versiooni 7 uuendamiseks. Tõsi, selleks tuleb uuendada paljude indeksite mappimist ElasticSearchis, kuna need on üle läinud versioonist 5.5 ja kuulutatud vananenuks versioonis 6 (versioonis 7 ei ole neid lihtsalt olemas). See tähendab, et uuendamise protsessis ei saa me mingil juhul ilma logideta jääda. Versioonist 7 ootame kõige rohkem Kibana't, millel on parendatud liides ja uued filtrid.
Me saavutasime oma põhieesmärgid: loobusime logide kadumisest ja vähendasime infrastruktuuri klastrite seiskamisaega 2-3 katkestusest nädalas paarile tunni teenindustöödele kuus. Kõik see töö ei ole tootmisprotsessis peaaegu märgatav. Kuid nüüd saame täpselt määrata, mis meie teenusega toimub, suudame kiiresti tegutseda rahulikult ja ei pea muretsema, et logid kaovad. Üldiselt oleme rahul, õnnelikud ja valmistume uusiteks saavutusteks, millest räägime hiljem.
Allikas: habr.com
