前言
因开发需求，需要解析Zabbix web监控数据表结构；因为网上关于Zabbix数据表结构解析的比较少，所以心血来潮写了一篇作为记录。
突破口
对
Zabbix数据库表结构做解析的时候，我有个习惯，直接针对某个itemid怼。
这次当然不例外，随便找了个Zabbix web itemid。
直接查数据库里有哪些表
show tables like "%http%";
+---------------------------+
| Tables_in_zabbix (%http%) |
+---------------------------+
| httpstep |
| httpstep_field |
| httpstepitem |
| httptest |
| httptest_field |
| httptestitem |
+---------------------------+用屁股猜已经猜出大概存储的是什么内容：
-
httpstep存储的为场景信息 -
httpstepitem存储的为场景ID -
httptest存储的为步骤信息 -
httptestitem存储的为步骤ID
剖析
以itemid为突破口
获取到这个场景的itemID
查询这个item所在的testID与testitemID
select * from httptestitem where itemid="56263" ;
+----------------+------------+--------+------+
| httptestitemid | httptestid | itemid | type |
+----------------+------------+--------+------+
| 1194 | 398 | 56263 | 4 |
+----------------+------------+--------+------+根据这个itemid我们找到他对应的场景id。
获取这个场景的几个监控item值
- Last error message of scenario
- Download speed for scenario
- Failed step of scenario
select * from httptestitem where httptestid="398";
+----------------+------------+--------+------+
| httptestitemid | httptestid | itemid | type |
+----------------+------------+--------+------+
| 1192 | 398 | 56261 | 2 |
| 1193 | 398 | 56262 | 3 |
| 1194 | 398 | 56263 | 4 |
+----------------+------------+--------+------+解析一波，具体自己参照Latest data
#############
# 各Type剖析
#
# type类型为2代表【Download speed for scenario】
# 场景总下载速度,历史数据存储在history表.
#
# type类型为3代表【Failed step of scenario】
# 场景返回状态码, 0表示场景正常, 每个步骤异常为1.历史数据存储在history_uint表.
#
# type类型为4代表【Last error message of scenario】
# 上一次场景返回错误信息,历史数据存储在history_str表.
#
#############
接下来根据场景ID找出步骤
查询http场景下的步骤
- Download speed for step
- Response time for step
- Response code for step
select * from httpstepitem where httpstepid="398";
+----------------+------------+--------+------+
| httpstepitemid | httpstepid | itemid | type |
+----------------+------------+--------+------+
| 1192 | 398 | 56180 | 2 |
| 1193 | 398 | 56181 | 1 |
| 1194 | 398 | 56182 | 0 |
+----------------+------------+--------+------+解析一波，具体自己参照Latest data
#############
# 各Type剖析
#
# type类型为2代表【Download speed for step】
# 步骤的下载速度,历史数据存储在history表.
#
# type类型为1代表【Response time for step】
# 步骤返回时间,历史数据存储在history表.
#
# type类型为0代表【Response code for step】
# 步骤的返回状态码, 其中0为无法连接,无状态码.历史数据存储在history_uint表.
#
#############接下来剖析详细场景与步骤
根据ID查询场景信息
自行对应ZabbixWEB界面
select * from httptest where httptestid="398" \G;
*************************** 1. row ***************************
httptestid: 398
name: 业务接口A
applicationid: 800
nextcheck: 1542984224
delay: 1m
status: 0
agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/38.0.2125.104 Safari/537.36
authentication: 0
http_user:
http_password:
hostid: 10084
templateid: 397
http_proxy:
retries: 1
ssl_cert_file:
ssl_key_file:
ssl_key_password:
verify_peer: 0
verify_host: 0顺便简单介绍下场景下的字段表，也就是一些自定宏
select * from httptest_field limit 1;
+------------------+------------+------+----------+-------------------+
| httptest_fieldid | httptestid | type | name | value |
+------------------+------------+------+----------+-------------------+
| 1 | 535 | 1 | {IP} | 10.1.1.1 |
+------------------+------------+------+----------+-------------------+
# type为1表示 Variables.
# type为0表示 Headers.接下来查看场景里面的步骤 自行参照Steps页面
查询指定ID的步骤
select * from httpstep where httptestid="398"\G;
*************************** 1. row ***************************
httpstepid: 412
httptestid: 398
name: 业务接口A
no: 1
url: https://baidu.com
timeout: 15s
posts:
required:
status_codes:
follow_redirects: 0
retrieve_mode: 0
post_type: 0
# no代表场景的步骤
# required表示步骤正常返回字符串,填写内容为正则表达式.步骤也有map字段表
select * from httpstep_field limit 1;
+------------------+------------+------+----------+---------------------+
| httpstep_fieldid | httpstepid | type | name | value |
+------------------+------------+------+----------+---------------------+
| 1 | 129 | 1 | {rentid} | regex:([0-9]{4,10}) |
+------------------+------------+------+----------+---------------------+
# type为0表示 Headers.
# type为1表示 Variables.
# type为2表示 Post fields.后记
文章一些数据表字段不明白都可以参照ZabbixWEB配置页面。
另外建议大家Zabbix二次开发的时候可以怼库就怼库，遇到逻辑复杂没有把握才使用API。