从MWC 2026看智能可观测底座：统一数据链路与智能分析

1. 巴塞罗那现场可观测性厂商为什么成了 MWC 的显眼包MWC 的展馆每年都挤得不像话但今年的热闹和往年不太一样。以前大家围在终端厂商的展台前看新手机、看芯片参数今年我在 4 号馆和 5 号馆之间来回走了两天发现一个非常明显的变化可观测性厂商的展台前面排队等着交流的人居然比旁边不少设备商还要多。观测云这次出现在 MWC 2026 的现场展台布置不算最豪华但过来问问题的人几乎没断过——有欧洲本地的运维负责人有做跨境业务的技术总监还有一些是刚从监控体系要不要全部推倒重来的讨论中走出来的架构师。这个现象背后其实藏着一个行业共识当业务系统越来越分散、多云混合架构越来越普遍大家缺的不再是某个单点监控工具而是一个能覆盖全球节点、统一处理指标、日志、链路数据的底座。可观测性正在从出了问题再排查的被动手段变成提前感知风险、快速定位根因的主动基础设施。观测云这次喊出的打造智能可观测底座恰好切中的就是这层需求。1.1 从设备联网到业务可观测展区热度明显转移前几年 MWC 上聊得最多的是联接——设备怎么连上网、网络切片怎么做、边缘节点怎么部署。今年我发现话题重心明显变了大量参会者开始追问联上网之后业务跑得稳不稳多云环境下出问题到底该看哪个平台的监控告警一天几千条怎么找到真正需要处理的那几条。这些问题的本质已经从有没有监控变成了可观测能力够不够强。尤其是一些做全球业务的展商他们自己内部的监控体系往往由四五套不同厂商的工具拼凑而成基础设施用一套云原生用一套业务指标再看另一套。每一套都能看到一部分数据但数据之间没有关联出问题的时候反而更难定位。我现场和一位做跨境物流系统的架构师聊了聊他说自己最大的痛点不是没有数据而是数据太多且割裂故障发生时根本不知道先看哪个屏幕。1.2 观测云展台现场他们到底演示了什么观测云在 MWC 现场的核心演示场景给我印象最深的是一个模拟的跨境业务故障定位流程系统模拟了三个区域节点同时出现访问延迟波动展台工作人员在统一界面上拉出一条从用户端到后端服务的完整调用链很快就把问题定位到了某个区域节点的某个数据库实例上。整个过程没有切换任何工具指标、日志、链路在同一页面完成了交叉关联。这个演示看着简单但内行都知道要做到一条链路贯穿所有环节其实很难。它要求底层的采集器能够覆盖主机、容器、Kubernetes、中间件、数据库、消息队列等各类对象同时还要把不同来源的数据统一规范成可关联的模型。观测云在展台上重点展示了统一采集器 DataKit 的接入方式以及基于 OpenTelemetry 生态的兼容能力。也就是说用户已有的探针和数据格式不需要全部推翻通过标准协议就能接入到一个统一平台里。2. 智能可观测底座不是营销词数据、链路、分析三层架构拆解可观测底座这个词这几年被喊得有点泛滥但真正落到工程层面它至少要解决三个层次的问题数据能不能采全、采到的数据能不能用、用了之后能不能快速产出结论。观测云这次展示的架构基本就是按照这三个层次来设计的。我从现场技术人员的讲解里提炼了一下跟我自己平时的工程经验对照发现很多设计逻辑是经得起推敲的。2.1 数据采集层统一 Agent 和 OpenTelemetry 生态的对接逻辑先聊采集层。这是所有可观测性平台的地基地基不稳上面全白搭。观测云的做法是通过一个统一采集器 DataKit 去覆盖主机、进程、容器、日志文件、应用性能等所有可采集对象而不是像传统监控工具那样每接入一种数据源就要部署一套独立的 Agent。这个设计的好处非常直接。我记得以前帮客户做监控体系梳理时一台物理机上最多能跑七八个不同厂商的采集进程资源占用高不说版本冲突、端口冲突都是家常便饭。统一 Agent 至少能把一个采集器采所有数据这件事落地从运维角度看能省掉不少管理成本。更重要的一点是对 OpenTelemetry 生态的兼容。现在越来越多的应用通过 OpenTelemetry SDK 做埋点如果可观测平台不支持标准协议用户要么改造代码要么放弃已有埋点。观测云在协议层直接兼容 OTLP意味着开发团队以前埋的点、打的 Span 都能继续用只需要把导出地址指向新的平台即可。这看起来是个很小的技术决策但实际落地时能省掉大量迁移成本。我在展台旁听到有参观者专门问我们现有系统如果要迁过来代码要动多少工作人员的回答是埋点不用改改一下 exporter 配置就行。这个答案对很多团队来说就是定心丸。2.2 数据处理与存储层指标、日志、链路如何归一化采完数据之后接下来考验的是平台的“消化能力”。指标数据量相对可控但日志和链路的数据量往往非常惊人。一个每天几亿条日志的业务系统如果平台没有高效的压缩和采样策略存储成本会直接爆炸。观测云在存储层的设计思路是把指标、日志、链路三类数据统一到一个数据模型里然后在最底层做标签索引和字段归一化。这样做的一个直接好处是用户可以像查询指标一样去筛选日志也可以从一条链路直接跳转到某段日志的上下文。这种交叉检索能力在传统“日志系统归日志系统、监控归监控”的架构里是做不到的。另一个值得提的是采样策略。全量采集链路数据在任何规模下都不现实观测云给出的方案是头尾采样加关键业务全采的组合策略——健康请求采样一部分用于趋势分析慢请求和异常请求则全部保留用于问题定位。我现场问了一下这个策略能不能配置答案是支持的。对于做大型分布式系统的团队来说这个能力很实用因为你既不想丢失异常现场也不想为每一笔正常请求都付出存储成本。2.3 智能分析层告警降噪、异常检测和根因分析的实际效果以前每次参加技术大会一提到 AIOps 我就有点条件反射式的怀疑因为市面上太多产品把“智能”做成了一堆炫酷大屏。但这次观测云演示的智能分析能力我至少看到了几个能落地的场景。第一个场景是告警降噪。系统会自动把相同时间窗口、相同服务、相同错误码的告警聚合成一条事件再根据影响范围排序。这个功能听起来简单但在大规模环境里效果立竿见影。很多团队的告警一天上千条真正需要人处理的其实只有几条其余都是同一个故障衍生出来的“告警风暴”。聚合和收敛之后值班人员才能把精力放到真正重要的事情上。第二个场景是异常检测。传统监控阈值是人工配置的配置太严容易误报太松又漏报。观测云的异常检测会基于历史基线做动态判断比如某接口的响应时间平时在 50 毫秒左右突然涨到 200 毫秒即便还没超过固定阈值系统也会发出提示。这在流量波动的业务场景下特别有用因为静态阈值根本不可能适应全天候的潮汐变化。第三个场景是根因分析。这一块目前各家做得都比较谨慎观测云的演示也比较务实不做全自动的AI 替代人的承诺而是把嫌疑对象按置信度排序列出关联的日志和链路证据由人来最终判断。我觉得这是目前技术条件下最合理的产品形态——AI 负责缩小排查范围人负责最终决策。3. 布局全球这件事工程层面远比想象中复杂观测云这次在 MWC 上强调的是布局全球这个口号听起来大气但真正要把可观测服务卖到全球、同时在多个区域稳定运行工程量非常庞大。我在现场和他们的技术人员聊了一些细节结合自己做过的跨境项目经验这部分展开讲讲。3.1 全球节点就近接入与数据回传路径设计可观测平台要服务全球客户第一个要解决的是数据接入问题。如果客户在法兰克福有节点数据却要传到某个亚太区域的处理中心中间必然产生很高的延迟采集和上传本身就会影响业务更别提一旦链路不稳定监控数据还会大量丢失。观测云的思路是在全球主要区域部署接入节点让数据在离产生位置最近的节点完成采集、清洗和初步聚合然后再按照配置同步到中心集群做统一分析。这种就近接入、分层汇聚的架构在数据工程领域不算新鲜但在可观测领域能真正落地的厂商并不多因为每个节点都要保证独立的可用性和扩展能力运维复杂度是成倍上升的。做全球业务的技术团队应该都有体会跨国专线的稳定性永远是个玄学任何一个区域的网络抖动都可能影响可观测数据的完整性。所以平台必须在采集端做本地缓存和重试机制——数据暂时传不出去时先存在本地等网络恢复后再补传。观测云的 Agent 端就内置了这种能力。我在展台了解到这个细节时还是有点感慨的很多自建监控体系的团队恰恰是忽略了这一步导致跨国网络一抖动数据就出黑洞。3.2 多区域数据合规与数据驻留的工程应对这个话题在展会上几乎每个做跨境业务的参观者都会问到。不同国家和地区对数据存储位置、数据出境都有各自的合规要求可观测平台作为承接业务运行数据的载体必须在架构层面就支持数据驻留——某个区域产生的数据可以只存储在该区域不同区域之间的数据做到逻辑隔离甚至物理隔离。观测云现场展示的多区域架构方案有一个设计我觉得很务实控制台是统一的数据存储是分区的。客户可以在同一个账号下管理全球所有节点的监控数据但每个区域的数据默认保存在本地只有客户主动配置同步任务才会跨区域汇总。这样既满足了合规要求又没有牺牲管理上的统一性。注意一点这里说的合规不是有没有证的问题而是架构上能不能做到数据不出域。有些做全球业务的客户内部审计流程非常严格如果平台连区域隔离都做不到产品再好也进不了他们的采购名单。所以说到底全球化的可观测底座表面看是品牌和节点的问题本质上是一个数据主权边界的工程问题。3.3 跨国网络环境下数据采集的可靠性保障我特别想分享一个自己踩过的坑曾经帮一家出海企业搭监控系统他们在东南亚、欧洲、美洲都有节点采集器也部署了结果发现美洲节点的数据频繁丢失。排查了很久才发现是因为采集器到中心集群的长连接在跨洲链路上经常被中间网络设备重置而采集端的默认配置里没有重连和数据补偿机制。所以在可观测平台的全球化架构里采集器与中心端的通信协议设计非常关键。观测云的方案是采集器与接入节点之间保持短连接加批量上报同时本地磁盘缓存未发送数据网络恢复后按时间戳补传。短连接的好处是每个请求独立单次失败不影响后续数据批量上报的好处是降低请求次数减少网络开销本地缓存则是最后一道保险。这里也给正在自建监控体系的团队一个建议选型时务必问清楚采集器是否支持网络异常时的本地缓存和断点续传这比多关心几个花哨功能重要得多。全球网络环境永远不会像你想的那么稳定数据采集链路一旦断裂后面所有的分析、展示、告警都成了无源之水。4. 从展会 Demo 到生产落地可观测平台选型与迁移的实操建议展台 Demo 做得再漂亮回到自己的业务环境里能不能落地才是真正考验。我在现场听了不少参观者与观测云技术团队的问答结合以往帮企业做监控体系建设的经验把几个高频问题和自己的判断整理一下。4.1 现场交流中大家最关心的三个问题第一个问题出奇一致:我们现在已经有 Prometheus、ELK 和 Zipkin 三套系统了迁到统一平台会不会很麻烦这个问题其实反映了目前大多数团队的现状——工具链不少但各管一段。从技术角度看Prometheus 的指标可以通 OpenTelemetry 或远程写协议接入ELK 的日志可以通过标准日志采集方式对接Zipkin 链路可以通过 OTLP 上报。迁移的重点不在于数据怎么搬而在于同一套标签体系怎么统一。如果各系统里对同一个服务的命名都不一样即便数据都导进了一个平台关联效果也会大打折扣。第二个问题是关于成本的:按量计费的话日志量这么大用得起吗这也是可观测平台落地时最现实的问题。观测云的按量计费模式好处是用多少付多少不像传统商业监控软件那样上来就是一大笔 license 费用。但我建议团队在接入前先做一次数据量盘点哪些日志必须全量留存、哪些可以降采样、哪些其实可以直接丢弃先在采集端做好治理上平台之后成本才会可控。平台再便宜也架不住无意义的全量数据往里灌。第三个问题是关于自建和 SaaS 的选择。有自己的机房和运维团队的企业往往倾向于私有化部署但做全球业务、希望快速开箱即用的团队更偏向 SaaS。观测云两种模式都支持这也符合目前市场的实际情况。我个人的看法是除非有严格的数据隔离合规要求否则中小团队优先考虑 SaaS把运维平台的精力省下来投入到业务系统本身性价比更高。4.2 可观测平台落地时最容易踩的坑第一个坑是没有统一标签规范就直接接入。标签是关联数据的纽带但很多团队接入平台之前没有梳理清楚服务的命名规范、环境标签的划分标准。结果数据一进来同一个应用在测试环境和生产环境混在一起排查的时候根本分不清。我的建议是在正式迁移之前花一到两周时间和开发、运维一起把服务目录和标签规范定下来这件事看起来费时间其实是整个落地过程中性价比最高的投入。第二个坑是盲目追求全量采样。有些团队一听可观测就觉得什么数据都得采结果存储成本暴涨真正排查问题时反而被海量噪声淹没。合理的做法是分场景制定采样策略:核心交易链路全量留存边缘业务和低频接口按需采样DEBUG 级别的日志只保留短期。观测云的控制台里提供了比较灵活的采样配置但关键是用户自己要清楚哪些业务是核心业务。第三个坑是告警规则直接照搬旧平台。原来的监控体系里很多告警规则是从业务系统上线时就定下来的阈值早就和实际运行情况脱节。接入新平台之后如果原样迁移等于把狼来了的游戏继续玩下去。比较好的做法是借着迁移的机会做一次告警规则的全面梳理指标是否还有效、阈值是否合理、是否需要关联上下文。观测云的智能告警降噪前提也是告警规则本身先符合实际业务否则再强的聚合算法也救不了本来就错的规则。5. 我在现场的几个判断与思考逛完 MWC 2026 的可观测板块最大的感受是这个赛道已经过了要不要上的讨论阶段大家的问题都变成了怎么上、怎么用好。这本身就是行业成熟的表现。5.1 可观测性正在从工具链变成基础设施以前很多公司把监控当成一个配套工具运维团队自己维护一套 Prometheus 加 Grafana 就觉得很够用了。但这一两年随着业务系统拆得越来越细、容器实例越起越多、云厂商越来越分散传统监控手段的局限性愈发明显。我在展会上遇到好几个来自不同公司的运维负责人反馈其实都差不多不是不想继续用开源组件而是开源组件组合起来光维护成本就吃掉了一个人力。可观测平台替代自己拼装工具链正慢慢从一种选择变成一种必然。这也意味着可观测性未来会像网络、存储、计算一样成为企业技术架构的基础能力只是这个能力其他基础设施不太一样——它横跨所有层是唯一能贯穿用户端、应用、中间件、基础设施的全局视角。谁把这个底座做得越稳、越智能企业在面对业务快速增长和系统复杂化时就越从容。5.2 AI 能力在可观测场景的落地节奏这次展会看下来几乎每家可观测厂商都在讲 AI但大部分还停留在AI 助手帮你查日志的功能层。真正让 AI 发挥价值的方向应该是异常检测、根因分析、告警降噪这类需要它从海量时序和文本数据中找规律的任务。观测云演示的智能分析能力显然就是在往这个方向走。不过我也要保持一种审慎的乐观。AI 在可观测领域的落地最大的瓶颈不是模型不够聪明而是数据质量不够干净。如果多套系统之间的数据没有打通、标签体系没有统一AI 能基于的分析素材就是割裂的。所以对于大多数企业来说现阶段更实际的做法是先把底座的数据统一工作做扎实然后逐步引入 AI 能力而不是一开始就把希望寄托在一个全自动智能运维大脑上。说回这次 MWC 的收获。观测云选择在 MWC 这样的全球化舞台上系统性地展示智能可观测底座对行业来说其实是个很有意思的信号可观测性已经不再是互联网大厂的专属玩法它正在下沉为每一个出海企业、每一个多云架构团队的标准配置。如果你所在团队的监控体系正处在各路工具各自为战的阶段不妨趁这次展会后的热度认真评估一下统一底座这件事——越早动手后面的路越好走。