Zabbix深入分析某

Zabbix深入分析2015 目录
1研究目标4
2系统架构4
2.1Server4
2.2数据库存储〔Database storage〕5
2.3WEB 界面5
2.4Proxy5
2.5Agent5
2.6Get6
2.7Sender6
2.8工作机制6
3WEB界面菜单功能7
4主要功能名词与概念8
SNMP8
IPMP8
配置〔configuration〕8
主机和主机组〔Hosts and host group〕8
模板〔Templates〕9
监控项〔Items〕9
监控〔WEB〕9
触发器〔Triggers〕9
宏〔Macro〕10
事件〔Events〕10
图形〔Grahps〕11
Screen11
报表〔Reports〕12
IT 服务〔ITs〕12
发现〔Discovery〕12
队列〔Queue〕13
应用〔Applications〕13
分布式监控〔Distributed monitoring〕13
维护<Maintenance>13
5监控项类型〔Item Type〕14
5.1Zabbix客户端代理〔Zabbix Agent>14
5.2SNMP代理〔SNMP Agent〕26
5.3SNMP被动方式〔SNMP Trap〕27
5.4IPMI检测27
5.5简单检测27
5.6日志文件监控27
5.7计算监控27
5.8部检查27
5.9SSH检查31
5.10Telnet检查32
5.11外部检查32
5.12汇总检查32
5.13被动监控32
5.14JMX监控32
5.15ODBC监控32
6触发器〔Triggers〕33
6.1概述33
6.2配置触发器33
6.3触发器表达式〔Expression〕33
Function33
Function parameter37
运算符37
触发器举例38
滞留状态39
6.4触发器依赖性〔Dependency〕40
6.5触发器严重性〔Severity〕40
6.6触发器的单位符号〔Unit symbols〕41
单位后缀41
使用举例41
7报警与其策略42
7.1概述42
7.2报警流程42
7.3报警媒介〔Media type〕42
7.4报警动作〔Action〕43
Action〔基本属性〕43
Conditions〔条件〕43
Operations〔操作〕43
7.5报警升级〔Esacalations〕45
8Quickstart46
9数据模型46
10Zabbix API46
10.1概览46
API使用说明46
Zabbix API支持的数据类型47
"get"方法支持的通用参数47
10.2监控48
History48
Events48
Service monitoring48
10.3配置49
Hosts and host groups49
Items and applications50
Triggers50
Grahps51
Templates51
Export and import51
Low-level discovery51
Screens52
Actions and alerts53
ITs53
Maps53
Web monitoring54
Network discovery54
10.4管理54
Users54
General55
Proxies56
Scripts56
10.5API信息56
10.6API引用的对象〔Object〕的属性57
History object57
11图表套件-FusionChats58
11.1概述58
11.2套件59
FusionChartsXT59
FusionWidgetsXT61
PowerChartsXT62
FusionMapsXT63
11.3开发〔PHP〕64
12调研总结64
12.1Zabbix 可监控的基本模块64
12.2Zabbix API65
12.3Zabbix 图表65
外部查看图表可行性65
利用FusionCharts 展现65
12.4报警策略的可定制性65
12.5与Zabbix用户会话同步策略67
统一用户67
动态登录67
13系统的集成67
13.1方案67
方案一：建模块67
方案二：iframe嵌入67
方案三：图表接口68
13.2方案总结68
1研究目标
通过对ZABBIX的研究实现如下目标：
➢熟悉可监控的基本模块
➢研究API,并且要写代码测试到监控任务的API控制,包括创建,暂停,更改选项,删除任务。

➢研究API,写代码看是否能读取到全部监控结果
➢研究Zabbix报表,搞清楚两个问题,
⏹是否能直接调用Zabbix的出图组件或选项或api,
⏹如果Zabbix图形体验不能满足我们的要求,是否我们能拿到出图的全部数据来自己
组织出图〔我们已有的经验有open flash chart,接下来我们可能会采购
fusionchart图表组件>,
➢研究Zabbix的报警策略,看看能否做出根据监控的任务或选项来实施不同的报警规则,看看是否能实现报警级别定义与优先级定义,如果要使用我们自定义的报警策略,看看如果与zb集成。

➢研究Zabbix的用户登录设置,看看如何实现我们的应用集成时免登录〔特别是需要查看监控结果时〕
➢在熟悉了zb的前提下,考虑并设计我们的应用跟zb做集成的方案
2系统架构
图：Zabbix架构
图：Zabbix基本数据流
2.1Server
Server执行轮询和捕获数据,它计算监控项,给用户发送报警信息。

