蓝鲸观测平台：统一观测数据关联模型探索

DeepFlow

发布于 2024-09-27 14:43:32

830

发布于 2024-09-27 14:43:32

前言

本文为蓝鲸观测平台数据模块负责人在蓝鲸智云和 DeepFlow 社区合办的第六场 eBPF 零侵扰可观测性 Meetup 上的演讲，原来题为根因定位关键：统一观测数据关联模型探索

概述

根因分析高度依赖可关联的观测数据。蓝鲸在构建了包含 traces、logs、metrics 等多种数据类型的复杂数据系统的基础上，探索通过整合 CMDB、K8s、eBPF 等数据源，利用实体关联，网络关联，自定义关联等关联手段，构建了统一的观测数据关联模型，为用户全景视图能力，大语言模型智能跟因分析能力等场景，构建了关键的数据基础，取得了初步的效果，以下是我们的分享，主要分为三部分：

从监控到观测转型的困境
观测数据关联模型探索
关联模型实践案例

本文提供了完整演讲稿（下面章节）及 AI 总结（文章最后一个章节），并在文章最后附带上了演讲原视频，读者可以根据需求选择阅读。

演讲稿原稿

现在我分享的是我们最近关注的一个点，就是统一观测数据关联模型探索。大家一看这个话题可能会有点懵，接下来我就从以下几个方面来给大家阐述一下，为什么会存在这个关联模型？

第一部分是从监控到观测转型的困境。第二部分是关联模型的探索与构建。第三部分会分享我们在关联模型应用上的一些实践案例。

首先进入第一部分。先开始简单介绍一下我们蓝鲸整个的技术体系。我们的观测平台是属于在整个蓝鲸体系 PaaS 层级的一个部分。从下往上是针对 SaaS、CI/CD 以及 CO 提供一些具体的应用场景，比如说监控指标数据展示，以及日志分析、根因分析等能力。

在横向，PaaS 像有一些 AIops 平台、容器平台、作业平台、集成管理、CI/CD 等等，在整个PaaS 层面进行数据可以打通。这就是我们整个蓝鲸的技术体系，它的每一个组件的能力都是可拔插的，整体则是以蓝鲸企业版作为开源对外。

好，我们先来讲一下可观测整个发展的历程。大家可以看到这张图，现阶段我把我们整个可观测相关的一些技术栈或者说一些软件，包括最近的 DeepFlow 也都放上去了，还有大家比较耳熟能详的 K8s、OTel、Prometheus 等等。

这里面 K8s 出现其实有点突兀，我在这一整张图里面称之为“群星闪耀时”。每一个像这些，甚至像 2010 年的 ES，现在很多团队其实都在使用当中，包括 InfluxDB，然后最近的 CK 等等，都是大家非常熟悉的东西。这里面我大概程度上分成了两个部分。

第一部分是在可观测出现之前，我称之为传统监控以及现在经常说的可观测。传统监控和可观测的区别，其实我总结下来可能就是两个不一样的地方，一个是被动，一个是主动。什么叫被动呢？被动就是 DevOps 分离，开发归开发，运维归运维，监控归监控。

在可观测出现的阶段，我们开发一个项目，打一些日志，做一些监控体系，都是会专门交给一个运维团队去做。出了什么问题，我们需要他们提供一些能力。一直到后面的可观测时代出现，它变为主动，就是 SRE。SRE 的话，就是你就是该服务的可用性工程师，需要对自己的服务负责。即使是作为一个开发者，你也需要在你的可观测性上提供一些像指标、日志，包括 Trace 上报等。这里面为什么说主动？就是因为为了做这个可观测性，暴露出可观测的事情，你需要去做很多自己额外的工作，而不是说你只是单纯地把这个东西上报到某一个地方，或者作为简单的改造。

当然现在在 eBPF 的加持之下，我们可以做很多零侵入的方案来解决上报困难的问题。虽然解决了上报困难的问题，但是基于可观测性的能力，比如说你要配一些仪表盘，配一些 Trace 的具体上报字段，或者在应用层面你希望依然要花很多功夫去做。这就是我认为传统监控跟可观测最大的区别。

