最近两年,我看到可观测性的话题非常火热,各大技术社区都在讨论什么是可观测性,如何上可观测性。当然也有很多观点觉得所谓的可观测性又是新瓶装旧酒,只是再把传统的监控炒作一番,起一个新的概念忽悠而已。这些讨论不仅仅存在在中文技术圈,也广泛的存在海外的技术圈里。那么到底什么是可观测性,为什么需要构建可观测性呢?我通过这些年一些实际项目的实践,略有心得,想以本文抛砖引玉。
然而,仔细思考后就会发现,其实监控平台的本质,就是分成了四个核心组件:数据采集、数据存储、数据分析和数据使用,所有的监控平台都遵循这个逻辑。
比如 Prometheus,就是通过定义 Exporter 的数据结构,先以轮询抓取方式采集监控指标数据,存放到自有的时序存储里,再通过 PromQL 或者连接 Grafana 进行数据的分析,最后用 Alertmanager 检测数据并推送告警?同理,所有的日志系统,不也是通过采集器收集数据,统一存储,然后再进行分析和告警么?APM、NPM、RUM 都是一样的结构。
这几年随着云原生化和微服务化的普及,运维团队也好,研发团队也好,为了监控这件事情,持续投入了很多精力。小公司可能有个 3-5 套监控系统,大公司甚至有 10 套或更多的监控系统,我看到大家都在努力地构建更多新的监控平台去应对更多新的系统问题。
那么再来看各种监控平台采集到的数据,是不是都遵循这样一种数据结构,以尽可能真实地记录被监控对象当时的状态:即以时间为最主要的索引,叠加标签列和不同的 Payload。对于 Prometheus 来说就是指标,对于日志系统来说就是代码打印的日志文本,对于 APM、 NPM 或 RUM 来说也是类似的数据结构。
当所有的监控数据汇聚到集中数据平台以后,能做什么呢?好像也只能用于一些报表和大屏,变成了展示给管理者看的一个东西(或者管理者对这些枯燥的数据根本不感兴趣),那还不如直接展示业务数据来的直观。
所以相对来说,这种方式的投入产出比就太低了。
于是,大家开始了往第二个方向尝试,从消费效果上统一。从效果上看,最终对监控平台的消费就是看报表和告警,但是不同的监控平台有不一样的数据看板样式,也有独立的消息通道,得一个个切换着看数据仪表板,也得从一堆通道里接收告警,能不能都统一了?
于是又有了通过 Grafana 这样的工具实现统一大屏展示,和通过大数据的方式,实现聚合通知,将告警事件合并。虽然没有聚合源数据,但统一了输出效果,看上去也挺不错的。
实现用统一的数据了解系统的整体运行状态,再利用这些数据进一步开发出更高维度的数据应用,让开发、测试、运维和运营都能使用,我认为这才是构建可观测性的真正价值,也是我想要的可观测性平台。
当然这件事情并不简单,得先有一套完整并统一的数据采集体系,还要有一个可以处理所有监控数据的平台,它们的功能除了要承担传统的系统监控任务以外,还需要有能力做数据治理和数据挖掘,构建复杂度相当于一个大型的实时数仓。
首先,我们需要有一个真正意义上可以将各种数据统一采集的 Agent,它必须是能覆盖基础设施、云原生、各种技术栈和各种应用系统的,不仅仅要有能力采集数据,还能支持在采集过程中完成对于数据的结构化,标准化的治理。
接着,我们需要一个真正意义上面向可观测性数据存储分析的统一的数据仓库,它可以高效地处理所有的可观测性的信号数据,如指标,事件,日志,调用链等等,有强大的在线分析能力。
2022 年国内曾有百仓大战的盛况,但我看到能存活到今天的,并且适合做可观测性平台数仓的产品并不多。不是因为它们的性能不够,问题恰恰是太超出了,增加了成本。大部分数仓产品是按照电商平台对 CDP 要求设计的,能满足 RTA/RTB 的毫秒级别响应,但若用作一个可观测性平台数仓,会更多考虑如何降低成本,以及考虑如何横向打通业务数仓,作聚合视图。
然后,我们需要一个统一的且友好的互动界面,来实现对上述数据的使用和可视化操作,包括配置告警条件,设置告警通道、生成仪表板甚至发布协同任务等,最好都能在同一套界面风格和脚本语言里操作,比如全部统一成 PromQL,也要把功能标签都统一掉,就说「标签」这个词本身,我见过叫 label、lable 或者 tag 的,要是在同一套系统里随机出现不同名词,这谁受得了。