首先贴出一张网上找的一张关于zabbix报警相关表结构及表关联逻辑图:
前端
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事件一共有三种,分别为:触发器事件、发现事件、内部事件、自动注册事件。3d
zabbix内部事件日志
zabbix发现事件code
zabbix触发事件orm
触发器状态发生变化生成一个包含详细状态信息的触发器事件server
zabbix自动注册事件blog
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媒介类型包括mail、sms、自定义脚本。
media_type表
MariaDB [rtm]> select * from media_type\G; *************************** 1. row *************************** mediatypeid: 1 type: 0 description: Email smtp_server: mail.company.com smtp_helo: company.com smtp_email: rtm@company.com 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: jabber@company.com 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}\n 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表数据来自用户配置的报警媒介。
MariaDB [rtm]> show create table alerts\G; *************************** 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为自定义脚本操做将阻塞队列排空。
不过下来研究过表结构和事件逻辑,我以为能够这样尝试解决:
还有一种方法就是在zabbix的general下的管家下面设置事件和报警相关数据存储时间为一天,这样其实也是经过删除数据库数据解决,不过是zabbix管家主动帮咱们作了。
时间仓促,后面再补充。。。。。。