然后在这里我也说了，它突然出现了一个叫 K8s 的东西，它其实是象征着一个时代的突然变化。从云原生出来之后，你会发现在后面的一大波，虽然时间很短，但是它的技术革新其实出现了很多变化，很快。像 Prometheus、ClickHouse，以及 OTel、eBPF 等等，都是大家非常熟悉的一些东西。

云原生这个东西就不太展开去说，它更多的是在于提供了一种整个技术领域的标准。里面可能包括现在以前很少出现的微服务这种东西，架构到一定复杂程度，像容器、微服务、网格这些东西出现了之后，所谓的这种可观测性才变得更加重要，并且更加难以用传统的监控方式去观察。

第二部分就是我们蓝鲸观测平台已经做了好几年了，在这几年的过程中，我们基于整个观测场景搭建了那么一套观测体系，有常见的三大支柱，我们现在加了一根第四根支柱，就是事件那块，像指标、Logs、Trace 等等，通过各种统一接入手段上报，统一接入，最后用告警层面对用户进行通知，然后再搭配上层盖上了各种各样的观测场景。

这就是我们称之为可观测大厦，可观大厦里面看起来好像每一个都可以了，你要配指标就是配指标，你要看日志就看日志，你要配调用链就配调用链，每一个都可以用，并且也都能用，能找到问题。但是我们在这个过程中会发现可观测大厦已经建成，但是空中还飘着两朵乌云，我们称之为数据孤岛和故障根因。具体是怎么样的，我们接下来慢慢分析一下。

这是一张普通的微服务架构，真的是非常普通的 SaaS 层调用，中间是一个接入层，接入层里面其实就是两个域名，一个 API 的域名，还有一个普通的域名做了一个简单的分集群配置，中间是有一个 LB 负载均衡，进行流量分配。下面分别是默认服务和 API 服务的 Service 以及内部组件，一个第三方的，你可以理解为是告警模块和查询模块这么一个服务，紫色的是一个告警模块。接下来对应的像 K8s 里面，它结构也是比较复杂，有各自的 Pod 以及一些调度。在 CMDB 层，你有它的主机，包括一些无法通过容器层面去纳管的 Redis、MySQL 等主机调用。

基于这张图，我们每一个 Pod 或者服务都会对应接入对应的一些指标、Trace 以及 Logs，包括之前所做的一些可观测的最佳实践，互相之间有一些关联，比如通过指标去找到一些 Trace，通过一些日志。它这两边的东西其实是一个不同层级，每一个 Pod 有它自己的指标和 Trace 和日志，沉淀下来的话，整个的复杂度会非常高，面对一个简单的微服务架构。我们来问个问题，当一个异常产生时，会发生什么样的情况？

各类指标的一些告警，比如 CPU 升高了，服务重启了，内存可能就是 OOM 了，大量的异常日志，比如访问一些 API 失败了，访问 Redis 失败了，访问 MySQL 失败了，还有一些调用链的耗时、失败率的陡增。这就是我们看到整个接入了这些东西所面临的情况。

这就是我们刚刚提到的困境上的一个点，我们回到可观测的一个目标上来看，整个可观测其实就是为了解决故障发现到故障问题定位的过程，它属于 MTTD 和 MTTR。在这里面故障产生原因有多种多样的，比如发布变更、中间件，或者网络、磁盘。针对这些东西，可能就像我刚刚说的，可能是 HTTP 服务异常，也可能是队列阻塞，或者 CPU 内存高负载，Pod 的重启，查询耗时增加等等，这些所有的东西组成起来就会形成一个信息风暴。之前叫做告警风暴，我在这里用的是信息风暴，因为除了告警，我们还需要通过告警去看到各种各样的指标、日志以及调用链等信息。

