你不知道的Zabbix 6.0标签功能还能这样用！

问：

您好，我是永兴证券的，我咨询下生产中遇到2个的问题，想听听您的建议。

1.我们目前没有成熟的CMDB，我们正常维护资产信息是通过Excel表单的形式的CMDB，我们对Zabbix的使用覆盖度较高，基本上所有的系统上架的流程中都有监控的添加，添加后也会使用标签区分。在实际的使用过程中，我发现去查关键信息时，把Zabbix信息看成了CMDB的一部分。例如：我需要集很多资产，其中一部分是通过标签加入的，如此Zabbix中的信息就会全面。我想咨询下：把Zabbix当作CMDB来用，比CMDB使用更深入，长期如此会不会出现问题？

答：

您在Zabbix中配置主机的标签，并且深入使用是否会对Zabbix系统有响应的影响。您是根据具体的情况去配置的，使用深入是很好的。能够实现您具体的一些功能，但是您担心可能是后续的维护。当您公司的发展规模越来越大后必定会有相应的分拆（即，最小化的配置&响应工具的拆分）。故此，需要根据您公司的运维规划合理设置。

问：

2.我对一个主机中添加标签，我需要加多少?有无上限?我加多了会不会有问题？例如：我使用信息时通过API去查主机的信息，查取后，我定义的标签过多，是否会对我的主机信息或Zabbix性能有影响？

答：

标签使用多了是否对性能有影响？标签本身就是偏向静态的，其本身是不会对你的性能带来太大的开销，而且，如果您的资产对应的标签能够满足您的要求，您可以去添加，添加得太多反而会影响使用，这个就没有太大的必要了。因为就像数据采集一样，你什么数据都采集，但是你到实际情况时根本不知道要看什么数据，故此，这需要根据实际情况，哪一些是需要的，另外有一些不需要的就完全没有必要添加进去。

问：

何老师您好，我在项目中经常会碰到有些客户会问针对标签方面的问题，目前6.0刚出来，在实施的过程中的权限问题。在Zabbix6.0之前的版本，是通过组的形式来控制权限，我想问用户如何更方便的控制权限，针对于查看触发器、监控项，可以做到这一步嘛？

答：

关于这一块我也咨询过原厂的首席培训师，Zabbix能否做到监控指标维度的权限控制，这一块也常在用户现场被提问。例如：某一块的数据并不是要全部开放，我只想给它开放CPU、内存的一些信息，目前是实现不了的，但是后面也会进一步做到监控指标的权限控制。因为我们把监控指标都添加了标签，标签的使用场景越来越多了，故此，向这一步细化的可能性会很大。

本文整理自上海宏时数据 Zabbix培训师 何星 在2022Zabbix峰会演讲分享。ppt可在公众号后台回复“ppt"。

1、Zabbix标签的介绍

Zabbix标签主要分5类有6个类型，前面几个类型是使用得最多的，后面则为比较新的标签。有我们比较熟悉的，如：模板、主机、监控项和触发器的标签。

标签既然有如此多的维度，那他们之间是否有相应的继承关系呢？确实是有继承关系的！Zabbix的数据流，模板上定义监控项标签，将模板与主机进行关联，开始采集数据并且去评测采集的数据是否满足对应的条件，以上是我培训的时候最常讲的，是最基本的一个数据流。

当模板与主机进行关联之后，对应的监控项和触发器会继承到对应的标签，最后在事件当中反映出来。

以下介绍Zabbix具体的使用场景。对应的事件、主机、监控项的过滤、对应的信息查询以上是最常用的。除了查询之外，我们还可以做一些稍微高级的配置，如：我们根据用户群组做对应的事件权限的控制，以及在触发剂动作条件中去配置标签作为条件。

配置维护期时，也可以根据标签来作为他的条件。此外的使用场景：触发器对应恢复。前面我的同事王军讲SNMP Trap的对应恢复时提到SNMP Trap会有较多的事件，一个事件恢复之后才会产生新的事件,这是不合理的。有可能一次性出现很多事件，可以通过标签做到对应的事件恢复。

事件压制和全局事件的关联，Zabbix是内置有事件压制的功能，当然得根据你的实际情况去使用。可计算的监控项，也可以根据标签做对应的一个过滤。

2、资产自动维护场景

将标签应用到实际运维场景中。大家可能会好奇，资产自动维护是怎样自动维护的呢？资产是否与CMDB有关系呢？

将资产分为几类，如：常用的操作、系统、数据库、中间键、虚拟化、存储、硬件设备。可能您的公司较大，建设有一套完整的CMDB系统；可能您的公司较小，大家需要用表格维护，都没有问题。以上都是资产，都是对公司有用的信息。当然一般都建议使用CMDB，需要有一定的成熟度，它的数据相对而言较可靠，当然并不要求完全可靠。

