Konferensi HighLoad++ berikutnya akan diadakan pada tanggal 6 dan 7 April 2020 di St. Petersburg Detail dan tiket . HighLoad++ Moskow 2018. Aula “Moskow”. 9 November, 15:00. Tesis dan .
* Pemantauan - online dan analitik.
* Batasan dasar platform ZABBIX.
* Solusi untuk menskalakan penyimpanan analitik.
* Optimalisasi server ZABBIX.
* Pengoptimalan UI.
* Pengalaman mengoperasikan sistem di bawah beban lebih dari 40k NVPS.
* Kesimpulan singkat.
Mikhail Makurov (selanjutnya – MM): - Halo semua!
Maxim Chernetsov (selanjutnya – KIA): - Selamat siang!
MM: – Izinkan saya memperkenalkan Maxim. Max adalah seorang insinyur berbakat, penggiat jejaring terbaik yang saya kenal. Maxim terlibat dalam jaringan dan layanan, pengembangan dan pengoperasiannya.
KIA: – Dan saya ingin bercerita tentang Mikhail. Mikhail adalah pengembang C. Dia menulis beberapa solusi pemrosesan lalu lintas beban tinggi untuk perusahaan kami. Kami tinggal dan bekerja di Ural, di kota pria tangguh Chelyabinsk, di perusahaan Intersvyaz. Perusahaan kami adalah penyedia layanan Internet dan televisi kabel untuk satu juta orang di 16 kota.
MM: – Dan patut dikatakan bahwa Intersvyaz lebih dari sekedar penyedia, ini adalah perusahaan IT. Sebagian besar solusi kami dibuat oleh departemen TI kami.
A: dari server yang memproses lalu lintas hingga pusat panggilan dan aplikasi seluler. Departemen IT kini memiliki sekitar 80 orang dengan kompetensi yang sangat-sangat beragam.
Tentang Zabbix dan arsitekturnya
KIA: – Dan sekarang saya akan mencoba membuat rekor pribadi dan mengatakan dalam satu menit apa itu Zabbix (selanjutnya disebut “Zabbix”).
Zabbix memposisikan dirinya sebagai sistem pemantauan out-of-the-box tingkat perusahaan. Ini memiliki banyak fitur yang membuat hidup lebih mudah: aturan eskalasi tingkat lanjut, API untuk integrasi, pengelompokan, dan deteksi otomatis host dan metrik. Zabbix memiliki apa yang disebut alat penskalaan - proxy. Zabbix adalah sistem sumber terbuka.
Secara singkat tentang arsitektur. Kita dapat mengatakan bahwa itu terdiri dari tiga komponen:
- pelayan. Ditulis dalam C. Dengan pemrosesan yang agak rumit dan transfer informasi antar thread. Semua pemrosesan terjadi di dalamnya: mulai dari penerimaan hingga penyimpanan ke database.
- Semua data disimpan dalam database. Zabbix mendukung MySQL, PostreSQL dan Oracle.
- Antarmuka web ditulis dalam PHP. Pada sebagian besar sistem, ia hadir dengan server Apache, tetapi bekerja lebih efisien jika dikombinasikan dengan nginx + php.
Hari ini kami ingin menceritakan satu kisah dari kehidupan perusahaan kami terkait Zabbix...
Sebuah kisah dari kehidupan perusahaan Intersvyaz. Apa yang kita miliki dan apa yang kita butuhkan?
5 atau 6 bulan yang lalu. Suatu hari sepulang kerja...
KIA: - Misha, halo! Saya senang saya berhasil menangkap Anda - ada percakapan. Kami kembali mengalami masalah dengan pemantauan. Saat terjadi kecelakaan besar, semuanya berjalan lambat dan tidak ada informasi tentang keadaan jaringan. Sayangnya, hal ini bukan kali pertama terjadi. Saya membutuhkan bantuan Anda. Mari kita buat pemantauan kita berfungsi dalam kondisi apa pun!
MM: - Tapi mari kita sinkronisasi dulu. Saya belum melihat ke sana selama beberapa tahun. Sejauh yang saya ingat, kami meninggalkan Nagios dan beralih ke Zabbix sekitar 8 tahun yang lalu. Dan sekarang kami tampaknya memiliki 6 server yang kuat dan sekitar selusin proxy. Apakah saya membingungkan sesuatu?
KIA: - Hampir. 15 server, beberapa di antaranya adalah mesin virtual. Yang paling penting adalah hal itu tidak menyelamatkan kita pada saat kita sangat membutuhkannya. Seperti kecelakaan - server melambat dan Anda tidak dapat melihat apa pun. Kami mencoba mengoptimalkan konfigurasi, namun hal ini tidak memberikan peningkatan performa yang optimal.
MM: - Itu sudah jelas. Apakah Anda melihat sesuatu, apakah Anda sudah menggali sesuatu dari diagnosa?
KIA: – Hal pertama yang harus Anda tangani adalah database. MySQL terus-menerus dimuat, menyimpan metrik baru, dan ketika Zabbix mulai menghasilkan banyak peristiwa, database mengalami overdrive selama beberapa jam. Saya sudah memberi tahu Anda tentang pengoptimalan konfigurasi, tetapi tahun ini mereka memperbarui perangkat keras: server memiliki lebih dari seratus gigabyte memori dan susunan disk pada RAID SSD - tidak ada gunanya mengembangkannya secara linier dalam jangka panjang. Apa yang kita lakukan?
MM: - Itu sudah jelas. Secara umum, MySQL adalah database LTP. Tampaknya sudah tidak cocok lagi untuk menyimpan arsip metrik seukuran kita. Mari kita cari tahu.
KIA: - Ayo!
Integrasi Zabbix dan Clickhouse sebagai hasil hackathon
Setelah beberapa waktu kami menerima data menarik:
Sebagian besar ruang di database kami ditempati oleh arsip metrik dan kurang dari 1% digunakan untuk konfigurasi, template, dan pengaturan. Pada saat itu, kami telah mengoperasikan solusi Big data berbasis Clickhouse selama lebih dari satu tahun. Arah pergerakannya jelas bagi kami. Pada Hackathon musim semi kami, saya menulis integrasi Zabbix dengan Clickhouse untuk server dan frontend. Saat itu, Zabbix sudah memiliki dukungan untuk ElasticSearch, dan kami memutuskan untuk membandingkannya.
Perbandingan Clickhouse dan Elasticsearch
MM: – Sebagai perbandingan, kami menghasilkan beban yang sama dengan yang disediakan server Zabbix dan melihat bagaimana sistem akan berperilaku. Kami menulis data dalam kumpulan 1000 baris, menggunakan CURL. Kami berasumsi sebelumnya bahwa Clickhouse akan lebih efisien untuk memuat profil seperti yang dilakukan Zabbix. Hasilnya bahkan melebihi ekspektasi kami:
Dalam kondisi pengujian yang sama, Clickhouse menulis data tiga kali lebih banyak. Pada saat yang sama, kedua sistem mengkonsumsi sangat efisien (sejumlah kecil sumber daya) saat membaca data. Namun Elastics membutuhkan prosesor dalam jumlah besar saat merekam:
Secara total, Clickhouse jauh lebih unggul daripada Elastix dalam hal konsumsi prosesor dan kecepatan. Pada saat yang sama, karena kompresi data, Clickhouse menggunakan hard drive 11 kali lebih sedikit dan melakukan operasi disk sekitar 30 kali lebih sedikit:
KIA: – Ya, pekerjaan Clickhouse dengan subsistem disk diimplementasikan dengan sangat efisien. Anda dapat menggunakan disk SATA berukuran besar untuk database dan mendapatkan kecepatan penulisan ratusan ribu baris per detik. Sistem siap pakai mendukung sharding, replikasi, dan sangat mudah dikonfigurasi. Kami sangat puas dengan penggunaannya sepanjang tahun.
Untuk mengoptimalkan sumber daya, Anda dapat menginstal Clickhouse di samping database utama yang ada dan dengan demikian menghemat banyak waktu CPU dan operasi disk. Kami telah memindahkan arsip metrik ke cluster Clickhouse yang ada:
Kami sangat meringankan database MySQL utama sehingga kami dapat menggabungkannya pada satu mesin dengan server Zabbix dan meninggalkan server khusus untuk MySQL.
Bagaimana cara kerja polling di Zabbix?
4 bulan lalu
MM: – Baiklah, bisakah kita melupakan masalah pangkalannya?
KIA: - Itu sudah pasti! Masalah lain yang perlu kita selesaikan adalah lambatnya pengumpulan data. Sekarang ke-15 server proxy kami dipenuhi dengan SNMP dan proses polling. Dan tidak ada jalan lain kecuali memasang server baru dan baru.
MM: - Besar. Namun pertama-tama, beri tahu kami cara kerja polling di Zabbix?
KIA: – Singkatnya, ada 20 jenis metrik dan selusin cara untuk mendapatkannya. Zabbix dapat mengumpulkan data baik dalam mode "permintaan-respons", atau menunggu data baru melalui "Antarmuka Trapper".
Perlu dicatat bahwa di Zabbix asli metode ini (Trapper) adalah yang tercepat.
Ada server proxy untuk distribusi beban:
Proxy dapat melakukan fungsi pengumpulan yang sama seperti server Zabbix, menerima tugas darinya dan mengirimkan metrik yang dikumpulkan melalui antarmuka Trapper. Ini adalah cara resmi yang direkomendasikan untuk mendistribusikan beban. Proxy juga berguna untuk memantau infrastruktur jarak jauh yang beroperasi melalui NAT atau saluran lambat:
MM: – Semuanya jelas dengan arsitektur. Kita perlu melihat sumbernya...
Beberapa hari kemudian
Kisah bagaimana nmap fping menang
MM: “Saya rasa saya menggali sesuatu.”
KIA: - Beri tahu saya!
MM: – Saya menemukan bahwa saat memeriksa ketersediaan, Zabbix memeriksa maksimal 128 host sekaligus. Saya mencoba meningkatkan angka ini menjadi 500 dan menghapus interval antar paket di ping (ping) mereka - ini menggandakan kinerjanya. Tapi saya ingin jumlah yang lebih besar.
KIA: – Dalam praktik saya, terkadang saya harus memeriksa ketersediaan ribuan host, dan saya belum pernah melihat yang lebih cepat dari nmap untuk ini. Saya yakin ini adalah cara tercepat. Ayo kita coba! Kita perlu meningkatkan jumlah host per iterasi secara signifikan.
MM: – Periksa lebih dari lima ratus? 600?
KIA: - Setidaknya beberapa ribu.
MM: - OKE. Hal terpenting yang ingin saya katakan adalah saya menemukan bahwa sebagian besar polling di Zabbix dilakukan secara sinkron. Kita pasti perlu mengubahnya ke mode asynchronous. Kemudian kita dapat meningkatkan jumlah metrik yang dikumpulkan oleh lembaga survei secara signifikan, terutama jika kita meningkatkan jumlah metrik per iterasi.
KIA: - Besar! Dan kapan?
MM: – Seperti biasa, kemarin.
KIA: – Kami membandingkan kedua versi fping dan nmap:
Pada sejumlah besar host, nmap diperkirakan lima kali lebih efektif. Karena nmap hanya memeriksa ketersediaan dan waktu respons, kami memindahkan penghitungan kerugian ke pemicu dan secara signifikan mengurangi interval pemeriksaan ketersediaan. Kami menemukan jumlah host optimal untuk nmap adalah sekitar 4 ribu per iterasi. Nmap memungkinkan kami mengurangi biaya CPU untuk pemeriksaan ketersediaan sebanyak tiga kali lipat dan mengurangi interval dari 120 detik menjadi 10.
Optimalisasi pemungutan suara
MM: “Kemudian kami mulai melakukan pemungutan suara. Kami terutama tertarik pada deteksi dan agen SNMP. Di Zabbix, pemungutan suara dilakukan secara serempak dan tindakan khusus telah diambil untuk meningkatkan efisiensi sistem. Dalam mode sinkron, ketidaktersediaan host menyebabkan penurunan polling yang signifikan. Ada keseluruhan sistem negara bagian, ada proses khusus - yang disebut lembaga survei yang tidak dapat dijangkau, yang hanya bekerja dengan host yang tidak dapat dijangkau:
Ini adalah komentar yang menunjukkan matriks keadaan, seluruh kompleksitas sistem transisi yang diperlukan agar sistem tetap efektif. Selain itu, jajak pendapat tersinkronisasi itu sendiri cukup lambat:
Itulah sebabnya ribuan aliran jajak pendapat di lusinan proxy tidak dapat mengumpulkan jumlah data yang kami perlukan. Implementasi asinkron tidak hanya memecahkan masalah jumlah thread, tetapi juga secara signifikan menyederhanakan sistem status host yang tidak tersedia, karena untuk nomor apa pun yang diperiksa dalam satu iterasi polling, waktu tunggu maksimum adalah 1 batas waktu:
Selain itu, kami memodifikasi dan meningkatkan sistem polling untuk permintaan SNMP. Faktanya adalah kebanyakan orang tidak dapat merespons beberapa permintaan SNMP secara bersamaan. Oleh karena itu, kami membuat mode hybrid, ketika polling SNMP dari host yang sama dilakukan secara asinkron:
Hal ini dilakukan untuk seluruh paket host. Mode ini pada akhirnya tidak lebih lambat dari mode asinkron sepenuhnya, karena polling satu setengah ratus nilai SNMP masih jauh lebih cepat daripada 1 batas waktu.
Eksperimen kami menunjukkan bahwa jumlah permintaan optimal dalam satu iterasi adalah sekitar 8 ribu dengan polling SNMP. Secara total, transisi ke mode asynchronous memungkinkan kami mempercepat kinerja polling sebanyak 200 kali, beberapa ratus kali lipat.
KIA: – Optimalisasi jajak pendapat yang dihasilkan menunjukkan bahwa kita tidak hanya dapat menghilangkan semua proxy, namun juga mengurangi interval untuk banyak pemeriksaan, dan proxy tidak lagi diperlukan sebagai cara untuk berbagi beban.
Sekitar tiga bulan lalu
Ubah arsitektur - tambah beban!
MM: - Nah, Max, apakah ini waktunya produktif? Saya memerlukan server yang kuat dan insinyur yang baik.
KIA: - Oke, ayo kita rencanakan. Ini adalah waktu yang tepat untuk beralih dari titik mati 5 ribu metrik per detik.
Pagi setelah peningkatan
KIA: - Misha, kami memperbarui diri, tetapi di pagi hari kami memutar kembali... Coba tebak, kecepatan apa yang berhasil kami capai?
MM: – maksimal 20 ribu.
KIA: - Ya, 25! Sayangnya, kita berada tepat di titik awal kita memulainya.
MM: - Mengapa? Apakah Anda menjalankan diagnostik?
KIA: - Ya tentu! Di sini, misalnya, adalah atasan yang menarik:
MM: - Mari kita lihat. Saya melihat bahwa kami telah mencoba sejumlah besar rangkaian jajak pendapat:
Namun pada saat yang sama mereka tidak dapat mendaur ulang sistem tersebut bahkan hingga setengahnya:
Dan performa keseluruhannya cukup kecil, sekitar 4 ribu metrik per detik:
Apakah ada hal lain?
KIA: – Ya, salah satu pemberi suara:
MM: – Di sini Anda dapat melihat dengan jelas bahwa proses pemungutan suara sedang menunggu “semafor”. Ini adalah kuncinya:
KIA: - Tidak jelas.
MM: – Begini, ini mirip dengan situasi di mana sekelompok thread mencoba bekerja dengan sumber daya yang hanya dapat digunakan oleh satu orang dalam satu waktu. Yang dapat mereka lakukan hanyalah membagikan sumber daya ini seiring berjalannya waktu:
Dan kinerja total bekerja dengan sumber daya tersebut dibatasi oleh kecepatan satu inti:
Ada dua cara untuk mengatasi masalah ini.
Tingkatkan perangkat keras mesin, beralih ke inti yang lebih cepat:
Atau ubah arsitektur dan sekaligus ubah bebannya:
KIA: – Omong-omong, pada mesin uji kami akan menggunakan lebih sedikit inti daripada mesin tempur, tetapi frekuensi per inti 1,5 kali lebih cepat!
MM: - Jernih? Anda perlu melihat kode server.
Jalur data di server Zabbix
KIA: – Untuk mengetahuinya, kami mulai menganalisis bagaimana data ditransfer di dalam server Zabbix:
Gambarnya keren, kan? Mari kita bahas langkah demi langkah agar lebih atau kurang jelas. Ada thread dan layanan yang bertanggung jawab untuk mengumpulkan data:
Mereka mengirimkan metrik yang dikumpulkan melalui soket ke manajer Praprosesor, tempat metrik tersebut disimpan dalam antrean:
“Manajer praprosesor” mengirimkan data ke pekerjanya, yang menjalankan instruksi prapemrosesan dan mengembalikannya melalui soket yang sama:
Setelah ini, manajer praprosesor menyimpannya di cache riwayat:
Dari sana mereka diambil oleh penyerap sejarah, yang melakukan cukup banyak fungsi: misalnya, menghitung pemicu, mengisi cache nilai dan, yang paling penting, menyimpan metrik dalam penyimpanan sejarah. Secara umum, prosesnya rumit dan sangat membingungkan.
MM: – Hal pertama yang kami lihat adalah sebagian besar thread bersaing untuk mendapatkan apa yang disebut “cache konfigurasi” (area memori tempat semua konfigurasi server disimpan). Thread yang bertanggung jawab untuk mengumpulkan data melakukan banyak pemblokiran:
...karena konfigurasi tidak hanya menyimpan metrik dengan parameternya, tetapi juga antrean tempat polling mengambil informasi tentang apa yang harus dilakukan selanjutnya. Ketika ada banyak poller dan satu memblokir konfigurasi, yang lain menunggu permintaan:
Pihak yang melakukan pemungutan suara tidak boleh menimbulkan konflik
Oleh karena itu, hal pertama yang kami lakukan adalah membagi antrean menjadi 4 bagian dan mengizinkan petugas pemungutan suara untuk memblokir antrean ini, sekaligus bagian-bagian ini, dalam kondisi aman:
Hal ini menghilangkan persaingan untuk cache konfigurasi, dan kecepatan polling meningkat secara signifikan. Namun kemudian kami menemukan fakta bahwa manajer praprosesor mulai mengumpulkan antrian pekerjaan:
Manajer praprosesor harus dapat membuat prioritas
Ini terjadi ketika kinerjanya kurang. Kemudian yang bisa dia lakukan hanyalah mengumpulkan permintaan dari proses pengumpulan data dan menambahkan buffernya hingga menghabiskan seluruh memori dan crash:
Untuk mengatasi masalah ini, kami menambahkan soket kedua yang didedikasikan khusus untuk pekerja:
Dengan demikian, manajer praprosesor memiliki kemampuan untuk memprioritaskan pekerjaannya dan, jika buffer bertambah, tugasnya adalah memperlambat penghapusan, memberikan kesempatan kepada pekerja untuk menggunakan buffer ini:
Kemudian kami menemukan bahwa salah satu penyebab perlambatan ini adalah para pekerja itu sendiri, karena mereka bersaing untuk mendapatkan sumber daya yang sama sekali tidak penting bagi pekerjaan mereka. Kami mendokumentasikan masalah ini sebagai perbaikan bug, dan masalah ini telah diatasi di Zabbix versi baru:
Kami menambah jumlah soket - kami mendapatkan hasilnya
Selanjutnya, manajer praprosesor itu sendiri menjadi hambatan, karena merupakan satu thread. Itu bertumpu pada kecepatan inti, memberikan kecepatan maksimum sekitar 70 ribu metrik per detik:
Oleh karena itu, kami membuat empat, dengan empat set soket, pekerja:
Dan ini memungkinkan kami meningkatkan kecepatan hingga sekitar 130 ribu metrik:
Non-linearitas pertumbuhan dijelaskan oleh fakta bahwa persaingan untuk mendapatkan cache sejarah telah muncul. 4 manajer praprosesor dan penyerap sejarah bersaing untuk itu. Saat ini, kami menerima sekitar 130 ribu metrik per detik pada mesin pengujian, menggunakannya oleh sekitar 95% prosesor:
Sekitar 2,5 bulan yang lalu
Penolakan dari komunitas snmp meningkatkan NVP satu setengah kali lipat
MM: – Max, saya butuh mobil uji baru! Kita tidak lagi cocok dengan keadaan saat ini.
KIA: - Apa yang kamu punya sekarang?
MM: – Sekarang – 130 ribu NVP dan prosesor siap pakai.
KIA: - Wow! Dingin! Tunggu, saya punya dua pertanyaan. Menurut perhitungan saya, kebutuhan kita sekitar 15-20 ribu metrik per detik. Mengapa kita membutuhkan lebih banyak?
MM: “Saya ingin menyelesaikan pekerjaan ini.” Saya ingin melihat seberapa besar manfaat yang dapat kita peroleh dari sistem ini.
KIA: - Tetapi…
MM: “Tapi itu tidak ada gunanya untuk bisnis.”
KIA: - Itu sudah jelas. Dan pertanyaan kedua: bisakah kita mendukung apa yang kita miliki sekarang sendiri, tanpa bantuan pengembang?
MM: - Menurutku tidak. Mengubah cara kerja cache konfigurasi adalah sebuah masalah. Ini mempengaruhi perubahan di sebagian besar thread dan cukup sulit untuk dipertahankan. Kemungkinan besar, akan sangat sulit untuk mempertahankannya.
KIA: “Maka kita memerlukan semacam alternatif.”
MM: - Ada pilihan seperti itu. Kita dapat beralih ke core cepat, sambil mengabaikan sistem penguncian baru. Kami masih akan mendapatkan performa 60-80 ribu metrik. Pada saat yang sama, kita dapat meninggalkan seluruh kode lainnya. Clickhouse dan polling asinkron akan berfungsi. Dan perawatannya akan mudah.
KIA: - Luar biasa! Saya sarankan kita berhenti di sini.
Setelah mengoptimalkan sisi server, kami akhirnya dapat meluncurkan kode baru ke dalam produksi. Kami mengabaikan beberapa perubahan demi beralih ke mesin dengan core cepat dan meminimalkan jumlah perubahan kode. Kami juga telah menyederhanakan konfigurasi dan menghilangkan makro di item data jika memungkinkan, karena makro tersebut memperkenalkan penguncian tambahan.
Misalnya, mengabaikan makro komunitas snmp, yang sering ditemukan dalam dokumentasi dan contoh, dalam kasus kami memungkinkan untuk lebih mempercepat NVP sekitar 1,5 kali lipat.
Setelah dua hari dalam produksi
Menghapus pop-up riwayat insiden
KIA: – Misha, kami telah menggunakan sistem ini selama dua hari, dan semuanya berfungsi. Tapi hanya jika semuanya berfungsi! Kami telah merencanakan pekerjaan dengan transfer segmen jaringan yang cukup besar, dan kami kembali memeriksa dengan tangan kami apa yang naik dan apa yang tidak.
MM: - Tidak mungkin! Kami memeriksa semuanya 10 kali. Server menangani ketidaktersediaan jaringan lengkap secara instan.
KIA: - Ya, saya mengerti segalanya: server, database, top, austat, log - semuanya cepat... Tapi kita melihat antarmuka web, dan ada prosesor "di rak" di server dan ini:
MM: - Itu sudah jelas. Mari kita lihat webnya. Kami menemukan bahwa dalam situasi di mana terdapat banyak insiden aktif, sebagian besar widget langsung mulai bekerja dengan sangat lambat:
Alasannya adalah pembuatan pop-up riwayat insiden yang dihasilkan untuk setiap item dalam daftar. Oleh karena itu, kami mengabaikan pembuatan jendela ini (mengomentari 5 baris kode), dan ini memecahkan masalah kami.
Waktu pemuatan widget, meskipun sama sekali tidak tersedia, telah dikurangi dari beberapa menit menjadi 10-15 detik yang dapat kami terima, dan riwayat masih dapat dilihat dengan mengklik waktu:
Setelah bekerja. 2 bulan yang lalu
KIA: - Misha, kamu mau berangkat? Kita harus bicara.
MM: - Aku tidak bermaksud melakukannya. Sesuatu dengan Zabbix lagi?
KIA: - Tidak, santai saja! Saya hanya ingin mengatakan: semuanya berfungsi, terima kasih! Aku punya bir.
Zabbix efisien
Zabbix adalah sistem dan fungsi yang cukup universal dan kaya. Ini dapat digunakan untuk instalasi kecil, namun seiring dengan meningkatnya kebutuhan, itu harus dioptimalkan. Untuk menyimpan arsip metrik yang besar, gunakan penyimpanan yang sesuai:
- Anda dapat menggunakan alat bawaan dalam bentuk integrasi dengan Elasticsearch atau mengunggah riwayat ke file teks (tersedia mulai versi XNUMX);
- Anda dapat memanfaatkan pengalaman dan integrasi kami dengan Clickhouse.
Untuk meningkatkan kecepatan pengumpulan metrik secara signifikan, kumpulkan metrik tersebut menggunakan metode asinkron dan kirimkan melalui antarmuka trapper ke server Zabbix; atau Anda dapat menggunakan patch untuk membuat poller Zabbix menjadi asinkron.
Zabbix ditulis dalam C dan cukup efisien. Memecahkan beberapa hambatan arsitektural memungkinkan Anda untuk lebih meningkatkan kinerjanya dan, menurut pengalaman kami, memperoleh lebih dari 100 ribu metrik pada mesin prosesor tunggal.
Patch Zabbix yang sama
MM: – Saya ingin menambahkan beberapa poin. Seluruh laporan saat ini, semua pengujian, nomor diberikan untuk konfigurasi yang kami gunakan. Kami sekarang mengambil sekitar 20 ribu metrik per detik darinya. Jika Anda mencoba memahami apakah ini berhasil untuk Anda, Anda dapat membandingkannya. Apa yang dibahas hari ini diposting di GitHub dalam bentuk patch:
Tambalannya meliputi:
- integrasi penuh dengan Clickhouse (server Zabbix dan frontend);
- menyelesaikan masalah dengan manajer praprosesor;
- pemungutan suara asinkron.
Patch ini kompatibel dengan semua versi 4, termasuk lts. Kemungkinan besar, dengan sedikit perubahan, ini akan berfungsi pada versi 3.4.
Terima kasih atas perhatian Anda.
pertanyaan
Pertanyaan dari penonton (selanjutnya – A): – Selamat siang! Tolong beritahu saya, apakah Anda memiliki rencana untuk interaksi intensif dengan tim Zabbix atau dengan mereka bersama Anda, sehingga ini bukan tambalan, tetapi perilaku normal Zabbix?
MM: – Ya, kami pasti akan melakukan beberapa perubahan. Sesuatu akan terjadi, sesuatu akan tetap ada di tambalan.
A: – Terima kasih banyak atas laporan yang luar biasa! Tolong beri tahu saya, setelah menerapkan tambalan, dukungan dari Zabbix akan tetap ada dan bagaimana cara terus memperbarui ke versi yang lebih tinggi? Apakah mungkin untuk memperbarui Zabbix setelah patch Anda ke 4.2, 5.0?
MM: – Saya tidak bisa mengatakan apa pun tentang dukungan. Jika saya adalah dukungan teknis Zabbix, saya mungkin akan mengatakan tidak, karena ini adalah kode orang lain. Sedangkan untuk basis kode 4.2, posisi kami adalah: “Kami akan bergerak seiring waktu, dan kami akan memperbarui diri pada versi berikutnya.” Oleh karena itu, untuk beberapa waktu kami akan memposting patch untuk versi terbaru. Saya sudah katakan di laporan: jumlah perubahan versi masih cukup kecil. Saya pikir transisi dari 3.4 ke 4 memakan waktu sekitar 15 menit. Ada yang berubah di sana, tapi tidak terlalu penting.
A: – Jadi Anda berencana untuk mendukung patch Anda dan Anda dapat menginstalnya dengan aman dalam produksi dan menerima pembaruan di masa mendatang?
MM: – Kami sangat merekomendasikannya. Ini memecahkan banyak masalah bagi kami.
KIA: – Sekali lagi, saya ingin menarik perhatian pada fakta bahwa perubahan yang tidak menyangkut arsitektur dan tidak menyangkut pemblokiran atau antrian bersifat modular, mereka berada dalam modul terpisah. Bahkan dengan perubahan kecil pun Anda dapat mempertahankannya dengan cukup mudah.
MM: – Jika Anda tertarik dengan detailnya, maka “Clickhouse” menggunakan apa yang disebut perpustakaan sejarah. Itu tidak terikat - ini adalah salinan dari dukungan Elastics, yaitu dapat dikonfigurasi. Jajak pendapat hanya mengubah pemberi suara. Kami yakin ini akan berhasil untuk jangka waktu yang lama.
A: - Terima kasih banyak. Katakan padaku, apakah ada dokumentasi tentang perubahan yang dilakukan?
MM: – Dokumentasi adalah tambalan. Jelasnya, dengan diperkenalkannya Clickhouse, dengan diperkenalkannya jenis poller baru, opsi konfigurasi baru pun muncul. Tautan dari slide terakhir memiliki penjelasan singkat tentang cara menggunakannya.
Tentang mengganti fping dengan nmap
A: – Bagaimana Anda akhirnya menerapkan hal ini? Bisakah Anda memberikan contoh spesifik: apakah Anda memiliki strapper dan skrip eksternal? Apa yang akhirnya memeriksa sejumlah besar host dengan begitu cepat? Bagaimana cara Anda menambang host ini? Apakah kita perlu memasukkannya ke nmap, mendapatkannya dari suatu tempat, memasukkannya, menjalankan sesuatu?..
MM: - Dingin. Sebuah pertanyaan yang sangat tepat! Intinya adalah ini. Kami memodifikasi perpustakaan (ping ICMP, bagian dari Zabbix) untuk pemeriksaan ICMP, yang menunjukkan jumlah paket - satu (1), dan kode mencoba menggunakan nmap. Artinya, ini adalah pekerjaan internal Zabbix, yang telah menjadi pekerjaan internal pinger. Oleh karena itu, tidak diperlukan sinkronisasi atau penggunaan penjebak. Hal ini dilakukan dengan sengaja agar sistem tetap utuh dan tidak harus berurusan dengan sinkronisasi dua sistem database: apa yang harus diperiksa, diunggah melalui poller, dan apakah unggahan kita rusak?.. Ini jauh lebih sederhana.
A: – Apakah ini juga berfungsi untuk proxy?
MM: – Ya, tapi kami tidak memeriksanya. Kode pollingnya sama di Zabbix dan server. Seharusnya berhasil. Izinkan saya menekankan sekali lagi: kinerja sistem sedemikian rupa sehingga kita tidak memerlukan proxy.
KIA: – Jawaban yang benar untuk pertanyaan adalah: “Mengapa Anda memerlukan proxy dengan sistem seperti itu?” Hanya karena NAT atau pemantauan melalui semacam saluran lambat...
A: – Dan Anda menggunakan Zabbix sebagai allertor, jika saya mengerti dengan benar. Atau apakah grafik Anda (tempat lapisan arsip berada) dipindahkan ke sistem lain, seperti Grafana? Atau apakah Anda tidak menggunakan fungsi ini?
MM: – Saya tekankan sekali lagi: kita telah mencapai integrasi penuh. Kami menuangkan sejarah ke dalam Clickhouse, tetapi pada saat yang sama kami telah mengubah frontend php. Frontend Php menuju ke Clickhouse dan mengerjakan semua grafik dari sana. Pada saat yang sama, sejujurnya, kami memiliki bagian yang membuat data di sistem tampilan grafis lain dari Clickhouse yang sama, dari data Zabbix yang sama.
KIA: – Dalam “Grafan” juga.
Bagaimana keputusan dibuat mengenai alokasi sumber daya?
A: – Bagikan sedikit dapur bagian dalam Anda. Bagaimana keputusan dibuat bahwa perlu mengalokasikan sumber daya untuk pemrosesan produk yang serius? Secara umum, ini adalah risiko tertentu. Dan tolong beri tahu saya, dalam konteks fakta bahwa Anda akan mendukung versi baru: bagaimana keputusan ini dapat dibenarkan dari sudut pandang manajemen?
MM: – Tampaknya, kami tidak menceritakan drama sejarah dengan baik. Kami berada dalam situasi di mana sesuatu harus dilakukan, dan pada dasarnya kami menggunakan dua tim paralel:
- Salah satunya adalah meluncurkan sistem pemantauan menggunakan metode baru: pemantauan sebagai layanan, serangkaian solusi sumber terbuka standar yang kami gabungkan dan kemudian mencoba mengubah proses bisnis agar dapat bekerja dengan sistem pemantauan baru.
- Pada saat yang sama, kami memiliki seorang programmer yang antusias melakukan hal ini (tentang dirinya sendiri). Kebetulan dia menang.
A: – Dan berapa ukuran tim?
KIA: - Dia ada di depanmu.
A: – Jadi, seperti biasa, Anda membutuhkan yang penuh gairah?
MM: – Saya tidak tahu apa itu passion.
A: - Dalam hal ini, rupanya, kamu. Terima kasih banyak, kamu luar biasa.
MM: - Terima kasih.
Tentang patch untuk Zabbix
A: – Untuk sistem yang menggunakan proxy (misalnya, dalam beberapa sistem terdistribusi), apakah mungkin untuk mengadaptasi dan menambal, katakanlah, poller, proxy, dan sebagian praprosesor Zabbix itu sendiri; dan interaksi mereka? Apakah mungkin untuk mengoptimalkan pengembangan yang ada untuk sistem dengan banyak proxy?
MM: – Saya tahu bahwa server Zabbix dirakit menggunakan proxy (kode dikompilasi dan diperoleh). Kami belum menguji ini dalam produksi. Saya tidak yakin tentang ini, tapi menurut saya manajer praprosesor tidak digunakan di proxy. Tugas proxy adalah mengambil sekumpulan metrik dari Zabbix, menggabungkannya (juga mencatat konfigurasi, database lokal) dan mengembalikannya ke server Zabbix. Server sendiri kemudian akan melakukan preprocessing ketika menerimanya.
Ketertarikan terhadap proxy dapat dimengerti. Kami akan memeriksanya. Ini adalah topik yang menarik.
A: – Idenya adalah ini: jika Anda dapat menambal poller, Anda dapat menambalnya di proxy dan menambal interaksi dengan server, dan mengadaptasi praprosesor untuk tujuan ini hanya di server.
MM: – Saya pikir ini lebih sederhana. Anda mengambil kodenya, menerapkan patch, lalu mengkonfigurasinya sesuai kebutuhan - mengumpulkan server proxy (misalnya, dengan ODBC) dan mendistribusikan kode patch ke seluruh sistem. Jika perlu - kumpulkan proxy, jika perlu - server.
A: – Kemungkinan besar, Anda tidak perlu menambal transmisi proxy ke server juga?
KIA: - Tidak, itu standar.
MM: – Faktanya, salah satu idenya tidak terdengar. Kami selalu menjaga keseimbangan antara ledakan ide dan jumlah perubahan serta kemudahan dukungan.
Beberapa iklan 🙂
Terima kasih untuk tetap bersama kami. Apakah Anda menyukai artikel kami? Ingin melihat konten yang lebih menarik? Dukung kami dengan melakukan pemesanan atau merekomendasikan kepada teman, , analog unik dari server level awal, yang kami temukan untuk Anda: (tersedia dengan RAID1 dan RAID10, hingga 24 core dan hingga 40GB DDR4).
Dell R730xd 2x lebih murah di pusat data Equinix Tier IV di Amsterdam? Hanya disini di Belanda! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - mulai $99! Membaca tentang
Sumber: www.habr.com