这些信息能不能用呢？可以用。这就像我们平常排查一样，一点点去排查，一点点去看，看到哪里有问题，找到最终的问题。看起来疑似是结果的东西，但它可能是原因，不一定是结果。信息有很多，比如我调了一个服务，这个服务请求量直接陡降，但并不代表是因为查询阻塞导致下游服务的问题，也可能是因为上游服务导致异常，导致查询才有异常。所以这里面就会有信息互为因果。

我们观察到，从我们排查的角度来说，也是东排查一下西排查，把这些所有信息放在一起去探索，做一些决策。那么我们就认为这个信息是互为因果，需要关联起来才会产生比较有用的效果。

接下来就回到一开始的主题，为什么我们要去探索这个关联模型的东西？

说到关联模型，就是我刚刚提到的那个微服务架构，一个简单的微服务架构，真正把整个数据拿出来看，可以看到左边是我们的三大支柱，Trace、Metric 以及 Log 等等，互相之间也做了一些初步的关联，通过一些字段，TraceID、Label 等等。右边是我们一个稍微复杂一点的架构，甚至可能在云原生时代大部分人都会用到的一个架构。

首先上层是多云的架构，不同的云厂商有自己不同的产品，像负载均衡、对象存储以及容器，还有一些像 VPC，就是私有网络这种，在不同的区域，比如两地三中心等架构。在这个基础上我可能又觉得不安全，我还需要跨云的部署，那么我就会有像亚马逊、谷歌云等多云的部署，特别是在海外的一些项目，这块是非常常见的。不可能一个云让你去跑，上层的云产品就是比较复杂。

到了 K8s，K8s 看起来好像很简单，一个独立集群，一个 Namespace、Deployment，它内部是有自己管控的。但是大家看一下右边，即使是对于 K8s，现在大家用得比较多的，它可能也还会有多种不同的集群类型，像最近比较火的弹性容器 EKS Service，还有共享的集群，或者联邦集群。稍微规模大一点的容器层级，各种类型的集群都会用到，这取决于公司的策略或方案。

接下来是传统的 CMDB 的东西，CMDB 里面就是我们看到的主机，MySQL、Kafka 等等，它有自己的模块和业务层级。这里我专门标出一个黄色的点 IPv4、IPv6，其实现在我们经常做的一件事，就是 IPv6 改造。本来这事不是一个很大的事，IPv4 对应一个 IPv6，但是在改造过程中，其实要做很多工作，就是我没有办法。之前是把 IP 作为一个 ID 去全局跑，现在突然之间多了一个 IPv6，它不是简单建立一个关联就可以了，需要做很多事情，去做改造之类的。所以这些东西就构成了整个的数据生态，甚至在当下跟未来层面，它可能也是在不断变化，产生一些影响你现在架构的东西。

所以这里总结下来就是不同的观测实体（右边这一块）以及不同的观测数据（左边那一块）。综合下来就是分散的排查流程，这就是我们现在所面临的数据生态。

好，到了第二部分，其实我们要做关联，我们捋下来，拿刚刚的架构图来说，我们现在要做关联，那么我们是不是就简单地把它线连起来就可以了？比如说我们的一个实体资源，黑色这条线是没有方向的，是一个上下的关联关系，并没有说一个方向，说某一个资源是归属于某一个资源。像有箭头的黄色的，它属于流量的一些数据。我需要比如说 MySQL 的流量，通过数据给到告警的 Pod，告警 Pod 再通过查询的模块 Pod 取到一些数据，最终给到一些用户。

这里的关联总结下来，其实右边那一块分为两种类型，大的方向分为两种类型，一种是架构关联，架构关联里面分为两种，一种是资源管控和资源信息关联。第二部分是流量关联，流量关联里面分为网络流量，就是黄色箭头那一块。第二部分是数据流这块，我这里总结的是相当于指标、日志、Trace 等等，在生产过程中或者 Runtime 过程中产生的一些真实的数据流量，在整个数据里面也是起到一个很关键的作用。