它是Zabbix的核心组件,agent和proxies向它报告系统可用性与完整性的数据。

server本身就可以使用简单服务检测来检测远程网络服务〔比如web服务器和mail服务器〕。

Server是存储有配置文件、统计信息和操作信息的核心资源库,当被监控系统任何一部分出现问题时,它向管理员发送报警信息。

一个基本的ZabbixServer被分为三个不同的组件：Zabbxi Server、基于Web的管理界面〔web frontend〕和数据库存储。

所有的Zabbix配置信息存储在数据库中,Server和frontend与数据库进行交互。

例如,当你用frontend或者API创建一个新的监控项时,事实上是被加入到数据库的监控项表。

然后,大约一分钟后,ZabbixServer将查询监控项表获取
数据库中的可用监控项并把它们存储在Server缓存中。

这就是为什么当你在frontend中做任何改变,需要等两分钟后才会在最新数据这一部分反映出来。

2.2数据库存储〔Database storage〕
所有的配置信息以与Zabbix采集的数据都保存在数据库中。

2.3WEB 界面
为方便从不同平台去访问管理Zabbix,Zabbix提供了一个基于WEB的界面,可以通过界面实现监控与其各项系统配置管理。

WEB界面作为 Zabbix Server的一部分也可以运行在不同的物理服务器上。

2.4Proxy
在Zabbix的部署中Zabbix Proxy是一个可选的组件。

一个Zabbix代理〔Proxies〕可以代表Zabbix服务器收集性能和可用性数据。

这样,代理〔Proxies〕可以负担采集数据的任务并且减轻Zabbix服务器负载。

同时,使用代理〔Proxies〕是实施统一和分布式监控的最简单方式,因为所有的客户端和代理〔Proxies〕向一个Zabbix服务器报告数据,并且所有数据集中保存在服务器数据库。

图：Zabbix Proxy示意图
一个Zabbix代理〔Proxies〕可以用在以下：
➢监控远程区域；
➢监控拥有不可靠的区域；
➢当监控数以千计的设备时分担Zabbix服务器的负载；
➢简化分布式监控的维护；
所有代理〔Proxies〕采集到的数据在传送给服务器之前都保存在本地。

这样,临时与服务器断开连接也不会导致数据丢失。

proxy配置文件中的参数ProxyLocalBuffer 和 ProxyOfflineBuffer控制数据在本地保存多久。

Zabbix代理〔Proxies〕是一个数据收集器。

它不进行触发器计算,处理事件或发送报警信息。

2.5Agent
Zabbix客户端代理〔Agent〕部署在被监控目标上,用于监测本地资源和应用〔硬盘,存,处理器统计等〕。

Zabbix 客户端代理〔Agent 〕用于采集本地当前信息并向Zabbix server 报告以做进一步处理。

在发生故障时〔例如磁盘满或服务进程崩溃〕,Zabbix server 可以积极的发送报警信息提醒管理员注意相应的情况。

由于使用了地系统调用来采集统计信息,Zabbix 客户端代理〔Agent 〕十分高效。

被动与主动检测
Zabbix 客户端代理〔Agent 〕可以执行被动和主动检测。

在被动检测中,Zabbix 客户端代理〔Agent 〕负责数据请求。

服务器或代理请求数据,例如,CPU 负载,客户端代理返回结果。

主动检测需要更复杂的处理。

Zabbix 客户端代理〔Agent 〕首先必须从服务器获取监控项列表来进行独立处理,然后它将定期发送新数据给服务。

可以通过选择各自的监控项类型来决定执行主动检测还是被动检测。

Zabbix 客户端代理〔Agent 〕处理监控项类型为'Zabbix agent' 或 'Zabbix agent <active>'的检测。

2.6 Get
Zabbix_get 是一个用来与Zabbix agent 通信并从Zabbix agent 获取所需信息的程序。

这个工具常用来客户端排错。

2.7 Sender
Zabbix_Sender 是用于向ZabbixServer 发送性能数据进行处理的命令行工具。

这个工具常用于执行需要长时间运行的用户脚本并发送可用性与性能数据。

2.8 工作机制
Item Trigger Event
Action 3
21图：报警流程
器对应的操作。

