基础篇

第1章 Zabbix监控系统简介

1.1 Zabbix是什么

Zabbix是什么？可以用最简短的一句话概括——Zabbix是一种企业级的分布式开源监控解决方案。

我想这句话对于熟悉Zabbix的人来说应该不会陌生，可能我们都知道分布式、开源、监控解决方案，那么这里的企业级又具体代表什么含义呢？对于一套成熟的企业级的监控解决方案，需要面对几个问题，如监控接入的设备越来越多，需要分布式监控、多分支监控及防火墙后端的监控，需要支持高可用、多主机、无单点故障，安全加固，端对端加密，专业认证等。

很荣幸，在2020年，Zabbix获评Gartner ITIM基础架构监控工具第一名，并且在2021年上半年，在IT Central Station的IT基础监控（IT Infrastructure Monitoring）、网络监控（Network Monitoring）、服务器监控（Server Monitoring）、云监控（Cloud Monitoring）软件榜单中，Zabbix均排名第一。

开发Zabbix的初衷是开发一款卓越的监控解决方案，并提供及时的响应和可靠的支持，以解决任何有关其安装、操作和使用的问题。

1.2 Zabbix的诞生

Zabbix是由Alexei Vladishev创建的，根据Alexei先生在被采访时的描述，那时他只是一名负责AIX和HP-UX的系统管理员，本想着如何通过自动化来简化自己的日常工作，开始编写各种工具。最初Zabbix只是一堆使用crontab运行的Perl脚本，后来他决定使用新的架构和技术来重写，这也变成了他的业余爱好项目，他本人对编程非常感兴趣，历经4年的开发，他把这款软件命名为Zabbix，并以开源软件的形式发布。因此，Zabbix的第一个版本于2001年发布。

Zabbix由Zabbix SIA公司持续进行开发、更新与维护，同时为用户提供Zabbix培训、Zabbix认证及技术支持服务。

Zabbix遵循了GNU GPL（GNU General Public License，GNU通用公共许可证）V2协议设计和编码，这就意味着Zabbix的源代码是免费且完全公开的，可以供任何用户下载使用。

Zabbix采用All in One的监控解决方案，并且Zabbix并不是为特定行业、特定客户创建的一款产品，而是将Zabbix的可用范围持续不断扩大。从最初的传统IT基础监控到物联网设备监控，从数据采集到屏幕数据可视化，从事件告警到趋势预测等，Zabbix自始至终都在听取用户的反馈，并不断努力推进Zabbix的多样性。由于Zabbix的灵活性和极强的可扩展性，以及极低的维护成本，Zabbix常常成为大型企业首选的监控解决方案。

1.3 Zabbix的功能

在谈论Zabbix的功能之前，我想请教读者几个问题：您之前是否使用过其他监控软件？是什么促使您愿意选择学习Zabbix的呢？Zabbix与市面上流行的监控软件之间有哪些区别？我希望您能够了解的是，Zabbix不仅是一款监控软件，还是一套完善的、开箱即用的监控解决方案，我认为它的使用方式和监控理念对IT监控进行了一次系统的梳理和革新。

因为我个人之前也经历过从自己写各种监控脚本到使用各种监控软件的过程。当我第一次使用Zabbix时，就被它的功能和处理逻辑吸引了，如自动生成监控项、模板的概念、基于界面的人性化操作，鼠标操作就可以完成配置、对外提供完善的API、各种开箱即用的功能等。

我再也不需要为维护某监控软件的几千行的配置文件而发愁，Zabbix的各种触发器函数可以让我更精准地判断系统故障，避免“狼来了”的效应。

接下来，我将简单、快速地介绍一下Zabbix具体有哪些功能。

1.3.1 数据采集

既然是讲监控，不得不说的Zabbix的第一个点就是数据采集，那么Zabbix的数据采集都涵盖了哪些呢？

这里先简单地展示一台服务器的Zabbix agent可用性状态（见图1-1）及CPU性能监控数据（见图1-2）。以Zabbix agent存活状态为依据判断服务器是否在线、是否可用。可能会有人说：“Zabbix agent是否存活不能作为服务器是否存活的标准。例如，Zabbix agent停掉了，但并不代表服务器出现故障。”这就要看每个人的评判标准了，可以基于服务器是否能ping通，或者服务器某个端口是否存活为条件进行判断。但是我认为的标准就是我的服务器Zabbix agent必须在线，服务器既然存活，就必须要纳管到监控平台，这就是一条规范或标准。