好，我们刚刚也讲了要构建这个关联，那么构建关联，我们就一个个来看构建关联要怎么构建。像我们的一个接入层，最简单的就有一个域名，这个东西全网通用，我们把这个域名跟所谓的 LB 关联起来，就认为它是一个关联，构建了一个关联。接下来我们再往下构建，有一个 LB 构建到一个 Service，我们就把这个 IP 记下来，找一张表做个关联。看完这张图，就会发现每一个实体之间，其实都有自己独特的 ID 描述。而且问题是这个 ID 可能是重名，甚至可能只是现在叫这个 ID，过段时间可能又换了一个 ID，像我们刚刚提到的 IPv4 和 IPv6，其实就是一个很典型的特征。你拿了这个 IP 之后，现在做好了关联，过段时间 IPv6 换了之后，怎么办？包括我们的指标、日志等等，都是这样。

如果只是按照这种方式一层层去做关联，是不是就会陷入一个困境，或者无法维护这个东西？这里我又跳回到“群星闪耀时”提出的一个点，那里面有看起来格外耀眼的两个东西，一个叫做 K8s，一个叫做 OTel。它们之所以耀眼，我认为更多的是在于整个的开发体系提出了自己的一个标准。它们开放自己，基于这个标准，我们可以做很多的接入方式。

当然像指标，Prometheus 那块，它也是提出了自己的标准，各个领域其实都有，只是提到这两个点。K8s 层面，我简单讲一下，它提出的一些标准是什么东西，它重新定义了自己的一个所谓的调度单元和执行单元，把它抽象成现在主机的一个关系，在这里就叫 Pod 和 Container。Pod 其实就是一个所谓的进程组，Container 就是单进程，通过这种方式，在上面包了各种各样类型的资源，比如 Deployment、工作负载等等，围绕着最小的调度单位形成了一整块的容器编排模式，这是第一个 K8s 的标准。

第二个 OpenTelemetry，我这里提了两个点，也是他们之前这个 OpenTracing，有了一个 Trace 和 Span 的概念。Trace 代表一次完整的请求调用，Span 是指每个完整的请求里面每一次的请求调用。他们把这些概念抽象出来之后，是不是在后面只要有类似的加入，比如有一些体系的介入，就可以基于这个标准去做一些合作，适应现在的一些网络模式。

所以我这里下了一个总结，构建关联需要先定义关联标准。你这样一个一张张表去关联是不行的，一定是要基于某种标准，去思考一下这个标准是怎么样去适配到这个东西。

这里思考第一个点，就是怎么定义资源。我们先来看一下上面被遮盖的三个，其实都是 LB，LB 第一个是一个外网的 LB，有一个公网的 IP，那么拿这个 IP 是不是全网都可以唯一识别到它就是这个 IP？所以这个 IP 就是它的身份 ID。第二个，这个 IP 会加一个 Cloud ID 的东西，这会在多云的场景下，这个 IP 只在你这个云里面是唯一的，跨了一个云可能不唯一了，就多了一个 Cloud ID 的东西。第三个是私有网络的 IP，就是内网的 IP，可能在 IP 之外，还有域名，可能还有你所归属的 VPC。即使是一个 LB，它在不同的场景或者不同的应用层面，规则也是不一样的，那么我们是不是可以都称之为 LB？

它其实是 LB，但又不是 LB，就像人都可以称之为人，但是可以有白人、黑人这种。我们要定义的其实就是说在用的时候，需要他是什么样的一个人？比如在做一些运动会的时候，只要是个人就行，但是如果是在做国家运动会，他人上面必须要加一个国家，他必须是中国人或者美国人，才能代表他这个人在整个运动会里面所承担的角色。整个资源定义其实就在做这样一件事情。

包括后面举两个例子，两个 Node 也会不太一样，一个是容器集群里面的一个 Node，这个 Node 在容器集群里面有一个 Node Name，但并不代表就是它的 IP。到了后面那个 Node，是 CMDB 层面的一个 Node，有它的 IPv4、IPv6 和 IDC 等等。

