·2021-11-24 14:39

系统架构师·李宁（中国）体育用品有限公司

Zabbix在一位企业资深运维人员的眼中，究竟是怎样的存在？

字数 6434阅读 9601评论 4赞 14

自从有疫情以来，时间好像加装了翅膀，每天在不知不觉中飞快度过。总感觉有点小忙，有时还忙的不知所以然。好久没有坐下来写运维方面的东西了，近期收到好友邀请准备计划写一点有关监控类 Zabbix 的方面小文。

做运维算算也有不少年头了，接触过的监控产品也算是不少了，产品也是多种多样，各自优缺点鲜明。在监控领域很难说那家产品一家独大，每个产品均有自己擅长的领域或场景。监控类的一个新产品的出现往往不是去替代另一个产品，更多的往往是对原有产品的补充或互补。至于一个产品最终是否可以长期快速的发展取决于多种因素，也不是一句话可以概括的。下面来分享一下我直接在工作当中使用 Zabbix 的一点经验，由于篇幅所限，本文不做具体模块的太深入的探讨。

一. Zabbix 的由来

使用 zabbix 监控产品有必要了解一下他的创始人是谁：Alexei Vladishev( 阿列克谢 . 弗拉迪谢夫，拉脱维亚人 )

这位帅哥曾经是一个系统管理员，为了监控运行的服务器和设备正常运行，进过其他的尝试后，下定决心独自开发一个监控软件。经过四年的开发，最终开发出一款监控软件，命名为“ Zabbix” ，并最终选择以开源软件的形式发布，使用 GPLv2 许可证（ Linux 也使用这个许可证）。因此， Zabbix 的第一个版本于 2001 年发布。 Alexei Vladishev 在这一方面为人类的进步做出了不小的贡献。目前 Zabbix 由其成立的公司—— Zabbix SIA 积极的持续开发更新维护，产品部署遍布全球多个国家。服务方面，为能给中国爱好者和用户提供更本地化和个性化的服务，坚定企业使用 Zabbix 的决心与信心， Zabbix SIA 指定上海宏时数据为其在中国唯一战略合作伙伴、唯一分销商与原厂代表。依托双方各自优势携手在中国开展 Zabbix 原厂的咨询培训、软件开发、远程支持、现场实施、等全方位的落地，并携手定制适合中国客户的解决方案。

zabbix是什么？

答： Zabbix 是一个完全开源免费的企业级监控解决方案 , 任何人都可用，它旨在监视和跟踪各种网络服务，服务器和其他网络硬件的状态。

Zabbix 的目标是监控 Monitor Anything ，这口号真是响亮，感情天上飞的，水里游的只要插上探针在 zabbix 一切都不是事。

下面我们来说说 zabbix 版本相关信息。

二． Zabbix 版本发布

Zabbix 从开始发布至今，其大版本发布时间如下图所示：

关注过 Zabbix 的朋友可能会注意到软件版本里有标准版和 LTS 版本的存在，这里简单做个介绍。

LTS 为 Long Term Support 的简写， Zabbix 将为客户提供 5 年的支持服务。前三年完全支持与后两年有限制支持。前三年包括一般、关键、安全性问题解决，后两年包括关键、安全性问题解决。超出时间不提供技术支持服务。然而标准版，只提供 6+1 月支持。

Zabbix版本发布计划

标准版本：

目前的发布计划周期为六个月，每六个月将有一个新的 Zabbix 稳定版本发布。

LTS代表 “ 长期支持版本 ” 。

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

Zabbix 官方预计在 2021 年第四季度发布 6.0 LTS 版本。

在了解有关 zabbix 版本信息后，下面来聊一下 zabbix 的架构体系和运行逻辑。

三． Zabbix 架构

介绍 zabbix 产品，还是非常有必要它的架构体系，直接上图：

参考连接：百度

参考： http://t.zoukankan.com/liujunjun-p-12254847.html

通过以上 2 张图基本上可以大致了解 Zabbix 的体系结构和运行流程，产品涉及很多概念和术语，在这里简单列一下经常接触的组件：

(一) Zabbix-server 顾名思义： zabbix 监控的 server ，最核心的部分（）

(二) Zabbix-database ： zabbix 监控的数据库，可以独立部署

(三) Agent ： zabbix 监控的的代理或者客户端

(四) Proxy ：当监控的规模比较大时，为了降低 server 的负载的解决方案，一个 server 可以对接多个 proxy ， proxy 可以设置缓存监控数据时间，能够在 server 异常恢复后同步指定时间的数据到 server ，整体监控不丢失数据。