通过图1-1和图1-2可以看到，通过Zabbix，可以全方位地掌握自己的服务器的各项监控指标及状态。

对于以上的监控数据，可以通过在操作系统上部署Zabbix agent来获取，那如果监控对象是一台交换机，或者是一台路由器，又或者是一台UPS，该怎么办呢？Zabbix除了提供在操作系统上部署的采集客户端Zabbix agent，还支持其他的采集方式，如SNMP（包括主动轮询和被动捕获）数据采集，只要为设备配置好SNMP功能，就可以采集基于SNMP的监控数据，不仅如此，Zabbix还提供了更多的数据采集方式，如IPMI、JMX、VMware等。

如果这些都不是我们想要的采集方式，那么Zabbix还可以自定义数据采集方式，我们可以通过自己擅长的编程语言，如Bash Shell、Python、Perl等来编写数据采集的脚本，或者通过模块进行监控数据的采集。

对于监控项的配置，我们可以灵活地定义数据采集间隔，可以设置1秒钟1次，或者1小时1次。对于一些核心、重要的监控数据，可以采用秒级监控；对于一些非核心监控数据，就可以稍微延长采集间隔。后面会对Zabbix内置的每种监控类型做更详细的描述。

1.3.2 灵活的阈值定义

现在我们已经采集到了监控数据，那可以用这些监控数据做什么呢？通过监控数据配置告警是运维工作必不可少的一项需求，Zabbix可以通过触发器对采集值与参考值进行判断，从而实现告警。例如，CPU负载大于90%就告警，这是一个非常简单的故障场景（大于90%就告警，小于90%就恢复），这样就会出现一个问题，即如果CPU负载一直在90%左右浮动，就会出现反复告警的情况，这种场景放在以前就会产生很多通知，因此，Zabbix提供了一种更为聪明的判断方法。例如，告警条件为大于90%，但是Zabbix可以设置恢复条件为小于30%，这样就避免了反复告警的情况。另外，我们还可以设置凌晨1点到早上7点不告警。了解触发器的各种函数的功能，可以组合出更符合自己需求的表达式。

1.3.3 高度可配置化的告警

接下来，我们通过Zabbix提供的触发器判断是否发生了故障，如果发生故障，就对这个故障进行一系列的操作。例如，指定递增计划告警，在告警不同阶段通知不同的接收者，通过媒介配置自定义发送告警内容通知（如常用的邮件、短信、微信、钉钉甚至电话通知等）。

1.3.4 实时图形

对于监控数据的展示，Zabbix通过使用内置的图形功能，可以将监控数据绘制成图形，如图1-3所示，任意展示不同时间区间内的数据趋势，如5分钟、15分钟、30分钟、1小时甚至几天或几个月的数据。

1.3.5 Web监控功能

Zabbix的Web监控功能不仅可以检测HTTP请求的响应代码及过滤页面上的某些特殊的关键字符串，还可以追踪模拟鼠标在Web网站上的点击操作，以检查Web网站的功能。

1.3.6 丰富的可视化

前面提到的实时图形展示只是针对单个监控指标的图形生成的，在Zabbix中，也可以创建将多个监控值组合到单个视图中的自定义图形（见图1-4），还包括网络的拓扑图、自定义数据聚合图、幻灯片演示图、报表视图、业务视图、可钻取视图。

1.3.7 历史数据存储

Zabbix的监控数据保存在数据库当中，这样我们就可以随时抽取历史数据，而且Zabbix内置了数据管理机制，我们可以随意自定义各种历史数据的保存时间，Zabbix将依据配置的保存时间清理旧数据。

1.3.8 配置简单

Zabbix监控项以模板为集合，模板采用模块化的方式管理，如模板可以分为Cpu、Mem、Disk，如果只想监控CPU，那么只需插入Cpu模板即可，在Web界面添加监控设备为主机并将主机添加到数据库中后，Zabbix agent就会采集主机数据用于监控，并且监控模板可以随意插拔，这一切只需用鼠标操作即可。