总结下来，我总结了三点，这个资源必须具备三个属性，一个是唯一性、可读性和扩展性。唯一性很好理解，就是拿这个资源，就知道这个资源在当下具备唯一的身份 ID，只要它发生任何关联，就可以识别出它来，而不是说这个东西就跟一群人做关联，只是跟你做关联，发生了这个运动行为。

第二个是可读性，就是通过定义了这个资源之后，明确地知道这个资源是在干什么的，值得具备一个识别。就像我刚刚举的例子，像中国人是有中国和人这两个属性。

第三个是可扩展性，也是我刚刚一直在提到的一个点，拿 IPv6 来举例，就是一个主机之前是 IPv4，要扩展它 IPv6，这是一个很大的工作量。但是如果设计的时候具备扩展性，这个身份在不同场合上变化了之后，就可以以扩展性的方式重新适应这个身份。

具体的实例就在下面，当你是一个外网的 LB 的时候，只需要一个 IP，但是当你是一个跨云的 LB，我们在你原先的一个资源里面构建一个资源，那么它的资源会新增加一个 Cloud ID 的属性，同时构建一个云的资源类型叫 Cloud，一个资源类型。同时私有网络也是一样，构建了一个私有网络的资源，它有自己的 VPC，有自己的 IP，那么 VPC 就是属于它，VPC 加 IP 就是它的唯一身份 ID，再构建一个叫 VPC 的资源，形成了这一整个资源的描述。下面也可以看一下主机，这个主机之前定义了一个叫 System，它的 IP 可能就是一个 IPv4 的 IP，这时候突然之间有了 IPv6 的诉求，那么就新增一个 IPv6 的实体，再通过这个 IPv4 和 IPv6 把它们作为一定的关联，形成了这两个身份的互换，这是在资源定义上的一个思考。

刚刚一直在讲的是实体资源的定义，我们回到数据流的定义。左边是拿到的一个指标里面的一个 CPU 使用量的指标，它的指标就是向 cadvisor 那边去采的。看起来是一个容器的指标，为什么这样说呢？因为有 Container 的维度，有 Pod 的维度和 Namespace 维度以及 Cluster ID 维度。这个指标我们就认为它是归属在 Container 里面，在描述的事情，就是 Container 的一个指标的 CPU 使用量，在描述这个 CPU，只有 Container 这个 CPU。

但是我们在使用过程中，包括在配一些仪表盘告警的时候，不是直接配这一个指标的，是通过聚合算法去配的。比如要继续算这个集群的总 CPU 使用量，就是下面第三行这个 sum，然后 by 一个 Cluster ID。那这个时候称之为这个指标还是这个 Container 的资源的归属，那么显然是有问题的，因为它表达的是这个集群的 CPU，所以更多的去归属在集群那一层。

这一整下来，对于数据流层面的定义，我们就是说数据流不取决于原先的数据流是长什么样子，而是在使用检索或者策略，在聚合计算的过程中，把它当做什么类型的指标，什么类型的资源类型在使用，那么它就是什么样类型的资源类型。就像上面的，如果指标维度里面保留了 Container、CPU、Pod、Namespace、Cluster ID 等等，它就是一个 Container CPU 的指标，就是在描述 Container 的 CPU 的一件事。如果只保留了三个维度 Pod，那么就在描述这个 Pod 的 CPU。如果只保留了一个 Cluster ID，那么在描述的就是这个集群的 CPU，这就是我们对数据流的定义的标准。

到了第三步，我们刚刚所提到的资源定义的标准，包括它的关联就可以直接去做关联，这些东西都有了之后，我们还需要再看一个场景。现在这个场景就是一次简单的变更，一个 Pod 的变更，可以注意到这里是一个 Query API Service 的重启，它的 Pod 就已经不再是原先那个 Pod，它原来叫 Pod1，现在因为重启之后变成了 Pod2，同时这个节点调度在了 127.0.0.4 的节点上面。那么它也就是发生了变化。

