可观测性新进化——Zabbix 8.0峰会核心议题前瞻

2025年一直是出现在从前科幻片中的年份，现在已经来到2025，是否有哪一个科技或科幻的名词对你有所冲击？

比如AI、最近这几年常见的机器人、无人机等等……

其实在我们运维工作中也有。

比如：云原生，由云原生再衍生出来的可观测性。

01

可观测性与可观测性监控

第一部分是对可观测性和可观测性监控的理解

可观测性并不是本身自己产生的，是因为有云的存在，有微服务的存在，才有了现在对可观测性的阐述和可观性的监控。

·什么是可观测性？

最早是国外把可观测性的单词observability带到我们的视角中，让我们理解。但这个单词本身属于科学范围，且更多用于天文科技。比如我们常说的宇宙天文的可观测性。

物质本身把自己隐藏的很深，那可观测性就比较差。但是如果我们用一些手段把它破坏开，对于我们来讲可观测性就强了。

可观测性第一取决于这个物质本身的属性特性、第二取决于我们自己掌握的技术手段

·云原生下的监控挑战

从基础设施到顶层应用，云原生的一切都被软件定义。云原生不仅是服务器，它更多是通过软件定义的一切。从基础设施到网络到服务应用，都是通过软件来定义管理的。

云原生其中一点就是微服务。以前，我们都单体服务在一个服务器集房，就算有五十个一百个，也是在可控范围内的。但未来的微服务是成千上万的，可能达到数十万。那时候的监控绝不是依赖于肉眼或者肉眼看一个页面所能理解和监控的。我们更多的要对它所在整个云原生层次中，观测的对象所能暴露出的能让我们完全掌握住的监控项和监控指标，进行统一管理。

由于它的异变性、不确定性、复杂性、模糊性，导致我们无法简单的通过观察或是看一下就能掌握。

这是云原生下监控所面临的挑战，从这就扩展出了可观测性的要求。

·云原生世界的观测内容

如何去了解这个可观测性的内容，最早出来的可观测性就是三个部分内容:

Metrics（指标）

Log（日志）

Trace（追踪）

那我应该如何去理解这件事情呢？

前一个部分我已经认为它像一个物质，类似桌子椅子。可以通过它的颜色、形状和状态来描述它。更可以通过化学的方式来理解。（比如拿化学试剂研究它是不是不锈钢）

我们可以通过物理、化学两个方面，用我们从小到大学习的知识理解它。

——物理方面就是看它属于哪个类目，用颜色，或是体积重量来描述。

——化学方面就是看它化学反应分析材质构成来进行描述。

这对应我们的实际知识是标尺。

我们首先要认识它是谁。无论是AI还是别的什么，也首先要明确他是谁。刚才我们Zabbix的同事已经分享了很多标准化的东西。这个标准化指的就是从放置在生产环境中开始，这个标识就要确保从头到尾多个跨系统之后都要叫这个名字，否则今天叫A另一个地方叫B，大家说的其实是一个东西，但由于标识不统一，沟通不畅，对描述就无法进行管理了，这也是可观测性差的一个方面。

Metrics我就不讲了，这也是大家所理解的度量。然后日志 Trace。还有可扩展性、功能一致性，这个是接口上访问出来的结果，那它反馈回来的结果是真正我所要的结果吗？很多以前在政府网站，网站放上去了，但放上去后，他反馈回来是我的要的那个页面吗？

有时经常说被人黑挂了，或者说黑掉了，出问题了。但其实这是要交互的，类似于化学中我用试剂对它进行探测反应。我们理解可观测性内容和落实可观测性内容时，要通过多个手段像物质一样的去了解它，那可观测性内容就更丰富更全面一些了，而不是简单的通过所谓的Metrics、Log、Trace这三方面。

·建立时间维度的观测视角

监控本身就是和时间有关的东西，并不是说现在所监控到的状态会一直保持。

比如六点监控的数据，到了七点的时候，就是又一个监控数据，两个是不一样的。这就是我们说的时间并不存在，只是我们度量的一个维度而已。

以建立时间维度的角度来进行可观测性的查看。在现在所有的监控系统中，创建个报表或者查看一个数据，很多都是在某一个特定时间点的数据，如果要做后续的分析，做报表和查看，都要以时间段。

还有一点，就是时间切面是什么？刚才我分析了Metrics、Log、Trace这些维度和一致性之类的。当我要对某一件事情探测、监控时，我要看这个时间切面上的多个维度属性的值来进行统一的观测。获取结果才能做我们的决策判断。建立一个时间维度的进行观测查看。

·可观测性的认知

1、云原生世界观测对象是每个软件定义的单元

我们在定义微服务或者定义观测对象时，比如Kubernetes，已经定义最小的一个可操纵单元为pod。但其实pod不是最小的，它还可以拆解。这就像物理一样。有分子原子，还有更深的。但到我们正研究的各个对象上时，就要确定一个所能控制的最小的界定范围。这也是我们要定义的时候，观测对象有一个相应的不同范围的定义单元。

