zabbix表字段类型和value type问题

本文解决了一个关于Zabbix监控中无法正确获取Spark Streaming时间戳监控值的问题。问题根源在于数据库表字段类型不匹配,导致长整型时间戳无法正确存储。通过调整item的值类型为无符号解决了此问题。

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

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

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

agent的日志:

1
2
3
4
5
6
7
8
9
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的值:

1
2
3
4
5
6
7
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情况:

1
2
3
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位,超过了这个限制,导致数据插入报错。

1
2
3
4
5
6
7
8
desc  history
+--------+---------------------+------+-----+---------+-------+
| Field  | Type                | Null | Key | Default | Extra |
+--------+---------------------+------+-----+---------+-------+
| itemid | bigint(20) unsigned | NO   | MUL | NULL    |       |
| clock  | int(11)             | NO   |     | 0       |       |
| value  | double(16,4)        | NO   |     | 0.0000  |       |
+--------+---------------------+------+-----+---------+-------+

把item的value type改为unsigned即可:

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

1
2
3
4
5
6
7
8
9
desc history_uint;
+--------+---------------------+------+-----+---------+-------+
| Field  | Type                | Null | Key | Default | Extra |
+--------+---------------------+------+-----+---------+-------+
| itemid | bigint(20) unsigned | NO   | MUL | NULL    |       |
| clock  | int(11)             | NO   |     | 0       |       |
| value  | bigint(20) unsigned | NO   |     | 0       |       |
| ns     | int(11)             | NO   |     | 0       |       |
+--------+---------------------+------+-----+---------+-------+

小结:

在处理zabbix item的问题时,通过zabbix_get并结合items表的error字段可以快速的定位问题.



本文转自菜菜光 51CTO博客,原文链接:http://blog.51cto.com/caiguangguang/1427490,如需转载请自行联系原作者

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值