本文整理自Zabbix中级认证专家李铭栓（满分学员）在Zabbix Meetup广州站的演讲。

掌握这几种监控方式解决80%的监控问题，剩下的20%如何实现？这里有答案！

几点经验分享：

1.先使用Zabbix默认模板，再逐步了解指标和触发器含义、模板规范等，最后优化模板；

2.尽量多使用依赖监控项和预处理；

3.合理使用LLD，减少不必要的手动配置；  

4.多看Zabbix官方文档，不懂可以参加Zabbix官方认证培训。

大家下午好，我是李铭栓。今天要与大家分享的是系统化的学习经验。对于刚接触Zabbix的新手，应该如何快速地学习和了解，以便在短时间内有目标地逐步深入学习Zabbix呢？让我们来看一下本次演讲的大纲。我将分为三个部分进行讲解，从初识到学习了解，最后到重复实践，依次向大家介绍。

1. 自底向上认识Zabbix

如果身边有人刚接触Zabbix，甚至对每个组件的功能都不是很理解，我们可以通过一个形象的例子来介绍，这样会更容易理解。对于刚接触Zabbix的用户来说，可能首先会看到Zabbix Web页面，因为他们会从这里开始使用。但是，Zabbix Web页面的菜单项很多，页面也很多，可能会让人感到一头雾水，不知道应该从哪个页面开始学习。在这里，我提供一个新颖的思路，就是让他们想象自己是Zabbix Web页面的开发人员，然后思考他们会如何设计这个页面的模块。

为什么我会这么想呢？因为我有一些网站和系统开发的经验。所以，开发这些页面时，我会首先考虑功能性。比如，对于一个Web系统，首先会有用户管理模块，因此会有一个用户列表页面，用来查看所有的用户。如果用户很多，可能需要对他们进行分组，所以可能会有一个用户组页面。由于Web页面可能很复杂，不同的用户可能需要看到不同的内容，因此就会有用户角色的功能。

回到Zabbix Web页面的设计，由于它是一个监控工具，因此页面上肯定会有配置和查看的功能。这自然而然地引出了监控配置和监控查看可能会有哪些页面。因此，在初次了解Zabbix Web页面时，应该首先关注这三大功能的相关页面，如用户管理、监控配置和监控查看，这样就可以找到对应的页面，了解它们的功能。

总之，我认为对于新手用户来说，应该采用一种快速了解Zabbix的方法论。我们不应该停留在表面上的认识和理解，而是应该从它的基础本质出发，变被动为主动。因此，要主动地理解Zabbix作为监控工具的本质是怎样的。

2.由浅入深学习Zabbix

接下来要深入学习Zabbix，进入第二部分，由浅入深学习Zabbix。作为监控工具，学习如何添加监控是首要任务。在这里我不会详细讲解具体的配置步骤，因为Zabbix的官方文档已经提供了很好的帮助。我将分享一条基本的学习和配置路径，就像PPT所示的那样，这里的配置从左到右的难度是逐步递增的。

我认为最简单的监控是ping监控。只需要输入一个IP地址或者DNS地址，将其添加为主机，然后连接ping模板，就可以实现监控了。其次是ICMP监控，通过ICMP可以监控大部分网络设备，比如路由器和交换机。刚开始可以选择Zabbix上已经提供现成模板的一些设备进行监控，比如思科设备、华为设备等等。

随后，难度会逐步增加，可能就是Web监控。通过Web监控，可以监测一些网站的状态码和下载速度。关于这方面的配置，Zabbix官方文档中有详细的指引和示例，我也强烈建议跟着文档一步步实践。

最后就是Agent监控了，这是最常见的场景之一。在服务器上安装Zabbix Agent，并配置好，可以监控服务器的性能指标。我认为，在实现了以上几种类型的监控之后，应该已经能够满足80%的监控需求了。当然，虽然这一页看起来很简单，但实际上，对于刚接触Zabbix的用户来说，去实践这几类监控可能会花费不少时间。但只要掌握了这些内容，就表明在Zabbix监控配置方面已经没有太多的问题。即使遇到问题，也可以通过官方文档进行查询解决。

