1Triggers(触发器)
描述 |
详细 |
备注 |
术语描述 |
1)触发器是评估监控项采集的数据的逻辑表达式,代表了当前系统状态。 2)触发器可定义一个什么数据是可接受的阈值,因此,如果接收的数据超过了可接受的状态,则触发器会被触发 - 或将状态更改为PROBLEM. |
触发器状态:OK/PROBLEM |
其他 |
如果在表达式中使用基于时间的函数(nodata(), date(), dayofmonth(), dayofweek(), time(), now()),触发器就会由Zabbix timer进程每30秒重新计算一次。如果在表达式中同时使用基于时间和非基于时间的函数,当接收到一个新值和每隔30秒都会重新计算触发器的状态 |
1.1创建触发器
描述 |
详细 |
备注 |
配置 |
1点击Zabbix上方菜单栏的Configuration → Hosts 2在Host那一行点击Triggers 3在右上角点击Create Trigger(或者在触发器名称上编辑一个现有的触发器) 4在打开的页面输入触发器的参数 |
https://www.zabbix.com/documentation/3.4/manual/config/triggers/trigger |
配置项 |
1)Name:触发器名称 可能包含支持的macros:{HOST.HOST}, {HOST.NAME}, {HOST.CONN}, {HOST.DNS}, {HOST.IP}, {ITEM.VALUE},{ITEM.LASTVALUE} 和 {$MACRO}。 $1, $2…$9宏可以用来指代第一、第二至第九个表达式的常量。 2)Severity:通过点击对应的按钮来设置所需的触发器severity, 3) Problem expression:用于定义问题条件的逻辑表达式 |
备注:$1-$9如果引用了相对简单的常量或易懂的表达式,宏将会正确解析。例如,如果表达式为{New host:system.cpu.load[percpu,avg1].last()}>5,则名为“Processor load above $1 on {HOST.NAME}“的触发器名称将自动更改为”Processor load above 5 on New host” |
触发器表达式 |
简单表达式: {<server>:<key>.<function>(<parameter>)}<operator><constant> 说明: 1)Function:函数,从zabbix支持的函数列表中选择(如avg,change…) 2)Parameter;函数参数 a) 数字函数中允许秒数作为参数,如sum(30),统计30s内的所有值之和 b) 可使用前缀#指定参数具有不同意义,如sum(#5),统计最后5个值的和 c) Last函数以#作为前缀时,表示选择指定位置的值,如给定值3、7、2、6、5(按照时间顺序,第一个值3为最新值),last(#2) 将返回值为7 ,last(#5) 将返回值为5。 3) Operators,运算符 4)value caching值缓存:触发器请求的数据缓存在zabbix server(且不会因监控项历史数据移除而清除) 5)样例;{Zabbix-server:system.cpu.load[all,avg1].last()}>5 { Zabbix-server:system.cpu.load[all,avg1].last()}>5 or { Zabbix-server:system.cpu.load[all,avg1].min(10m)}>2 6) Hysteresis:滞变(如温度超过20c,保持一个状态,直到温度下降到15c),需要使用自动发现规则:Recovery expression,输入一个恢复表达式。仅当问题事件先处理才能出发恢复表达式。问题表达式({server:temp.last()}>20)恢复表达式({server:temp.last()}<=15 |
1)Zabbix支持的函数列表: https://www.zabbix.com/documentation/3.4/manual/appendix/triggers/functions 2)avg, count, last, min and max 函数支持额外的第二个参数time_shift(时间偏移量)。这个参数允许从过去一段时间内引用数据。例如,avg(1h,1d)将会返回一天前1小时的平均值。 注意:触发器需要使用history历史数据来计算。如果历史数据不可用(特别是关于time_shift时间偏移量),则无法使用趋势信息,因此必须至少保持触发器函数所预期这段时间的历史信息。 |
触发器依赖 |
主机之间某些依赖关系可能有用的地方,依赖关系设置的通知可能会被抑制,而只发送根本问题的通知。 |
|
触发器严重性 |
2 Events(事件)
描述 |
详细 |
备注 |
概述 |
trigger events(触发器事件) discovery events - 发现事件 uto registration events - 自动注册事件,当主动的agents被自动注册到server时 internal events - 内部事件,当监控项item/自动发现规则low-level |
|
触发器事件生成 |
触发器会创建两种类型的事件:问题(Problem)和正常(OK)。 |
|
3 事件通知
3.1media类型
描述 |
详细 |
备注 |
邮件 |
AdministrationàMedia typesàcreate media typeà Name:Email Type:Email SMTP server:localhost SMTP port:25 SMTP helo:localhost SMTP email:[email protected] à点击add |
|
短信(sms) |
触发器会创建两种类型的事件:问题(Problem)和正常(OK)。 |
|
Jabber(即时通讯) |
||
Ez Texting(zabbix的技术合作伙伴,提供美国加拿大的手机号短信服务) |
4 宏(macros)
3.1media类型
描述 |
详细 |
备注 |
概述 |
宏是一个变量,在上下文中,宏解析为一个特殊的值。 |
|
宏函数 |
语法:{<macro>.<func>(<params>)} <macro> - 这个参数为要定义的宏 <func> - 要应用的函数; <params> - 以逗号分隔的函数参数列表。如果他们以 (空格), " 或者包含 ), ,这些符号开始,则参数必须要引用。 例如:{{ITEM.VALUE}.regsub(pattern, output)} |
如果在受支持的位置使用函数,但是应用于不支持宏函数的宏, 那么宏的计算结果为 “UNKNOWN”。 如果在不支持宏函数的位置将宏函数应用于宏, |
自定义宏(用户宏) |
管理 → 常规 → 右上角下拉菜单选择 “宏” |
|
自动发现(LLD)宏 |
5 服务监控(service monitoring)
描述 |
详细 |
备注 |
概述 |
服务监控(services monitoring)旨在帮助那些想要高级(业务)基础设施的监控的人。在许多情况下,我们关注的不是底层细节,比如磁盘空间不足、CPU 负载高等。我们关注的是IT部门提供的可用性的服务。我们还对确定IT基础设施薄弱的地方,IT各种服务级协定(SLA),现有的IT基础设施的结构,以及其他的信息感兴趣 |
该结构的每个节点都具有属性状态。根据选择算法进行状态计算并传播到上层节点。服务(services)最底层的服务是触发器。该节点的状态依赖于触发器的状态。 |
配置 |
配置(Configuration)→服务(services) àname: server1 Paraent service: root Status calculation algorithm:状态计算算法(不计算、至少一个节点有问题,所有节点都有问题) Calculate SLA, acceptable SLA (in %):可接受的SAL(% 计)(Acceptable SLA) Trigger:选择触发器 Sort order:显示排序,数字小的优先 |
最高的父节点服务是 ‘root‘。您可以通过添加低级服务节点和各个节点服务创建下层层次结构。 |
原文地址:https://www.cnblogs.com/cslj2013/p/9182417.html