1.3.9 模板套用

刚才讲到了模板，模板之间也可以互相关联。例如，现在有一个OS模板，接下来在OS模板当中关联了Cpu、Mem、Disk 3种模板，关联后，OS模板就继承了上述3种模板的监控项目，当将OS模板插入监控主机后，主机就会自动继承Cpu、Mem、Disk 3种模板的监控项目。

1.3.10 自动发现

我们在使用监控软件时，最头疼的莫过于添加监控设备，面对数量日趋庞大的服务器、网络设备，作为管理员，不可能一台一台地手动把它们添加至监控平台，而且人工操作会出现错监、漏监等情况。Zabbix的Zabbix agent可以在部署完成并启动后，根据配置自动注册至监控平台，还可以根据配置标识自动划分至对应的业务组中，并自动添加所对应的监控模板；至于其他设备，也可以基于其他判断条件，如通过SNMP，或者通过网络扫描获取设备的特定描述信息及标识，自动添加至Zabbix监控平台。

对于单台设备的监控项的生成，也可以采用自动的方式。例如，每台服务器的磁盘分区可能不尽相同，那么通过低级发现功能，可以基于自身的磁盘分区生成对应的监控项目，如图1-5所示；或者交换机有不同个数的网络接口，通过低级发现功能，也可以生成不同端口的监控。这样就省去了大量人工操作，做到了真正的自动化。

1.3.11 统一Web管理界面

Zabbix基础PHP提供了一套Web前端管理界面，这样我们就可以从任意地方访问监控平台，并且管理界面可以随个人喜好进行定制。另外，对于前端所有的操作，都会有审计日志进行记录，确保操作可追溯。

1.3.12 Zabbix API

Zabbix本身提供了完备的API，可用于批量操作、第三方软件集成和其他用途等。尤其重要的是，Zabbix提供了详细的API调用文档，方便开发者查询。

1.3.13 权限管理系统

对于一个完善的监控平台，用户权限划分尤为重要，Zabbix提供了颗粒化的权限分配，可以为不同用户分配不同监控视图的访问权限。

1.3.14 Zabbix agent

Zabbix agent主要部署于被监控对象上，几乎可以部署在任何操作系统上，包括Linux、Windows、UNIX等。

1.3.15 二进制的程序

为了更好地提高性能，更少地占用资源，Zabbix采用C语言编写，方便移植。

1.3.16 适应更复杂的环境

当监控网络跨防火墙、跨数据中心的时候，通过Zabbix proxy进行数据采集，可以轻松实现分布式远程监控。

1.4 Zabbix组件介绍

Zabbix中包含很多组件，本节将全面解释Zabbix中各组件的功能。通过这些组件，可以了解Zabbix的监控思想，特别是Zabbix中的重要理念。

对Zabbix组件有基本的了解，将会了解本书中的其他内容的背景，对将来深入学习其技术细节会有很大的帮助。

1.Zabbix server

Zabbix server是Zabbix的核心处理程序，主要负责数据的主动轮询与被动接收、触发器的条件判断、用户通知等。它是Zabbix agent和Zabbix proxy报告系统可用性与完整性数据的核心组件。另外，还可以通过Zabbix server使用简单的服务检查来远程检查网络服务（如Web服务器或邮件服务器）。

Zabbix server是所有配置、数据统计和数据操作的核心处理程序，也是Zabbix监控系统的告警中心。当监控系统出现任何异常时，Zabbix server都将发送警报通知给相应的管理员。

Zabbix server的基本功能分为3个不同的组件：Zabbix server、Web frontend（PHP前端）和数据库（MySQL、PostgreSQL等）。

Zabbix的所有配置信息都存储在数据库中。例如，当在Web前端（或API）新增一个监控项时，此监控项会被添加到数据库的监控项表item里，然后Zabbix server以每分钟一次的频率查询监控项表中的有效监控项，并将查询结果存储到Zabbix server缓存中，这就是为什么Zabbix前端所做的任何更改都需要两分钟左右才能在最新数据中显示的原因。

2.Zabbix agent

Zabbix agent部署在被监控的设备上，主动监控本地资源和应用程序（硬盘、内存、处理器统计信息等）。

