Zabbix 在一位企业资深运维人员眼中，究竟是怎样的存在？—用户分享
The following article is from twt企业IT社区 Author twt社区
【导读】本文介绍了Zabbix的一些必备知识，并重点分享了作者工作当中使用Zabbix的一手经验。
【作者】董志卫，任职于李宁（中国）体育有限公司，深耕运维领域多年。
做运维算算也有不少年头了，接触过的监控产品也算是不少，产品也多种多样，各自优缺点鲜明。在监控领域很难说哪家产品一家独大，每个产品均有自己擅长的领域或场景。监控类的一个新产品的出现往往不是去替代另一个产品，更多的往往是对原有产品的补充或互补。至于一个产品最终是否可以长期快速的发展取决于多种因素，也不是一句话可以概括的。下面来分享一下我直接在工作当中使用Zabbix的一点经验，由于篇幅所限，本篇小文不做具体模块的太深入的探讨。
一. Zabbix的由来
使用Zabbix监控产品有必要了解一下他的创始人是谁：Alexei Vladishev(阿列克谢.弗拉迪谢夫，拉脱维亚人)
这位帅哥曾经是一个系统管理员，为了监控运行的服务器和设备正常运行，经过其他的尝试后，下定决心独自开发一个监控软件。经过四年的开发，最终开发出一款监控软件，命名为“Zabbix”，并最终选择以开源软件的形式发布，使用GPLv2许可证（Linux也使用这个许可证）。因此，Zabbix的第一个版本于2001年发布。Alexei Vladishev在这一方面为人类的进步做出了不小的贡献。目前Zabbix由其成立的公司—— Zabbix SIA 积极的持续开发更新维护，产品部署遍布全球多个国家。
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产品，还是非常有必要它的架构体系，直接上图：
(图片来自百度)
通过以上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及数据库监控方式
1.Agent 主要解决的操作系统的监控
2.SNMP 主要解决网络设备及安全设备的监控，如果操作系统按照了Snmp agent 也可以进行监控
3.JMS 主要是解决各类Java平台和程序的监控
4.IPMI 主要是解决服务器相关硬件类的底层监控。如风扇，温度，电压等
5.Trapper 主要解决自定义监控类需求
6.agentless monitoring主要是解决无agent的监控，如接口，IP等
7.web monitoring主要是解决：监控服务的状态，如监控的页面在不在，页面请求响应时间，页面内数据的下载速度等
8.数据库监控主要是解决通过插件监控各种类型的数据库
3）分布式部署
作为一个完整的解决方案，Zabbix是适配多种规模的监控场景，在中大型和超大型的监控场景下，分布式部署必不可少。Zabbix拥有Proxy极大的增强了其扩展能力。特别是在当今混合云和多云的的环境，Zabbix可以统一的监控方案。
理论情况下Zabbix的分布式解决方案可以无限的扩展，满足任意数量设备监控需求。Zabbix proxy 的部署扩展的zabbix server的能力，同时也降低了网络带宽的压力，一个proxy处理将近100个节点的常规操作系统监控指标下，网络IO只有差不多200Kb，极大的降低了带宽的压力。
四．为何选择Zabbix
首先要介绍一下选择Zabbix的原因：
开源免费
完整的解决方案
零活自定义功能
团队能力提升，知识积累
监控场景多样化
如果这些理由都不能打动你，那么你就找一个不选择它的理由就可以了。一个产品纵然有千般好，同时也有不好的一面。
其实，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这么个东东简直是太方便了。他就是一个通用的数据库查询客户端，通过修改上面的数据源，可以快速的查询各种结果:
不得不说Grafana的开发者想的确实够周到的。
3.面板panel
Panel作为Grafana展示的核心元素，你要想在上面展示的数据均需要不同类型的panel进行展示，不通面板展示风格和效果迥异，选择合适类型的面板显得尤为重要。
例如：同样是内存的利用率查看：
Panel option及其他选项也相当的重要，比如Gauge的unit的选项继需要选择Percent（0-100），比如右侧百分比到80%显示橙色，90%显示红色。每一个选项都有它实际的指导意义。
4.环境变量和正则表达式
环境变量定义和表达式匹配尤为重要，一个DashBoard如果没有合适的变量定义基本上就别想很好的进行分类和选择输出。
举例：
一个Linux模糊查询，那么这个对应的主机组就可以只是匹配输出Linux组的相关输出，不同的表达式匹配可以千变万化的作用。有兴趣的朋友可以深入研究。
在变量定义的下面部分有Preview of values，这一部分比较实用，它能够快速的给你输出匹配的结果，有助于你判断上面的各项定义是否合理。如图所示：
有关Grafana更多更深层次的使用需要结合实际场景进行学习和研究，路漫漫其修远兮，吾将上下而求索。一个完美的产品需要有匠人的精神，不断的去探索和学习。
七．使用感受
Zabbix作为一个开源免费的企业级监控解决方案，从它的诞生到现在，前后更新迭代多个版本，整体的软件持续稳定性和极强的业务敏感洞察力，指引它与时俱进，不断完善。Zabbix的在全球和中国的生态已经初步成熟起来，希望它能够越做越好，帮助更多的企业，助力企业快速成长。
最后归结一句话：Zabbix 产品解决方案还是相当不错的。
欢迎给小Z投稿分享你的感受和经验，相信开源的力量。
往期推荐
| |||
| |||
备注“使用Zabbix年限+企业+姓名”
进入交流群，4000+用户已加入
一个人走得快，一群人走得远