{"id":53590,"date":"2019-12-05T00:00:00","date_gmt":"2019-12-04T21:00:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/kak-my-v-tsian-ukroshhali-terabajty-logov"},"modified":"2020-02-18T14:01:30","modified_gmt":"2020-02-18T11:01:30","slug":"kak-my-v-tsian-ukroshhali-terabajty-logov","status":"publish","type":"post","link":"https:\/\/prohoster.info\/et\/blog\/administrirovanie\/kak-my-v-tsian-ukroshhali-terabajty-logov","title":{"rendered":"Kuidas me CIAN-is alistame terabaite logisid","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Kuidas
\n
\nTere k\u00f5igile, olen Aleksander, t\u00f6\u00f6tan CIAN-is insenerina ning tegele mul s\u00fcsteemiadministreerimise ja infrastruktuuri protsesside automatiseerimisega. \u00dche eelmise artikli kommentaarides paluti meil r\u00e4\u00e4kida, kust me saame 4 TB logisid p\u00e4evas ja mida me nendega teeme. Jah, meil on palju logisid ja nende t\u00f6\u00f6tlemiseks on loodud eraldi infrastruktuuri klaster, mis v\u00f5imaldab meil kiiresti lahendada probleeme. K\u00e4esolevas artiklis r\u00e4\u00e4gin, kuidas me \u00fche aastaga selle pidevalt kasvava andmevoogiga t\u00f6\u00f6tamiseks kohandasime.
\n<\/a><\/noindex><\/p>\n

Kust me alustasime<\/h3>\n

\n\"Kuidas
\n
\nViimased paar aastat on cian.ru koormus kasvanud v\u00e4ga kiiresti ning 2018. aasta kolmandaks kvartaliks ulatus saidi k\u00fclastatavus 11,2 miljoni unikaalse kasutajani kuus. Sel ajal kaotasime kriitilistel hetkedel kuni 40% logisid, mist\u00f5ttu ei suuda me kiiresti intsidente lahendada ning kulutame neile v\u00e4ga palju aega ja vaeva. Samuti ei suutnud me sageli probleemi p\u00f5hjust leida ning see kordus m\u00f5ne aja p\u00e4rast. See oli peavalu, millega tuli midagi ette v\u00f5tta.<\/p>\n

Sel hetkel kasutasime logide salvestamiseks 10 andmnode Elasticsearch 5.5.2 klastri vaikeseadeid indekseid. See juurutati \u00fcle aasta tagasi populaarse ja taskukohase lahendusena: siis ei olnud logivool nii suur, et oleks m\u00f5tet ebastandardeid konfiguratsioone v\u00e4lja m\u00f5elda.\u00a0<\/p>\n

Saabunud logide t\u00f6\u00f6tlemist tagas Logstash erinevatel portidel viiel Elasticsearch koordineerijatel. Iga indeks, s\u00f5ltumata suurusest, koosnes viiest shardist. Toolik oli korraldatud tunni ja p\u00e4eva rotatsiooniks, mist\u00f5ttu ilmus klastrisse iga tunni jooksul ligikaudu 100 uut shardit. Kuni logisid oli veel mitte v\u00e4ga palju, suutis klaster hakkama saada ja tema seadeid ei m\u00e4rgatud.\u00a0<\/p>\n

Kiire kasvu probleemid<\/h3>\n

\nGenerated logide maht kasvas v\u00e4ga kiiresti, kuna kaks protsessi kattusid. \u00dchest k\u00fcljest kasvas teenuse kasutajate arv pidevalt. Teiselt poolt hakkasime aktiivselt \u00fcleminekutele mikroteenustele, jagades meie vanad monoliidid C# ja Pythonis. Mituk\u00fcmmend uusi mikroteenust, mis asendasid osa monoliidist, genereerisid infrastruktuuri klastri jaoks m\u00e4rgatavalt rohkem logisid.\u00a0<\/p>\n

Just scaling led us to a point where the cluster became almost unmanageable. When logs began to come in at a rate of 20,000 messages per second, frequent unnecessary rotations increased the number of shards to 6,000, and over 600 shards were allocated to each node.\u00a0<\/p>\n

This caused issues with memory allocation, and when a node failed, all shards had to be moved simultaneously, multiplying the traffic and loading the other nodes, making it nearly impossible to write data to the cluster. During this time, we were left without logs. And when there was a problem with serveriga<\/a> we lost 1\/10 of the cluster in general. The large number of small-sized indexes added to the complexity.<\/p>\n

Ilma logideta ei saanud me aru s\u00fcndmuse p\u00f5hjustest ja varem v\u00f5i hiljem oleksime samadele probleemidele uuesti jalaga peale astunud, mis meie meeskonna ideoloogias olid vastuv\u00f5etamatud, kuna k\u00f5ik meie t\u00f6\u00f6 mehhanismid on \u00fcles ehitatud just sellele \u2014 mitte kordama samu probleeme. Selleks vajasime t\u00e4ielikku logide mahtu ja nende edastamist praktiliselt reaalajas, kuna valveinseneride meeskond j\u00e4lgis h\u00e4ireid mitte ainult m\u00f5\u00f5dikutelt, vaid ka logidelt. Probleemi ulatuse m\u00f5istmiseks \u2014 toona oli logide kogumaht umbes 2 TB p\u00e4evas.\u00a0<\/p>\n

Seadsime eesm\u00e4rgiks \u2014 t\u00e4ielikult v\u00e4listada logide kadumine ja v\u00e4hendada nende toimetamise aega ELK-klastrisse maksimaalselt 15 minutini erakorraliste olukordade ajal (sellele numbrile toetudes, saime hiljem sisemises KPI-sse).<\/p>\n

Uus rotatsiooni mehhanism ja kuum-soe s\u00f5lmed<\/h3>\n

\n\"Kuidas
\n
\nKlastri muutmist alustasime ElasticSearchi versiooni uuendamisega 5.5.2-st 6.4.3-ni. Meie 5. versioon krahhas j\u00e4lle, ja otsustasime selle kustutada ja t\u00e4ielikult uuendada \u2014 logide p\u00e4rast pole enam vahet. Nii et selle \u00fclemineku sooritasime vaid paaritunni jooksul.<\/p>\n

Selle etapi k\u00f5ige suurem muudatus oli Apache Kafka juurutamine kolme node'i juures, kus koordinaator toimis vahepevana. S\u00f5numite maakler p\u00e4\u00e4stis meid logide kadumisest ElasticSearch\u2019i probleemide korral. Samal ajal lisasime klastrisse 2 node\u2019i ja l\u00e4ksime \u00fcle hot-warm arhitektuurile, kus oli kolm \"kuuma\" node'i, asetatud erinevatesse rack'idesse andmekeskuses. Neilt suunati edasi logid, mida ei tohtinud mingil juhul kaotada \u2014 nginx, samuti rakenduste vealogid. \u00dclej\u00e4\u00e4nud node\u2019itelt suunati v\u00e4iksemad logid \u2014 debug, warning jms, samuti liikusid 24 tunni p\u00e4rast \u201eolulised\u201c logid \u201ekuumadelt\u201c node'ilt.<\/p>\n

Et mitte suurendada v\u00e4ikeste indeksite arvu, l\u00e4ksime ajarotatsioonilt \u00fcle rollover mehhanismile. Foorumites oli palju teavet selle kohta, et suuruse j\u00e4rgi rotatsioon on v\u00e4ga ebastabiilne, mist\u00f5ttu otsustasime kasutada rotatsiooni indeksis olevate dokumentide arvu j\u00e4rgi. Anal\u00fc\u00fcsisime iga indeksi ja registreerisime dokumentide arvu, mille j\u00e4rel peaks rotatsioon k\u00e4ivituma. Nii saavutame optimaalse shard'i suuruse \u2014 mitte rohkem kui 50 GB.\u00a0<\/p>\n

Klastri optimeerimine<\/h3>\n

\n\"Kuidas
\n
\nKuid me ei ole probleemidest t\u00e4ielikult vabanenud. Kahjuks hakkasid ikkagi ilmuma v\u00e4iksed indeksid: need ei saavutanud m\u00e4\u00e4ratud mahtu, ei roteerunud ja kustutati globaalsete indeksite puhastamisega, mis kestis \u00fcle kolme p\u00e4eva, kuna me eemaldasime kuup\u00e4eva j\u00e4rgi rotateerimise. See p\u00f5hjustas andmete kadumise, kuna indeks klastrist kadus t\u00e4ielikult, ja katse kirjutada mitteeksisteerivasse indeksisse rikkus meie haldust logikat, mida kasutasime. Kirjutamiseks m\u00f5eldud alias muudeti indeksiks ja see rikkus rollover'i loogikat, mis p\u00f5hjustas kontrollimatut m\u00f5ningate indeksite kasvu kuni 600 GB.\u00a0<\/p>\n

N\u00e4iteks p\u00f6\u00f6rdemugava konfiguratsiooni jaoks:<\/p>\n

curator-elk-rollover.yaml\n\n---\nactions:\n  1:\n    action: rollover\n    options:\n      name: \"nginx_write\"\n      conditions:\n        max_docs: 100000000\n  2:\n    action: rollover\n    options:\n      name: \"python_error_write\"\n      conditions:\n        max_docs: 10000000\n<\/code><\/pre>\n
Rollover aliasi puudumise korral tekkis viga:<\/p>\n
ERROR    alias \"nginx_write\" not found.\nERROR    Failed to complete action: rollover.  : Unable to perform index rollover with alias \"nginx_write\".\n<\/code><\/pre>\n
Probleem lahendamine j\u00e4i j\u00e4rgmisse iteratsiooni ja keskendusime muule k\u00fcsimusele: l\u00e4ksime \u00fcle Logstashi pull-loogikale, mis tegeleb sisendi logide t\u00f6\u00f6tlemisega (\u00fclek\u00fcllastumise teabe eemaldamine ja rikastamine). Panime selle Dockerisse, mida k\u00e4itame l\u00e4bi docker-compose, seal asub ka logstash-exporter, mis edastab statistikat Prometheusele logivoo operatiivseks j\u00e4lgimiseks. Nii andsime endale v\u00f5imaluse sujuvalt muuta logstashi instantside arvu, mis vastutavad iga logit\u00fc\u00fcbi t\u00f6\u00f6tlemise eest.<\/p>\n
Samal ajal, kui me klastreid t\u00e4iustasime, kasvas cian.ru k\u00fclastatavus 12,8 miljoni unikaalse kasutajani kuus. Tulemuseks oli see, et meie muudatused j\u00e4id natuke maha tootmisest ja sattusime olukorda, kus 'soojad' nodid ei suuda koormusega hakkama saada ja peatavad kogu logide edastamise. 'K\u00fcsimata' andmed saime probleemideta, kuid \u00fclej\u00e4\u00e4nud kohaletoimetamisse tuli sekkuda ja teostada k\u00e4sitsi rollover, et jaotada indeksid \u00fchtlaselt.\u00a0<\/p>\n
Klastris on kohaliku docker-compose'i t\u00f5ttu keeruline skaleerida ja logstash instantside seadistusi muuta, kuna k\u00f5ik toimingud tuli k\u00e4sitsi teha (uute l\u00f5ppude lisamiseks tuli k\u00e4sitsi l\u00e4bi k\u00e4ia k\u00f5ik serverid ja igal pool teha docker-compose up -d).<\/p>\n
Logide \u00fcmberjaotamine<\/h3>\n
\nSel aastal septembris j\u00e4tkasime monoliidi l\u00f5hkumist, klastrikoormus kasvas ja logide voog l\u00e4henes 30 000 s\u00f5numile sekundis.\u00a0<\/p>\n
\"Kuidas
\n
\nJ\u00e4rgmist iteratsiooni alustasime riistvara v\u00e4rskendamisega. Viielt koordinaatorilt l\u00e4ksime kolmele, vahetasime v\u00e4lja andmeserverid ja s\u00e4\u00e4stsime raha ning mahutavust. Nodide jaoks kasutame kahte konfiguratsiooni:\u00a0<\/p>\n