Zabbix es compatible con TimescaleDB, una solución de base de datos basada en PostgreSQL que particiona automáticamente los datos en fragmentos basados en el tiempo para admitir un rendimiento más rápido a gran escala.
Actualmente, Zabbix proxy no es compatible con TimescaleDB.
Las instrucciones en esta página pueden utilizarse para los siguientes escenarios:
Pre-requisitos: Extensión TimescaleDB de una versión soportada instalada en el servidor de base de datos. Para instrucciones de instalación, consulte la documentación de TimescaleDB.
Antes de instalar TimescaleDB, instale una versión soportada de PostgreSQL desde el repositorio oficial de PostgreSQL.
Habilite la extensión TimescaleDB para la base de datos específica ejecutando:
Ejecutar este comando requiere privilegios de administrador de base de datos.
Si utiliza un esquema de base de datos diferente a 'public', debe agregar una cláusula SCHEMA al comando anterior. Por ejemplo:
echo "CREATE EXTENSION IF NOT EXISTS timescaledb SCHEMA yourschema CASCADE;" | sudo -u postgres psql zabbix
Luego ejecute el script postgresql/timescaledb/schema.sql. Para nuevas instalaciones, el script debe ejecutarse después de que la base de datos PostgreSQL regular haya sido creada con el esquema/datos iniciales (consulte creación de base de datos).
Por favor, ignore los mensajes de advertencia que informan que no se siguen las mejores prácticas al ejecutar el script schema.sql en TimescaleDB versión 2.9.0 y superiores. Independientemente de esta advertencia, la configuración se completará correctamente.
La migración de los datos existentes de histórico, tendencias y registro de auditoría puede tomar mucho tiempo. El server y el frontend de Zabbix deben estar detenidos durante el período de migración.
El script schema.sql establece los siguientes parámetros de housekeeping:
Para utilizar el housekeeping particionado para histórico y tendencias, ambas opciones deben estar habilitadas. También es posible habilitar la sobrescritura individualmente, ya sea solo para histórico o solo para tendencias.
Para PostgreSQL y TimescaleDB, el script postgresql/timescaledb/schema.sql establece dos parámetros adicionales:
Para eliminar correctamente los datos comprimidos mediante el housekeeper, se deben habilitar ambas opciones: Anular el período de historial del item y Anular el período de tendencias del item. Si la anulación está deshabilitada y las tablas tienen fragmentos comprimidos, el housekeeper no eliminará los datos de estas tablas y se mostrarán advertencias sobre una configuración incorrecta en las secciones Housekeeping e Información del sistema.
Todos estos parámetros se pueden cambiar en Administración > Mantenimiento después de la instalación.
Es posible que desee ejecutar la herramienta timescaledb-tune proporcionada por TimescaleDB para optimizar los parámetros de configuración de PostgreSQL en su postgresql.conf.
Al actualizar Zabbix a una versión que contiene nuevas hypertables de TimescaleDB, el server de Zabbix no configura automáticamente esas hypertables (por ejemplo, al actualizar de Zabbix 6.4 a 8.0, ya que las versiones 7.0.0 y 7.0.2 han introducido nuevas hypertables).
Para configurar las nuevas hypertables de TimescaleDB, siga estos pasos:
postgresql/timescaledb/schema.sql; esto configura las nuevas hypertables de TimescaleDB. Tenga en cuenta que, desde Zabbix 7.0.0, la ubicación y el nombre del script han cambiado de postgresql/timescaledb.sql a postgresql/timescaledb/schema.sql.Por favor, ignore los mensajes de advertencia que informan que no se siguen las mejores prácticas al ejecutar el script schema.sql en TimescaleDB versión 2.9.0 y superiores. Independientemente de esta advertencia, la configuración se completará correctamente.
Se admite la compresión nativa de TimescaleDB para todas las tablas de Zabbix que son hypertables de TimescaleDB. Durante la actualización o migración a TimescaleDB, la compresión inicial de las tablas grandes puede llevar mucho tiempo.
Tenga en cuenta que la compresión es compatible bajo la licencia Timescale Community "timescale" y no es compatible bajo la licencia Apache 2.0 "apache". Si Zabbix detecta que la compresión no es compatible, se escribe un mensaje de advertencia en el registro del servidor Zabbix y los usuarios no pueden habilitar la compresión en el frontend.
Se recomienda a los usuarios que se familiaricen con la compresión en la documentación de TimescaleDB antes de utilizar la compresión.
Tenga en cuenta que existen ciertas limitaciones impuestas por la compresión, específicamente:
Los ajustes de compresión se pueden cambiar en el bloque Compresión de histórico, tendencias y registro de auditoría en la sección Administración > Limpieza del frontend de Zabbix.
| Parámetro | Por defecto | Comentarios |
|---|---|---|
| Habilitar compresión | Habilitado | Marcar o desmarcar la casilla de verificación no activa/desactiva la compresión inmediatamente. Dado que la compresión es gestionada por el Housekeeper, los cambios tendrán efecto en hasta 2 veces las horas de HousekeepingFrequency (establecido en zabbix_server.conf)Después de deshabilitar la compresión, los nuevos fragmentos que entren en el período de compresión no se comprimirán. Sin embargo, todos los datos previamente comprimidos permanecerán comprimidos. Para descomprimir fragmentos previamente comprimidos, siga las instrucciones en la documentación de TimescaleDB. Al actualizar desde versiones anteriores de Zabbix con soporte para TimescaleDB, la compresión no se habilitará por defecto. |
| Comprimir registros anteriores a | 7d | Este parámetro no puede ser inferior a 7 días. Debido a la inmutabilidad de los fragmentos comprimidos, todos los datos atrasados (por ejemplo, datos retrasados por un proxy) que sean anteriores a este valor se descartarán. |
Para un mejor rendimiento de actualización de tendencias, es posible que desee reducir el "chunk_time_interval" para las tablas trends y trends_uint de 30 días a 7 días o menos, dependiendo de cuántos items utilicen tendencias. El propósito de este ajuste es cumplir con las mejores prácticas de TimescaleDB y garantizar que el tamaño del fragmento permanezca dentro de los recursos disponibles del sistema.