Halo semuanya, nama saya Alexander, saya bekerja di CIAN sebagai insinyur dan terlibat dalam administrasi sistem dan otomatisasi proses infrastruktur. Dalam komentar di salah satu artikel sebelumnya, kami diminta untuk memberi tahu di mana kami mendapatkan 4 TB log per hari dan apa yang kami lakukan dengannya. Ya, kami memiliki banyak log, dan cluster infrastruktur terpisah telah dibuat untuk memprosesnya, yang memungkinkan kami menyelesaikan masalah dengan cepat. Dalam artikel ini saya akan berbicara tentang bagaimana kami mengadaptasinya selama satu tahun untuk bekerja dengan aliran data yang terus berkembang.
Di mana kita memulai?
Selama beberapa tahun terakhir, beban di cian.ru telah berkembang sangat pesat, dan pada kuartal ketiga tahun 2018, lalu lintas sumber daya mencapai 11.2 juta pengguna unik per bulan. Pada saat itu, pada saat-saat kritis kami kehilangan hingga 40% log, itulah sebabnya kami tidak dapat menangani insiden dengan cepat dan menghabiskan banyak waktu dan tenaga untuk menyelesaikannya. Kami juga sering tidak dapat menemukan penyebab masalahnya, dan masalah tersebut akan terulang kembali setelah beberapa waktu. Itu adalah neraka dan sesuatu harus dilakukan untuk mengatasinya.
Saat itu, kami menggunakan cluster 10 node data dengan ElasticSearch versi 5.5.2 dengan pengaturan indeks standar untuk menyimpan log. Ini diperkenalkan lebih dari setahun yang lalu sebagai solusi yang populer dan terjangkau: aliran log tidak begitu besar, tidak ada gunanya membuat konfigurasi non-standar.
Pemrosesan log masuk disediakan oleh Logstash pada port berbeda di lima koordinator ElasticSearch. Satu indeks, berapa pun ukurannya, terdiri dari lima pecahan. Rotasi setiap jam dan harian diselenggarakan, sebagai hasilnya, sekitar 100 pecahan baru muncul di cluster setiap jam. Meskipun jumlah lognya tidak terlalu banyak, cluster ini dapat mengatasinya dengan baik dan tidak ada yang memperhatikan pengaturannya.
Tantangan pertumbuhan yang cepat
Volume log yang dihasilkan tumbuh sangat cepat, karena dua proses saling tumpang tindih. Di satu sisi, jumlah pengguna layanan bertambah. Di sisi lain, kami mulai secara aktif beralih ke arsitektur layanan mikro, menghilangkan monolit lama kami di C# dan Python. Beberapa lusin layanan mikro baru yang menggantikan bagian dari monolit menghasilkan lebih banyak log secara signifikan untuk klaster infrastruktur.
Penskalaan itulah yang membawa kami ke titik di mana klaster menjadi tidak dapat dikelola. Ketika log mulai tiba dengan kecepatan 20 ribu pesan per detik, seringnya rotasi yang tidak berguna meningkatkan jumlah pecahan menjadi 6 ribu, dan terdapat lebih dari 600 pecahan per node.
Hal ini menyebabkan masalah dengan alokasi RAM, dan ketika sebuah node mengalami error, semua pecahan mulai bergerak secara bersamaan, melipatgandakan lalu lintas dan memuat node lain, sehingga hampir tidak mungkin untuk menulis data ke cluster. Dan selama periode ini kami dibiarkan tanpa log. Dan jika ada masalah dengan server, pada dasarnya kami kehilangan 1/10 cluster. Sejumlah besar indeks kecil menambah kompleksitas.
Tanpa log, kami tidak memahami alasan kejadian tersebut dan cepat atau lambat dapat melakukan kesalahan yang sama lagi, dan dalam ideologi tim kami hal ini tidak dapat diterima, karena semua mekanisme kerja kami dirancang untuk melakukan hal yang sebaliknya - jangan pernah terulang kembali. masalah yang sama. Untuk melakukan hal ini, kami memerlukan log dalam jumlah penuh dan pengirimannya hampir secara real-time, karena tim teknisi yang bertugas memantau peringatan tidak hanya dari metrik, tetapi juga dari log. Untuk memahami skala masalahnya, saat itu total volume log adalah sekitar 2 TB per hari.
Kami menetapkan tujuan untuk sepenuhnya menghilangkan hilangnya log dan mengurangi waktu pengirimannya ke cluster ELK menjadi maksimal 15 menit selama force majeure (kami kemudian mengandalkan angka ini sebagai KPI internal).
Mekanisme rotasi baru dan node panas-hangat
Kami memulai konversi cluster dengan memperbarui versi ElasticSearch dari 5.5.2 ke 6.4.3. Sekali lagi cluster versi 5 kami mati, dan kami memutuskan untuk mematikannya dan memperbaruinya sepenuhnya - masih belum ada log. Jadi kami melakukan transisi ini hanya dalam beberapa jam.
Transformasi terbesar pada tahap ini adalah implementasi Apache Kafka pada tiga node dengan koordinator sebagai buffer perantara. Broker pesan menyelamatkan kami dari kehilangan log selama masalah dengan ElasticSearch. Pada saat yang sama, kami menambahkan 2 node ke cluster dan beralih ke arsitektur hot-warm dengan tiga node “hot” yang terletak di rak berbeda di pusat data. Kami mengarahkan log ke sana menggunakan topeng yang tidak boleh hilang dalam keadaan apa pun - nginx, serta log kesalahan aplikasi. Log kecil dikirim ke node yang tersisa - debug, peringatan, dll., dan setelah 24 jam, log "penting" dari node "panas" ditransfer.
Agar tidak menambah jumlah indeks kecil, kami beralih dari rotasi waktu ke mekanisme rollover. Ada banyak informasi di forum bahwa rotasi berdasarkan ukuran indeks sangat tidak dapat diandalkan, jadi kami memutuskan untuk menggunakan rotasi berdasarkan jumlah dokumen dalam indeks. Kami menganalisis setiap indeks dan mencatat jumlah dokumen yang setelahnya rotasi harus dilakukan. Dengan demikian, kami telah mencapai ukuran pecahan optimal - tidak lebih dari 50 GB.
Optimasi klaster
Namun, kami belum sepenuhnya menghilangkan permasalahan tersebut. Sayangnya, indeks kecil masih muncul: indeks tersebut tidak mencapai volume yang ditentukan, tidak dirotasi, dan dihapus oleh pembersihan global indeks yang lebih lama dari tiga hari, sejak kami menghapus rotasi berdasarkan tanggal. Hal ini menyebabkan hilangnya data karena indeks dari cluster hilang sama sekali, dan upaya untuk menulis ke indeks yang tidak ada mematahkan logika kurator yang kami gunakan untuk manajemen. Alias untuk penulisan diubah menjadi indeks dan mematahkan logika rollover, menyebabkan pertumbuhan beberapa indeks yang tidak terkendali hingga 600 GB.
Misalnya, untuk 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
Jika tidak ada alias rollover, terjadi kesalahan:
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 solusi untuk masalah ini untuk iterasi berikutnya dan menangani masalah lain: kami beralih ke logika tarik Logstash, yang memproses log masuk (menghapus informasi yang tidak perlu dan memperkaya). Kami menempatkannya di docker, yang kami luncurkan melalui docker-compose, dan kami juga menempatkan logstash-exporter di sana, yang mengirimkan metrik ke Prometheus untuk pemantauan operasional aliran log. Dengan cara ini kami memberikan diri kami kesempatan untuk mengubah jumlah instance logstash yang bertanggung jawab untuk memproses setiap jenis log dengan lancar.
Saat kami meningkatkan klaster, lalu lintas cian.ru meningkat menjadi 12,8 juta pengguna unik per bulan. Akibatnya, ternyata transformasi kami sedikit tertinggal dari perubahan produksi, dan kami dihadapkan pada kenyataan bahwa node “hangat” tidak dapat mengatasi beban dan memperlambat seluruh pengiriman log. Kami menerima data "panas" tanpa kegagalan, namun kami harus melakukan intervensi dalam pengiriman sisanya dan melakukan rollover manual untuk mendistribusikan indeks secara merata.
Pada saat yang sama, penskalaan dan perubahan pengaturan instance logstash di cluster diperumit oleh fakta bahwa itu adalah komposisi buruh pelabuhan lokal, dan semua tindakan dilakukan secara manual (untuk menambahkan tujuan baru, perlu melalui semua secara manual server dan lakukan docker-compose up -d di mana saja).
Redistribusi log
Pada bulan September tahun ini, kami masih memotong monolit, beban pada cluster meningkat, dan aliran log mendekati 30 ribu pesan per detik.
Kami memulai iterasi berikutnya dengan pembaruan perangkat keras. Kami beralih dari lima koordinator menjadi tiga, mengganti node data dan menang dalam hal uang dan ruang penyimpanan. Untuk node kami menggunakan dua konfigurasi:
- Untuk node “panas”: E3-1270 v6 / 960Gb SSD / 32 Gb x 3 x 2 (3 untuk Hot1 dan 3 untuk Hot2).
- Untuk node “hangat”: E3-1230 v6 / 4Tb SSD / 32 Gb x 4.
Pada iterasi ini, kami memindahkan indeks dengan log akses layanan mikro, yang menggunakan ruang yang sama dengan log nginx garis depan, ke grup kedua yang terdiri dari tiga node “panas”. Kami sekarang menyimpan data pada node "panas" selama 20 jam, dan kemudian mentransfernya ke node "hangat" ke log lainnya.
Kami memecahkan masalah hilangnya indeks kecil dengan mengkonfigurasi ulang rotasinya. Sekarang indeks dirotasi setiap 23 jam, meskipun hanya ada sedikit data di sana. Ini sedikit meningkatkan jumlah pecahan (ada sekitar 800), tetapi dari sudut pandang kinerja cluster, hal ini dapat ditoleransi.
Hasilnya, terdapat enam node “panas” dan hanya empat node “hangat” di cluster tersebut. Hal ini menyebabkan sedikit penundaan pada permintaan dalam interval waktu yang lama, namun meningkatkan jumlah node di masa mendatang akan menyelesaikan masalah ini.
Iterasi ini juga memperbaiki masalah kurangnya penskalaan semi-otomatis. Untuk melakukan ini, kami menerapkan infrastruktur cluster Nomad - serupa dengan yang telah kami terapkan dalam produksi. Untuk saat ini, jumlah Logstash tidak berubah secara otomatis tergantung pada bebannya, tetapi kita akan membahasnya.
Планы на будущее
Konfigurasi yang diterapkan berskala sempurna, dan sekarang kami menyimpan 13,3 TB data - semua log selama 4 hari, yang diperlukan untuk analisis peringatan darurat. Kami mengubah beberapa log menjadi metrik, yang kami tambahkan ke Grafit. Untuk mempermudah pekerjaan para insinyur, kami memiliki metrik untuk kluster infrastruktur dan skrip untuk perbaikan semi-otomatis atas masalah umum. Setelah menambah jumlah node data yang direncanakan tahun depan, kami akan beralih ke penyimpanan data dari 4 menjadi 7 hari. Ini akan cukup untuk pekerjaan operasional, karena kami selalu berusaha menyelidiki insiden secepatnya, dan untuk penyelidikan jangka panjang terdapat data telemetri.
Pada bulan Oktober 2019, lalu lintas ke cian.ru telah meningkat menjadi 15,3 juta pengguna unik per bulan. Ini menjadi ujian serius bagi solusi arsitektur untuk mengirimkan log.
Sekarang kami bersiap untuk memperbarui ElasticSearch ke versi 7. Namun, untuk ini kami harus memperbarui pemetaan banyak indeks di ElasticSearch, karena indeks tersebut berpindah dari versi 5.5 dan dinyatakan tidak digunakan lagi di versi 6 (tidak ada di versi 7). Artinya selama proses update pasti akan terjadi semacam force majeure yang akan membuat kita tidak memiliki log selama masalah tersebut teratasi. Dari versi 7, kami sangat menantikan Kibana dengan antarmuka yang ditingkatkan dan filter baru.
Kami mencapai tujuan utama kami: kami menghentikan kehilangan log dan mengurangi waktu henti cluster infrastruktur dari 2-3 kerusakan per minggu menjadi beberapa jam pekerjaan pemeliharaan per bulan. Semua pekerjaan dalam produksi ini hampir tidak terlihat. Namun, sekarang kami dapat menentukan dengan tepat apa yang terjadi dengan layanan kami, kami dapat melakukannya dengan cepat dalam mode senyap dan tidak khawatir log akan hilang. Secara umum, kami puas, gembira, dan bersiap untuk eksploitasi baru, yang akan kami bicarakan nanti.
Sumber: www.habr.com