从这一页开始，就是我认为的分水岭，也就是说，Zabbix能否更好地发挥作用？能否满足剩余20%的监控需求？这就是我接下来要分享的内容了。

首先，要为客户提供监控解决方案，我认为自己也需要理解监控的本质原理以及数据的含义等。以刚才提到的ICMP监控为例，如果客户问及ping监控的原理，以及Zabbix进行ping监控时默认发送几个包，大家能回答上来吗？如果客户希望通过Zabbix实现每隔10秒进行ping请求，每次请求间隔0.5秒发送包，总共发送10个包的场景，你该如何实现呢？实际上，这些答案都可以在官方文档中找到。如表所示，Zabbix的内置ping监控键值提供了许多参数可以调整，比如包的数量、间隔时间等。通过修改这些参数，可以定制化客户的监控模板。

对于刚才的示例场景中，Zabbix的ping监控默认发送几个包呢？这个问题也可以在官方文档中找到答案。通常情况下，Zabbix是依赖于PING命令来实现监控的，与通常使用的PING命令略有不同。在Zabbix中，默认发送3个包，每隔一秒发送一次。我举这个例子的目的是想告诉大家，学习监控时最好理解其本质。通过Zabbix监控工具实现监控，最好了解监控的原理和机制，这样才能更好地回答客户的监控需求。

提到Agent监控，最常见的监控场景就是针对Linux和Windows服务器的监控。如果大家对运维方面有所了解的话，就会知道很多服务都是运行在服务器上的。比如在自己的电脑上安装微信、浏览器等应用程序，这些应用程序都是依赖操作系统的。因此，对服务器的操作系统（OS）进行监控是非常常见的。最常见的OS监控指标包括CPU、内存和磁盘等。对这些系统指标进行监控，并进行可视化展示是非常重要的。除了在Zabbix的仪表板模块展示数据外，我推荐使用专门的可视化平台，比如Grafana，来与Zabbix对接，实现监控数据的可视化。通过仪表板，可以清晰地看到主机和服务器当前的性能状况。

除了配置监控之外，可视化方面的建议也很重要，因为监控最终呈现给用户的应该是灵活、生动的数据化大屏。不应该只是展示一些数据。接下来，我认为Zabbix用户，特别是那些已经熟悉监控配置的用户，能否进阶，取决于他们是否能独立进行模板开发。

在模板开发方面，我认为最好的学习实践方式就是从Zabbix的默认模板中去借鉴学习。Zabbix自带的监控模板中，我列举了一些值得学习参考的模板，例如Linux和Windows的Agent监控模板，以及思科设备的SNMP模板等等。通过查看和分析这些模板，实际上可以学习到以下内容：命名规范：经常需要自己创建监控项和触发器，因此要学习它们的命名规范，以确保监控项具有易读性和可读性。

其次是监控项类型预处理，以及一些常用的Agent监控和Zabbix监控项。实际上，这涉及到触发器的表达式，也就是告警触发器。如果掌握了这些表达式函数的各种用法，就可以实现复杂的告警逻辑表达式了。此外，底层自动发现也非常重要，它可以自动扫描、发现或删除一批监控项对象。监控项类型方面，Zabbix提供了17种监控项类型，支持非常多的监控方式，除了Agent监控项、Ping监控之外，还有SSH检查、Web监控等等。宏可以实现文本替换的功能。

我想分享一下监控项预处理这方面的功能。我认为在模板开发中，这是比较实用、方便的功能。我列举了一些常见的预处理方法，比如正则表达式，用于从文本中提取数据。除此之外，还有一些简单的数值处理，比如自定义乘数、简单更改、每秒更改等等。我在右边列举了一些常见的适用场景，当然，这些示例也可以从默认模板中找到。我最喜欢的是使用JavaScript进行预处理，因为通过JavaScript可以对数据进行更灵活的处理，这取决于你是否擅长编写脚本，但它的灵活性是非常高的。