2、可观测性是被观测对象应具备的固有属性和特征

3、可观测性内容可以对照我们认知世界的物理化学方法

我们从小到大学以来学得的知识、了解物理化学的很多方式和手段，都可以在工作中所运用起来。我们观察更多服务器、建设更多服务器，在建CMDB的时候，每个指标都要列清楚，像MySQL的监，其实是用SQL语言查询来落实监控，这都是不同的方法，这也是我们在各种实验中的可有参照。

4、要保持客观性、系统性、关联性和预见性原则

客观性:

比如我在监控这个系统时植入了大量的Agent，那这时候这个Agent已经变成干扰了。所以要克制自己，不放太多，以确保被观测对象的内容或影响差值的东西准确。

系统性、关联性和预见性:

在我们在处理这个监控和被观测对象所暴露出来的监控指标反馈时，不能单说这个被观测或被监控的点。要看它所关联的或在整个环境里所具有的被反馈出来的数据特征，这样才能确保我们对被观测对象在故障处理时能具保一定手段。

5、建立起以时间维度的观察与分析

建立起了这样的认知后，那接着谈谈我在Zabbix监控中是如何去落实的。

02

基于Zabbix的可观测性监控

第二阶段是基于Zabbix的可观测性监控。

·基于Zabbix的可观测性监控架构

首先我们创建一个监控的架构

以下是我的设计：

1、以Zabbix为中心在整个监控中构造一个事件处理的模块。

2、外围设置采集、存储、动作，还有展示四部分，将这四部分分别放入不同的开源软件。

这些开源软件有自己的不同功能，比如说在采集方面，普罗米修斯本身就是为云编程而生的，Kubernetes用的非常好。它通过Zabbix的预处理功能很容易就可以自动的把一些指标被Zabbix纳管，稍后我们会举例说明到底纳管到什么程度。

再一个就是日志，和Skywalking，都可以通过Zabbix进行监控，比如日志关键字还有Skywalking上事件的处理响应，都可以和Zabbix 进行联动，通过事件形式反馈到动作上面，这个动作就是大家常集成的东西。

Zabbix的功能非常强大，包括报警、短信等。这些存储的比如ES或者MySQL都可以作为监控储存数据。像日志或Zabbix其他的一些可以转化为ES存储。

这也给我们带来另一个关于监控中的成本问题的思考：我们做监控的成本绝对不能超过业务。

所以我们在整个设计监控架构中，基于这个提出七个点:

首先是轻架构，轻架构就是他们之间可以灵活选用互相集成模块。

其次是模块化，随时可拆解随时可使用。

低嵌入就是通过API接口，它的上层并没有一个强力的耦合，所有都变成一个部署架构的微服务化，每个应用之间通过接口来进行调用，那对于我们运维来讲，实现了敏捷运维和低成本。

智能化指的是Zabbix可以很好的与deepseek、chatgpt进行集成。在23年之前没有这些AI的时候，我们一直头疼于做数据挖掘、大数据学习来进行智能处理。但现在有了接口，我们直接就可以对接上去。

·与Prometheus集成(Metric)

首先是我们和普罗米修斯是怎么集成的。Zabbix对接上层的普罗米修斯集群，普罗米修斯集群核心是Mimir, 这个Mimir是Grafana，就是所谓的普罗米修斯的下一代。

普罗米修斯这帮人重新又开发了一套作为集中化存储的普罗米修斯集群架构工具，比较轻。不像以前的普罗米修斯集群架构，比较重，直接远程就可以进行统一的数据存储管理。

这让我们运维的同事、同学们感到压力很大。有时候以前有很熟悉的一套，突然间老板说有新的了你怎么不学。这个使得我们既保留了以前的，又学习新的。

通过这样，首先在学习成本上，我们在保留原有的基础上，进行低投入的学习。再就是我们整个过程是自动化的，Zabbix的预处理功能非常强大，整个所有的配置好后全是自动化的，不需要我们再进行太多额外的手动干预。因为普罗米修斯，它监控项阈值配置特别多，一个个梳理非常头疼。再就是我们把整个接入，也很容易和现在的微服务这些进行对接。

·与ELK集成(Logs)

下一个就是与ELK，在我们常用的监控场景，ELK的日志流量比较大，且整个规模化的ELK集群维护也非常复杂。

对于日志的关键字告警，对我们也有一个要求，那这个要求我们如何实现？大家有的是在ELK集群里面这层做。那我们是如何处理的呢？

就是在Logstash里面我们建了一套集群:Logstash集群，然后通过Logstash做日志入库。把所有通过不同的Logstash配置之后进行，根据自己的业务区分将其拆分到不同的ES集群上。