就我们刚刚所提到的所有的关联模型，它都有一个暗含的点，就是跟时序是强关联的。如果这个模型不是一个时序的，只是一个实时的，现在这个时候就已经不存在所谓的观测的意义了。所有的观测，都是当下以及未来，甚至以前都是需要在观测整个体系里面去表现的。所以右上角我也提到了，有了这些数据，才能进行复盘定位分析和对比。如果只是因为拿当下的关联关系，去算出来当下的结果，然后再给到之后，后面的所有复盘对比，都没办法去做，只是有一个结果，但是这个结果根本不知道是怎么样去产生的。

好，然后这里会有一个重点，第一个是在讲一个图模型，就刚刚所说的关联模型，有一个资源定义以及资源关联。然后第二个是时序的模型，把这两个合并起来，其实就是我们现在所需要的数据关联模型。这里面我们有考量两个技术方案。

第一个是先构建一个图模型，然后再通过图模型按照时序的方式去构建快照，每个时序时间片的切片，形成一个时序的概念。第二个方案是基于现有的时序存储再加查询建模。最后我们选择的方案其实有很多数据上的考量，主要是对整体的分布式数据存储的问题。像现在图存储，现在可用的一些引擎，分布式引擎，并不存在一个时序的能力，而且在快照的过程中，其实是基于一个超大的模型去做快照，这对于我们的处理来说是有很大的瓶颈。

然后这里就是我们最终基于刚刚的标准，以及加了一些内置的关联，建了两张表，一个叫资源类型表和关联关系表。右边就是我们基于这个内置指标，内置了主机的一些资源，还有主机跟节点是什么关联的，Pod 跟 Node 是怎么关联的，把每一条线都串起来，形成了整个的关联模型。

这里特别讲一下对于 eBPF 的数据，可以举个简单的例子，eBPF 在左上角，有一些 Pod 互相之间互访，比如 Web Pod 访问 Query 的一个 Pod，右边根据这两个数据的类型，构建我们刚刚标准上面定义的需要一个模型，比如一个 Flow 关联模型以及资源模型，它是一个 Pod 模型和一个 Node 模型。构建完之后，最后再生成一个 Pod_to_Pod_Flow 的关联指标，最后就是把 eBPF 和数据纳入到我们刚刚的关联模型。

然后刚刚也提到有一个关联的建模能力，这块能力其实是我们选择第二个方案，拿一个时序数据库，再加一个查询建模，然后图计算这块的东西。左边是关联数据，我们建了一些 Relation 数据，在图层面其实就是一个个边、一个个顶点。上层有一些顶点和边的定义，下面通过指标类型去区分它是有向还是无向。最后我们在图计算引擎里面构建了一个数据的模型和类型模型。最终达到的目的就是在任意时间、任意关联的目标信息，我们都可以通过这个查询引擎去查到。第二部分，任意时间的任意资源的拓扑关系，主要目的是为了实现这两个查询。

好，最后我们也是在向总的 DeepFlow 层面，通过他们去把整个 eBPF 的数据接入到我们的关联模型里面，主要是从 DeepFlow Service 直接到我们的 Collector，走了一个 Kafka，写到了我们刚刚的数据关联模型里面。

最后这就是模型的最终形态。左边是架构层面的 CMDB，包括云的，还有 K8s 的，以及应用层面的一些架构数据。右边是流量，像指标、日志、Event、告警等等，因为我们做了这个关联的标准模型，所以像有很多第三方的，像刚刚 DeepFlow，就是以第三方的标准形式接进来的，还有一些其他的第三方数据，最后再形成一个基于我们的查询的图计算引擎做的一个叫做 Time Series Relation Model 的查询的时序图引擎。

好，刚才讲了很多枯燥的实现过程，我们直接来看一下实践的案例。这里是我们的一个全景视图，这个全景视图说实话也不太全，因为这块我们也是在半探索、半实践的过程中，底层实现都已经完全实现了，都 OK 了。在上层，我们要根据用户的一些场景去做更多的探索以及展示。

