Zabbix深入分析2015.doc

Zabbix深入分析Zabbix深入分析2015目录1研究目标82系统架构92.1Server102.2数据库存储（Database storage）102.3WEB 界面102.4Proxy102.5Agent112.6Get122.7Sender122.8工作机制123WEB界面菜单功能134主要功能名词及概念144.1.1SNMP144.1.2IPMP144.1.3配置（configuration）154.1.4主机和主机组（Hosts and host group）154.1.5模板（Templates）154.1.6监控项（Items）154.1.7网站监控（WEB）154.1.8触发器（Triggers）164.1.9宏（Macro）164.1.10事件（Events）174.1.11图形（Grahps）184.1.12Screen184.1.13报表（Reports）184.1.14IT 服务（IT services）194.1.15发现（Discovery）194.1.16队列（Queue）204.1.17应用（Applications）204.1.18分布式监控（Distributed monitoring）204.1.19维护(Maintenance)205监控项类型（Item Type）215.1Zabbix客户端代理（Zabbix Agent)215.2SNMP代理（SNMP Agent）385.3SNMP被动方式（SNMP Trap）395.4IPMI检测395.5简单检测395.6日志文件监控395.7计算监控395.8内部检查405.9SSH检查455.10Telnet检查455.11外部检查455.12汇总检查455.13被动监控455.14JMX监控465.15ODBC监控466触发器（Triggers）466.1概述466.2配置触发器466.3触发器表达式（Expression）476.3.1Function476.3.2Function parameter516.3.3运算符516.3.4触发器举例526.3.5滞留状态546.4触发器依赖性（Dependency）546.5触发器严重性（Severity）556.6触发器的单位符号（Unit symbols）566.6.1单位后缀566.6.2使用举例567报警及其策略577.1概述577.2报警流程587.3报警媒介（Media type）587.4报警动作（Action）587.4.1Action（基本属性）597.4.2Conditions（条件）597.4.3Operations（操作）597.5报警升级（Esacalations）618Quickstart629数据模型6410Zabbix API6410.1概览6410.1.1API使用说明6410.1.2Zabbix API支持的数据类型6510.1.3“get”方法支持的通用参数6510.2监控6710.2.1History6710.2.2Events6710.2.3Service monitoring6710.3配置6710.3.1Hosts and host groups6710.3.2Items and applications6810.3.3Triggers6910.3.4Grahps6910.3.5Templates7010.3.6Export and import7010.3.7Low-level discovery7010.3.8Screens7110.3.9Actions and alerts7210.3.10IT services7210.3.11Maps7310.3.12Web monitoring7310.3.13Network discovery7310.4管理7410.4.1Users7410.4.2General7510.4.3Proxies7510.4.4Scripts7610.5API信息7610.6API引用的对象（Object）的属性7610.6.1History object7611图表套件-FusionChats7811.1概述7811.2套件7911.2.1FusionChartsXT7911.2.2FusionWidgetsXT8511.2.3PowerChartsXT9011.2.4FusionMapsXT9611.3开发（PHP）9612调研总结9712.1Zabbix 可监控的基本模块9712.2Zabbix API9812.3Zabbix 图表9812.3.1外部查看图表可行性9812.3.2利用FusionCharts 展现9812.4报警策略的可定制性9812.5与Zabbix用户会话同步策略10012.5.1统一用户10012.5.2动态登录10013系统的集成10013.1方案10013.1.1方案一：内建模块10113.1.2方案二：iframe嵌入10113.1.3方案三：图表接口10213.2方案总结1021 研究目标通过对ZABBIX的研究实现如下目标： 熟悉可监控的基本模块 研究API，并且要写代码测试到监控任务的API控制，包括创建，暂停，更改选项，删除任务。 研究API，写代码看是否能读取到全部监控结果 研究Zabbix报表，搞清楚两个问题，n 是否能直接调用Zabbix的出图组件或选项或api，n 如果Zabbix图形体验不能满足我们的要求，是否我们能拿到出图的全部数据来自己组织出图（我们已有的经验有open flash chart,接下来我们可能会采购fusionchart图表组件)， 研究Zabbix的报警策略，看看能否做出根据监控的任务或选项来实施不同的报警规则，看看是否能实现报警级别定义及优先级定义，如果要使用我们自定义的报警策略，看看如果与zb集成。 研究Zabbix的用户登录设置，看看如何实现我们的应用集成时免登录（特别是需要查看监控结果时） 在熟悉了zb的前提下，考虑并设计我们的应用跟zb做集成的方案2 系统架构图：Zabbix架构图：Zabbix基本数据流2.1 ServerServer执行轮询和捕获数据，它计算监控项，给用户发送报警信息。它是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.3 WEB 界面为方便从不同平台去访问管理Zabbix，Zabbix提供了一个基于WEB的界面，可以通过界面实现监控及其各项系统配置管理。WEB界面作为 Zabbix Server的一部分也可以运行在不同的物理服务器上。2.4 Proxy在Zabbix的部署中Zabbix Proxy是一个可选的组件。一个Zabbix代理（Proxies）可以代表Zabbix服务器收集性能和可用性数据。这样，代理（Proxies）可以负担采集数据的任务并且减轻Zabbix服务器负载。同时，使用代理（Proxies）是实施统一和分布式监控的最简单方式，因为所有的客户端和代理（Proxies）向一个Zabbix服务器报告数据，并且所有数据集中保存在服务器数据库。图：Zabbix Proxy示意图一个Zabbix代理（Proxies）可以用在以下： 监控远程区域； 监控拥有不可靠链接的区域； 当监控数以千计的设备时分担Zabbix服务器的负载； 简化分布式监控的维护；所有代理（Proxies）采集到的数据在传送给服务器之前都保存在本地。这样，临时与服务器断开连接也不会导致数据丢失。proxy配置文件中的参数ProxyLocalBuffer 和 ProxyOfflineBuffer控制数据在本地保存多久。Zabbix代理（Proxies）是一个数据收集器。它不进行触发器计算，处理事件或发送报警信息。2.5 AgentZabbix客户端代理（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 GetZabbix_get是一个用来与Zabbix agent通信并从Zabbix agent获取所需信息的程序。这个工具常用来客户端排错。2.7 SenderZabbix_Sender是用于向ZabbixServer发送性能数据进行处理的命令行工具。这个工具常用于执行需要长时间运行的用户脚本并发送可用性及性能数据。2.8 工作机制图：报警流程为了创建一个采集数据的监控项，你必须首先创建一个主机。只有有了采集数据的监控项，才能根据这个监控项设置触发器。只有有了触发器，才能设置触发器对应的操作。因此，如果你想收到 CPU load it too high on Server X这样的报警，你必须首先为 Server X创建一个主机（Host），然后在主机中创建一个采集CPU load的监控项（item），然后创建一个触发器（trigger）来判断cpu负载是否高了，然后在创建一个操作（action），用于当cpu负载高时发送报警邮件。这看起来是很复杂的，使用模版之后，将完全不是这样的。但是，由于这样的设计，可以进行非常灵活的设置。3 WEB界面菜单功能 监控（Monitoring）仪表盘（Dashboard）总览（Overview）网站（WEB）最新数据（Latest data）触发器（Triggers）事件（Events）图形（Graphs）多屏（Screens）拓扑图（Maps）发现（Discovery）IT服务（IT services） 资产（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服务（IT services） 管理（Administration）一般（General）节点管理（DM）认证（Authentication）用户（Users）示警媒体类型（Media types）脚本（Scripts）审计（Audit）队列（Queue）警报（Notifications）4 主要功能名词及概念4.1.1 SNMP也是agent的一种，指支持SNMP协议的设备（也可以是服务器），通过设定SNMP的参数将相关监控数据传送至服务器端（大部份的交换机、防火墙等网络设备都支持SNMP协议）。4.1.2 IPMPAgent的另一种方式，主要应用于设备的物理性能监控，例如设备的温度、风扇的转速等。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（响应代码，http状态码），也可以检查目标html页面所包含的预先定义的字符串。要激活网站监控（Web Monitoring），你需要定义web方案。一个web方案由一个或多个HTTP请求或步骤组成。Zabbix服务器以预定义的顺序顶起执行这些步骤。在任何web方案中都将收集下面的信息： 整个方案所有步骤的平均下载时间，以秒计； 失败的步数； 最后一个错误信息；在任何web方案的每一步将收集下面的信息： 每秒下载速度； 响应时间； 响应代码；Zabbix也能够检查获取到的HTML页面是否包含预定义的字符串。它可以执行一个虚拟的登录表单提交等。Zabbix网站监控（Web Monitoring）支持HTTP和HTTPS两种情况。当执行一个web方案时，Zabbix经常接受重定向。在执行一个方案期间，cookies被保存。4.1.8 触发器（Triggers）触发器是评估监控项收集到的数据的逻辑表达式，然后反应系统的当前状态。监控项是用来收集系统数据的，一直等着出现报警或者值得注意的情况是不切实际的。评估数据的工作可以交给触发器做。监控项表达式可以定义一个可接受数据的阀值。因此，当输入数据超越了可接受状态，触发器发动或者把状态变为PROBLEM。一个触发器可能有下列状态：值描述OK触发器的正常状态。PROBLEM通常意味着有情况发生。举个例子说，处理器负载太高。4.1.9 宏（Macro）Zabbix支持可以在各种场合可以使用的大量宏（Marcos）。有效使用宏（Marcos）可以让你节省时间并且让配置文件更清晰。这里的宏（Marcos）是和C语言里的宏的作用一样，是用一个简单的宏名称来替代繁琐的代码片段。为了更高的灵活性，Zabbix支持用户宏（Marcos）它们可以在全局、模版级别和主机级别定义。这些宏（Marcos）有一个特殊的语法：（$MACRO）。宏（Marcos）可以使用在下列情况：l 监控项关键字和描述l 触发器表达式和名称l 其他宏（Marcos）名字可以使用下面的字母：AZ，09，_，.zabbix替代宏按照下面的优先权： 主机级别宏（优先检查） 为主机第一层模版定义的宏（即直接链接到主机的模版），以模版ID存储 为主机第二层模版定义的宏，以模版ID存储 为主机第三层模版定义的宏，以模版ID存储 全局宏 (最后检查)换句话说，如果主机中没有存在宏，zabbix将增加深度在主机模版中寻找。如果仍然没有找到，并且全局宏存在，则使用全局宏4.1.10 事件（Events）Zabbix中的事件被三种源生成： 触发器（triggers） - 任何时候一个触发器改变它的状态； 发现（discovery） - 检查到主机或服务时； 自动注册（auto registration） - 当活动客户端是被服务器自动注册时；1. 触发器事件（Trigger events）触发器状态改变是最频繁也是最重要的时间源。每一次触发器改变它的状态，一个事件生存了。事件包含了触发器改变的细节什么时候触发器状态改变了和现在触发器是什么状态。2. 发现事件（Discovery events）Zabbix定期扫描网络发现规则中定义的IP列表。每个规则的检测频率是可以单独配置的。一旦一个主机（或服务的情况改变）被发现了，一个（或）多个发现性事件生成了。Zabbix生成下列事件：事件（Event）什么时候产生（When generated）服务正常运行每次Zabbix能检查到服务服务停止每次Zabbix检查不到服务主机正常运行如果一个IP至少有一个服务正常主机停止如果所有的服务都没有回应服务发现如果一个服务从停止状态恢复或者第一次被发现服务丢失如果服务在正常状态被检查到找不到了主机发现如果一个主机从停止状态恢复或者第一次被发现主机丢失如果主机在正常状态被检查到找不到了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.12 ScreenScreen将多种信息放在一起展示，便于集中展示某个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.14 IT 服务（IT services）在许多情况下，我们不感兴趣的低级别的细节，如磁盘空间不足，处理器负载高等，我们感关心的是我们的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基础设施提供可靠有效的分布式监控，对于大规模设施监控提供两种解决方案：n 代理，可以代表Zabbix Server收集本地数据，然后提交到Zabbix Server；n 多节点，这种方式是在每个节点上部署完整的Zabbix；4.1.19 维护(Maintenance)可以为Zabbix主机和主机组定义维护(maintenance)时间。这里有两种维护(maintenance)类型：有数据收集和无数据收集。在主机维护(maintenance)期间为了避免收到报警信息，action应该修改配置，在报警条件中修改Maintenance status = not in “maintenance” 这样，在维护(maintenance)期间，你将不会收到报警信息。如果在维护(maintenance)期间发生了一个不可修复的错误，那么在维护(maintenance)时间结束后，才能接到该问题的报警。如果要想在维护(maintenance)期间收到错误的报警信息，那么就需要将上面的条件去掉。5 监控项类型（Item Type）5.1 Zabbix客户端代理（Zabbix Agent)每一个监控项都可以选择被动或主动监控，下表提供了通过Zabbix Agent可以得到的监控项的key。监控项对各个操作系统的支持参考：/documentation/2.0/manual/appendix/items/supported_by_platform针对Win32平台特有的监控项参考：/documentation/2.0/manual/config/items/itemtypes/zabbix_agent/win_keysKey描述返回值参数备注agent代理agent.hostnameAgent主机名称String value-返回的主机名称就是agent客户端的配置中定义的主机名称agent.ping检查agent的可用性1表示可用；无返回值表示不可用-使用nodata()方法检查主机可用性agent.versionAgent版本String-Example: 1.8.2Kernel内核kernel.maxfiles操作系统支持打开的文件的最大数量Integer.文件数量kernel.maxproc操作系统支持的进程的最大数量。Integer.进程数量Log日志logfile,监控的日志文件Log.file-日志的完整路径regexp-正在表达式encoding编码maxlines-每秒向Zabbix Server或Proxy发送的最大行数，该参数会覆盖zabbix_agentd.conf配置文件的“MaxLinesPerSecond”mode模式可选值:all(default),skip(跳过旧数据的处理).The item must be configured as anactive check.Example key:log/home/zabbix/logs/logfile,100See a moredetailed description.mode参数从 2.0开始支持.logrtfile_format,监控多个匹配到的日志文件Log.file_format绝对路径，文件名用正则匹配regexp正则encoding编码maxlines-每秒向Zabbix Server或Proxy发送的最大行数，该参数会覆盖zabbix_agentd.conf配置文件的“MaxLinesPerSecond”mode-模式可选值:all(default),skip(跳过旧数据的处理).The item must be configured as anactive check.Example key:logrt/home/zabbix/logs/logfile0-91,3$,100Log rotation is based on the last modification time of files.See a moredetailed description.mode参数从 2.0开始支持.Net网络net.dns,zone,检查DNS服务是否可用0 DNS不可用 (没有响应或解析失败)1 -DNS正常ipDNS的IP (留空表示是默认DNS, windows忽略)zone- zone to test theDNStype要查询的记录类型 (default is SOA)timeout(Windows上忽略) 请求超时(默认 1 秒)count(Windows上忽略) 请求尝试次数 (default is 2)Example key:net.dns,,MX,2,1type可选的值有:ANY, A, NS, CNAME,MB, MG, MR, PTR, MD, MF, MX, SOA, NULL, WKS (非windows), HINFO, MINFO, TXT, SRV不支持国际域名, please use IDNA encoded names instead.Zabbix 2.0以前的名称为 (任然支持):net.tcp.dnsnet.dns.record,zone,执行一个DNS查询当成功时返回一个带有相关信息的StringipDNS的IP (留空表示是默认DNS, windows忽略)zone- zone to test theDNStype要查询的记录类型 (default is SOA)timeout(Windows上忽略) 请求超时(默认 1 秒)count(Windows上忽略) 请求尝试次数 (default is 2)Example key:net.dns.record,,MX,2,1type可选的值有:ANY, A, NS, CNAME,MB, MG, MR, PTR, MD, MF, MX, SOA, NULL, WKS (非windows), HINFO, MINFO, TXT, SRVSRV record type is supported since Zabbix agent version 1.8.6.不支持国际域名, please use IDNA encoded names instead.Zabbix 2.0以前的名称为 (任然支持):net.tcp.dnsnet.if.collisionsifOut-of-window collision.Number of collisions.Integer.if- interfacenet.if.discovery网络接口列表. 用于 low-level discovery.JSON object2.0版本的agent开始支持net.if.inif,网络接口输入统计Integer.if接口名称mode可选值:bytes字节数 (default)packets数据包数errors- 错误数dropped丢包数Multi-byte interface names on Windows are supported since Zabbix agent version 1.8.6.Example keys:net.if.ineth0,errorsnet.if.ineth0You may use this key with aDelta (speed per second)store value in order to get bytes per second .if.outif,网络接口输出统计Integer.if接口名称mode可选值:bytes字节数 (default)packets数据包数errors- 错误数dropped丢包数Multi-byte interface names on Windows are supported since Zabbix agent 1.8.6 version.Example keys:net.if.outeth0,errorsnet.if.outeth0You may use this key with aDelta (speed per second)store value in order to get bytes per second .if.totalif,网络接口的I/O流量统计Integer.if接口名称mode可选值:bytes字节数 (default)packets数据包数errors- 错误数dropped丢包数Example keys:net.if.totaleth0,errorsnet.if.totaleth0You may use this key with aDelta (speed per second)store value in order to get bytes per second statistics.Note that dropped packets are supported only if both net.if.in and net.if.out work for dropped packets on your .tcp.listenport检查端口监听状态0 没有监听1 监听状态porttcp端口Example:net.tcp.listen80On Linux supported since Zabbix agent version 1.8.4net.tcp.port,port检查端口是否可用，如果可用尝试TCP连接0 连接失败1 可用连接ip- (default is )port 端口Example:net.tcp.port,80 可用检查web服务器80端口是否可用.旧名称: check_port*对于简单的TCP性能测试可以用 net.tcp.service.perftcp,注意：这些检查可能会导致额外的守护进程的日志信息（SMTP和SSH会话通常记录）。net.tcp.serviceservice,检查服务，如果在运行则接受tcp连接0 服务挂了1 服务在运行service以下任意值:ssh,ntp,ldap,smtp,ftp,http,pop,nntp,imap,tcp,https,telnetip- (default is )port- (默认将使用服务的默认端口)Example key:net.tcp.serviceftp,45 可以测试端口为45的FTP服务测试.注意：这些检查可能会导致额外的守护进程的日志信息（SMTP和SSH会话通常记录）。该方法目前不支持加密协议(如IMAP端口 993 orPOP端口995)，这些检查可以使用net.tcp.port.windows 版本的agent目前不支持检查LDAP和HTTPS.Note that the telnet check looks for a prompt (: at the end).旧名称: check_service*Note that before Zabbix 1.8.3 versionservice.ntpshould be used instead ofntp.httpsandtelnetservices are supported since Zabbix 2.0.net.tcp.service.perfservice,检查服务性能0 服务挂了;如果服务可用，则返回连接到服务的秒数service以下任意值:ssh,ntp,ldap,smtp,ftp,http,pop,nntp,imap,tcp,https,telnetip- (default is )port- (默认将使用服务的默认端口)Example key:net.tcp.service.perfssh 可用于测试从SSH服务器的初始响应速度.该方法目前不支持加密协议(如IMAP端口 993 orPOP端口995). 可以用 net.tcp.service.perftcp, 替代.windows 版本的agent目前不支持检查LDAP和HTTPS.Note that the telnet check looks for a prompt (: at the end).就名称: check_service_perf*Note that before Zabbix 1.8.3 versionservice.ntpshould be used instead ofntp.httpsandtelnetservices are supported since Zabbix 2.0.net.udp.listenport检查UDP端口状态.0 不可用1 监听状态portUDP端口号Example:net.udp.listen68On Linux supported since Zabbix agent version 1.8.4Proc进程proc.mem,指定用户的指定进程内存使用情况.内存使用量(单位： bytes).name进程名称 (默认是所有进程)user 用户名 (默认为所有用户)mode 可选值:avg,max,min,sum(default)cmdline附加的过滤命令Example keys:proc.mem,root - “root”用户的所有进程占用内存情况proc.memzabbix_server,zabbix - 行在 zabbix 用户下的zabbix_server所有进程的占用proc.mem,oracle,max,oracleZABBIX oracle进程含有oracleZABBIX命令时在内存最紧张的情况下的内存用量proc.num,某用户的指定状态下的进程数.Number of 进程名称 (默认是所有名称)user用户名 (默认是所有用户的)state可选值:all(default),run,sleep,zombcmdline-附加的过滤命令Example keys:proc.num,mysql mysql用户的进程数proc.numapache2,www-data www-data用户下apache2的进程数proc.num,oracle,sleep,oracleZABBIX - oracle用户含有oracleZABBIX命令的状态为sleep的进程数在 Windows上,仅支持name和user参数Sensor传感器sensordevice,sensor,硬件传感器读数device设备名称 (如果使用了参数, 这是一个正则)sensor传感器名称(如果使用了参数, 这是一个正则)mode可选值:avg,max,min.On Linux 2.4, reads/proc/sys/dev/sensors.Example key:sensorw83781d-i2c-0-2d,temp1Prior to Zabbix