zabbix 历史数据和趋势数据

zabbix 历史数据和趋势数据

什么是 zabbix 历史数据和趋势数据？

历史数据（history）和趋势数据（trends）是Zabbix中存储收集到的数据的两种方式。历史数据：每一分钟收集到的监控数据

一般来讲，强烈建议将历史数据保留时长设置得尽可能的小。这么做可以让数据库不会因存储了大量的历史数据，导致超负荷运行。可以选择长时间的保留趋势数据，来替代长期需要的历史数据。例如：设置成保留14天历史数据和5年的趋势数据。

趋势数据：按小时统计计算的平均值数据

趋势数据是一种内建的历史数据压缩机制，可以用来存储数字类型监控项的每小时的最小值、最大值、平均值和记录数量。 通常趋势数据设置的的留存时间应当比历史数据留存时间设置的长。

历史数据表和趋势数据表

历史数据：history相关表，从history_uint表里面可以查询到设备监控项目的最大，最小和平均值,即存储监控数据的原始数据。

Refer：通过历史数据表查询数据

趋势数据：trends相关表，趋势数据是经过Zabbix计算的数据，数据是从history_uint里面汇总的，从trends_uint可以查看到监控数据每小时最大，最小和平均值，即存储监控数据的汇总数据。

查看趋势数据表中指定的数据：

mysql> use zabbix; mysql> desc trends_uint; +-----------+---------------------+------+-----+---------+-------+ | Field | Type | Null | Key | Default | Extra | +-----------+---------------------+------+-----+---------+-------+ | itemid | bigint(20) unsigned | NO | PRI | NULL | | | clock | int(11) | NO | PRI | 0 | | | num | int(11) | NO | | 0 | | | value_min | bigint(20) unsigned | NO | | 0 | | | value_avg | bigint(20) unsigned | NO | | 0 | | | value_max | bigint(20) unsigned | NO | | 0 | | +-----------+---------------------+------+-----+---------+-------+ 6 rows in set (0.00 sec)

查询指定时间段的趋势

mysql> select itemid,from_unixtime(clock) as time,value_max from trends_uint where itemid=179831 and clock >= unix_timestamp('2022/06/22 17:00:00') and clock <= unix_timestamp('2022/06/22 19:00:00'); +--------+---------------------+-----------+ | itemid | time | value_max | +--------+---------------------+-----------+ | 179831 | 2022-06-22 17:00:00 | 400 | | 179831 | 2022-06-22 18:00:00 | 400 | | 179831 | 2022-06-22 19:00:00 | 384 | +--------+---------------------+-----------+ 3 rows in set (0.00 sec)

Note：

from_unixtime()函数是将时间戳转换为格式化时间，人类可读；unix_timestamp()函数是将格式化时间转换为时间戳，计算机可读；

一个因为重启 zabbix-server 导致 趋势数据 重复的案例

背景：

问题分析：

1、紧急情况下，先将 ELK 上重复的数据清理掉，保证 数据的一致性；2、查看 zabbix 官方文档 趋势数据的说明，其中有一段：

通常趋势数据设置的的留存时间应当比历史数据留存时间设置的长。任何过旧的趋势数据会被管家从数据库删除。随着数据的流入，Zabbix服务器会在运行时在趋势缓存中累积趋势数据。在以下情况下，服务器会将趋势刷新到数据库中（前端可以在其中找到它们）： 一个新的小时开始或者服务端收到该监控项的新值 一个新的小时将在不到5分钟内结束（没有新值） 服务器停止 要在图表上查看趋势，您需要至少等到下一小时的开始（如果监控项经常更新），最多等到下一小时的结束（如果监控项很少更新），最多需要2个小时。当服务器刷新趋势缓存并且该小时数据库中已经有趋势数据时（例如，服务器已在半小时中重启），服务器需要使用更新语句而不是简单的插入。因此，在更大的初始化安装上，如果需要重新启动，最好在一小时结束时停止服务器，在下一小时开始时启动，以避免趋势数据重叠。

3、查看了两次重启 zabbix-server 的时间：第一次是在 2022/6/22 18:27:57（18:00 数据重复）

