前言
众所周知,真正意义上的统一监控观测平台本质上是一个超大的数据湖,其存储了大量的来自监控指标,各种各样的日志,各种各样的链路追踪以及包括用户访问行为等海量的可观测性数据。
这些海量数据有什么特点呢?
- 首先,第一个特点是时间戳是这些数据的最重要的标记,这个无需多言。
- 其次,第二个特点是数据结构千变万化,我们通常用 tag 这个概念来对这些数据进行标记。
所以观测云的核心数据结构就是:
timestamp {tag1,tag2,tag3……} content
如果对应指标,指标名也是个 tag,content 就是一个数值。如果对应到日志,content 则是日志的原内容,我们可以在日志上加入采集路径,来源等 tag,也可以将内容中的关键信息提取到 tag。如果对应链路和用户访问也是类似,只不过 content 里面放的是一些扩展说明的 json 结构,tag 里则是放着相关的 trace 或 event 的属性。其他类型的可观测数据也是类似,就不一一展开说明了。
支持 Schemaless 特性至关重要
从这里也可以发现,对于不同的监控观测对象,对于不同的应用产生的 trace,对于不同的终端产生的 event,其 tag 完全是不同的,所以我们需要一种能够由写入数据本身字描述的数据结构,即半结构化(semi-structured)或者称之为无结构(schemaless)的数据库。这些动态的 tag 可以被记录,可以被检索,可以被分析,甚至 tag 本身又是一种嵌套的 json 结构,如果我们需要记录一个点击事件,那么实际上会增加一个 position 的字段,而内部是一个 {x=100,y=200} 的 json 结构,这些 json 形态的 tag 也可以被分析可以被检索。
为什么记录观测性数据需要这种 schemaless 的数据结构和对应的数据库非常重要?主要有以下三个原因:
方便各种各样的数据集成和接入
可观测性需要对接的监控观测的对象非常多,种类也很多,从硬件到操作系统到中间件数据库到各种应用,我们不可能为海量的技术栈全面的去构建基于 schema 的表结构,这样意味着非常大的配置工作,也很难兼容新出现的技术栈,如新出现的技术栈暴露了一个标准的 openmetric 协议,在观测云的数据模型中,只需要将其直接接入,你并不需要实现定义什么,数据本身就是模型。
方便我们在可观测性数据上追加任意的 tag
要用好可观测性,不仅仅只是标准化把数据接入进来,事实上我们还是需要加入很多自己的 tag,可能是管理上的 tag,如:项目,集群,人员,也可能增加很多业务上的 tag,如:订单号,金额,用户信息,地理坐标等等。这些 tag 的追加必然可以被监控配置或者业务代码本身来决定,并不需要也不应该在监控观测平台来配置,这才是体现观测数据的最大意义(know unknown)。
真正让工程师能落地可观测性数据治理
对于开发工程师来说,可以自由的对任意数据追加自己的业务描述,对于运维工程师来说也可以任意根据自己的业务需求任意追加管理描述,所有人追加在数据上的 tag 都可以进行多维度的分析,都可以变成一种检索的条件,这样才是真正能将可观测性建设落地的基本,每个人只对自己认知边界追加 tag,最终的数据就自然而然变成了一个全方位可分析的数据,大家不用开会写个文档耗费时间去定义所谓的数据结构,避免浪费大量的精力去维护数据模型。
常见的 Tag 整理:https://docs.guance.com/datakit/common-tags/
总结
构建可观测性最重要的是基于半结构化的 schemaless 的数据库方案构建整个监控观测系统,这个能力将真正意义上决定你使用的是一个传统监控产品,还是真正的现代化监控观测平台。
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用
。你还可以使用@
来通知其他用户。