Zabbix minangka sistem pemantauan. Kaya sistem liyane, ngadhepi telung masalah utama kabeh sistem pemantauan: ngumpulake lan ngolah data, nyimpen sejarah, lan ngresiki.
Tahap nampa, ngolah lan ngrekam data mbutuhake wektu. Ora akeh, nanging kanggo sistem gedhe iki bisa nyebabake wektu tundha gedhe. Masalah panyimpenan yaiku masalah akses data. Padha digunakake kanggo laporan, mriksa lan pemicu. Latensi ing akses data uga mengaruhi kinerja. Nalika database tuwuh, data sing ora relevan kudu dibusak. Mbusak minangka operasi angel sing uga mangan sawetara sumber daya.
Masalah telat sajrone koleksi lan panyimpenan ing Zabbix ditanggulangi kanthi caching: sawetara jinis cache, caching ing database. Kanggo ngatasi masalah katelu, caching ora cocok, mula Zabbix nggunakake TimescaleDB. Dheweke bakal ngandhani sampeyan Andrey Guschin - teknisi dhukungan teknis . Andrey wis ndhukung Zabbix luwih saka 6 taun lan duwe pengalaman langsung karo kinerja.
Kepiye cara kerja TimescaleDB, kinerja apa sing bisa ditindakake dibandhingake karo PostgreSQL biasa? Apa peran Zabbix kanggo database TimescaleDB? Kepiye cara miwiti saka awal lan kepiye migrasi saka PostgreSQL lan konfigurasi sing luwih apik? Babagan kabeh iki ing ngisor potong.
Tantangan Produktivitas
Saben sistem ngawasi ngadhepi tantangan kinerja tartamtu. Aku bakal ngomong babagan telu: pengumpulan lan pangolahan data, panyimpenan, lan ngresiki riwayat.
Pangumpulan lan pangolahan data kanthi cepet. Sistem ngawasi sing apik kudu cepet nampa kabeh data lan ngolah miturut ekspresi pemicu - miturut kritéria. Sawise diproses, sistem uga kudu cepet nyimpen data iki ing database kanggo nggunakake mengko.
panyimpenan Sajarah. Sistem ngawasi sing apik kudu nyimpen riwayat ing basis data lan nyedhiyakake akses gampang menyang metrik. Sejarah dibutuhake kanggo digunakake ing laporan, grafik, pemicu, ambang, lan item data tandha sing diwilang.
Mbusak riwayat. Kadhangkala ana dina nalika sampeyan ora perlu nyimpen metrik. Napa sampeyan butuh data sing diklumpukake 5 taun kepungkur, sasi utawa rong sasi: sawetara simpul wis dibusak, sawetara host utawa metrik ora dibutuhake maneh amarga wis ketinggalan jaman lan ora diklumpukake maneh. Sistem ngawasi sing apik kudu nyimpen data historis lan mbusak saka wektu kanggo wektu supaya database ora tuwuh.
Ngresiki data basi minangka masalah kritis sing mengaruhi kinerja database.
Caching ing Zabbix
Ing Zabbix, telpon pisanan lan kaloro ditanggulangi nggunakake caching. RAM digunakake kanggo ngumpulake lan ngolah data. Kanggo panyimpenan - riwayat ing pemicu, grafik lan unsur data sing diwilang. Ing sisih database ana sawetara caching kanggo pilihan dhasar, contone, grafik.
Caching ing sisih server Zabbix dhewe yaiku:
- KonfigurasiCache;
- ValueCache;
- HistoryCache;
- TrendsCache.
Coba luwih rinci.
KonfigurasiCache
Iki minangka cache utama ing ngendi kita nyimpen metrik, host, item data, pemicu - kabeh sing dibutuhake kanggo PreProcessing lan kanggo koleksi data.
Kabeh iki disimpen ing ConfigurationCache supaya ora nggawe pitakon sing ora perlu ing database. Sawise server diwiwiti, kita nganyari cache iki, nggawe lan nganyari konfigurasi sacara periodik.
Pangumpulan data
Diagram kasebut cukup gedhe, nanging sing utama yaiku pemilih. Iki macem-macem "pollers" - proses perakitan. Dheweke tanggung jawab kanggo macem-macem jinis perakitan: ngumpulake data liwat SNMP, IPMI, lan nransfer kabeh menyang PreProcessing.
Kolektor kasebut digambarake ing warna oranye.
Zabbix wis ngetung item agregasi sing dibutuhake kanggo mriksa agregat. Yen kita duwe, kita njupuk data kasebut langsung saka ValueCache.
PreProcessing HistoryCache
Kabeh kolektor nggunakake ConfigurationCache kanggo nampa proyek. Banjur ditransfer menyang PreProcessing.
PreProcessing nggunakake ConfigurationCache kanggo nampa langkah PreProcessing. Iki ngolah data kanthi macem-macem cara.
Sawise ngolah data nggunakake PreProcessing, kita simpen ing HistoryCache kanggo diproses. Iki mungkasi pangumpulan data lan kita pindhah menyang proses utama ing Zabbix - sinkronisasi sajarah, awit iku arsitektur monolitik.
Cathetan: PreProcessing minangka operasi sing angel banget. Kanthi v 4.2 wis dipindhah menyang proxy. Yen sampeyan duwe Zabbix gedhe banget karo nomer akeh unsur data lan frekuensi koleksi, banjur iki ndadekake karya luwih gampang.
ValueCache, riwayat & tren cache
Sinkronisasi sejarah minangka proses utama sing ngolah saben unsur data kanthi atom, yaiku saben nilai.
Sinkronisasi sejarah njupuk nilai saka HistoryCache lan mriksa Konfigurasi kanggo anané pemicu kanggo petungan. Yen padha ana, iku ngetung.
Sinkronisasi riwayat nggawe acara, eskalasi kanggo nggawe tandha yen dibutuhake dening konfigurasi, lan cathetan. Yen ana pemicu kanggo pangolahan sakteruse, banjur nyimpen nilai kasebut ing ValueCache supaya ora ngakses tabel riwayat. Iki carane ValueCache kapenuhan data sing perlu kanggo ngitung pemicu lan unsur diwilang.
Sinkronisasi sejarah nulis kabeh data menyang database, lan nulis menyang disk. Proses pangolahan rampung ing kene.
Caching ing database
Ing sisih database ana macem-macem cache nalika sampeyan pengin ndeleng grafik utawa laporan babagan acara:
Innodb_buffer_pooling sisih MySQL;shared_buffersing sisih PostgreSQL;effective_cache_sizeing sisih Oracle;shared_pooling sisih DB2.
Ana akeh cache liyane, nanging iki sing utama kanggo kabeh database. Dheweke ngidini sampeyan nyimpen data ing RAM sing asring dibutuhake kanggo pitakon. Dheweke duwe teknologi dhewe kanggo iki.
Kinerja database kritis
Server Zabbix terus-terusan ngumpulake data lan nulis. Nalika diwiwiti maneh, uga diwaca saka sejarah kanggo ngisi ValueCache. Migunakake skrip lan laporan Zabbix API, sing dibangun ing antarmuka Web. Zabbix API ngakses database lan njupuk data sing dibutuhake kanggo grafik, laporan, dhaptar acara lan masalah paling anyar.
Kanggo visualisasi - Grafana. Iki minangka solusi sing populer ing antarane pangguna. Bisa langsung ngirim panjalukan liwat Zabbix API lan kanggo database, lan nggawe kompetisi tartamtu kanggo nampa data. Mula, tuning database sing luwih apik lan luwih apik dibutuhake kanggo cocog karo pangiriman asil lan tes kanthi cepet.
housekeeper
Tantangan kinerja katelu ing Zabbix yaiku ngresiki sejarah nggunakake Housekeeper. Nderek kabeh setelan - unsur data nuduhake suwene kanggo nyimpen dinamika owah-owahan (tren) ing dina.
We ngetung TrendsCache ing fly. Nalika data kasebut teka, kita ngumpulake sajrone siji jam lan ngrekam ing tabel kanggo dinamika owah-owahan tren.
Housekeeper miwiti lan mbusak informasi saka database nggunakake biasanipun "milih". Iki ora mesthi efektif, kaya sing bisa dideleng saka grafik kinerja proses internal.
Grafik abang nuduhake yen sinkronisasi Sejarah terus sibuk. Grafik oranye ing ndhuwur yaiku Housekeeper, sing terus mlaku. Dheweke ngenteni database mbusak kabeh baris sing ditemtokake.
Nalika sampeyan kudu mateni Housekeeper? Contone, ana "ID Item" lan sampeyan kudu mbusak 5 ewu baris pungkasan ing wektu tartamtu. Mesthi, iki kedadeyan kanthi indeks. Nanging biasane dataset gedhe banget, lan database isih maca saka disk lan sijine menyang cache. Iki mesthi dadi operasi sing larang banget kanggo database lan, gumantung saka ukuran database, bisa nyebabake masalah kinerja.
Housekeeper gampang dipateni. Ing antarmuka Web ana setelan ing "Administrasi umum" kanggo Housekeeper. Kita mateni Housekeeping internal kanggo riwayat tren internal lan ora bisa ngatur maneh.
Housekeeper dipateni, grafik leveled - apa masalah sing bisa ana ing kasus iki lan apa sing bisa mbantu ngatasi tantangan kinerja katelu?
Pemisahan - pemisahan utawa pemisahan
Biasane, partisi dikonfigurasi kanthi cara sing beda ing saben basis data relasional sing wis dakdaftar. Saben duwe teknologi dhewe, nanging padha ing umum. Nggawe partisi anyar asring nyebabake masalah tartamtu.
Biasane, partisi dikonfigurasi gumantung saka "persiyapan" - jumlah data sing digawe ing sedina. Minangka aturan, Pemisahan ditanggepi ing sedina, iki minangka minimal. Kanggo tren saka kumpulan anyar - 1 sasi.
Nilai bisa diganti yen "persiyapan" gedhe banget. Yen "persiyapan" cilik nganti 5 nvps (nilai anyar per detik), sing medium saka 000 nganti 5, banjur sing gedhe luwih saka 000 nvps. Iki minangka panginstalan gedhe lan gedhe banget sing mbutuhake konfigurasi database sing ati-ati.
Ing instalasi sing gedhe banget, wektu sedina bisa uga ora optimal. Aku wis ndeleng partisi MySQL 40 GB utawa luwih saben dina. Iki minangka jumlah data sing akeh banget sing bisa nyebabake masalah lan kudu dikurangi.
Apa sing menehi Partitioning?
Tabel partisi. Asring iki file kapisah ing disk. Rencana pitakon milih partisi kanthi luwih optimal. Biasane partisi digunakake dening sawetara - iki uga bener kanggo Zabbix. Kita nggunakake "timestamp" ing kana - wektu wiwit wiwitan jaman. Iki nomer biasa kanggo kita. Sampeyan nyetel wiwitan lan pungkasan dina - iki minangka partisi.
mbusak cepet - DELETE. Siji file/subtabel dipilih, tinimbang pilihan baris kanggo dibusak.
Ngartekno nyepetake pengangkatan data SELECT - nggunakake siji utawa luwih partisi, tinimbang kabeh tabel. Yen sampeyan ngakses data sing umure rong dina, dijupuk saka database luwih cepet amarga sampeyan mung kudu mbukak siji file menyang cache lan bali, dudu meja gedhe.
Asring akeh database uga digawe cepet INSERT - sisipan menyang meja anak.
TimescaleDB
Kanggo v 4.2, kita nguripake kanggo TimescaleDB. Iki minangka ekstensi kanggo PostgreSQL kanthi antarmuka asli. Ekstensi kasebut bisa digunakake kanthi efektif karo data seri wektu, tanpa kelangan keuntungan saka database relasional. TimescaleDB uga partisi kanthi otomatis.
TimescaleDB duwe konsep hipertabel (hypertable) sing digawe. Isine bongkahan - sekat. Potongan kanthi otomatis ngatur pecahan hypertable sing ora mengaruhi pecahan liyane. Saben potongan duwe sawetara wektu dhewe.
TimescaleDB vs PostgreSQL
TimescaleDB kerjane kanthi efisien. Produsen ekstensi kasebut ngaku nggunakake algoritma pangolahan pitakon sing luwih bener, utamane inserts . Minangka ukuran insert dataset mundak akeh, algoritma njaga kinerja pancet.
Sawise 200 yuta larik, PostgreSQL biasane wiwit mudhun kanthi signifikan lan ilang kinerja dadi 0. TimescaleDB ngidini sampeyan nglebokake "sisipan" kanthi efisien kanggo jumlah data apa wae.
Instalasi
Nginstal TimescaleDB cukup gampang kanggo paket apa wae. ING kabeh diterangake kanthi rinci - gumantung saka paket PostgreSQL resmi. TimescaleDB uga bisa dibangun lan disusun kanthi manual.
Kanggo basis data Zabbix, kita mung ngaktifake ekstensi:
echo "CREATE EXTENSION IF NOT EXISTS timescaledb CASCADE;" | sudo -u postgres psql zabbix
Sampeyan ngaktifake extension lan nggawe kanggo database Zabbix. Langkah pungkasan yaiku nggawe hypertable.
Migrasi tabel riwayat menyang TimescaleDB
Ana fungsi khusus kanggo iki 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 kasebut nduweni telung parameter. pisanan- tabel ing database, sing sampeyan kudu nggawe hypertable. Kapindho - lapangan, miturut sampeyan kudu nggawe chunk_time_interval - interval potongan partisi sing bakal digunakake. Ing kasusku, interval sedina - 86.
Parameter katelu - migrate_data. Yen sampeyan nyetel true, banjur kabeh data saiki ditransfer menyang potongan sing wis digawe. Aku digunakake dhewe migrate_data. Aku duwe babagan 1 TB, sing njupuk luwih saka jam. Malah ing sawetara kasus, nalika nyoba, aku mbusak data sajarah saka jinis karakter sing ora dibutuhake kanggo panyimpenan, supaya ora nransfer.
Langkah pungkasan - UPDATE: ing db_extension sijine timescaledbsupaya database ngerti yen ekstensi iki ana. Zabbix ngaktifake lan nggunakake sintaks lan pitakon kanthi bener menyang database - fitur sing dibutuhake kanggo TimescaleDB.
Konfigurasi hardware
Aku digunakake loro server. pisanan- mesin VMware. Iku cukup cilik: 20 Intel® Xeon® CPU E5-2630 v 4 @ 2.20GHz pemroses, 16 GB RAM lan 200 GB SSD.
Aku nginstal PostgreSQL 10.8 karo Debian 10.8-1.pgdg90 + 1 OS lan sistem file xfs. Aku ngatur kabeh minimal kanggo nggunakake database tartamtu iki, minus apa Zabbix dhewe bakal nggunakake.
Ing mesin padha ana server Zabbix, PostgreSQL lan agen mbukak. Aku duwe 50 agen aktif sing digunakake LoadableModulekanggo banget cepet generate asil beda: nomer, strings. Aku ngisi database kanthi akeh data.
Kaping pisanan konfigurasi sing ana 5 unsur data saben host. Meh saben unsur ngemot pemicu supaya padha karo instalasi nyata. Ing sawetara kasus, ana luwih saka siji pemicu. Kanggo siji simpul jaringan ana 3-000 pemicu.
Interval Nganyari Item Data − 4-7 detik. Aku ngatur beban dhewe kanthi nggunakake ora mung 50 agen, nanging nambah liyane. Uga, nggunakake unsur data, Aku mbosenke nyetel mbukak lan suda interval nganyari kanggo 4 s.
PostgreSQL. 35 nvps
Laku pisanan ing hardware iki yaiku PostgreSQL murni - 35 ewu nilai per detik. Kaya sing sampeyan ngerteni, nglebokake data butuh sekedhik - kabeh apik lan cepet. Ing bab mung sing 200 GB SSD disk isi munggah cepet.
Iki minangka dashboard kinerja server Zabbix standar.
Grafik biru pisanan yaiku jumlah nilai per detik. Grafik kapindho ing sisih tengen yaiku loading proses mbangun. Katelu yaiku ngemot proses mbangun internal: sinkronisasi sejarah lan Housekeeper, sing wis suwe ditindakake ing kene.
Grafik kaping papat nuduhake panggunaan HistoryCache. Iki minangka jinis buffer sadurunge dilebokake ing database. Grafik kaping lima ijo nuduhake panggunaan ValueCache, yaiku, pira ValueCache cocog kanggo pemicu - iki sawetara ewu nilai per detik.
PostgreSQL. 50 nvps
Banjur aku nambah beban dadi 50 ewu nilai per detik ing hardware sing padha.
Nalika mbukak saka Housekeeper, nglebokake 10 ewu nilai butuh 2-3 detik.
Pembantu rumah tangga wis mulai ngganggu kerja.
Grafik katelu nuduhake yen, ing umum, beban ing trappers lan synchers sajarah isih ing 60%. Ing grafik kaping papat, HistoryCache wis mulai diisi kanthi aktif sajrone operasi Housekeeper. Iku 20% kebak, yaiku babagan 0,5 GB.
PostgreSQL. 80 nvps
Banjur aku nambah beban dadi 80 ewu nilai per detik. Iki kira-kira 400 ewu unsur data lan 280 ewu pemicu.
Biaya loading telung puluh synchers sajarah wis cukup dhuwur.
Aku uga nambah macem-macem paramèter: sinkronisasi riwayat, cache.
Ing hardware, loading sinkronisasi sejarah saya tambah maksimal. HistoryCache kanthi cepet diisi data - data kanggo pangolahan wis diklumpukake ing buffer.
Kabeh wektu iki aku diamati carane prosesor, RAM lan paramèter sistem liyane digunakake, lan ketemu sing nggunakake disk ing maksimum.
Aku wis entuk panggunaan Kapabilitas disk maksimum ing hardware iki lan ing mesin virtual iki. Kanthi intensitas kaya ngono, PostgreSQL wiwit nyiram data kanthi aktif, lan disk ora duwe wektu kanggo nulis lan maca.
Server kapindho
Aku njupuk server liyane, sing wis 48 prosesor lan 128 GB RAM. Aku nyetel - nyetel menyang 60 sinkronisasi sajarah, lan entuk kinerja sing bisa ditampa.
Nyatane, iki wis dadi watesan produktivitas sing kudu ditindakake.
TimescaleDB. 80 nvps
Tugas utamaku yaiku nguji kemampuan TimescaleDB nglawan beban Zabbix. 80 ewu nilai per detik akeh banget, frekuensi ngumpulake metrik (kajaba Yandex, mesthi) lan "persiyapan" sing cukup gedhe.
Ana penurunan ing saben grafik - iki persis migrasi data. Sawise gagal ing server Zabbix, profil loading saka sinkronisasi sejarah diganti akeh - mudhun kaping telu.
TimescaleDB ngidini sampeyan nglebokake data meh 3 kaping luwih cepet lan nggunakake HistoryCache kurang.
Mulane, sampeyan bakal nampa data ing wektu sing tepat.
TimescaleDB. 120 nvps
Banjur aku nambah jumlah unsur data dadi 500 ewu. Tugas utama yaiku nguji kemampuan TimescaleDB - aku nampa nilai kalkulasi 125 ewu per detik.
Iki minangka "persiyapan" sing bisa digunakake kanggo wektu sing suwe. Nanging amarga diskku mung 1,5 TB, aku ngisi sawetara dina.
Sing paling penting yaiku ing wektu sing padha partisi TimescaleDB anyar digawe.
Iki rampung unnoticeable kanggo kinerja. Nalika partisi digawe ing MySQL, contone, kabeh beda. Iki biasane kedadeyan ing wayah wengi amarga ngalangi sisipan umum, nggarap tabel lan bisa nggawe degradasi layanan. Iki ora kedadeyan karo TimescaleDB.
Minangka conto, aku bakal nuduhake siji grafik saka akeh ing masyarakat. Ing gambar, TimescaleDB diaktifake, amarga beban nggunakake io.weight ing prosesor wis mudhun. Panggunaan unsur proses internal uga suda. Kajaba iku, iki minangka mesin virtual biasa ing disk pancake biasa, dudu SSD.
temonan
TimescaleDB minangka solusi sing apik kanggo "persiyapan" cilik, sing mengaruhi kinerja disk. Iki bakal ngidini sampeyan terus kerja kanthi apik nganti database dipindhah menyang hardware kanthi cepet.
TimescaleDB gampang kanggo ngatur, menehi hasil kinerja, dianggo uga karo Zabbix lan duwe kaluwihan saka PostgreSQL.
Yen sampeyan nggunakake PostgreSQL lan ora rencana kanggo ngganti, Aku menehi saran nggunakake PostgreSQL karo ekstensi TimescaleDB magepokan karo Zabbix. Solusi iki bisa digunakake kanthi efektif nganti "persiyapan" medium.
Nalika kita ngomong "kinerja dhuwur" kita tegese . Sampeyan ora bakal ngenteni suwe kanggo sinau babagan teknologi lan praktik sing ngidini layanan bisa nglayani mayuta-yuta pangguna. Dhaptar kanggo 7 lan 8 November kita wis nyawiji, nanging kene liyane bisa disaranake.
Langganan kita и , kang kita mbukak fitur saka konferensi mbesuk, lan mangerteni carane kanggo njaluk paling metu saka iku.
Source: www.habr.com