官方博文 | Zabbix模板指南(一)，文末福利让你的知识变现！
Zabbix模板指南
Zabbix4.4版本发布之后，官方同时正式发布了Zabbix模板指南（Templates Guidelines），小秘将通过三篇文章给大家做系统性的盘点，分别是：
一、模板指南概述（Templates Guidelines）
什么是Zabbix监控模板？我们为什么发布模板指南？
二、模板样式指南(Style guide)
三、模板最佳实践(Best practices)
模板指南概述
前言
01
该文档分享的不是每个人都必须遵循的严格规则。而是以文档的形式将我们创始团队的经验更好的传递给大家，告诉大家我们当前的模板构建方法，我们将不断更新该文档中的规则和最佳实践。
02
简介
Zabbix监控之Resource vs service
在我们开始讨论什么是好的模板之前，先来简要地讨论一下监控。监控是一个常见但含糊的术语，没有关于它的真正的RFC定义。有些人说监控是不断在社交网络上寻找有关您公司的信息，而另一些人可能说是收集有关植物土壤营养和水分的传感器读数。虽然Zabbix是一个通用（universal）监控解决方案，我们为任何类型的监控项目提供工具集。但是在本文档中，我们将重点关注对现代IT分布式系统提供的监控。
一切都可以看作是服务（service）或资源（resource）。
服务（service）是您的组织向外界提供的东西。就像在线零售商店或公共电子邮件服务一样。如果客户可以成功的从您的在线商店购买商品，那证明您的服务可用。也许服务是您的部门为公司其他部门提供的服务，比如您按需提供给其他部门的计算资源一样，此类内部服务可能是您公司提供外部服务的基础。如您所见，服务问题显然会影响实际的使用。服务的可用性和性能监控是您从一开始就应该集中关注的。正如Google在SRE书中所建议的那样，应将服务不可用视为紧急情况，并且必须立即直呼通知响应的负责人员（service unavailability should be considered a red-hot situation and the responsible person must be immediately paged）。
资源（resource）是有助于提供服务的组件。它可以是服务器，虚拟机，容器，数据库，中间件app，微服务定制app，某些硬件控制器，网络或其他任何内容。您可以将资源分解为更小的位，例如将服务器拆分为CPU，RAM，IO子系统，现代的分布式系统可能是一组复杂的，具有动态性质的不同资源的组合，其中，根据服务负载按需添加和删除资源，就像在Kubernetes集群或AWS中一样。资源也需要监控，但是有所不同。由于资源不可用并不一定会直接影响实际的使用。因此请尽量减少对资源故障的直呼告警，转而创建工单，在指定的工作时间内解决即可。
服务监控是项目级别的监控-没法做到开箱即可监控，也很难在share.zabbix.com上获得可以直接使用的模板-您需要使用Zabbix功能创建自己的东西。这是因为所有服务都是不同的，具有不同的SLO，具有不同的体系结构等，因此很难为服务监视准备通用的模板蓝图。有以下方法可以借鉴：
1. 尝试综合监控：定期模拟用户（与您的服务交互的人员或其他应用程序）活动：使用黑盒测试检查。
2. 在Zabbix中使用Web监控并模拟常见的用户场景，例如，尝试登录并从商店购买测试项目。
3. 更简单的HTTP检查也可以-只需确保您的网站URL返回HTTP 200 OK
4. 如果您的服务提供了REST API，请编写一个脚本来模拟一些常见的服务活动。
5. 尝试使用真实用户监控法：从日志，网络或数据库中收集和读取有关真实用户的事务。
6. 计算成功/失败请求的比率
7. 收集每秒/每分钟对您的服务的请求速率
8. 计算对服务的最小/最大/平均响应时间或创建直方图。
零率（或率的突然下降），高错误率（处处都是HTTP 500）等可能表明出现了严重的服务问题。
但是，如果设置了服务监控，为什么还要监控资源？有多种原因，但是最重要的原因是：知道服务中断（症状）后，您需要找出问题的根本原因（ root cause）。
资源是许多项目、架构中常见且通用的。这就是模板适用的地方。讲真，您真的需要浪费时间来创建自己的监控解决方案来监控OS Linux？MySQL数据库，思科路由器或Docker主机吗？节省时间，关注服务级别的监控吧！
什么样的监控模板可以称之为好的模板？
让我们尝试列举一个好的模板的属性，在构建模板时我们遵循Zabbix的一些关键原则：
1. 灵活且可重复使用
在Zabbix中，模板可以看作是某些特定监控对象的监视解决方案。是一种容器，可用于在Zabbix服务器实例之间传输配置和监视解决方案。高质量的模板是由某位Zabbix用户创建，满足自己使用的同时分享给社区之后，其他用户可以直接下载使用，并且根据实际case顺利的做更新。所以说模板的灵活和复用性非常重要。如果其他Zabbix用户可以下载并直接使用，而不用做大幅度的修改的话，那证明这个模板确实是不错的。
以下是有关如何实现的一些经验法则：
尽可能使用低级发现（low-level discovery），以避免不受支持的监控项或触发器。如果您有某种metric，这并不意味着它可以在其他情况下使用-可以是不同的硬件，软件版本或配置。
在触发器，监控项中使用用户宏。例如，对Nginx存根状态URL使用{$ NGINX.URL}。或在温度控制触发器中使用{$ TEMP.MAX.CRIT}。这将允许用户配置和微调模板和链接的主机，而不用更改，也不会破坏与将来版本的兼容性。
避免将项目/服务所需的罕见指标/触发器添加到资源模板中。对于您认为非常具体的项目/服务级别指标，只需将其移至另一个模板并将其链接到通用模板即可。
尽可能避免外部依赖。使用内部Zabbix数据收集和处理功能来首先收集数据。使用HTTP代理，强大的预处理步骤，例如Javascript，JSONPath，JMX等。这将确保此类模板易于安装，并且其所有配置和处理都在模板中定义。仅在没有其他替代方法时才诉诸外部脚本。
我们认为，一个好的模板不仅仅是一组metrics（监控项），阈值（触发器）和仪表板的简单堆叠。好的模板最重要的组成部分是其中包含的有关受监控对象的专业知识，这里指的是不仅要知道收集指标的数量，而且要知道哪些指标是有用的、重要的，哪些指标是无用的，或者如何设置阈值做重要问题的通知，避免告警噪音。
虽然极简的模板可能无法提供您所需的所有信息，但是另一方面，过于复杂的模板也很糟糕，因为用户将注意力集中在最重要的指标上，所以：
避免添加太多metrics。把事情简单化。不要尝试进行基准测试，性能分析，收集深入的调试级别（debugging）指标。这会导致不必要的负载。让Zabbix找出问题所在，然后在真正需要深入分析的主机上使用专用工具进行性能分析和调试。
避免使用模板中的触发器产生过多的问题噪音。确保从触发器创建的问题同时有立即（通过电话）或推迟（通过工单）的操作。避免使用“供参考”和“情况看起来很奇怪”这种类型的触发器。
3.模块化和监控范围
最后一件非常重要的事情是模板范围（template scope）。我们已经讨论过服务和资源，因此，通常来说，好的模板是具有单个资源范围的模板：
供应商特定的硬件服务器
温度传感器
操作系统模板，例如Linux OS或Windows OS
Nginx，Apache，Tomcat，RabbitMQ等应用
像MySQL，PostgreSQL，Oracle，DB2，Redis，Mongo等数据库
AWS，Azure或其他云提供商
虚拟化提供程序，例如VMware群集，Hyper-V
容器编排系统，例如Kubernetes
网络设备或网络控制器
一些自定义应用程序
如果将模板监控范围保留在单个资源中，这类模板将更加的易于共享，对于架构中具有相同构建基块的人会很有用。另外，避免合并不同层的资源–不要将Linux OS和PostgreSQL的metrics添加到单个模板中。
但是“内部”metrics范围呢？应该收集哪些metrics类别？当然，您可以出于各种原因进行监控，包括收集业务指标或查找安全漏洞，但是在创建通用资源Zabbix模板时，请尝试采用以下方法：
3.1从故障监控或可用性监视开始。监控人员从监控系统中最想获取的信息应该就是：我的系统是否已启动并正在运行？因此，请尝试首先在模板中解决该问题。
也就是说运行状况健康度检查至关重要，这是您或任何用户想了解的第一件事。在模板中添加相关监控项和触发器确认-您的监控对象是否可访问，是否已启动并正在运行。使用ICMP ping，检查TCP端口是否打开，检查API返回HTTP 200 OK，以此类推。
故障监控解决的第二个问题是即将发生的故障。例如，
硬件过热，即将关闭
您的磁盘空间不足，并且很快，由于没有空间，数据库将拒绝向数据库写入新数据。
添加可以帮助您干预并防止这些后果的监控项和触发器。
另外，如果您的监视对象可以自行检测故障，充分利用这个功能！许多系统可以使用日志或发送SNMP陷阱等直接报告故障。这就是我们之前所说的专业知识，由系统的开发人员，供应商和作者为您提供，没有人比他们更了解这些系统。因此，只需确保您可以在Zabbix模板中重新转换系统本身检测到的故障即可。
3.2一旦模板可以检查系统的运行状况-请继续进行性能监控。这时您需要全部打开box（白箱监控）。有很多不错的方法可以帮助您选择首先收集哪些metrics：USE，来自Google或RED的业务监控4个黄金指标。只要确保您在模板中添加的项和触发器可帮助解决以下场景的问题：
我的系统运行缓慢。在运行但是响应时间很慢，性能下降了。
我们刚刚发生了大故障。我们需要进行调查并进行追溯分析，找出发生了什么事情，以确保不再发生。要进行此类分析，我们需要事先收集有用的指标。
3.3 库存和状态监控
尽管Zabbix不是库存系统，但通过Zabbix仍可以收集有关资源的大量信息，最重要的是，可以检测到更改，例如系统在维护时段之外重新启动，版本已更新或版本已过时等等。
3.4 安全性
什么场景下使用Zabbix检测资源，监控安全性问题：
使用的资源版本受CVE约束，考虑更新
配置错误导致系统在没有适当身份验证的情况下就可以公开使用。
请考虑将此类项目和触发器也添加到模板中。
4. 遵守准则
最后是模板的样式。如何命名您的监控项？模板？触发器？如果我们在创建Zabbix模板时都遵循相同的样式–那么，由谁，您，Zabbix或来自地球另一端的另一个社区成员制作此模板并没有关系，因为模板的内容和布局将非常的标准、可复用。
结论
03
遵循样式准则和模板核心原则意味着我们可以将可以重复使用彼此的模板，社区用户之间互相分享，互相增值，这会节省大量的时间。
到此对Zabbix模板指南的介绍结束了，这是我们在Zabbix中构建模板的规则集合。下期我们将从模板样式规则开始为大家分享细节。
04
您可能感兴趣的链接
Zabbix模板银行已经正式发布，年度订阅服务、知识库也帮助大家在使用Zabbix的过程中快速的获取解决方案、专业建议、技术支持，点击了解详情。
Zabbix模板银行
Zabbix年度订阅服务
Zabbix知识库
社区的意义在于知识共享，知识共享才让知识更有价值，点击查看社区模板。
社区模板分享
模板分享 知识变现
想要分享你的Zabbix模板？请与小Z联系！我们将选择优质模板发布，并为您赠送Zabbix精美礼品。超优质模板还可加入Zabbix模板银行计划，让您的知识变现！
联系我们
电话：17502189550（微信同号）
邮箱：china@zabbix.com
网站：www.zabbix.com/cn www.grandage.cn
一键关注
关注公众号
加入社区群
Zabbix社区，因你而更美好