Persidangan HighLoad++ seterusnya akan diadakan pada 6 dan 7 April 2020 di St. Petersburg Butiran dan tiket . HighLoad++ Moscow 2018. Dewan "Moscow". 9 November, 15:00. Tesis dan .
* Pemantauan - dalam talian dan analitik.
* Had asas platform ZABBIX.
* Penyelesaian untuk menskalakan storan analitik.
* Pengoptimuman pelayan ZABBIX.
* Pengoptimuman UI.
* Alami mengendalikan sistem di bawah beban lebih daripada 40k NVPS.
* Kesimpulan ringkas.
Mikhail Makurov (selepas ini – MM): - Hai semua!
Maxim Chernetsov (selepas ini – MCH): - Selamat petang!
MM: – Izinkan saya memperkenalkan Maxim. Max ialah seorang jurutera berbakat, perangkaian terbaik yang saya kenali. Maxim terlibat dalam rangkaian dan perkhidmatan, pembangunan dan operasinya.
MCH: – Dan saya ingin memberitahu anda tentang Mikhail. Mikhail ialah pembangun C. Dia menulis beberapa penyelesaian pemprosesan trafik muatan tinggi untuk syarikat kami. Kami tinggal dan bekerja di Ural, di bandar lelaki tangguh Chelyabinsk, di syarikat Intersvyaz. Syarikat kami ialah penyedia perkhidmatan Internet dan televisyen kabel untuk satu juta orang di 16 bandar.
MM: – Dan patut dikatakan bahawa Intersvyaz adalah lebih daripada sekadar pembekal, ia adalah syarikat IT. Kebanyakan penyelesaian kami dibuat oleh jabatan IT kami.
J: daripada pelayan memproses trafik ke pusat panggilan dan aplikasi mudah alih. Jabatan IT kini mempunyai kira-kira 80 orang dengan kecekapan yang sangat pelbagai.
Mengenai Zabbix dan seni binanya
MCH: – Dan sekarang saya akan cuba menetapkan rekod peribadi dan mengatakan dalam satu minit apa itu Zabbix (selepas ini dirujuk sebagai "Zabbix").
Zabbix meletakkan dirinya sebagai sistem pemantauan out-of-the-box peringkat perusahaan. Ia mempunyai banyak ciri yang menjadikan kehidupan lebih mudah: peraturan peningkatan lanjutan, API untuk penyepaduan, pengumpulan dan pengesanan automatik hos dan metrik. Zabbix mempunyai alat penskalaan yang dipanggil - proksi. Zabbix ialah sistem sumber terbuka.
Secara ringkas tentang seni bina. Kita boleh mengatakan bahawa ia terdiri daripada tiga komponen:
- pelayan. Ditulis dalam C. Dengan pemprosesan dan pemindahan maklumat yang agak kompleks antara benang. Semua pemprosesan berlaku di dalamnya: daripada menerima kepada menyimpan ke pangkalan data.
- Semua data disimpan dalam pangkalan data. Zabbix menyokong MySQL, PostreSQL dan Oracle.
- Antara muka web ditulis dalam PHP. Pada kebanyakan sistem ia disertakan dengan pelayan Apache, tetapi berfungsi dengan lebih cekap dalam kombinasi dengan nginx + php.
Hari ini kami ingin menceritakan satu kisah dari kehidupan syarikat kami yang berkaitan dengan Zabbix...
Kisah dari kehidupan syarikat Intersvyaz. Apa yang kita ada dan apa yang kita perlukan?
5 atau 6 bulan yang lalu. Sehari selepas kerja...
MCH: - Misha, hello! Saya gembira saya berjaya menangkap awak - ada perbualan. Kami sekali lagi menghadapi masalah dengan pemantauan. Semasa kemalangan besar, semuanya perlahan dan tiada maklumat tentang keadaan rangkaian. Malangnya, ini bukan kali pertama berlaku. Saya perlukan bantuan anda. Mari jadikan pemantauan kami berfungsi dalam apa jua keadaan!
MM: - Tetapi mari kita selaraskan dahulu. Saya tidak melihat ke sana dalam beberapa tahun. Seingat saya, kami meninggalkan Nagios dan bertukar kepada Zabbix kira-kira 8 tahun yang lalu. Dan kini kami nampaknya mempunyai 6 pelayan berkuasa dan kira-kira sedozen proksi. Adakah saya mengelirukan apa-apa?
MCH: - Hampir. 15 pelayan, sebahagian daripadanya adalah mesin maya. Perkara yang paling penting ialah ia tidak menyelamatkan kita pada masa yang paling kita perlukan. Seperti kemalangan - pelayan perlahan dan anda tidak dapat melihat apa-apa. Kami cuba mengoptimumkan konfigurasi, tetapi ini tidak memberikan peningkatan prestasi yang optimum.
MM: - Ia jelas. Adakah anda melihat sesuatu, adakah anda sudah mencungkil sesuatu daripada diagnostik?
MCH: – Perkara pertama yang perlu anda uruskan ialah pangkalan data. MySQL sentiasa dimuatkan, menyimpan metrik baharu, dan apabila Zabbix mula menjana sekumpulan peristiwa, pangkalan data menjadi terlalu pemacu selama beberapa jam. Saya sudah memberitahu anda tentang mengoptimumkan konfigurasi, tetapi secara literal tahun ini mereka mengemas kini perkakasan: pelayan mempunyai lebih daripada seratus gigabait memori dan susunan cakera pada SSD RAID - tidak ada gunanya mengembangkannya secara linear dalam jangka panjang. Apa yang kita lakukan?
MM: - Ia jelas. Secara amnya, MySQL ialah pangkalan data LTP. Nampaknya, ia tidak lagi sesuai untuk menyimpan arkib metrik saiz kami. Mari kita fikirkan.
MCH: - Jom!
Integrasi Zabbix dan Clickhouse hasil daripada hackathon
Selepas beberapa lama kami menerima data yang menarik:
Kebanyakan ruang dalam pangkalan data kami telah diduduki oleh arkib metrik dan kurang daripada 1% digunakan untuk konfigurasi, templat dan tetapan. Pada masa itu, kami telah mengendalikan penyelesaian data Besar berdasarkan Clickhouse selama lebih daripada setahun. Arah pergerakan jelas kepada kami. Di Hackathon musim bunga kami, saya menulis integrasi Zabbix dengan Clickhouse untuk pelayan dan bahagian hadapan. Pada masa itu, Zabbix sudah mempunyai sokongan untuk ElasticSearch, dan kami memutuskan untuk membandingkannya.
Perbandingan Clickhouse dan Elasticsearch
MM: – Sebagai perbandingan, kami menjana beban yang sama seperti yang disediakan oleh pelayan Zabbix dan melihat bagaimana sistem akan bertindak. Kami menulis data dalam kelompok 1000 baris, menggunakan CURL. Kami mengandaikan terlebih dahulu bahawa Clickhouse akan menjadi lebih cekap untuk profil pemuatan yang Zabbix lakukan. Hasilnya bahkan melebihi jangkaan kami:
Di bawah keadaan ujian yang sama, Clickhouse menulis tiga kali lebih banyak data. Pada masa yang sama, kedua-dua sistem menggunakan sangat cekap (sebilangan kecil sumber) semasa membaca data. Tetapi Elastics memerlukan sejumlah besar pemproses semasa merakam:
Secara keseluruhan, Clickhouse jauh lebih unggul daripada Elastix dari segi penggunaan dan kelajuan pemproses. Pada masa yang sama, disebabkan oleh pemampatan data, Clickhouse menggunakan 11 kali lebih sedikit pada pemacu keras dan melakukan kira-kira 30 kali lebih sedikit operasi cakera:
MCH: – Ya, kerja Clickhouse dengan subsistem cakera dilaksanakan dengan sangat cekap. Anda boleh menggunakan cakera SATA yang besar untuk pangkalan data dan mendapatkan kelajuan menulis ratusan ribu baris sesaat. Sistem out-of-the-box menyokong sharding, replikasi, dan sangat mudah untuk dikonfigurasikan. Kami lebih berpuas hati dengan penggunaannya sepanjang tahun.
Untuk mengoptimumkan sumber, anda boleh memasang Clickhouse di sebelah pangkalan data utama anda yang sedia ada dan dengan itu menjimatkan banyak masa CPU dan operasi cakera. Kami telah mengalihkan arkib metrik ke kluster Clickhouse sedia ada:
Kami melegakan pangkalan data MySQL utama sehingga kami boleh menggabungkannya pada satu mesin dengan pelayan Zabbix dan meninggalkan pelayan khusus untuk MySQL.
Bagaimanakah pengundian berfungsi di Zabbix?
4 bulan lalu
MM: – Nah, bolehkah kita melupakan masalah dengan pangkalan?
MCH: - Itu yang pasti! Masalah lain yang perlu kami selesaikan ialah pengumpulan data yang perlahan. Kini semua 15 pelayan proksi kami telah terlebih sarat dengan SNMP dan proses pengundian. Dan tidak ada cara kecuali memasang pelayan baharu dan baharu.
MM: - Hebat. Tetapi pertama-tama, beritahu kami cara pengundian berfungsi dalam Zabbix?
MCH: – Ringkasnya, terdapat 20 jenis metrik dan sedozen cara untuk mendapatkannya. Zabbix boleh mengumpul data sama ada dalam mod "tindak balas permintaan", atau menunggu data baharu melalui "Antara Muka Penjebak".
Perlu diingat bahawa dalam Zabbix asal kaedah ini (Trapper) adalah yang terpantas.
Terdapat pelayan proksi untuk pengagihan beban:
Proksi boleh melaksanakan fungsi pengumpulan yang sama seperti pelayan Zabbix, menerima tugas daripadanya dan menghantar metrik yang dikumpul melalui antara muka Trapper. Ini ialah cara yang disyorkan secara rasmi untuk mengagihkan beban. Proksi juga berguna untuk memantau infrastruktur jauh yang beroperasi melalui NAT atau saluran perlahan:
MM: – Semuanya jelas dengan seni bina. Kita perlu melihat sumber...
Beberapa hari kemudian
Kisah bagaimana nmap fping menang
MM: "Saya rasa saya telah menggali sesuatu."
MCH: - Beritahu saya!
MM: – Saya mendapati bahawa semasa menyemak ketersediaan, Zabbix menyemak maksimum 128 hos pada satu masa. Saya cuba meningkatkan nombor ini kepada 500 dan mengalih keluar selang antara paket dalam ping (ping) mereka - ini menggandakan prestasi. Tetapi saya mahu nombor yang lebih besar.
MCH: – Dalam amalan saya, kadangkala saya perlu menyemak ketersediaan beribu-ribu hos, dan saya tidak pernah melihat apa-apa yang lebih pantas daripada nmap untuk ini. Saya pasti ini adalah cara terpantas. Jom cuba! Kita perlu meningkatkan bilangan hos setiap lelaran dengan ketara.
MM: – Semak lebih daripada lima ratus? 600?
MCH: - Sekurang-kurangnya beberapa ribu.
MM: - OKEY. Perkara paling penting yang saya ingin katakan ialah saya mendapati bahawa kebanyakan pengundian di Zabbix dilakukan secara serentak. Kami pastinya perlu menukarnya kepada mod tak segerak. Kemudian kita boleh meningkatkan secara mendadak bilangan metrik yang dikumpul oleh pengundi, terutamanya jika kita meningkatkan bilangan metrik setiap lelaran.
MCH: - Hebat! Dan bila?
MM: – Seperti biasa, semalam.
MCH: – Kami membandingkan kedua-dua versi fping dan nmap:
Pada sebilangan besar hos, nmap dijangkakan sehingga lima kali lebih berkesan. Memandangkan nmap hanya menyemak ketersediaan dan masa tindak balas, kami mengalihkan pengiraan kerugian kepada pencetus dan mengurangkan selang semakan ketersediaan dengan ketara. Kami mendapati bilangan hos yang optimum untuk nmap adalah sekitar 4 ribu setiap lelaran. Nmap membenarkan kami mengurangkan kos CPU untuk semakan ketersediaan sebanyak tiga kali dan mengurangkan selang daripada 120 saat kepada 10.
Pengoptimuman pengundian
MM: “Kemudian kami mula melakukan tinjauan pendapat. Kami terutamanya berminat dalam pengesanan dan ejen SNMP. Di Zabbix, pengundian dilakukan secara serentak dan langkah khas telah diambil untuk meningkatkan kecekapan sistem. Dalam mod segerak, ketiadaan hos menyebabkan kemerosotan undian yang ketara. Terdapat keseluruhan sistem negeri, terdapat proses khas - yang dipanggil pemungutan suara yang tidak dapat dicapai, yang berfungsi hanya dengan hos yang tidak dapat dicapai:
Ini ialah ulasan yang menunjukkan matriks keadaan, semua kerumitan sistem peralihan yang diperlukan agar sistem itu kekal berkesan. Di samping itu, pengundian segerak itu sendiri agak perlahan:
Itulah sebabnya beribu-ribu aliran tinjauan pendapat pada berpuluh-puluh proksi tidak dapat mengumpul jumlah data yang diperlukan untuk kami. Pelaksanaan tak segerak menyelesaikan bukan sahaja masalah dengan bilangan utas, tetapi juga memudahkan sistem keadaan hos yang tidak tersedia dengan ketara, kerana untuk sebarang nombor yang diperiksa dalam satu lelaran pengundian, masa menunggu maksimum ialah 1 tamat masa:
Selain itu, kami mengubah suai dan menambah baik sistem pengundian untuk permintaan SNMP. Hakikatnya ialah kebanyakan orang tidak boleh bertindak balas kepada berbilang permintaan SNMP pada masa yang sama. Oleh itu, kami membuat mod hibrid, apabila pengundian SNMP bagi hos yang sama dilakukan secara tak segerak:
Ini dilakukan untuk keseluruhan pek hos. Mod ini akhirnya tidak lebih perlahan daripada mod tak segerak sepenuhnya, kerana mengundi satu setengah ratus nilai SNMP masih jauh lebih cepat daripada 1 tamat masa.
Percubaan kami telah menunjukkan bahawa bilangan permintaan optimum dalam satu lelaran ialah kira-kira 8 ribu dengan tinjauan SNMP. Secara keseluruhannya, peralihan kepada mod tak segerak membolehkan kami mempercepatkan prestasi pengundian sebanyak 200 kali ganda, beberapa ratus kali ganda.
MCH: – Pengoptimuman tinjauan pendapat yang terhasil menunjukkan bahawa kami bukan sahaja boleh menyingkirkan semua proksi, tetapi juga mengurangkan selang untuk banyak semakan, dan proksi tidak lagi diperlukan sebagai cara untuk berkongsi beban.
Kira-kira tiga bulan lalu
Tukar seni bina - tingkatkan beban!
MM: - Nah, Max, adakah masa untuk menjadi produktif? Saya memerlukan pelayan yang berkuasa dan jurutera yang baik.
MCH: - Baiklah, mari kita rancang. Sudah tiba masanya untuk bergerak dari titik mati 5 ribu metrik sesaat.
Pagi selepas naik taraf
MCH: - Misha, kami mengemas kini diri kami, tetapi pada waktu pagi kami berpatah balik... Cuba teka berapa kelajuan yang kami berjaya capai?
MM: – 20 ribu maksimum.
MCH: - Ya, 25! Malangnya, kami berada di tempat kami bermula.
MM: - Kenapa? Adakah anda menjalankan sebarang diagnostik?
MCH: - Ya pasti! Di sini, sebagai contoh, adalah bahagian atas yang menarik:
MM: - Jom tonton. Saya melihat bahawa kami telah mencuba sejumlah besar urutan pengundian:
Tetapi pada masa yang sama mereka tidak dapat mengitar semula sistem walaupun separuh:
Dan prestasi keseluruhan agak kecil, kira-kira 4 ribu metrik sesaat:
Ada apa-apa lagi?
MCH: – Ya, jejak salah seorang pengundi:
MM: – Di sini anda boleh melihat dengan jelas bahawa proses pengundian sedang menunggu "semaphore". Ini adalah kunci:
MCH: - Tidak jelas.
MM: – Lihat, ini serupa dengan situasi di mana sekumpulan benang cuba berfungsi dengan sumber yang hanya boleh digunakan oleh satu pada satu masa. Kemudian apa yang boleh mereka lakukan ialah berkongsi sumber ini dari semasa ke semasa:
Dan jumlah prestasi bekerja dengan sumber sedemikian dihadkan oleh kelajuan satu teras:
Terdapat dua cara untuk menyelesaikan masalah ini.
Tingkatkan perkakasan mesin, tukar kepada teras yang lebih pantas:
Atau tukar seni bina dan pada masa yang sama tukar beban:
MCH: – Ngomong-ngomong, pada mesin ujian kami akan menggunakan lebih sedikit teras daripada pada satu pertempuran, tetapi ia adalah 1,5 kali lebih cepat dalam kekerapan setiap teras!
MM: - Jelas? Anda perlu melihat kod pelayan.
Laluan data dalam pelayan Zabbix
MCH: – Untuk mengetahuinya, kami mula menganalisis cara data dipindahkan di dalam pelayan Zabbix:
Gambar yang menarik kan? Mari kita lalui langkah demi langkah untuk menjadikannya lebih atau kurang jelas. Terdapat rangkaian dan perkhidmatan yang bertanggungjawab untuk mengumpul data:
Mereka menghantar metrik yang dikumpul melalui soket kepada pengurus Prapemproses, di mana ia disimpan dalam baris gilir:
"Pengurus prapemproses" menghantar data kepada pekerjanya, yang melaksanakan arahan prapemprosesan dan mengembalikannya melalui soket yang sama:
Selepas ini, pengurus prapemproses menyimpannya dalam cache sejarah:
Dari sana ia diambil oleh penyerap sejarah, yang melaksanakan banyak fungsi: contohnya, mengira pencetus, mengisi cache nilai dan, yang paling penting, menyimpan metrik dalam storan sejarah. Secara umum, prosesnya rumit dan sangat mengelirukan.
MM: – Perkara pertama yang kami lihat ialah kebanyakan utas bersaing untuk apa yang dipanggil "cache konfigurasi" (kawasan memori di mana semua konfigurasi pelayan disimpan). Benang yang bertanggungjawab untuk mengumpul data melakukan terutamanya banyak penyekatan:
...memandangkan konfigurasi menyimpan bukan sahaja metrik dengan parameternya, tetapi juga baris gilir dari mana pengundi mengambil maklumat tentang perkara yang perlu dilakukan seterusnya. Apabila terdapat banyak pengundi dan satu menyekat konfigurasi, yang lain menunggu permintaan:
Pengundi tidak sepatutnya bercanggah
Oleh itu, perkara pertama yang kami lakukan ialah membahagikan baris gilir kepada 4 bahagian dan membenarkan pengundi menyekat baris gilir ini, bahagian ini pada masa yang sama, di bawah keadaan selamat:
Ini mengalih keluar persaingan untuk cache konfigurasi, dan kelajuan pengundi meningkat dengan ketara. Tetapi kemudian kami menemui hakikat bahawa pengurus prapemproses mula mengumpul baris gilir kerja:
Pengurus prapemproses mesti boleh memberi keutamaan
Ini berlaku dalam kes di mana dia kurang prestasi. Kemudian apa yang dia boleh lakukan ialah mengumpul permintaan daripada proses pengumpulan data dan menambah penimbal mereka sehingga ia menggunakan semua memori dan ranap:
Untuk menyelesaikan masalah ini, kami menambah soket kedua yang didedikasikan khusus untuk pekerja:
Oleh itu, pengurus prapemproses mempunyai peluang untuk mengutamakan kerjanya dan, jika penimbal berkembang, tugasnya adalah untuk memperlahankan penyingkiran, memberi pekerja peluang untuk mengambil penimbal ini:
Kemudian kami mendapati bahawa salah satu sebab kelembapan adalah pekerja itu sendiri, kerana mereka bersaing untuk mendapatkan sumber yang sama sekali tidak penting untuk kerja mereka. Kami mendokumenkan masalah ini sebagai pembetulan pepijat, dan ia telah pun diselesaikan dalam versi baharu Zabbix:
Kami menambah bilangan soket - kami mendapat hasilnya
Selanjutnya, pengurus prapemproses itu sendiri menjadi hambatan, kerana ia adalah satu utas. Ia bergantung pada kelajuan teras, memberikan kelajuan maksimum kira-kira 70 ribu metrik sesaat:
Oleh itu, kami membuat empat, dengan empat set soket, pekerja:
Dan ini membolehkan kami meningkatkan kelajuan kepada kira-kira 130 ribu metrik:
Ketidak-linearan pertumbuhan dijelaskan oleh fakta bahawa persaingan untuk cache sejarah telah muncul. 4 pengurus prapemproses dan ahli sejarah bersaing untuk mendapatkannya. Pada ketika ini, kami menerima kira-kira 130 ribu metrik sesaat pada mesin ujian, menggunakan kira-kira 95% daripada pemproses:
Kira-kira 2,5 bulan yang lalu
Penolakan daripada komuniti snmp meningkatkan NVP sebanyak satu setengah kali ganda
MM: – Max, saya perlukan kereta ujian baharu! Kami tidak lagi sesuai dengan yang sekarang.
MCH: - Apa yang awak ada sekarang?
MM: – Sekarang – 130k NVP dan pemproses sedia rak.
MCH: - Wah! Sejuk! Tunggu, saya ada dua soalan. Mengikut pengiraan saya, keperluan kita sekitar 15-20 ribu metrik sesaat. Mengapa kita memerlukan lebih banyak lagi?
MM: "Saya mahu menyelesaikan kerja." Saya ingin melihat sejauh mana kita boleh memerah daripada sistem ini.
MCH: - Tetapi…
MM: "Tetapi ia tidak berguna untuk perniagaan."
MCH: - Ia jelas. Dan soalan kedua: bolehkah kita menyokong apa yang kita ada sekarang sendiri, tanpa bantuan pembangun?
MM: - Saya tidak fikir. Menukar cara cache konfigurasi berfungsi adalah masalah. Ia menjejaskan perubahan dalam kebanyakan benang dan agak sukar untuk dikekalkan. Kemungkinan besar, ia akan menjadi sangat sukar untuk mengekalkannya.
MCH: "Kemudian kita memerlukan beberapa jenis alternatif."
MM: - Terdapat pilihan sedemikian. Kita boleh bertukar kepada teras pantas, sambil meninggalkan sistem penguncian baharu. Kami masih akan mendapat prestasi 60-80 ribu metrik. Pada masa yang sama, kita boleh meninggalkan semua kod yang lain. Clickhouse dan pengundian tak segerak akan berfungsi. Dan ia akan menjadi mudah untuk mengekalkan.
MCH: - Hebat! Saya cadangkan kita berhenti di sini.
Selepas mengoptimumkan bahagian pelayan, kami akhirnya dapat melancarkan kod baharu ke dalam pengeluaran. Kami meninggalkan beberapa perubahan yang memihak kepada beralih kepada mesin dengan teras pantas dan meminimumkan bilangan perubahan kod. Kami juga telah memudahkan konfigurasi dan menghapuskan makro dalam item data jika boleh, kerana ia memperkenalkan penguncian tambahan.
Sebagai contoh, meninggalkan makro snmp-komuniti, yang sering dijumpai dalam dokumentasi dan contoh, dalam kes kami memungkinkan untuk mempercepatkan lagi NVP sebanyak kira-kira 1,5 kali.
Selepas dua hari dalam pengeluaran
Mengalih keluar tetingkap timbul sejarah kejadian
MCH: – Misha, kami telah menggunakan sistem selama dua hari, dan semuanya berfungsi. Tetapi hanya apabila semuanya berfungsi! Kami telah merancang kerja dengan pemindahan segmen rangkaian yang agak besar, dan kami sekali lagi menyemak dengan tangan kami apa yang naik dan apa yang tidak.
MM: - Tidak boleh! Kami menyemak semuanya 10 kali. Pelayan mengendalikan ketiadaan rangkaian yang lengkap dengan serta-merta.
MCH: - Ya, saya faham segala-galanya: pelayan, pangkalan data, atas, austat, log - semuanya pantas... Tetapi kami melihat antara muka web, dan terdapat pemproses "di rak" pada pelayan dan ini:
MM: - Ia jelas. Jom tonton web. Kami mendapati bahawa dalam situasi di mana terdapat sejumlah besar insiden aktif, kebanyakan widget langsung mula berfungsi dengan sangat perlahan:
Sebabnya ialah penjanaan tetingkap timbul sejarah kejadian yang dijana untuk setiap item dalam senarai. Oleh itu, kami meninggalkan penjanaan tetingkap ini (mengulas 5 baris dalam kod), dan ini menyelesaikan masalah kami.
Masa memuatkan widget, walaupun tidak tersedia sepenuhnya, telah dikurangkan daripada beberapa minit kepada 10-15 saat yang boleh diterima untuk kami, dan sejarah masih boleh dilihat dengan mengklik pada masa:
Selepas kerja. 2 bulan lepas
MCH: - Misha, awak pergi? Kita perlu berbincang.
MM: - Saya tidak berniat. Sesuatu dengan Zabbix lagi?
MCH: - Tidak, berehat! Saya hanya ingin berkata: semuanya berfungsi, terima kasih! Saya ada bir.
Zabbix adalah cekap
Zabbix adalah sistem dan fungsi yang agak universal dan kaya. Ia boleh digunakan untuk pemasangan kecil di luar kotak, tetapi apabila keperluan berkembang, ia perlu dioptimumkan. Untuk menyimpan arkib metrik yang besar, gunakan storan yang sesuai:
- anda boleh menggunakan alat terbina dalam dalam bentuk penyepaduan dengan Elasticsearch atau memuat naik sejarah ke fail teks (tersedia dari versi XNUMX);
- Anda boleh memanfaatkan pengalaman dan penyepaduan kami dengan Clickhouse.
Untuk meningkatkan kelajuan pengumpulan metrik secara mendadak, kumpulkannya menggunakan kaedah tak segerak dan hantarkannya melalui antara muka penjebak ke pelayan Zabbix; atau anda boleh menggunakan tampalan untuk menjadikan peninjau Zabbix tidak segerak.
Zabbix ditulis dalam C dan agak cekap. Menyelesaikan beberapa kesesakan seni bina membolehkan anda meningkatkan lagi prestasinya dan, mengikut pengalaman kami, memperoleh lebih daripada 100 ribu metrik pada mesin pemproses tunggal.
Tampalan Zabbix yang sama
MM: – Saya mahu menambah beberapa mata. Keseluruhan laporan semasa, semua ujian, nombor diberikan untuk konfigurasi yang kami gunakan. Kami kini mengambil kira-kira 20 ribu metrik sesaat daripadanya. Jika anda cuba memahami sama ada ini sesuai untuk anda, anda boleh membandingkan. Apa yang dibincangkan hari ini disiarkan di GitHub dalam bentuk tampung:
Tampalan termasuk:
- integrasi penuh dengan Clickhouse (kedua-dua pelayan Zabbix dan bahagian hadapan);
- menyelesaikan masalah dengan pengurus prapemproses;
- pengundian tak segerak.
Patch ini serasi dengan semua versi 4, termasuk lts. Kemungkinan besar, dengan perubahan yang minimum ia akan berfungsi pada versi 3.4.
Terima kasih atas perhatian anda.
soalan
Soalan daripada hadirin (selepas ini – A): – Selamat tengah hari! Sila beritahu saya, adakah anda mempunyai rancangan untuk interaksi intensif dengan pasukan Zabbix atau dengan mereka dengan anda, supaya ini bukan tampalan, tetapi tingkah laku biasa Zabbix?
MM: – Ya, kami pasti akan melakukan beberapa perubahan. Sesuatu akan berlaku, sesuatu akan kekal dalam tampalan.
J: – Terima kasih banyak atas laporan yang sangat baik! Sila beritahu saya, selepas menggunakan tampalan, sokongan daripada Zabbix akan kekal dan bagaimana untuk terus mengemas kini kepada versi yang lebih tinggi? Adakah mungkin untuk mengemas kini Zabbix selepas tampalan anda kepada 4.2, 5.0?
MM: - Saya tidak boleh mengatakan apa-apa tentang sokongan. Jika saya adalah sokongan teknikal Zabbix, saya mungkin akan mengatakan tidak, kerana ini adalah kod orang lain. Bagi pangkalan kod 4.2, kedudukan kami ialah: "Kami akan bergerak mengikut masa, dan kami akan mengemas kini diri kami pada versi seterusnya." Oleh itu, untuk beberapa lama kami akan menyiarkan tampalan untuk versi yang dikemas kini. Saya sudah berkata dalam laporan itu: bilangan perubahan dengan versi masih agak kecil. Saya rasa peralihan daripada 3.4 kepada 4 mengambil masa kira-kira 15 minit. Sesuatu telah berubah di sana, tetapi tidak begitu penting.
J: – Jadi anda bercadang untuk menyokong tampung anda dan anda boleh memasangnya dengan selamat dalam pengeluaran dan menerima kemas kini dalam beberapa cara pada masa hadapan?
MM: – Kami amat mengesyorkannya. Ini menyelesaikan banyak masalah untuk kami.
MCH: – Sekali lagi, saya ingin menarik perhatian kepada fakta bahawa perubahan yang tidak melibatkan seni bina dan tidak melibatkan penyekatan atau baris gilir adalah modular, ia berada dalam modul berasingan. Walaupun dengan perubahan kecil anda boleh mengekalkannya dengan mudah.
MM: – Jika anda berminat dengan butirannya, maka “Clickhouse” menggunakan perpustakaan sejarah yang dipanggil. Ia tidak diikat - ia adalah salinan sokongan Elastics, iaitu, ia boleh dikonfigurasikan. Pengundian hanya menukar pengundi. Kami percaya ini akan berkesan untuk masa yang lama.
J: - Terima kasih banyak-banyak. Beritahu saya, adakah terdapat sebarang dokumentasi perubahan yang dibuat?
MM: – Dokumentasi adalah tampalan. Jelas sekali, dengan pengenalan Clickhouse, dengan pengenalan jenis tinjauan pendapat baharu, pilihan konfigurasi baharu timbul. Pautan dari slaid terakhir mempunyai penerangan ringkas tentang cara menggunakannya.
Mengenai menggantikan fping dengan nmap
J: – Bagaimanakah anda akhirnya melaksanakan ini? Bolehkah anda memberikan contoh khusus: adakah anda mempunyai tali pengikat dan skrip luaran? Apa yang akhirnya menyemak sebilangan besar hos dengan begitu cepat? Bagaimanakah anda melombong hos ini? Adakah kita perlu memberi mereka makan untuk nmap entah bagaimana, bawa mereka dari suatu tempat, letakkan mereka, jalankan sesuatu?..
MM: - Sejuk. Soalan yang sangat betul! Intinya adalah ini. Kami mengubah suai perpustakaan (ping ICMP, sebahagian daripada Zabbix) untuk semakan ICMP, yang menunjukkan bilangan paket - satu (1), dan kod itu cuba menggunakan nmap. Iaitu, ini adalah kerja dalaman Zabbix, yang telah menjadi kerja dalaman pinger. Sehubungan itu, tiada penyegerakan atau penggunaan perangkap diperlukan. Ini dilakukan dengan sengaja untuk membiarkan sistem utuh dan tidak perlu berurusan dengan penyegerakan dua sistem pangkalan data: apa yang perlu diperiksa, muat naik melalui tinjauan pendapat, dan adakah muat naik kami rosak?.. Ini lebih mudah.
J: – Adakah ia berfungsi untuk proksi juga?
MM: - Ya, tetapi kami tidak menyemak. Kod pengundian adalah sama dalam kedua-dua Zabbix dan pelayan. Harus bekerja. Biar saya tekankan sekali lagi: prestasi sistem sedemikian rupa sehingga kita tidak memerlukan proksi.
MCH: – Jawapan yang betul untuk soalan itu ialah: “Mengapa anda memerlukan proksi dengan sistem sedemikian?” Hanya kerana NAT atau pemantauan melalui saluran perlahan...
J: – Dan anda menggunakan Zabbix sebagai alertor, jika saya faham dengan betul. Atau adakah grafik anda (di mana lapisan arkib berada) dialihkan ke sistem lain, seperti Grafana? Atau adakah anda tidak menggunakan fungsi ini?
MM: – Saya akan menekankan sekali lagi: kita telah mencapai integrasi lengkap. Kami mencurahkan sejarah ke Clickhouse, tetapi pada masa yang sama kami telah menukar bahagian hadapan php. Bahagian hadapan Php pergi ke Clickhouse dan melakukan semua grafik dari sana. Pada masa yang sama, sejujurnya, kami mempunyai bahagian yang membina data dalam sistem paparan grafik lain daripada Clickhouse yang sama, daripada data Zabbix yang sama.
MCH: - Dalam "Grafan" juga.
Bagaimanakah keputusan dibuat tentang peruntukan sumber?
J: – Kongsi sedikit dapur dalaman anda. Bagaimanakah keputusan dibuat bahawa adalah perlu untuk memperuntukkan sumber untuk pemprosesan serius produk? Ini, secara amnya, risiko tertentu. Dan sila beritahu saya, dalam konteks fakta bahawa anda akan menyokong versi baharu: bagaimanakah keputusan ini mewajarkan dari sudut pandangan pengurusan?
MM: - Nampaknya, kami tidak menceritakan drama sejarah dengan baik. Kami mendapati diri kami berada dalam situasi di mana sesuatu perlu dilakukan, dan kami pada dasarnya pergi dengan dua pasukan selari:
- Satu melancarkan sistem pemantauan menggunakan kaedah baharu: pemantauan sebagai perkhidmatan, set standard penyelesaian sumber terbuka yang kami gabungkan dan kemudian cuba mengubah proses perniagaan untuk berfungsi dengan sistem pemantauan baharu.
- Pada masa yang sama, kami mempunyai pengaturcara yang bersemangat yang melakukan ini (tentang dirinya). Kebetulan dia menang.
J: – Dan apakah saiz pasukan?
MCH: - Dia ada di hadapan awak.
J: – Jadi, seperti biasa, anda memerlukan seorang yang bersemangat?
MM: - Saya tidak tahu apa itu ghairah.
J: - Dalam kes ini, nampaknya, anda. Terima kasih banyak, anda hebat.
MM: - Terima kasih.
Mengenai patch untuk Zabbix
J: – Untuk sistem yang menggunakan proksi (contohnya, dalam beberapa sistem yang diedarkan), adakah mungkin untuk menyesuaikan dan menampal, katakan, peninjau, proksi dan sebahagiannya prapemproses Zabbix itu sendiri; dan interaksi mereka? Adakah mungkin untuk mengoptimumkan perkembangan sedia ada untuk sistem dengan berbilang proksi?
MM: – Saya tahu bahawa pelayan Zabbix dipasang menggunakan proksi (kod itu disusun dan diperolehi). Kami belum menguji ini dalam pengeluaran. Saya tidak pasti tentang perkara ini, tetapi saya fikir pengurus prapemproses tidak digunakan dalam proksi. Tugas proksi adalah untuk mengambil satu set metrik daripada Zabbix, menggabungkannya (ia juga merekodkan konfigurasi, pangkalan data tempatan) dan memberikannya semula kepada pelayan Zabbix. Pelayan itu sendiri kemudiannya akan melakukan prapemprosesan apabila ia menerimanya.
Minat terhadap proksi boleh difahami. Kami akan menyemaknya. Ini adalah topik yang menarik.
J: – Ideanya ialah ini: jika anda boleh menampal pemungut pendapat, anda boleh menampalnya pada proksi dan menampal interaksi dengan pelayan, dan menyesuaikan prapemproses untuk tujuan ini hanya pada pelayan.
MM: - Saya rasa ia lebih mudah. Anda mengambil kod itu, menggunakan tampalan, kemudian mengkonfigurasinya mengikut cara yang anda perlukan - kumpulkan pelayan proksi (contohnya, dengan ODBC) dan edarkan kod yang ditambal merentas sistem. Jika perlu - kumpulkan proksi, jika perlu - pelayan.
J: – Kemungkinan besar, anda tidak perlu menampal penghantaran proksi ke pelayan tambahan?
MCH: - Tidak, ia standard.
MM: – Malah, salah satu idea tidak berbunyi. Kami sentiasa mengekalkan keseimbangan antara ledakan idea dan jumlah perubahan dan kemudahan sokongan.
Beberapa iklan 🙂
Terima kasih kerana tinggal bersama kami. Adakah anda suka artikel kami? Ingin melihat kandungan yang lebih menarik? Sokong kami dengan membuat pesanan atau mengesyorkan kepada rakan, , analog unik pelayan peringkat permulaan, yang kami cipta untuk anda: (tersedia dengan RAID1 dan RAID10, sehingga 24 teras dan sehingga 40GB DDR4).
Dell R730xd 2 kali 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 - daripada $99! Baca tentang
Sumber: www.habr.com