接下来是一些使用示例，我觉得可以从一些模板中摘取出来。首先是CPU使用率的计算，在Linux中，CPU使用率实际上是根据每个CPU的空闲时间计算得出的。在只能获取空闲时间的情况下，就需要通过预处理来计算CPU使用率的数值了。在这个例子中，使用了JavaScript进行数值计算。还有一种场景叫做重复值丢弃，比如获取系统名称的监控场景。系统名称肯定是不会改变的，因此不可能每分钟都获取一次，甚至每小时获取一次都可能显得多余，但又想监测这个名称是否发生变化。这时可以使用重复值丢弃这种预处理方式。虽然默认情况下是每小时收集一次，但只要与上一次的值没有变化，就不存入数据库，这样可以节省存储空间。当然，如果一直没有变化，历史数据中就一直没有数据，那我如何得知它是否正常工作呢？这时可以使用“discard change with heartbeat ”这种预处理功能。比如，设置每隔12个小时即使没有变化也要存储一次监控项，这样既能检查其是否正常工作，又能节省存储空间。

还有两个例子，一个是接口速率的计算，比如对网络设备的接口速率进行监控。通常情况下，我们获取到的原始值是接口的总字节数，因此需要进行计算。首先可以使用“每秒变化量”来计算新增的字节数，然后再通过自定义乘数进行单位转换，乘以8就可以将单位转换成比特bps。

接着从主监控项中提取一些数值，比如有些监控项返回的是一串JSON数据，需要从JSON数据中提取某个数值，这时就可以使用JSON Path进行提取。我认为在模板开发中，这四个例子应该是会比较常用的。

接下来是底层自动发现（Low Level Discovery，LLD），LLD的用法是可以自动创建监控项、触发器等。通常情况下，LLD适用于扫描一些被监控主机上的不定数量的实体。比如在Windows服务器中，可能有网络接口、进程、磁盘等，但每台服务器的数量可能都不同。在这种情况下，无法预先手动配置，因此需要通过LLD来解决这个问题，它可以自动扫描这些实例，并自动创建相应的监控项。

接着就是宏，它是预先定义好的一串特殊文本，我更喜欢称其为变量或常量。在Zabbix中，宏有固定的几类格式，分别是内置宏、用户宏和LLD宏，也就是底层自动发现。宏的设计使得Zabbix在做触发器配置、告警配置和监控配置等方面具有了极大的灵活性。

接下来我会举几个宏的使用例子。首先，对于一批要监控的Linux服务器，可能大家都直接套用模板，设置了高CPU使用率的告警。但是根据应用业务的不同，每个服务器的告警阈值可能是不同的，比如有些服务器的告警阈值是90%，而其他的是85%。在监控内容一致的情况下，可以通过宏来实现这样的配置，而不需要修改模板配置。举个例子，可以看到触发器的函数中使用了宏，在模板上定义了默认值为90，如果要将某个主机的告警阈值改成85，只需直接修改该主机上的宏即可，因为宏会从模板上继承下来，这样就实现了监控场景的定制化。

第二个示例是关于告警模板，我认为这也是非常实用的。假设有自定义的告警模板场景，就会了解到宏的便捷性。在告警模板中可以调用内置宏，比如被监控主机的名称、IP，以及告警事件的一些信息等。因为通用的告警模板无法事先知道这些信息，所以肯定是通过宏来调用展示这些信息。

第三个场景是底层自动发现的LLD，也就是刚才介绍过的。底层自动发现意味着要获取的对象的信息都是未知的，因为每台主机扫描出来的对象肯定是不同的，而且经常不知道它们的信息。在这种情况下，可以使用LLD宏来代替对应的信息位置。比如扫描接口时，一开始根本不知道它的接口名称，可以先用LLD宏"interface name"进行代替。通过自动发现监控项获取LLD宏的信息，可以对返回的信息进行相应的创建和填充。

