Hallo elkenien, myn namme is Alexander, ik wurkje by CIAN as yngenieur en bin belutsen by systeemadministraasje en automatisearring fan ynfrastruktuerprosessen. Yn 'e opmerkingen foar ien fan' e foarige artikels waarden wy frege om te fertellen wêr't wy 4 TB oan logs per dei krije en wat wy mei har dogge. Ja, wy hawwe in protte logs, en in aparte ynfrastruktuerkluster is makke om se te ferwurkjen, wêrtroch wy problemen fluch kinne oplosse. Yn dit artikel sil ik prate oer hoe't wy it yn 'e rin fan in jier oanpast hawwe om te wurkjen mei in hieltyd groeiende stream fan gegevens.
Wêr binne wy begûn?
Yn 'e ôfrûne jierren is de lading op cian.ru heul fluch groeid, en troch it tredde fearnsjier fan 2018 berikte boarneferkear 11.2 miljoen unike brûkers per moanne. Op dat stuit ferlearen wy op krityske mominten oant 40% fan 'e logs, dat is de reden wêrom't wy net fluch koenen omgean mei ynsidinten en in protte tiid en muoite bestege oan it oplossen. Wy koenen ek faak de oarsaak fan it probleem net fine, en it soe nei in skoftke weromkomme. It wie in hel en der moast wat oan dien wurde.
Op dat stuit brûkten wy in kluster fan 10 gegevensknooppunten mei ElasticSearch ferzje 5.5.2 mei standert yndeksynstellingen om logs op te slaan. It waard mear as in jier lyn yntrodusearre as in populêre en betelbere oplossing: doe wie de stream fan logs net sa grut, der wie gjin punt om te kommen mei net-standert konfiguraasjes.
Ferwurking fan ynkommende logs waard levere troch Logstash op ferskate havens op fiif ElasticSearch-koördinatoren. Ien yndeks, nettsjinsteande grutte, bestie út fiif shards. Der waard in oere- en deistige rotaasje organisearre, dêrtroch ferskynden der alle oeren sa'n 100 nije skerpen yn it kluster. Hoewol d'r net in protte logs wiene, koe it kluster goed en gjinien joech oandacht oan har ynstellingen.
De útdagings fan rappe groei
It folume fan oanmakke logs groeide heul fluch, om't twa prosessen inoar oerlappe. Oan 'e iene kant groeide it oantal brûkers fan' e tsjinst. Oan 'e oare kant begûnen wy aktyf te wikseljen nei in mikroservice-arsjitektuer, en seagen ús âlde monoliten yn C # en Python. Ferskate tsientallen nije mikrotsjinsten dy't dielen fan 'e monolit ferfongen, generearren signifikant mear logs foar it ynfrastruktuerkluster.
It wie skaalfergrutting dy't ús liede ta it punt dêr't it kluster praktysk net te behearjen waard. Doe't de logs begon te kommen mei in taryf fan 20 tûzen berjochten per sekonde, fergrutte faak nutteleaze rotaasje it oantal shards nei 6 tûzen, en d'r wiene mear as 600 shards per knooppunt.
Dit late ta problemen mei de tawizing fan RAM, en doe't in knooppunt ferûngelokke, begûnen alle shards tagelyk te bewegen, it fermannichfâldigjen fan ferkear en it laden fan oare knopen, wat it hast ûnmooglik makke om gegevens nei it kluster te skriuwen. En yn dizze perioade bleaunen wy sûnder logs. En as der in probleem wie mei de tsjinner, hawwe wy yn prinsipe 1/10 fan it kluster ferlern. In grut oantal lytse yndeksen tafoege kompleksiteit.
Sûnder logboeken begrepen wy de redenen foar it ynsidint net en koenen ier of letter wer op deselde rake stappe, en yn 'e ideology fan ús team wie dit net akseptabel, om't al ús wurkmeganismen ûntwurpen binne om krekt it tsjinoerstelde te dwaan - nea werhelje deselde problemen. Om dit te dwaan, hawwe wy it folsleine folume fan logs en har levering hast yn realtime nedich, om't in team fan yngenieurs op plicht warskôgings kontrolearre net allinich fan metriken, mar ek fan logs. Om de skaal fan it probleem te begripen, wie op dat stuit it totale folume fan logs sawat 2 TB per dei.
Wy sette in doel om it ferlies fan logs folslein te eliminearjen en de tiid fan har levering oan it ELK-kluster te ferminderjen oant maksimaal 15 minuten by oermacht (wy hawwe letter op dizze sifer fertroud as in ynterne KPI).
Nije rotaasjemeganisme en waarm-waarme knopen
Wy begûnen de klusterkonverzje troch it bywurkjen fan de ElasticSearch-ferzje fan 5.5.2 nei 6.4.3. Noch ien kear ferstoar ús ferzje 5-kluster, en wy besletten it út te skeakeljen en it folslein te aktualisearjen - d'r binne noch gjin logs. Dat wy makken dizze oergong yn mar in pear oeren.
De meast grutskalige transformaasje op dit poadium wie de ymplemintaasje fan Apache Kafka op trije knopen mei in koördinator as in tuskenbuffer. De berjochtmakelaar rêde ús fan it ferliezen fan logs by problemen mei ElasticSearch. Tagelyk hawwe wy 2-knooppunten tafoege oan it kluster en wikselje oer nei in heul waarme arsjitektuer mei trije "hot" knopen dy't yn ferskate rekken yn it datasintrum lizze. Wy hawwe logs nei har omlaat mei in masker dat ûnder gjin omstannichheden ferlern moat wurde - nginx, lykas applikaasjeflaterlogs. Lytse logs waarden stjoerd nei de oerbleaune knopen - debug, warskôging, ensfh., En nei 24 oeren waarden "wichtige" logs fan "hot" knopen oerdroegen.
Om it oantal lytse yndeksen net te ferheegjen, wikselje wy fan tiidrotaasje nei it rollovermeganisme. D'r wie in protte ynformaasje op 'e foarums dat rotaasje troch yndeksgrutte tige ûnbetrouber is, dus wy besletten om rotaasje te brûken troch it oantal dokuminten yn' e yndeks. Wy analysearren elke yndeks en registrearre it oantal dokuminten wêrnei't rotaasje moat wurkje. Sa hawwe wy berikt de optimale shard grutte - net mear as 50 GB.
Cluster optimisaasje
Wy hawwe de problemen lykwols net hielendal kwyt. Spitigernôch ferskynden der noch lytse yndeksen: se berikten it opjûne folume net, waarden net rotearre en waarden wiske troch wrâldwide skjinmeitsjen fan yndeksen âlder dan trije dagen, om't wy rotaasje op datum fuortsmiten hawwe. Dit late ta gegevensferlies troch it feit dat de yndeks fan it kluster folslein ferdwûn, en in besykjen om te skriuwen nei in net-besteande yndeks bruts de logika fan 'e kurator dy't wy brûkten foar behear. Alias foar skriuwen waard omboud ta in yndeks en bruts de rollover logika, wêrtroch ûnkontrolearre groei fan guon yndeksen oant 600 GB.
Bygelyks, foar de rotaasje konfiguraasje:
с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 der gjin rollover alias wie, barde in flater:
ERROR alias "nginx_write" not found.
ERROR Failed to complete action: rollover. <type 'exceptions.ValueError'>: Unable to perform index rollover with alias "nginx_write".
Wy lieten de oplossing foar dit probleem foar de folgjende iteraasje en namen in oar probleem op: wy skeakelen oer nei de pull-logika fan Logstash, dy't ynkommende logs ferwurket (ûnnedige ynformaasje ferwiderje en ferrykjen). Wy pleatsten it yn docker, dy't wy lansearje fia docker-compose, en wy pleatsten dêr ek logstash-eksporter, dy't metriken nei Prometheus stjoert foar operasjonele tafersjoch fan 'e logstream. Op dizze manier joegen wy ússels de kâns om it oantal logstash-ynstânsjes soepel te feroarjen dat ferantwurdlik is foar it ferwurkjen fan elk type log.
Wylst wy it kluster ferbetterje, groeide it ferkear fan cian.ru nei 12,8 miljoen unike brûkers per moanne. As gefolch, it die bliken dat ús transformaasjes wiene in bytsje efter de feroarings yn produksje, en wy waarden konfrontearre mei it feit dat de "waarme" knopen koenen net omgaan met de lading en fertrage de hiele levering fan logs. Wy krigen "hot" gegevens sûnder mislearrings, mar wy moasten yngripe yn 'e levering fan' e rest en in manuele rollover dwaan om de yndeksen evenredich te fersprieden.
Tagelyk waard skaalfergrutting en feroarjen fan de ynstellings fan logstash-eksimplaren yn it kluster komplisearre troch it feit dat it in lokale docker-compose wie, en alle aksjes waarden mei de hân útfierd (om nije einen ta te foegjen, wie it nedich om troch alle hân te gean de servers en oeral docker-compose up -d).
Log werferdieling
Yn septimber fan dit jier wiene wy noch de monolith te snijen, de lading op 'e kluster gie ta, en de stream fan logs kaam oan 30 tûzen berjochten per sekonde.
Wy begûnen de folgjende iteraasje mei in hardware update. Wy wikselje fan fiif koördinators nei trije, ferfongen gegevens nodes en wûn yn termen fan jild en opslachromte. Foar knooppunten brûke wy twa konfiguraasjes:
- Foar "hot" knopen: E3-1270 v6 / 960Gb SSD / 32 Gb x 3 x 2 (3 foar Hot1 en 3 foar Hot2).
- Foar "waarme" knopen: E3-1230 v6 / 4Tb SSD / 32 Gb x 4.
By dizze iteraasje ferpleatse wy de yndeks mei tagongslogs fan mikrotsjinsten, dy't deselde romte ynnimt as frontline nginx-logs, nei de twadde groep fan trije "hot" knopen. Wy bewarje no gegevens op "hot" knopen foar 20 oeren, en ferpleatse se dan nei "waarme" knopen nei de rest fan 'e logs.
Wy hawwe it probleem oplost fan ferdwinen fan lytse yndeksen troch har rotaasje opnij te konfigurearjen. No wurde de yndeksen yn alle gefallen elke 23 oeren rotearre, sels as d'r in bytsje gegevens binne. Dit ferhege it oantal shards in bytsje (d'r wiene sa'n 800), mar út it eachpunt fan klusterprestaasjes is it tolerabel.
As gefolch wiene d'r seis "waarme" en mar fjouwer "waarme" knopen yn it kluster. Dit soarget foar in lichte fertraging op oanfragen oer lange tiid yntervallen, mar it fergrutsjen fan it oantal knopen yn 'e takomst sil dit probleem oplosse.
Dizze iteraasje befestige ek it probleem fan it gebrek oan semi-automatyske skaalfergrutting. Om dit te dwaan, hawwe wy in ynfrastruktuer Nomad-kluster ynset - fergelykber mei wat wy al yn produksje hawwe ynset. Foar no feroaret it bedrach fan Logstash net automatysk ôfhinklik fan 'e lading, mar wy komme hjirop.
Plannen foar de takomst
De ymplementearre konfiguraasje skalen perfekt, en no bewarje wy 13,3 TB oan gegevens - alle logs foar 4 dagen, wat nedich is foar needanalyse fan warskôgings. Wy konvertearje guon fan 'e logs yn metriken, dy't wy tafoegje oan Graphite. Om it wurk fan yngenieurs makliker te meitsjen, hawwe wy metriken foar it ynfrastruktuerkluster en skripts foar semy-automatyske reparaasje fan mienskiplike problemen. Nei it fergrutsjen fan it oantal gegevensknooppunten, dat foar takom jier pland is, sille wy oerstappe nei gegevensopslach fan 4 nei 7 dagen. Dit sil genôch wêze foar operasjoneel wurk, om't wy altyd besykje ynsidinten sa gau mooglik te ûndersiikjen, en foar lange termynûndersiken binne telemetriegegevens.
Yn oktober 2019 wie ferkear nei cian.ru al groeid nei 15,3 miljoen unike brûkers per moanne. Dit waard in serieuze test fan 'e arsjitektoanyske oplossing foar it leverjen fan logs.
No binne wy tariede om ElasticSearch te aktualisearjen nei ferzje 7. Hjirfoar sille wy lykwols de mapping fan in protte yndeksen yn ElasticSearch moatte bywurkje, om't se ferhuze fan ferzje 5.5 en waarden ferklearre as ferâldere yn ferzje 6 (se besteane gewoan net yn ferzje 7). Dit betsjut dat d'r tidens it fernijingsproses perfoarst in soarte fan oermacht sil wêze, dy't ús sûnder logs litte sil wylst it probleem is oplost. Fan ferzje 7 sjogge wy it meast út nei Kibana mei in ferbettere ynterface en nije filters.
Wy hawwe ús haaddoel berikt: wy stopje mei it ferliezen fan logs en fermindere de downtime fan it ynfrastruktuerkluster fan 2-3 crashes per wike nei in pear oeren ûnderhâldswurk yn 'e moanne. Al dit wurk yn produksje is hast ûnsichtber. No kinne wy lykwols krekt bepale wat der bart mei ús tsjinst, wy kinne it fluch dwaan yn in stille modus en gjin soargen dat de logs ferlern gean. Yn 't algemien binne wy tefreden, lokkich en tariede op nije eksploaten, wêr't wy letter oer prate.
Boarne: www.habr.com