Zabbix运维实践经验分析.docx

《Zabbix运维实践经验分析.docx》由会员分享，可在线阅读，更多相关《Zabbix运维实践经验分析.docx（19页珍藏版）》请在第一文库网上搜索。

1、Zabbix运维实践经验分析【导读】本文介绍了ZabbiX的一些必备知识，并重点分享了作者工作当中使用Zabbix的一手经验。做运维算算也有不少年头了，接触过的监控产品也算是不少，产品也多种多样，各自优缺点鲜明。在监控领域很难说哪家产品一家独大，每个产品均有自己擅长的领域或场景。监控类的一个新产品的出现往往不是去替代另一个产品，更多的往往是对原有产品的补充或互补。至于一个产品最终是否可以长期快速的发展取决于多种因素，也不是一句话可以概括的。下面来分享一下我直接在工作当中使用ZabbiX的一点经验，由于篇幅所限，本篇小文不做具体模块的太深入的探讨。使用ZabbiX监控产品有必要了解一下他的创始人

2、是谁：A1exeiVIadiSheV（阿列克谢.弗拉迪谢夫，拉脱维亚人）这位帅哥曾经是一个系统管理员，为了监控运行的服务器和设备正常运行，经过其他的尝试后，下定决心独自开发一个监控软件。经过四年的开发，最终开发出一款监控软件，命名为“Zabbix”,并最终选择以开源软件的形式发布，使用GP1V2许可证（1inUX也使用这个许可证）因此，ZabbiX的第一个版本于2001年发布。A1exeiVIadiSheV在这一方面为人类的进步做出了不小的贡献。目前ZabbiX由其成立的公司ZabbixSIA积极的持续开发更新维护，产品部署遍布全球多个国家。Zabbix是什么？ZabbiX是一个完全开源免费的

3、企业级监控解决方案，任何人都可用，它旨在监视和跟踪各种网络服务，服务器和其他网络硬件的状态。ZabbiX的目标是监控MonitOrAnything,这口号真是响亮，感情天上飞的、水里游的，只要插上探针在ZabbiX一切都不是事。下面我们来说说ZabbiX版本相关信息。二.Zabbix版本发布ZabbiX从开始发布至今，其大版本发布时间如下图所示:关注过Zabbix的朋友可能会注意到软件版本里有标准版和1TS版本的存在，这里简单做个介绍。1TS为1OngTermSUPPOrt的简写，ZabbiX将为客户提供5年的支持服务。前三年完全支持与后两年有限制支持。前三年包括一般、关键、安全性问题解决，后

4、两年包括关键、安全性问题解决。超出时间不提供技术支持服务。然而标准版，只提供6+1月支持。Zabbix版本发布计划标准版本：目前的发布计划周期为六个月，每六个月将有一个新的Zabbix稳定版本发布。1TS代表“长期支持版本”Zabbix1TS版本每一年半发布一次，且为ZabbiX客户提供五年的支持服务。Zabbix官方预计在2023年第四季度发布6.01TS版本。在了解有关ZabbiX版本信息后，下面来聊一下ZabbiX的架构体系和运行逻辑。三.Zabbix架构介绍ZabbiX产品，还是非常有必要它的架构体系，直接上图:（图片来自百度）(图片来自http：/1iujunjun-p-122548

5、47.htm1)通过以上2张图基本上可以大致了解Zabbix的体系结构和运行流程，产品涉及很多概念和术语，在这里简单列一下经常接触的组件：(-)Zabbix-Server顾名思义：zabbix监控的SerVer,最核心的部分(-)Zabbi-database：zabbix监控的数据库，可以独立部署(.)Agent:ZabbiX监控的的代理或者客户端(四)Proxy:当监控的规模比较大时，为了降低SerVer的负载的解决方案，一个SerVer可以对接多个PrOXy,proxy可以设置缓存监控数据时间，能够在server异常恢复后同步指定时间的数据到server,整体监控不丢失数据。(五)Zabb

