Zabbix Code Guidelines

Sidebar

zh:thosts

模版

Zabbix模版指南

免责申明

此文档的目的不是为了让每个人都严格遵守规则。相反,此文档展示了我们构建模板的方法,文档中描述的任何规则和最佳实践在未来可能被更改或者放弃。

当前文档状态: 草稿 可供预览和反馈。模板定制可联系Zabbix中国——上海宏时数据系统有限公司。

介绍

Zabbix监控方式。 资源与服务

在我们开始讨论什么是最佳的模板之前,让我们来简单讨论一下监控。由于监控是一个很常见且模棱两可的术语,所以没有真正的RFC定义。有人可能会说,监控是指不断地在社交网络上搜索有关你公司地信息,而另一些人可能会说,监控是指收集有关植物土壤营养和水分的传感器数据。Zabbix是通用的监控解决方案,我们为任何类型的监控项目提供一个工具集。但在此文档中,我们会重点讨论对现代分布式系统的监控方法。

一切皆可被视为 服务 或者 资源.

服务 是指你的组织提供给外部的事物。例如在线零售商店,或者公共电子邮件服务。如果你的商店在线并且顾客可以成功的在商店中购买商品 - 那么你的服务是可用的。又或许是你的部门向公司的其他部门提供的服务。比如您根据需要提供给其他部门的计算资源。此类内部服务可能是你的公司在线商店的依赖服务。这种情况下,服务出现问题会影响你公司的在线商店。 监控服务的 可用性性能 是你首先应该做的。正如Google在SRE书中建议的,服务不可用应视为紧急情况,必须立即联系负责人。

资源 是协助提供服务的组件。它可以是服务器,虚拟机,容器,数据库,应用中间件,自开发的微服务应用,硬件控制器,网络或者其他组件。你可以将资源进行细分,例如将服务器细分为CPU、内存、IO子系统,或者将网络设备分为2层或3层设备。现代分布式系统可能是一组具有动态特性的不同资源的复杂集合,根据服务的负载情况按需添加和删除资源,就像Kubernetes集群或者AWS一样。资源同样也需要被监控,但有所不同。因为资源不可用不一定会影响服务,应当尽量减少对资源不可用的告警,例如在工作时间内创建工单,而非在休息时间。

服务监控被认为是项目级别的监控 – 它不是你可以开箱即用或者在share.zabbix.com上获取的模板 - 它是需要你利用Zabbix的功能自行创建。因为所有的服务都是不同的,拥有不同的SLO(服务等级目标),不同的系统架构等等,所以很难为服务监控准备一个通用的方案。但是请考虑一下的方法:

  • 尝试综合监控: 定期模拟用户 (与你的服务交互的人或其他应用程序) 活动:使用黑盒方法检查服务状态
    • 在Zabbix中使用Web监控来模拟常见的用户场景,例如,尝试登录并从在线商店购买测试商品
    • 也可以使用更简单的HTTP检查 – 仅确认你的网站地址返回的HTTP状态码是200 OK
    • 如果你的服务提供REST API, 请编写一个脚本来模拟一些常见的服务活动
  • 尝试真实用户的监控方法:从日志、网络或数据库中收集和读取有关真实用户的事务数据
    • 统计成功/失败请求的比例
    • 收集每秒/每分钟对你的服务的请求速率
    • 计算你的服务的最小/最大/平均响应时间或创建直方图

如果出现了例如请求速率为0 (或者请求速率突然下降),高错误率 (非常多的HTTP 500错误),说明服务出现了严重的问题。

但是如果设置了服务监控,为什么还需要监控资源呢?有很多种原因,但是最重要的一个原因是:一旦你发现服务宕了 (根据现状),你需要找出问题的 根本原因

资源在许多项目、不同的系统架构中是通用的,这就是模板的作用。说实在的,你真的需要浪费时间来创建自己的Linux系统监控解决方案吗?或者MySQL数据库,Cisco路由器,又或者是docker主机?也许你可以通过服务级别监控来更有效地利用你的时间。

制作一个优秀的模板需要哪些东西?

让我们试着定义一个优秀的模板的一些属性,我们在Zabbix中构建模板时遵循的一些关键原则:

1. 灵活可重用

在Zabbix中,模板相当于针对某个特定对象的监控解决方案。它是在Zabbix server实例间传输配置和监控解决方案的一种容器。一个高质量的模板是Zabbix用户创建的,为了自己的利益而使用,然后与Zabbix社区共享,这样下一个人就可以下载这个模板并重用它,用更新的想法和方法更新它,为共同的事业做出贡献。因此,当你想知道什么是高质量的Zabbix模板,首先想到的是灵活和可重用。如果其他Zabbix用户可以下载并使用它,而不需要做出大量修改 – 这真是一个非常棒的设计。

以下是一些关于如何实现模板灵活和可重用的经验和规则:

  • 尽可能使用LLD低级别自动发现 避免不支持的项或触发器。例如在你的环境中有一些指标,这并不意味着它在任何环境中都是可用的 – 它可能有不同的硬件,软件版本,或者配置。
  • 在监控项和触发器中 使用用户宏 。 例如, 使用{$NGINX.URL}替代Nginx stub status的URL。或者在温度控制的触发器中使用{$TEMP.MAX.CRIT}。 这样用户可以通过配置或者微调模板和链接的主机,而不是改变模板,破坏与未来版本的兼容性。
  • 避免将项目/服务所需的罕见的指标或触发器 添加到资源模板中。对于你认为非常具体的项目/服务级别指标,只需将其移动到另一个模板并将其链接到通用模板。
  • 尽可能 避免外部依赖 。优先使用Zabbix内部的数据采集和处理功能来采集数据,使用HTTP代理,强大的预处理步骤例如Javascript脚本,JSONPath, JMX等等。这将确保此类模板易于安装,并且其所有配置和处理都在模板中定义。只有在没有其他选择时才使用外部脚本。

2. 了解专业知识

我们还认为,好的模板不仅仅是捆绑在一起的一组指标(监控项)、阈值(触发器)和仪表盘。一个好的模板最重要的组成部分是它包含了多少关于被监控对象的专业知识。我们所说的专业知识,不是指一个人知道如何收集的指标的数量 – 而是知道哪些指标是有用的和重要的,哪些是无用的,或者应该使用什么阈值来只通知那些重要的问题,而不需要太多的告警。

虽然非常简单的模板可能无法提供你所需的所有信息,但另一方面,臃肿、过大的模板也很糟糕,因为用户会失去对最重要指标的关注,并且会被大量的告警问题淹没。所以:

  • 避免添加 过多的指标 。把事情简单化。不要尝试进行基准测试、分析、收集深度调试级别的指标。它会给Zabbix带来不必要的负载以及监控对象。 将这些问题独立出来 – 然后在需要的主机上使用专门的工具进行分析和调试。
  • 避免在模板中添加 过多的触发器 。确保通过触发器产生的问题需要立即(通知)或推迟(创建工单)。避免使用“供参考”和“这不正常”的触发器级别。

3. 模块化和范围