4、结合官方说的：如果需要重新启动，最好在一小时结束时停止服务器，在下一小时开始时启动，以避免趋势数据重叠。可以判断 80% 是这里的问题，但是还是需要再复现下该情况；由于没有测试环境，只能等下一次有重启zabbix的安排时，分别在每个小时刚开始时和，中间时间段和重启下，验证我的猜测；

如何删除某一条 zabbix history data？

# 先查询 mysql> select itemid,from_unixtime(clock) as time,value from history_uint where itemid=211620 and clock >= unix_timestamp('2022/07/14 14:00:00') and clock <= unix_timestamp('2022/07/14 15:00:00'); +--------+---------------------+------------+ | itemid | time | value | +--------+---------------------+------------+ | 211620 | 2022-07-14 14:00:00 | 5772548 | | 211620 | 2022-07-14 14:01:00 | 5778302 | | 211620 | 2022-07-14 14:02:01 | 5783793 | | 211620 | 2022-07-14 14:03:01 | 5787192 | | 211620 | 2022-07-14 14:04:01 | 5789197 | | 211620 | 2022-07-14 14:05:00 | 5791213 | | 211620 | 2022-07-14 14:06:00 | 5795615 | | 211620 | 2022-07-14 14:07:00 | 5814422 | | 211620 | 2022-07-14 14:08:00 | 5814518 | | 211620 | 2022-07-14 14:09:00 | 5819851 | | 211620 | 2022-07-14 14:10:01 | 5820767 | | 211620 | 2022-07-14 14:11:01 | 5825848 | | 211620 | 2022-07-14 14:12:00 | 5826080 | | 211620 | 2022-07-14 14:13:00 | 5826553 | | 211620 | 2022-07-14 14:14:00 | 5826893 | | 211620 | 2022-07-14 14:15:01 | 5830066 | | 211620 | 2022-07-14 14:16:00 | 5835610 | | 211620 | 2022-07-14 14:17:01 | 5835967 | | 211620 | 2022-07-14 14:18:00 | 5836668 | | 211620 | 2022-07-14 14:19:00 | 5749407 | | 211620 | 2022-07-14 14:20:01 | 5750478 | | 211620 | 2022-07-14 14:21:01 | 5751182 | | 211620 | 2022-07-14 14:22:00 | 5762615 | | 211620 | 2022-07-14 14:23:00 | 5764112 | | 211620 | 2022-07-14 14:24:00 | 5766961 | | 211620 | 2022-07-14 14:25:01 | 5769428 | | 211620 | 2022-07-14 14:26:00 | 5779067 | | 211620 | 2022-07-14 14:27:00 | 5781703 | | 211620 | 2022-07-14 14:28:00 | 5792346 | | 211620 | 2022-07-14 14:29:01 | 5800125 | | 211620 | 2022-07-14 14:30:00 | 5802542 | | 211620 | 2022-07-14 14:31:01 | 5798819 | | 211620 | 2022-07-14 14:32:00 | 5801194 | | 211620 | 2022-07-14 14:33:01 | 5807220 | | 211620 | 2022-07-14 14:34:00 | 5813478 | | 211620 | 2022-07-14 14:35:00 | 5817587 | | 211620 | 2022-07-14 14:36:01 | 5834869 | | 211620 | 2022-07-14 14:37:00 | 5836098 | | 211620 | 2022-07-14 14:38:00 | 5838025 | | 211620 | 2022-07-14 14:39:00 | 5842170 | | 211620 | 2022-07-14 14:40:00 | 5843492 | | 211620 | 2022-07-14 14:41:01 | 5984238592 | +--------+---------------------+------------+ # 缩小查询范围，找到我们要删除的那条数据 mysql> select value from history_uint where itemid=211620 and clock >= unix_timestamp('2022/07/14 14:41:00') and clock <= unix_timestamp('2022/07/14 15:00:00'); +------------+ | value | +------------+ | 5984238592 | +------------+ 1 row in set (0.00 sec) # 删除该条记录 mysql> delete from history_uint where itemid=211620 and clock >= unix_timestamp('2022/07/14 14:41:00') and clock <= unix_timestamp('2022/07/14 15:00:00'); Query OK, 1 row affected (0.00 sec) # 查看是否删除成功 mysql> select value from history_uint where itemid=211620 and clock >= unix_timestamp('2022/07/14 14:41:00') and clock <= unix_timestamp('2022/07/14 15:00:00'); Empty set (0.00 sec)

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。