(五) Zabbix-web ：是访问 zabbix 监控的主要入口，绝大数的配置查看工作都在 web 界面完成。

还有很多如 host ， hostgroup, template, action ， trigger 等，详细的解释不在此一一详细解释，如有需求请自行百度。

不过我还是要说一下 Zabbix 监控系统是如何进行工作的， Zabbix 作为一个监控系统以下几个环节是必不可少的：

1）监控实现

采样：周期性的获取某个被监测指标的相关数据，大致分为主动模式和被动模式

存储：将采集到的数据存储在指定的存储系统中， Zabbix 数据库是 mysql 或者 PostgreSQL, 新版本支持部署在 TimescaleDB

对于数据的存储可分为两大类：

历史数据：可理解为过去某一时间点的数据

趋势数据：可理解为过去某一段时间的数据

展示：采集完数据后，为了使数据能更直观的展现在用户面前，可将采集到的数据做二次处理，做成各类图形。 Zabbix 就是使用的 PHP 程序将采集的数据通过 Web GUI 直观的展示给用户。

报警：当监控的指标出现异常时需要监控系统能自动的发出告警信息，甚至在出现报警后能自动完成修复。

2）监控方式

Zabbix 主要有 Agent ， SNMP ， JMX ， IPMI, Trapper ， web 及数据库监控方式

Agent 主要解决的操作系统的监控
SNMP 主要解决网络设备及安全设备的监控，如果操作系统按照了 Snmp agent 也可以进行监控
JMS 主要是解决各类 Java 平台和程序的监控
IPMI 主要是解决服务器相关硬件类的底层监控。如风扇，温度，电压等
Trapper 主要解决自定义监控类需求
agentless monitoring 主要是解决无 agent 的监控，如接口， IP 等
web monitoring 主要是解决：监控服务的状态，如监控的页面在不在，页面请求响应时间，页面内数据的下载速度等
数据库监控主要是解决通过插件监控各种类型的数据库

3）分布式部署

作为一个完整的解决方案， Zabbix 是适配多种规模的监控场景，在中大型和超大型的监控场景下，分布式部署必不可少。 Zabbix 拥有 Proxy 极大的增强了其扩展能力。特别是在当今混合云和多云的的环境， Zabbix 可以统一的监控方案。

理论情况下 Zabbix 的分布式解决方案可以无限的扩展，满足任意数量设备监控需求。 Zabbix proxy 的部署扩展的 zabbix server 的能力，同时也降低了网络带宽的压力，一个 proxy 处理将近 100 个节点的常规操作系统监控指标下，网络 IO 只有差不多 200Kb ，极大的降低了带宽的压力。

四．为何选择 Zabbix

首先要介绍一下选择 Zabbix 的原因：

1、开源免费

2、完整的解决方案

3、零活自定义功能

4、团队能力提升，知识积累

5、监控场景多样化

如果这些理由都不能打动你，那么你就找一个不选择它的理由就可以了。一个产品纵然有千般好，同时也有不好的一面。

Zabbix 其实从开始发布到他真正大面积的占领市场，除了自身的不断优化之外还需要时间因素。我选择 Zabbix 也不是从一开始就真正的在生产环境中应用。 Zabbix 自从 3.2 版本以后才变得逐渐完善起来，我是从 3.4 版本开始运用到生产环境，大面积的投入使用，直到 5.0 版本一直更新使用，整体监控平台稳定输出，保障业务使用。

在开源监控市场， Zabbix 和后起之秀 prometheus 占领了半壁江山。 Prometheus 是随着 K8S 的逐渐成熟之后开始慢慢成熟起来，近年来其社区也非常的活跃。在未来容器市场大有作为的前提下， prometheus 会暂居越来越多的市场份额。

这里做一个对比：

由于我所在企业当中监控场景多样化和前面多种原因，我们选择 Zabbix 作为统一监控解决方案。

Zabbix 上手难度不大，通过简单的学习，半个小时即可搭建出一套可用的监控环境，至于说要用好，还是要投入一些精力进行研究和定制。并且 Zabbix 生态已经非常成熟，学习的成本和压力不大。

五．监控场景

Zabbix 作为一个整体的解决方案，基本上你能想到的场景他都可以监控，这个依赖于他自身强大的集成能力，可以集成各种插件。

随着市场的发展各种的模块也在不断的更迭，基本上是简单的配置即可使用。为我们更加便于使用做好大量选择。在此我们说他优点的同时稍微说一下这方面的不足 : 监控模块监控力度精细化不够，食而无味，弃之可惜