这里是我们现在构建的全景视图，有一些资源拓扑、网络拓扑，以及这个资源的 Pod 或者这个 APM，这个应用对应的一些指标、日志、事件、告警等等。还有我们后面也会有变更日历，就是把变更以及 CI/CD 整个全部串起来，通过刚刚标准关联的方式加入到我们的体系里面。不管是从 Pod 层级，还是从应用层级，或者从业务层级、服务层级，都能看到自己的拓扑关系，后面还会再加入一个服务版本的概念，这就是我们的一个全景视图。

接下来再讲一下，我们最终一开始标题上提到的故障归因里面的一个应用，这里其实就是我们用混沌工程注入了一个 Redis 的 Debug 服务，导致它无法建立连接，模拟了 Redis 的服务端连接异常。这里告警层面是向 BigBase MetaData Meta API 那一层发起的，会触发一个告警。在这里，我们通过我们的 AI 大模型，以及我们刚刚的关联数据模型，去进行计算，计算完之后就可以获取到这个根因是 Redis 出现了故障。同时通过这个分析也能看到这个服务挂了之后，影响的上游是怎么样的一个情况，它有一个上游的 Ingress Nginx 服务，再往上也会有其他的一些关联。

好，然后我们再进入一个故障详情的展示，这里是一个故障指图，刚刚也讲了最终影响的范围是怎么样的，比如下面有些服务挂了，上面是根因，但是有很多服务在调它，那么它就自然而然变成一些红色的，包括有些依赖的服务。这里就是说可以一目了然看到一些影响范围。

第二部分是聚合加时间回溯，刚刚我们一直在讲为什么要加入时间的概念，基于这个故障，可以重新再基于现在的发生和未发生之间重新做一个故障回溯，看到整个故障发生场景是怎么样的，可能是因为一次变更，或者是调度，或者因为一个 Pod 重启等等。这里也会关联一些异常指标，包括我们后面也会加入一些日志事件等，因为关联信息量其实比较多，我们在做一些界面展示，或者在一些产品落地化的时候会做一些取舍。

AI总结

统一数据管理模型的探索

近期，我们重点关注了统一数据管理模型的探索。这个主题可能初看有些抽象，下面我将从多个角度详细阐述其背景和意义。主要内容包括：

从传统监控到可观测的转型困境
关联模型的探索与构建
关联模型的实践案例分享

第一部分：从传统监控到可观测性的转型困境

技术体系简介

首先，介绍一下我们蓝鲸的技术体系。我们的观测平台位于整个蓝鲸体系的 PaaS 层，向上为 SaaS、CI/CD 和 CO 等具体场景提供支持，如监控数据展示、日志分析、根因分析等能力。横向上，PaaS 层与 AI OPS 平台、容器平台等进行数据层面的打通，实现了在作业平台、配置管理、CI/CD 和告警等应用层面的数据互通。整个体系的各个组件均具备可插拔性，整体以蓝鲸企业版的形式开源对外。

可观测性的发展历程

在可观测性的发展过程中，我们整理了相关的技术栈和软件，包括近期的 DeepFlow、广为人知的 Kubernetes（K8s）、OpenTelemetry（OTel）、Prometheus 等。Kubernetes 的出现标志着云原生时代的到来，引发了技术的快速迭代，涌现了诸如 ClickHouse、VM 等众多新技术。

我们将整个发展过程分为两个阶段：

传统监控阶段：开发、运维和监控彼此独立，开发人员专注于代码，运维团队负责部署和监控。当出现问题时，依赖运维团队提供支持。
可观测性阶段：强调主动性，出现了 SRE（Site Reliability Engineering）角色。开发者需要对自身服务的可用性负责，主动在代码中集成指标、日志和追踪信息，即使借助 eBPF 等技术简化数据上报，仍需在应用层面投入大量精力配置仪表盘、追踪字段等。

转型困境

在向可观测性转型的过程中，我们面临以下困境：