zabbix表字段类型和value type问题
2014-06-17 23:21
120 查看
最近在帮同事搞spark streaming的监控,主要是通过解析servlet的url来获取对应的监控值。
其中有部分值是和时间戳有关系的,java的时间戳是精确到ms的,是13位。
在添加监控后,发现不能正常获取到值。
在agent端,直接通过zabbix_get测试,是可以拿到值的,证明和item值的获取没有关系,从日志也可以看出,item的value是正常发送出去的。
agent的日志:
从proxy的日志可以看出,proxy通过get_values获取到值,调用substitute_key_macros对值进行处理,最后调用send_data_to_server将数据发送到server.
再来看server的数据情况,通过items表可以查看对应监控项的lastvalue(items的lastvalue是varchar(255)的,很少出现type问题)和error情况:
item为float类型时,value的字段类型是double(16,4),即总16位,其中小数占4位,这里因为java的时间戳为13位,超过了这个限制,导致数据插入报错。
这种类型的数据存储在history_uint表里面,其value的字段类型是bigint(20),一般不会到达限制。
在处理zabbix item的问题时,通过zabbix_get并结合items表的error字段可以快速的定位问题.
其中有部分值是和时间戳有关系的,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字段可以快速的定位问题.
相关文章推荐
- 有关读取SQL数据库里TEXT和NTEXT类型字段内容的问题
- mysql---使用unsigned字段类型时的问题
- oracle 定长字段查询问题 ,ibatis 与pl/sql查询的char类型字段查询不同
- php 读 mssql 的ntext 字段类型的问题
- Oracle long raw 类型字段读取问题
- ntext类型字段查询问题?
- 关于修改以太网帧头类型字段引发的问题
- oracle 定长字段查询问题 ,ibatis 与pl/sql查询的char类型字段查询不同
- 操作Oracle数据库实现上传图片到Blob类型的字段出现的问题
- 关于Java读取mysql中date类型字段默认值'0000-00-00'的问题
- 读取Excel文件时字段类型的问题
- 关于LINQ字段不同类型做映射问题!
- 解决hibernate中不能正常使用blog类型字段上传数据的问题
- oracle 定长字段查询问题 ,ibatis 与pl/sql查询的char类型字段查询不同
- SQL Server Varchar类型字段中文乱码问题的解决
- 关于smallDateTime类型字段排序的问题
- Hibernate字段映射问题(包装类型与源生类型)
- 关于学习MSDN中"创建自定义字段类型和字段控件"的一些心得跟问题。
- Hibernate连接Oracle的Date类型字段丢失时间问题(解决方案)
- expdp/impdp导入导出Long字段类型产生乱码问题