zabbix报警逻辑初探
Posted liao-lin
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了zabbix报警逻辑初探相关的知识，希望对你有一定的参考价值。
zabbix报警逻辑初探
首先贴出一张网上找的一张关于zabbix报警相关表结构及表关联逻辑图：
actions表
actions表对应前端配置是动作(actions)
action由condition(条件)和operations(操作)组成。当满足指定的条件，然后执行操作。发送内容在动作里配置(比如默认情况下没有加上报警产生时间，可以人为加上去)。
MariaDB [rtm]> desc actions;
+---------------+---------------------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+---------------+---------------------+------+-----+---------+-------+
| actionid | bigint(20) unsigned | NO | PRI | NULL | |
| name | varchar(255) | NO | UNI | | |
| eventsource | int(11) | NO | MUL | 0 | |
| evaltype | int(11) | NO | | 0 | |
| status | int(11) | NO | | 0 | |
| esc_period | int(11) | NO | | 0 | |
| def_shortdata | varchar(255) | NO | | | |
| def_longdata | text | NO | | NULL | |
| recovery_msg | int(11) | NO | | 0 | |
| r_shortdata | varchar(255) | NO | | | |
| r_longdata | text | NO | | NULL | |
| formula | varchar(255) | NO | | | |
+---------------+---------------------+------+-----+---------+-------+
actionid: action的id
name： action的名称
eventsource： 对应events表的source
evaltype: conditions里计算方式的id(0:and/or, 1:and, 2:or, 3:自定义表达式)
status: 启用状态(0启用， 1禁用)
esc_period: 步骤操作持续时间
def_shortdata: subject
def_longdata: message内容
recovery_msg: 恢复消息启用状态，1-启用
r_shortdata： 恢复subject
r_longdata 恢复message
fromula: conditions里自定义的表达式zabbix事件
zabbix事件一共有三种，分别为：触发器事件、发现事件、内部事件、自动注册事件。
zabbix内部事件
- 监控项item状态从normal变为unsupported，或者从unsupported变为normal
- low-level发现规则状态从normal变为unsupported，或者从unsupported变为normal
- 触发器状态从normal变为unknown，或者从unknown变为normal
zabbix发现事件
- 配置网络发现规则之后，zabbix会定期按照这个规则去扫描IP段，一旦发现主机和服务，便生成一个事件
- zabbix自动发现
zabbix触发事件
触发器状态发生变化生成一个包含详细状态信息的触发器事件
zabbix自动注册事件
active agent主动与server通信，zabbix server使用agent通信的ip地址与端口来添加主机，并生成一个自动注册事件
events表
MariaDB [rtm]> select * from events where source=0;
+---------+--------+--------+----------+------------+-------+--------------+-----------+--------------------------------------------+
| eventid | source | object | objectid | clock | value | acknowledged | ns | description |
+---------+--------+--------+----------+------------+-------+--------------+-----------+--------------------------------------------+
| 317 | 0 | 0 | 13075 | 1548827260 | 0 | 0 | 399008160 | 99.9512<5 |
| 318 | 0 | 0 | 13467 | 1548827312 | 0 | 0 | 696464358 | (0=0 and 0.1854>75) or (0=1 and 0.1854>65) |
| 308 | 0 | 0 | 13468 | 1548827253 | 0 | 1 | 367035016 | (0=0 and 0>75) or (0=1 and 0>65) |
| 309 | 0 | 0 | 13469 | 1548827254 | 0 | 0 | 352296205 | (0=0 and 0>75) or (0=1 and 0>65) |
| 310 | 0 | 0 | 13470 | 1548827255 | 0 | 0 | 363172506 | (0=0 and 0>75) or (0=1 and 0>65) |
| 311 | 0 | 0 | 13471 | 1548827256 | 0 | 0 | 375124809 | (0=0 and 0.0169>75) or (0=1 and 0.0169>65) |
| 319 | 0 | 0 | 13472 | 1548827257 | 0 | 0 | 373863748 | (0=0 and 2.5554>75) or (0=1 and 2.5554>65) |
| 320 | 0 | 0 | 13473 | 1548827258 | 0 | 0 | 381757318 | (0=0 and 0.0846>75) or (0=1 and 0.0846>65) |
| 321 | 0 | 0 | 13474 | 1548827259 | 0 | 0 | 388674314 | (0=0 and 0.2199>75) or (0=1 and 0.2199>65) |
| 322 | 0 | 0 | 13475 | 1548827260 | 0 | 0 | 398635590 | (0=0 and 0>75) or (0=1 and 0>65) |
| 323 | 0 | 0 | 13479 | 1548827264 | 0 | 0 | 425321837 | (0=0 and 3.1495>75) or (0=1 and 3.1495>65) |
| 324 | 0 | 0 | 13480 | 1548827265 | 0 | 0 | 429536321 | (0=0 and 0>75) or (0=1 and 0>65) |
| 325 | 0 | 0 | 13481 | 1548827266 | 0 | 0 | 439574519 | (0=0 and 0>75) or (0=1 and 0>65) |
| 326 | 0 | 0 | 13482 | 1548827267 | 0 | 0 | 441541684 | (0=0 and 0>75) or (0=1 and 0>65) |
| 327 | 0 | 0 | 13483 | 1548827268 | 0 | 0 | 448121449 | (0=0 and 0>75) or (0=1 and 0>65) |
| 328 | 0 | 0 | 13484 | 1548827269 | 0 | 1 | 460702185 | (0=0 and 0.0406>75) or (0=1 and 0.0406>65) |
action里可根据事件源(四个事件类型)创建不同的动作。和这里的source是对应起来的。
objectid对应的是triggers表里的triggerid
value等于0就是OK，等于1就是PROBLEM
acknowledged=0就是未确认，等于1就是已确认
source=0的就是触发器事件
source=1的就是自动发现事件
source=2的就是自动注册事件
source=3的就是内部事件zabbix报警媒介自定义
zabbix媒介类型包括mail、sms、自定义脚本。
media_type表
MariaDB [rtm]> select * from media_typeG;
*************************** 1. row ***************************
mediatypeid: 1
type: 0
description: Email
smtp_server: mail.company.com
smtp_helo: company.com
smtp_email: [email protected]
exec_path:
gsm_modem:
username:
passwd:
status: 0
smtp_port: 25
smtp_security: 0
smtp_verify_peer: 0
smtp_verify_host: 0
smtp_authentication: 0
exec_params:
*************************** 2. row ***************************
mediatypeid: 2
type: 3
description: Jabber
smtp_server:
smtp_helo:
smtp_email:
exec_path:
gsm_modem:
username: [email protected]
passwd: rtm
status: 0
smtp_port: 25
smtp_security: 0
smtp_verify_peer: 0
smtp_verify_host: 0
smtp_authentication: 0
exec_params:
*************************** 3. row ***************************
mediatypeid: 3
type: 2
description: SMS
smtp_server:
smtp_helo:
smtp_email:
exec_path:
gsm_modem: /dev/ttyS0
username:
passwd:
status: 0
smtp_port: 25
smtp_security: 0
smtp_verify_peer: 0
smtp_verify_host: 0
smtp_authentication: 0
exec_params:
*************************** 4. row ***************************
mediatypeid: 4
type: 1
description: 智能告警
smtp_server:
smtp_helo:
smtp_email:
exec_path: sr_event/sr_event_client/sr_event_client.py
gsm_modem:
username:
passwd:
status: 0
smtp_port: 25
smtp_security: 0
smtp_verify_peer: 0
smtp_verify_host: 0
smtp_authentication: 0
exec_params: {ALERT.SUBJECT}
4 rows in set (0.00 sec)
media表
MariaDB [rtm]> desc media;
+-------------+---------------------+------+-----+-----------------+-------+
| Field | Type | Null | Key | Default | Extra |
+-------------+---------------------+------+-----+-----------------+-------+
| mediaid | bigint(20) unsigned | NO | PRI | NULL | |
| userid | bigint(20) unsigned | NO | MUL | NULL | |
| mediatypeid | bigint(20) unsigned | NO | MUL | NULL | |
| sendto | varchar(100) | NO | | | |
| active | int(11) | NO | | 0 | |
| severity | int(11) | NO | | 63 | |
| period | varchar(100) | NO | | 1-7,00:00-24:00 | |
+-------------+---------------------+------+-----+-----------------+-------+media表数据来自用户配置的报警媒介。
alerts表
MariaDB [rtm]> show create table alertsG;
*************************** 1. row ***************************
Table: alerts
Create Table: CREATE TABLE `alerts` (
`alertid` bigint(20) unsigned NOT NULL,
`actionid` bigint(20) unsigned NOT NULL,
`eventid` bigint(20) unsigned NOT NULL,
`userid` bigint(20) unsigned DEFAULT NULL,
`clock` int(11) NOT NULL DEFAULT '0',
`mediatypeid` bigint(20) unsigned DEFAULT NULL,
`sendto` varchar(100) COLLATE utf8_bin NOT NULL DEFAULT '',
`subject` varchar(255) COLLATE utf8_bin NOT NULL DEFAULT '',
`message` text COLLATE utf8_bin NOT NULL,
`status` int(11) NOT NULL DEFAULT '0',
`retries` int(11) NOT NULL DEFAULT '0',
`error` varchar(128) COLLATE utf8_bin NOT NULL DEFAULT '',
`esc_step` int(11) NOT NULL DEFAULT '0',
`alerttype` int(11) NOT NULL DEFAULT '0',
PRIMARY KEY (`alertid`),
KEY `alerts_1` (`actionid`),
KEY `alerts_2` (`clock`),
KEY `alerts_3` (`eventid`),
KEY `alerts_4` (`status`,`retries`),
KEY `alerts_5` (`mediatypeid`),
KEY `alerts_6` (`userid`),
CONSTRAINT `c_alerts_1` FOREIGN KEY (`actionid`) REFERENCES `actions` (`actionid`) ON DELETE CASCADE,
CONSTRAINT `c_alerts_2` FOREIGN KEY (`eventid`) REFERENCES `events` (`eventid`) ON DELETE CASCADE,
CONSTRAINT `c_alerts_3` FOREIGN KEY (`userid`) REFERENCES `users` (`userid`) ON DELETE CASCADE,
CONSTRAINT `c_alerts_4` FOREIGN KEY (`mediatypeid`) REFERENCES `media_type` (`mediatypeid`) ON DELETE CASCADE
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin
1 row in set (0.00 sec)列出这个表结构是因为遇到过zabbix邮件队列阻塞，解决办法网上很少有资料，因此自己去后台查看了表信息。网上说有人通过删数据库数据解决。而且zabbix界面的动作日志数据都来自这张表。
删数据解决我没尝试过，我通过引流方式将原来阻塞的邮件方式转换为mediatypeid为自定义脚本操作将阻塞队列排空。
不过下来研究过表结构和事件逻辑，我觉得可以这样尝试解决：
- 备份events和alerts表
- 查找出阻塞这段时间的events，根据这个eventsid去删除events相关记录和alerts相关记录。
还有一种方法就是在zabbix的general下的管家下面设置事件和报警相关数据存储时间为一天，这样其实也是通过删除数据库数据解决，不过是zabbix管家主动帮我们做了。
时间仓促，后面再补充。。。。。。
以上是关于zabbix报警逻辑初探的主要内容，如果未能解决你的问题，请参考以下文章