感谢太保科技自动化运维专家杜颖君在2023Zabbix大会·上海站的精彩分享。
点击查看视频（B站账号：Zabbix中国），本文为演讲实录有删减。
欢迎参加12月Zabbix中国峰会，点击了解议程。
正文：
我认为Zabbix作为开源监控运维软件的佼佼者，陪伴我们度过了许多岁月，这离不开我们创始人团队及对产品孜孜不倦的追求和与时俱进的工作态度。相信Zabbix的未来也会更加宽广。
作为Zabbix的忠实用户，我们公司已经使用Zabbix多年。自2015年起，我一直致力于建立公司的自动化运维体系，其中包含监控和一系列自动化产品。
今天我从提问中了解到，大家对云原生环境下的监控体系也相当关心。我非常感谢宏时数据给我这个机会分享我的课题：太平洋保险在多云环境下Zabbix的运用实践。今天的议题分为4个部分，
太保云建设情况介绍 多云环境对监控体系的挑战 Zabbix如何面对挑战 Zabbix在智能化监控体系中的运用。
一、太保云建设情况介绍
首先，介绍一下公司云情况。公司整体数据中心运营架构与金融行业相似，采用两地三中心运行模式。在今年年初，我们创建了一朵信创云，主要使用的厂商是阿里，原来的云平台主体在某数据中心，我们称之为传统云。另外，我们云下主机总规模大约有6000多台，三个中心加起来，生产环境基本上共有近4万台主机设备。
二、多云环境对监控体系的挑战
关于建立多云环境，大家之前也提到，企业中可能会有多套云环境共存，甚至与传统模式和容器形态的共存共生，我相信这会伴随我们很长时间。
我列出了一些主要问题。
第一，是容器化与传统部署模式的并存，容器状态的运行模式与传统模式实际上是不同的。
第二，云产品自带的监控覆盖指标数量有限，这些数据是我们经过实践论证得出的结论。
第三，云产品的监控模式，我认为有必要详细介绍。主要是各个产品组件自带的监控指标，将其汇总到所谓的监控产品中。实际上，云原生提供的监控产品主要具备告警处理事件分层功能，对标Zabbix的是告警模块。采集模块与云产品本身一起的，导致会存在一些问题。问题一，数据格式肯定是不统一的。问题二是作为云产品的提供者，主业并非监控。问题三是我们整体架构的复杂度得到了提升，因为内部相对更复杂。目前新的云原生平台可能都是基于k8sKubernetes部署，而老的容器平台是基于Marathon平台定制开发的，还有传统的非容器化部署形态，实际上是三种环境共存。
第四， 现在监控的信息量非常大。从我们的体量来看，无论是单独依靠Zabbix还是底层的一些基础监控，在单个领域来看是足够的，但还需要整合起来同步使用，这样整体的告警分析难度就能大幅度降低。
三、Zabbix如何面对挑战
现在我们看一下Zabbix在我们的环境下如何使用。这部分主要是我们公司内部产品架构的模拟。在中间部分，我们已经将三朵云，信创 、华三和云下设备，全部用Zabbix作为基础组件进行监控。
对于云来说，交付产物仍然是操作系统，包括网络设备、通讯设备和安全设备。无论它的核心和操作层是什么，基本上上面的内容仍然万变不离其宗。而底下的“风火水电”设备则是将内外环境结合起来使用的。上层对于应用的交易响应，我们也引入了其他产品，对于旁路和全链路的监控。最上层实际上是我们自己封装的，将下面的几套监控环境数据整合起来，形成一些看板告警的能力。这边是Zabbix在我们的云环境下的使用范围及用到的特性，主机层以及通用类型的中间件。例如ngnix、redis，以及我们现在的信创组件，如东方通等，我们都是使用Zabbix来统一实现。
关于网络存储和通讯安全这些传统设备，基本上采用了Syslog加关键字的方法，放在Zabbix中进行统一的告警处理。另外一部分是关于容器层级的监控。现在会使用Zabbix进行基础容器层级的监控，这针对于K8sKubernetes。
首先Zabbix自从6.0以后，也带有了对pod直接采集信息的功能。基本上我们能够通过模板实现了对容器内部CPU和内存的监控。另外一部分是现在容器的部署形态。如果使用Kubernetes，一个pod里会有多个容器。有些监控是附带的，不在我们监控范围内。我们使用Zabbix对Prometheus预处理标签功能，筛选需要监控的容器实例。实现这一步以后，Zabbix容器指标这部分与传统监控指标差不多，我认为统一来看就行了。这部分主要针对Prometheus和Kubernetes
的应用。
为什么我们选择Zabbix作为主体监控工具？是因为我们在内部进行了反复论证。
第一，覆盖面。Zabbix作为统一的监控工具在我们这边运行了很多年。我们非常认可Zabbix的覆盖面，基本上能满足基础设施层的所有监控需求。
第二，开放性。我认为这对我们至关重要。因为各种云厂商的数据开放性相对较差，我们要集成它们的数据，需要很大的精力与他们沟通。Zabbix采用我们的代理采集方式，我下面有张图会重点介绍。对于我们来说，数据集成方法无需担心，而且与传统监控可以融合。
第三，易用性。无论是新云还是老云，操作系统层级都能统一使用Zabbix的方案和模板等，实现上来讲原来可用的现在还能用。
我认为大家在拥有云产品之后，不必过于迷信云产品本身的能力。相对而言，我们不必过分追求云产品的最新或最好。总体来说，我对云产品的理解，基础设施层和操作系统层都是相同的，它们的区别在哪里呢？一方面是在管控分配资源的自动化能力方面，相较于传统数据中心要操作的便捷性更好，另一方面是网络，封装了软件定义的网络管理模式。
这张图展示了我们内部的大致监控架构图。今年我们增加了一套松江的信创云的数据环境，基本上架构可以不动，仍然沿用原来的架构。另外一块是关于数据开放性，我们已经在Zabbix Proxy层和server层进行了实施。
用Filebeats组件,我们需要抽取性能数据推送到kafka ，然后通过运维数据总线进行集成。这主要有两个方面，一是我们会使用多套Zabbix server来管理数据中心，整体形成统一的数据平面。另一方面，在Zabbix数据方面，我们需要与CMDB、自动化运维等下游依赖数据的系统进行整体关联，以实现数据横向打通。
刚才提到，Zabbix可以覆盖我们在云环境下的大部分监控要求，但实际上还有一些确实是无法覆盖的，这是云厂商本身提供的能力。总体来说，上面这些功能我们没有用Zabbix进行覆盖。这主要是阿里的一些产品，它本身提供的包括云端自己分出来的云，等于全部用pass平台去完成 MongoDB等功能。另一方面，Zabbix对容器层级的监控我们主要用于告警，涉及到问题排查与分析的，还是会使用Prometheus。
实际上在内部过程中，采集方式是对接SIS，也就是阿里操作的数据总线。一开始他们并不允许我们直接获取他们的数据，这也是经过多轮谈判后，才走到这一步才能实现的。
实际上我们的告警中心为云产品进行了大量翻译工作。刚才提到，各个不同云产品组件提供的告警信息对运维人员造成了巨大冲击，基本上看不懂。经过多轮努力，历时4个多月，我们才处理了所有监控，让他们能够真正地说人话。另外，那张图展示了我们云原生监控能力的数据流向。主体将他们的数据提供给我们，然后与我们的CMDB和业务系统关联。容器化部分和基础组件也是相同的。
最后，总结一下我们认为Zabbix在多云环境下的监控优势。
这是大致用于Zabbix进行容器化采集的一个模板。对于kubernetes的templates，我们覆盖的组织还不多，因为信创云是新上的，目前规模相对有限。
接下来我将介绍一下主要优势。
第一，Zabbix通用指标数量远大于云产品自带监控产品，且采集组件性能和稳定性相对可靠。我们Zabbix对于监控采集的通用指标肯定远大于云厂商提供的。
第二，Zabbix事件告警触发规则前端界面配置，且支持规则效验功能，告警管理能力的灵活性和通用性强。Zabbix事件告警触发规则，相对来说配置的友好度较高。这可能与我们多年在用Zabbix有关，已经习惯了，但总体来说，相比云厂商需要在各个产品组件中调整阈值，Zabbix友好得多，成本也会降低。
第三，Zabbix专注于监控领域，产品化程度高，云产品监控能力多为各个产品自带，友好性有待提升。Zabbix专注于监控领域，其产品化程度相对较高。我刚才提到云产品的一些监控指标输出对于其产品研发来说，并非主业，它肯定要主攻云相关产品能力的监控，对他来说是辅助，等同于一个配角。这是我们在与云厂商的架构师深度交流后才了解到的情况，实际上他们团队的重视程度肯定弱于开发其主打产品。
第四，Zabbix自带容器监控能力已经可以满足常规监控场景，可补足Prometheus在告警管理上的短板，配合使用效果更佳。现在针对应用层本身的告警和触发对业务产生影响的并不多，因为依赖容器k8sKubernetes本身的自愈机制，包括我们依靠老的容器平台，它的健康检查包括自身的健康检查和探活重启机制就能解决大部分问题了。目前，业务影响较高且超出运维人员认知范畴的，排障时间较慢的问题主要出现在数据库层和网络层。
第五，是多云、云下设备统一管理，可减少监控建设及后续运维成本。在多云形态下，我们为何坚定地一定把Zabbix统一的三套环境拉平，实现统一管理。讨论这个方案时，内部也有很多声音，包括阿里也提出来，从理论上来说宿主机或虚拟机这一层是不允许安装探针的。我们经过了多轮谈判讨论才能部署好自己的一些自动化探针。从我的团队出发，我肯定希望拥有一套统一的管理，维护成本和后续数据对接的成本会小很多。
四、Zabbix在智能化监控体系中的运用
最后一部分可能会超出Zabbix的范围体系。在这次范围体系中，我们在智能监控体系建设中的一些内容。Zabbix数据的运用可能与其自身能力有关,主要是基于指标数据进行了一些衍生的高阶开发。这一块在过去两年中也是我的重点工作中心。
首先，我们现在的环境变得更加优越，监控手段也增加了。我们刚才也看到了，从上到下我们有好几套与监控相关的产品，目前的监控覆盖面大了之后将会出现无效告警，这是一个严重的问题，每种监控类型都会出现。
实际上我们现在最需要解决的两大问题，一个是从海量信息中剔除有效告警，另一个是目前拥有多套监控平台，实际上对于他们的故障排查来说仍然存在困难，因为他们可能不知道哪些信息是我能掌握的？我们的系统已经采集到了哪些信息？我应该从哪个平台上查看？从我们的监控体系建设角度来看，实际上还是有所欠缺。
右边这张图主要是这两年的一个工作目标。会加强对Zabbix本身组合告警的功能。
Zabbix多指标组合告警功能剔除30%无效告警。一个指标出现告警后，我会查看其他几组指标，如果同时发生超过阈值的情况，我们会将其判定为一个告警。这样我们可以在评估后剔除大约有30%的无效告警。
因为现在很多指标类似于网络流量和IO，我们采集了很多数据，但是不敢开启告警。开的话接单人员肯定受不了。
运行基线动态阈值，结合故障分析引擎告警抑制率70%。我们会引入动态基线，即动态阈值算法。结合在建的一套故障分析引擎。也就是说将人工排障经验沉淀到我们的系统中，进行第二道过滤基本上可以将告警抑制率达到70%。
精准定位，引导恢复，故障自愈。较高阶的精准定位，现在也在讨论gpt大模型。将一些沉淀的应急预案和恢复方法如自动化方法全部与监控结合起来，作为故障治愈和引导恢复的功能。
这一块主要是我们后续规划的智能监控体系的整体规划图。
大家也看到，Zabbix在其中是指标数据的一个重要贡献。我们还会使用多维域值功能。当然我们还会加入一些封装，固定阈值是最常见的。
这也是我们今年年头在进行的一些探索，是在数字孪生源宇宙方面的一些运用。其实对于我们的机房来说。我们之前也提到了，带外的是针对硬件设备，例如设备的风扇、亮灯等，我们已经将其投射到数字孪生的数据中心空间里，包括现有的温度热量和动环信息数据也已经集成。
下一步，我们会将Zabbix数据集成到数字孪生的数据中心，这样物理设施的巡检和应用系统的影响分析可以很快展现在运维人员面前。这是一个应用拓扑图，从上到下，例如一台主机或网络设备出现告警后，它上面有多少承载的应用会受到影响。另外，也可以对物理设施的操作进行模拟。简单来说，就是拔掉网线，直接关闭机器，对于整个应用对它是否有影响。我们是基于全套数据进行全域分析，降低人进机房的频率。
最后，我也想与大家分享一个观点。一个相对轻松的小故事。我们现在无论是监控还是自动化，工具非常多。举一个较为普遍的例子。之前有个肥皂厂，他们在流水线上最后一道工序是将肥皂装入盒子，工人可能会出现疏忽，导致使用空盒子也放入流水线，最终在市场上销售。管理者请来了一位工程师提供了一个机械臂的方案。成本和耗时相对较高。他在进行在讨论这个方案的过程中，有一位老工人提出来说：如果仅解决空盒子问题，只需放一台电风扇就可以了。这对工程师来说确实是一个挑战。当场应该也是比较懵的。实际上，从我们的分析来看，电风扇确实可以解决一定的问题，成本也相对较低。效果也相当好。但是总体来说它不能作为方案。空盒子可以吹走，但如果里面只有半块肥皂或者1/3块肥皂，可能就搞不定了。
通过这个故事，我想表达什么？就在我们在多种云环境体系下，什么样的工具实际都需要关注它的长处和短处。我们也不必过于迷信云能够带来好处。我们也需要考虑传统的东西。这几年的工作中，我一直在做电风扇和机械臂之间的取舍，包括我们之前提到的智能算法、基线预测、收敛告警。听上去相对高大上的算法进行开发，传统开发的规则机制来收敛和抑制也OK。从效果来看，你真的说他能差多少也不见得，对吧？大家不用对号入座，肯定不是说谁就是电风扇。
总体来说，我们可以把思路放宽一点，心胸也可以放宽一点。在这种环境下，我们必须打好组合拳。只有这样才能迎接我们的新挑战。我的分享就到这里。
更多案例分享，欢迎参加Zabbix中国峰会！
本文分享自微信公众号 - Zabbix开源社区（china_zabbix）。
如有侵权，请联系 [email protected] 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一起分享。