因此,如果你想收到 CPU load it too high on Server X这样的报警,你必须首先为 Server X创建一个主机〔Host〕,然后在主机中创建一个采集CPU load的监控项〔item〕,然后创建一个触发器〔trigger〕来判断cpu 负载是否高了,然后在创建一个操作〔action〕,用于当cpu负载高时发送报警。

这看起来是很复杂的,使用模版之后,将完全不是这样的。

但是,由于这样的设计,可以进行非常灵活的设置。

3WEB界面菜单功能
✧监控〔Monitoring〕
仪表盘〔Dashboard〕
总览〔Overview〕
〔WEB〕
最新数据〔Latest data〕
触发器〔Triggers〕
事件〔Events〕
图形〔Graphs〕
多屏〔Screens〕
拓扑图〔Maps〕
发现〔Discovery〕
IT服务〔ITs〕
✧资产〔Inventory〕
总览〔Overview〕
主机〔Hosts〕
✧报表〔Reports〕
Zabbix状态〔Status of Zabbix〕
可用性报表〔Availability report〕
触发器Top 100〔Triggers top 100〕
自定义条状图报表〔Bar reports〕
✧配置〔Configuration〕
主机组〔Host groups〕
模板〔Templates〕
主机〔Hosts〕
维护〔Maintenance〕
〔WEB〕
动作〔Actions〕
多屏〔Screens〕
简报片显示〔Slide shows〕
拓扑图〔Maps〕
发现〔Discovery〕
IT服务〔ITs〕
管理〔Administration〕
一般〔General〕
节点管理〔DM〕
认证〔Authentication〕
用户〔Users〕
示警媒体类型〔Media types〕
脚本〔Scripts〕
审计〔Audit〕
队列〔Queue〕
警报〔Notifications〕
4主要功能名词与概念
4.1.1SNMP
也是agent的一种,指支持SNMP协议的设备〔也可以是服务器〕,通过设定SNMP的参数将相关监控数据传送至服务器端〔大部份的交换机、防火墙等网络设备都支持SNMP协议〕。

4.1.2IPMP
Agent的另一种方式,主要应用于设备的物理性能监控,例如设备的温度、风扇的转速等。

4.1.3配置〔configuration〕
在Zabbix中一切的开始需从配置开始,可以配置的包含主机组、主机、监控模板、被监控主机的维护时段、web、动作〔Action〕、拓扑图、维护等等。

Zabbix提供将所有配置导出为标准XML格式的文件,同样,也支持导入标准格式的XML 配置文件。

4.1.4主机和主机组〔Hosts and host group〕
Host是Zabbix监控的基本载体,所有的监控项都是基于host的。

要想使用Zabbix做监控我们的设备的话第一步就是创建一个主机,只有创建了主机才能监控并且查看该设备的各种性能参数图表。

主机组就是对主机的一个多对多分组。

4.1.5模板〔Templates〕
如果有大量的同一类设备,需要监控的信息也大致类似,一个个去修改相关参数比较麻烦,我们可以通过创建一个template来简化操作。

4.1.6监控项〔Items〕
Item是监控项,是监控的基本元素,每一个监控项对应一个被监控端的采集值。

在Configuration->Hosts界面,我们能看到每个host所包含的items总数,点击对应主机的items项,可以看到具体的每个item信息,这些items可以引用自templates,也可以自己创建。

4.1.7监控〔WEB〕
WEB是针对的性能监控,主要是speed〔每秒下载速度〕、Response time〔响应时间〕、Response code〔响应代码,状态码〕,也可以检查目标html页面所包含的预先定义的字符串。

要激活监控〔Web Monitoring〕,你需要定义web方案。

一个web方案由一个或多个请求或步骤组成。

Zabbix服务器以预定义的顺序顶起执行这些步骤。

在任何web方案中都将收集下面的信息：
➢整个方案所有步骤的平均下载时间,以秒计；
➢失败的步数；
➢最后一个错误信息；
在任何web方案的每一步将收集下面的信息：
➢每秒下载速度；
➢响应时间；
➢响应代码；
Zabbix也能够检查获取到的HTML页面是否包含预定义的字符串。

它可以执行一个虚拟的登录表单提交等。

Zabbix监控〔Web Monitoring〕支持和S两种情况。

当执行一个web方案时,Zabbix 经常接受重定向。

在执行一个方案期间,cookies被保存。

4.1.8触发器〔Triggers〕
触发器是评估监控项收集到的数据的逻辑表达式,然后反应系统的当前状态。

