Hello semua, nama saya Alexander, saya bekerja di CIAN sebagai jurutera dan terlibat dalam pentadbiran sistem dan automasi proses infrastruktur. Dalam ulasan kepada salah satu artikel sebelumnya, kami diminta untuk memberitahu di mana kami mendapat 4 TB log setiap hari dan apa yang kami lakukan dengannya. Ya, kami mempunyai banyak log, dan kluster infrastruktur yang berasingan telah dibuat untuk memprosesnya, yang membolehkan kami menyelesaikan masalah dengan cepat. Dalam artikel ini saya akan bercakap tentang cara kami menyesuaikannya sepanjang tahun untuk bekerja dengan aliran data yang semakin meningkat.
Di mana kita bermula?
Sejak beberapa tahun kebelakangan ini, beban pada cian.ru telah berkembang dengan sangat cepat, dan menjelang suku ketiga 2018, trafik sumber mencapai 11.2 juta pengguna unik setiap bulan. Pada masa itu, pada saat-saat genting kami kehilangan sehingga 40% daripada log, itulah sebabnya kami tidak dapat menangani insiden dengan cepat dan menghabiskan banyak masa dan usaha untuk menyelesaikannya. Kami juga sering tidak dapat mencari punca masalah, dan ia akan berulang selepas beberapa ketika. Ia adalah neraka dan sesuatu perlu dilakukan mengenainya.
Pada masa itu, kami menggunakan gugusan 10 nod data dengan ElasticSearch versi 5.5.2 dengan tetapan indeks standard untuk menyimpan log. Ia telah diperkenalkan lebih setahun yang lalu sebagai penyelesaian yang popular dan berpatutan: maka aliran log tidak begitu besar, tidak ada gunanya untuk menghasilkan konfigurasi bukan standard.
Pemprosesan log masuk disediakan oleh Logstash pada port berbeza pada lima penyelaras ElasticSearch. Satu indeks, tanpa mengira saiz, terdiri daripada lima serpihan. Putaran setiap jam dan harian telah dianjurkan, hasilnya, kira-kira 100 serpihan baru muncul dalam kelompok setiap jam. Walaupun tidak terdapat banyak log, kluster itu dapat mengatasi dengan baik dan tiada siapa yang memberi perhatian kepada tetapannya.
Cabaran pertumbuhan pesat
Jumlah log yang dijana berkembang dengan sangat cepat, kerana dua proses bertindih antara satu sama lain. Di satu pihak, bilangan pengguna perkhidmatan itu bertambah. Sebaliknya, kami mula beralih secara aktif kepada seni bina perkhidmatan mikro, menggergaji monolit lama kami dalam C# dan Python. Beberapa dozen perkhidmatan mikro baharu yang menggantikan bahagian monolit menghasilkan lebih banyak log untuk kluster infrastruktur.
Penskalaan yang membawa kami ke titik di mana kluster menjadi hampir tidak terurus. Apabila log mula tiba pada kadar 20 ribu mesej sesaat, putaran yang tidak berguna yang kerap meningkatkan bilangan serpihan kepada 6 ribu, dan terdapat lebih daripada 600 serpihan setiap nod.
Ini membawa kepada masalah dengan peruntukan RAM, dan apabila nod terhempas, semua serpihan mula bergerak serentak, mendarabkan trafik dan memuatkan nod lain, yang menjadikannya hampir mustahil untuk menulis data ke kluster. Dan dalam tempoh ini kami ditinggalkan tanpa balak. Dan jika terdapat masalah dengan pelayan, kami pada dasarnya kehilangan 1/10 kluster. Sebilangan besar indeks kecil menambah kerumitan.
Tanpa log, kami tidak memahami sebab kejadian itu dan lambat laun boleh memijak rake yang sama sekali lagi, dan dalam ideologi pasukan kami ini tidak boleh diterima, kerana semua mekanisme kerja kami direka untuk melakukan sebaliknya - jangan sekali-kali mengulangi masalah yang sama. Untuk melakukan ini, kami memerlukan jumlah penuh log dan penghantarannya hampir dalam masa nyata, memandangkan pasukan jurutera bertugas memantau makluman bukan sahaja daripada metrik, tetapi juga daripada log. Untuk memahami skala masalah, pada masa itu jumlah isipadu log adalah kira-kira 2 TB sehari.
Kami menetapkan matlamat untuk menghapuskan kehilangan log sepenuhnya dan mengurangkan masa penghantarannya ke kelompok ELK kepada maksimum 15 minit semasa force majeure (kami kemudiannya bergantung pada angka ini sebagai KPI dalaman).
Mekanisme putaran baharu dan nod panas-panas
Kami memulakan penukaran kluster dengan mengemas kini versi ElasticSearch daripada 5.5.2 kepada 6.4.3. Sekali lagi kluster versi 5 kami mati, dan kami memutuskan untuk mematikannya dan mengemas kini sepenuhnya - masih tiada log. Jadi kami membuat peralihan ini dalam beberapa jam sahaja.
Transformasi berskala paling besar pada peringkat ini ialah pelaksanaan Apache Kafka pada tiga nod dengan penyelaras sebagai penimbal perantaraan. Broker mesej menyelamatkan kami daripada kehilangan log semasa masalah dengan ElasticSearch. Pada masa yang sama, kami menambah 2 nod pada kluster dan bertukar kepada seni bina panas-panas dengan tiga nod "panas" yang terletak di rak berbeza di pusat data. Kami mengalihkan log kepada mereka menggunakan topeng yang tidak boleh hilang dalam apa jua keadaan - nginx, serta log ralat aplikasi. Log kecil dihantar ke nod yang tinggal - nyahpepijat, amaran, dsb., dan selepas 24 jam, log "penting" daripada nod "panas" dipindahkan.
Untuk tidak menambah bilangan indeks kecil, kami beralih daripada putaran masa kepada mekanisme peralihan. Terdapat banyak maklumat di forum bahawa putaran mengikut saiz indeks sangat tidak boleh dipercayai, jadi kami memutuskan untuk menggunakan putaran mengikut bilangan dokumen dalam indeks. Kami menganalisis setiap indeks dan merekodkan bilangan dokumen selepas itu penggiliran harus berfungsi. Oleh itu, kami telah mencapai saiz serpihan yang optimum - tidak lebih daripada 50 GB.
Pengoptimuman kluster
Walau bagaimanapun, kami belum menyingkirkan sepenuhnya masalah itu. Malangnya, indeks kecil masih muncul: mereka tidak mencapai volum yang ditentukan, tidak diputar dan dipadamkan oleh pembersihan global indeks yang lebih lama daripada tiga hari, kerana kami mengalih keluar putaran mengikut tarikh. Ini membawa kepada kehilangan data kerana fakta bahawa indeks daripada kluster hilang sepenuhnya, dan percubaan untuk menulis kepada indeks yang tidak wujud telah memecahkan logik kurator yang kami gunakan untuk pengurusan. Alias ββuntuk menulis telah ditukar kepada indeks dan memecahkan logik peralihan, menyebabkan pertumbuhan tidak terkawal beberapa indeks sehingga 600 GB.
Sebagai contoh, untuk konfigurasi putaran:
Ρ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
Jika tiada alias peralihan, ralat berlaku:
ERROR alias "nginx_write" not found.
ERROR Failed to complete action: rollover. <type 'exceptions.ValueError'>: Unable to perform index rollover with alias "nginx_write".
Kami meninggalkan penyelesaian kepada masalah ini untuk lelaran seterusnya dan mengambil satu lagi isu: kami beralih kepada logik tarik Logstash, yang memproses log masuk (mengalih keluar maklumat yang tidak perlu dan memperkaya). Kami meletakkannya dalam docker, yang kami lancarkan melalui docker-compose, dan kami juga meletakkan logstash-exporter di sana, yang menghantar metrik kepada Prometheus untuk pemantauan operasi aliran log. Dengan cara ini kami memberi diri kami peluang untuk menukar bilangan kejadian logstash dengan lancar yang bertanggungjawab untuk memproses setiap jenis log.
Semasa kami menambah baik kluster, trafik cian.ru meningkat kepada 12,8 juta pengguna unik setiap bulan. Akibatnya, ternyata transformasi kami sedikit di belakang perubahan dalam pengeluaran, dan kami berhadapan dengan fakta bahawa nod "hangat" tidak dapat menampung beban dan memperlahankan keseluruhan penghantaran log. Kami menerima data "panas" tanpa kegagalan, tetapi kami terpaksa campur tangan dalam penghantaran yang lain dan melakukan peralihan manual untuk mengagihkan indeks secara sama rata.
Pada masa yang sama, penskalaan dan menukar tetapan kejadian logstash dalam kluster adalah rumit oleh fakta bahawa ia adalah karang docker tempatan, dan semua tindakan dilakukan secara manual (untuk menambah hujung baharu, anda perlu menyemak semua secara manual. pelayan dan lakukan docker-compose up -d di mana-mana).
Pengagihan semula log
Pada bulan September tahun ini, kami masih memotong monolit, beban pada kelompok semakin meningkat, dan aliran log menghampiri 30 ribu mesej sesaat.
Kami memulakan lelaran seterusnya dengan kemas kini perkakasan. Kami bertukar daripada lima penyelaras kepada tiga, menggantikan nod data dan menang dari segi wang dan ruang storan. Untuk nod kami menggunakan dua konfigurasi:
- Untuk nod "panas": E3-1270 v6 / 960Gb SSD / 32 Gb x 3 x 2 (3 untuk Hot1 dan 3 untuk Hot2).
- Untuk nod "hangat": E3-1230 v6 / 4Tb SSD / 32 Gb x 4.
Pada lelaran ini, kami mengalihkan indeks dengan log akses perkhidmatan mikro, yang menggunakan ruang yang sama seperti log nginx barisan hadapan, ke kumpulan kedua tiga nod "panas". Kami kini menyimpan data pada nod "panas" selama 20 jam, dan kemudian memindahkannya ke nod "panas" ke seluruh log.
Kami menyelesaikan masalah indeks kecil yang hilang dengan mengkonfigurasi semula putarannya. Sekarang indeks diputar setiap 23 jam dalam apa jua keadaan, walaupun terdapat sedikit data di sana. Ini sedikit meningkatkan bilangan serpihan (terdapat kira-kira 800 daripadanya), tetapi dari sudut prestasi kluster ia boleh diterima.
Akibatnya, terdapat enam nod "panas" dan hanya empat "panas" dalam kelompok. Ini menyebabkan sedikit kelewatan pada permintaan dalam selang masa yang lama, tetapi meningkatkan bilangan nod pada masa hadapan akan menyelesaikan masalah ini.
Lelaran ini juga membetulkan masalah kekurangan penskalaan separa automatik. Untuk melakukan ini, kami menggunakan kluster Nomad infrastruktur - serupa dengan apa yang telah kami gunakan dalam pengeluaran. Buat masa ini, jumlah Logstash tidak berubah secara automatik bergantung pada beban, tetapi kami akan sampai ke sini.
ΠΠ»Π°Π½Ρ Π½Π° Π±ΡΠ΄ΡΡΠ΅Π΅
Skala konfigurasi yang dilaksanakan dengan sempurna, dan kini kami menyimpan 13,3 TB data - semua log selama 4 hari, yang diperlukan untuk analisis kecemasan makluman. Kami menukar beberapa log kepada metrik, yang kami tambahkan kepada Grafit. Untuk memudahkan kerja jurutera, kami mempunyai metrik untuk kluster infrastruktur dan skrip untuk pembaikan separa automatik bagi masalah biasa. Selepas menambah bilangan nod data, yang dirancang untuk tahun depan, kami akan beralih kepada storan data dari 4 hingga 7 hari. Ini akan mencukupi untuk kerja operasi, kerana kami sentiasa cuba menyiasat insiden secepat mungkin, dan untuk penyiasatan jangka panjang terdapat data telemetri.
Pada Oktober 2019, trafik ke cian.ru telah meningkat kepada 15,3 juta pengguna unik setiap bulan. Ini menjadi ujian serius terhadap penyelesaian seni bina untuk menghantar log.
Kini kami sedang bersedia untuk mengemas kini ElasticSearch kepada versi 7. Walau bagaimanapun, untuk ini, kami perlu mengemas kini pemetaan banyak indeks dalam ElasticSearch, kerana ia telah berpindah dari versi 5.5 dan telah diisytiharkan sebagai tidak digunakan dalam versi 6 (mereka langsung tidak wujud dalam versi 7). Ini bermakna bahawa semasa proses kemas kini pasti akan berlaku beberapa jenis force majeure, yang akan meninggalkan kita tanpa log semasa isu itu diselesaikan. Daripada versi 7, kami sangat menantikan Kibana dengan antara muka yang dipertingkatkan dan penapis baharu.
Kami mencapai matlamat utama kami: kami berhenti kehilangan log dan mengurangkan masa henti kluster infrastruktur daripada 2-3 ranap seminggu kepada beberapa jam kerja penyelenggaraan sebulan. Semua kerja dalam pengeluaran ini hampir tidak dapat dilihat. Walau bagaimanapun, kini kami boleh menentukan dengan tepat apa yang berlaku dengan perkhidmatan kami, kami boleh melakukannya dengan cepat dalam mod senyap dan tidak bimbang bahawa log akan hilang. Secara umum, kami berpuas hati, gembira dan bersedia untuk eksploitasi baru, yang akan kami bincangkan kemudian.
Sumber: www.habr.com