Kami akan melihat bagaimana Zabbix berfungsi dengan pangkalan data TimescaleDB sebagai bahagian belakang. Kami akan menunjukkan kepada anda cara untuk bermula dari awal dan cara untuk berhijrah dari PostgreSQL. Kami juga akan menyediakan ujian prestasi perbandingan bagi kedua-dua konfigurasi.
HighLoad++ Siberia 2019. Dewan Tomsk. 24 Jun, 16:00. Tesis dan . Persidangan HighLoad++ seterusnya akan diadakan pada 6 dan 7 April 2020 di St. Petersburg. Butiran dan tiket .
Andrey Gushchin (selepas ini – AG): – Saya seorang jurutera sokongan teknikal ZABBIX (selepas ini dirujuk sebagai “Zabbix”), seorang jurulatih. Saya telah bekerja dalam sokongan teknikal selama lebih daripada 6 tahun dan mempunyai pengalaman langsung dengan prestasi. Hari ini saya akan bercakap tentang prestasi yang TimescaleDB boleh berikan jika dibandingkan dengan PostgreSQL 10 biasa. Selain itu, beberapa bahagian pengenalan tentang cara ia berfungsi secara umum.
Cabaran produktiviti teratas: daripada pengumpulan data kepada pembersihan data
Sebagai permulaan, terdapat cabaran prestasi tertentu yang dihadapi oleh setiap sistem pemantauan. Cabaran produktiviti pertama ialah mengumpul dan memproses data dengan cepat.
Sistem pemantauan yang baik harus cepat, tepat pada masanya menerima semua data, memprosesnya mengikut ungkapan pencetus, iaitu, memprosesnya mengikut beberapa kriteria (ini berbeza dalam sistem yang berbeza) dan menyimpannya dalam pangkalan data untuk menggunakan data ini dalam masa hadapan.
Cabaran prestasi kedua ialah penyimpanan sejarah. Simpan dalam pangkalan data dengan kerap dan dapatkan akses cepat dan mudah kepada metrik ini yang dikumpulkan dalam tempoh masa tertentu. Perkara yang paling penting ialah data ini mudah diperoleh, menggunakannya dalam laporan, graf, pencetus, dalam beberapa nilai ambang, untuk makluman, dsb.
Cabaran prestasi ketiga ialah pembersihan sejarah, iaitu apabila anda sampai ke tahap di mana anda tidak perlu menyimpan sebarang metrik terperinci yang telah dikumpulkan selama 5 tahun (walaupun bulan atau dua bulan). Sesetengah nod rangkaian telah dipadamkan, atau sesetengah hos, metrik tidak lagi diperlukan kerana ia sudah lapuk dan tidak lagi dikumpulkan. Semua ini perlu dibersihkan supaya pangkalan data anda tidak berkembang terlalu besar. Secara umum, sejarah pembersihan selalunya merupakan ujian yang serius untuk storan - selalunya ia mempunyai kesan yang sangat kuat terhadap prestasi.
Bagaimana untuk menyelesaikan masalah caching?
Saya sekarang akan bercakap secara khusus tentang Zabbix. Dalam Zabbix, panggilan pertama dan kedua diselesaikan menggunakan caching.
Pengumpulan dan pemprosesan data - Kami menggunakan RAM untuk menyimpan semua data ini. Data ini kini akan dibincangkan dengan lebih terperinci.
Juga di bahagian pangkalan data terdapat beberapa caching untuk pilihan utama - untuk graf dan perkara lain.
Caching pada sisi pelayan Zabbix itu sendiri: kami mempunyai ConfigurationCache, ValueCache, HistoryCache, TrendsCache. Apa ini?
ConfigurationCache ialah cache utama tempat kami menyimpan metrik, hos, item data, pencetus; semua yang anda perlukan untuk memproses prapemprosesan, mengumpul data, daripada hos mana untuk dikumpulkan, dengan kekerapan yang mana. Semua ini disimpan dalam ConfigurationCache supaya tidak pergi ke pangkalan data dan membuat pertanyaan yang tidak perlu. Selepas pelayan bermula, kami mengemas kini cache ini (menciptanya) dan mengemas kininya secara berkala (bergantung pada tetapan konfigurasi).
Caching dalam Zabbix. Pengumpulan data
Di sini rajahnya agak besar:
Yang utama dalam skim ini ialah pengumpul ini:
Ini adalah proses perhimpunan itu sendiri, pelbagai "pemilih" yang bertanggungjawab untuk pelbagai jenis perhimpunan. Mereka mengumpul data melalui icmp, ipmi, dan pelbagai protokol dan memindahkan semuanya ke prapemprosesan.
PreProcessing HistoryCache
Selain itu, jika kami telah mengira elemen data (mereka yang biasa dengan Zabbix tahu), iaitu, mengira, elemen data pengagregatan, kami mengambilnya terus daripada ValueCache. Saya akan memberitahu anda bagaimana ia diisi kemudian. Semua pengumpul ini menggunakan ConfigurationCache untuk menerima pekerjaan mereka dan kemudian meneruskannya ke prapemprosesan.
Prapemprosesan juga menggunakan ConfigurationCache untuk mendapatkan langkah prapemprosesan dan memproses data ini dalam pelbagai cara. Bermula dari versi 4.2, kami telah mengalihkannya ke proksi. Ini sangat mudah, kerana prapemprosesan itu sendiri adalah operasi yang agak sukar. Dan jika anda mempunyai Zabbix yang sangat besar, dengan sejumlah besar elemen data dan kekerapan pengumpulan yang tinggi, maka ini sangat memudahkan kerja.
Oleh itu, selepas kami memproses data ini dalam beberapa cara menggunakan prapemprosesan, kami menyimpannya dalam HistoryCache untuk memprosesnya dengan lebih lanjut. Ini menyimpulkan pengumpulan data. Kami beralih ke proses utama.
Kerja penyegerak sejarah
Proses utama dalam Zabbix (kerana ia adalah seni bina monolitik) ialah penyegerak Sejarah. Ini ialah proses utama yang berurusan secara khusus dengan pemprosesan atom setiap elemen data, iaitu setiap nilai:
- nilai datang (ia mengambilnya dari HistoryCache);
- semak dalam Penyegerak konfigurasi: sama ada terdapat sebarang pencetus untuk pengiraan - mengiranya;
jika ada - mencipta acara, mencipta peningkatan untuk mencipta amaran, jika perlu mengikut konfigurasi; - rekod pencetus untuk pemprosesan seterusnya, pengagregatan; jika anda mengagregat sepanjang jam terakhir dan seterusnya, nilai ini diingati oleh ValueCache supaya tidak pergi ke jadual sejarah; Oleh itu, ValueCache diisi dengan data yang diperlukan yang diperlukan untuk mengira pencetus, elemen yang dikira, dll.;
- kemudian Penyegerak Sejarah menulis semua data ke pangkalan data;
- pangkalan data menulisnya ke cakera - di sinilah proses pemprosesan berakhir.
Pangkalan data. Caching
Di bahagian pangkalan data, apabila anda ingin melihat graf atau beberapa laporan tentang peristiwa, terdapat pelbagai cache. Tetapi dalam laporan ini saya tidak akan bercakap tentang mereka.
Untuk MySQL terdapat Innodb_buffer_pool, dan sekumpulan cache berbeza yang juga boleh dikonfigurasikan.
Tetapi ini adalah yang utama:
- shared_buffers;
- berkesan_cache_size;
- shared_pool.
Untuk semua pangkalan data, saya mengatakan bahawa terdapat cache tertentu yang membolehkan anda menyimpan dalam RAM data yang sering diperlukan untuk pertanyaan. Mereka mempunyai teknologi mereka sendiri untuk ini.
Mengenai Prestasi Pangkalan Data
Sehubungan itu, terdapat persekitaran yang kompetitif, iaitu pelayan Zabbix mengumpul data dan merekodkannya. Apabila dimulakan semula, ia juga membaca dari sejarah untuk mengisi ValueCache dan sebagainya. Di sini anda boleh mempunyai skrip dan laporan yang menggunakan API Zabbix, yang dibina pada antara muka web. API Zabbix memasuki pangkalan data dan menerima data yang diperlukan untuk mendapatkan graf, laporan atau beberapa jenis senarai peristiwa, masalah terkini.
Juga penyelesaian visualisasi yang sangat popular ialah Grafana, yang digunakan oleh pengguna kami. Dapat log masuk terus melalui API Zabbix dan melalui pangkalan data. Ia juga mewujudkan persaingan tertentu untuk mendapatkan data: penalaan pangkalan data yang lebih halus dan lebih baik diperlukan untuk mematuhi penyampaian keputusan dan ujian yang pantas.
Mengosongkan sejarah. Zabbix mempunyai Housekeeper
Panggilan ketiga yang digunakan dalam Zabbix ialah mengosongkan sejarah menggunakan Housekeeper. Penjaga rumah mengikut semua tetapan, iaitu, elemen data kami menunjukkan berapa lama untuk disimpan (dalam hari), berapa lama untuk menyimpan trend dan dinamik perubahan.
Saya tidak bercakap tentang TrendCache, yang kami kira dengan cepat: data tiba, kami mengagregatkannya selama satu jam (kebanyakannya ini adalah nombor untuk jam terakhir), jumlahnya adalah purata/minimum dan kami merekodkannya sekali sejam dalam jadual dinamik perubahan (“Trend”) . "Housekeeper" memulakan dan memadam data daripada pangkalan data menggunakan pilihan biasa, yang tidak selalu berkesan.
Bagaimana untuk memahami bahawa ia tidak berkesan? Anda boleh melihat gambar berikut pada graf prestasi proses dalaman:
Penyegerak Sejarah anda sentiasa sibuk (graf merah). Dan graf "merah" yang berada di atas. Ini ialah "Housekeeper" yang bermula dan menunggu pangkalan data memadam semua baris yang telah ditentukan.
Mari ambil beberapa ID Item: anda perlu memadam 5 ribu terakhir; sudah tentu, mengikut indeks. Tetapi biasanya dataset agak besar - pangkalan data masih membacanya dari cakera dan memasukkannya ke dalam cache, dan ini adalah operasi yang sangat mahal untuk pangkalan data. Bergantung pada saiznya, ini boleh menyebabkan masalah prestasi tertentu.
Anda boleh melumpuhkan Housekeeper dengan cara yang mudah - kami mempunyai antara muka web yang biasa. Tetapan dalam Pentadbiran umum (tetapan untuk "Pengurus Rumah") kami melumpuhkan pengemasan dalaman untuk sejarah dan aliran dalaman. Sehubungan itu, Housekeeper tidak lagi mengawal perkara ini:
Apa yang boleh anda lakukan seterusnya? Anda mematikannya, graf anda telah diratakan... Apakah masalah lanjut yang mungkin timbul dalam kes ini? Apa yang boleh membantu?
Pembahagian (sectioning)
Biasanya ini dikonfigurasikan dengan cara yang berbeza pada setiap pangkalan data hubungan yang saya senaraikan. MySQL mempunyai teknologinya sendiri. Tetapi secara keseluruhan mereka sangat serupa apabila ia datang kepada PostgreSQL 10 dan MySQL. Sudah tentu, terdapat banyak perbezaan dalaman dalam cara ia semua dilaksanakan dan bagaimana ia mempengaruhi prestasi. Tetapi secara umum, penciptaan partition baru sering juga membawa kepada masalah tertentu.
Bergantung pada persediaan anda (berapa banyak data yang anda buat dalam satu hari), mereka biasanya menetapkan minimum - ini adalah 1 hari / kelompok, dan untuk "trend", dinamik perubahan - 1 bulan / kelompok baharu. Ini mungkin berubah jika anda mempunyai persediaan yang sangat besar.
Katakan segera tentang saiz persediaan: sehingga 5 ribu nilai baharu sesaat (dipanggil nvps) - ini akan dianggap sebagai "persediaan" kecil. Purata – dari 5 hingga 25 ribu nilai sesaat. Semua yang di atas adalah pemasangan yang besar dan sangat besar yang memerlukan konfigurasi pangkalan data yang sangat berhati-hati.
Pada pemasangan yang sangat besar, 1 hari mungkin tidak optimum. Saya secara peribadi telah melihat partition pada MySQL sebanyak 40 gigabait setiap hari (dan mungkin terdapat lebih banyak lagi). Ini adalah jumlah data yang sangat besar, yang boleh membawa kepada beberapa masalah. Ia perlu dikurangkan.
Mengapa anda memerlukan pembahagian?
Apa yang disediakan oleh Pembahagian, saya rasa semua orang tahu, ialah pembahagian meja. Selalunya ini adalah fail berasingan pada permintaan cakera dan span. Ia memilih satu partition dengan lebih optimum jika ia adalah sebahagian daripada partitioning biasa.
Untuk Zabbix, khususnya, ia digunakan mengikut julat, mengikut julat, iaitu, kami menggunakan cap waktu (nombor biasa, masa sejak permulaan zaman). Anda menentukan permulaan hari/akhir hari, dan ini ialah partition. Sehubungan itu, jika anda meminta data yang berusia dua hari, semuanya diambil dari pangkalan data dengan lebih cepat, kerana anda hanya perlu memuatkan satu fail ke dalam cache dan mengembalikannya (bukannya jadual besar).
Banyak pangkalan data juga mempercepatkan sisipan (penyisipan ke dalam satu jadual kanak-kanak). Saya bercakap secara abstrak buat masa ini, tetapi ini juga mungkin. Pembahagian sering membantu.
Elasticsearch untuk NoSQL
Baru-baru ini, dalam 3.4, kami melaksanakan penyelesaian NoSQL. Menambahkan keupayaan untuk menulis dalam Elasticsearch. Anda boleh menulis jenis tertentu: anda pilih - sama ada menulis nombor atau beberapa tanda; kami mempunyai teks rentetan, anda boleh menulis log ke Elasticsearch... Sehubungan itu, antara muka web juga akan mengakses Elasticsearch. Ini berfungsi dengan baik dalam beberapa kes, tetapi pada masa ini ia boleh digunakan.
TimescaleDB. Hipertable
Untuk 4.4.2 kami memberi perhatian kepada satu perkara seperti TimescaleDB. Apa ini? Ini adalah lanjutan untuk PostgreSQL, iaitu, ia mempunyai antara muka PostgreSQL asli. Selain itu, sambungan ini membolehkan anda bekerja dengan lebih cekap dengan data siri masa dan mempunyai pembahagian automatik. Bagaimana rupanya:
Ini adalah jadual hiper - terdapat konsep sedemikian dalam Skala Masa. Ini ialah jadual hiper yang anda buat, dan ia mengandungi ketulan. Potongan adalah partition, ini adalah meja kanak-kanak, jika saya tidak silap. Memang berkesan.
TimescaleDB dan PostgreSQL
Seperti yang dipastikan oleh pengeluar TimescaleDB, mereka menggunakan algoritma yang lebih betul untuk memproses pertanyaan, khususnya sisipan, yang membolehkan mereka mempunyai prestasi yang lebih kurang tetap dengan saiz sisipan set data yang semakin meningkat. Iaitu, selepas 200 juta baris Postgres, yang biasa mula merosot dan kehilangan prestasi secara literal kepada sifar, manakala Skala Waktu membolehkan anda memasukkan sisipan secekap mungkin dengan sebarang jumlah data.
Bagaimana untuk memasang TimescaleDB? Mudah sahaja!
Ia ada dalam dokumentasi, ia diterangkan - anda boleh memasangnya daripada pakej untuk mana-mana... Ia bergantung pada pakej Postgres rasmi. Boleh disusun secara manual. Kebetulan saya terpaksa menyusun untuk pangkalan data.
Pada Zabbix kami hanya mengaktifkan Pelanjutan. Saya rasa mereka yang menggunakan Extention dalam Postgres... Anda cukup aktifkan Extention, buat untuk pangkalan data Zabbix yang anda gunakan.
Dan langkah terakhir...
TimescaleDB. Penghijrahan jadual sejarah
Anda perlu membuat jadual hiper. Terdapat fungsi khas untuk ini - Cipta jadual hiper. Di dalamnya, parameter pertama ialah jadual yang diperlukan dalam pangkalan data ini (yang mana anda perlu membuat jadual hiper).
Medan untuk mencipta dan chunk_time_interval (ini ialah selang ketulan (partition yang perlu digunakan). 86 adalah satu hari.
Parameter Migrate_data: Jika anda memasukkan ke true, maka ini akan memindahkan semua data semasa ke bongkah yang telah dibuat sebelumnya.
Saya sendiri telah menggunakan migrate_data - ia mengambil masa yang agak lama, bergantung pada saiz pangkalan data anda. Saya mempunyai lebih satu terabait - ia mengambil masa lebih sejam untuk mencipta. Dalam sesetengah kes, semasa ujian, saya memadamkan data sejarah untuk teks (history_text) dan rentetan (history_str) supaya tidak memindahkannya - ia tidak begitu menarik bagi saya.
Dan kami membuat kemas kini terakhir dalam db_extention kami: kami memasang timescaledb supaya pangkalan data dan, khususnya, Zabbix kami memahami bahawa terdapat db_extention. Dia mengaktifkannya dan menggunakan sintaks dan pertanyaan yang betul kepada pangkalan data, menggunakan "ciri" yang diperlukan untuk TimescaleDB.
Konfigurasi pelayan
Saya menggunakan dua pelayan. Pelayan pertama ialah mesin maya yang agak kecil, 20 pemproses, 16 gigabait RAM. Saya mengkonfigurasi Postgres 10.8 padanya:
Sistem pengendalian ialah Debian, sistem fail ialah xfs. Saya membuat tetapan minimum untuk menggunakan pangkalan data khusus ini, tolak apa yang Zabbix sendiri akan gunakan. Pada mesin yang sama terdapat pelayan Zabbix, PostgreSQL dan ejen muat.
Saya telah menggunakan 50 ejen aktif yang menggunakan LoadableModule untuk menjana hasil yang berbeza dengan cepat. Merekalah yang menghasilkan rentetan, nombor, dan sebagainya. Saya mengisi pangkalan data dengan banyak data. Pada mulanya, konfigurasi mengandungi 5 ribu elemen data bagi setiap hos, dan kira-kira setiap elemen data mengandungi pencetus - agar ini menjadi persediaan sebenar. Kadangkala anda memerlukan lebih daripada satu pencetus untuk digunakan.
Saya mengawal selia selang kemas kini dan beban itu sendiri dengan bukan sahaja menggunakan 50 ejen (menambah lebih banyak), tetapi juga menggunakan elemen data dinamik dan mengurangkan selang kemas kini kepada 4 saat.
Ujian prestasi. PostgreSQL: 36 ribu NVP
Pelancaran pertama, persediaan pertama yang saya ada adalah pada PostreSQL 10 tulen pada perkakasan ini (35 ribu nilai sesaat). Secara umum, seperti yang anda lihat pada skrin, memasukkan data mengambil masa sesaat - semuanya baik dan pantas, pemacu SSD (200 gigabait). Satu-satunya perkara ialah 20 GB diisi dengan cepat.
Akan terdapat banyak graf sedemikian pada masa hadapan. Ini ialah papan pemuka prestasi pelayan Zabbix standard.
Graf pertama ialah bilangan nilai sesaat (biru, kiri atas), 35 ribu nilai dalam kes ini. Ini (tengah atas) ialah pemuatan proses binaan, dan ini (kanan atas) ialah pemuatan proses dalaman: penyegerak sejarah dan pembantu rumah, yang di sini (tengah bawah) telah berjalan untuk sekian lama.
Graf ini (tengah bawah) menunjukkan penggunaan ValueCache - bilangan hits ValueCache untuk pencetus (beberapa ribu nilai sesaat). Satu lagi graf penting ialah yang keempat (kiri bawah), yang menunjukkan penggunaan HistoryCache, yang saya bincangkan, yang merupakan penimbal sebelum dimasukkan ke dalam pangkalan data.
Ujian prestasi. PostgreSQL: 50 ribu NVP
Seterusnya, saya meningkatkan beban kepada 50 ribu nilai sesaat pada perkakasan yang sama. Apabila dimuatkan oleh Housekeeper, 10 ribu nilai direkodkan dalam 2-3 saat dengan pengiraan. Apa, sebenarnya, ditunjukkan dalam tangkapan skrin berikut:
"Pengurus Rumah" sudah mula mengganggu kerja, tetapi secara amnya, beban pada perangkap penenggelam sejarah masih pada tahap 60% (graf ketiga, kanan atas). HistoryCache sudah mula diisi secara aktif semasa Housekeeper sedang berjalan (kiri bawah). Ia adalah kira-kira setengah gigabait, 20% penuh.
Ujian prestasi. PostgreSQL: 80 ribu NVP
Kemudian saya meningkatkannya kepada 80 ribu nilai sesaat:
Ia adalah kira-kira 400 ribu elemen data, 280 ribu pencetus. Sisipan, seperti yang anda lihat, dari segi beban sinkers sejarah (terdapat 30 daripadanya) sudah agak tinggi. Kemudian saya meningkatkan pelbagai parameter: sinkers sejarah, cache... Pada perkakasan ini, beban pada sinkers sejarah mula meningkat kepada maksimum, hampir "di rak" - sewajarnya, HistoryCache masuk ke beban yang sangat tinggi:
Selama ini saya memantau semua parameter sistem (bagaimana pemproses digunakan, RAM) dan mendapati bahawa penggunaan cakera adalah maksimum - saya mencapai kapasiti maksimum cakera ini pada perkakasan ini, pada mesin maya ini. "Postgres" mula membuang data dengan agak aktif pada keamatan sedemikian, dan cakera tidak lagi mempunyai masa untuk menulis, membaca...
Saya mengambil pelayan lain yang sudah mempunyai 48 pemproses dan 128 gigabait RAM:
Saya juga "menala"nya - memasang penyegerak Sejarah (60 keping) dan mencapai prestasi yang boleh diterima. Sebenarnya, kita tidak "di atas rak", tetapi ini mungkin had produktiviti, di mana ia sudah perlu untuk melakukan sesuatu mengenainya.
Ujian prestasi. TimescaleDB: 80 ribu NVP
Tugas utama saya ialah menggunakan TimescaleDB. Setiap graf menunjukkan penurunan:
Kegagalan ini adalah tepatnya pemindahan data. Selepas itu, dalam pelayan Zabbix, profil pemuatan sinkers sejarah, seperti yang anda lihat, banyak berubah. Ia membolehkan anda memasukkan data hampir 3 kali lebih pantas dan menggunakan lebih sedikit HistoryCache - sewajarnya, anda akan menghantar data tepat pada masanya. Sekali lagi, 80 ribu nilai sesaat adalah kadar yang agak tinggi (sudah tentu, bukan untuk Yandex). Secara keseluruhan ini adalah persediaan yang agak besar, dengan satu pelayan.
Ujian prestasi PostgreSQL: 120 ribu NVP
Seterusnya, saya meningkatkan nilai bilangan elemen data kepada setengah juta dan menerima nilai yang dikira sebanyak 125 ribu sesaat:
Dan saya mendapat graf ini:
Pada dasarnya, ini adalah persediaan yang berfungsi, ia boleh berfungsi untuk masa yang agak lama. Tetapi kerana saya hanya mempunyai cakera 1,5 terabait, saya menggunakannya dalam beberapa hari. Perkara yang paling penting ialah pada masa yang sama partition baru dicipta pada TimescaleDB, dan ini tidak disedari sepenuhnya untuk prestasi, yang tidak boleh dikatakan tentang MySQL.
Biasanya, sekatan dibuat pada waktu malam, kerana ini biasanya menyekat pemasukan dan berfungsi dengan jadual dan boleh menyebabkan kemerosotan perkhidmatan. Dalam kes ini, ini tidak berlaku! Tugas utama adalah untuk menguji keupayaan TimescaleDB. Hasilnya ialah angka berikut: 120 ribu nilai sesaat.
Terdapat juga contoh dalam komuniti:
Orang itu juga menghidupkan TimescaleDB dan beban menggunakan io.weight menurun pada pemproses; dan penggunaan elemen proses dalaman juga telah berkurangan disebabkan oleh kemasukan TimescaleDB. Selain itu, ini adalah cakera lempeng biasa, iaitu mesin maya biasa pada cakera biasa (bukan SSD)!
Untuk beberapa tetapan kecil yang dihadkan oleh prestasi cakera, TimescaleDB, pada pendapat saya, adalah penyelesaian yang sangat baik. Ia akan membolehkan anda terus bekerja sebelum berhijrah ke perkakasan yang lebih pantas untuk pangkalan data.
Saya menjemput anda semua ke acara kami: Persidangan di Moscow, Sidang Kemuncak di Riga. Gunakan saluran kami - Telegram, forum, IRC. Jika anda mempunyai sebarang pertanyaan, datang ke meja kami, kami boleh bercakap tentang segala-galanya.
Soalan Khalayak
Soalan daripada penonton (selepas ini - A): - Jika TimescaleDB begitu mudah untuk dikonfigurasikan, dan ia memberikan peningkatan prestasi sedemikian, maka mungkin ini harus digunakan sebagai amalan terbaik untuk mengkonfigurasi Zabbix dengan Postgres? Dan adakah terdapat sebarang kelemahan dan keburukan penyelesaian ini, atau selepas semua, jika saya memutuskan untuk membuat Zabbix untuk diri saya sendiri, saya boleh dengan mudah mengambil Postgres, memasang Skala Waktu di sana dengan segera, menggunakannya dan tidak memikirkan sebarang masalah?
AG: – Ya, saya akan mengatakan bahawa ini adalah cadangan yang baik: gunakan Postgres dengan segera dengan sambungan TimescaleDB. Seperti yang telah saya katakan, banyak ulasan yang baik, walaupun pada hakikatnya "ciri" ini adalah percubaan. Tetapi sebenarnya ujian menunjukkan bahawa ini adalah penyelesaian yang hebat (dengan TimescaleDB) dan saya fikir ia akan berkembang! Kami memantau cara sambungan ini berkembang dan akan membuat perubahan mengikut keperluan.
Walaupun semasa pembangunan, kami bergantung pada salah satu daripada "ciri" mereka yang terkenal: adalah mungkin untuk bekerja dengan ketulan sedikit berbeza. Tetapi kemudian mereka memotongnya dalam keluaran seterusnya, dan kami terpaksa berhenti bergantung pada kod ini. Saya akan mengesyorkan menggunakan penyelesaian ini pada banyak persediaan. Jika anda menggunakan MySQL... Untuk persediaan purata, sebarang penyelesaian berfungsi dengan baik.
J: – Pada graf terakhir daripada komuniti, terdapat graf dengan "Pengurus Rumah":
Dia terus bekerja. Apakah yang dilakukan oleh Housekeeper dengan TimescaleDB?
AG: – Sekarang saya tidak boleh mengatakan dengan pasti – Saya akan melihat kod dan memberitahu anda dengan lebih terperinci. Ia menggunakan pertanyaan TimescaleDB bukan untuk memadam ketulan, tetapi untuk mengagregatkannya. Saya belum bersedia untuk menjawab soalan teknikal ini. Kami akan mengetahui lebih lanjut di gerai hari ini atau esok.
J: – Saya mempunyai soalan yang sama – tentang prestasi operasi pemadaman dalam Skala Masa.
A (jawapan daripada penonton): – Apabila anda memadam data daripada jadual, jika anda melakukannya melalui pemadaman, maka anda perlu melalui jadual - padam, bersihkan, tandakan segala-galanya untuk vakum masa hadapan. Dalam Skala Masa, kerana anda mempunyai ketulan, anda boleh menggugurkan. Secara kasarnya, anda hanya memberitahu fail yang berada dalam data besar: "Padam!"
Skala masa hanya memahami bahawa bahagian seperti itu tidak lagi wujud. Dan kerana ia disepadukan ke dalam perancang pertanyaan, ia menggunakan cangkuk untuk menangkap keadaan anda dalam pilihan atau operasi lain dan serta-merta memahami bahawa bahagian ini tidak lagi wujud - "Saya tidak akan pergi ke sana lagi!" (data tidak tersedia). Itu sahaja! Iaitu, imbasan jadual digantikan dengan pemadaman fail binari, jadi ia pantas.
J: – Kami telah pun menyentuh topik bukan SQL. Setakat yang saya faham, Zabbix sebenarnya tidak perlu mengubah suai data, dan semua ini adalah seperti log. Adakah mungkin untuk menggunakan pangkalan data khusus yang tidak boleh mengubah data mereka, tetapi pada masa yang sama menyimpan, mengumpul, dan mengedarkan dengan lebih cepat - Clickhouse, sebagai contoh, sesuatu seperti Kafka?.. Kafka juga log! Adakah mungkin untuk menyepadukan mereka?
AG: - Pemunggahan boleh dilakukan. Kami mempunyai "ciri" tertentu sejak versi 3.4: anda boleh menulis semua fail sejarah, peristiwa, segala-galanya ke fail; dan kemudian hantar ke mana-mana pangkalan data lain menggunakan beberapa pengendali. Malah, ramai orang mengolah semula dan menulis terus ke pangkalan data. Dengan cepat, penyerap sejarah menulis semua ini ke dalam fail, memutar fail ini, dan seterusnya, dan anda boleh memindahkannya ke Clickhouse. Saya tidak boleh mengatakan tentang rancangan, tetapi mungkin sokongan lanjut untuk penyelesaian NoSQL (seperti Clickhouse) akan diteruskan.
J: – Secara umum, ternyata anda boleh menyingkirkan postgres sepenuhnya?
AG: – Sudah tentu, bahagian yang paling sukar dalam Zabbix ialah jadual sejarah, yang mencipta paling banyak masalah, dan peristiwa. Dalam kes ini, jika anda tidak menyimpan acara untuk masa yang lama dan menyimpan sejarah dengan trend dalam beberapa storan pantas yang lain, maka secara umum, saya fikir, tidak akan ada masalah.
J: – Bolehkah anda menganggarkan berapa cepat semuanya akan berfungsi jika anda bertukar kepada Clickhouse, sebagai contoh?
AG: - Saya belum mengujinya. Saya fikir sekurang-kurangnya nombor yang sama boleh dicapai dengan mudah, memandangkan Clickhouse mempunyai antara muka sendiri, tetapi saya tidak boleh mengatakan dengan pasti. Adalah lebih baik untuk menguji. Semuanya bergantung pada konfigurasi: berapa banyak hos yang anda ada, dan sebagainya. Memasukkan adalah satu perkara, tetapi anda juga perlu mendapatkan semula data ini - Grafana atau sesuatu yang lain.
J: – Jadi kita bercakap tentang perjuangan yang sama, dan bukan tentang kelebihan hebat pangkalan data pantas ini?
AG: – Saya fikir apabila kita menyepadukan, akan ada ujian yang lebih tepat.
J: – Ke mana perginya RRD lama yang baik? Apa yang membuatkan anda beralih kepada pangkalan data SQL? Pada mulanya, semua metrik dikumpulkan pada RRD.
AG: – Zabbix mempunyai RRD, mungkin dalam versi yang sangat kuno. Selalu ada pangkalan data SQL - pendekatan klasik. Pendekatan klasik ialah MySQL, PostgreSQL (mereka telah wujud untuk masa yang sangat lama). Kami hampir tidak pernah menggunakan antara muka biasa untuk pangkalan data SQL dan RRD.
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