Zabbix 4.2 发布！支持Prometheus数据收集，可扩展性大大提升
4 月 2 日，Zabbix 正式发布了 Zabbix 4.2 版本。Zabbix 具备现代监控系统所应提供的一切功能，包括数据收集与处理、分布式监控、实时问题与异常检测、警报、升级、乃至可视化等等。
下面是 Zabbix4.2 版本的一些新特性。
除了现有官方工具包与设备之外，Zabbix 4.2 版本还将适用于以下平台：
• 面向 RaspberryPi 的 Zabbix 工具包；
• 面向 SUSE Enterprise Linux Server 的 Zabbix 工具包；
• 面向 Mac OS/X 的 Zabbix 代理；
• 面向 MSI for Windows 的 Zabbix 代理；
• Zabbix Docker 镜像。
感兴趣的朋友可以在 https://www.zabbix.com/download 查看完整的可用平台选项。
Zabbix 能够以多种不同方式（push/pull）从各类数据源收集数据，具体包括 JMX、SNMP、WMI、HTTP/HTTPS、RestAPI、XML Soap、SSH、Telnet、代理、脚本以及其它数据源。现在，Zabbix 开始支持 Prometheus 数据源。
现在，Zabbix 通过对 PromQL 语言原生的支持实现了对导出工具的集成。此外，依赖性指标的引入，使得 Zabbix 能够以高效方式收集大量 Prometheus 指标：我们使用单一 HTTP 调用获取所有数据，而后将其复用为对应的相关指标。
Zabbix 还能够将 Prometheus 数据转换为 JSON 格式，从而直接用于低级别发现（LLD)。
我们都希望能尽快发现问题。但大多数情况下，这意味着我们必须以极为频繁的方式执行检查，最终有可能导致监控系统过载。那么我们该如何避免这种情况？非常简单——对预处理频率进行 throttling，从而帮助我们跳过递归值。
现在，我们能够以高频度方式收集数据，立即发现问题，且无需在 Zabbix 数据库当中保留过多历史数据。而在对 heartbeat 进行 throttling 后，我们可以获取漂亮的 graph。
我们当然不希望收集到错误的数据。利用 Zabbix 4.2，大家可以通过内置的预处理规则解决这个问题。这些规则利用 JSONPath 或者 XMLPath 对正则表达式进行匹配，并根据结果实现数据验证。
现在，用户还能够从收集到的数据当中提取错误消息。对于来自外部 API 的错误而言，这种能力将大大简化操作流程。
在 Zabbix 4.2 当中，可以充分利用以 JavaScript 编写而成的用户自定义脚本来实现多种强大的功能。
对 JavaScript 的支持将大大提升用户的数据预处理自由度。事实上，用户现在可以将全部外的部脚本替换为 JavaScript 形式。
如此一来，用户将能够实现各类数据转换、聚合、筛选、算术以及逻辑运算等。
随着预处理能力的快速演进，用户当然还需要一款能够验证复杂场景的工具。Zabbix 4.2 允许大家直接通过 Web UI 对这些预处理规则进行测试！
在 4.2 版本之前，全部预处理任务都由 Zabbix 服务器单独处理。Zabbix 4.2 的可扩展能力大大提升——一切预处理功能，都可以由代理负责执行。
将基于代理的预处理机制与 throttling 相结合，意味着大家将能够执行高频监控、每秒收集数百万个值，且完全不必担心 Zabbix 服务器发生过载。代理程序会对收集到的数据执行大量预处理操作，而服务器实际只接收其中的一小部分数据。
低级别发现（LLD）是一种非常有效的工具，用于自动发现各类资源（包括文件系统、进程、应用程序以及服务等），并自动创建与之相关的指标、触发器以及 graph。这款工具能够极大地节省用户地时间与精力，仅利用单一模板即可监控具有不同资源的目标设备。
Zabbix 4.2 支持基于任意 JSON 输入的处理方式，这反过来允许直接与外部 API 通信，并利用接收到的数据自动创建主机、指标与触发器。
与 JavaScript 的预处理功能相结合，Zabbix 4.2 现在得以创造出多种多样的模板选项，从而轻松应对云 API、应用程序 API、XML 内数据、JSON 或者其它格式下的外部数据源。
凭借着更高效的算法与面向性能的数据结构设计，TimescaleDB 的性能更加出色。
TimescaleDB 的另一大重要优势在于自动表分区，这将显著提高性能并（与 Zabbix 结合使用）对历史数据进行全自动管理。然而，必须承认的是，Zabbix 团队一直没有对此进行过任何严格的基准测试。此外，在生产环境下运行 TimescaleDB 所带来的具体性能提升，也一直难以量化。
因此就目前来讲，TimescaleDB 仍是一个快速发展且相当年轻的项目，请大家谨慎加以使用。
在 Zabbix 4.2 版本之前，用户只能为各独立 trigger 设置标签。现在，随着对模板及主机标签的支持能力成为现实，Zabbix 的标签管理效率也将得到提升。
所有检测到的问题不仅会从 trigger 当中获取标签信息，同时亦能够从主机与相应的模板内获取标签信息，从而确保判断的正确性。
Zabbix 4.2 自动注册选项使我们能够根据正则表达式过滤主机名称。在需要为各种主机集合创建不同的自动注册场景时，这项功能至关重要。另外，如果大家的设备采用非常复杂的命名约定，则可使用正则表达式进行匹配，从而提升管理效率。
另一项改进与自动发现期间的主机命名有关。Zabbix 4.2 允许用户将接收到的指标数据分配为主机名称与可见名称。
这项功能意义重大，能够帮助大家实现网络发现的高度自动化，且特别适合于使用 Zabbix 或者 SNMP 代理的场景。
Zabbix 4.2 允许大家立足前端发送测试消息或者检查已经选定的警报方法，从而判断其是否能够如预期般正常运作。在对接入外部警报与帮助台系统的集成脚本进行检查时，这项功能可谓意义重大。
Zabbix 4.2 引入了对 Zabbix 服务器与代理的内部性能与可用性指标的远程监控。不仅如此，这项功能还允许用户发现与 Zabbix 相关的问题并在组件过载情况下发布提醒，例如代理中的本地缓冲区内已经存储了大量数据。
Zabbix 4.2 在邮件消息当中支持 HTML 格式。这意味着大家不再局限于纯文本，而可以利用 HTML 及 CSS 的所有功能发布更好、更易于阅读的警报消息。
现在，网络映射支持一组新的宏选项，用于创建指向外部系统的、由用户定义的 URL，允许大家立足服务台或者配置管理系统要开外部提交申报，或者仅使用一到两次鼠标点击即执行任何其它操作。
此项功能允许我们同时利用主指标的接收值作为数据收集与 LLD 规则。如果从 Prometheus 导出工具收集数据，则 Zabbix 将只执行一次 HTTP 查询，而查询结果将立即被用于所有相关指标标准（LLD 规则与指标值）。
Zabbix 4.2 提供 GIF 动图支持功能，从而使映射中的问题更易于发现。
Web 监控使用户能够从 HTTP 标头当中提取数据。
凭借这一功能，我们现在可以利用从过程中某一步骤收取到的身价验证令牌为 Web 监控及外部 API 创建多步骤场景。
Zabbix Sender 现在能够将指标数据发送至全部 IP 地址。这些 IP 地址由 Zabbix Agent 配置文件中的“ServerActive”参数进行定义。
现在，触发器页面配置迎来了一款出色的扩展过滤器，能够根据指定标准快速困难地选择对应的触发器。
这是一项重要性不那么突出，但却效果拔群的改进。Zabbix 将能够在 graph 工具提示中显示时间戳。
• 对仪表板中的小工具进行非破坏性尺寸调整与重新排序。
• item 原型的批量更新。
• DNS 相关检查已支持 IPv6（“net.dns”与“new.dns.record”）。
• 用于 VMware 事件日志检查“vmware.eventlog”的“skip”参数。
• 经过扩展的预处理错误消息，将中间步骤结果纳入其中。
Zabbix 使用手册当中提供一份完整清单，其中列举出扩展信息以及与 Zabbix 4.2 版本相关的开发、改进与最新功能：https://www.zabbix.com/documentation/4.2/manual/introduction/whatsnew420
原文链接：https://www.zabbix.com/whats_new_4_2
活动推荐
年前经历了几场面试，发现对于运维人才的招聘要求也增加了很多。那么如何判断哪些技术技能才是企业重点关注？运维工程师的价值和成长路径是什么？
这里整理了从 Kubernetes 到 Nginx、持续交付到运维体系管理的干货课程，带你解读从运维小工到专家的实战心法，高效解决 80% 的开发难题。（通过极客时间企业账号学习还有更多福利优惠～）
相关内容
微信扫码咨询专知VIP会员