Zabbix estas monitora sistemo. Kiel ĉiu alia sistemo, ĝi alfrontas tri ĉefajn problemojn de ĉiuj monitoraj sistemoj: kolektado kaj prilaborado de datumoj, stokado de historio kaj purigado de ĝi.
La stadioj de ricevado, prilaborado kaj registrado de datumoj prenas tempon. Ne multe, sed por granda sistemo, tio povas rezultigi grandajn malfruojn. La stokadproblemo estas demando pri datuma aliro. Ili estas uzataj por raportoj, kontroloj kaj ellasiloj. Prokrastoj de aliro al datumoj ankaŭ influas rendimenton. Kiam la datumbazo kreskas, sensignifaj datumoj devas esti forigitaj. Forigo estas peza operacio, kiu ankaŭ manĝas kelkajn rimedojn.
Kolekto kaj konservado prokrasto problemoj en Zabbix estas solvitaj per kaŝmemoro: pluraj specoj de kaŝmemoroj, kaŝmemoro en la datumbazo. Por solvi la trian problemon, kaŝmemoro ne taŭgas, do TimescaleDB estis uzata en Zabbix. Rakontos pri ĝi Andrej Guŝĉin - teknika subtena inĝeniero . Andrey apogas Zabbix dum pli ol 6 jaroj kaj rekte okupiĝas pri agado.
Kiel funkcias TimescaleDB, kian rendimenton ĝi povas doni kompare kun regula PostgreSQL? Kian rolon ludas Zabbix en TimescaleDB? Kiel komenci de nulo kaj kiel migri de PostgreSQL kaj kiu agorda efikeco estas pli bona? Ĉio ĉi sub la tranĉo.
Efikecdefioj
Ĉiu monitora sistemo alfrontas certajn rendimentajn defiojn. Mi parolos pri tri el ili: datumkolektado kaj prilaborado, konservado, historia purigado.
Rapida kolekto kaj prilaborado de datumoj. Bona monitora sistemo devus rapide ricevi ĉiujn datumojn kaj prilabori ĝin laŭ ellasaj esprimoj - laŭ siaj propraj kriterioj. Post prilaborado, la sistemo devas ankaŭ rapide konservi ĉi tiujn datumojn en la datumbazo por uzi ĝin poste.
Stokado de historio. Bona monitora sistemo devus stoki historion en datumbazo kaj disponigi facilan aliron al metrikoj. La historio necesas por esti uzata en raportoj, grafikaĵoj, ellasiloj, sojloj kaj kalkulitaj atentaj eroj.
Purigante historion. Kelkfoje venas tago, kiam vi ne bezonas stoki metrikojn. Kial vi bezonas datumojn, kiuj estis kolektitaj antaŭ 5 jaroj, unu aŭ du monatoj: iuj nodoj estis forigitaj, iuj gastigantoj aŭ metrikoj ne plu bezonas, ĉar ili estas malmodernaj kaj ne plu kolektitaj. Bona monitora sistemo devus stoki historiajn datumojn kaj forigi ĝin de tempo al tempo por ke la datumbazo ne kresku.
Purigado de malfreŝaj datumoj estas dorna afero, kiu havas grandan efikon al datumbaza rendimento.
Kaŝmemoro en Zabbix
En Zabbix, la unua kaj dua vokoj estas solvitaj uzante kaŝmemoron. RAM estas uzata por kolekti kaj prilabori datumojn. Por stokado - historio en ellasiloj, grafikaĵoj kaj kalkulitaj eroj. Sur la DB-flanko, ekzistas iu kaŝmemoro por bazaj elektoj, kiel grafikaĵoj.
Kaŝmemoro flanke de la Zabbix-servilo mem estas:
- ConfigurationCache;
- ValueCache;
- HistoryCache;
- TrendsCache.
Ni konsideru ilin pli detale.
ConfigurationCache
Ĉi tiu estas la ĉefa kaŝmemoro, en kiu ni stokas metrikojn, gastigantojn, datumojn, ellasilon - ĉion, kio necesas por Antaŭprocesado kaj por datumkolektado.
Ĉio ĉi estas konservita en la ConfigurationCache por ne krei nenecesajn demandojn en la datumbazo. Post kiam la servilo komenciĝas, ni ĝisdatigas ĉi tiun kaŝmemoron, kreas kaj periode ĝisdatigas agordojn.
Kolekto de datumoj
La skemo estas sufiĉe granda, sed la ĉefa afero en ĝi estas kolektantoj. Temas pri diversaj "pollers" - kunigprocezoj. Ili respondecas pri malsamaj specoj de kunigo: ili kolektas datumojn per SNMP, IPMI, kaj transdonas ĉion al Preprocessing.
Elektiloj estas ronde oranĝe.
Zabbix komputis agregajn erojn kiuj estas bezonataj por agregi ĉekojn. Se ni havas ilin, ni prenas la datumojn por ili rekte de la ValueCache.
Antaŭprocesanta Historikaŝmemoro
Ĉiuj kolektantoj uzas la ConfigurationCache por ricevi laborpostenojn. Poste ili transdonas ilin al Antaŭprocesado.
Preprocessing uzas ConfigurationCache por akiri Preprocessing paŝojn. Ĝi prilaboras ĉi tiujn datumojn en diversaj manieroj.
Post prilaborado de la datumoj per Preprocessing, ni konservas ĝin en la HistoryCache por prilabori ĝin. Ĉi tio kompletigas la datumkolektadon kaj ni pluiras al la ĉefa procezo en Zabbix - historia sinkronilo, ĉar ĝi estas monolita arkitekturo.
Noto: Antaŭprocesado estas sufiĉe peza operacio. Ekde v 4.2 ĝi estis movita al prokurilo. Se vi havas tre grandan Zabbix kun granda nombro da eroj kaj kolektofrekvenco, tiam ĉi tio multe pli facilas.
ValueCache, historio kaj tendencoj kaŝmemoro
History syncer estas la ĉefa procezo, kiu atome prilaboras ĉiun datenelementon, tio estas, ĉiun valoron.
Historia sinkronilo prenas valorojn de HistoryCache kaj kontrolas Agordon por ellasiloj por kalkuloj. Se ili estas - kalkulas.
Historia sinkronilo kreas eventon, eskaladas por krei atentigojn se postulite de agordo kaj registras. Se estas ellasiloj por plia prilaborado, tiam ĝi memoras ĉi tiun valoron en ValueCache por ne rilati al la historia tabelo. Jen kiel la ValueCache estas plenigita kun la datumoj necesaj por kalkuli ellasilon, kalkulitajn erojn.
History syncer skribas ĉiujn datumojn al la datumbazo, kaj ĝi skribas al disko. La pretiga procezo finiĝas ĉi tie.
DB kaŝmemoro
Estas diversaj kaŝmemoroj ĉe la DB-flanko kiam vi volas rigardi grafikaĵojn aŭ raportojn pri eventoj:
Innodb_buffer_poolsur la MySQL-flanko;shared_buffersĉe la flanko de PostgreSQL;effective_cache_sizesur la Orakolo-flanko;shared_poolsur la DB2-flanko.
Estas multaj aliaj kaŝmemoroj, sed ĉi tiuj estas la ĉefaj por ĉiuj datumbazoj. Ili permesas vin konservi datumojn en RAM, kiuj ofte bezonas por demandoj. Ili havas sian propran teknologion por tio.
Datumbaza rendimento estas kritika
Zabbix-servilo konstante kolektas datumojn kaj skribas ĝin. Kiam rekomencita, ĝi ankaŭ legas el la historio por plenigi la ValueCache. Skriptoj kaj raportoj uzoj Zabbix API, kiu estas konstruita surbaze de la Reta interfaco. La Zabbix API aliras la datumbazon kaj prenas la necesajn datumojn por grafikaĵoj, raportoj, okazaĵlistoj kaj lastatempaj temoj.
Por bildigo - grafana. Ĉi tio estas populara solvo inter niaj uzantoj. Ŝi povas rekte sendi petojn per la Zabbix API kaj al la datumbazo, kaj kreas certan samtempecon por akiri datumojn. Tial, pli bona kaj pli bona datumbaza agordado estas necesa por egali la rapidan liveron de rezultoj kaj testado.
dommastrino
La tria agado-defio en Zabbix estas purigado de historio kun Domzorgisto. Ĝi respektas ĉiujn agordojn - la datumelementoj indikas kiom longe konservi la dinamikon de ŝanĝoj (tendencoj) en tagoj.
TrendsCache ni kalkulas sur la muŝo. Kiam la datumoj eniras, ni agregas ĝin en unu horo kaj metas ĝin en tabelojn por la dinamiko de tendencaj ŝanĝoj.
Domzorgisto komencas kaj forigas informojn el la datumbazo per la kutimaj "elektoj". Ĉi tio ne ĉiam estas efika, kio povas esti komprenita de la agadografoj de internaj procezoj.
La ruĝa grafikaĵo montras, ke la Historia sinkronilo estas konstante okupata. La oranĝa diagramo ĉe la supro estas Housekeeper, kiu konstante funkcias. Ĝi atendas ke la datumbazo forigu ĉiujn vicojn kiujn ĝi specifis.
Kiam vi malebligu Dommastruiston? Ekzemple, ekzistas "Identigilo" kaj vi devas forigi la lastajn 5 mil liniojn en certa tempo. Kompreneble, ĉi tio okazas per indeksoj. Sed kutime la datumaro estas tre granda, kaj la datumbazo ankoraŭ legas el la disko kaj metas ĝin en la kaŝmemoron. Ĉi tio ĉiam estas tre multekosta operacio por la datumbazo kaj, depende de la grandeco de la datumbazo, povas konduki al rendimentoproblemoj.
Domservisto estas simple malŝaltebla. En la Reta interfaco, estas agordo en "Ĝenerala Administracio" por Domservisto. Malebligu internan mastrumadon por interna tendenca historio kaj ĝi ne plu kontrolas ĉi tion.
Domservisto estas malfunkciigita, grafikaĵoj ebeniĝis - kio povus esti la problemoj en ĉi tiu kazo kaj kio povas helpi solvi la trian agadon defio?
Partitioning - dispartigo aŭ dispartigo
Dispartigo estas kutime agordita alimaniere sur ĉiu rilata datumbazo, kiun mi listigis. Ĉiu havas sian propran teknologion, sed ili ĝenerale similas. Krei novan sekcion ofte kondukas al certaj problemoj.
Tipe, sekcioj estas agorditaj depende de la "agordo" - la kvanto de datumoj kreitaj en unu tago. Kiel regulo, Dispartigo estas starigita en unu tago, ĉi tio estas la minimumo. Por novaj dispartigaj tendencoj - 1 monato.
La valoroj povas ŝanĝiĝi en la kazo de tre granda "agordo". Se malgranda "agordo" estas ĝis 5 nvps (novaj valoroj por sekundo), averaĝa estas de 000 ĝis 5, tiam granda estas super 000 nvps. Ĉi tiuj estas grandaj kaj tre grandaj instalaĵoj, kiuj postulas zorgan agordon de la datumbazo mem.
Sur tre grandaj instalaĵoj, unu tago eble ne estas optimuma. Mi vidis MySQL-diskojn de 40 GB aŭ pli tage. Ĉi tio estas tre granda kvanto da datumoj, kiuj povas konduki al problemoj kaj devus esti reduktitaj.
Kio donas Partition?
Dispartigaj tabloj. Ofte ĉi tiuj estas apartaj dosieroj sur disko. La demandplano elektas unu sekcion pli optimume. Kutime dispartigo estas uzata per intervalo - tio validas ankaŭ por Zabbix. Ni uzas tie "timestamp" - la tempo ekde la komenco de la epoko. Ni havas regulajn nombrojn. Vi fiksas la komencon kaj finon de la tago - ĉi tio estas sekcio.
Rapida forigo - DELETE. Unu dosiero/subtabelo estas elektita, ne elekto de vicoj por forigo.
Signife akcelas datuman specimenigon SELECT - uzas unu aŭ plurajn sekciojn, ne la tutan tabelon. Se vi aliras du tagojn malnovajn datumojn, ĝi prenas ĝin el la datumbazo pli rapide ĉar vi nur devas ŝargi ĝin en la kaŝmemoron kaj redoni nur unu dosieron, ne grandan tabelon.
Ofte multaj datumbazoj ankaŭ plirapidiĝas INSERT - enmetas en la infanan tablon.
TimecaleDB
Por v 4.2 ni turnis nian atenton al TimescaleDB. Ĉi tio estas PostgreSQL-etendo kun denaska interfaco. La etendaĵo funkcias efike kun temposeriodatenoj sen perdi la avantaĝojn de interrilataj datumbazoj. TimescaleDB ankaŭ aŭtomate dispartigas.
TimescaleDB havas koncepton hipertablo (hipertable) kiun vi kreas. En ĝi estas pecoj - vandoj. Pecoj estas aŭtomate administritaj fragmentoj de hipertablo, kiuj ne influas aliajn fragmentojn. Ĉiu peco havas sian propran tempon.
TimescaleDB kontraŭ PostgreSQL
TimescaleDB estas vere efika. La produktantoj de la etendaĵo asertas, ke ili uzas pli ĝustan demandopretigan algoritmon, precipe, inserts . Ĉar la grandeco de la datumarenigaĵo kreskas, la algoritmo konservas konstantan efikecon.
Post 200 milionoj da vicoj, PostgreSQL kutime komencas multe mallaŭdi kaj perdi rendimenton al 0. TimescaleDB permesas vin efike enmeti "enigaĵojn" kun ajna kvanto da datumoj.
fikso
Instali TimescaleDB estas sufiĉe facila por iuj pakaĵoj. EN ĉio estas detala - ĝi dependas de la oficialaj pakoj de PostgreSQL. TimescaleDB ankaŭ povas esti konstruita kaj kompilita mane.
Por la datumbazo Zabbix, ni simple aktivigas la etendon:
echo "CREATE EXTENSION IF NOT EXISTS timescaledb CASCADE;" | sudo -u postgres psql zabbix
vi aktivigas extension kaj kreu ĝin por la datumbazo Zabbix. La lasta paŝo estas krei hipertabelon.
Migrado historiaj tabeloj al TimescaleDB
Estas speciala funkcio por ĉi tio. 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
La funkcio havas tri parametrojn. Unue - tabelo en datumbazoLa por kiu vi volas krei hipertabelon. Due - kampo, laŭ kiu necesas krei chunk_time_interval — intervalo de dispartigaj pecoj uzotaj. En mia kazo, la intervalo estas unu tago - 86.
La tria parametro estas migrate_data. Se agordita true, tiam ĉiuj aktualaj datumoj estas transdonitaj al antaŭkreitaj pecoj. Mi mem uzis migrate_data. Mi havis ĉirkaŭ 1TB, kiu daŭris pli ol unu horon. Eĉ en iuj kazoj, dum testado, mi forigis la historiajn datumojn de karakteroj, kiuj estas laŭvolaj por stokado, por ne transdoni ilin.
Lasta paŝo - UPDATE: en db_extension meti timescaledbpor ke la datumbazo komprenu, ke ekzistas ĉi tiu etendo. Zabbix aktivigas ĝin kaj ĝuste uzas la sintakson kaj demandojn jam al la datumbazo - tiuj funkcioj kiuj estas necesaj por TimescaleDB.
Aparataro agordo
Mi uzis du servilojn. Unue - VMware-maŝino. Ĝi estas sufiĉe malgranda: 20 Intel® Xeon® CPU E5-2630 v 4 @ 2.20GHz, 16 GB da RAM kaj 200 GB SSD-disko.
Mi instalis PostgreSQL 10.8 sur ĝi kun Debian OS 10.8-1.pgdg90+1 kaj xfs-dosiersistemo. Mi agordis ĉion minimume por uzi ĉi tiun apartan datumbazon, minus kion Zabbix mem uzos.
Sur la sama maŝino estis Zabbix-servilo, PostgreSQL kaj ŝarĝaj agentoj. Mi havis 50 aktivajn agentojn kiuj uzis LoadableModulepor generi diversajn rezultojn tre rapide: nombroj, ŝnuroj. Mi plenigis la datumbazon per multaj datumoj.
Komence, la agordo enhavis 5 eroj datumoj per gastiganto. Preskaŭ ĉiu elemento enhavis ellasilon por ke ĝi aspektu kiel realaj instalaĵoj. En kelkaj kazoj estis pli ol unu ellasilo. Unu reto nodo havis 3-000 ellasiloj.
Intervalo de ĝisdatigo de ero − 4-7 sekundoj. Mi reguligis la ŝarĝon mem uzante ne nur 50 agentojn, sed aldonante pliajn. Ankaŭ, helpe de datumoj elementoj, mi dinamike reguligis la ŝarĝon kaj reduktis la ĝisdatigan intervalon al 4 s.
PostgreSQL. 35 nvps
Mia unua funkciado sur ĉi tiu aparataro estis sur pura PostgreSQL - 35 mil valoroj por sekundo. Kiel vi povas vidi, enmeti datumojn prenas frakciojn de sekundo - ĉio estas bona kaj rapida. La nura afero estas, ke la 200 GB SSD-disko pleniĝas rapide.
Ĉi tio estas norma Zabbix-servila rendimentopanelo.
La unua blua grafikaĵo estas la nombro da valoroj por sekundo. La dua grafikaĵo dekstre ŝarĝas konstruprocezojn. La tria estas la ŝarĝo de internaj konstruprocezoj: historiaj sinkroniloj kaj Housekeeper, kiu funkcias dum sufiĉe da tempo ĉi tie.
La kvara grafikaĵo montras la uzon de HistoryCache. Ĉi tio estas speco de bufro antaŭ ol enmeti en la datumbazon. La verda kvina grafiko montras la uzadon de ValueCache, tio estas, kiom da ValueCache-trafoj por ellasiloj estas pluraj miloj da valoroj por sekundo.
PostgreSQL. 50 nvps
Tiam mi pliigis la ŝarĝon al 50 mil valoroj por sekundo sur la sama aparataro.
Ŝargante de Domservisto, enmeti 10 mil valorojn daŭris 2-3 sekundojn.
Domservistino jam komencas enmiksiĝi.
La tria grafikaĵo montras, ke ĝenerale, la ŝarĝo de ĉasistoj kaj historiaj sinkroniloj ankoraŭ estas je la nivelo de 60%. Sur la kvara grafikaĵo, la HistoryCache dum la funkciado de Housekeeper jam sufiĉe aktive komencas pleniĝi. Ĝi estas 20% plena - ĉirkaŭ 0,5 GB.
PostgreSQL. 80 nvps
Tiam mi pliigis la ŝarĝon al 80 mil valoroj por sekundo. Ĉi tio estas proksimume 400 mil datumelementoj kaj 280 mil ellasiloj.
La ŝarĝa enmetaĵo de tridek historiaj sinkroniloj jam estas sufiĉe alta.
Mi ankaŭ pliigis diversajn parametrojn: historiaj sinkroniloj, kaŝmemoroj.
Sur mia aparataro, la ŝarĝo de historiaj sinkroniloj pliiĝis al la maksimumo. HistoryCache rapide pleniĝis kun datumoj - la bufro amasigis datumojn por prilaborado.
Dum ĉi tiu tempo, mi rigardis kiel la procesoro, RAM kaj aliaj sistemaj parametroj estas uzataj, kaj trovis, ke disko-uzado estas maksimuma.
Mi uzis maksimuma diskkapacito sur ĉi tiu aparataro kaj sur ĉi tiu virtuala maŝino. Kun tia intenseco, PostgreSQL komencis forĵeti datumojn sufiĉe aktive, kaj la disko ne plu havis tempon por skribi kaj legi.
Dua servilo
Mi prenis alian servilon kiu jam havis 48 procesorojn kaj 128 GB da RAM. Mi agordis ĝin - starigis 60 historian sinkronilon, kaj atingis akcepteblan rendimenton.
Fakte, ĉi tio jam estas rendimenta limo, kie io devas esti farita.
temposkalitab. 80 nvps
Mia ĉefa tasko estas testi la kapablojn de TimescaleDB kontraŭ Zabbix-ŝarĝo. 80 mil valoroj por sekundo estas multe, la ofteco de kolektado de metrikoj (krom Yandex, kompreneble) kaj sufiĉe granda "aranĝo".
Estas trempiĝo sur ĉiu grafikaĵo - ĉi tio estas nur datuma migrado. Post la malsukcesoj en la servilo Zabbix, la ŝarĝa profilo de la historia sinkronilo multe ŝanĝiĝis - ĝi falis trifoje.
TimescaleDB permesas vin enmeti datumojn preskaŭ 3 fojojn pli rapide kaj uzi malpli HistoryCache.
Sekve, vi ricevos datumojn ĝustatempe.
temposkalitab. 120 nvps
Tiam mi pliigis la nombron da datumelementoj al 500 mil. La ĉefa tasko estis kontroli la kapablojn de TimescaleDB - mi ricevis kalkulitan valoron de 125 mil valoroj por sekundo.
Ĉi tio estas funkcianta "agordo", kiu povas daŭri longan tempon por funkcii. Sed ĉar mia disko estis nur 1,5 TB, mi plenigis ĝin post kelkaj tagoj.
Plej grave, novaj TimescaleDB-diskoj estis kreitaj samtempe.
Por agado, ĉi tio estas tute nerimarkebla. Kiam sekcioj estas kreitaj en MySQL, ekzemple, aferoj estas malsamaj. Ĉi tio kutime okazas nokte, ĉar ĝi blokas ĝeneralan enmeton, tablomanipuladon kaj povas krei degeneron de la servo. Ĉi tio ne estas la kazo kun TimescaleDB.
Ekzemple, mi montros unu grafikaĵon de la aro en komunumo. En la bildo, TimescaleDB estas ebligita, danke al kiu la ŝarĝo pri la uzo de io.weight sur la procesoro falis. La uzo de elementoj de internaj procezoj ankaŭ malpliiĝis. Krome, ĉi tio estas ordinara virtuala maŝino sur ordinaraj patkukaj diskoj, kaj ne SSD.
trovoj
TimescaleDB estas bona solvo por malgrandaj "agordoj", kiuj ripozas sur la rendimento de la disko. Ĝi permesos al vi daŭre labori bone ĝis la datumbazo estas migrita al aparataro pli rapide.
TimescaleDB estas facile instalebla, donas rendimentan akcelon, funkcias bone kun Zabbix kaj havas avantaĝojn super PostgreSQL.
Se vi uzas PostgreSQL kaj ne planas ŝanĝi ĝin, tiam mi rekomendas uzu PostgreSQL kun TimescaleDB etendo kune kun Zabbix. Ĉi tiu solvo funkcias efike ĝis meza "aranĝo".
Ni diras "alta rendimento" - ni volas diri . Ne daŭros longe antaŭ ol vi ekkonos la teknologiojn kaj praktikojn, kiuj permesas servojn servi milionojn da uzantoj. Listo por la 7-a kaj 8-a de novembro, ni jam desegnis, sed pli oni povas sugesti.
Abonu nian и , en kiu ni malkaŝas la funkciojn de la venonta konferenco, kaj ekscias kiel eltiri la plej grandan parton de ĝi.
fonto: www.habr.com