6、ixreb:是访问ZabbiX监控的主要入口，绝大数的配置查看工作都在web界面完成。还有很多如host,hostgroup,temp1ate,action,trigger等，不在此一一详细解释，如有需求请自行百度。不过我还是要说一下ZabbiX监控系统是如何进行工作的，Zabbix作为一个监控系统以下几个环节是必不可少的：1）监控实现采样：周期性的获取某个被监测指标的相关数据，大致分为主动模式和被动模式。存储：将采集到的数据存储在指定的存储系统中，Zabbix数据库是MySQ1或者PostgreSQ1,新版本支持部署在TinIeSCaIeDBo对于数据的存储可分为两大类：历史数据：可理解为过

7、去某一时间点的数据趋势数据：可理解为过去某一段时间的数据展示：采集完数据后，为了使数据能更直观的展现在用户面前，可将采集到的数据做二次处理，做成各类图形。Zabbix就是使用的PHP程序将采集的数据通过WebGUI直观的展示给用户。报警：当监控的指标出现异常时需要监控系统能自动的发出告警信息，甚至在出现报警后能自动完成修复。2）监控方式ZabbiX主要有Agent,SNMP,JMX,IPMI,Trapper,Web及数据库监控方式1. Agent主要解决的操作系统的监控2. SNMP主要解决网络设备及安全设备的监控，如果操作系统按照了SnmPagent也可以进行监控3. JMS主要是解决各类J

8、aVa平台和程序的监控4. IPMI主要是解决服务器相关硬件类的底层监控。如风扇，温度，电压等5. Trapper主要解决自定义监控类需求6. agent1essmonitoring主要是解决无agent的监控，如接口，IP等7. webmonitoring主要是解决：监控服务的状态，如监控的页面在不在，页面请求响应时间，页面内数据的下载速度等8. 数据库监控主要是解决通过插件监控各种类型的数据库3）分布式部署作为一个完整的解决方案，ZabbiX是适配多种规模的监控场景，在中大型和超大型的监控场景下，分布式部署必不可少。ZabbiX拥有ProXy极大的增强了其扩展能力。特别是在当今混合云和多云

9、的的环境，ZabbiX可以统一的监控方案。理论情况下Zabbix的分布式解决方案可以无限的扩展，满足任意数量设备监控需求。Zabbixproxy的部署扩展的ZabbiXSerVer的能力，同时也降低了网络带宽的压力，一个ProXy处理将近100个节点的常规操作系统监控指标下，网络IO只有差不多200Kb,极大的降低了带宽的压力。四.为何选择ZabbiX首先要介绍一下选择Zabbix的原因: 开源免费 完整的解决方案 零活自定义功能 团队能力提升，知识积累 监控场景多样化如果这些理由都不能打动你，那么你就找一个不选择它的理由就可以了。一个产品纵然有千般好，同时也有不好的一面。其实，ZabbiX从

10、开始发布到真正大面积的占领市场，除了自身的不断优化之外还有时间因素。我选择ZabbiX也不是从一开始就真正的在生产环境中应用。Zabbix自从3.2版本以后才变得逐渐完善起来，我是从3.4版本开始运用到生产环境，大面积的投入使用，直到5.0版本一直更新使用，整体监控平台稳定输出，保障业务使用。在开源监控市场，ZabbiX和后起之秀PrOnIetheUS占领了半壁江山。Prometheus是随着K8S的逐渐成熟之后开始慢慢成熟起来，近年来其社区也非常的活跃。在未来容器市场大有作为的前提下，PrOnIetheUS可能会占据越来越多的市场份额。这里做一个对比：由于我的企业当中监控场景多样化和前面多种