监控项是用来收集系统数据的,一直等着出现报警或者值得注意的情况是不切实际的。

评估数据的工作可以交给触发器做。

监控项表达式可以定义一个可接受数据的阀值。

因此,当输入数据超越了可接受状态,触发器发动－－或者把状态变为PROBLEM。

一个触发器可能有下列状态：
值描述
OK 触发器的正常状态。

PROBLEM 通常意味着有情况发生。

举个例子说,处理器负载太高。

4.1.9宏〔Macro〕
Zabbix支持可以在各种场合可以使用的大量宏〔Marcos〕。

有效使用宏〔Marcos〕可以让你节省时间并且让配置文件更清晰。

这里的宏〔Marcos〕是和C语言里的宏的作用一样,是用一个简单的宏名称来替代繁琐的代码片段。

为了更高的灵活性,Zabbix支持用户宏〔Marcos〕它们可以在全局、模版级别和主机级别定义。

这些宏〔Marcos〕有一个特殊的语法：〔$MACRO〕。

宏〔Marcos〕可以使用在下列情况：
●监控项关键字和描述
●触发器表达式和名称
●其他
宏〔Marcos〕名字可以使用下面的字母：A－Z,0－9,_,.
zabbix替代宏按照下面的优先权：
✓主机级别宏〔优先检查〕
✓为主机第一层模版定义的宏〔即直接到主机的模版〕,以模版ID存储
✓为主机第二层模版定义的宏,以模版ID存储
✓为主机第三层模版定义的宏,以模版ID存储
✓…
✓全局宏 <最后检查>
换句话说,如果主机中没有存在宏,zabbix将增加深度在主机模版中寻找。

如果仍然没有找到,并且全局宏存在,则使用全局宏
4.1.10事件〔Events〕
Zabbix中的事件被三种源生成：
➢触发器〔triggers〕 - 任何时候一个触发器改变它的状态；
➢发现〔discovery〕 - 检查到主机或服务时；
➢自动注册〔auto registration〕 - 当活动客户端是被服务器自动注册时；
1.触发器事件〔Trigger events〕
触发器状态改变是最频繁也是最重要的时间源。

每一次触发器改变它的状态,一个事件生存了。

事件包含了触发器改变的细节－－什么时候触发器状态改变了和现在触发器是什么状态。

2.发现事件〔Discovery events〕
Zabbix定期扫描网络发现规则中定义的IP列表。

每个规则的检测频率是可以单独配置的。

一旦一个主机〔或服务的情况改变〕被发现了,一个〔或〕多个发现性事件生成了。

Zabbix生成下列事件：
3.活动客户端自动发现事件〔Active agent auto-discovery events〕
活动客户端自动注册在Zabbix产生事件。

如果配置了,当之前一个不知名的活动客户端请求检查时,活动客户端自动注册事件产生。

服务器使用接收到的客户端的IP地址和端口来添加一个新的自动注册主机。

4.1.11图形〔Grahps〕
随着大量数据流入Zabbix,对于用户来说,观看能够图形比观看数据更容易了解Zabbix 正在发生的事件。

这就是图形的用武之地了。

图形可以一目了然的让你掌握数据流,相关问题,什么时候发生了或者分析出一些或许会进入故障状态的事件。

Zabbix可以提供给用户置的简单图形,也可以提供给用户更复杂的自定义图形。

Zabbix的Graphs功能很强大,可以为每一个item绘制图表,也可以把多个items绘制在一图表。

通过configuration->hosts选择要绘制图表的host,点击graphs,create graphs 即可创建图表。

图表样式,有线状、柱状、饼状；还可以自定义图表大小,与Y轴最大最小值；通过add items可以添加在同一个图表中展示的多个items。

4.1.12Screen
Screen将多种信息放在一起展示,便于集中展示某个host的多个信息,或是比较多个hosts的同一种信息,这些信息可以为graphs、maps、server infos等等,几乎涵盖Zabbix 所有的监控信息。

4.1.13报表〔Reports〕
如果有大量的同一类设备,需要监控的信息也大致类似,一个个去修改相关参数比较麻烦,我们可以通过创建一个template来简化操作。

在Zabbix中关于报表的功能有三项：
➢Avaliability report：整个系统可用的系统报表提供过滤功能。

➢Most busy triggers top 100：提供最常用的triggers 预览。

➢Bar report ：可定制报表可以报多个报表整合到一起。