最后一件非常重要的事情是模板范围。我们已经谈到了服务和资源,因此,一般来说,好的模板是具有单个资源范围的模板:

  • 特定厂商的硬件服务器
  • 温度传感器
  • 操作系统模板,如Linux操作系统或Windows操作系统
  • Nginx、Apache、Tomcat、RabbitMQ等应用程序
  • MySQL、PostgreSQL、Oracle、DB2、Redis、Mongo等数据库
  • 云服务提供商,如AWS、Azure或其他
  • 虚拟化提供商,如VMware集群、Hyper-V
  • 容器编排系统,如Kubernetes
  • 网络设备或网络控制器
  • 其他自定义应用程序

如果将模板作用在单个资源中,那么共享此类模板将更容易,而且对于在其系统架构中具有相同构建模块的人来说,这些模板将非常有用。另外,避免合并不同类型的资源—不要将Linux操作系统和PostgreSQL数据库的指标添加到单个模板中。

那么“内部”的指标范围呢?您应该收集哪些指标类型、类?当然,你可以出于各种原因进行监控,包括收集业务指标或查找安全漏洞,但在创建通用资源的Zabbix模板时,请尝试采用以下方法:

3.1 始终从 故障 监控或可用性监控开始。人们希望从监控中得到的最多也是最重要的答案是:我的系统是否已启动并运行?所以,试着先在模板中解决这个问题。

也就是说,这里更喜欢黑盒监控方法,简单或不那么简单的健康检查是必不可少的,也是你或任何用户想知道的第一件事。将监控项和触发器添加到模板中,可以帮助您确保监控的内容是可访问的,并且正在运行。例如使用ICMP ping,检查TCP端口是否打开,检查API是否返回HTTP 200 OK,等等。

故障监控解决的第二个问题是即将发生的故障。例如,

  • 硬件过热,即将关闭
  • 磁盘剩余空间不足,数据库即将无法写入新数据。

添加监控项和触发器有助于你及时发现并阻止此结果的产生。

另外,如果监控对象可以自己检测故障 - 请使用它!许多系统可以使用日志或发送SNMP陷阱等直接报告故障。这就是我们之前讨论过的那种从开发者、供应商、系统作者那里获得的专业知识。没有人比他们更清楚。因此,只需确保在Zabbix模板中转译系统本身检测到的故障。

3.2 在你的模板可以检查系统的运行状况之后 - 可以接着做性能监控。 这是你需要进行白盒监控。有一些非常好的方法可以帮助您选择首先收集哪些指标:使用Google的四个黄金信号,或者使用RED作为请求驱动的服务。只需使用监控项和触发器来扩展模板,以帮助解决以下用例:

  • 我的系统很慢。它在运行,但响应时间不令人满意。性能下降。
  • 我们刚刚出现了大规模停机。我们需要调查并做 回顾性分析 ,找出发生了什么,以确保不再发生。要做这样的分析,我们需要事先收集有用的指标。

3.3 资产和状态控制

虽然Zabbix不是资产管理系统,但它仍然可以收集大量有关资源的信息,最重要的是,可以检测到更改,例如系统在维护窗口外重新启动、版本更新或过期等等。所以,把它作为模板清单的一部分。

3.4 安全

如果您知道如何正确检测资源的安全问题,即:

  • 使用的资源版本以CVE为准。考虑更新
  • 错误配置会导致系统在未经认证就可以公开访问。

然后考虑将这些监控项和触发器也添加到模板中。

4. 遵循指导原则

最后是模板的样式。如何命名您的监控项?模板?触发器?如果我们在创建Zabbix模板时都遵循相同的风格 – 那么谁制作了这个模板就无关紧要了 - 无论是你、Zabbix或者其他地区的社区成员 - 因为模板的内容和布局将是可预测和可预期的。

结论

遵循样式指导原则和模板核心原则意味着我们可以将彼此的模板复用,来监控指定的项目,从而节省时间并学习其他人对监控对象的专业知识。

以上就是 Zabbix模板指南 的介绍,这是我们如何在Zabbix中构建模板的一整套规则。

如果出现以下情况,我建议阅读本指南:

  • 你想和其他人共享你的模板
  • 你想在创建模板是避免常见错误
  • 作为硬件或软件供应商, 您希望为您的解决方案提供一个Zabbix模板

样式指南

1.1 总则

1.1.1 避免大量的模板调整

尽量使模板中的所有内容保持默认和简单。例如,更新间隔、历史记录、趋势等监控项属性。只有在有充分理由的情况下才能改变它们。不要浪费时间决定更新间隔是1分钟还是2分钟,或者2.5分钟?使用帕累托法则(二八定律),以20%的时间和精力获得80%的模板效率。不要过度设计,除非有原因。

1.1.2 模板语言

所有模板描述、名称等必须首先用英语创建。如果您需要另一种语言的模板 - 请考虑保留两个副本 - 英文版和本地化版。

1.1.3 所有项已启用

默认情况下,应启用所有监控项、触发器、LLD低级别自动发现规则和其他配置实体,以使模板开箱即用。

1.1.4 避免使用全局宏

如果使用了用户宏,请在模板中定义它们,而不是使用全局宏 — 这样用户就可以获得默认值或宏变量名称的示例。如果使用全局宏,则它们不会与模板一起导出。

1.1.5 避免使用全局正则表达式

