作为工程师，我想要的可观测性平台

最近两年，我看到可观测性的话题非常火热，各大技术社区都在讨论什么是可观测性，如何上可观测性。当然也有很多观点觉得所谓的可观测性又是新瓶装旧酒，只是再把传统的监控炒作一番，起一个新的概念忽悠而已。这些讨论不仅仅存在在中文技术圈，也广泛的存在海外的技术圈里。

那么到底什么是可观测性，为什么需要构建可观测性呢？我通过这些年一些实际项目的实践，略有心得，想以本文抛砖引玉。

从传统监控的构建思路开始说起

大家知道一句话，无监控不运维，监控系统是伴随着 IT 技术发展一直在进化的，从主要面向物理设备监控的 Zabbix，到适用于云原生基础设施的 Prometheus，面向应用的运维衍生出了 APM（应用性能监控），面向网络有 NPM（网络性能监控），面向用户体验有 RUM（真实用户监控），面向日志又有 ELK、Splunk 等，以及其他适用于各种细分场景的工具。这些产品的出现说明用户的需求是能覆盖整个系统的监控，以更好地运维。这些技术或者产品都经历了几十年的发展，累积了很多成熟实践方法论与价值，大多企业在采购或者建设监控平台的时候会参照这种模块化组装的思路。

然而，仔细思考后就会发现，其实监控平台的本质，就是分成了四个核心组件：数据采集、数据存储、数据分析和数据使用，所有的监控平台都遵循这个逻辑。比如 Prometheus，就是通过定义 Exporter 的数据结构，先以轮询抓取方式采集监控指标数据，存放到自有的时序存储里，再通过 PromQL 或者连接 Grafana 进行数据的分析，最后用 Alertmanager 检测数据并推送告警？同理，所有的日志系统，不也是通过采集器收集数据，统一存储，然后再进行分析和告警么？APM，NPM，RUM 都是一样的结构。

这几年随着云原生化和微服务化的普及，运维团队也好，研发团队也好，为了监控这件事情，持续投入了很多精力。小公司可能有个 3-5 套监控系统，大公司甚至有 10 套或更多的监控系统，我看到大家都在努力地构建更多新的监控平台去应对更多新的系统问题。

所有系统的运行状态数据，代码执行的过程数据，用户行为数据都会客观产生，监控平台并不是凭空制造出这些监控数据，只是尽可能地去记录和分析这些事实数据而已。

我们为什么不把客观数据保存在一起？

那么再来看各种监控平台采集到的数据，是不是都遵循这样一种数据结构，以尽可能真实地记录被监控对象当时的状态：即以时间为最主要的索引，叠加标签列和不同的 Payload。对于 Prometheus 来说就是指标，对于日志系统来说就是代码打印的日志文本，对于 APM、 NPM 或 RUM 来说也是类似的数据结构。

那我们为什么不把这些相似结构的数据保存在一起？

事实上也不是没有人做过，一般主流有两个方向：

第一个方向，是构建所谓的监控数据中台。比如有公司用大数据的处理方式来解决数据统一的问题，通过各种技术手段，将数据从各种监控工具同步到一个数据平台。但这种方式存在几个巨大的问题：1. 所有数据都要经过 ETL（不管是异步还是实时） 才能以相对统一的结构存储到大数据平台，等于将数据又另存了一份，增加了存储成本；2. 当所有的监控数据汇聚到集中数据平台以后，能做什么呢？好像也只能用于一些报表和大屏，变成了展示给管理者看的一个东西（或者管理者对这些枯燥的数据根本不感兴趣），那还不如直接展示业务数据来的直观。所以相对来说，这种方式的投入产出比就太低了。

于是，大家开始了往第二个方向尝试，从消费效果上统一。从效果上看，最终对监控平台的消费就是看报表和告警，但是不同的监控平台有不一样的数据看板样式，也有独立的消息通道，得一个个切换着看数据仪表板，也得从一堆通道里接收告警，能不能都统一了？于是又有了通过 Grafana 这样的工具实现统一大屏展示，和通过大数据的方式，实现聚合通知，将告警事件合并。虽然没有聚合源数据，但统一了输出效果，看上去也挺不错的。然而新的巨大的问题是每当新增加一项数据时，就得想办法安插进效果平台里，更要命的是根本无法预测这些新数据的字段类型。可以想象下玩俄罗斯方块的场景，当产生新形状的速度越来越快时，来不及合并消除，整个系统会不可避免地向增熵发展，最后变得千疮百孔，直至 Game Over。

为什么没有去简化这一切？