4.1.14IT 服务〔ITs〕
在许多情况下,我们不感兴趣的低级别的细节,如磁盘空间不足,处理器负载高等,我们感关心的是我们的IT部门提供的服务的可用性、各种IT服务的SLA、现有的IT基础设施的结构,以与其它更高级别的信息。

IT服务的目的是关联对应于业务的IT基础架构〔组建/服务/硬件等〕,并找出影响相关业务的IT基础架构。

4.1.15发现〔Discovery〕
Zabbix提供了一个自动网络发现检测功能,通过正确的配置后可以实现：
➢加快Zabbix部署
➢简化管理
➢在经常变化的环境中无需过多的管理
Zabbix网络发现功能是基于以下信息的：
➢IP围
➢外部可用的服务〔如：FTP,SSH, WEB,POP3,IMAP,TCP等〕
➢收到的来自Zabbix Agent的信息
➢收到的来自SNMP Agent的信息
网络发现功能不提供网络拓扑的发现。

网络发现一般包括两个阶段：Discovery〔发现〕和Actions〔动作〕。

Discovery〔发现〕
Zabbix按照预定义的频率规则定期扫IP。

每一个发现主机或一个服务时也触发一个相应的动作Action产生。

Actions〔动作〕
Discovery触发了一个Action后可以执行的相关操作如：
➢发送通知
➢添加/删除主机
➢启用/禁用主机
➢添加主机组
➢从组中删除主机
➢主机与模板的关联和断开
➢执行远程脚本
4.1.16队列〔Queue〕
这个队列显示了等待更新的监控项。

队列仅仅是来自来自数据库数据的逻辑表示。

zabbix中没有IPC队列或任何其他的队列。

队列中的统计数据是一个良好的Zabbix服务器的性能指标。

4.1.17应用〔Applications〕
应用是用来将监控项组织成一个逻辑组。

举例来说,MySQL服务应用可以保存所有与MySQL有关的监控项：MySQL可用性,磁盘空间,处理器负载,每秒的存取次数,低速查询的数量等。

应用也用于网络分组方案。

如果你使用应用,在〔监控〕Monitoring → Latest data 〔最新数据〕中你将看到每个应用中的监控项和网络分组方案。

4.1.18分布式监控〔Distributed monitoring〕
Zabbix为IT基础设施提供可靠有效的分布式监控,对于大规模设施监控提供两种解决方案：
⏹代理,可以代表Zabbix Server收集本地数据,然后提交到Zabbix Server；
⏹多节点,这种方式是在每个节点上部署完整的Zabbix；
4.1.19维护<Maintenance>
可以为Zabbix主机和主机组定义维护<maintenance>时间。

这里有两种维护<maintenance>类型：有数据收集和无数据收集。

在主机维护<maintenance>期间为了避免收到报警信息,action应该修改配置,在报警条件中修改'Maintenance status = not in "maintenance"' ——这样,在维护<maintenance>期间,你将不会收到报警信息。

如果在维护<maintenance>期间发生了一个不可修复的错误,那么在维护<maintenance>时间结束后,才能接到该问题的报警。

如果要想在维护<maintenance>期间收到错误的报警信息,那么就需要将上面的条件去
掉。

5监控项类型〔Item Type〕
5.1Zabbix客户端代理〔Zabbix Agent>
每一个监控项都可以选择被动或主动监控,下表提供了通过Zabbix Agent可以得到的监控项的key。

监控项对各个操作系统的支持参考：
s.zabbix./documentation/2.0/manual/appendix/items/supported_by_platform 针对Win32平台特有的监控项参考：
s.zabbix./documentation/2.0/manual/config/items/itemtypes/zabbix_agent/win_ keys
5.2SNMP代理〔SNMP Agent〕
通常打印机、网络交换机、路由器、UPS这些设备是无法配置为Zabbix Agent客户端,但他们默认都支持SNMP。

为了能从这些设备上通过SNMP Agent收集到数据,需要在Zabbix
Server配置中设置支持SNMP。

5.3SNMP被动方式〔SNMP Trap〕
5.4IPMI检测
Zabbix可以对IPMI〔Intelligent Platform Management Interface,智能平台接口〕设备的健康状态和可用性进行监控。

要使用IPMI功能Zabbix Server服务器必须在配置中设置对IPMI支持。

IPMI是一个标准化的接口远程"lights-out"或"out-of-band"的计算机系统管理。