Zabbix agent收集本地的性能数据并将数据报告给Zabbix server或Zabbix proxy，用于进一步处理。一旦出现异常（如硬盘空间已满或有崩溃的服务进程），Zabbix server就会主动通知管理员指定机器上的异常。Zabbix agent的极高效率源于它可以利用本地系统调用来完成统计数据的采集。

3.Zabbix agent 2

Zabbix agent 2为新一代的Zabbix agent，未来可能会替代原Zabbix agent。Zabbix agent 2有以下优势。

（1）减少TCP连接数。

（2）具有更好的检查并发性。

（3）易于通过插件进行扩展。

Zabbix agent 2是用Go语言开发的（复用了原Zabbix agent的部分C代码）。Zabbix agent 2需要在1.13+版本的Go环境中编译。

Zabbix agent 2不支持Linux上的守护进程，而且从Zabbix 5.0.4开始，它可以作为Windows Service运行。

它的被动检查的工作原理与Zabbix agent类似，其主动检查支持scheduled/flexible间隔和并行检查。

4.Zabbix proxy

Zabbix proxy可以从一个或多个受监控设备中采集监控数据并将数据发送给Zabbix server，主要功能是代理Zabbix server工作。所有收集的数据都在本地缓存，然后传输到Zabbix proxy所属的Zabbix server上。

部署Zabbix proxy是可选的，它有利于分担Zabbix server的负载。如果通过Zabbix proxy采集数据，则Zabbix server上会减少CPU和磁盘I/O的资源消耗。

Zabbix proxy是无须本地管理员即可集中监控远程位置、分支机构和网络的解决方案，同时，Zabbix proxy需要使用独立的数据库。

5.Zabbix Java Gateway

从Zabbix 2.0开始，Zabbix开始支持监控JMX应用程序，对应的组件为Zabbix Java Gateway。Zabbix Java Gateway的守护进程是用Java编写的。为了在特定主机上找到JMX计数器的值，Zabbix server向Zabbix Java Gateway发送请求，Zabbix Java Gateway使用JMX管理API来远程查询相关的应用。被监控应用不需要安装额外的软件，只需在启动时向命令行添加-Dcom.sun.management.jmxremote选项即可。

Zabbix Java Gateway接受来自Zabbix server或Zabbix proxy的请求，并且只能用作“被动Proxy”。在Zabbix server或Zabbix proxy配置文件中，可配置唯一的Zabbix Java Gateway。如果主机有Zabbix JMX agent或其他类型的监控项，则只将Zabbix JMX agent监控项传递给Zabbix Java Gateway进行检索。

当必须通过Zabbix Java Gateway更新监控项时，Zabbix server或Zabbix proxy将连接Zabbix Java Gateway并请求该值，Zabbix Java Gateway将检索该值并将其传回Zabbix server或Zabbix proxy。因此，Zabbix Java Gateway不会缓存任何值。

Zabbix server或Zabbix proxy具有连接Zabbix Java Gateway的特定类型的进程，由StartJavaPollers选项控制。在内部，Zabbix Java Gateway启动多个线程，由StartPollers选项控制。在服务器端，如果连接超过Timeout选项配置的秒数，则连接将被终止，但Zabbix Java Gateway可能仍在忙于从JMX计数器检索值。为了解决这个问题，从Zabbix 2.0.15、Zabbix 2.2.10和Zabbix 2.4.5开始，Zabbix Java Gateway中增加Timeout选项，允许为JMX网络操作设置超时。

Zabbix server或Zabbix proxy尝试尽可能地将请求汇集到单个JMX目标中（受监控项取值间隔影响），并在单个连接中将它们发送给Zabbix Java Gateway以获得更好的性能。

此外，建议StartJavaPollers选项的值小于或等于StartPollers选项的值，否则可能会出现Zabbix Java Gateway中无可用线程来为传入请求提供服务的情况。

6.Web管理界面

为了从任何地方都可以轻松访问Zabbix，Zabbix基于PHP编写并提供了一套Web管理界面，可以使用市面上流行的Web服务中间件Aapche、Nginx等进行部署。该界面是Zabbix server的重要组成部分之一，通常（但不一定）和Zabbix server运行在同一台服务器上，Zabbix的Web管理界面也是Zabbix API调用的入口。

