Zabbix mangrupikeun sistem ngawaskeun. Sapertos sistem anu sanés, éta nyanghareupan tilu masalah utama sadaya sistem ngawaskeun: ngumpulkeun sareng ngolah data, nyimpen sajarah, sareng ngabersihkeunana.
Tahap narima, ngolah jeung ngarékam data butuh waktu. Henteu seueur, tapi pikeun sistem anu ageung ieu tiasa nyababkeun telat anu ageung. Masalah panyimpen nyaéta masalah aksés data. Éta téh dipaké pikeun laporan, cék sarta pemicu. Latén dina aksés data ogé mangaruhan kinerja. Nalika basis data tumuwuh, data anu teu relevan kedah dihapus. Ngahapus mangrupikeun operasi anu sesah anu ogé ngahakan sababaraha sumber.
Masalah telat nalika ngumpulkeun sareng neundeun di Zabbix direngsekeun ku cache: sababaraha jinis cache, cache dina pangkalan data. Pikeun ngajawab masalah katilu, cache teu cocog, jadi Zabbix dipaké TimescaleDB. Anjeunna bakal ngabejaan Anjeun tentang eta Andrey Gushchin - insinyur rojongan teknis . Andrey parantos ngadukung Zabbix langkung ti 6 taun sareng gaduh pangalaman langsung sareng pagelaran.
Kumaha jalanna TimescaleDB, kinerja naon anu tiasa dipasihkeun dibandingkeun sareng PostgreSQL biasa? Naon peran Zabbix pikeun database TimescaleDB? Kumaha ngamimitian ti mimiti sareng kumaha migrasi ti PostgreSQL sareng konfigurasi mana anu langkung saé? Ngeunaan sadayana ieu handapeun cut.
Tantangan Produktivitas
Unggal sistem ngawaskeun nyanghareupan tantangan kinerja husus. Kuring bakal ngobrol ngeunaan tilu di antarana: pangumpulan sareng pamrosésan data, neundeun, sareng ngabersihan sajarah.
Pangumpulan sareng pangolahan data gancang. Sistem ngawaskeun anu saé kedah gancang nampi sadaya data sareng ngolahna dumasar kana ekspresi pemicu - numutkeun kriteria na. Saatos ngolah, sistem ogé kedah gancang nyimpen data ieu dina pangkalan data pikeun dianggo engké.
Panyimpenan sajarah. Hiji sistem ngawaskeun alus kedah nyimpen sajarah dina database sarta nyadiakeun aksés gampang metrics. Sajarah diperlukeun pikeun dipaké dina laporan, grafik, pemicu, thresholds, sarta diitung item data waspada.
Ngabersihan sajarah. Kadang-kadang aya dinten nalika anjeun henteu kedah nyimpen métrik. Naha anjeun peryogi data anu dikumpulkeun 5 sababaraha taun ka pengker, sabulan atanapi dua: sababaraha titik parantos dipupus, sababaraha host atanapi métrik henteu diperyogikeun deui sabab parantos katinggaleun jaman sareng henteu deui dikumpulkeun. Sistem ngawaskeun anu saé kedah nyimpen data sajarah sareng ngahapus tina waktos ka waktos supados pangkalan data henteu tumbuh.
Ngabersihan data basi mangrupikeun masalah kritis anu mangaruhan pisan kana kinerja database.
Caching dina Zabbix
Dina Zabbix, sauran kahiji sareng kadua direngsekeun nganggo cache. RAM dipaké pikeun ngumpulkeun jeung ngolah data. Pikeun neundeun - sajarah dina micu, grafik jeung elemen data diitung. Di sisi database aya sababaraha cache pikeun pilihan dasar, contona, grafik.
Caching di sisi server Zabbix sorangan nyaéta:
- ConfigurationCache;
- ValueCache;
- HistoryCache;
- TrendsCache.
Hayu urang mikirkeun aranjeunna langkung rinci.
ConfigurationCache
Ieu mangrupikeun cache utama dimana urang nyimpen métrik, host, barang data, pemicu - sadayana anu urang peryogikeun pikeun PreProcessing sareng pikeun ngumpulkeun data.
Sadaya ieu disimpen dina ConfigurationCache supados henteu nyiptakeun patarosan anu teu perlu dina pangkalan data. Saatos server dimimitian, urang ngamutahirkeun cache ieu, nyieun tur périodik ngamutahirkeun konfigurasi.
Ngumpulkeun data
Diagram anu cukup badag, tapi hal utama di dinya kolektor. Ieu rupa-rupa "pollers" - prosés assembly. Aranjeunna tanggung jawab pikeun sababaraha jinis rakitan: aranjeunna ngumpulkeun data ngalangkungan SNMP, IPMI, sareng mindahkeun sadayana ka PreProcessing.
Kolektor digariskeun dina jeruk.
Zabbix geus ngitung item aggregation nu diperlukeun pikeun agrégat cék. Upami urang gaduh aranjeunna, urang nyandak data pikeun aranjeunna langsung tina ValueCache.
PreProcessing HistoryCache
Sadaya kolektor nganggo ConfigurationCache pikeun nampi padamelan. Teras aranjeunna mindahkeun kana PreProcessing.
PreProcessing ngagunakeun ConfigurationCache pikeun nampa léngkah PreProcessing. Éta ngolah data ieu ku sababaraha cara.
Saatos ngolah data nganggo PreProcessing, urang simpen dina HistoryCache pikeun diolah. Ieu mungkas pangumpulan data sareng urang teraskeun kana prosés utama di Zabbix - sinkronisasi sajarah, Kusabab éta arsitéktur monolithic.
Catetan: PreProcessing mangrupikeun operasi anu sesah. Kalawan v 4.2 eta geus dipindahkeun ka proxy. Upami Anjeun gaduh Zabbix kacida gedéna jeung sajumlah badag elemen data jeung frékuénsi ngumpulkeun, mangka ieu ngajadikeun karya loba gampang.
ValueCache, sajarah & tren cache
Sinkronisasi sajarah nyaéta prosés utama anu sacara atom ngolah unggal unsur data, nyaéta, unggal nilai.
Sinkronisasi sajarah nyandak nilai tina HistoryCache sareng pariksa Konfigurasi pikeun ayana pemicu pikeun itungan. Upami aranjeunna aya, éta ngitung.
Sinkronisasi sajarah nyiptakeun hiji acara, escalation pikeun nyieun ngabejaan lamun diperlukeun ku konfigurasi, sarta rékaman. Upami aya pemicu pikeun ngolah saterasna, teras nyimpen nilai ieu dina ValueCache supados henteu ngaksés tabel sajarah. Ieu kumaha ValueCache ngeusi data anu diperlukeun pikeun ngitung pemicu jeung elemen diitung.
Sinkronisasi sajarah nyerat sadaya data kana pangkalan data, sareng nyerat kana disk. Prosés ngolah ends dieu.
Caching dina pangkalan data
Di sisi pangkalan data aya rupa-rupa caches nalika anjeun hoyong ningali grafik atanapi laporan ngeunaan acara:
Innodb_buffer_pooldina sisi MySQL;shared_buffersdina sisi PostgreSQL;effective_cache_sizedi sisi Oracle;shared_pooldi sisi DB2.
Aya seueur cache anu sanés, tapi ieu mangrupikeun anu utama pikeun sadaya pangkalan data. Aranjeunna ngidinan Anjeun pikeun nyimpen data dina RAM anu mindeng diperlukeun pikeun queries. Aranjeunna gaduh téknologi sorangan pikeun ieu.
Kinerja database penting pisan
Server Zabbix terus-terusan ngumpulkeun data sareng nyeratna. Nalika di-restart, éta ogé maca tina sajarah pikeun ngeusian ValueCache. Ngagunakeun naskah jeung laporan Zabbix API, nu diwangun dina panganteur Web. Zabbix API ngakses database jeung retrieves data diperlukeun pikeun grafik, laporan, daptar acara jeung isu panganyarna.
Pikeun visualisasi - grafana. Ieu mangrupikeun solusi anu populer di kalangan pangguna urang. Bisa langsung ngirim requests ngaliwatan API Zabbix jeung database, sarta nyiptakeun kompetisi tangtu pikeun data narima. Ku alatan éta, finer tur hadé tuning tina database diperlukeun pikeun cocog pangiriman gancang hasil na nguji.
pembantu rumah tangga
Tantangan kinerja katilu di Zabbix nyaéta ngabersihan sajarah nganggo Housekeeper. Éta nuturkeun sadaya setélan - unsur data nunjukkeun sabaraha lami pikeun nyimpen dinamika parobahan (tren) dina sababaraha dinten.
Urang ngitung TrendsCache on laleur. Nalika data sumping, urang agrégat salami sajam sareng ngarékam dina tabel pikeun dinamika parobahan tren.
Housekeeper ngamimitian sareng mupus inpormasi tina pangkalan data nganggo "milih" biasa. Ieu teu salawasna éféktif, sakumaha bisa ditempo ti grafik kinerja prosés internal.
Grafik beureum nunjukeun yen sinkronisasi Sajarah terus sibuk. Grafik jeruk di luhur nyaéta Housekeeper, anu terus dijalankeun. Anjeunna ngantosan pangkalan data ngahapus sadaya baris anu anjeunna ditangtukeun.
Nalika anjeun kedah nganonaktipkeun Housekeeper? Salaku conto, aya "Item ID" sareng anjeun kedah ngahapus 5 rébu baris terakhir dina waktos anu tangtu. Tangtu, ieu kajadian ku indéks. Tapi biasana dataset pisan badag, sarta database masih maca tina disk jeung nempatkeun kana cache nu. Ieu salawasna operasi pisan mahal pikeun database na, gumantung kana ukuran database, bisa ngakibatkeun masalah kinerja.
Housekeeper gampang mareuman. Dina panganteur Web aya setelan dina "Administrasi umum" pikeun Housekeeper. Urang nganonaktipkeun Housekeeping internal pikeun sajarah trend internal tur eta euweuh manages eta.
Housekeeper dipareuman, grafik ditujukeun - naon masalah anu aya dina hal ieu sareng naon anu tiasa ngabantosan tangtangan kinerja katilu?
Partitioning - partitioning atanapi partitioning
Biasana, partisi dikonpigurasi dina cara anu béda dina unggal database relasional anu ku kuring didaptarkeun. Masing-masing gaduh téknologi sorangan, tapi sacara umum sami. Nyiptakeun partisi énggal sering nyababkeun sababaraha masalah.
Biasana, partisi dikonpigurasi gumantung kana "setup" - jumlah data anu didamel dina hiji dinten. Sakumaha aturan, Partitioning dikaluarkeun dina hiji poé, ieu téh minimum. Pikeun tren bets anyar - 1 bulan.
Nilaina tiasa robih upami "setelan" ageung pisan. Upami "setelan" leutik dugi ka 5 nvps (nilai énggal per detik), anu sedeng tina 000 dugi ka 5, teras anu ageung langkung luhur 000 nvps. Ieu mangrupikeun pamasangan anu ageung sareng ageung anu peryogi konfigurasi ati-ati database.
Dina pamasangan anu ageung pisan, waktos sadinten tiasa henteu optimal. Kuring geus katempo partisi MySQL 40 GB atawa leuwih per poé. Ieu mangrupikeun jumlah data anu ageung pisan anu tiasa nyababkeun masalah sareng kedah dikirangan.
Naon anu masihan Partitioning?
Méja partisi. Seringna ieu mangrupikeun file anu misah dina disk. Rencana pamundut milih hiji partisi langkung optimal. Biasana partisi dianggo ku rentang - ieu ogé leres pikeun Zabbix. Kami nganggo "timestamp" di dinya - waktos ti mimiti jaman. Ieu mangrupikeun nomer biasa pikeun urang. Anjeun nyetél awal sareng akhir dinten - ieu mangrupikeun partisi.
Panyabutan gancang - DELETE. Hiji file/subtable dipilih, tinimbang pilihan baris pikeun ngahapus.
Nyata nyepetkeun dimeunangkeun data SELECT - ngagunakeun hiji atawa leuwih partitions, tinimbang sakabéh méja. Upami anjeun ngaksés data anu umurna dua dinten, éta dicandak tina pangkalan data langkung gancang sabab anjeun ngan ukur kedah ngamuat hiji file kana cache sareng uih deui, sanés méja ageung.
Mindeng loba database ogé gancangan INSERT - insertions kana méja anak.
TimescaleDB
Pikeun v 4.2, urang ngalihkeun perhatian ka TimescaleDB. Ieu mangrupikeun ekstensi pikeun PostgreSQL kalayan antarmuka asli. Extension tiasa dianggo sacara efektif sareng data séri waktos, tanpa kaleungitan kauntungan tina database relasional. TimescaleDB ogé partisi sacara otomatis.
TimescaleDB gaduh konsép hypertable (hypertable) nu Anjeun jieun. Ieu ngandung sakumpulan - partitions. Potongan sacara otomatis diurus fragmen hypertable anu henteu mangaruhan fragmen anu sanés. Unggal chunk boga rentang waktu sorangan.
TimescaleDB vs PostgreSQL
TimescaleDB jalanna éfisién pisan. Pabrikan ekstensi ngaku yén aranjeunna ngagunakeun algoritma pamrosésan pamundut anu langkung leres, khususna inserts . Salaku ukuran sisipan dataset tumuwuh, algoritma mertahankeun kinerja konstan.
Saatos 200 juta jajar, PostgreSQL biasana mimiti sag sacara signifikan sareng kaleungitan kinerja ka 0. TimescaleDB ngamungkinkeun anjeun sacara éfisién nyelapkeun "sisipan" kanggo jumlah data naon waé.
setting
Masang TimescaleDB cukup gampang pikeun pakét naon waé. DI sadayana dijelaskeun sacara rinci - éta gumantung kana pakét PostgreSQL resmi. TimescaleDB ogé tiasa diwangun sareng disusun sacara manual.
Pikeun pangkalan data Zabbix kami ngan ukur ngaktipkeun ekstensi:
echo "CREATE EXTENSION IF NOT EXISTS timescaledb CASCADE;" | sudo -u postgres psql zabbix
Anjeun ngaktipkeun extension tur jieun eta pikeun database Zabbix. Lengkah panungtungan nyaéta nyieun hypertable a.
Migrasi tabel sajarah ka TimescaleDB
Aya fungsi husus pikeun ieu 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
Fungsina ngagaduhan tilu parameter. kahiji- tabél dina database, nu Anjeun kudu nyieun hypertable a. Kadua- sawah, nurutkeun nu kudu nyieun chunk_time_interval - interval sakumpulan partisi anu dianggo. Dina hal kuring, interval hiji poé - 86.
Parameter katilu - migrate_data. Upami anjeun nyetél true, teras sadaya data ayeuna ditransferkeun ka sakumpulan anu tos didamel. Kuring dipaké sorangan migrate_data. Kuring kungsi ngeunaan 1 TB, nu nyandak leuwih sajam. Malahan dina sababaraha kasus, nalika nguji, kuring ngahapus data sajarah ngeunaan jinis karakter anu henteu diperyogikeun pikeun neundeun, ku kituna henteu nransperkeunana.
Léngkah terakhir- UPDATE: at db_extension nempatkeun timescaledbsupados pangkalan data ngartos yén ekstensi ieu aya. Zabbix ngaktifkeunana sareng leres ngagunakeun sintaksis sareng patarosan kana pangkalan data - fitur-fitur anu dipikabutuh pikeun TimescaleDB.
Konfigurasi hardware
Kuring dipaké dua server. kahiji- mesin VMware. Ieu rada leutik: 20 Intel® Xeon® CPU E5-2630 v 4 @ 2.20GHz prosesor, 16 GB RAM sarta 200 GB SSD.
Kuring dipasang PostgreSQL 10.8 di dinya sareng Debian 10.8-1.pgdg90 + 1 OS sareng sistem file xfs. Kuring ngonpigurasi sagalana minimally ngagunakeun database husus ieu, dikurangan naon Zabbix sorangan bakal ngagunakeun.
Dina mesin sarua aya server Zabbix, PostgreSQL na agén beban. Kuring kungsi 50 agén aktip anu ngagunakeun LoadableModulepikeun gancang pisan ngahasilkeun hasil béda: angka, string. Kuring ngeusian database ku loba data.
Mimitina konfigurasi ngandung 5 unsur data per host. Ampir unggal unsur ngandung pemicu sangkan eta sarupa pamasangan nyata. Dina sababaraha kasus aya leuwih ti hiji pemicu. Pikeun hiji titik jaringan aya 3-000 micu.
Interval Update Item Data − 4-7 detik. Kuring ngatur beban sorangan ku ngagunakeun teu ukur 50 agén, tapi nambahkeun leuwih. Ogé, ngagunakeun elemen data, abdi dinamis disaluyukeun beban sarta ngurangan interval update ka 4 s.
PostgreSQL. 35 nvps
Mimiti kuring ngajalankeun hardware ieu dina PostgreSQL murni - 35 rébu nilai per detik. Sakumaha anjeun tiasa tingali, inserting data nyokot fraksi sadetik - sagalana alus tur gancang. Hiji-hijina hal éta 200 GB SSD disk ngeusi up gancang.
Ieu mangrupikeun dasbor kinerja server Zabbix standar.
Grafik biru kahiji nyaéta jumlah nilai per detik. Grafik kadua di katuhu nyaéta ngamuat prosés ngawangun. Anu katilu nyaéta ngamuat prosés ngawangun internal: panyingkronan sajarah sareng Housekeeper, anu parantos dijalankeun di dieu pikeun sababaraha waktos.
Grafik kaopat nunjukkeun panggunaan HistoryCache. Ieu mangrupikeun jinis panyangga sateuacan ngalebetkeun kana pangkalan data. Grafik kalima héjo nunjukkeun pamakean ValueCache, nyaéta, sabaraha ValueCache hits pikeun pemicu - ieu sababaraha rébu nilai per detik.
PostgreSQL. 50 nvps
Teras kuring ningkatkeun beban kana 50 rébu nilai per detik dina hardware anu sami.
Nalika ngamuat ti Housekeeper, ngalebetkeun 10 rébu nilai butuh 2-3 detik.
Ibu rumah tangga geus mimiti ngaganggu gawé.
Grafik katilu nunjukeun yen, sacara umum, beban on trappers na synchers sajarah masih di 60%. Dina grafik kaopat, HistoryCache geus dimimitian ngeusian rada aktip salila operasi Housekeeper. Ieu 20% pinuh, nu ngeunaan 0,5 GB.
PostgreSQL. 80 nvps
Teras kuring ningkatkeun beban ka 80 rébu nilai per detik. Ieu kirang langkung 400 rébu unsur data sareng 280 rébu pemicu.
Biaya loading tilu puluh sajarah synchers geus rada luhur.
Kuring ogé ngaronjat rupa parameter: sinkronisasi sajarah, caches.
Dina hardware abdi, loading of syncers sajarah ngaronjat ka maksimum. HistoryCache gancang ngeusi data - data pikeun ngolah geus akumulasi dina panyangga.
Sadaya waktos ieu kuring ningali kumaha prosesor, RAM sareng parameter sistem anu sanés dianggo, sareng mendakan yén pamakean disk éta maksimal.
Kuring geus ngahontal pamakéan kamampuhan disk maksimum dina hardware ieu sareng dina mesin virtual ieu. Kalayan inténsitas sapertos kitu, PostgreSQL mimiti nyéépkeun data sacara aktip, sareng disk henteu gaduh waktos nyerat sareng maca.
Server kadua
Kuring nyokot server sejen, nu geus miboga 48 processor na 128 GB RAM. Kuring nyetél éta - disetel ka 60 sajarah sinkronisasi, sarta ngahontal kinerja ditarima.
Nyatana, ieu mangrupikeun wates produktivitas dimana aya anu kedah dilakukeun.
TimescaleDB. 80 nvps
Tugas utama kuring nyaéta pikeun nguji kamampuan TimescaleDB ngalawan beban Zabbix. 80 rébu nilai per detik téh loba, frékuénsi ngumpulkeun metrics (iwal Yandex, tangtosna) jeung cukup badag "setup".
Aya dip dina unggal grafik - ieu persis migrasi data. Saatos gagal dina server Zabbix, profil loading tina sinkronisasi sajarah robah pisan - turun tilu kali.
TimescaleDB ngidinan Anjeun pikeun nyelapkeun data ampir 3 kali leuwih gancang sarta ngagunakeun kirang HistoryCache.
Sasuai, anjeun bakal nampa data dina ragam timely.
TimescaleDB. 120 nvps
Teras kuring ningkatkeun jumlah elemen data ka 500 rébu. Tugas utama nyaéta pikeun nguji kamampuan TimescaleDB - kuring nampi nilai diitung tina 125 rébu nilai per detik.
Ieu mangrupikeun "setelan" anu tiasa dianggo pikeun waktos anu lami. Tapi kusabab disk kuring ngan ukur 1,5 TB, kuring ngeusian dina sababaraha dinten.
Anu paling penting nyaéta dina waktos anu sami partisi TimescaleDB énggal diciptakeun.
Ieu sagemblengna unnoticeable pikeun kinerja. Nalika partisi didamel dina MySQL, contona, sadayana béda. Ieu biasana lumangsung peuting sabab blok sisipan umum, gawé bareng tabel sarta bisa nyieun degradasi jasa. Ieu sanés kasus sareng TimescaleDB.
Salaku conto, kuring bakal nunjukkeun hiji grafik tina seueur komunitas. Dina gambar, TimescaleDB diaktipkeun, hatur nuhun anu beban dina ngagunakeun io.weight on processor geus turun. Pamakéan unsur prosés internal ogé turun. Sumawona, ieu mangrupikeun mesin virtual biasa dina piringan pancake biasa, sanés SSD.
papanggihan
TimescaleDB mangrupikeun solusi anu saé pikeun "setup" leutik, anu mangaruhan kinerja disk. Ieu bakal ngidinan Anjeun pikeun neruskeun gawé ogé nepi ka database ieu hijrah ka hardware gancang-gancang.
TimescaleDB gampang pikeun ngonpigurasikeun, méré gains kinerja, jalan ogé kalawan Zabbix na boga kaunggulan leuwih PostgreSQL.
Upami anjeun nganggo PostgreSQL sareng henteu ngarencanakeun ngarobih, kuring nyarankeun anggo PostgreSQL sareng ekstensi TimescaleDB ditéang sareng Zabbix. Solusi ieu tiasa dianggo sacara efektif dugi ka "setup" sedeng.
Lamun urang nyebutkeun "kinerja tinggi" kami hartosna . Anjeun moal lila ngadagoan pikeun diajar ngeunaan téknologi sareng prakték anu ngamungkinkeun jasa pikeun ngalayanan jutaan pangguna. Daptar pikeun Nopémber 7 jeung 8 kami geus disusun, tapi di dieu leuwih bisa nyarankeun.
Ngalanggan kami и , di mana urang ngungkabkeun fitur-fitur konperénsi anu bakal datang, sareng milari kumaha cara maksimalkeunana.
sumber: www.habr.com