这一点上劣势相对突出，比如 Oracle 监控插件，其版本更新迭代较慢，能够搜集的监控元素不多，相比较专业的 Oracle 监控工具相差甚多。还需要频繁大量的自定义监控。希望 zabbix 推出相应插件的时功能能够尽量满足大部分的监控需求，毕竟重口难调。

Zabbix 可以监控东西太多了，在此不一一列举，这里介绍以往在以下几个方面使用，且整体使用效果不错。。

硬件（小型机， PC ，存储）
操作系统（ AIX,Windows,Linux ）
数据库（ oracle ，）
网络设备（交换机，路由器，流量设备，负载均衡，防火墙）
虚拟化
服务和业务网站监控
自定义监控

有关 Zabbix 在这些使用场景的具体使用，在此不做具体详细的介绍。下面主要介绍一下比较典型的几个方面问题：

1.Agent的部署

在大量的部署 Agent 的场景下可以使用 zabbix 的自动发现及匹配相关规则，也可使用 Python 或者其他语言写成的工具，调用 Zabbix 的 Api ，批量的添加和配置 Agent 业务场景

2.数据获取

zabbix 配置完毕后，可能会遇到数据获取不到或者获取数据较少的情况。

(一) 数据获取不到几种可能常见原因 ：

1) 配置不对： agent 和 server 端配置不对应

2) Agent 没有启动：配置完成未启动或未设置开机启动

3) 网络不通：防火墙未放开

4) 版本不兼容：如 snmp v1 ， v2 ， v3

5) 字段类型不匹配： time 和 string 等

6) 模板选择不对

Zabbix 获取不到数据是初学者经常可能遇到的问题，以上几个步骤可以涵盖大部分此类问题的原因。

(二)数据获取较少

此类问题主要可以分为 3 类：

1) 监控 agent 的版本和 Server 版本及模板库的不配，获取部分数据，

2) 操作系统或网络 snmp 库版本太低，本身提供的接口信息较少

3) Zabbix 模板定义获取数据的范围或者指标太少，导致管理节点智能获取较少数据。

如遇此类问题首先要确认是否是因为受监控对象自身版本太低导致，如不能升级更新客户端的操作系统或者网络设备等监控对象的系统版本，可通过自定义的方式，手工添加相应的监控 item 或范围。必要的时候更新监控模板，完善相应监控内容。

3.Maps

Maps 功能可以方便的基于某一个特点业务场景，通过连接线勾勒出相互之间的关系，并且可以实时更新的。对于整个业务系统的监控就非常的方便。也便于掌握每个节点的相关情况。

4.告警

Zabbix 成熟的告警体系和集成能力，使得很方便的选择时候直接的监控接收方式。目前主流的监控告警接收方案（邮件 + 钉钉或微信）

如图所示：

（钉钉）

（企业微信）

5.报表

Zabbix 从第一版本发布至今，它的报表功能一致就不是很好。可读性并不是很强，且自身没有自动发送报表的功能。这个可以看着 zabbix 目前的一个减分项，往往需要自定义，通过邮件系统调用 api 接口获取原始监控数据，通过编程语言定制后再发送出去。体验不是不好。

国内的很多公司监控产品都是基于 Zabbix 为底板进行了深度的开发，在功能，可用性和报表等功能做到了大大的加强，并最终成为商业产品。不过这些都需要真金白银换过来的，作为用户还是要清楚的了解自身具体需求，在后续产品的选择上就没有太大的困难了。

六 . 监控展示 Grafana

相信做监控的朋友对 Grafana 这个产品不陌生， Grafana+Zabbix 基本上已经成了行业标配。通过 Grafana 展示 zabbix 的监控数据，可以随心所欲显示各种效果，打造属于自己 Style 。话不多说，直接上图（ Linux 和网络交换机的监控展示）。

Grafana搭配 zabbix ，完美的解决了数据的采集和展示问题。

Grafana的安装这里不做过多的介绍，官网和各种论坛有大量的文章描述安装和实施过程。

在这里主要介绍一点 grafana 的使用方面经验。

1.DashBoard

Grafana 官网有大量的有关 zabbix 的 Dashboard ，通过（ ID 或 json 格式）可以很方便的联网导入你的 Grafana ，简单的修改数据源即可使用。但是很少有比较完善的 dashboard ，基本上都需要经过适当的修改才会满足大致的需求，如果打造属于自己的精致的 DashBoard, 那么就需要很好的研究一下各组件及选项的使用。

2.Explore

刚开始接触 Explore 时很少去关注它，不过渐渐的熟悉的熟悉起来 Grafana 以后，你会感觉有 Explore 这么个东东简直是太方便了。他就是一个通用的数据库查询客户端，通过修改上面的数据源，可以快速的查询各种结果 :