Zabbix 支持 TimescaleDB,这是一个基于 PostgreSQL 的数据库解决方案,可将数据自动按时间分片,以在大规模数据场景下提供更快的性能。
目前,Zabbix proxy 不支持 TimescaleDB。
本页面的说明适用于以下场景:
前提条件:数据库服务器上已安装supported version的TimescaleDB扩展。安装说明请参阅Timescale 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进行修改。
您可能需要run TimescaleDB提供的timescaledb-tune工具来优化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日志中记录警告信息,且用户无法在前端启用压缩功能。
建议用户在使用压缩功能前get熟悉Timescale documentation中的压缩相关内容。
需注意压缩功能存在以下限制:
压缩设置可通过Zabbix前端管理→数据管家中的历史数据、趋势数据和审计日志压缩模块进行配置。
参数 | 默认值 | 说明 |
---|---|---|
Enable compression | 启用 | 勾选框的选中状态不会立即激活/停用压缩功能。由于压缩由数据管家处理,变更将在最多2次HousekeepingFrequency 小时后生效(该值在zabbix_server.conf中设置)禁用压缩后,符合压缩周期的新数据块将不再压缩,但已压缩数据仍保持压缩状态。如需解压已压缩数据块,请参照Timescale documentation中的说明。 从支持TimescaleDB的旧版Zabbix升级时,压缩功能默认不启用。 |
Compress records older than | 7天 | 该参数不得小于7天 由于压缩块的不可变性,所有超过此阈值的延迟数据(如因proxy导致延迟的数据)将被丢弃。 |
为优化趋势update性能,建议将trends
和trends_uint
表的"chunk_time_interval"从30天调整为7天或更短(具体取决于使用趋势功能的监控项数量)。此设置旨在遵循TimescaleDB最佳实践,确保数据块大小始终在系统可用资源范围内。