7.Zabbix Sender

Zabbix Sender是一个命令行应用程序，可用于将性能数据发送到Zabbix server中进行处理。该实用程序通常用于长时间运行的用户脚本，用于定期发送可用性和性能数据。如果需要将结果直接发送到Zabbix server或Zabbix proxy中，则必须配置监控项为trapper类型。

8.Zabbix Get

Zabbix Get是一个命令行应用，可以用于与Zabbix agent进行通信，并从Zabbix agent那里获取所需的信息。该应用常用于Zabbix agent故障排错，这里需要注意的是，此命令只能用于被动模式检测。

1.5 Zabbix专业术语

在开始学习Zabbix之前，我希望大家能花点时间看一下Zabbix术语，因为这些术语也是Zabbix重要的概念组成部分。

1.主机（host）

主机是指需要监视的服务器或网络设备等类型对象，在Zabbix的概念当中，一切监控设备都通过主机来实现，需要具有IP或DNS。

2.主机组（host group）

主机组是主机的逻辑分组，可以包含主机和模板。主机组中的主机和模板不会以任何方式相互链接。通过主机组可以为不同的用户组分配主机的访问权限。

3.监控项（item）

监控项用来从主机上接收特定的指标数据，数据分为5种类型：数字（无正负）、数字（浮点数）、字符、日志、文本。

注意：如果所需的数字有可能是负数的话，则要选择数字（浮点数）。

4.值预处理（value preprocessing）

在数据被保存到数据库之前，要对接收的指标数据进行转换，这就是值预处理。目前，值预处理可以直接在Zabbix proxy上进行。详细用法会在后续章节讲解。

5.触发器（trigger）

监控项只收集数据，为了自动判断传入的数据，需要定义触发器。

触发器包含一个表达式，通过表达式定义触发问题的阈值。当接收的数据超过阈值时，触发器从“OK”状态进入“Problem”状态；当接收的数据低于阈值时，触发器保持或返回“OK”状态。

6.事件（event）

事件是指发生的需要关注的事件，如触发器状态改变、自动发现/监控代理自动注册。

7.事件标签（event tag）

事件标签是提前设置的事件标记，可以用于事件关联、权限细化设置等。

8.事件关联（event correlation）

事件关联是一种灵活的、准确的解决问题的方法。

例如，自定义一个触发器A报告的问题可以由另一个触发器B解决，触发器B甚至可以使用不同的数据收集方法。

9.异常（problem）

异常是指监控项处于“异常”状态的触发器。

10.异常更新（problem update）

异常更新是Zabbix提供的异常管理选项，如添加评论、确认异常、改变严重级别或手动关闭等。

11.动作（action）

动作是指预先定义的应对事件的动作。一个动作由操作（如发出通知）和条件（何时进行操作）组成。

12.动作升级（escalation）

动作升级是指用户自定义的一个在动作（action）内执行操作的场景，是发送通知/执行远程命令的序列。

13.媒介（media）

媒介是指Zabbix发送告警通知的方式、途径。

14.通知（notification）

通知的作用是通过预先设定好的媒介途径发送事件信息给用户。

15.远程命令（remote command）

远程命令是预定义好的，在满足特定条件的情况下，可以在被监控主机上自动执行。

16.监控模板（template）

监控模板是应用于一台或多台主机上的一套实体组合（如监控项、触发器、图形、聚合图形、应用、LLD、Web场景等）。

监控模板的应用使得主机上的监控任务部署快捷方便，也使得监控任务进行批量修改更加简单。监控模板直接关联到每台单独的主机上。

17.应用（application）

应用是监控项的逻辑分组。

18.Web场景（web scenario）

Web场景是用来检查B/S架构Web应用的可用性的一个或多个HTTP请求。

19.前端（frontend）

前端是指Zabbix提供的Web前端应用。

20.仪表盘（dashboard）

在自定义的Web前端模块仪表盘中，用于重要的概要和可视化信息展示的单元称为组件（widget）。

21.仪表盘组件（widget）

仪表盘组件是仪表盘中用来展示某种信息和数据的可视化组件（如概览、map、图表、时钟等）。

22.Zabbix API