它允许直接从所谓的"out-of-band"管理卡,独立于操作系统或机器是否开机时监控硬件状态。

仅适用于具有IPMI支持〔HP iLO, DELL DRAC, IBM RSA, Sun SSP等〕的设备的Zabbix IPMI监视。

5.5简单检测
简单的检查,通常用于远程代理服务检查。

Zabbix Agent是没有必要做简单检查的,Zabbix Server负责处理简单检查。

5.6日志文件监控
Zabbbix可以用于被自动切割了的多个的日志文件的集中监控与分析。

当一个日志文件包含特定的字符或者字符模式时,Zabbix向用户发送报警信息。

要进行日志文件监控,以下是必须的
➢Zabbix客户端代理〔Zabbix agent〕
➢设置日志文件监控的监控项
5.7计算监控
可以在其它监控项目基础上创建计算监控项目,因此计算监控项目是创建虚拟数据源的方式,它基于一个算术表达式,改值将被定期计算,得到数据将被存储在Zabbix 数据库中,这意味着我们将为图形生成历史趋势数据。

5.8部检查
部检查允许监控Zabbix的部。

要使用此项则选择Zabbix internal类型。

部检查是由Zabbix Server计算的。

下表示所支持的检查项：
trigger function.
If <param> is version , version of Java gateway is returned. Example: "2.0.0".第二个参数必须是空的,用来保留供将来使用This item is supported starting from version 2.0.0.
zabbix[process,<type>,<mode>,<state>]
Time a particular Zabbix process or a group of processes
<identified by <type> and <mode>> spent in <state> in
percentage. It is calculated for last minute only.
If <mode> is Zabbix process number that is not running <for
example, with 5 pollers running <mode> is specified to be
6>, such an item will turn into unsupported state.
Minimum and maximum refers to the usage percentage for a
single process. So if in a group of 3 pollers usage
percentages per process were 2, 18 and 66, min would return
2 and max would return 66.
Processes report what they are doing in shared memory and
the self-monitoring process summarizes that data each
second. State changes <busy/idle> are registered upon
change - thus a process that becomes busy registers as such
and doesn't change or update the state until it becomes
idle. This ensures that even fully hung processes will be
correctly registered as 100% busy.
Currently, "busy" means "not sleeping", but in the future
additional states might be introduced - waiting for locks,
performing database queries, etc.
On Linux and most other systems, resolution is 1/100 of
a second.
The following process types are currently supported:alerter - process for sending notifications configuration syncer - process for managing in-memory cache of configuration data db watchdog - sender of a warning message in case DB is not available discoverer - process for discovery of devices escalator - process for
escalation of actions history syncer - history DB
writer housekeeper - process for removal of old
historical data poller - web monitoring
poller icmp pinger - poller for icmpping
checks ipmi poller - poller
for IPMI checks java poller - poller for Java
checks node watcher - process for sending
historical data and configuration changes between
nodes poller - normal poller for passive
checks proxy poller - poller for passive
proxies self-monitoring - process for collecting
internal server statistics timer - process for
evaluation of time-related trigger functions and
maintenances trapper - trapper for active checks,
traps, inter-node and -proxy
communication unreachable poller - poller for
unreachable devices
Note: You can also see these process types in a
server log file.
Valid modes are:avg - average value for all
processes of a given type <default>count -
returns number of forks for a given process
type, <state>should not be specified max -
maximum value min - minimum value <process number> - process number <between 1 and the number of pre-forked instances>. For example, if 4 trappers are running, the value is between 1 and 4.
Valid states are:busy - process is in busy state, for example, processing request <default>.idle -
5.9SSH检查
SSH检查属于低限的代理监控,Zabbix Agent是不需要进行SSH监控的。

要进行SSH检
查之前要对Zabbix Server进行配置支持SSH2.
5.10Telnet检查
与SSH检查类似,Telnet检查也是低限的代理监控,Zabbix Agent也不需要进行Telnet 检查。

5.11外部检查
外部检查是通过Zabbix Server运行一个shell脚本或二进制程序实现。

外部检查不需要被监控主机上运行任何一种代理。

5.12汇总检查
汇总检查是直接通过Zabbix Server对数据库查询收集汇总的信息来实现。

汇总检查不需要任何被监控主机上运行代理。

5.13被动监控
被动监控项目是接受输入数据而不是查询,它可以将任何有用的数据push到Zabbix。