那回到问题的开始，既然所有的数据都长得差不多，为什么不从一开始就统一建模，然后用一个统一的平台去管理所有的监控数据？我们可以将所有的数据统一采集（这很关键，所以现在开始流行 One Agent），用统一的结构，存到一个统一的存储里，那之后无论是做数据分析，或是检测告警，不都是水到渠成的事情吗？甚至在此之上，还能利用 Tag 的一致性，关联上业务标签，挖掘出更多数据价值。

实现用统一的数据了解系统的整体运行状态，再利用这些数据进一步开发出更高维度的数据应用，让开发、测试、运维和运营都能使用，我认为这才是构建可观测性的真正价值，也是我想要的可观测性平台。

当然这件事情并不简单，得先有一套完整并统一的数据采集体系，还要有一个可以处理所有监控数据的平台，它们的功能除了要承担传统的系统监控任务以外，还需要有能力做数据治理和数据挖掘，构建复杂度相当于一个大型的实时数仓。这个数仓还要能同时服务于多个职能团队，满足一些完全不同的用户，比如处理系统故障告警的运维团队，和处理用户业务流程阻塞的运营团队，他们所关注的数据逻辑会有很大差异。我看到现在很多所谓的可观测性平台，只是简单做了一些监控系统的 UI 缝合，运维用着都费劲，更别指望能提高组织的工作效率了。

真正的面向可观测性的平台

很显然，设计和使用一个可观测性平台的过程，会是先难后易。在设计阶段，这个平台必须具备以下的特征：

首先，我们需要有一个真正意义上可以将各种数据统一采集的 Agent，它必须是能覆盖基础设施、云原生、各种技术栈和各种应用系统的，不仅仅要有能力采集数据，还能支持在采集过程中完成对于数据的结构化，标准化的治理。

接着，我们需要一个真正意义上面向可观测性数据存储分析的统一的数据仓库，它可以高效地处理所有的可观测性的信号数据，如指标，事件，日志，调用链等等，有强大的在线分析能力。 2022 年国内曾有百仓大战的盛况，但我看到能存活到今天的，并且适合做可观测性平台数仓的产品并不多。不是因为它们的性能不够，问题恰恰是太超出了，增加了成本。大部分数仓产品是按照电商平台对 CDP 要求设计的，能满足 RTA/RTB 的毫秒级别响应，但若用作一个可观测性平台数仓，会更多考虑如何降低成本，以及考虑如何横向打通业务数仓，作聚合视图。

然后，我们需要一个统一的且友好的互动界面，来实现对上述数据的使用和可视化操作，包括配置告警条件，设置告警通道、生成仪表板甚至发布协同任务等，最好都能在同一套界面风格和脚本语言里操作，比如全部统一成 PromQL，也要把功能标签都统一掉，就说「标签」这个词本身，我见过叫 label、lable 或者 tag 的，要是在同一套系统里随机出现不同名词，这谁受得了。

最后，我们还要需要一套可自定义的数据开发工具，来扩展可观测性数据的使用边界，比如打通与业务数据的关联，盘活数据资产，更好的服务于业务。

做到这些很难吗？好像是挺难的。但我相信我会很习惯去使用这个平台，就像哪怕几行简单的文字，我也习惯用 Notion 来处理，而不是 VI，哪怕后者看上去更简单小巧，前者略臃肿庞大，但又怎样呢，Notion 可以让我的文字更有价值，有了 Ask AI 后，我更离不开它了。

面向未来

做到这一切以后能做什么呢？想象一下，我们相当于拥有了一个完整地全方位地观测整个系统的能力，具备了远程 Debug 任何代码的能力，我们不需要在故障发生后，再想办法去重现这个故障，现在只要调取故障发生时的所有状态数据，还原现场就行了，这才是真正能帮助开发人员提升效率的做法。而这只是开始，利用这些数据，我们能更好地通过数据去自动化调度我们的基础设施，调度我们的代码，调度我们的应用部署。更进一步，如果和业务数仓结合，我们可以更好地洞察消费者，更好地了解用户，可以将业务和技术整合起来分析，尤其对于数字化原生的企业来说，产品本身就是数字化应用，应用代码，应用表现和业务表现自然息息相关。将这些数据整合起来，可以提升整个企业的效率，而不仅仅是单个技术团队。

可观测性正在席卷全球，如果作为一个企业的技术负责人，如果还停留在用监控系统去解决稳定性问题层面，很显然大量的数据价值被忽视了。云计算的发展带来数据量爆炸，但一切的数据本就存在，只是我们之前忽略了而已。

最后，推荐一本书

OREILLY 的《Observability Engineering》，中文译名《可观测性工程》。如您也有想法，欢迎一起交流。