Zabbix API允许用户使用JSON RPC协议创建、更新和获取Zabbix对象（如主机、监控项、图表等）信息或执行任何其他自定义的任务。

23.Zabbix server

Zabbix server是Zabbix软件的核心进程，用来执行监控操作，与Zabbix proxy和Zabbix agent进行交互、触发器计算、发送告警通知。

24.Zabbix agent

Zabbix agent是部署在监控对象上的进程，能够主动监控本地资源和应用。

25.Zabbix proxy

Zabbix proxy是指代替Zabbix server采集数据，从而分担Zabbix server负载的进程。

26.加密（encryption）

Zabbix组件之间的加密通信（Server、Proxy、Agent、zabbix_sender和zabbix_get工具）支持使用安全网络传输协议（Transport Layer Security，TLS）。

27.网络自动发现（network discovery）

网络自动发现是指网络设备的自动发现。

28.低级发现（low-level discovery）

低级发现是指特定设备上低级别实体的自动发现，可以发现必要的实体（如文件系统、网络接口等）。

29.低级发现规则（low level discovery rule）

为自动发现设备中低级别实体设定的一系列规则称为低级发现规则。

30.项目原型（item prototype）

项目原型是指有特定变量的指标，用于自动发现。低级别自动发现执行后，该变量将被实际自动发现的参数替换，该指标也自动开始采集数据。

31.触发器原型（trigger prototype）

触发器原型是有特定参数作为变量的触发器，用于自动发现。在自动发现执行后，该变量将被实际自动发现的参数替换，该触发器自动开始计算数据。

还有一些其他的Zabbix实体原型也被用于自动发现中，如图表原型、主机原型、主机组原型、应用原型。

32.自动注册（agent auto-registration）

自动注册是指Zabbix agent自动注册为一台主机且开始监控的自动执行进程。

1.6 Zabbix版本及发布周期

前面已经大概解释过Zabbix的各种专业术语，接下来解释一下Zabbix SIA公司关于Zabbix软件新版本发布的政策，并概述Zabbix早期版本的支持服务的时限。因为很多Zabbix初学者刚开始问的最多的一个问题就是“我应该选择哪个Zabbix版本进行安装呢？”

多年来，为了确保Zabbix为其用户和客户提供质量符合预期的产品与计划性的支持，每个新的Zabbix软件版本发布都遵循产品周期和到期时间的标准。对Zabbix终端用户来说，Zabbix的产品周期使新版本的内容更具可预测性和可管理性。

自2001年Zabbix软件首次发布开始，新的稳定版本每一年半发布一次，对于所有标准版本，Zabbix客户都将获得为期5年的服务与支持，可以根据表1-1查看当前Zabbix版本的支持服务及期限。

1.6.1 Zabbix发布计划

自从第一个稳定版本1.0发布以来，Zabbix版本控制使用小版本号来表示主要版本。每个小版本实际上实现了许多新特性，而变更级别的版本主要引入了错误修复。

Zabbix版本编号方案随着时间的推移而改变。虽然最初的两个稳定分支是1.0和1.1，但是在1.1版本之后，决定在开发版本中使用奇数，在标准版本中使用偶数。因此，1.3在1.1之后作为开发更新版本发布，标准版本为1.4。

目前，Zabbix的产品发布计划周期为6个月，每6个月将有一个新的Zabbix标准版本发布。从发布计划（见图1-6）中可以看到，LTS release X就相当于5.0版本，每1年X加1，即下一个LTS版本为6.0版本。1年当中，每间隔6个月发布一个当前版本的X.2标准版本，即1年会发布两个标准版本，如5.2、5.4。每个标准版本的支持期限为6个月。

总结一下：每一年半Zabbix将会发布的版本。

（1）Zabbix标准版本发布。Zabbix标准版本将在全面支持（基础的、紧急的及安全性上的问题）的6个月内为Zabbix用户提供支持服务，如图1-7所示，直到下一个Zabbix稳定版本发布，再加一个月的最低限度支持（仅限紧急的和安全性上的问题）。Zabbix标准版本将会导致第二个版本号的变动。