要使用被动监控项,你必须：
➢在Zabbix里设置一个被动监控项目
➢将数据发送到Zabbix
5.14JMX监控
JMX监控可以通过对JMX计数器来对Java应用程序监控。

Zabbix2.0添加了一个新的守护进程叫"Zabbix Java Gateway"的原生的JMX监控支持。

5.15ODBC监控
ODBC监控是对应在Zabbix前端里的数据库监控项。

6触发器〔Triggers〕
6.1概述
详见：4.1.8触发器〔Triggers〕
6.2配置触发器
要配置一个触发器,按照下面的步骤
点击： Configuration → Hosts
在host那一行,点击trigger
在右边点击Create trigger <或者点击触发器的名称来编辑一个已经存在的触发器> 在表单中输入触发器的参数
Trigger标签所有必要的触发器属性：
参数触发器名称,名称里面可以包含宏
表达式〔Expression〕用来计算触发器状态的逻辑表达式
多个问题事件生成〔Multiple PROBLEM events generation〕选择这个选项,你可以触发器评估出每一个 'Problem' 时生成一个事件
Comments 用来提供更多该触发器信息的文本字段。

可能包含解决
该问题的提示,负责人的相关信息等。

URL 如果不为空的话,那么该URL用在Screen中的 '触发器
状态〔Status of Triggers〕'这一选项上
Severity 点击该按钮可以设置触发器严重性
Enabled 如果需要的话,取消该该项将禁用触发器你也可以通过打开一个已经存在的触发器,点击Clone按钮,保存为你需要的名字这个方法来配置一个触发器。

6.3触发器表达式〔Expression〕
在触发器中使用表达式是非常灵活的。

你可以用它们复杂的逻辑来测试关于监控统计。

一个简单有用的触发器可能像下面的情况：
1 {<server>:<key>.<function><<parameter>>}<operator><constant>
6.3.1Function
触发器函数允许参考收集到的数据的前时间和其他因素,下表是支持触发器表达式的所有函数：
6.3.2Function parameter
大多数数值型函数接受秒数作为一个参数〔argument〕
你可以使用前缀＃来指定一个参数〔argument〕有不同的意思：
函数调用〔FUNCTION CALL〕意思〔MEANING〕
sum<600> 600秒所有值的和
sum<#5> 最近第5个值的和
函数last在用hash标记前缀时有不同的意义－－它返回给定的第n个值。

假设给定值3, 7, 2, 6, 5,last<#2>将返回第二个值7,last<#5>将返回第五个值5。

要忽略的函数也必须给它一个参数,例如：last〔0〕
6.3.3运算符
触发器支持下列运算符〔优先级渐降〕
6.3.4触发器举例
例子一
.zabbix 上的处理器负载太高
1 {.zabbix.:system.cpu.load[all,avg1].last<0>}>5
'{.zabbix.:system.cpu.load[all,avg1]'给出了监控参数的名称。

它指定：
✓服务器是'.zabbix.'
✓被监控关键字是'system.cpu.load[all,avg1]'
✓通过使用函数'last<>',我们指定最近的值
✓'>5'表示来自 zabbix 的最后负载测量大于5则触发器进入PROBLEM状态
例子二
.zabbix 过载
1 {.zabbix.:system.cpu.load[all,avg1].last<0>}>5|{.zabbix.:system.cpu.load[all
,avg1].min<10m>}>2
无论当前处理器负载大于5还是最近10分钟的负载大于2,该表达式的值都是真。

例子三
文件/etc/passwd被更改了,使用函数diff：
1 {.zabbix.:vfs.file.cksum[/etc/passwd].diff<0>}>0
当文件/etc/passwd之前的checksum值于最近的值不同,则该表达式为真
相似的表达式也可以用在监控重要的文件〔如/etc/passwd, /etc/inetd.conf, /kernel等〕变更上
例子四
有人从因特网上下载大文件,使用函数min：
1 {.zabbix.:net.if.in[eth0,bytes].min<5m>}>100K
当最近5分钟,eth0接收的字节数大于100KB,则该表达式为真。

例子五
两个SMTP服务器的集群节点都停止了,注意在一个表达式中使用两个不同的主机：
1 {smtp1.zabbix.:net.tcp.service[smtp].last<0>}=0&{smtp2.zabbix.:net.tcp.servi
ce[smtp].last<0>}=0
当SMTP服务器smtp1.zabbix 与smtp2.zabbix 都停止时,表达式为真。