Halo sadayana, nami abdi Alexander, abdi damel di CIAN salaku insinyur sareng aub dina administrasi sistem sareng otomatisasi prosés infrastruktur. Dina komentar ka salah sahiji artikel saméméhna, kami dipenta pikeun ngabejaan dimana urang meunang 4 TB log per poé sarta naon urang ngalakukeun jeung aranjeunna. Leres, kami ngagaduhan seueur log, sareng klaster infrastruktur anu misah parantos didamel pikeun ngolahna, anu ngamungkinkeun urang gancang ngarengsekeun masalah. Dina artikel ieu kuring bakal ngobrol ngeunaan kumaha urang diadaptasi eta ngaliwatan kursus sataun pikeun digawekeun ku aliran data kantos-tumuwuh.
Dimana urang ngamimitian?
Sapanjang sababaraha taun katukang, beban dina cian.ru parantos ningkat pisan, sareng dina kuartal katilu 2018, lalu lintas sumberdaya ngahontal 11.2 juta pangguna unik per bulan. Dina waktos éta, dina momen kritis urang leungit nepi ka 40% tina log, naha nu mangrupa urang teu bisa gancang nungkulan insiden sarta spent loba waktu jeung usaha resolving aranjeunna. Urang ogé mindeng teu bisa manggihan ngabalukarkeun masalah, sarta eta bakal recur sanggeus sababaraha waktu. Éta naraka sareng hal anu kedah dilakukeun ngeunaan éta.
Dina waktos éta, kami nganggo gugusan 10 titik data sareng versi ElasticSearch 5.5.2 sareng setélan indéks standar pikeun nyimpen log. Ieu diwanohkeun leuwih ti sataun katukang salaku solusi populér tur affordable: lajeng aliran log teu jadi badag, euweuh titik dina datang nepi ka konfigurasi non-standar.
Ngolah log asup disayogikeun ku Logstash dina palabuhan anu béda dina lima koordinator ElasticSearch. Hiji indéks, paduli ukuranana, diwangun ku lima shards. Rotasi per jam sareng poean diayakeun, salaku hasilna, kira-kira 100 beling anyar muncul dina kluster unggal jam. Sanaos henteu seueur pisan log, kluster éta nyerep saé sareng teu aya anu nengetan setélanna.
Tantangan tumuwuhna gancang
Volume log anu dihasilkeun gancang pisan, sabab dua prosés silih tumpang tindih. Di hiji sisi, jumlah pangguna jasa naék. Di sisi séjén, urang mimiti aktip pindah ka arsitéktur microservice, sawing up monoliths heubeul urang dina C # jeung Python. Sababaraha belasan microservices anyar nu ngaganti bagian tina monolith dihasilkeun nyata leuwih log pikeun klaster infrastruktur.
Éta skala anu nyababkeun urang ka titik dimana kluster janten praktis teu tiasa diurus. Nalika log mimiti sumping dina laju 20 rébu pesen per detik, rotasi anu henteu kapake naékkeun jumlah beling ka 6 rébu, sareng aya langkung ti 600 beling per node.
Ieu nyababkeun masalah sareng alokasi RAM, sareng nalika titik nabrak, sadaya beling mimiti ngalih sakaligus, ngalikeun lalu lintas sareng ngamuat titik-titik anu sanés, anu matak ampir teu mungkin pikeun nyerat data kana kluster. Sarta dina mangsa ieu kami ditinggalkeun tanpa log. Tur upami aya masalah jeung server, urang dasarna leungit 1/10 tina klaster. Sajumlah ageung indéks leutik nambihan pajeulitna.
Tanpa log, urang henteu ngartos alesan pikeun kajadian éta sareng engké atanapi engké tiasa ngaléngkah deui kana rake anu sami, sareng dina idéologi tim kami ieu henteu katampi, sabab sadaya mékanisme padamelan urang dirancang pikeun ngalakukeun sabalikna - henteu kantos ngulang deui. masalah anu sarua. Jang ngalampahkeun ieu, urang diperlukeun volume pinuh log sarta pangiriman maranéhanana ampir sacara real waktu, saprak tim insinyur on-tugas diawaskeun ngabejaan teu ukur tina métrik, tapi ogé tina log. Pikeun ngartos skala masalah, dina waktos éta volume total log sakitar 2 TB per dinten.
Urang nangtukeun tujuan pikeun sakabéhna ngaleungitkeun leungitna log sarta ngurangan waktu pangiriman maranéhna pikeun klaster ELK ka maksimum 15 menit salila force majeure (urang engké ngandelkeun inohong ieu salaku KPI internal).
mékanisme rotasi anyar jeung titik panas-haneut
Urang ngamimitian konvérsi klaster ku ngamutahirkeun versi ElasticSearch tina 5.5.2 ka 6.4.3. Sakali deui klaster versi 5 urang maot, sareng urang mutuskeun pikeun mareuman sareng ngapdet lengkep - masih teu aya log. Janten urang ngadamel transisi ieu ngan ukur sababaraha jam.
Transformasi anu paling ageung dina tahap ieu nyaéta palaksanaan Apache Kafka dina tilu titik kalayan koordinator salaku panyangga perantara. Calo pesen nyalametkeun urang tina kaleungitan log nalika aya masalah sareng ElasticSearch. Dina waktos anu sami, kami nambihan 2 titik kana kluster sareng ngalih ka arsitéktur panas-panas sareng tilu titik "panas" anu aya dina rak anu béda dina pusat data. Kami dialihkeun log ka aranjeunna nganggo masker anu henteu kedah leungit dina kaayaan naon waé - nginx, ogé log kasalahan aplikasi. Log minor dikirim ka titik sésana - debug, peringatan, sareng sajabana, sareng saatos 24 jam, log "penting" tina titik "panas" ditransfer.
Dina raraga teu nambahan jumlah indéks leutik, urang switched ti rotasi waktos ka mékanisme rollover. Aya seueur inpormasi dina forum yén rotasi ku ukuran indéks henteu tiasa dipercaya, janten kami mutuskeun pikeun nganggo rotasi ku jumlah dokumén dina indéks. Kami nganalisa unggal indéks sareng ngarékam jumlah dokumén saatos rotasi kedah jalan. Ku kituna, urang geus ngahontal ukuran beling optimal - teu leuwih ti 50 GB.
Optimasi klaster
Najan kitu, urang teu sagemblengna meunang leupas tina masalah. Hanjakalna, indéks leutik masih némbongan: aranjeunna henteu ngahontal volume anu ditangtukeun, henteu diputar, sareng dihapus ku beberesih global tina indéks langkung lami ti tilu dinten, saprak urang ngahapus rotasi dumasar kana tanggal. Ieu ngakibatkeun leungitna data alatan kanyataan yén indéks tina klaster ngiles lengkep, sarta usaha nulis ka indéks non-existent peupeus logika curator nu urang dipaké pikeun manajemén. Alias pikeun tulisan dirobih kana indéks sareng ngarobih logika rollover, nyababkeun pertumbuhan anu teu terkendali tina sababaraha indéks dugi ka 600 GB.
Contona, pikeun konfigurasi rotasi:
с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
Upami teu aya alias rollover, aya kasalahan:
ERROR alias "nginx_write" not found.
ERROR Failed to complete action: rollover. <type 'exceptions.ValueError'>: Unable to perform index rollover with alias "nginx_write".
Urang ninggalkeun solusi pikeun masalah ieu pikeun Iteration salajengna jeung nyandak up masalah sejen: urang pindah kana logika tarik Logstash, nu ngolah log asup (nyoplokkeun informasi perlu jeung enriching). Kami nempatkeun éta dina docker, anu kami luncurkeun via docker-compose, sareng kami ogé nempatkeun logstash-eksportir di dinya, anu ngirimkeun métrik ka Prometheus pikeun ngawaskeun operasional aliran log. Ku cara ieu kami masihan kasempetan pikeun ngarobih jumlah instansi logstash anu tanggung jawab pikeun ngolah unggal jinis log.
Nalika kami ningkatkeun kluster, lalu lintas cian.ru ningkat kana 12,8 juta pangguna unik per bulan. Hasilna, tétéla yén transformasi urang rada balik parobahan produksi, sarta kami Nyanghareupan kanyataan yén titik "haneut" teu bisa Cope jeung beban sarta ngalambatkeun turun sakabéh pangiriman log. Kami nampi data "panas" tanpa gagal, tapi urang kedah campur dina pangiriman sésana sareng ngalakukeun rollover manual supados merata ngadistribusikaeun indéks.
Dina waktos anu sami, skala sareng ngarobih setélan instansi logstash dina kluster pajeulit ku kanyataan yén éta mangrupikeun docker-compose lokal, sareng sadaya tindakan dilaksanakeun sacara manual (pikeun nambihan tungtung énggal, éta kedah sacara manual ngaliwat sadayana. server sareng docker-compose up -d dimana-mana).
Redistribusi log
Dina Séptémber taun ieu, urang masih motong up monolith nu, beban dina klaster ngaronjat, sarta aliran log ieu approaching 30 sarébu pesen per detik.
Urang ngamimitian iteration salajengna ku update hardware. Urang switched tina lima koordinator ka tilu, ngaganti titik data jeung meunang dina hal duit jeung gudang. Pikeun titik kami nganggo dua konfigurasi:
- Pikeun titik "panas": E3-1270 v6 / 960Gb SSD / 32 Gb x 3 x 2 (3 pikeun Hot1 jeung 3 pikeun Hot2).
- Pikeun titik "haneut": E3-1230 v6 / 4Tb SSD / 32 Gb x 4.
Dina iterasi ieu, urang mindahkeun indéks jeung aksés log of microservices, nu nyokot up spasi sarua salaku hareup-garis nginx log, ka grup kadua tilu titik "panas". Urang ayeuna nyimpen data dina titik "panas" pikeun 20 jam, lajeng mindahkeun aranjeunna ka titik "haneut" ka sesa log.
Urang direngsekeun masalah indéks leutik ngaleungit ku reconfiguring rotasi maranéhna. Ayeuna indéksna diputer unggal 23 jam dina sagala hal, sanaos aya sakedik data di dinya. Ieu rada ngaronjat jumlah shards (aya ngeunaan 800 sahijina), tapi tina sudut pandang kinerja klaster éta lumayan.
Hasilna, aya genep "panas" na ngan opat "haneut" titik dina klaster. Ieu ngabalukarkeun reureuh slight on requests leuwih interval lila, tapi ngaronjatna jumlah titik dina mangsa nu bakal datang bakal ngajawab masalah ieu.
Iteration ieu ogé ngalereskeun masalah kurangna skala semi-otomatis. Jang ngalampahkeun ieu, kami nyebarkeun kluster Nomad infrastruktur - sami sareng anu kami parantos dipasang dina produksi. Pikeun ayeuna, jumlah Logstash henteu otomatis robih gumantung kana beban, tapi urang bakal dugi ka ieu.
Rencana pikeun mangsa nu bakal datang
Skala konfigurasi anu dilaksanakeun sampurna, sareng ayeuna urang nyimpen 13,3 TB data - sadayana log salami 4 dinten, anu dipikabutuh pikeun analisa darurat peringatan. Kami ngarobih sababaraha log kana métrik, anu kami tambahkeun kana Grafit. Pikeun ngagampangkeun pagawéan insinyur, kami gaduh métrik pikeun klaster infrastruktur sareng skrip pikeun perbaikan semi-otomatis masalah umum. Saatos ningkatkeun jumlah titik data, anu direncanakeun pikeun taun payun, urang bakal ngalih ka panyimpenan data tina 4 dugi ka 7 dinten. Ieu bakal cukup pikeun digawé operasional, sabab urang salawasna coba pikeun nalungtik kajadian pas mungkin, sarta pikeun panalungtikan jangka panjang aya data telemetry.
Dina Oktober 2019, lalu lintas ka cian.ru parantos ningkat kana 15,3 juta pangguna unik per bulan. Ieu janten uji serius ngeunaan solusi arsitéktur pikeun nganteurkeun log.
Ayeuna urang Nyiapkeun pikeun ngapdet ElasticSearch kana versi 7. Tapi, pikeun ieu urang kudu ngamutahirkeun pemetaan loba indexes di ElasticSearch, saprak maranéhna dipindahkeun tina versi 5.5 sarta dinyatakeun salaku deprecated dina versi 6 (aranjeunna ngan saukur teu aya dina versi. 7). Ieu ngandung harti yén salila prosés update pasti bakal aya sababaraha jenis force majeure, nu bakal ninggalkeun urang tanpa log bari masalah ieu direngsekeun. Tina versi 7, kami paling ngarepkeun Kibana kalayan antarmuka anu ningkat sareng saringan énggal.
Kami ngahontal tujuan utama: urang lirén kaleungitan log sareng ngirangan downtime klaster infrastruktur tina 2-3 kacilakaan per minggu ka sababaraha jam gawé pangropéa per bulan. Sadaya karya ieu dina produksi ampir teu katingali. Nanging, ayeuna urang tiasa nangtoskeun naon anu kajantenan sareng jasa kami, urang tiasa gancang ngalakukeunana dina modeu sepi sareng henteu hariwang yén log bakal leungit. Sacara umum, urang wareg, senang jeung Nyiapkeun pikeun eksploitasi anyar, nu urang bakal ngobrol engké.
sumber: www.habr.com