Banyak orang kesulitan dengan Elasticsearch. Namun apa jadinya jika Anda ingin menggunakannya untuk menyimpan log “dalam volume yang sangat besar”? Dan apakah mengalami kegagalan pada salah satu dari beberapa pusat data juga tidak menimbulkan rasa sakit? Arsitektur seperti apa yang harus Anda buat, dan kendala apa yang akan Anda temui?
Kami di Odnoklassniki memutuskan untuk menggunakan elasticsearch untuk memecahkan masalah manajemen log, dan sekarang kami berbagi pengalaman kami dengan Habr: baik tentang arsitektur maupun jebakan.
Saya Pyotr Zaitsev, saya bekerja sebagai administrator sistem di Odnoklassniki. Sebelumnya saya juga seorang admin, bekerja dengan Manticore Search, Sphinx search, Elasticsearch. Mungkin, jika ...pencarian lain muncul, saya mungkin akan mengerjakannya juga. Saya juga berpartisipasi dalam sejumlah proyek open source secara sukarela.
Ketika saya datang ke Odnoklassniki, saya dengan ceroboh mengatakan pada saat wawancara bahwa saya bisa bekerja dengan Elasticsearch. Setelah saya menguasainya dan menyelesaikan beberapa tugas sederhana, saya diberi tugas besar untuk mereformasi sistem manajemen log yang ada saat itu.
Persyaratan
Persyaratan sistem dirumuskan sebagai berikut:
- Graylog akan digunakan sebagai frontend. Karena perusahaan telah memiliki pengalaman menggunakan produk ini, pemrogram dan penguji mengetahuinya, familiar dan nyaman bagi mereka.
- Volume data: rata-rata 50-80 ribu pesan per detik, tapi kalau ada yang rusak maka trafiknya tidak dibatasi apa-apa, bisa 2-3 juta baris per detik
- Setelah berdiskusi dengan pelanggan tentang persyaratan kecepatan pemrosesan kueri penelusuran, kami menyadari bahwa pola umum penggunaan sistem seperti ini adalah sebagai berikut: orang mencari log aplikasi mereka selama dua hari terakhir dan tidak ingin menunggu lebih dari satu hari. kedua untuk hasil kueri yang dirumuskan.
- Administrator bersikeras bahwa sistem dapat dengan mudah diskalakan jika diperlukan, tanpa mengharuskan mereka mempelajari cara kerjanya secara mendalam.
- Sehingga satu-satunya tugas pemeliharaan yang diperlukan sistem ini secara berkala adalah mengganti beberapa perangkat keras.
- Selain itu, Odnoklassniki memiliki tradisi teknis yang sangat baik: layanan apa pun yang kami luncurkan harus selamat dari kegagalan pusat data (mendadak, tidak terencana, dan sepenuhnya terjadi kapan saja).
Persyaratan terakhir dalam implementasi proyek ini paling merugikan kami, yang akan saya bahas lebih detail.
Rabu
Kami bekerja di empat pusat data, sedangkan node data Elasticsearch hanya dapat ditempatkan di tiga pusat data (karena sejumlah alasan non-teknis).
Keempat pusat data ini berisi sekitar 18 ribu sumber log yang berbeda - perangkat keras, kontainer, mesin virtual.
Fitur penting: cluster dimulai dalam container bukan pada mesin fisik, tetapi pada . Kontainer dijamin memiliki 2 inti, mirip dengan 2.0Ghz v4, dengan kemungkinan mendaur ulang inti yang tersisa jika tidak digunakan.
Dengan kata lain:
Topologi
Saya awalnya melihat bentuk umum solusinya sebagai berikut:
- 3-4 VIP berada di belakang A-record domain Graylog, ini adalah alamat tujuan pengiriman log.
- setiap VIP adalah penyeimbang LVS.
- Setelah itu, log masuk ke baterai Graylog, sebagian data dalam format GELF, sebagian dalam format syslog.
- Kemudian semua ini ditulis dalam jumlah besar ke sejumlah koordinator Elasticsearch.
- Dan mereka, pada gilirannya, mengirimkan permintaan tulis dan baca ke node data yang relevan.
Terminologi
Mungkin tidak semua orang memahami terminologi tersebut secara detail, jadi saya ingin membahasnya sedikit.
Elasticsearch memiliki beberapa jenis node - master, koordinator, node data. Ada dua tipe lain untuk transformasi log yang berbeda dan komunikasi antar cluster yang berbeda, namun kami hanya menggunakan yang terdaftar.
Menguasai
Ini melakukan ping ke semua node yang ada di cluster, memelihara peta cluster terkini dan mendistribusikannya antar node, memproses logika peristiwa, dan melakukan berbagai jenis housekeeping di seluruh cluster.
Koordinator
Melakukan satu tugas: menerima permintaan baca atau tulis dari klien dan merutekan lalu lintas ini. Jika ada permintaan tulis, kemungkinan besar, master akan menanyakan pecahan indeks relevan mana yang harus dimasukkannya, dan akan mengarahkan permintaan lebih lanjut.
simpul data
Menyimpan data, melakukan kueri penelusuran yang datang dari luar, dan melakukan operasi pada pecahan yang terletak di dalamnya.
abu-abu
Ini seperti perpaduan Kibana dengan Logstash dalam tumpukan ELK. Graylog menggabungkan UI dan alur pemrosesan log. Di bawah tenda, Graylog menjalankan Kafka dan Zookeeper, yang menyediakan konektivitas ke Graylog sebagai sebuah cluster. Graylog dapat menyimpan log dalam cache (Kafka) jika Elasticsearch tidak tersedia dan mengulangi permintaan baca dan tulis yang gagal, mengelompokkan dan menandai log sesuai dengan aturan yang ditentukan. Seperti Logstash, Graylog memiliki fungsi untuk mengubah baris sebelum menulisnya ke Elasticsearch.
Selain itu, Graylog memiliki penemuan layanan bawaan yang memungkinkan, berdasarkan satu node Elasticsearch yang tersedia, untuk mendapatkan seluruh peta cluster dan memfilternya berdasarkan tag tertentu, yang memungkinkan untuk mengarahkan permintaan ke kontainer tertentu.
Secara visual terlihat seperti ini:
Ini adalah tangkapan layar dari contoh tertentu. Di sini kami membuat histogram berdasarkan permintaan pencarian dan menampilkan baris yang relevan.
Indeks
Kembali ke arsitektur sistem, saya ingin membahas lebih detail tentang bagaimana kami membangun model indeks sehingga semuanya berfungsi dengan benar.
Pada diagram di atas, ini adalah level terendah: Node data Elasticsearch.
Indeks adalah entitas virtual besar yang terdiri dari pecahan Elasticsearch. Masing-masing pecahan itu sendiri tidak lebih dari indeks Lucene. Dan setiap indeks Lucene, pada gilirannya, terdiri dari satu atau lebih segmen.
Saat mendesain, kami memperkirakan bahwa untuk memenuhi persyaratan kecepatan membaca data dalam jumlah besar, kami perlu “menyebarkan” data ini secara merata ke seluruh node data.
Hal ini mengakibatkan jumlah pecahan per indeks (dengan replika) harus sama dengan jumlah node data. Pertama, untuk memastikan faktor replikasi sama dengan dua (yaitu, kita bisa kehilangan setengah dari cluster). Dan kedua, untuk memproses permintaan baca dan tulis pada setidaknya setengah dari cluster.
Kami pertama kali menentukan waktu penyimpanan 30 hari.
Distribusi pecahan dapat direpresentasikan secara grafis sebagai berikut:
Seluruh persegi panjang abu-abu gelap adalah indeks. Kotak merah kiri di dalamnya adalah pecahan utama, yang pertama dalam indeks. Dan kotak biru adalah pecahan replika. Mereka berlokasi di pusat data yang berbeda.
Saat kami menambahkan pecahan lainnya, pecahan tersebut akan masuk ke pusat data ketiga. Dan, pada akhirnya, kita mendapatkan struktur ini, yang memungkinkan hilangnya DC tanpa kehilangan konsistensi data:
Rotasi indeks, mis. membuat indeks baru dan menghapus yang terlama, kami membuatnya sama dengan 48 jam (sesuai dengan pola penggunaan indeks: 48 jam terakhir paling sering dicari).
Interval rotasi indeks ini disebabkan oleh alasan berikut:
Ketika permintaan pencarian tiba di node data tertentu, maka, dari sudut pandang kinerja, akan lebih menguntungkan bila satu pecahan ditanyakan, jika ukurannya sebanding dengan ukuran pinggul node. Hal ini memungkinkan Anda untuk menyimpan bagian "panas" dari indeks di tumpukan dan mengaksesnya dengan cepat. Ketika ada banyak “bagian panas”, kecepatan pencarian indeks menurun.
Saat sebuah node mulai mengeksekusi kueri penelusuran pada satu shard, node tersebut mengalokasikan sejumlah thread yang sama dengan jumlah inti hyperthreading dari mesin fisik. Jika kueri penelusuran memengaruhi sejumlah besar pecahan, maka jumlah utas akan bertambah secara proporsional. Hal ini berdampak negatif pada kecepatan pencarian dan berdampak negatif pada pengindeksan data baru.
Untuk memberikan latensi pencarian yang diperlukan, kami memutuskan untuk menggunakan SSD. Untuk memproses permintaan dengan cepat, mesin yang menghosting kontainer ini harus memiliki setidaknya 56 inti. Angka 56 dipilih sebagai nilai yang cukup bersyarat yang menentukan jumlah thread yang akan dihasilkan Elasticsearch selama operasi. Di Elasitcsearch, banyak parameter kumpulan thread secara langsung bergantung pada jumlah inti yang tersedia, yang pada gilirannya secara langsung memengaruhi jumlah node yang diperlukan dalam cluster sesuai dengan prinsip “lebih sedikit inti - lebih banyak node”.
Hasilnya, kami menemukan bahwa rata-rata sebuah pecahan memiliki berat sekitar 20 gigabyte, dan terdapat 1 pecahan per indeks. Oleh karena itu, jika kita memutarnya setiap 360 jam sekali, maka kita akan mendapatkan 48 jam. Setiap indeks berisi data selama 15 hari.
Sirkuit penulisan dan pembacaan data
Mari kita cari tahu bagaimana data dicatat dalam sistem ini.
Katakanlah beberapa permintaan datang dari Graylog ke koordinator. Misalnya kita ingin mengindeks 2-3 ribu baris.
Koordinator, setelah menerima permintaan dari Graylog, mempertanyakan master: “Dalam permintaan pengindeksan, kami secara khusus menentukan indeks, tetapi di pecahan mana untuk menulisnya tidak ditentukan.”
Master merespons: “Tulis informasi ini ke pecahan nomor 71,” setelah itu dikirim langsung ke node data yang relevan, tempat pecahan utama nomor 71 berada.
Setelah itu log transaksi direplikasi ke pecahan replika, yang terletak di pusat data lain.
Permintaan pencarian datang dari Graylog ke koordinator. Koordinator mengalihkannya berdasarkan indeks, sementara Elasticsearch mendistribusikan permintaan antara pecahan primer dan pecahan replika menggunakan prinsip round-robin.
180 node merespons secara tidak merata, dan saat mereka merespons, koordinator mengumpulkan informasi yang telah “disebarkan” oleh node data yang lebih cepat. Setelah ini, ketika semua informasi telah sampai, atau permintaan telah mencapai batas waktu, ia memberikan semuanya langsung ke klien.
Keseluruhan sistem ini rata-rata memproses kueri penelusuran selama 48 jam terakhir dalam 300-400 md, tidak termasuk kueri dengan wildcard di depannya.
Bunga dengan Elasticsearch: Pengaturan Java
Agar semuanya berfungsi seperti yang kami inginkan, kami menghabiskan waktu yang sangat lama untuk men-debug berbagai hal di cluster.
Bagian pertama dari masalah yang ditemukan terkait dengan cara Java dikonfigurasikan sebelumnya secara default di Elasticsearch.
Masalah satu
Kami telah melihat sejumlah besar laporan bahwa di tingkat Lucene, ketika pekerjaan latar belakang sedang berjalan, penggabungan segmen Lucene gagal dan terjadi kesalahan. Pada saat yang sama, jelas dalam log bahwa ini adalah kesalahan OutOfMemoryError. Kami melihat dari telemetri bahwa pinggulnya bebas, dan tidak jelas mengapa operasi ini gagal.
Ternyata penggabungan indeks Lucene terjadi di luar pinggul. Dan kontainer sangat terbatas dalam hal sumber daya yang dikonsumsi. Hanya heap yang dapat masuk ke dalam sumber daya ini (nilai heap.size kira-kira sama dengan RAM), dan beberapa operasi di luar heap mengalami error karena kesalahan alokasi memori jika karena alasan tertentu operasi tersebut tidak dapat masuk ke dalam ~500MB yang tersisa sebelum batas.
Perbaikannya cukup sepele: jumlah RAM yang tersedia untuk container ditingkatkan, setelah itu kami lupa bahwa kami bahkan mengalami masalah seperti itu.
Masalah kedua
4-5 hari setelah peluncuran cluster, kami melihat bahwa node data mulai keluar dari cluster secara berkala dan masuk ke dalamnya setelah 10-20 detik.
Ketika kami mulai mencari tahu, ternyata memori off-heap di Elasticsearch ini tidak dikontrol dengan cara apa pun. Ketika kami memberikan lebih banyak memori ke kontainer, kami dapat mengisi kumpulan buffer langsung dengan berbagai informasi, dan itu dihapus hanya setelah GC eksplisit diluncurkan dari Elasticsearch.
Dalam beberapa kasus, operasi ini memakan waktu cukup lama, dan selama itu cluster berhasil menandai node ini sebagai sudah keluar. Masalah ini dijelaskan dengan baik .
Solusinya adalah sebagai berikut: kami membatasi kemampuan Java untuk menggunakan sebagian besar memori di luar heap untuk operasi ini. Kami membatasinya hingga 16 gigabyte (-XX:MaxDirectMemorySize=16g), memastikan bahwa GC eksplisit dipanggil lebih sering dan diproses lebih cepat, sehingga tidak lagi mengganggu stabilitas cluster.
Masalah ketiga
Jika Anda berpikir bahwa masalah “node yang meninggalkan cluster pada saat yang paling tidak terduga” telah selesai, Anda salah.
Saat kami mengonfigurasi pekerjaan dengan indeks, kami memilih mmapfs pada pecahan baru dengan segmentasi yang bagus. Ini merupakan kesalahan besar, karena saat menggunakan mmapfs, file tersebut dipetakan ke dalam RAM, dan kemudian kami bekerja dengan file yang dipetakan tersebut. Karena itu, ternyata ketika GC mencoba menghentikan thread dalam aplikasi, kita pergi ke titik aman untuk waktu yang sangat lama, dan dalam perjalanan ke sana, aplikasi berhenti merespons permintaan master tentang apakah aplikasi itu hidup. . Oleh karena itu, master percaya bahwa node tersebut tidak lagi ada di cluster. Setelah itu, setelah 5-10 detik, pengumpul sampah berfungsi, node menjadi hidup, memasuki cluster lagi dan mulai menginisialisasi pecahan. Semuanya terasa seperti “produksi yang pantas kami dapatkan” dan tidak cocok untuk sesuatu yang serius.
Untuk menghilangkan perilaku ini, pertama-tama kami beralih ke niof standar, dan kemudian, ketika kami bermigrasi dari versi elastis kelima ke versi keenam, kami mencoba hybridfs, di mana masalah ini tidak muncul kembali. Anda dapat membaca selengkapnya tentang jenis penyimpanan .
Masalah keempat
Lalu ada masalah lain yang sangat menarik yang kami tangani dalam waktu singkat. Kami menangkapnya selama 2-3 bulan karena polanya benar-benar tidak bisa dipahami.
Kadang-kadang koordinator kami pergi ke Full GC, biasanya setelah makan siang, dan tidak pernah kembali lagi dari sana. Pada saat yang sama, saat mencatat penundaan GC, tampilannya seperti ini: semuanya berjalan dengan baik, baik, baiklah, lalu tiba-tiba semuanya menjadi sangat buruk.
Pada awalnya kami berpikir bahwa kami memiliki pengguna jahat yang meluncurkan semacam permintaan yang membuat koordinator keluar dari mode kerja. Kami mencatat permintaan dalam waktu yang sangat lama, mencoba mencari tahu apa yang terjadi.
Hasilnya, ternyata saat pengguna meluncurkan permintaan besar, dan permintaan tersebut sampai ke koordinator Elasticsearch tertentu, beberapa node merespons lebih lama daripada yang lain.
Dan sementara koordinator menunggu respon dari semua node, dia mengumpulkan hasil yang dikirim dari node yang sudah merespon. Untuk GC, ini berarti pola penggunaan heap kami berubah dengan sangat cepat. Dan GC yang kami gunakan tidak dapat mengatasi tugas ini.
Satu-satunya perbaikan yang kami temukan untuk mengubah perilaku cluster dalam situasi ini adalah migrasi ke JDK13 dan penggunaan pengumpul sampah Shenandoah. Ini memecahkan masalah, koordinator kami berhenti terjatuh.
Di sinilah masalah Java berakhir dan masalah bandwidth dimulai.
"Berries" dengan Elasticsearch: throughput
Masalah dengan throughput berarti bahwa cluster kami bekerja secara stabil, namun pada puncak jumlah dokumen yang diindeks dan selama manuver, kinerja tidak mencukupi.
Gejala pertama yang ditemui: selama beberapa “ledakan” dalam produksi, ketika sejumlah besar log tiba-tiba dihasilkan, kesalahan pengindeksan es_rejected_execution mulai sering muncul di Graylog.
Hal ini disebabkan oleh fakta bahwa thread_pool.write.queue pada satu node data, hingga saat Elasticsearch mampu memproses permintaan pengindeksan dan mengunggah informasi ke shard pada disk, hanya mampu menyimpan 200 permintaan dalam cache secara default. Dan masuk Sangat sedikit yang dibicarakan tentang parameter ini. Hanya jumlah maksimum utas dan ukuran default yang ditunjukkan.
Tentu saja, kami memutarbalikkan nilai ini dan menemukan hal berikut: khususnya, dalam pengaturan kami, hingga 300 permintaan di-cache dengan cukup baik, dan nilai yang lebih tinggi penuh dengan fakta bahwa kami kembali terbang ke GC Penuh.
Selain itu, karena ini adalah kumpulan pesan yang tiba dalam satu permintaan, Graylog perlu diubah agar tidak menulis sering dan dalam kumpulan kecil, tetapi dalam kumpulan besar atau setiap 3 detik sekali jika kumpulan tersebut masih belum lengkap. Dalam hal ini, ternyata informasi yang kita tulis di Elasticsearch tersedia bukan dalam dua detik, tetapi dalam lima detik (yang cukup cocok untuk kita), tetapi jumlah pengulangan yang harus dilakukan untuk melewati sejumlah besar tumpukan informasi berkurang.
Hal ini sangat penting pada saat-saat ketika ada sesuatu yang mogok di suatu tempat dan dengan marah melaporkannya agar tidak mendapatkan Elastic yang sepenuhnya di-spam, dan setelah beberapa waktu - node Graylog yang tidak dapat dioperasikan karena buffer yang tersumbat.
Selain itu, ketika kami mengalami ledakan produksi yang sama, kami menerima keluhan dari pemrogram dan penguji: pada saat mereka benar-benar membutuhkan log ini, mereka diberikan dengan sangat lambat.
Mereka mulai memikirkannya. Di satu sisi, jelas bahwa permintaan pencarian dan permintaan pengindeksan diproses, pada dasarnya, pada mesin fisik yang sama, dan dengan satu atau lain cara akan ada penarikan tertentu.
Namun hal ini sebagian dapat dihindari karena fakta bahwa dalam versi keenam Elasticsearch, sebuah algoritme muncul yang memungkinkan Anda mendistribusikan kueri antara node data yang relevan tidak sesuai dengan prinsip round-robin acak (wadah yang mengindeks dan menyimpan data utama -shard bisa sangat sibuk, tidak akan ada cara untuk merespons dengan cepat), tetapi meneruskan permintaan ini ke wadah yang lebih sedikit muatannya dengan replika-shard, yang akan merespons lebih cepat. Dengan kata lain, kita sampai pada use_adaptive_replica_selection: true.
Gambar bacaannya mulai terlihat seperti ini:
Peralihan ke algoritme ini memungkinkan peningkatan waktu kueri secara signifikan pada saat kami memiliki aliran log yang besar untuk ditulis.
Terakhir, masalah utamanya adalah penghapusan pusat data tanpa rasa sakit.
Apa yang kami inginkan dari cluster segera setelah kehilangan koneksi dengan satu DC:
- Jika kita memiliki master saat ini di pusat data yang gagal, maka master tersebut akan dipilih kembali dan dipindahkan sebagai peran ke node lain di DC lain.
- Master akan segera menghapus semua node yang tidak dapat diakses dari cluster.
- Berdasarkan yang tersisa, dia akan memahami: di pusat data yang hilang kami memiliki pecahan utama ini dan itu, dia akan segera mempromosikan pecahan replika pelengkap di pusat data yang tersisa, dan kami akan terus mengindeks datanya.
- Sebagai akibatnya, throughput penulisan dan pembacaan cluster akan menurun secara bertahap, namun secara umum semuanya akan berfungsi, meskipun lambat, namun stabil.
Ternyata, kami menginginkan sesuatu seperti ini:
Dan kami mendapatkan yang berikut ini:
Bagaimana hal itu terjadi?
Saat pusat data tumbang, master kami menjadi penghambatnya.
Kenapa?
Faktanya adalah master memiliki TaskBatcher, yang bertanggung jawab untuk mendistribusikan tugas dan acara tertentu di cluster. Setiap keluarnya node, setiap promosi shard dari replika ke primer, tugas apa pun untuk membuat shard di suatu tempat - semua ini pertama-tama masuk ke TaskBatcher, tempat ia diproses secara berurutan dan dalam satu thread.
Pada saat penarikan satu pusat data, ternyata semua node data di pusat data yang masih ada menganggapnya sebagai tugas mereka untuk memberi tahu master “kita telah kehilangan pecahan ini dan itu dan node data ini dan itu.”
Pada saat yang sama, node data yang masih hidup mengirimkan semua informasi ini ke master saat ini dan mencoba menunggu konfirmasi bahwa dia menerimanya. Mereka tidak menunggu ini, karena master menerima tugas lebih cepat daripada yang bisa dia jawab. Node-node tersebut menghitung waktu permintaan berulang, dan master saat ini bahkan tidak mencoba menjawabnya, tetapi sepenuhnya asyik dengan tugas mengurutkan permintaan berdasarkan prioritas.
Dalam bentuk terminal, ternyata node data tersebut mengirim spam ke master hingga masuk ke GC penuh. Setelah itu, peran master kami dipindahkan ke beberapa node berikutnya, hal yang sama terjadi padanya, dan akibatnya cluster tersebut benar-benar runtuh.
Kami melakukan pengukuran, dan sebelum versi 6.4.0, yang telah diperbaiki, cukup bagi kami untuk mengeluarkan hanya 10 node data dari 360 secara bersamaan untuk mematikan cluster sepenuhnya.
Itu terlihat seperti ini:
Setelah versi 6.4.0, di mana bug mengerikan ini diperbaiki, node data berhenti mematikan master. Namun hal itu tidak membuatnya “lebih pintar”. Yaitu: ketika kita mengeluarkan 2, 3 atau 10 (angka apa pun selain satu) node data, master menerima beberapa pesan pertama yang mengatakan bahwa node A telah pergi, dan mencoba memberi tahu node B, node C tentang hal ini, node D.
Dan saat ini, hal ini hanya dapat diatasi dengan menetapkan batas waktu untuk upaya memberi tahu seseorang tentang sesuatu, yang setara dengan sekitar 20-30 detik, dan dengan demikian mengontrol kecepatan pergerakan pusat data keluar dari cluster.
Pada prinsipnya, ini sesuai dengan persyaratan yang awalnya disajikan pada produk akhir sebagai bagian dari proyek, namun dari sudut pandang “sains murni” ini adalah bug. Yang, omong-omong, telah berhasil diperbaiki oleh pengembang di versi 7.2.
Selain itu, ketika node data tertentu padam, ternyata menyebarkan informasi tentang keluarnya lebih penting daripada memberi tahu seluruh cluster bahwa ada pecahan primer ini dan itu (untuk mempromosikan pecahan replika di data lain. pusat di primer, dan informasi dapat ditulis pada mereka).
Oleh karena itu, ketika semuanya sudah mati, node data yang dirilis tidak langsung ditandai sebagai basi. Oleh karena itu, kami terpaksa menunggu sampai semua ping habis waktunya ke node data yang dirilis, dan hanya setelah itu cluster kami mulai memberi tahu kami bahwa di sana, di sana, dan di sana kami perlu terus merekam informasi. Anda dapat membaca lebih lanjut tentang ini .
Alhasil, pengoperasian penarikan pusat data saat ini memakan waktu sekitar 5 menit pada jam sibuk. Untuk raksasa yang besar dan kikuk, ini adalah hasil yang cukup bagus.
Hasilnya, kami mengambil keputusan berikut:
- Kami memiliki 360 node data dengan disk 700 gigabyte.
- 60 koordinator untuk merutekan lalu lintas melalui node data yang sama.
- 40 master yang kami tinggalkan sebagai semacam warisan sejak versi sebelum 6.4.0 - untuk bertahan dari penarikan pusat data, kami siap mental untuk kehilangan beberapa mesin agar dijamin memiliki kuorum master bahkan di skenario terburuk
- Setiap upaya untuk menggabungkan peran dalam satu wadah ditanggapi dengan fakta bahwa cepat atau lambat node tersebut akan rusak saat dimuat.
- Seluruh cluster menggunakan heap.size sebesar 31 gigabyte: semua upaya untuk mengurangi ukuran mengakibatkan matinya beberapa node pada permintaan pencarian berat dengan wildcard di depan atau mengakibatkan pemutus sirkuit di Elasticsearch itu sendiri.
- Selain itu, untuk memastikan kinerja pencarian, kami mencoba untuk menjaga jumlah objek di cluster sekecil mungkin, untuk memproses kejadian sesedikit mungkin dalam kemacetan yang kami dapatkan di master.
Terakhir tentang pemantauan
Untuk memastikan bahwa semua ini berfungsi sebagaimana mestinya, kami memantau hal-hal berikut:
- Setiap node data melaporkan ke cloud kami bahwa node tersebut ada, dan terdapat pecahan ini dan itu di dalamnya. Ketika kita memadamkan sesuatu di suatu tempat, cluster melaporkan setelah 2-3 detik bahwa di pusat A kita memadamkan node 2, 3, dan 4 - ini berarti bahwa di pusat data lain kita tidak dapat memadamkan node yang hanya memiliki satu pecahan. kiri.
- Mengetahui sifat perilaku master, kami dengan cermat memperhatikan jumlah tugas yang tertunda. Karena bahkan satu tugas yang macet, jika tidak habis waktunya, secara teoritis dalam beberapa situasi darurat dapat menjadi alasan mengapa, misalnya, promosi pecahan replika di primer tidak berfungsi, itulah sebabnya pengindeksan akan berhenti berfungsi.
- Kami juga mencermati penundaan pengumpul sampah, karena kami telah mengalami kesulitan besar dalam hal ini selama pengoptimalan.
- Tolak demi benang untuk memahami terlebih dahulu di mana letak hambatannya.
- Ya, metrik standar seperti heap, RAM, dan I/O.
Saat membangun pemantauan, Anda harus mempertimbangkan fitur Thread Pool di Elasticsearch. menjelaskan opsi konfigurasi dan nilai default untuk pencarian dan pengindeksan, tetapi sama sekali tidak membahas tentang thread_pool.management. Thread ini memproses, khususnya, kueri seperti _cat/shards dan kueri serupa lainnya, yang nyaman digunakan saat menulis pemantauan. Semakin besar clusternya, semakin banyak permintaan yang dieksekusi per unit waktu, dan thread_pool.management yang disebutkan di atas tidak hanya tidak disajikan dalam dokumentasi resmi, tetapi juga dibatasi secara default hingga 5 thread, yang dibuang dengan sangat cepat, setelahnya pemantauan mana yang berhenti bekerja dengan benar.
Yang ingin saya katakan sebagai kesimpulan: kita berhasil! Kami dapat memberikan kepada pemrogram dan pengembang kami alat yang, dalam hampir semua situasi, dapat dengan cepat dan andal memberikan informasi tentang apa yang terjadi dalam produksi.
Ya, ternyata cukup rumit, namun demikian, kami berhasil menyesuaikan keinginan kami dengan produk yang sudah ada, yang tidak perlu kami tambal dan tulis ulang sendiri.
Sumber: www.habr.com