Zabbix和CMDB联动较重要的功能是：Zabbix能推动CMDB的建设。

讲一个最基本的、也是客户提出来的需求：我有很多Zabbix监控的主机和资产，我想知道产生事件的时候我要去联系谁？

例如：当该事件出来后，他的第一联系人是谁呢？从事这个工作的人员，当有事件出来，“叮”有个声音告警，需要打电话，突然出现一个没有联系的，那打给谁呢？打给值班的。目前是通过第三方平台去实现的，如：事件平台、告警平台。

为避免部署多套系统，在Zabbix中怎样去实现呢？

上图中有用户、触发器、标签。前面讲到了最基本的需求——我该联系谁？

肯定得有用户，用户从哪里去拿？1.你的CMDB当中或者说HR管理系统中去获取联系人信息，添加到Zabbix用户当中。Zabbix用户就是一些普普通通的用户，你可以去设置登录。其他的统一告警管理平台，就是张表。你需要做到对应的一些增删改。

比如：新员工入职了，要让他管一些系统；老员工离职了，要把他踢出去。不至于他人离职了还给他发短信、邮件，这又不归他管。此外有可能在职员工的手机号码变更了，肯定需要进行更新维护。

更新维护怎样与事件关联呢?需要通过触发器的标签，为什么此处要选择标签而不选择资产呢?

CMDB就是资产，Zabbix里面有主机的资产，但是Zabbix里面的资产字段是固定的，不能做修改的。很多时候一台主机上既监控操作系统数据库或者中间键。当在主机层面直接去配置资产时，根本做不到对应的类型显示对应的资产。

所以我们最终选择在标签层面、触发器层面，进行标签的配置。最终显示的模板上的标签

或者触发器监控项的标签，最终都会汇总到事件中,可以在事件中查看对应的标签信息。

一台主机上有操作系统、数据库、中间键，肯定是改对应的资产类型，改操作需要进行过滤，一台主机上所有的触发器修改了，它的标签也随着修改了，这肯定是不合理的。

前面有演讲嘉宾讲到，对应的CMDB需要有一个唯一的字段，否则无法进行关联。无法进行对应的数据治理，CMDB与Zabbix对接也是一样的。必须要有一个唯一的字段才能够建立相应的关联关系。通过这个字段可以知道它是增加、删除或是修改的。

普通的触发器在主机层面是可以直接修改标签的，但是，如果是触发器原型生成的触发器是没法直接进行修改的。所以需要直接在触发器原型中进行配置。

举例一个场景，如：监控多实例的对象，多实例的对象可能联系人都不同。

这个时候有人可能说做不到这个层面，对应的一个IP的数据库，即使多实例也发给相同的管理人员，可能有一些人不纠结，有一些人比较纠结，可能说这个并不是我管的CMDB里面有对应的数据你发给我干嘛？那这个时候怎么做呢？

通过Zabbix的触发器原型就可以实现，以上看起来会有点复杂，要实现功能比较强大。因为它的标签名称和标签值中都可以使用LLD宏和用户宏，前面讲了这么多理论，要实现相应的功能，具体怎样实现呢？我们需要去调Zabbix API。

那常用的一些功能，我们可以写成一个方法去统一调用。做成共用 的方法可以避免以下2个问题1.具体要怎么去配置？2.其他人共同参与应该怎样？

获取也是一样的，修改之后需要做比对。修改的是否正确，后面实现相应的纳管率的显示。具体是怎样的效果呢？

例如此处为相同IP上挂了操作系统数据库，数据库为多实例的，需要显示不同的资产信息，在标签中可以进行查看，如：操作系统的对应的资产信息、主题名称、主题管理员中有相应的名称、电话号码、邮箱信息，此外它的应用类型、所属的部门 、业务系统，这些信息都可以拿到。

此外在同一台主机上的数据库也一样可以获取到对应数据库管理员的信息，以及数据库的字段。另外实例也是同样的，可以显示不同的数据库管理员的信息以做到精准匹配。

前面讲到了对应的修改，建设历程是相较麻烦的，对应的需要去了解它的准确率以及纳管率。

纳管率，之前的演讲嘉宾讲到了，拉出来CMDB资产后，是否完全纳管？有哪些没有纳管呢？我该怎样去做？领导说：“纳管率需要达到多少。有没有数据？”以上都能给到一个直观的印象。可以通过触发器标签实现以上应用场景，建设不可能是一蹴而就的，需要分批跑，可以先选择一种类型。这也不影响CMDB，即使它的数据不完全准确，但是通过edx的联动后，告警发出去，相应岗位的同事肯定会有反馈的，从而促使CMDB的进一步完善。