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

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

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

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
+--------+---------------------+------+-----+---------+-------+
| 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）,一般不会到达限制。

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字段可以快速的定位问题.