11、原因，我们选择Zabbix作为统一监控解决方案。ZabbiX上手难度不大，通过简单的学习，半个小时即可搭建出一套可用的监控环境，至于说要用好，还是要投入一些精力进行研究和定制。并且ZabbiX生态已经非常成熟，学习的成本和压力不大。五.监控场景Zabbix作为一个整体的解决方案，基本上你能想到的场景他都可以监控，这个依赖于他自身强大的集成能力，可以集成各种插件。随着市场的发展各种的模块也在不断的更迭，基本上是简单的配置即可使用。为我们更加便于使用做好大量选择。在此我们说他优点的同时稍微说一下这方面的不足：监控模块监控力度精细化不够，食而无味，弃之可惜。这一点上劣势相对突出，比如OraCIe监控

12、插件，其版本更新迭代较慢，能够搜集的监控元素不多，相比较专业的OraC1e监控工具相差甚多。还需要频繁大量的自定义监控。希望ZabbiX推出相应插件的时功能能够尽量满足大部分的监控需求，毕竟重口难调。Zabbix可以监控东西太多了，在此不一一列举，这里介绍在以下几个方面使用，且整体使用效果不错。-硬件（小型机，PC,存储）- 操作系统(AIX,Windows,1inux)- 数据库（Orae1e）- 网络设备（交换机，路由器，流量设备，负载均衡，防火墙）- 虚拟化- 服务和业务网站监控- 自定义监控有关ZabbiX在这些使用场景的具体使用，在此不做具体详细的介绍。下面主要介绍一下比较典型的几个

13、问题：1 .Agent的部署在大量的部署Agent的场景下可以使用zabbix的自动发现及匹配相关规则，也可使用Python或者其他语言写成的工具，调用ZabbiX的Api,批量的添加和配置Agent业务场景2 .数据获取zabbix配置完毕后，可能会遇到数据获取不到或者获取数据较少的情况。（一）数据获取不到几种可能常见原因：1）配置不对：agent和SerVer端配置不对应2）Agent没有启动：配置完成未启动或未设置开机启动3）网络不通：防火墙未放开4）版本不兼容：如snmpv1,v2,v35）字段类型不匹配：time和String等6）模板选择不对Zabbix获取不到数据是初学者经常可能

14、遇到的问题，以上几个步骤可以涵盖大部分此类问题的原因。（二）数据获取较少此类问题主要可以分为3类：1）监控agent的版本和SerVer版本及模板库的不配，获取部分数据，2）操作系统或网络SrImP库版本太低，本身提供的接口信息较少3）ZabbiX模板定义获取数据的范围或者指标太少，导致管理节点智能获取较少数据。如遇此类问题首先要确认是否是因为受监控对象自身版本太低导致，如不能升级更新客户端的操作系统或者网络设备等监控对象的系统版本，可通过自定义的方式，手工添加相应的监控item或范围。必要的时候更新监控模板，完善相应监控内容。3 .MapsMaps功能可以方便的基于某一个特点业务场景，通过连

15、接线勾勒出相互之间的关系，并且可以实时更新的。对于整个业务系统的监控就非常的方便。也便于掌握每个节点的相关情况。4 .告警ZabbiX成熟的告警体系和集成能力，使得很方便的选择时候直接的监控接收方式。目前主流的监控告警接收方案（邮件+钉钉或微信）如图所示:钉钉和企业微信5.报表ZabbiX从第一版本发布至今，它的报表功能一致就不是很好。可读性并不是很强，且自身没有自动发送报表的功能。这个可以看着ZabbiX目前的一个减分项，往往需要自定义，通过邮件系统调用api接口获取原始监控数据，通过编程语言定制后再发送出去。体验不是不好。国内的很多公司监控产品都是基于ZabbiX为底板进行了深度的开发，在功能，可用性和报表等功能做到了大大的加强，并最终成为商业产品。不过这些都需要真金白银换过来的，作为用户还是要清楚的了解自身具体需求，在后续产品的选择上就没有太大的困难了。六.监控展示Grafana相信做监控的朋友对Grafana这个产品不陌生，Grafana+Zabbix基本上已经成了行业标配。通过Grafana展示ZabbiX的监控数据，可以随心所欲显示各种效果，打造属于自己Sty1e。话不多说，直接上图（1inUX和网络交换机