Zabbix é un sistema de monitorización. Como calquera outro sistema, enfróntase a tres problemas principais de todos os sistemas de vixilancia: recoller e procesar datos, almacenar o historial e borralo.
As etapas de recepción, tratamento e gravación de datos levan tempo. Non moito, pero para un sistema grande, isto pode producir grandes atrasos. O problema de almacenamento é unha cuestión de acceso aos datos. Utilízanse para informes, comprobacións e disparadores. Os atrasos no acceso aos datos tamén afectan o rendemento. Cando a base de datos crece, hai que eliminar os datos irrelevantes. A eliminación é unha operación pesada que tamén consume algúns recursos.
Os problemas de atraso de recollida e almacenamento en Zabbix resólvense mediante o caché: varios tipos de caché, o caché na base de datos. Para resolver o terceiro problema, o almacenamento na caché non é axeitado, polo que TimescaleDB utilizouse en Zabbix. Contará sobre iso Andrey Gushchin - Enxeñeiro de soporte técnico . Andrey leva máis de 6 anos apoiando a Zabbix e participa directamente na actuación.
Como funciona TimescaleDB, que rendemento pode dar en comparación co PostgreSQL normal? Que papel xoga Zabbix en TimescaleDB? Como comezar de cero e como migrar desde PostgreSQL e que o rendemento da configuración é mellor? Todo isto baixo o corte.
Retos de rendemento
Cada sistema de monitorización enfróntase a certos desafíos de rendemento. Falarei de tres deles: recollida e tratamento de datos, almacenamento, limpeza do historial.
Recollida e procesamento de datos rápidos. Un bo sistema de vixilancia debería recibir rapidamente todos os datos e procesalos segundo as expresións de activación, segundo os seus propios criterios. Despois do procesamento, o sistema tamén debe almacenar rapidamente estes datos na base de datos para utilizalos máis tarde.
Almacenamento do historial. Un bo sistema de vixilancia debería almacenar o historial nunha base de datos e facilitar o acceso ás métricas. O historial é necesario para usarse en informes, gráficos, activadores, limiares e elementos de alerta calculados.
Borrando o historial. Ás veces chega un día no que non necesitas almacenar métricas. Por que necesitas datos que se recolleron hai 5 anos, un ou dous meses: elimináronse algúns nodos, xa non son necesarios algúns hosts ou métricas porque están desactualizados e xa non se recollen. Un bo sistema de vixilancia debería almacenar datos históricos e borralos de cando en vez para que a base de datos non medre.
A limpeza de datos obsoletos é un problema espiñento que ten un gran impacto no rendemento da base de datos.
Almacenamento na caché en Zabbix
En Zabbix, a primeira e a segunda chamadas resólvense usando a caché. A memoria RAM úsase para recoller e procesar datos. Para almacenamento: historial en disparadores, gráficos e elementos calculados. No lado da base de datos, hai algo de caché para seleccións básicas, como gráficos.
O almacenamento na caché do propio servidor Zabbix é:
- Caché de configuración;
- ValueCache;
- HistoryCache;
- TrendsCache.
Considerémolos con máis detalle.
Caché de configuración
Esta é a caché principal na que almacenamos métricas, hosts, elementos de datos, disparadores, todo o que se necesita para o preprocesamento e para a recollida de datos.
Todo isto gárdase no ConfigurationCache para non crear consultas innecesarias na base de datos. Despois de que se inicie o servidor, actualizamos esta caché, creamos e actualizamos periodicamente as configuracións.
Recollida de datos
O esquema é bastante grande, pero o principal é coleccionistas. Estes son varios "pollers" - procesos de montaxe. Son responsables de diferentes tipos de montaxe: recollen datos a través de SNMP, IPMI e transfiren todo a PreProcessing.
Os pickers están rodeados de cor laranxa.
Zabbix calculou elementos de agregación que son necesarios para agregar comprobacións. Se os temos, collemos os datos directamente do ValueCache.
Caché do historial de preprocesamento
Todos os colectores usan ConfigurationCache para recibir traballos. Despois pásanos a PreProcessing.
Preprocessing usa ConfigurationCache para obter pasos de preprocessing. Procesa estes datos de varias maneiras.
Despois de procesar os datos con PreProcessing, almacenámolos no HistoryCache para procesalos. Isto completa a recollida de datos e pasamos ao proceso principal en Zabbix - sincronizador de historial, xa que é unha arquitectura monolítica.
Nota: o preprocesamento é unha operación bastante pesada. Desde a versión 4.2 moveuse a un proxy. Se tes un Zabbix moi grande cunha gran cantidade de elementos e frecuencia de recollida, isto facilita moito as cousas.
ValueCache, caché de historia e tendencias
History Syncer é o proceso principal que procesa atomicamente cada elemento de datos, é dicir, cada valor.
O sincronizador de historial toma valores de HistoryCache e verifica a configuración dos disparadores para os cálculos. Se son - calcula.
O sincronizador de historial crea un evento, escala para crear alertas se é necesario pola configuración e rexistra. Se hai disparadores para o procesamento posterior, lembra este valor en ValueCache para non referirse á táboa de historial. Así é como se enche o ValueCache cos datos necesarios para calcular os disparadores, os elementos calculados.
History Syncer escribe todos os datos na base de datos e escribe no disco. O proceso de procesamento remata aquí.
Caché de base de datos
Hai varios cachés no lado da base de datos cando queres ver gráficos ou informes de eventos:
Innodb_buffer_poolno lado de MySQL;shared_buffersno lado de PostgreSQL;effective_cache_sizeno lado de Oracle;shared_poolno lado de DB2.
Hai moitos outros cachés, pero estes son os principais para todas as bases de datos. Permítenche manter os datos na RAM que adoitan ser necesarios para as consultas. Teñen a súa propia tecnoloxía para iso.
O rendemento da base de datos é fundamental
O servidor Zabbix está constantemente recompilando datos e escribindoos. Cando se reinicia, tamén le do historial para encher o ValueCache. Usos de scripts e informes API de Zabbix, que está construído sobre a base da interface web. A API de Zabbix accede á base de datos e recupera os datos necesarios para gráficos, informes, listas de eventos e problemas recentes.
Para visualización - grafana. Esta é unha solución popular entre os nosos usuarios. Pode enviar solicitudes directamente a través da API de Zabbix e á base de datos, e crea unha certa concorrencia para obter datos. Polo tanto, é necesario un axuste máis fino e mellor da base de datos para coincidir coa entrega rápida de resultados e probas.
Gobernanta
O terceiro reto de actuación en Zabbix é limpar a historia con Housekeeper. Respecta todas as configuracións: os elementos de datos indican canto tempo se almacena a dinámica dos cambios (tendencias) en días.
TrendsCache calculamos sobre a marcha. Cando entran os datos, agrégámolos nunha hora e poñémolos en táboas para a dinámica dos cambios de tendencia.
Ama de casa inicia e elimina información da base de datos coas "seleccións" habituais. Isto non sempre é eficiente, o que se pode entender a partir dos gráficos de rendemento dos procesos internos.
O gráfico vermello mostra que o sincronizador do historial está constantemente ocupado. O gráfico laranxa na parte superior é Housekeeper, que está en funcionamento constantemente. Espera a que a base de datos elimine todas as filas que especificou.
Cando se debe desactivar a empregada do fogar? Por exemplo, hai un "ID de elemento" e cómpre eliminar as últimas 5 mil liñas nun tempo determinado. Por suposto, isto ocorre por índices. Pero normalmente o conxunto de datos é moi grande e a base de datos aínda le dende o disco e colócao na caché. Esta é sempre unha operación moi cara para a base de datos e, dependendo do tamaño da base de datos, pode provocar problemas de rendemento.
A empregada do fogar é sinxela de desactivar. Na interface web, hai unha configuración en "Administración xeral" para Housekeeper. Desactiva a limpeza interna para o historial de tendencias interno e xa non o controla.
Desactivouse a empregada do fogar, os gráficos niveláronse: cales poderían ser os problemas neste caso e que poden axudar a resolver o terceiro desafío de rendemento?
Partición - partición ou partición
A partición adoita configurarse dun xeito diferente en cada base de datos relacional que enumerei. Cada un ten a súa propia tecnoloxía, pero son similares, en xeral. A creación dunha nova partición adoita levar a certos problemas.
Normalmente, as particións están configuradas dependendo da "configuración" - a cantidade de datos que se crean nun día. Como regra xeral, a partición confírmase nun día, este é o mínimo. Para novas tendencias de partición: 1 mes.
Os valores poden cambiar no caso dunha "configuración" moi grande. Se unha "configuración" pequena é de ata 5 nvps (novos valores por segundo), unha media é de 000 a 5, entón unha grande está por riba dos 000 nvps. Trátase de instalacións grandes e moi grandes que requiren unha coidadosa configuración da propia base de datos.
En instalacións moi grandes, un día pode non ser óptimo. Vin particións MySQL de 40 GB ou máis por día. Esta é unha cantidade moi grande de datos que pode dar lugar a problemas e debe reducirse.
Que dá a partición?
Táboas de partición. Moitas veces estes son ficheiros separados no disco. O plan de consulta selecciona unha partición de forma máis óptima. Normalmente úsase a partición por intervalo; isto tamén é certo para Zabbix. Alí usamos "sello de tempo" - o tempo desde o inicio da época. Temos números regulares. Estableces o comezo e o final do día: esta é unha partición.
Eliminación rápida - DELETE. Seleccionouse un ficheiro/subtáboa, non unha selección de filas para eliminar.
Acelera significativamente a mostraxe de datos SELECT - usa unha ou máis particións, non a táboa enteira. Se estás a acceder a datos de dous días de antigüidade, obtén os datos da base de datos máis rápido porque só tes que cargalos na caché e devolver só un ficheiro, non unha táboa grande.
Moitas veces moitas bases de datos tamén se aceleran INSERT - insírese na táboa filla.
TimecaleDB
Para a versión 4.2 diriximos a nosa atención a TimescaleDB. Esta é unha extensión de PostgreSQL cunha interface nativa. A extensión funciona de forma eficiente con datos de series temporais sen perder as vantaxes das bases de datos relacionais. TimescaleDB tamén particiona automaticamente.
TimescaleDB ten un concepto hipertáboa (hipertable) que creas. Nel están anacos - particións. Os anacos son fragmentos xestionados automaticamente dunha hipertáboa que non afectan a outros fragmentos. Cada anaco ten o seu propio intervalo de tempo.
TimescaleDB vs PostgreSQL
TimescaleDB é realmente eficiente. Os produtores da extensión afirman que usan un algoritmo de procesamento de consultas máis correcto, en particular, inserts . A medida que o tamaño da inserción do conxunto de datos crece, o algoritmo mantén un rendemento constante.
Despois de 200 millóns de filas, PostgreSQL normalmente comeza a caer moito e perder o rendemento a 0. TimescaleDB permítelle inserir "insercións" de forma eficiente con calquera cantidade de datos.
Instalación
Instalar TimescaleDB é bastante sinxelo para calquera paquete. EN todo está detallado - depende dos paquetes oficiais de PostgreSQL. TimescaleDB tamén se pode construír e compilar a man.
Para a base de datos Zabbix, simplemente activamos a extensión:
echo "CREATE EXTENSION IF NOT EXISTS timescaledb CASCADE;" | sudo -u postgres psql zabbix
ti activas extension e créao para a base de datos Zabbix. O último paso é crear unha hipertáboa.
Migrando táboas de historial a TimescaleDB
Hai unha función especial para iso. 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
A función ten tres parámetros. Primeira - táboa na base de datosO para o que quere crear unha hipertáboa. segundo - campo, segundo o cal é necesario crear chunk_time_interval — intervalo de fragmentos de partición a utilizar. No meu caso, o intervalo é dun día: 86.
O terceiro parámetro é migrate_data. Se se establece true, entón todos os datos actuais transfírense a anacos creados previamente. Eu mesmo usei migrate_data. Tiven preto de 1 TB que levou máis dunha hora. Mesmo nalgúns casos, ao realizar a proba, eliminei os datos históricos dos tipos de personaxes, que son opcionais para o almacenamento, para non transferilos.
Último paso - UPDATE: en db_extension poñer timescaledbpara que a base de datos entenda que existe esta extensión. Zabbix actívao e usa correctamente a sintaxe e as consultas que xa están na base de datos, as funcións que son necesarias para TimescaleDB.
Configuración de hardware
Usei dous servidores. Primeira - Máquina VMware. É o suficientemente pequeno: 20 CPU Intel® Xeon® E5-2630 v 4 a 2.20 GHz, 16 GB de RAM e unha unidade SSD de 200 GB.
Instalei PostgreSQL 10.8 nel con Debian OS 10.8-1.pgdg90+1 e o sistema de ficheiros xfs. Configurei todo mínimamente para usar esta base de datos en particular, menos o que usará o propio Zabbix.
Na mesma máquina había un servidor Zabbix, PostgreSQL e axentes de carga. Tiven 50 axentes activos que usaron LoadableModulepara xerar varios resultados moi rapidamente: números, cadeas. Enchei a base de datos con moitos datos.
Inicialmente, a configuración contida 5 artigos datos por host. Case todos os elementos contiñan un disparador para facelo parecer instalacións reais. Nalgúns casos houbo máis dun disparador. Un nodo de rede tiña 3-000 disparadores.
Intervalo de actualización do elemento − segundo 4-7. Regulei a propia carga usando non só 50 axentes, senón engadindo máis. Ademais, coa axuda de elementos de datos, regulei dinámicamente a carga e reduín o intervalo de actualización a 4 s.
PostgreSQL. 35 nvps
A miña primeira execución con este hardware foi en PostgreSQL puro: 35 mil valores por segundo. Como podes ver, inserir datos leva fraccións de segundo: todo está ben e rápido. O único é que a unidade SSD de 200 GB se enche rapidamente.
Este é un panel estándar de rendemento do servidor Zabbix.
O primeiro gráfico azul é o número de valores por segundo. O segundo gráfico da dereita está cargando procesos de compilación. O terceiro é a carga de procesos de compilación internos: sincronizadores de historial e Housekeeper, que leva bastante tempo funcionando aquí.
O cuarto gráfico mostra o uso de HistoryCache. Este é unha especie de búfer antes de inserilo na base de datos. O quinto gráfico verde mostra o uso de ValueCache, é dicir, cantas visitas de ValueCache para disparadores son varios miles de valores por segundo.
PostgreSQL. 50 nvps
Entón aumentei a carga a 50 mil valores por segundo no mesmo hardware.
Ao cargar desde Housekeeper, inserir 10 mil valores levou 2-3 segundos.
A empregada do fogar xa comeza a estorbar.
O terceiro gráfico amosa que, en xeral, a carga de tramperos e sincronizadores de historias segue a ser do 60%. No cuarto gráfico, o HistoryCache durante o funcionamento de Housekeeper xa comeza a encherse de forma bastante activa. Está cheo nun 20 % - preto de 0,5 GB.
PostgreSQL. 80 nvps
Entón aumentei a carga a 80 mil valores por segundo. Trátase de aproximadamente 400 mil elementos de datos e 280 mil disparadores.
A inserción de carga de trinta sincronizadores de historial xa é bastante alta.
Tamén aumentei varios parámetros: sincronizadores de historial, cachés.
No meu hardware, a carga dos sincronizadores de historial aumentou ao máximo. HistoryCache encheuse rapidamente de datos: o búfer acumulou datos para procesar.
Durante todo este tempo, observei como se usaban o procesador, a memoria RAM e outros parámetros do sistema e descubrín que a utilización do disco era máxima.
Eu teño feito uso de capacidade máxima do disco neste hardware e nesta máquina virtual. Con tanta intensidade, PostgreSQL comezou a volcar datos de forma bastante activa e o disco xa non tiña tempo para escribir e ler.
Segundo servidor
Tomei outro servidor que xa tiña 48 procesadores e 128 GB de RAM. Axusteino: configurei 60 sincronizadores de historial e conseguín un rendemento aceptable.
De feito, este xa é un límite de rendemento onde hai que facer algo.
escala temporalb. 80 nvps
A miña tarefa principal é probar as capacidades de TimescaleDB contra unha carga de Zabbix. 80 mil valores por segundo son moito, a frecuencia de recollida de métricas (excepto Yandex, por suposto) e unha "configuración" bastante grande.
Hai un descenso en cada gráfico: isto é só unha migración de datos. Despois dos fallos no servidor Zabbix, o perfil de carga do sincronizador de historial cambiou moito: caeu tres veces.
TimescaleDB permítelle inserir datos case 3 veces máis rápido e usar menos HistoryCache.
En consecuencia, recibirá os datos de forma oportuna.
escala temporalb. 120 nvps
Entón aumentei o número de elementos de datos a 500 mil. A tarefa principal foi comprobar as capacidades de TimescaleDB: obtiven un valor calculado de 125 mil valores por segundo.
Esta é unha "configuración" de traballo que pode tardar moito tempo en funcionar. Pero como o meu disco tiña só 1,5 TB, encheino nun par de días.
O máis importante é que se estaban creando novas particións TimescaleDB ao mesmo tempo.
Para o rendemento, isto é completamente imperceptible. Cando se crean particións en MySQL, por exemplo, as cousas son diferentes. Isto adoita ocorrer pola noite, porque bloquea a inserción xeral, a manipulación da táboa e pode crear unha degradación do servizo. Este non é o caso de TimescaleDB.
Por exemplo, mostrarei un gráfico do conxunto na comunidade. Na imaxe, TimescaleDB está habilitado, grazas ao cal diminuíu a carga do uso de io.weight no procesador. Tamén diminuíu o uso de elementos dos procesos internos. Ademais, esta é unha máquina virtual común en discos de panqueque comúns e non un SSD.
Descubrimentos
TimescaleDB é unha boa solución para pequenas "configuracións", que descansan no rendemento do disco. Permitirache seguir traballando ben ata que a base de datos sexa migrada ao hardware máis rápido.
TimescaleDB é fácil de configurar, aumenta o rendemento, funciona ben con Zabbix e ten vantaxes sobre PostgreSQL.
Se usa PostgreSQL e non pensa cambialo, recoméndoo use PostgreSQL coa extensión TimescaleDB en conxunto con Zabbix. Esta solución funciona eficazmente ata unha "configuración" media.
Dicimos "alto rendemento" - queremos dicir . Non pasará moito tempo antes de coñecer as tecnoloxías e as prácticas que permiten que os servizos sirvan para millóns de usuarios. Lista para os días 7 e 8 de novembro, xa o temos elaborado, pero pódese suxerir máis.
Subscríbete ao noso и , na que desvelamos as características da vindeira conferencia, e descubrimos como sacarlle o máximo proveito.
Fonte: www.habr.com