Zabbix表字段类型和value type问题

184次阅读

没有评论

共计 3854 个字符，预计需要花费 10 分钟才能阅读完成。

最近在帮同事搞 spark streaming 的监控，主要是通过解析 servlet 的 url 来获取对应的监控值。

其中有部分值是和时间戳有关系的，Java 的时间戳是精确到 ms 的，是 13 位。

在添加监控后，发现不能正常获取到值。
在 agent 端，直接通过 zabbix_get 测试，是可以拿到值的，证明和 item 值的获取没有关系, 从日志也可以看出，item 的 value 是正常发送出去的。

一些 Zabbix 相关教程集合 ：

安装部署分布式监控系统 Zabbix 2.06 http://www.linuxidc.com/Linux/2013-07/86942.htm

《安装部署分布式监控系统 Zabbix 2.06》http://www.linuxidc.com/Linux/2013-07/86942.htm

CentOS 6.3 下 Zabbix 安装部署 http://www.linuxidc.com/Linux/2013-05/83786.htm

Zabbix 分布式监控系统实践 http://www.linuxidc.com/Linux/2013-06/85758.htm

CentOS 6.3 下 Zabbix 监控 apache server-status http://www.linuxidc.com/Linux/2013-05/84740.htm

CentOS 6.3 下 Zabbix 监控 MySQL 数据库参数 http://www.linuxidc.com/Linux/2013-05/84800.htm

agent 的日志：

87104:20140612:063124.064 In zbx_popen() command:’Python /apps/sh/zabbix_scripts/spark/spark-monitor-streaming.py streaming-color.StreamingMetrics.streaming.lastReceivedBatch_submissionTime’

87104:20140612:063124.064 End of zbx_popen():5

231239:20140612:063124.064 zbx_popen(): executing script

87104:20140612:063124.201 In zbx_waitpid()

87104:20140612:063124.201 zbx_waitpid() exited, status:0

87104:20140612:063124.201 End of zbx_waitpid():231239

87104:20140612:063124.201 Run remote command [python /apps/sh/zabbix_scripts/spark/spark-monitor-streaming.py streaming-color.StreamingMetrics.streaming.lastReceivedBatch_submissionTime] Result [13] [1402481880037]…

87104:20140612:063124.201 For key [spark_stream[streaming-color.StreamingMetrics.streaming.lastReceivedBatch_submissionTime]] received value [1402481880037]

87104:20140612:063124.201 In process_value() key:’xxxxx:spark_stream[streaming-color.StreamingMetrics.streaming.lastReceivedBatch_submissionTime]’ value:’1402481880037′

通过数据库开始入手，先来看 proxy 的 proxy_history 表对应的 item 的值：

select itemid,from_unixtime(clock),value from proxy_history where itemid=’106018′ order by itemid;

+——–+———————-+———————-+

| itemid | from_unixtime(clock) | value |

+——–+———————-+———————-+

| 106018 | 2014-06-12 11:42:47 | 1402481880037.000000 |

| 106018 | 2014-06-12 11:17:29 | 1402481880037.000000 |

| 106018 | 2014-06-12 11:30:17 | 1402481880037.000000 |

可以看到值被转换成 float 的形式（如果 item 值的类型设置为 float 型，会精确度 6 位小数），而 value 的类型是 longtext，所以这里插入 proxy 的表不会出错。

从 proxy 的日志可以看出，proxy 通过 get_values 获取到值，调用 substitute_key_macros 对值进行处理，最后调用 send_data_to_server 将数据发送到 server.

再来看 server 的数据情况，通过 items 表可以查看对应监控项的 lastvalue（items 的 lastvalue 是 varchar(255) 的，很少出现 type 问题）和 error 情况：

select b.itemid,b.key_,b.lastvalue,b.error from hosts a,items b where a.hostid=b.hostid and a.host=’xxxxx’ and b.key_ like ‘spark_stream[%Time]’;

itemid|key_lastvalue|error

|106018| spark_stream[streamingcolor.StreamingMetrics.streaming.lastReceivedBatch_submissionTime] | 1402481880037 | Type of received value [1402481880037.000000] is not suitable for value type [Numeric (float)] |

可以看到报错信息是和 value type 有关系的 (之前也处理过一个类似的 case:http://caiguangguang.blog.51cto.com/1652935/1377089)，再来 review 下 history 相关表的 value 数据类型：

item 为 float 类型时，value 的字段类型是 double(16,4)，即总 16 位，其中小数占 4 位，这里因为 java 的时间戳为 13 位，超过了这个限制，导致数据插入报错。

desc history

+——–+———————+——+—–+———+——-+

+——–+———————+——+—–+———+——-+

| clock | int(11) | NO | | 0 | |

| value | double(16,4) | NO | | 0.0000 | |

+——–+———————+——+—–+———+——-+

把 item 的 value type 改为 unsigned 即可：

这种类型的数据存储在 history_uint 表里面，其 value 的字段类型是 bigint(20）, 一般不会到达限制。

desc history_uint;

+——–+———————+——+—–+———+——-+