刚才我们介绍了一些关于宏、自动发现等内容的使用方法和示例分享。接下来就是模板开发了。除了这些内容，还有其他一些，比如监控项类型等，大家都可以通过官方文档进行查阅和实践，这样会对自己定制开发监控模板有所帮助。

另外，我认为Zabbix中比较实用的功能之一是多种多样的告警媒介配置和自定义集成。最常见的高级媒介包括邮件、电话、短信等。当然，还可以集成到企业微信或者一些工单平台。Zabbix的告警媒介种类繁多，因此了解不同客户的告警媒介需求是很重要的。此外，Zabbix的告警动作也非常灵活，可以根据工作流程制定不同复杂程度的升级方案。Zabbix的告警升级不仅限于发送通知，还可以执行脚本。例如，如果发现告警两小时后仍未处理，可以执行脚本来解决问题。

另一个我比较推荐的小技巧是关于 Zabbix 中的主机群组。在 Zabbix 中，主机群组是支持嵌套的，你可以使用右斜杠进行嵌套。这在实际的使用场景中也非常常见。比如说，有大量的设备需要监控，这些设备可能分布在全国各地。当然，我们需要对这些设备进行分组和归纳，通常通过主机组进行管理。通过在主机组上添加位置信息，我们可以很方便地对设备进行分类。在 Zabbix 中嵌套主机组，可以通过父群组查找所有子群组的组件，这是非常实用的功能。

另外，我也推荐搭配使用主机树（host tree）。主机树是 Zabbix 的第三方页面模块，可以按主机组的嵌套层级展开主机列表。这样，你就可以一目了然地查看主机的分组情况。

好，讲到这里，我认为对于 Zabbix 用户来说，已经进阶到了各种监控配置，甚至学习模板开发的阶段。因为一旦掌握到了这些技能，就可以应对绝大多数的监控需求了。最后，需要通过一些实践逐渐深入。所以，掌握所有 Zabbix 技能的最佳实践方式之一，就是进行agent自定义监控项的开发。

Zabbix agent除了内置的监控项外，用户还可以自定义参数来实现非原生监控，这样就可以提高监控的灵活性和扩展性。举个例子，比如监控 Linux 服务器的 TCP 端口连接状态。尽管 Zabbix 6.0 以后已经有内置的监控项可以实现这个功能，但以下示例基于 Zabbix 5.0。

首先，可以通过一条命令获取不同状态的连接数量，然后编辑配置文件，利用代理调用该命令，获取这些连接状态的统计信息。接着，可以通过刚才提到的监控项预处理功能，实现对这些监控数据的处理。

通过主监控项获取所有状态的统计数据，然后利用主监控项创建依赖监控项，再通过监控项类型和预处理来提取这些数据实现监控。这个思路是很通用的，可以举一反三，比如监控进程的不同状态和数量。通过代理自定义监控项和预处理等技术，可以轻松实现这类监控需求。

对于 NAS 使用率的监控场景来说，可能需要更复杂的处理，因为可能需要自行开发脚本来获取数据。整个流程可能会更加细致，需要考虑到数据的获取、处理和存储等方面。

这个设计思路很有意义，特别是结合了底层自动发现功能。通过自动发现，可以扫描出需要监控的实例，并返回有关这些实例的信息，如地域、支付信息等。这些信息可以用来生成相应的监控项，实现对云上NAS实例数据的监控。

通过将这些信息写入监控项描述中，可以帮助用户更好地识别实例信息，提高监控的可读性和可管理性。类似地，对于其他需要对接Zabbix、对接外部数据、通过脚本处理的监控场景，都可以采用类似的方式来实现，这种方法非常灵活和通用。

以上是我的分享，欢迎交流。