Zabbix es un sistema de monitoreo. Como cualquier otro sistema, enfrenta tres problemas principales de todos los sistemas de monitoreo: recopilar y procesar datos, almacenar el historial y borrarlo.
Las etapas de recepción, procesamiento y registro de datos toman tiempo. No mucho, pero para un sistema grande, esto puede resultar en grandes retrasos. El problema del almacenamiento es una cuestión de acceso a los datos. Se utilizan para informes, comprobaciones y disparadores. Los retrasos en el acceso a los datos también afectan al rendimiento. Cuando la base de datos crece, los datos irrelevantes deben eliminarse. La eliminación es una operación pesada que también consume algunos recursos.
Los problemas de demora de recolección y almacenamiento en Zabbix se resuelven mediante el almacenamiento en caché: varios tipos de cachés, almacenamiento en caché en la base de datos. Para resolver el tercer problema, el almacenamiento en caché no es adecuado, por lo que se utilizó TimescaleDB en Zabbix. hablare de eso Andrei Gushchin - ingeniero de soporte técnico . Andrey ha estado apoyando a Zabbix durante más de 6 años y está directamente involucrado en el rendimiento.
¿Cómo funciona TimescaleDB, qué rendimiento puede ofrecer en comparación con PostgreSQL normal? ¿Qué papel juega Zabbix en TimescaleDB? ¿Cómo empezar desde cero y cómo migrar desde PostgreSQL y qué rendimiento de configuración es mejor? Todo esto bajo el corte.
Desafíos de rendimiento
Cada sistema de monitoreo enfrenta ciertos desafíos de rendimiento. Hablaré de tres de ellos: recopilación y procesamiento de datos, almacenamiento, limpieza de historial.
Rápida recopilación y procesamiento de datos. Un buen sistema de monitoreo debe recibir rápidamente todos los datos y procesarlos de acuerdo con las expresiones desencadenantes, de acuerdo con sus propios criterios. Después del procesamiento, el sistema también debe almacenar rápidamente estos datos en la base de datos para poder usarlos más adelante.
Almacenamiento de historial. Un buen sistema de monitoreo debe almacenar el historial en una base de datos y brindar fácil acceso a las métricas. El historial es necesario para utilizarlo en informes, gráficos, disparadores, umbrales y elementos de alerta calculados.
Limpiando historial. A veces llega un día en que no necesita almacenar métricas. ¿Por qué necesita datos que se recopilaron hace 5 años, un mes o dos? Se eliminaron algunos nodos, algunos hosts o métricas ya no son necesarios porque están desactualizados y ya no se recopilan. Un buen sistema de monitoreo debe almacenar datos históricos y eliminarlos de vez en cuando para que la base de datos no crezca.
La limpieza de datos obsoletos es un tema espinoso que tiene un gran impacto en el rendimiento de la base de datos.
Almacenamiento en caché en Zabbix
En Zabbix, la primera y la segunda llamada se resuelven mediante el almacenamiento en caché. La memoria RAM se utiliza para recopilar y procesar datos. Para el almacenamiento: historial en disparadores, gráficos y elementos calculados. En el lado de la base de datos, hay algo de almacenamiento en caché para selecciones básicas, como gráficos.
El almacenamiento en caché en el lado del propio servidor Zabbix es:
- Caché de configuración;
- caché de valor;
- caché de historial;
- Caché de tendencias.
Permítanos considerarlos con más detalle.
Caché de configuración
Este es el caché principal en el que almacenamos métricas, hosts, elementos de datos, disparadores, todo lo que se necesita para el preprocesamiento y la recopilación de datos.
Todo esto se almacena en el ConfigurationCache para no crear consultas innecesarias en la base de datos. Después de que se inicia el servidor, actualizamos este caché, creamos y actualizamos configuraciones periódicamente.
Сбор данных
El esquema es bastante grande, pero lo principal es coleccionistas. Estos son varios "sondeadores": procesos de ensamblaje. Son responsables de diferentes tipos de ensamblaje: recopilan datos a través de SNMP, IPMI y lo transfieren todo a PreProcessing.
Los recolectores están encerrados en un círculo naranja.
Zabbix ha calculado elementos de agregación que se necesitan para agregar cheques. Si los tenemos, tomamos los datos para ellos directamente desde ValueCache.
Historial de preprocesamientoCache
Todos los recopiladores usan ConfigurationCache para recibir trabajos. Luego los pasan a Preprocesamiento.
PreProcessing usa ConfigurationCache para obtener los pasos de PreProcessing. Procesa estos datos de varias maneras.
Después de procesar los datos con PreProcessing, los almacenamos en HistoryCache para procesarlos. Esto completa la recopilación de datos y pasamos al proceso principal en Zabbix: sincronizador de historia, ya que es una arquitectura monolítica.
Nota: el procesamiento previo es una operación bastante pesada. Desde v 4.2 se ha movido a un proxy. Si tiene un Zabbix muy grande con una gran cantidad de artículos y frecuencia de recolección, esto facilita mucho las cosas.
ValueCache, historial y caché de tendencias
El sincronizador de historial es el proceso principal que procesa atómicamente cada elemento de datos, es decir, cada valor.
El sincronizador de historial toma valores de HistoryCache y verifica la configuración en busca de activadores para los cálculos. Si lo son, calcula.
El sincronizador de historial crea un evento, escala para crear alertas si la configuración lo requiere y registra. Si hay desencadenantes para un procesamiento posterior, recuerda este valor en ValueCache para no hacer referencia a la tabla de historial. Así es como ValueCache se llena con los datos que se necesitan para calcular disparadores, elementos calculados.
El sincronizador de historial escribe todos los datos en la base de datos y los escribe en el disco. El proceso de procesamiento termina aquí.
almacenamiento en caché de base de datos
Hay varios cachés en el lado de la base de datos cuando desea ver gráficos o informes de eventos:
Innodb_buffer_poolen el lado de MySQL;shared_buffersen el lado de PostgreSQL;effective_cache_sizedel lado de Oracle;shared_poolen el lado de DB2.
Hay muchos otros cachés, pero estos son los principales para todas las bases de datos. Le permiten mantener datos en RAM que a menudo se necesitan para consultas. Tienen su propia tecnología para esto.
El rendimiento de la base de datos es crítico
El servidor Zabbix recopila datos constantemente y los escribe. Cuando se reinicia, también lee del historial para llenar ValueCache. Usos de scripts e informes API de Zabbix, que se construye sobre la base de la interfaz web. La API de Zabbix accede a la base de datos y recupera los datos necesarios para gráficos, informes, listas de eventos y problemas recientes.
Para visualización - Grafana. Esta es una solución popular entre nuestros usuarios. Puede enviar solicitudes directamente a través de la API de Zabbix y a la base de datos, y crea una cierta concurrencia para obtener datos. Por lo tanto, se necesita un mejor y más fino ajuste de la base de datos para que coincida con la rápida entrega de resultados y pruebas.
Ama de llaves
El tercer desafío de rendimiento en Zabbix es limpiar la historia con Housekeeper. Respeta todas las configuraciones: los elementos de datos indican cuánto tiempo almacenar la dinámica de los cambios (tendencias) en días.
TrendsCache lo calculamos sobre la marcha. Cuando llegan los datos, los agregamos en una hora y los ponemos en tablas para la dinámica de los cambios de tendencia.
Housekeeper inicia y elimina información de la base de datos con las "selecciones" habituales. Esto no siempre es eficiente, lo que se puede entender a partir de los gráficos de rendimiento de los procesos internos.
El gráfico rojo muestra que el sincronizador de historial está constantemente ocupado. El gráfico naranja en la parte superior es Housekeeper, que se ejecuta constantemente. Espera a que la base de datos elimine todas las filas que ha especificado.
¿Cuándo debería desactivar Housekeeper? Por ejemplo, hay un “Item ID” y necesitas borrar las últimas 5 mil líneas en un tiempo determinado. Por supuesto, esto sucede por índices. Pero, por lo general, el conjunto de datos es muy grande y la base de datos aún lee del disco y lo coloca en el caché. Esta es siempre una operación muy costosa para la base de datos y, según el tamaño de la base de datos, puede provocar problemas de rendimiento.
Housekeeper es fácil de desactivar. En la interfaz web, hay una configuración en "Administración general" para Housekeeper. Deshabilite el mantenimiento interno para el historial de tendencias internas y ya no controlará esto.
El ama de llaves se ha desactivado, los gráficos se han nivelado: ¿cuáles podrían ser los problemas en este caso y qué puede ayudar a resolver el tercer desafío de rendimiento?
Partición - partición o partición
La partición generalmente se configura de una manera diferente en cada base de datos relacional que he enumerado. Cada uno tiene su propia tecnología, pero son similares, en general. La creación de una nueva partición a menudo conduce a ciertos problemas.
Por lo general, las particiones se configuran según la "configuración": la cantidad de datos que se crean en un día. Como regla general, el particionamiento se configura en un día, este es el mínimo. Para nuevas tendencias de partición: 1 mes.
Los valores pueden cambiar en el caso de una "configuración" muy grande. Si un “setup” pequeño es de hasta 5 nvps (nuevos valores por segundo), uno promedio es de 000 a 5 000, luego uno grande está por encima de los 25 000 nvps. Estas son instalaciones grandes y muy grandes que requieren una configuración cuidadosa de la propia base de datos.
En instalaciones muy grandes, un día puede no ser óptimo. He visto particiones MySQL de 40 GB o más por día. Esta es una gran cantidad de datos que pueden generar problemas y deben reducirse.
¿Qué da el particionado?
Tablas de partición. A menudo, estos son archivos separados en el disco. El plan de consulta selecciona una partición de manera más óptima. Por lo general, la partición se usa por rango; esto también es cierto para Zabbix. Usamos allí "marca de tiempo": el tiempo desde el comienzo de la época. Tenemos números regulares. Usted establece el comienzo y el final del día: esta es una partición.
Eliminación rápida - DELETE. Se selecciona un archivo/subtabla, no una selección de filas para eliminar.
Acelera significativamente el muestreo de datos SELECT - utiliza una o más particiones, no toda la tabla. Si está accediendo a datos de hace dos días, los obtiene de la base de datos más rápido porque solo tiene que cargarlos en el caché y devolver solo un archivo, no una tabla grande.
A menudo, muchas bases de datos también aceleran INSERT - se inserta en la mesa infantil.
Escala de tiempoDB
Para v 4.2 dirigimos nuestra atención a TimescaleDB. Esta es una extensión de PostgreSQL con una interfaz nativa. La extensión funciona de manera eficiente con datos de series temporales sin perder las ventajas de las bases de datos relacionales. TimescaleDB también realiza particiones automáticamente.
TimescaleDB tiene un concepto hipertable (hipertable) que creas. en el estan trozos - particiones. Los fragmentos son fragmentos administrados automáticamente de una hipertabla que no afectan a otros fragmentos. Cada fragmento tiene su propio intervalo de tiempo.
TimescaleDB frente a PostgreSQL
TimescaleDB es realmente eficiente. Los productores de la extensión afirman que utilizan un algoritmo de procesamiento de consultas más correcto, en particular, inserts . A medida que crece el tamaño de la inserción del conjunto de datos, el algoritmo mantiene un rendimiento constante.
Después de 200 millones de filas, PostgreSQL generalmente comienza a ceder mucho y pierde rendimiento a 0. TimescaleDB le permite insertar "inserciones" de manera eficiente con cualquier cantidad de datos.
Instalación
Instalar TimescaleDB es bastante fácil para cualquier paquete. EN todo está detallado, depende de los paquetes oficiales de PostgreSQL. TimescaleDB también se puede construir y compilar a mano.
Para la base de datos de Zabbix, simplemente activamos la extensión:
echo "CREATE EXTENSION IF NOT EXISTS timescaledb CASCADE;" | sudo -u postgres psql zabbix
tu activas extension y créelo para la base de datos Zabbix. El último paso es crear una hipertabla.
Migración de tablas de historial a TimescaleDB
Hay una función especial para esto. 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ón tiene tres parámetros. Primero - tabla en base de datosEl para el que desea crear una hipertabla. Segundo - campo, según el cual es necesario crear chunk_time_interval — intervalo de fragmentos de partición a utilizar. En mi caso, el intervalo es de un día: 86.
El tercer parámetro es migrate_data. Si está configurado true, todos los datos actuales se transfieren a fragmentos creados previamente. yo mismo he usado migrate_data. Tenía alrededor de 1 TB que tomó más de una hora. Incluso en algunos casos, al hacer pruebas, eliminé los datos históricos de tipos de caracteres que son opcionales para el almacenamiento para no transferirlos.
Último paso - UPDATE: en db_extension poner timescaledbpara que la base de datos entienda que existe esta extensión. Zabbix lo activa y usa correctamente la sintaxis y las consultas que ya están en la base de datos, esas características que son necesarias para TimescaleDB.
Configuración de hardware
Usé dos servidores. Primero - máquina vmware. Es lo suficientemente pequeño: 20 CPU Intel® Xeon® E5-2630 v 4 a 2.20 GHz, 16 GB de RAM y una unidad SSD de 200 GB.
Instalé PostgreSQL 10.8 con Debian OS 10.8-1.pgdg90+1 y sistema de archivos xfs. Configuré todo mínimamente para usar esta base de datos en particular, menos lo que usará Zabbix.
En la misma máquina había un servidor Zabbix, PostgreSQL y agentes de carga. Tenía 50 agentes activos que usaban LoadableModulepara generar varios resultados muy rápidamente: números, cadenas. Llené la base de datos con muchos datos.
Inicialmente, la configuración contenía 5 elementos datos por host. Casi todos los elementos contenían un disparador para que pareciera una instalación real. En algunos casos hubo más de un desencadenante. Un nodo de red tenía 3-000 disparadores.
Intervalo de actualización de elementos − segundos 4-7. Regulé la carga en sí usando no solo 50 agentes, sino agregando más. Además, con la ayuda de elementos de datos, regulé dinámicamente la carga y reduje el intervalo de actualización a 4 s.
PostgresSQL. 35 nvps
Mi primera ejecución en este hardware fue en PostgreSQL puro: 35 200 valores por segundo. Como puede ver, la inserción de datos lleva fracciones de segundo: todo está bien y rápido. Lo único es que la unidad SSD de XNUMX GB se llena rápidamente.
Este es un panel de rendimiento del servidor Zabbix estándar.
El primer gráfico azul es el número de valores por segundo. El segundo gráfico a la derecha está cargando procesos de compilación. El tercero es la carga de procesos de compilación internos: sincronizadores de historial y Housekeeper, que se ha estado ejecutando durante bastante tiempo aquí.
El cuarto gráfico muestra el uso de HistoryCache. Este es un tipo de búfer antes de insertarlo en la base de datos. El quinto gráfico verde muestra el uso de ValueCache, es decir, cuántos hits de ValueCache para disparadores son varios miles de valores por segundo.
PostgresSQL. 50 nvps
Luego aumenté la carga a 50 mil valores por segundo en el mismo hardware.
Al cargar desde Housekeeper, la inserción de 10 mil valores tomó de 2 a 3 segundos.
El ama de llaves ya está empezando a estorbar.
El tercer gráfico muestra que, en general, la carga de trampas y sincronizadores de historial todavía está en el nivel del 60%. En el cuarto gráfico, el HistoryCache durante la operación de Housekeeper ya está comenzando a llenarse de manera bastante activa. Está lleno al 20%, alrededor de 0,5 GB.
PostgresSQL. 80 nvps
Luego aumenté la carga a 80 mil valores por segundo. Esto es aproximadamente 400 mil elementos de datos y 280 mil disparadores.
La inserción de carga de treinta sincronizadores de historial ya es bastante alta.
También aumenté varios parámetros: sincronizadores de historial, cachés.
En mi hardware, la carga de sincronizadores de historial aumentó al máximo. HistoryCache se llenó rápidamente con datos: el búfer ha acumulado datos para su procesamiento.
Durante todo este tiempo, observé cómo se usaban el procesador, la RAM y otros parámetros del sistema, y descubrí que la utilización del disco era máxima.
he hecho uso de capacidad máxima del disco en este hardware y en esta máquina virtual. Con tanta intensidad, PostgreSQL comenzó a volcar datos de forma bastante activa y el disco ya no tenía tiempo para escribir y leer.
Segundo servidor
Tomé otro servidor que ya tenía 48 procesadores y 128 GB de RAM. Lo sintonicé: configuré 60 sincronizadores de historial y logré un rendimiento aceptable.
De hecho, esto ya es un límite de rendimiento en el que hay que hacer algo.
escala temporalb. 80 nvps
Mi tarea principal es probar las capacidades de TimescaleDB contra una carga de Zabbix. 80 mil valores por segundo es mucho, la frecuencia de recopilación de métricas (a excepción de Yandex, por supuesto) y una "configuración" bastante grande.
Hay una caída en cada gráfico: esto es solo una migración de datos. Después de las fallas en el servidor Zabbix, el perfil de carga del sincronizador de historial ha cambiado mucho: se cayó tres veces.
TimescaleDB le permite insertar datos casi 3 veces más rápido y usar menos HistoryCache.
En consecuencia, recibirá datos de manera oportuna.
escala temporalb. 120 nvps
Luego aumenté la cantidad de elementos de datos a 500 125. La tarea principal era verificar las capacidades de TimescaleDB: obtuve un valor calculado de XNUMX XNUMX valores por segundo.
Esta es una "configuración" de trabajo que puede tardar mucho tiempo en funcionar. Pero como mi disco tenía solo 1,5 TB, lo llené en un par de días.
Lo que es más importante, se estaban creando nuevas particiones de TimescaleDB al mismo tiempo.
Para el rendimiento, esto es completamente imperceptible. Cuando se crean particiones en MySQL, por ejemplo, las cosas son diferentes. Esto suele ocurrir por la noche, porque bloquea la inserción general, la manipulación de tablas y puede degradar el servicio. Este no es el caso con TimescaleDB.
Por ejemplo, mostraré un gráfico del conjunto en comunidad. En la imagen, TimescaleDB está habilitado, gracias a lo cual ha disminuido la carga sobre el uso de io.weight en el procesador. También ha disminuido el uso de elementos de procesos internos. Además, esta es una máquina virtual ordinaria en discos Pancake ordinarios, y no un SSD.
Hallazgos
TimescaleDB es una buena solución para pequeñas "configuraciones", que se basan en el rendimiento del disco. Le permitirá seguir trabajando bien hasta que la base de datos se migre al hardware más rápido.
TimescaleDB es fácil de configurar, aumenta el rendimiento, funciona bien con Zabbix y tiene ventajas sobre PostgreSQL.
Si usa PostgreSQL y no planea cambiarlo, le recomiendo use PostgreSQL con la extensión TimescaleDB junto con Zabbix. Esta solución funciona de manera efectiva hasta una "configuración" media.
Decimos "alto rendimiento", queremos decir . No pasará mucho tiempo antes de que conozca las tecnologías y prácticas que permiten que los servicios sirvan a millones de usuarios. Lista para el 7 y 8 de noviembre ya lo hemos trazado, pero se puede sugerir más.
Suscríbete a nuestro и , en el que revelamos las características de la próxima conferencia y descubrimos cómo aprovecharla al máximo.
Fuente: habr.com