Zabbix 支持 TimescaleDB,这是一个基于 PostgreSQL 的数据库解决方案,可将数据自动按时间分片,以在大规模数据场景下提供更快的性能。
目前,Zabbix proxy 不支持 TimescaleDB。
本页面的说明适用于以下场景:
前提条件: 数据库服务器需安装supported version的TimescaleDB扩展。安装说明请参阅TimescaleDB documentation。
通过执行以下命令为特定数据库启用TimescaleDB扩展:
运行此命令需要数据库管理员权限。
若使用非'public'的数据库模式,需在上述命令中添加SCHEMA子句。例如:
echo "CREATE EXTENSION IF NOT EXISTS timescaledb SCHEMA yourschema CASCADE;" | sudo -u postgres psql zabbix
然后run postgresql/timescaledb/schema.sql
脚本。 对于全新安装,该脚本必须在常规PostgreSQL数据库创建并初始化模式/数据后run(参见database creation)。
在TimescaleDB version 2.9.0及以上版本运行schema.sql
脚本时,请忽略关于未遵循最佳实践的警告信息。 尽管存在此警告,配置仍将成功完成。
现有历史数据、趋势数据和审计日志数据的迁移可能耗时较长。 迁移期间需关闭Zabbix server和前端服务。
schema.sql
脚本设置以下管家参数:
要对历史和趋势数据启用分区管家功能,必须同时启用这两个选项。 也可单独启用历史或趋势的覆盖功能。
postgresql/timescaledb/schema.sql
脚本设置两个额外参数:
要成功通过housekeeper删除压缩数据,必须启用覆盖监控项历史数据保留周期
和覆盖监控项趋势数据保留周期选项。
如果覆盖功能被禁用且表中存在压缩数据块,housekeeper将不会从这些表中删除数据,
并且在Housekeeping
和System information部分会显示有关配置错误的警告信息。
所有参数均可在安装后通过管理→ Housekeeping进行修改
建议使用TimescaleDB提供的run工具 对postgresql.conf
中的PostgreSQL配置参数进行优化
当将 Zabbix 升级到包含新的 TimescaleDB 超表的 version 时,Zabbix server 不会自动配置这些超表(例如,从 Zabbix 6.4 升级到 7.0.3,因为版本 7.0.0 和 7.0.2 引入了新的超表)。
要配置新的 TimescaleDB 超表,请按照以下步骤操作:
postgresql/timescaledb/schema.sql
脚本;这将配置新的 TimescaleDB 超表。请注意,自 Zabbix 7.0.0 起,脚本的位置和名称已从 postgresql/timescaledb.sql
更改为 postgresql/timescaledb/schema.sql
。在 TimescaleDB version 2.9.0 及更高版本上运行 schema.sql
脚本时,请忽略提示未遵循最佳实践的警告消息。
尽管存在此警告,配置仍将成功完成。
所有作为TimescaleDB超表的Zabbix表均支持原生TimescaleDB压缩功能。在升级或迁移至TimescaleDB过程中, 对大表的初始压缩操作可能会耗费大量时间。
请注意压缩功能仅在"timescale" Timescale社区许可下支持, "apache" Apache 2.0许可下不支持。若Zabbix检测到压缩功能不可用, 会在Zabbix server日志中记录警告信息,且用户无法在前端启用压缩功能。
建议用户在使用压缩功能前,先通过TimescaleDB documentation文档get压缩相关原理。
需注意压缩功能存在以下限制:
压缩设置可通过Zabbix前端管理→数据管家中的历史、趋势与审计日志压缩模块进行配置。
参数 | 默认值 | 说明 |
---|---|---|
Enable compression | 启用 | 勾选框状态变更不会立即生效。由于压缩由数据管家进程处理,配置变更最长需要2倍HousekeepingFrequency 小时(该值在zabbix_server.conf中设置)才能生效禁用压缩后,符合压缩时间条件的新数据块将不再压缩,但已压缩数据仍保持压缩状态。如需解压已压缩数据块,请参照TimescaleDB documentation文档操作 从旧版支持TimescaleDB的Zabbix升级时,压缩功能默认处于关闭状态 |
Compress records older than | 7天 | 该值不得小于7天 由于压缩块的不可变性,所有超过该时限的延迟数据(如因proxy导致延迟的数据)都将被丢弃 |
为优化趋势update性能,建议根据使用趋势功能的监控项数量, 将trends
和trends_uint
表的"chunk_time_interval"从30天调整为7天或更短。 此设置遵循TimescaleDB最佳实践,可确保数据块大小始终在系统可用资源范围内。