也可以通过日志的应用名称，通过它的主题名拆分到不同集群。这样就分散了后端的ES大集群的集群压力,再对它进行有效的拆解。同时我们在Logstash上又定义了关键字日志和关键字过滤。这个可以用 插件去写。通过在里面写成那个关键字过滤规则。这样就可以把过滤规则通过一个Flask 就是 Python，写的一个API接口。

把Logstash发过来的告警监控报警数据，修正为Zabbix_sender的格式的数据，这样Zabbix就可以接收。接收后，通过相应的预处理和其自动发现功能。把应用的名称，或关键字，以报警形式形成监控项，在Zabbix系统中进行波测，形成有效联动。然后再由Zabbix统一形成事件处理的功能，这样在Logstash上我们也形成一个有效的集成，把Zabbix自动发现预处理功能应用在监控中。

·与Skywalking集成(Trace)

Skywalking本身没有关键字告警的能力。它只做Trace路由和Trace跟踪，然后去查看。Skywalking也有自己的API。我们把Skywalking所有固定配置一次性配置好，直接发到Flask上，转化成Zabbix_sender的格式到Zabbix来进行告警。Skywalking本身有自己的告警配置，但是修改起来特别麻烦。

·功能/一致性监控

这里我举例一个场景，业务一致性。在我们平时监控的时候，只是对某一个主机或者某一个服务器，或者某一个Service。这个业务场景就是从端到端的用户访问到真正返馈的结果，是否形成一个我所真正需要、期望的结果，如果不对就要报警。这个常见于我们做一些回归测试的自动化类似脚本，转移一下就可以使用了。就像我们每天早上做一个模拟的支付测试，或者模拟的领券，来确保开业时是可用的，这也是常见的一致性的监控。

·智能化监控事件的处理

在Zabbix事件处理的能力上。从Zabbix前端到他Action这部分都Zabbix自己带的功能。那我们该如何改造它变成一个智能化的监控实践呢？

其实只需要在脚本里写一个Python脚本。把相应的一些规则放到Zabbix里面后，他就会根据每次的告警事件直接调用到deepseek接口上。把告警事件发到deepseek接口，你要自己构建deepseek，如果普通的用deepseek，那它回答的是通用的答案。但如果你训练他，不断自己搭建模型，它就会按你所期的结果给反馈。这意味着你只需要简单的做一个相应的改造，就可以接入到现在的智能化能力了。

·时间视角的查看

Zabbix其实是有时间处理维度的查看的，可以在问题页面按照时间维度去查看。当我们把前面那些所有，包括日志、Skywalking、还有普罗米修斯这些都收集到这个平台上时。当你再用固定维度按时间查看的时候，你查看的是全面的事件情况，其实这个在Zabbix很容易就可以实现了。

03

可观测性监控的下一阶段

observability只是可观测性。但从我们监控的角度，我认为可以分为两个维度，一个是监测，一个控制。

到目前为止我们一直在讨论的其实都是监测。

从最早操作系统的时候，就已经有了监控的能力。包括他自己对单主机的CPU内存的控制。还有系统用户侧和系统侧的控制。

操作系统的发展是不断向前的，但随着80年代网络诞生，单操作系统已经无法进行有效的监控了。它更多取决于监测的能力。Zabbix也是在这时候诞生的，当时有很多这种工具都是基于操作系统和网络的，不断的发展监测直到云计算时，一直到云原生的时候，可观测性就属于监测这个维度了。

·可观测性监控的下一阶段——智能监控

一直到23年，有了AI的接入。我觉得我们的未来是智能监控。

当我监测的数据更全面，更多的可观测性带来数据或来源为我们赋能的时候，智能AI给我们监控这个方面带来的工作，是控制。

我能对我所监测对象的预期反馈是什么？这里我引入黑客帝国的影视片段，黑客帝国中展示了AI世界中应用版本的迭代及治理。

这个架构师说对尼奥说：你是完全在我掌控中。画面后面监视器代表监控，所有东西，你所有的行为都是我软件定义的。你所有做所做的一切的事情，都能被我监测和控制。

那这里又涉及到一个问题：锡安城是什么？我理解的锡安城其实是一个主动监控的红警工程。我们这么多年，一直是在被动的做监控，出现了事情，才会对看到的监测数据，做出人为的反应。

作为大数据也好，或者说其他微服务这种更多作为可被观测的属性和监控目标的时候，必须主动触发监测和被监控事件，才能不断训练模型。训练模型时反馈回来给我带来的就好像黑哥帝国第四部重启中讲的那样，当把自我攻防完全破坏掉的时候，就完成了版本迭代，就重启了。

我们智能监控的目的，就是在将来要主动的去监控，完成对所有的事情的预先监控和预先控制。

因为我们并不是所谓简单的AIOps，我们这个应该叫智能监控、主动监控。

以上就是我觉得可结合于AI的，大家可以思考的内容。