Zabbix és un sistema de monitorització. Com qualsevol altre sistema, s'enfronta a tres problemes principals de tots els sistemes de monitorització: recollir i processar dades, emmagatzemar l'historial i esborrar-lo.
Les etapes de recepció, processament i registre de dades requereixen temps. No gaire, però per a un sistema gran, això pot provocar grans retards. El problema d'emmagatzematge és una qüestió d'accés a les dades. S'utilitzen per a informes, comprovacions i activadors. Els retards en l'accés a les dades també afecten el rendiment. Quan la base de dades creix, s'han d'eliminar les dades irrellevants. La supressió és una operació pesada que també consumeix alguns recursos.
Els problemes de retard de recollida i emmagatzematge a Zabbix es resolen mitjançant la memòria cau: diversos tipus de memòria cau, la memòria cau a la base de dades. Per resoldre el tercer problema, la memòria cau no és adequada, de manera que es va utilitzar TimescaleDB a Zabbix. En parlarà Andrei Guixxin - Enginyer de suport tècnic . Andrey ha estat donant suport a Zabbix durant més de 6 anys i està directament implicat en l'actuació.
Com funciona TimescaleDB, quin rendiment pot oferir en comparació amb PostgreSQL normal? Quin paper juga Zabbix a TimescaleDB? Com començar des de zero i com migrar des de PostgreSQL i quin rendiment de configuració és millor? Tot això sota el tall.
Reptes de rendiment
Cada sistema de monitorització s'enfronta a certs reptes de rendiment. En parlaré de tres: recollida i tractament de dades, emmagatzematge, neteja de l'historial.
Recollida i tractament ràpid de dades. Un bon sistema de monitorització hauria de rebre ràpidament totes les dades i processar-les segons expressions disparadores, segons els seus propis criteris. Després del processament, el sistema també ha de desar ràpidament aquestes dades a la base de dades per poder utilitzar-les més tard.
Emmagatzematge de l'historial. Un bon sistema de monitorització hauria d'emmagatzemar l'historial en una base de dades i proporcionar un fàcil accés a les mètriques. L'historial és necessari per utilitzar-lo en informes, gràfics, activadors, llindars i elements d'alerta calculats.
Esborrar l'historial. De vegades arriba un dia en què no cal emmagatzemar mètriques. Per què necessiteu dades que es van recollir fa 5 anys, un mes o dos: s'han eliminat alguns nodes, ja no es necessiten alguns hosts o mètriques, perquè estan obsolets i ja no es recullen. Un bon sistema de seguiment hauria d'emmagatzemar dades històriques i esborrar-les de tant en tant perquè la base de dades no creixi.
La neteja de dades obsoletes és un problema espinós que té un gran impacte en el rendiment de la base de dades.
Emmagatzematge a la memòria cau a Zabbix
A Zabbix, la primera i la segona trucada es resolen mitjançant la memòria cau. La memòria RAM s'utilitza per recopilar i processar dades. Per a l'emmagatzematge: historial en activadors, gràfics i elements calculats. Al costat de la base de dades, hi ha una mica de memòria cau per a seleccions bàsiques, com ara gràfics.
La memòria cau al costat del propi servidor Zabbix és:
- ConfigurationCache;
- ValueCache;
- HistoryCache;
- TrendsCache.
Considereu-los amb més detall.
Cache de configuració
Aquesta és la memòria cau principal en la qual emmagatzemem mètriques, amfitrions, elements de dades, activadors, tot el que es necessita per al preprocessament i per a la recollida de dades.
Tot això s'emmagatzema a ConfigurationCache per no crear consultes innecessàries a la base de dades. Després que el servidor s'iniciï, actualitzem aquesta memòria cau, creem i actualitzem periòdicament les configuracions.
Recopilació de dades
L'esquema és bastant gran, però el més important és col·leccionistes. Es tracta de diversos "enquestadors": processos de muntatge. Són els responsables de diferents tipus de muntatge: recullen dades mitjançant SNMP, IPMI i les transfereixen tot a Preprocessing.
Els col·lectors estan dibuixats en taronja.
Zabbix ha calculat els elements d'agregació que són necessaris per agregar comprovacions. Si en tenim, les dades les traiem directament del ValueCache.
Caché d'historial de preprocessament
Tots els col·leccionistes utilitzen ConfigurationCache per rebre feines. Després els passen a Preprocessing.
El preprocessament utilitza ConfigurationCache per obtenir els passos del preprocessament. Tracta aquestes dades de diverses maneres.
Després de processar les dades amb PreProcessing, les desem a HistoryCache per processar-les. Això completa la recollida de dades i passem al procés principal a Zabbix: sincronitzador de la història, ja que és una arquitectura monolítica.
Nota: el preprocessament és una operació força pesada. Des de la v 4.2 s'ha mogut a un servidor intermediari. Si teniu un Zabbix molt gran amb un gran nombre d'articles i freqüència de recollida, això facilita molt les coses.
ValueCache, memòria cau d'història i tendències
History Syncer és el procés principal que processa atòmicament cada element de dades, és a dir, cada valor.
El sincronitzador d'historial pren valors de HistoryCache i comprova la configuració dels activadors per als càlculs. Si ho són - calcula.
El sincronitzador d'historial crea un esdeveniment, augmenta per crear alertes si la configuració ho requereix i registra. Si hi ha activadors per a un processament posterior, recorda aquest valor a ValueCache per no fer referència a la taula d'historial. Així és com s'omple el ValueCache amb les dades necessàries per calcular els activadors, els elements calculats.
History Syncer escriu totes les dades a la base de dades i escriu al disc. El procés de processament acaba aquí.
Emmagatzematge en memòria cau de la base de dades
Hi ha diversos cachés al costat de la base de dades quan voleu mirar gràfics o informes d'esdeveniments:
Innodb_buffer_poolal costat de MySQL;shared_buffersal costat de PostgreSQL;effective_cache_sizeal costat de l'Oracle;shared_poolal costat de DB2.
Hi ha molts altres cachés, però aquests són els principals per a totes les bases de dades. Us permeten conservar les dades a la memòria RAM que sovint es necessiten per a consultes. Tenen la seva pròpia tecnologia per a això.
El rendiment de la base de dades és fonamental
El servidor Zabbix està constantment recopilant dades i anotant-les. Quan es reinicia, també llegeix l'historial per omplir el ValueCache. Usos de scripts i informes API Zabbix, que es construeix a partir de la interfície web. L'API Zabbix accedeix a la base de dades i recupera les dades necessàries per a gràfics, informes, llistes d'esdeveniments i problemes recents.
Per a la visualització - Grafana. Aquesta és una solució popular entre els nostres usuaris. Ella sap enviar sol·licituds directament a través de l'API Zabbix i a la base de dades, i crea una certa concurrència per obtenir dades. Per tant, es necessita una millora i afinació de la base de dades per fer coincidir l'entrega ràpida de resultats i proves.
Mestressa de claus
El tercer repte d'actuació a Zabbix és netejar la història amb Housekeeper. Respecta tots els paràmetres: els elements de dades indiquen quant de temps s'han d'emmagatzemar la dinàmica dels canvis (tendències) en dies.
TrendsCache calculem sobre la marxa. Quan arriben les dades, les agreguem en una hora i les posem en taules per a la dinàmica dels canvis de tendència.
El mestressa comença i elimina la informació de la base de dades amb les "seleccions" habituals. Això no sempre és eficient, cosa que es pot entendre a partir dels gràfics de rendiment dels processos interns.
El gràfic vermell mostra que el sincronitzador d'historial està constantment ocupat. El gràfic taronja a la part superior és el mestre de cases, que funciona constantment. Espera que la base de dades esborri totes les files que ha especificat.
Quan s'ha de desactivar la mestressa? Per exemple, hi ha un "ID d'element" i heu d'eliminar les últimes 5 mil línies en un temps determinat. Per descomptat, això passa per índexs. Però normalment el conjunt de dades és molt gran i la base de dades encara llegeix des del disc i la posa a la memòria cau. Aquesta és sempre una operació molt cara per a la base de dades i, depenent de la mida de la base de dades, pot provocar problemes de rendiment.
La mestressa és fàcil de desactivar. A la interfície web, hi ha una configuració a "Administració general" per a la mestressa. Desactiveu la neteja interna per a l'historial de tendències interns i ja no ho controlarà.
S'ha desactivat la mestressa, els gràfics s'han estabilitzat: quins podrien ser els problemes en aquest cas i què pot ajudar a resoldre el tercer repte de rendiment?
Particionament - particionament o particionament
El particionament es configura normalment d'una manera diferent a cada base de dades relacional que he enumerat. Cadascun té la seva pròpia tecnologia, però són similars, en general. La creació d'una nova partició sovint comporta certs problemes.
Normalment, les particions es configuren en funció de la "configuració", la quantitat de dades que es creen en un dia. Per regla general, la partició es configura en un dia, aquest és el mínim. Per a noves tendències de partició: 1 mes.
Els valors poden canviar en el cas d'una "configuració" molt gran. Si una "configuració" petita és de fins a 5 nvps (nous valors per segon), una mitjana és de 000 a 5, llavors una de gran està per sobre de 000 nvps. Es tracta d'instal·lacions grans i molt grans que requereixen una configuració acurada de la pròpia base de dades.
En instal·lacions molt grans, un dia pot no ser òptim. He vist particions MySQL de 40 GB o més al dia. Es tracta d'una quantitat molt gran de dades que poden generar problemes i que s'han de reduir.
Què dóna la partició?
Taules de particions. Sovint, aquests són fitxers separats al disc. El pla de consultes selecciona una partició de manera més òptima. Normalment, la partició s'utilitza per rang; això també és cert per a Zabbix. Allà fem servir "marca de temps": el temps des del començament de l'època. Tenim números regulars. Definiu l'inici i el final del dia: aquesta és una partició.
Eliminació ràpida - DELETE. S'ha seleccionat un fitxer/subtaula, no una selecció de files per esborrar.
Accelera significativament el mostreig de dades SELECT - utilitza una o més particions, no tota la taula. Si accediu a dades de dos dies d'antiguitat, les obteniu de la base de dades més ràpidament perquè només les heu de carregar a la memòria cau i retornar només un fitxer, no una taula gran.
Sovint moltes bases de dades també s'acceleren INSERT - s'insereix a la taula infantil.
Escala de temps DB
Per a la v 4.2 vam dirigir la nostra atenció a TimescaleDB. Aquesta és una extensió PostgreSQL amb una interfície nativa. L'extensió funciona de manera eficient amb dades de sèries temporals sense perdre els avantatges de les bases de dades relacionals. TimescaleDB també particiona automàticament.
TimescaleDB té un concepte hipertaula (hipertable) que creeu. En ell es troben trossos - envans. Els fragments són fragments gestionats automàticament d'una hipertaula que no afecten altres fragments. Cada tros té el seu propi interval de temps.
TimescaleDB vs PostgreSQL
TimescaleDB és realment eficient. Els productors de l'extensió afirmen que utilitzen un algorisme de processament de consultes més correcte, en particular, inserts . A mesura que la mida de la inserció del conjunt de dades creix, l'algoritme manté un rendiment constant.
Després de 200 milions de files, PostgreSQL normalment comença a caure molt i a perdre rendiment fins a 0. TimescaleDB us permet inserir de manera eficient "insercions" amb qualsevol quantitat de dades.
Instal · lació
La instal·lació de TimescaleDB és prou fàcil per a qualsevol paquet. EN tot està detallat: depèn dels paquets oficials de PostgreSQL. TimescaleDB també es pot construir i compilar a mà.
Per a la base de dades Zabbix, simplement activem l'extensió:
echo "CREATE EXTENSION IF NOT EXISTS timescaledb CASCADE;" | sudo -u postgres psql zabbix
tu actives extension i creeu-lo per a la base de dades Zabbix. L'últim pas és crear una hipertaula.
Migració de taules d'historial a TimescaleDB
Hi ha una funció especial per a això. 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 funció té tres paràmetres. Primer - taula a la base de dadesEl per al qual voleu crear una hipertaula. segon - camp, segons el qual cal crear chunk_time_interval — interval de fragments de partició que s'utilitzaran. En el meu cas, l'interval és d'un dia: 86.
El tercer paràmetre és migrate_data. Si s'estableix true, llavors totes les dades actuals es transfereixen a fragments pre-creats. Jo mateix he utilitzat migrate_data. Vaig tenir aproximadament 1 TB que va trigar més d'una hora. Fins i tot en alguns casos, durant la prova, he suprimit les dades històriques dels tipus de caràcters que són opcionals per a l'emmagatzematge per no transferir-los.
Últim pas - UPDATE: dins db_extension posar timescaledbperquè la base de dades entengui que hi ha aquesta extensió. Zabbix l'activa i utilitza correctament la sintaxi i les consultes que ja estan a la base de dades, les característiques necessàries per a TimescaleDB.
Configuració de maquinari
Vaig utilitzar dos servidors. Primer - màquina VMware. És prou petit: 20 CPU Intel® Xeon® E5-2630 v 4 a 2.20 GHz, 16 GB de RAM i una unitat SSD de 200 GB.
Hi vaig instal·lar PostgreSQL 10.8 amb Debian OS 10.8-1.pgdg90+1 i el sistema de fitxers xfs. Ho he configurat tot mínimament per utilitzar aquesta base de dades en particular, menys el que farà servir Zabbix.
A la mateixa màquina hi havia un servidor Zabbix, PostgreSQL i agents de càrrega. Vaig tenir 50 agents actius que feien servir LoadableModuleper generar diversos resultats molt ràpidament: números, cadenes. Vaig omplir la base de dades amb moltes dades.
Inicialment, la configuració continguda 5 articles dades per host. Gairebé tots els elements contenien un disparador per fer-lo semblar a instal·lacions reals. En alguns casos hi va haver més d'un desencadenant. Un node de xarxa tenia 3-000 activadors.
Interval d'actualització d'elements − segons 4-7. Vaig regular la càrrega mateixa utilitzant no només 50 agents, sinó afegint-ne més. A més, amb l'ajuda d'elements de dades, vaig regular dinàmicament la càrrega i vaig reduir l'interval d'actualització a 4 s.
PostgreSQL. 35 nvps
La meva primera execució amb aquest maquinari va ser en PostgreSQL pur: 35 mil valors per segon. Com podeu veure, inserir dades triga fraccions de segon: tot està bé i ràpid. L'única cosa és que la unitat SSD de 200 GB s'omple ràpidament.
Aquest és un tauler estàndard de rendiment del servidor Zabbix.
El primer gràfic blau és el nombre de valors per segon. El segon gràfic de la dreta està carregant processos de compilació. El tercer és la càrrega de processos de compilació interns: sincronitzadors d'historial i Housekeeper, que s'està executant aquí des de fa força temps.
El quart gràfic mostra l'ús de HistoryCache. Aquest és una mena de memòria intermèdia abans d'inserir-lo a la base de dades. El cinquè gràfic verd mostra l'ús de ValueCache, és a dir, quantes visites de ValueCache per activadors són diversos milers de valors per segon.
PostgreSQL. 50 nvps
A continuació, vaig augmentar la càrrega a 50 mil valors per segon al mateix maquinari.
En carregar des de Housekeeper, inserir 10 mil valors va trigar entre 2 i 3 segons.
La mestressa ja comença a posar-se en el camí.
El tercer gràfic mostra que, en general, la càrrega de trappers i sincronitzadors d'historial encara es troba al nivell del 60%. Al quart gràfic, HistoryCache durant el funcionament de Housekeeper ja comença a omplir-se força activa. Està ple al 20%: uns 0,5 GB.
PostgreSQL. 80 nvps
Llavors vaig augmentar la càrrega a 80 mil valors per segon. Això són aproximadament 400 mil elements de dades i 280 mil activadors.
La inserció de càrrega de trenta sincronitzadors d'historial ja és bastant alta.
També vaig augmentar diversos paràmetres: sincronitzadors d'historial, memòria cau.
Al meu maquinari, la càrrega dels sincronitzadors d'historial va augmentar al màxim. HistoryCache es va omplir ràpidament de dades: la memòria intermèdia ha acumulat dades per processar-les.
Durant tot aquest temps, vaig observar com s'utilitzaven el processador, la memòria RAM i altres paràmetres del sistema, i vaig trobar que la utilització del disc era màxima.
n'he fet ús capacitat màxima del disc en aquest maquinari i en aquesta màquina virtual. Amb tanta intensitat, PostgreSQL va començar a bolcar dades de manera força activa i el disc ja no tenia temps per escriure i llegir.
Segon servidor
Vaig agafar un altre servidor que ja tenia 48 processadors i 128 GB de RAM. El vaig ajustar: vaig establir 60 sincronitzadors d'historial i vaig aconseguir un rendiment acceptable.
De fet, això ja és un límit de rendiment on cal fer alguna cosa.
a escala temporalb. 80 nvps
La meva tasca principal és provar les capacitats de TimescaleDB amb una càrrega Zabbix. 80 mil valors per segon és molt, la freqüència de recollida de mètriques (excepte Yandex, és clar) i una "configuració" força gran.
Hi ha una caiguda a cada gràfic: això és només una migració de dades. Després dels errors al servidor Zabbix, el perfil de càrrega del sincronitzador d'historial ha canviat molt: ha caigut tres vegades.
TimescaleDB us permet inserir dades gairebé 3 vegades més ràpid i utilitzar menys HistoryCache.
En conseqüència, rebràs les dades de manera oportuna.
a escala temporalb. 120 nvps
A continuació, vaig augmentar el nombre d'elements de dades a 500 mil. La tasca principal va ser comprovar les capacitats de TimescaleDB: vaig obtenir un valor calculat de 125 mil valors per segon.
Aquesta és una "configuració" de treball que pot trigar molt a funcionar. Però com que el meu disc només tenia 1,5 TB, el vaig omplir en un parell de dies.
El més important és que s'estaven creant noves particions TimescaleDB al mateix temps.
Per al rendiment, això és completament imperceptible. Quan es creen particions a MySQL, per exemple, les coses són diferents. Això sol passar a la nit, perquè bloqueja la inserció general, la manipulació de la taula i pot generar degradació del servei. Aquest no és el cas de TimescaleDB.
Per exemple, mostraré un gràfic del conjunt a la comunitat. A la imatge, TimescaleDB està habilitat, gràcies a la qual cosa s'ha reduït la càrrega de l'ús de io.weight al processador. També ha disminuït l'ús d'elements dels processos interns. A més, es tracta d'una màquina virtual normal en discs pancake normals, i no d'un SSD.
Troballes
TimescaleDB és una bona solució per a petites "configuracions", que es basen en el rendiment del disc. Us permetrà continuar treballant bé fins que la base de dades es migri al maquinari més ràpidament.
TimescaleDB és fàcil de configurar, augmenta el rendiment, funciona bé amb Zabbix i té avantatges respecte a PostgreSQL.
Si utilitzeu PostgreSQL i no teniu previst canviar-lo, us recomano utilitzeu PostgreSQL amb l'extensió TimescaleDB juntament amb Zabbix. Aquesta solució funciona amb eficàcia fins a una "configuració" mitjana.
Diem "alt rendiment" - ens referim . No passarà gaire abans de conèixer les tecnologies i pràctiques que permeten als serveis servir milions d'usuaris. Llista per als dies 7 i 8 de novembre, ja hem elaborat, però se'n poden suggerir més.
Subscriu-te al nostre и , en què desvelem les característiques de la propera conferència, i descobrim com treure'n el màxim profit.
Font: www.habr.com