Zabbix ialah sistem pemantauan. Seperti mana-mana sistem lain, ia menghadapi tiga masalah utama semua sistem pemantauan: mengumpul dan memproses data, menyimpan sejarah dan membersihkannya.
Peringkat menerima, memproses dan merekod data mengambil masa. Tidak banyak, tetapi untuk sistem yang besar ini boleh mengakibatkan kelewatan yang besar. Masalah storan ialah isu akses data. Ia digunakan untuk laporan, semakan dan pencetus. Kependaman dalam akses data juga memberi kesan kepada prestasi. Apabila pangkalan data berkembang, data yang tidak berkaitan perlu dipadamkan. Mengalih keluar ialah operasi sukar yang turut memakan beberapa sumber.
Masalah kelewatan semasa pengumpulan dan penyimpanan dalam Zabbix diselesaikan dengan caching: beberapa jenis cache, caching dalam pangkalan data. Untuk menyelesaikan masalah ketiga, caching tidak sesuai, jadi Zabbix menggunakan TimescaleDB. Dia akan memberitahu anda mengenainya Andrey Gushchin - jurutera sokongan teknikal . Andrey telah menyokong Zabbix selama lebih daripada 6 tahun dan mempunyai pengalaman langsung dengan prestasi.
Bagaimanakah TimescaleDB berfungsi, apakah prestasi yang boleh diberikan berbanding PostgreSQL biasa? Apakah peranan yang dimainkan oleh Zabbix untuk pangkalan data TimescaleDB? Bagaimana untuk bermula dari awal dan bagaimana untuk berhijrah dari PostgreSQL dan konfigurasi manakah yang mempunyai prestasi yang lebih baik? Mengenai semua ini di bawah potongan.
Cabaran Produktiviti
Setiap sistem pemantauan menghadapi cabaran prestasi tertentu. Saya akan bercakap tentang tiga daripadanya: pengumpulan dan pemprosesan data, penyimpanan dan pembersihan sejarah.
Pengumpulan dan pemprosesan data yang cepat. Sistem pemantauan yang baik harus cepat menerima semua data dan memprosesnya mengikut ungkapan pencetus - mengikut kriterianya. Selepas pemprosesan, sistem juga mesti cepat menyimpan data ini dalam pangkalan data untuk kegunaan kemudian.
Penyimpanan sejarah. Sistem pemantauan yang baik harus menyimpan sejarah dalam pangkalan data dan menyediakan akses mudah kepada metrik. Sejarah diperlukan untuk digunakan dalam laporan, graf, pencetus, ambang dan item data makluman yang dikira.
Mengosongkan sejarah. Kadangkala tiba hari apabila anda tidak perlu menyimpan metrik. Mengapa anda memerlukan data yang dikumpul 5 tahun lalu, sebulan atau dua: beberapa nod telah dipadamkan, beberapa hos atau metrik tidak lagi diperlukan kerana ia sudah lapuk dan tidak lagi dikumpulkan. Sistem pemantauan yang baik harus menyimpan data sejarah dan memadamnya dari semasa ke semasa supaya pangkalan data tidak berkembang.
Membersihkan data basi ialah isu kritikal yang memberi kesan besar kepada prestasi pangkalan data.
Caching dalam Zabbix
Dalam Zabbix, panggilan pertama dan kedua diselesaikan menggunakan caching. RAM digunakan untuk mengumpul dan memproses data. Untuk storan - sejarah dalam pencetus, graf dan elemen data yang dikira. Di bahagian pangkalan data terdapat beberapa caching untuk pilihan asas, sebagai contoh, graf.
Caching di sisi pelayan Zabbix itu sendiri ialah:
- ConfigurationCache;
- ValueCache;
- HistoryCache;
- TrendsCache.
Pertimbangkan mereka dengan lebih terperinci.
ConfigurationCache
Ini ialah cache utama tempat kami menyimpan metrik, hos, item data, pencetus - semua yang kami perlukan untuk PraPemprosesan dan pengumpulan data.
Semua ini disimpan dalam ConfigurationCache supaya tidak membuat pertanyaan yang tidak perlu dalam pangkalan data. Selepas pelayan bermula, kami mengemas kini cache ini, mencipta dan mengemas kini konfigurasi secara berkala.
Pengumpulan data
Gambar rajah itu agak besar, tetapi perkara utama di dalamnya adalah pemetik. Ini adalah pelbagai "pollers" - proses pemasangan. Mereka bertanggungjawab untuk pelbagai jenis pemasangan: mereka mengumpul data melalui SNMP, IPMI, dan memindahkan semuanya ke PreProcessing.
Pengumpul digariskan dalam oren.
Zabbix telah mengira item pengagregatan yang diperlukan untuk mengagregatkan cek. Jika kami mempunyainya, kami mengambil data untuknya terus daripada ValueCache.
PreProcessing HistoryCache
Semua pengumpul menggunakan ConfigurationCache untuk menerima kerja. Kemudian mereka memindahkannya ke PreProcessing.
PreProcessing menggunakan ConfigurationCache untuk menerima langkah PreProcessing. Ia memproses data ini dalam pelbagai cara.
Selepas memproses data menggunakan PreProcessing, kami menyimpannya dalam HistoryCache untuk diproses. Ini menamatkan pengumpulan data dan kami beralih ke proses utama dalam Zabbix - penyegerak sejarah, kerana ia adalah seni bina monolitik.
Nota: PraPemprosesan adalah operasi yang agak sukar. Dengan v 4.2 ia telah dipindahkan ke proksi. Jika anda mempunyai Zabbix yang sangat besar dengan sejumlah besar elemen data dan kekerapan pengumpulan, maka ini menjadikan kerja lebih mudah.
ValueCache, sejarah & trend cache
Penyegerak sejarah ialah proses utama yang memproses setiap elemen data secara atom, iaitu setiap nilai.
Penyegerak sejarah mengambil nilai daripada HistoryCache dan menyemak Konfigurasi untuk kehadiran pencetus untuk pengiraan. Jika mereka wujud, ia mengira.
Penyegerak sejarah mencipta acara, peningkatan untuk membuat makluman jika diperlukan mengikut konfigurasi dan rekod. Jika terdapat pencetus untuk pemprosesan seterusnya, maka ia menyimpan nilai ini dalam ValueCache supaya tidak mengakses jadual sejarah. Beginilah cara ValueCache diisi dengan data yang diperlukan untuk mengira pencetus dan elemen yang dikira.
Penyegerak sejarah menulis semua data ke pangkalan data, dan ia menulis ke cakera. Proses pemprosesan berakhir di sini.
Caching dalam pangkalan data
Di bahagian pangkalan data terdapat pelbagai cache apabila anda ingin melihat graf atau laporan tentang peristiwa:
Innodb_buffer_pooldi sisi MySQL;shared_buffersdi sebelah PostgreSQL;effective_cache_sizedi sebelah Oracle;shared_pooldi bahagian DB2.
Terdapat banyak cache lain, tetapi ini adalah yang utama untuk semua pangkalan data. Mereka membenarkan anda menyimpan data dalam RAM yang sering diperlukan untuk pertanyaan. Mereka mempunyai teknologi mereka sendiri untuk ini.
Prestasi pangkalan data adalah kritikal
Pelayan Zabbix sentiasa mengumpul data dan menulisnya. Apabila dimulakan semula, ia juga membaca dari sejarah untuk mengisi ValueCache. Menggunakan skrip dan laporan API Zabbix, yang dibina pada antara muka Web. Zabbix API mengakses pangkalan data dan mendapatkan semula data yang diperlukan untuk graf, laporan, senarai acara dan isu terkini.
Untuk visualisasi - grafana. Ini adalah penyelesaian yang popular di kalangan pengguna kami. Ia boleh menghantar permintaan terus melalui API Zabbix dan ke pangkalan data, dan mewujudkan persaingan tertentu untuk menerima data. Oleh itu, penalaan pangkalan data yang lebih halus dan lebih baik diperlukan untuk memadankan penyampaian keputusan dan ujian yang pantas.
Rumah tangga
Cabaran prestasi ketiga dalam Zabbix ialah pembersihan sejarah menggunakan Housekeeper. Ia mengikut semua tetapan - elemen data menunjukkan berapa lama untuk menyimpan dinamik perubahan (trend) dalam beberapa hari.
Kami mengira TrendsCache dengan cepat. Apabila data tiba, kami mengagregatkannya selama satu jam dan merekodkannya dalam jadual untuk dinamik perubahan arah aliran.
Housekeeper memulakan dan memadam maklumat daripada pangkalan data menggunakan "pilihan" biasa. Ini tidak selalu berkesan, seperti yang boleh dilihat daripada graf prestasi proses dalaman.
Graf merah menunjukkan bahawa penyegerak Sejarah sentiasa sibuk. Graf oren di bahagian atas ialah Housekeeper, yang sentiasa berjalan. Dia menunggu pangkalan data memadam semua baris yang dia nyatakan.
Bilakah anda perlu melumpuhkan Housekeeper? Sebagai contoh, terdapat "ID Item" dan anda perlu memadam 5 ribu baris terakhir dalam masa tertentu. Sudah tentu, ini berlaku dengan indeks. Tetapi biasanya dataset adalah sangat besar, dan pangkalan data masih membaca dari cakera dan memasukkannya ke dalam cache. Ini sentiasa merupakan operasi yang sangat mahal untuk pangkalan data dan, bergantung pada saiz pangkalan data, boleh membawa kepada masalah prestasi.
Penjaga rumah mudah dilumpuhkan. Dalam antara muka Web terdapat tetapan dalam "Pentadbiran am" untuk Housekeeper. Kami melumpuhkan Pengemasan dalaman untuk sejarah aliran dalaman dan ia tidak lagi mengurusnya.
Penjaga rumah telah dimatikan, graf diratakan - apakah masalah yang mungkin berlaku dalam kes ini dan apakah yang boleh membantu menyelesaikan cabaran prestasi ketiga?
Pembahagian - pembahagian atau pembahagian
Biasanya, pembahagian dikonfigurasikan dengan cara yang berbeza pada setiap pangkalan data hubungan yang telah saya senaraikan. Masing-masing mempunyai teknologi sendiri, tetapi mereka serupa secara umum. Mencipta partition baru selalunya membawa kepada masalah tertentu.
Biasanya, partition dikonfigurasikan bergantung pada "persediaan" - jumlah data yang dibuat dalam satu hari. Sebagai peraturan, Pembahagian dikeluarkan dalam satu hari, ini adalah minimum. Untuk trend kumpulan baru - 1 bulan.
Nilai mungkin berubah jika "persediaan" sangat besar. Jika "persediaan" kecil adalah sehingga 5 nvps (nilai baharu sesaat), yang sederhana adalah dari 000 hingga 5, maka yang besar melebihi 000 nvps. Ini adalah pemasangan yang besar dan sangat besar yang memerlukan konfigurasi pangkalan data yang teliti.
Pada pemasangan yang sangat besar, tempoh satu hari mungkin tidak optimum. Saya telah melihat partition MySQL sebanyak 40 GB atau lebih setiap hari. Ini adalah jumlah data yang sangat besar yang boleh menyebabkan masalah dan perlu dikurangkan.
Apa yang diberikan oleh Pembahagian?
Meja pembahagian. Selalunya ini adalah fail berasingan pada cakera. Pelan pertanyaan memilih satu partition dengan lebih optimum. Biasanya pembahagian digunakan mengikut julat - ini juga berlaku untuk Zabbix. Kami menggunakan "cap masa" di sana - masa sejak permulaan era. Ini adalah nombor biasa bagi kami. Anda menetapkan permulaan dan penghujung hari - ini ialah partition.
Penyingkiran cepat - DELETE. Satu fail/subjadual dipilih, bukannya pilihan baris untuk dipadamkan.
Mempercepatkan pengambilan data dengan ketara SELECT - menggunakan satu atau lebih partition, bukannya keseluruhan jadual. Jika anda mengakses data yang berusia dua hari, ia diambil daripada pangkalan data dengan lebih cepat kerana anda hanya perlu memuatkan satu fail ke dalam cache dan mengembalikannya, bukan jadual besar.
Selalunya banyak pangkalan data juga dipercepatkan INSERT — sisipan ke dalam jadual kanak-kanak.
TimescaleDB
Untuk v 4.2, kami menumpukan perhatian kami kepada TimescaleDB. Ini adalah lanjutan untuk PostgreSQL dengan antara muka asli. Sambungan berfungsi dengan berkesan dengan data siri masa, tanpa kehilangan faedah pangkalan data hubungan. TimescaleDB juga membahagi secara automatik.
TimescaleDB mempunyai konsep hipertable (hypertable) yang anda buat. Ia mengandungi ketulan - sekatan. Potongan diuruskan secara automatik serpihan hipertable yang tidak menjejaskan serpihan lain. Setiap bahagian mempunyai julat masa sendiri.
TimescaleDB lwn PostgreSQL
TimescaleDB berfungsi dengan sangat cekap. Pengeluar sambungan mendakwa bahawa mereka menggunakan algoritma pemprosesan permintaan yang lebih betul, khususnya, sisipan. Apabila saiz sisipan set data bertambah, algoritma mengekalkan prestasi yang berterusan.
Selepas 200 juta baris, PostgreSQL biasanya mula merosot dengan ketara dan kehilangan prestasi kepada 0. TimescaleDB membolehkan anda memasukkan "sisipan" dengan cekap untuk sebarang jumlah data.
Pemasangan
Memasang TimescaleDB agak mudah untuk mana-mana pakej. DALAM semuanya diterangkan secara terperinci - ia bergantung pada pakej PostgreSQL rasmi. TimescaleDB juga boleh dibina dan disusun secara manual.
Untuk pangkalan data Zabbix, kami hanya mengaktifkan sambungan:
echo "CREATE EXTENSION IF NOT EXISTS timescaledb CASCADE;" | sudo -u postgres psql zabbix
Anda aktifkan extension dan buatnya untuk pangkalan data Zabbix. Langkah terakhir ialah membuat jadual hiper.
Memindahkan jadual sejarah ke TimescaleDB
Terdapat fungsi khas untuk ini create_hypertable:
SELECT create_hypertable(‘history’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘history_unit’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘history_log’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘history_text’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘history_str’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘trends’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘trends_unit’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
UPDATE config SET db_extension=’timescaledb’, hk_history_global=1, hk_trends_global=1
Fungsi ini mempunyai tiga parameter. pertama - jadual dalam pangkalan data, yang mana anda perlu membuat jadual hiper. Kedua - bidang, mengikut mana anda perlu buat chunk_time_interval — selang ketulan partition yang akan digunakan. Dalam kes saya, selang satu hari - 86.
Parameter ketiga - migrate_data. Jika anda menetapkan true, maka semua data semasa dipindahkan ke ketulan yang telah dibuat sebelumnya. Saya sendiri menggunakannya migrate_data. Saya mempunyai kira-kira 1 TB, yang mengambil masa lebih sejam. Walaupun dalam beberapa kes, semasa ujian, saya memadamkan data sejarah jenis aksara yang tidak diperlukan untuk penyimpanan, supaya tidak memindahkannya.
Langkah terakhir - UPDATE: pada db_extension letak timescaledbsupaya pangkalan data memahami bahawa sambungan ini wujud. Zabbix mengaktifkannya dan menggunakan sintaks dan pertanyaan dengan betul kepada pangkalan data - ciri-ciri yang diperlukan untuk TimescaleDB.
Konfigurasi perkakasan
Saya menggunakan dua pelayan. pertama - mesin VMware. Ia agak kecil: 20 Intel® Xeon® CPU E5-2630 v 4 @ 2.20GHz pemproses, 16 GB RAM dan 200 GB SSD.
Saya memasang PostgreSQL 10.8 padanya dengan sistem fail Debian 10.8-1.pgdg90+1 OS dan xfs. Saya mengkonfigurasi segala-galanya secara minimum untuk menggunakan pangkalan data khusus ini, tolak apa yang Zabbix sendiri akan gunakan.
Pada mesin yang sama terdapat pelayan Zabbix, PostgreSQL dan ejen muatan. Saya mempunyai 50 ejen aktif yang menggunakan LoadableModuleuntuk menjana hasil yang berbeza dengan cepat: nombor, rentetan. Saya mengisi pangkalan data dengan banyak data.
Pada mulanya konfigurasi terkandung 5 elemen data setiap hos. Hampir setiap elemen mengandungi pencetus untuk menjadikannya serupa dengan pemasangan sebenar. Dalam sesetengah kes terdapat lebih daripada satu pencetus. Untuk satu nod rangkaian terdapat 3-000 pencetus.
Selang Kemas Kini Item Data − 4-7 saat. Saya mengawal beban itu sendiri dengan menggunakan bukan sahaja 50 ejen, tetapi menambah lagi. Selain itu, menggunakan elemen data, saya melaraskan beban secara dinamik dan mengurangkan selang kemas kini kepada 4 s.
PostgreSQL. 35 nvps
Larian pertama saya pada perkakasan ini adalah pada PostgreSQL tulen - 35 ribu nilai sesaat. Seperti yang anda lihat, memasukkan data mengambil masa sesaat - semuanya baik dan pantas. Satu-satunya perkara ialah cakera SSD 200 GB diisi dengan cepat.
Ini ialah papan pemuka prestasi pelayan Zabbix standard.
Graf biru pertama ialah bilangan nilai sesaat. Graf kedua di sebelah kanan ialah memuatkan proses binaan. Yang ketiga ialah memuatkan proses binaan dalaman: penyegerak sejarah dan Housekeeper, yang telah berjalan di sini untuk sekian lama.
Graf keempat menunjukkan penggunaan HistoryCache. Ini adalah sejenis penimbal sebelum dimasukkan ke dalam pangkalan data. Graf kelima hijau menunjukkan penggunaan ValueCache, iaitu, bilangan hits ValueCache untuk pencetus - ini adalah beberapa ribu nilai sesaat.
PostgreSQL. 50 nvps
Kemudian saya meningkatkan beban kepada 50 ribu nilai sesaat pada perkakasan yang sama.
Apabila memuatkan dari Housekeeper, memasukkan 10 ribu nilai mengambil masa 2-3 saat.
Penjaga rumah sudah mula mengganggu kerja.
Graf ketiga menunjukkan bahawa, secara amnya, beban pada perangkap dan penyegerak sejarah masih pada 60%. Dalam graf keempat, HistoryCache sudah mula diisi dengan agak aktif semasa operasi Housekeeper. Ia 20% penuh, iaitu kira-kira 0,5 GB.
PostgreSQL. 80 nvps
Kemudian saya meningkatkan beban kepada 80 ribu nilai sesaat. Ini adalah kira-kira 400 ribu elemen data dan 280 ribu pencetus.
Kos memuatkan tiga puluh penyegerak sejarah sudah agak tinggi.
Saya juga meningkatkan pelbagai parameter: penyegerak sejarah, cache.
Pada perkakasan saya, pemuatan penyegerak sejarah meningkat kepada maksimum. HistoryCache cepat diisi dengan data - data untuk pemprosesan telah terkumpul dalam penimbal.
Selama ini saya memerhatikan bagaimana pemproses, RAM dan parameter sistem lain digunakan, dan mendapati penggunaan cakera berada pada tahap maksimum.
Saya telah mencapai penggunaan keupayaan cakera maksimum pada perkakasan ini dan pada mesin maya ini. Dengan intensiti sedemikian, PostgreSQL mula mengepam data dengan agak aktif, dan cakera tidak lagi mempunyai masa untuk menulis dan membaca.
Pelayan kedua
Saya mengambil pelayan lain, yang sudah mempunyai 48 pemproses dan 128 GB RAM. Saya menalanya - menetapkannya kepada 60 penyegerak sejarah, dan mencapai prestasi yang boleh diterima.
Sebenarnya, ini sudah menjadi had produktiviti di mana sesuatu perlu dilakukan.
TimescaleDB. 80 nvps
Tugas utama saya adalah untuk menguji keupayaan TimescaleDB terhadap beban Zabbix. 80 ribu nilai sesaat adalah banyak, kekerapan mengumpul metrik (kecuali untuk Yandex, sudah tentu) dan "persediaan" yang agak besar.
Terdapat penurunan dalam setiap graf - ini adalah tepatnya penghijrahan data. Selepas kegagalan dalam pelayan Zabbix, profil pemuatan penyegerak sejarah banyak berubah - ia jatuh tiga kali.
TimescaleDB membolehkan anda memasukkan data hampir 3 kali lebih pantas dan menggunakan lebih sedikit HistoryCache.
Sehubungan itu, anda akan menerima data tepat pada masanya.
TimescaleDB. 120 nvps
Kemudian saya meningkatkan bilangan elemen data kepada 500 ribu. Tugas utama adalah untuk menguji keupayaan TimescaleDB - Saya menerima nilai yang dikira sebanyak 125 ribu nilai sesaat.
Ini ialah "persediaan" yang berfungsi yang boleh berfungsi untuk masa yang lama. Tetapi kerana cakera saya hanya 1,5 TB, saya mengisinya dalam beberapa hari.
Perkara yang paling penting ialah pada masa yang sama partition TimescaleDB baharu dicipta.
Ini sama sekali tidak dapat dilihat untuk prestasi. Apabila partition dibuat dalam MySQL, sebagai contoh, semuanya berbeza. Ini biasanya berlaku pada waktu malam kerana ia menyekat sisipan umum, berfungsi dengan jadual dan boleh membuat kemerosotan perkhidmatan. Ini tidak berlaku dengan TimescaleDB.
Sebagai contoh, saya akan menunjukkan satu graf daripada banyak dalam komuniti. Dalam gambar, TimescaleDB didayakan, berkat penggunaan io.weight pada pemproses telah menurun. Penggunaan elemen proses dalaman juga berkurangan. Selain itu, ini adalah mesin maya biasa pada cakera lempeng biasa, bukan SSD.
Penemuan
TimescaleDB ialah penyelesaian yang baik untuk "persediaan" kecil, yang memberi kesan kepada prestasi cakera. Ia akan membolehkan anda terus bekerja dengan baik sehingga pangkalan data dipindahkan ke perkakasan secepat mungkin.
TimescaleDB mudah dikonfigurasikan, memberikan peningkatan prestasi, berfungsi dengan baik dengan Zabbix dan mempunyai kelebihan berbanding PostgreSQL.
Jika anda menggunakan PostgreSQL dan tidak bercadang untuk mengubahnya, saya cadangkan gunakan PostgreSQL dengan sambungan TimescaleDB bersama dengan Zabbix. Penyelesaian ini berfungsi dengan berkesan sehingga "persediaan" sederhana.
Apabila kami menyebut "prestasi tinggi" yang kami maksudkan . Anda tidak perlu menunggu lama untuk mengetahui tentang teknologi dan amalan yang membolehkan perkhidmatan memberi perkhidmatan kepada berjuta-juta pengguna. Senaraikan untuk 7 dan 8 November kami telah pun menyusun, tetapi di sini lebih banyak boleh dicadangkan.
Langgan kami и , di mana kami mendedahkan ciri persidangan yang akan datang, dan mengetahui cara untuk memanfaatkannya sepenuhnya.
Sumber: www.habr.com