尽可能避免在模板中使用全局正则表达式,因为它们不会随模板一起导出。如果使用全局正则表达式,请在自述文件中记录模板必须使用的全局正则表达式和值(请注意,从4.0版本开始,您可以在LLD低级别自动发现过滤器中使用NOT反向过滤结果,请参阅ZBXNEXT-2788

1.1.6 避免不同模板的触发器相互依赖

避免不同模板的触发器相互依赖。改用全局关联和事件标记。

1.1.7 保持模板模块化。 模板概述

通常,为了保持模板的可复用性和模块化,单个模板应该只能监控单个资源或不可分离的资源集。

如果您需要监控主机上的多个资源(您很可能需要监控),请考虑创建一个所谓的“概述”或“标签”空模板,然后将多个资源模板链接到该模板。

好的不好的
“Apache”,
“MySQL”,
“PHP”,
“Linux” all linked to profile template named “LAMP”.
Then, “LAMP” is linked to hosts “lamp1” and “lamp2”.
“Apache”,
“MySQL”,
“PHP”,
“Linux” all linked directly to hosts “lamp1” and “lamp2”

如果需要,它也是在概述模板级别重新定义用户宏的好地方。

1.2 模板

1.2.1 模板名称

所有部分都用空格隔开,也可以使用下划线。

所有名称(组、模板、监控项、触发器、图形、应用集、仪表盘、自动发现)在特定部分中都使用普通大小写 - 例如“Zabbix server”。

为了区分模板,最普遍的数据采集方法可以在名称的末尾附加后缀,例如:“by SNMPv1”、“by SNMPv2”、“by SNMPv3”、“by Zabbix agent”、“by Zabbix agent active”、“by IPMI”、“by JMX”、“by ODBC”等。

从Zabbix 5.2版本开始,标准模板名称不再包含单词“template”和<Category short name>前缀。名称应以<Template name>本身(特定部分)开头,也可以选择后跟数据采集方法。
在5.2之前:Template App Nginx by HTTP,Template DB MySQL
从5.2开始:Nginx by HTTP,MySQL

好的不好的
Nginx by HTTP
MySQL
Brocade switch by SNMPv2
Brocade switch SNMPv2
Brocade switch_by SNMPv2
Agent 2 template NGINX
Template DB MySQL
SNMP Brocade switch
Brocade switch Template
Template Brocade Switch
1.2.2 模板可见名称

目前,我们建议将模板可见名称留空。

1.2.3 模板描述

使用该字段提供模板的简短描述,包括:

  • 简短描述
  • 模板主页URL地址 (share.zabbix.com或者github.com或者其他URL地址)
  • 模板作者
  • 如果文档很短 - 可以在模板中提供文档
  • 当前模板版本
  • 也可以提供简单的更新日志
1.2.4 选择一个模板组

所有模板必须添加到名为 templates/<Category Full Name> 的模板子组中。

好的不好的
模板“Cisco by SNMP”添加到组“Templates/Network Devices” 模板“Cisco by SNMP”添加到组“Datacenter/Network”

1.3 监控项

1.3.1 监控项命名

为每个监控项选择一个简单的描述性名称。

用对象名称(metric location)作为监控项名称(metric)的前缀:

<metric location>: <metric name>, 例如:

  • Interface eth0: Bits in
  • Interface eth0: Bits out

如果metric location只是一个数字或索引,则可以使用“#”:

  • #0: CPU utilization
  • #1: CPU utilization

考虑添加诸如“每秒”、“每小时”等后缀来更好地描述指标。

监控项名称中不能使用任何用户宏或$1宏,它们已弃用,将在Zabbix 5.0中删除。

如果这是一个master监控项,请考虑在您的监控项名称前面加上“Get”,以突出显示此监控项是采集器项目,而不是最终指标

1.3.2 键值

键值使用以点号分割的层级格式。

namespace:

用于区分模板的指标。更简单的方法,可以使用产品名的缩写

例如: nginx, pgsql, pgbouncer, docker

component:

被监控对象的组件或子资源。它也可以是分层的。

例如: upstream, pool, db, db.table, db.client

metric_name:

例如: max_reached.

如果可能的话,最好按照监控对象本身的名称来命名指标,但如果指标格式完全不同,或者指标名称完全混乱且不人性化,则例外。

每个键值必须以字母开头,并且只能在基础部分使用小写的拉丁字母.

如果你需要一个空格,可以使用下划线“_”来替代,例如:response_time。

请记住,最大键值长度是255个字符(包括params部分)。

例如: request_time. request_count

考虑为采集器附加 .get 项,这些监控项负责检索要在相关项目中使用的数据(master监控项)。

例如: pgsql.db.get_connection […], nginx.get_stub, nginx.get_logs

考虑使用 .rate 作为每秒速率的指标。

例如: nginx.connections.accepted.rate

考虑使用 .total 作为总量的指标。

params:

在参数中, 必须指定的参数应该放在前面,然后是可选参数。

1.3.3 监控项描述字段

使用该字段描述:

  • 监控项目的扩展描述,例如,相关指标的供应商描述
  • 为什么它这么重要
  • 如果可能,请提供文档参考
  • 有关此监控项如何采集数据或如何对其进行优化、配置的任何其他信息
1.3.4 单位

如果可能的话,别忘记填写单位.

将单位添加到黑名单中,来避免出现错误的单位自动转换。

例如:

使用 “!requests/s” 来避免 “Krequests/s” 出现。

使用预处理将GB,MB,KB单位转换为B (Bytes)。

使用预处理将毫秒(ms),分钟(minutes),小时(hours)转换为秒(seconds)。

1.3.5 值映射

在适用的情况下始终使用值映射,例如,在采集不同的状态时。

1.3.6 信息类型

在选择要使用哪种类型时采取类型限制:

执行转换后存储在数据库中的数据类型如下: 数字 (无正负) - 64位无符号整数 浮点数 - 浮点数,可以存储负值,值允许范围: -999999999999.9999 到 999999999999.9999。从Zabbix 2.2开始,还支持以科学记数法表示接收值。例如1e+7、1e-4 字符 – 短文本数据 日志 – 长文本数据,具有可选的日志相关属性(时间戳、日志源、严重性、日志事件ID) 文本 – 长文本数据,关于文本数据类型的限制,请参阅https://www.zabbix.com/documentation/current/manual/config/items/item

如果你的监控项是一个速率指标 (即使用了“每秒更改”的预处理步骤) - 请使用浮点数。

另外,如果需要存储负整数,不要忘记使用浮点数。

1.3.7 在更新间隔中使用时间后缀,可计算监控项公式

始终使用时间 (1m, 5m, 1d…) 后缀 来设置更新间隔, 历史数据保留时长, 趋势存储时间, 可计算监控项公式,来提高可读性。 请记住,你也可以在用户宏中使用它们,

1.3.8 选择一个更新间隔, 历史数据和趋势数据存储时长

默认情况下,使用:

更新间隔: 1m 历史数据保留时长: 7d 趋势存储时间: 365d

此外,在采集状态或配置数据(如序列号或主机名)等很少更改的监控项时,请考虑使用预处理步骤“Discard unchanged (with heartbeat)”:

如果监控项是一个 健康检查:

更新间隔设置为1m,预处理步骤“Discard unchanged (with heartbeat)”设置为1h。

如果监控项是一个 资产项目:

更新间隔设置为15m,预处理步骤“Discard unchanged (with heartbeat)”设置为24h。

如果监控项是一个 “Zabbix原始监控项(Zabbix raw item)” (master监控项或仅用于其他可计算监控项,见下文) - 更新历史数据保留时长设置为1h,趋势存储时间设置为0,因为不需要保留这些原始值。

另请注意:不要将更新间隔设置超过1d,这会导致你无法在“最新数据”中看到监控项数据,因为Zabbix前端认为24小时前收到的值不是最新的。

1.3.9 应用集

使用应用集来对监控项进行逻辑分组。首先考虑按指标位置(资源、子资源)对指标进行分组。

好的不好的
将所有与CPU相关的监控项分组到应用集“CPU”
CPU指标监控项添加到应用集“CPU”
所有键值为net.if.out[*]的监控项添加到应用集“Bits out”
CPU指标监控项添加到应用集“CPU”和“Performance”

不要使用应用集将监控项分成很细的组。为了模板可读性,仅在必要时将应用集拆分为子组。

考虑在必要时使用应用集原型。尤其是在预计会有大量被发现的监控项的地方。同样,通过应用集过滤最新数据和监控项,增加模板可读性。

好的不好的
网络接口指标添加到应用集原型“Interface {#IFNAME}”
所有PostgreSQL数据库指标添加到应用集原型“DB {#DBNAME}”
所有网络接口指标都添加到单个应用集“Interfaces”
所有PostgreSQL数据库指标添加到单个应用集“PostgreSQL”

一个监控项对于一个应用集

将监控项添加到单个应用集中。

虽然监控项可以添加到多个应用集中,但是最好不要那么做,以避免“最新数据”中的重复项,让用户难以理解。

Zabbix原始监控项 (Zabbix raw items)

如果监控项的唯一目的是为了采集和暂存值,然后将值传递给依赖监控项或者可计算监控项,可以添加到应用集“Zabbix raw items”。

好的可接受的
将master监控项(REST API响应结果为较长的JSON数据)添加到应用集“Zabbix item buffers” 保留master监控项采集的数据用于最终结果
1.3.10 可计算监控项

使用换行或者空格保证长公式具有可读性。

1.3.11 SNMP

SNMP OID 字段不应使用任何MIB对象, 这样模板可以在没有导入MIB库的情况下使用。同时,将MIB库中提供的指标名称作为键值,并在监控项描述中进行说明。

OID值不应该使用'.'作为开头。

好的不好的
1.3.6.1.4.1.1991.1.1.2.1.52.0 FOUNDRY-SN-AGENT-MIB::snAgGblCpuUtil1MinAvg.0 or .1.3.6.1.4.1.1991.1.1.2.1.52.0

将SNMP监控项目的字段“端口”留空。如果保留为空,则将从SNMP主机接口使用该端口。

1.4 低级别自动发现规则 (LLD)

1.4.1 命名

为每个发现规则选择一个简单的描述性名称. 确保它总是以“discovery”这个词结尾。

好的不好的
Network interface discovery
CPU core discovery
Network
Discovery of CPU cores

从LLD生成的监控项、触发器、图形名称应以它们所属的发现实体名称作为前缀。唯一的例外是单例发现模式。

1.4.2 更新间隔

使用1h。有关高级用法,请参阅最佳实践部分。

1.4.3 资源周期不足

保持默认值:30d.

1.4.4 过滤器

在过滤器中使用用户宏

考虑在过滤器中使用用户宏,每个LLD宏对应两个用户宏。

好的不好的
{#IFNAME} 匹配 {$NET.IF.IFNAME.MATCHES}
{#IFNAME} 不匹配 {$NET.IF.IFNAME.NOT_MATCHES}
..
{#IFTYPE} 匹配 {$NET.IF. IFTYPE.MATCHES}
{#IFTYPE} 不匹配 {$NET.IF.IFTYPE.NOT_MATCHES}

用户宏变量定义:
{$NET.IF.IFNAME.MATCHES} = ^.*$
{$NET.IF.IFNAME.NOT_MATCHES} = (^Software Loopback Interface|^NULL[0-9.]*$| ^[Ll]o[0-9.]*$| ^[Ss]ystem$|^Nu[0-9.]*$)

或者
{$NET.IF. IFTYPE.MATCHES} = ^.*$
{$NET.IF. IFTYPE.NOT_MATCHES} = CHANGE_IF_NEEDED
{#IFNAME} 匹配 "@Network interfaces for discovery"

这样,可以在链接模板或主机级别上重新定义过滤器,而无需更改模板本身。

SNMP

发现SNMP OID时,请确保使用与MIB转换值和原始值匹配的正则表达式。即使没有将适当的MIB库加载到Zabbix服务器或代理中,这也会使用过滤器。

例如,当你只需要查找资源类型为 hrStorageFixedDisk(1.3.6.1.2.1.25.2.1.4) 的磁盘时,可以使用过滤器

好的不好的
匹配 .*(\.4|hrStorageFixedDisk)$ 匹配 .*(hrStorageFixedDisk)$

1.5 触发器和问题

1.5.1 命名

触发器名称必须以它们所属的LLD对象作为前缀。

触发器名称不应使用{HOST.NAME}宏来缩短名称。考虑从主机列获取数据。

避免在触发器名称中使用{ITEM.LASTVALUE}

不要在触发器名称中使用{ITEM.LASTVALUE1-9}宏。从4.0开始,这些宏在问题名称生成并保留时会扩展为值。

在操作数据(Operational data)字段中使用它(从Zabbix 4.4开始可用)

用触发器名称说明阈值

考虑在触发器名称的括号中说明阈值。

好的不好的
Temperature is too high (over 35 C for 5m)
CPU load is too high (over 1.5)
MySQL: Refused connections (max_connections limit reached)
Temperature is too high ( now: 40)
CPU load is too high
MySQL: Refused connections
1.5.2 触发器描述

使用该字段描述:

  • 详细地描述这个问题。不要只是复制触发器名称
  • 为什么检查这个很重要
  • 如果可能,请描述问题可能产生的原因以及应采取的措施
  • 提供参考文档(如果有)
1.5.3 表达式

触发器表达式应该具有合理的抗抖动能力 — 也就是说,不只是依赖最后一个值,而是检查最近5或10分钟。另一方面,不要让表达式过于复杂 - 例如,不要使用触发器间隔,除非它真的有更加重要的用途。

最好能在触发器表达式中使用用户宏调整阈值。

好的不好的
{template:temperature.last()}>{$TEMP.MAX.WARN}} {template:temperature.last()}>30

使用换行和空格让较长的触发器表达式更具可读性。

1.5.4 在触发器中使用时间和单位后缀

在触发器表达式,问题名称,触发器描述,操作数据(operational data)中,始终使用时间 (1m, 5m, 1d…) 和大小 (1K, 1B, 1G) 后缀 来提高可读性。请记住,你也可以在用户宏中使用它们。

好的不好的
{template:temperature.avg(10m)>{$TEMP.MAX.WARN}}
{template:memory.free.avg(10m)<{$MEM_FREE.WARN} where {$MEM_FREE.WARN} = 100M
{template:temperature.avg(600)>{$TEMP.MAX.WARN}}
{template:memory.free.avg(10m)<{$MEM_FREE.WARN} where {$MEM_FREE.WARN} = 104857600
1.5.5 严重性

使用标准的Zabbix严重性等级在模板中创建触发器。考虑选择分配给触发器的严重性等级时,请记住以下几点:

严重性描述示例预计需要在多少时间内得到响应(并不总是正确!),仅作为示例参考
未分类 正常情况下不使用
信息 产生的事件需要被关注。这是未来可能有助于回顾性分析或审计的信息。 例如: 序列号变更, 用户登录等等
警告 一个轻微的警报,如果不关注可能导致一些更严重的问题。 例如: 磁盘剩余空间不足 在工作时间进行处理,不需要通知。
一般严重 性能警报:表示严重性能问题或关键服务降级的警报。
故障警报:部分资源故障或警告,如果不关注可能导致设备完全故障。
例如: CPU使用率高,可用内存不足,设备温度过高,磁盘阵列中的磁盘出现故障,网站访问变慢。 在工作时间进行处理,如果问题持续数小时,则创建问题事件工单。
严重 性能警报:关键服务不可用。
故障报警:设备不工作或不可用。
例如:Ping不通,网站无法访问。 如果影响服务,请在工作时间内进行处理,通知负责人。
否则,请在工作时间内创建问题事件工单。
灾难 保留用于提示停电、灾难、全局业务服务故障的警报。\\资源模板中不应存在具有灾难级别严重性的触发器。 例如:里加(Riga)数据中心异常, 核心网络出现问题,超过50%的用户无法在网站上购买任何东西。 一定要立即通知负责人

1.6 图形和仪表盘

1.6.1 图形名称

图形名称必须以它们所属的低级别自动发现对象作为前缀。

图形名称也可以以资源作为前缀。

1.7 用户宏

用户宏和LLD宏只接受大写字母,即 [A-Z0-9._]。

考虑使用特定于模板的前缀(命名空间)以避免与其他模板的潜在冲突。

好的或者不好的
{$MYSQL.HOST}
{$MYSQL.PORT}
{$MYSQL.PARAM1}
{$MYSQL_HOST}
{$MYSQL_PORT}
{$MYSQL_PARAM1}
{$HOST}
{$PORT}
{$PARAM1}

在LLD使用 宏上下文。 通过这种方式,不仅可以在主机级别,还可以在LLD实体级别更改和优化宏。

好的不好的
{$IF.ERRORS.WARN:”{#IFNAME}”}
{$TEMP.MAX.WARN:”{#SENSORNAME }”}
{$IF.ERRORS.WARN}
{$TEMP.MAX.WARN}

在宏变量名称中仅使用比较常见的单词缩写,例如:

警告(WARNING) – WARN
严重(CRITICAL) – CRIT
百分比(PERCENTAGE) – PCT
温度(TEMPERATURE) – TEMP
错误数(ERRORS) – ERR
丢包数(DISCARDS) – DISC
主机名(HOSTNAME) - HOST
数据库(DATABASE) – DB
密码(PASSWORD) – PASS
用户名(USERNAME) - USER
阈值(THRESHOLD) – THRESH
连接数(CONNECTIONS) - CONN
最大(MAXIMUM) – MAX
最小(MINIMUM) – MIN
平均(AVERAGE) – AVG
秒(SECOND) – SEC

如果没有好的缩写形式 - 最好设置完整的宏变量名,虽然这可能会很长,但是容易让人理解。

1.7.1 触发器宏

对于触发器表达式(阈值)中使用的宏,请使用:

{$[<NAMESPACE>.]<METRIC_NAME>[.MAX|.MIN][.OK |.WARN|.CRIT}]

当需要突出显示是高阈值还是低阈值时,请使用MAX | MIN。

好的不好的
{$MYSQL.REPLICATION_LAG.MAX.WARN}
{$TEMP.MAX.WARN:”{#SENSOR}”}
{$SERVICE.STATUS.CRIT}
{$IF.ERRORS.MAX.WARN}
{$DISK.STATUS.OK}
{$DISK.STATUS.WARN}
{$DISK.STATUS.CRIT}
{$MEM_UTIL.MAX.WARN}
{$MEM_UTIL.MAX.CRIT}
{$DISK_OK_STATUS}
{$MEMORY_UTIL_MAX}

1.8 文件

以XML文件共享你的模板。文件名应以单词“template”开头,后跟类别| 类别简称,然后是完整的模板名称。使用小写,将空格替换为下划线_

好的不好的
template_app_nginx.xml
template_db_mysql_by_odbc.xml
Template App Nginx.xml
Template_DB_MySQL.xml
mysql_by_odbc.xml

将每个模板文件存储在一个单独的目录中。在此目录中创建一个README.md文件或类似文件,以描述此模板的作用以及如何安装它。将用户参数文件或运行此模板所需的任何其他文件也放置到此目录中。

1.8.1 选择模板类别

您可以创建自己的模板类别。但首先,考虑使用以下推荐的类别之一:

类别全名类别简称描述模板名称 → 文件名称
Modules Module 不用于直接主机链接但通常用作其他模板依赖项的所有模板 Generic SNMPv2 → template_module_generic_snmpv2.xml
HOST-RESOURCES-MIB SNMPv2 → template_module_host-resources-mib-snmpv2.xml
Interfaces SNMPv2 → template_module_interfaces_snmpv2.xml
Interfaces simple SNMPv2 → template_module_interfaces_simple_snmpv2.xml
ICMP ping → template_module_icmp_ping.xml
Network devices Net 主要作用是联网的所有网络设备(或软件),包括交换机、路由器、无线、防火墙等 Generic device SNMPv2 → template_net_generic_device_snmpv2.xml
Juniper SNMPv2 → template_net_juniper_snmpv2.xml
Mikrotik SNMPv2 → template_net_mikrotik_snmpv2.xml
Dell Force S-Series SNMPv1 → template_net_dell_force_s-series_snmpv1.xml
Brocade FC SNMPv1 → template_net_brocade_fc_snmpv1.xml
Storage devices Storage FC和其他存储设备 IBM Storwize by SNMPv1 → template_storage_ibm_storwize_by _snmpv1.xml
EMC VNX → template_storage_emc_vnx.xml
Server hardware Server 服务器硬件(iLO、IMM、blades等) IBM IMM2 by SNMPv2 → template_server_ibm_imm2_by_snmpv2.xml
IBM IMM2 by IPMI → template_server_ibm_imm2_by_ipmi.xml
HP iLO by SNMPv2 → template_server_hp_ilo_by_snmpv2.xml
Operating systems OS 服务器操作系统(Windows、Linux、OSX、ESXi by SNMP、Solaris等) Linux → template_os_linux.xml
Linux by Zabbix agent active → template_os_linux_by_zabbix_agent_active.xml
Linux by SNMPv2 → template_os_linux_by_snmpv2.xml
Linux VMware → template_os_linux_vmware.xml
ESXi SNMPv2 → template_os_esxi_snmpv2.xml
Solaris → template_os_solaris.xml
Windows → template_os_windows.xml
Windows XP by SNMPv2 → template_os_windows_xp_by_snmpv2.xml
Databases DB 所有关系型和非关系型数据库以及键值存储 MySQL → template_db_mysql/xml
Redis → template_db_redis.xml
Oracle by ODBC → template_db_oracle_by_odbc.xml
Power Power UPS和其他电源类设备 Generic UPS by SNMPv2 → template_power_generic_ups_by_snmpv2.xml
APC by SNMPv2 → template_power_apc_by_snmpv2.xml
Eaton SNMPv2 → template_power_eaton_snmpv2.xml
Telephony Tel 硬件和软件电话系统(Asterisk, Panasonic, Avaya等),包括IP电话 Asterisk by SNMPv3 → template_tel_asterisk_by_snmpv3.xml
Avaya → template_tel_avaya.xml
Virtualization VM 虚拟机, Hyper-V, VMware, Xen, KVM… VMWare → template_vm_vmware.xml
Hyper-V → template_vm_hyper-v.xml
Xen → template_vm_xen.xml
Printers Printer 打印机和多功能打印机 Printer generic by SNMPv2 → template_printer_generic_by_snmpv2.xml
HP LaserJet → template_printer_hp_laserjet.xml
Applications App 不属于上述任何类别的软件 Generic Java JMX → template_app_generic_java_jmx.xml
RabbitMQ → template_app_rabbitmq.xml
Apache Tomcat JMX → template_app_apache_tomcat_jmx.xml
Apache ActiveMQ → template_app_apache_activemq.xml
Docker → template_app_docker
Apache2 → template_app_apache2.xml
Nginx by HTTP → template_app_nginx_by_http.xml
Hardware HW 不属于上述任何类别的其他硬件 Netbotz by SNMPv2 → template_hw_netbotz_by_snmpv2.xml
Siemens PLC by Modbus → template_hw_siemens_plc_by_modbus
Skycontrol by SNMPv2 → template_hw_skycontrol_by_snmpv2.xml
Skycontrol SNMPv1 → template_hw_skycontrol_snmpv1.xml
Netping → template_hw_netping.xml
1.8.2 说明文件结构

对模板的作用、如何安装、配置和调优提供清晰的解释是非常重要的。考虑在Readme文件中提供此类文档。Readme文件应包含以下部分:

概述

描述此模板是关于什么的,它测试的监控对象的版本。

设置

提供有关如何安装模板的清晰步骤说明。

Zabbix配置

在这里提供有关如何使用宏等配置模板的信息。

模板链接

列出所有模板链接(如果有)

低级别自动发现规则

列出应用了过滤器的低级别自动发现规则。

采集的监控项

列出所有采集的监控项。

触发器

列出所有触发器。

意见反馈

描述如何提供意见反馈。

演示

可选。提供一些实际模板的截图。

已知问题

在这里描述所有已知的限制。

参考文献

可选。提供启发你创建此模板的相关链接,或对有关监控对象的官方文档的引用。

最佳实践

2.1 低级别自动发现项目和处理不支持的项目

尽可能使用 低级别自动发现。这有助于避免不支持的项目,并提高模板的灵活性。

好的不好的
使用LLD发现温度传感器
使用LLD发现网络接口
使用LLD发现CPU
不使用LLD,而是直接使用静态的监控项
例如:CPU core #1 utilization,Sensor 1 temperature value,network interface Fa0/0
2.1.1 发现频率

在Zabbix中,低级别自动发现被认为是一项繁重的操作,因此其频率应该很低。考虑总是从每小时1次开始。

如果低级别自动发现使用另一个频繁更新的监控项作为源(监控项类型 = 相关项目)- 请为此类低级别自动发现使用预处理步骤 “Discard unchanged with heartbeat”。 你也可以将这种预处理步骤用于其他的低级别自动发现。

在这种情况下,您还可以使用低级别自动发现的预处理步骤处理数据,例如,来自master监控项的数据:

[ 
 {
  “volume_name”: “my disk1”,
  “volume_size”:  1000000000000,
  “volume_used”:  800000000000,
  “volume_updated_at”: “2019-07-01 00:00:00”
 },
 {
  “volume_name”: “my disk2”,
  “volume_size”:  1000000000000,
  “volume_used”:  800000000000,
  “volume_updated_at”: “2019-07-01 00:00:00”
 }
]

对于此类输出,请考虑使用JS或JSONPath预处理步骤将此数组转换为:

[ 
 {
  “volume_name”: “my disk1”
 },
 {
  “volume_name”: “my disk2”
 }
]

该预处理步骤需要应用在丢弃规则(throttling)之前。

2.1.2 Zabbix采集器的低级别自动发现

当通过Zabbix采集器协议推送监控项时 – 考虑推送低级别自动发现数据,因为低级别自动发现项支持它。

2.1.3 使用预处理动态构建低级别自动发现数据

通过JavaScript预处理和其他强大的功能,您可以动态创建低级别自动发现数据。此方法比外部发现脚本更好:

  • 使所有未来使用模板的用户都能清楚地看到低级别自动发现规则
  • 将低级别自动发现作为监控解决方案的一部分 — 可以轻松地将模板的部分内容进行转移
  • 避免外部依赖,如外部发现脚本

示例 1

使用Zabbix的HTTP代理通过链接http://demo.nginx.com/api/3/http/server_zones来获取Nginx Plus zones stats信息如下:

{
  "hg.nginx.org": {
    "processing": 0,
    "requests": 175276,
    "responses": {
      "1xx": 0,
      "2xx": 162948,
      "3xx": 10117,
      "4xx": 2125,
      "5xx": 8,
      "total": 175198
    },
    "discarded": 78,
    "received": 50484208,
    "sent": 7356417338
  },
 "trac.nginx.org": {
    "processing": 7,
    "requests": 448613,
    "responses": {
      "1xx": 0,
      "2xx": 305562,
      "3xx": 87065,
      "4xx": 23136,
      "5xx": 5127,
      "total": 420890
    },
    "discarded": 27716,
    "received": 137307886,
    "sent": 3989556941
  }
}

通过依赖监控项将此输出传递给低级别自动发现规则,并使用Javascript脚本进行预处理,如下所示:

//解析NGINX plus输出:
output = Object.keys(JSON.parse(value)).map(function(zone){
    return {"{#NGINX_ZONE}": zone}
})
return JSON.stringify({"data": output})

使原始JSON对象成为一个完全兼容LLD的JSON数组,可以用于NGINX zones低级别自动发现。

示例 2

使用Zabbix监控项 vfs.file.contents[/proc/diskstats] 获取磁盘的状态信息:

   7       0 loop0 2 0 10 0 0 0 0 0 0 0 0
   7       1 loop1 0 0 0 0 0 0 0 0 0 0 0
   7       2 loop2 0 0 0 0 0 0 0 0 0 0 0
   7       3 loop3 0 0 0 0 0 0 0 0 0 0 0
   7       4 loop4 0 0 0 0 0 0 0 0 0 0 0
   7       5 loop5 0 0 0 0 0 0 0 0 0 0 0
   7       6 loop6 0 0 0 0 0 0 0 0 0 0 0
   7       7 loop7 0 0 0 0 0 0 0 0 0 0 0
   8       0 sda 192218 21315 11221888 13020540 28630719 8482221 801446972 388811708 0 265066852 401774948
   8       1 sda1 252 59 11294 5424 6 0 12 464 0 4160 5888
   8       2 sda2 4 0 8 72 0 0 0 0 0 72 72
   8       5 sda5 191918 21256 11208378 13014352 22872982 8482221 801446960 215739516 0 99497600 228699704
 252       0 dm-0 186763 0 10985130 22979168 31930494 0 799946248 396490524 0 265080476 419505356
 252       1 dm-1 26897 0 220608 688352 187589 0 1500712 23501956 0 212608 24190464

将此输出传递给普通监控项,然后使用Javascript脚本进行预处理,如下所示:

var parsed = value.split("\n").reduce(function(acc, x, i) {
  acc["values"][x.split(/ +/)[3]] = x.split(/ +/).slice(1)
  acc["lld"].push({"{#DEVNAME}":x.split(/ +/)[3]});
  return acc;
}, {"values":{}, "lld": []});

return JSON.stringify(parsed);

使用上面的监控项作为master监控项创建新的低级别自动发现规则。对此低级别自动发现规则使用预处理步骤JSONPATH:

$.lld
2.1.4 单例模式的低级别自动发现

虽然低级别自动发现是为多个类似实体(如网络接口或磁盘)自动创建监控项、触发器和图形,但它也可以用作单个实例中是否存在实体的简单判断。

这种方法使模板保持简洁,当模板应用于具有不同配置或受监控对象版本的主机时,用户不会面临不支持的监控项。

要使用单例模式,需要执行以下操作:

  • 创建低级别自动发现规则。使用普通监控项或依赖监控项来获取非LLD格式的值。举个简单的例子,让一个普通的监控项返回文本“found”或“missing”。
  • 在低级别自动发现规则中使用预处理:
    • 检查接收的值是否匹配条件,以及是否应该创建监控项
    • 使用Javascript预处理,在长度为1的LLD数组中添加一个名为{#SINGLETON}的空的LLD宏

这两个步骤可以组合在一行JavaScript脚本中,生成LLD数组。

return JSON.stringify(value === 'found' ? [{'{#SINGLETON}': ''}] : []);

在监控项原型键值的方括号内使用{#SINGLETON}这个宏。

将此宏附加到任何图形原型的名称中。

空的宏是必需的,因此Zabbix可以将监控项或图形与原型区分开来。当宏在发现后并扩展开时 - 只能看到与静态定义的名称完全相同的监控项名称或图形名称。

以Zabbix 4.4的模板“Template App Apache by HTTP”中的MPM event discovery为例。我们也会在我们的博客里详细描述。

好的不好的
模板“Template App Apache by HTTP (Zabbix 4.4)”中的MPM event discovery使用单例发现模式 监控apache http服务器而不使用这种单例方法的模板,导致在禁用MPM事件模块时不支持MPM事件指标
有一个约束条件,即LLD宏必须位于监控项键值的方括号内。

2.2 监控项数据采集

2.2.1 尽可能在编写外部脚本/模块时减少对外部库的依赖

如果您需要使用外部脚本 - 请考虑使其可移植并易于安装的外部脚本。

2.2.2 预处理

更推荐使用Zabbix预处理,替代在Zabbix客户端中使用脚本进行复杂的数据解析:

  • 尽可能减少Zabbix客户端的使用
  • 使所有未来使用模板的用户都能清楚地看到预处理规则
  • 将预处理规则作为监控解决方案的一部分 — 可以轻松地将模板的部分内容进行转移
  • 避免在Windows和Linux平台上维护两套预处理规则
2.2.3 MASTER监控项 + 依赖监控项/预处理

更推荐使用Zabbix的master监控项 + 依赖监控项来支持多个单独的调用:

  • 为了使Zabbix尽可能减少对系统的消耗 - 减少对被监控对象的调用

复用master监控项的内容以创建低级别自动发现规则。然后再次复用master监控项的值,用于从监控项原型创建监控项。

master监控项历史数据保留时长

master监控项数据量可能非常大 (ZBXNEXT-223),而这些值仅用于对依赖监控项进行预处理。因此,将其历史数据保留时长缩短到最小的非零值,即1h

但是如果我们将历史数据保留时长设置为0呢?这样设置会给你带来一些其他的问题:

  • master监控项的nodata() 触发器会产生误报
  • 可用于数据收集的故障排除的信息较少

因此,我们建议此时选择1h

2.2.4 安全和认证

虽然以用户宏的形式传递密码看起来很方便,但要尽量避免。

如果您需要进行身份验证以收集指标数据 - 最好创建名为zbx_monitor且具有只读访问权限的用户。

2.2.5 使用用户自定义参数/外部检查采集数据

如果可以的话,更推荐使用用户自定义参数/外部检查或具有依赖监控项/预处理的模块而不是Zabbix采集器,因为使用Zabbix采集器时,你对数据采集的控制较少。

2.2.6 使用Zabbix采集器获取数据

如果存在以下情况之一,则首选使用Zabbix采集器而不是用户自定义参数/外部检查:

  • 需要从自己的自定义应用程序发送指标数据
  • 数据采集不规范(备份作业、报警信号等)
  • 需要发送带有不确定时间戳的数据
  • 完成数据收集脚本可能需要30秒以上
2.2.7 使用HTTP代理或者web.page.get采集数据

HTTP消息头将在web.page.get中删除

从Zabbix 4.4开始,web.paget.get将返回HTTP正文和消息头作为监控项值。因此,要使用Zabbix客户端键值web.page.get获取有效的JSON/XML数据,请使用 预处理中的正则表达式删除HTTP消息头:

Regular expression,
parameter = \n\s?\n(.*)
output: \1

这将返回JSON/XML数据,你可以使用预处理中的JSONPath/XMLPath轻松解析

2.3 健康检查和不同的状态

对于使用整数表示的状态指标,始终使用值映射

如果监控项采集结果中只包含YES/NO或者TRUE/FALSE两种状态时,考虑使用 预处理步骤 “Boolean to decimal”,以减少数据库存储空间使用,可以通过值映射进行展示。

考虑使用预处理步骤 “Discard unchanged with heartbeat” 处理状态指标类型的监控项。 这将极大地改善状态变化的反应,并且不会给Zabbix数据库带来额外的负载。比如设置更新间隔为10s,“Discard unchanged with heartbeat”为5m,或者设置更新间隔为1m,“Discard unchanged with heartbeat”为30m。 请注意,诸如count()或diff()之类的触发器函数的工作方式可能不同。

2.3.1 健康检查和不同状态的触发器

对于运行状况检查触发器,请考虑使用简单的触发器表达式:

{TEMPLATE_NAME:METRIC.count(#1,{$SERVICE.STATUS.CRIT},eq)}=1

如果运行状况检查指标仅返回整数值而不返回文本状态,则还可以使用:

{TEMPLATE_NAME:METRIC.last()}={$SERVICE.STATUS.CRIT}

为了让触发器更加简单。

如果运行状况检查会返回多个不同的值,请尝试将它们映射到以下不同严重性的触发器(简化严重性):

级别建议Zabbix严重性触发器名称触发器依赖关系示例表达式
Not OK 信息 Service X is not OK 依赖警告,一般严重或严重级别的触发器 {TEMPLATE_NAME:METRIC.count(#1,{$SERVICE.STATUS.OK},ne)}=1
Warning 警告 Service X is in warning state 依赖一般严重或严重级别的触发器 {TEMPLATE_NAME:METRIC.count(#1,{$SERVICE.STATUS.WARN},eq)}=1
Critical 一般严重或严重 Service X is in critical state {TEMPLATE_NAME:METRIC.count(#1,{$SERVICE.STATUS.CRIT},eq)}=1

如果错误状态太多或不是所有状态都已知,请使用“Not OK”级别。

{TEMPLATE_NAME:METRIC.count(#1,{$SERVICE.STATUS.OK},ne)}=1

请注意 Not OK 表达式中的 'ne'。

如果有多个指标值都表示严重级别,请将它们放在一个表达式中:

{TEMPLATE_NAME:METRIC.count(#1,{$SERVICE.STATUS.CRIT:"not_responding"},eq)}=1 or {TEMPLATE_NAME:METRIC.count(#1,{$SERVICE.STATUS.CRIT:"timeout"},eq)}=1

请注意,可以使用上下文宏来标记不同的状态。

对于有多个不同状态值的项目,请考虑添加恢复表达式:

{TEMPLATE_NAME:METRIC.count(5m,{$SERVICE.STATUS.CRIT},eq)}=0

2.4 采集资产清单和文本描述状态

对于资产或者其他很少更改的文本数据,考虑使用预处理步骤“Discard unchanged with heartbeat”。这将极大地改善状态变化的反应,并且不会给Zabbix数据库带来额外的负载。比如设置更新间隔为15m,“Discard unchanged with heartbeat”为1d。 请注意,诸如count()或diff()之类的触发器函数的工作方式可能不同。

如果从采集频率较高的master监控项中采集很少更改的资产字段,请始终使用此预处理步骤。

2.5 使用触发器代码片段

检查下面的触发器代码片段,并考虑重用配置,以避免重复造轮子。

案例:某些监控对象刚刚重启

触发器: <resource> has just been restarted (uptime < 10m)

适用于 设备、主机或软件/服务运行的正常运行时间计数器
名称 <resource> has been restarted (uptime < 10m)
描述 <resource> uptime is less than 10 minutes
表达式 {TEMPLATE_NAME:METRIC.last()}<10m
恢复表达式 -
恢复模式 -
允许手动关闭 Yes
严重性 主机为警告,其他为信息
依赖关系 -

案例:master监控项 + 依赖监控项中的预处理

触发器: Master item is not responding

<resource>: Failed to get items (no data for 30m)

适用于 用于一次性采集多个指标的监控项
表达式 {TEMPLATE_NAME:METRIC.nodata(30m)}=1
恢复表达式 -
恢复模式 -
允许手动关闭
严重性 警告
依赖关系 如果有: <Proc> is not running

案例:HTTP监控项 + 依赖监控项中使用预处理的正则表达式步骤

触发器: HTTP item is not responding

适用于 为其他相关项目(在预处理步骤中使用正则表达式)提供原始数据的HTTP监控项目。
在恢复模式中使用‘Body 和 Headers’
表达式 {TEMPLATE_NAME:METRIC.str(\“HTTP/1.1 200\”)}=0 or\n {TEMPLATE_NAME:METRIC.nodata(30m)}=1
恢复表达式 -
允许手动关闭
严重性 警告
依赖关系 如果有: <Proc> is not running

案例:对于变化较慢的值,数据采集结果高于或者低于设定的阈值

对于变化较慢的值(如温度),温度过高使用max(),温度过低使用min(),当达到阈值时立即响应,并通过延迟(确认)进行恢复。

触发器: <VALUE> is too high (over X)

适用于 温度过高 (变化较慢)
表达式 {TEMPLATE_NAME:METRIC.max(5m) > X

触发器: <VALUE> is too low (under X)

适用于 温度过低 (变化较慢)
表达 {TEMPLATE_NAME:METRIC.min(5m)} < X

案例:对于波动较大且频繁的值,使用连续超过5分钟高于或者低于设定的阈值

对于波动较大的值,使用min(高阈值)或者max(低阈值)作为触发器,避免触发器因波动产生误报。

触发器: <VALUE> is too high (over X for 5m)

适用于 CPU使用率 (波动较大), 信号强度(波动较大), 网络利用率
表达式 {TEMPLATE_NAME:METRIC.min(5m)} > X

触发器: <VALUE> is too low (under X for 5m)

适用于 CPU使用率 (波动较大), 信号强度(波动较大), 网络利用率
表达式 {TEMPLATE_NAME:METRIC.max(5m)} < X

案例:设备序列号发生变化

触发器: Serial numbers controls

适用于 序列号的监控项
名称 <resource> has been replaced (new serial number received)
描述 <resource> serial number has changed. Ack to close
表达式 {TEMPLATE_NAME:METRIC.diff()}=1 and {TEMPLATE_NAME:METRIC.strlen()}>0
恢复表达式 -
恢复模式
允许手动关闭
严重性 信息
依赖关系 -

案例:设备的软件版本发生变化

触发器: Version controls

适用于 软件版本的监控项
名称 <resource> version has changed (new version: {ITEM.VALUE})
描述 <resource> version has changed. Ack to close
表达式 {TEMPLATE_NAME:METRIC.diff()}=1 and {TEMPLATE_NAME:METRIC.strlen()}>0
恢复表达式 -
恢复模式
允许手动关闭
严重性 信息
依赖关系 -

案例:剩余磁盘空间

触发器: Filesystem space is critically low with timeleft with macro

{$VFS.FS.PUSED.MAX.CRIT:\"__RESOURCE__\"} = 90

适用于 文件系统
名称 Disk space is critically low (used > {$VFS.FS.PUSED.MAX.CRIT:\"__RESOURCE__\"})
描述 Space used: {ITEM.VALUE3} of {ITEM.VALUE2} ({ITEM.VALUE1}), time left till full: < 24h.

Two conditions should match: First, space utilization should be above {$VFS.FS.PUSED.MAX.CRIT:\"__RESOURCE__\"}.

Second condition should be one of the following:
- The disk free space is less than 5G.
- The disk will be full in less than 24 hours.
表达式 {TEMPLATE_NAME:vfs.fs.pused.last()}>{$VFS.FS.PUSED.MAX.CRIT:\"__RESOURCE__\"} and (({TEMPLATE_NAME:vfs.fs.total.last()}-{TEMPLATE_NAME:vfs.fs.used.last()})<5G or {TEMPLATE_NAME:vfs.fs.pused.timeleft(1h,,100)}<1d)
恢复表达式 -
恢复模式
允许手动关闭
严重性 一般严重
依赖关系 -

触发器: Filesystem space is low with timeleft with macro

{$VFS.FS.PUSED.WARN.CRIT:\"__RESOURCE__\"} = 80

适用于 文件系统
名称 Disk space is low (used > {$VFS.FS.PUSED.MAX.WARN:\"__RESOURCE__\"})
描述 Space used: {ITEM.VALUE3} of {ITEM.VALUE2} ({ITEM.VALUE1}), time left till full: < 24h.

Two conditions should match: First, space utilization should be above {$VFS.FS.PUSED.MAX.WARN:\"__RESOURCE__\"}.

Second condition should be one of the following:
- The disk free space is less than 10G.
- The disk will be full in less than 24 hours.
表达式 {TEMPLATE_NAME:vfs.fs.pused.last()}>{$VFS.FS.PUSED.MAX.WARN:\"__RESOURCE__\"} and (({TEMPLATE_NAME:vfs.fs.total.last()}-{TEMPLATE_NAME:vfs.fs.used.last()})<10G or {TEMPLATE_NAME:vfs.fs.pused.timeleft(1h,,100)}<1d)
恢复表达式 -
恢复模式
允许手动关闭
严重性 警告
依赖关系 Disk space is critically low.

2.6 可视化、图形和仪表盘

考虑为可能相关的监控项添加自定义图形。

好的: 包含不同CPU modes(user, system…)的所有监控项的图形

考虑添加仪表盘(聚合图形)来展示监控对象摘要或概览。

好的: 模板“Template App Zabbix Server”是一个好的例子

2.7 事件标签的使用

本节将在下一版本的文件中填写。