（2）Zabbix LTS（长期支持版本）发布。Zabbix LTS在5年内为Zabbix用户提供支持服务，如图1-8所示，包括3年的全面支持（基础的、紧急的及安全性上的问题）和2年的最低限度支持（仅限紧急的和安全性上的问题）。Zabbix LTS的发布将体现在版本号第一位数字的变动上。

注意：当任何Zabbix版本的生命周期到期后，Zabbix都将会停止对该版本进行进一步的维护更新，包括Blocker级和Cribical级的漏洞修复。因此，我们强烈建议用户将Zabbix监控解决方案升级到最新版本。

1.6.2 关于Zabbix LTS

LTS代表长期支持版本。Zabbix LTS每一年半发布一次，且为Zabbix客户提供5年的支持服务。

（1）3年全面支持：支持修复基础的、紧急的及安全性上的问题。

（2）2年最低限度支持：仅限支持修复紧急的和安全性上的问题。

Zabbix LTS没有任何额外的或隐藏的消费成本。Zabbix是一个100%的开源软件，每个人都可以下载使用。

Zabbix LTS的特点如下。

（1）支持期限更长，如为潜在的安全问题及漏洞进行迭代更新。

（2）令人期待的高质量更新及全新的功能点。

（3）快速更新，可适用于多变的复杂环境。

（4）在版本升级方面，更容易规划管理。

Zabbix LTS相较于标准版本的优势如下。

（1）更适合大型企业环境。

LTS：新的Zabbix LTS每一年半发布一次。

标准版本：新的标准版本每6个月发布一次，意味着企业需要每半年进行一次升级，这对大型商业IT基础设施来说会产生一些不可预计的问题。

（2）官方支持。

LTS：总计支持5年，包括3年基础的、紧急的和安全性上的问题修复（全面支持），以及2年仅紧急的和安全性上的问题修复（最低限度支持）。

标准版本：新的标准版本每6个月发布一次，意味着企业需要每半年进行一次升级。

（3）更多测试验证。

LTS：由于对紧急的和安全性上的问题的长期支持，Zabbix LTS更加稳定且可靠。

标准版本：Zabbix标准版本在完全稳定且安全之前不会停止测试，但由于其更频繁的发布频率和更短的支持时间，Zabbix标准版本用于问题修复的时间更短。

Zabbix LTS相较于标准版本的劣势为无法更早体验新功能。

LTS：Zabbix LTS每一年半发布一次，因此，如果客户正在监控大型企业环境，那么仅升级到Zabbix LTS是最适合的方式，但是此时需要等待一年半的时间才能访问使用此期间开发的功能。

标准版本：由于Zabbix标准版本的发布周期为6个月，所以客户可以每6个月就体验到最开发的新功能。

1.7 Zabbix版本兼容性

1.7.1 支持的Zabbix agent

从1.4版本开始，Zabbix agent与Zabbix 5.0兼容。但是，用户可能需要检查旧Zabbix agent的配置文件，因为可能会有一些参数的变动，如3.0以前版本的日志相关的参数与之前的不同。

想尝试新的功能和改进的监控项、性能，以及更小的内存使用，请使用最新的Zabbix 5.0 agent。

注意：更新于5.0的Zabbix agent不能与Zabbix server 5.0一起使用。

1.7.2 支持的Zabbix proxies

Zabbix 5.0 proxies只支持与Zabbix 5.0 server一起工作。

这里值得注意一下，当升级完Zabbix server后，尚未升级的Zabbix proxies无法向Zabbix server发送监控数据（Zabbix proxy无法刷新其配置）。Zabbix官方之前不推荐使用低版本Zabbix proxy向高版本Zabbix server发送监控数据，现在官方正式禁用低版本Zabbix proxy向高版本Zabbix server发送监控数据，Zabbix server将忽略未升级的Zabbix proxy。

1.7.3 支持的XML文件

Zabbix 5.0支持使用版本号为1.8、2.0、2.2、2.4、3.0、3.2、3.4、4.0、4.2和4.4的Zabbix导出的XML文件导入。

在Zabbix 1.8 XML导出格式中，触发器依赖项仅按名称存储。如果有几个具有相同名称（如具有不同的严重性和表达式）且在它们之间定义了依赖关系的触发器，则不可能被导入，必须手动从XML文件中删除这些依赖项，并在导入后重新添加。