前言
在上一篇文章观察系统解决了什么它又需要什么我讲述了观察系统的必要性以及观察系统需要什么数据.但是以什么样的眼光看待传递给观察系统的数据是模糊的,而事实上看待数据的眼光或者格局会作为顶层设计直接影响整个观察系统的最后的功能表现和技术水平的高低.
很多公司喜欢把一些对分布式的观察系统叫做日志处理系统,告警系统,监控系统等,老实讲都是片面的或者没有真正的理解观察系统和监控系统字面用词区别下的本质理念区别.一个优秀的观察系统不单是日志处理,监控,告警这些单维的功能组件.它是基于日志数据,指标数据等基础数据并结合链路追踪技术做数据综合处理后形成的完备的无缝的观察平台.
Logging,Metrics和Tracing的概念
OpenTelemetry基本定义了一个好的观察系统最后要做到的形态:终态就是实现Metrics、Tracing、Logging的融合,作为CNCF可观察性的终极解决方案.
OpenTelemetry is a collection of tools, APIs, and SDKs. You use it to instrument, generate, collect, and export telemetry data (metrics, logs, and traces) for analysis in order to understand your software's performance and behavior.
- Tracing: 提供了一个请求从接收到处理完毕整个生命周期的跟踪路径，通常请求都是在分布式的系统中处理，所以也叫做分布式链路追踪。
- Metrics: 提供量化的系统内/外部各个维度的指标，一般包括Counter、Gauge、Histogram等。
- Logging: 提供系统/进程最精细化的信息，例如某个关键变量、事件、访问记录等。
这三者在可观察性上缺一不可,基于Metrics的告警发现异常，通过Tracing定位问题(可疑)模块，根据模块具体的Logging定位到错误根源，最后再基于这次问题调查经验调整Metrics(增加或者调整报警阈值等)以便下次可以更早发现/预防此类问题.
实现Metrics、Tracing、Logging融合的关键是能够拿到这三者之间的关联关系.这篇文章(Metrics, tracing, and logging)详细的描述了三者的定义. 下面我对这篇文章做简短的解释方便大家快速理解,当然要全面的客观的了解还是要看原文.
首先我们Metrics、Tracing、Logging可以用下面的韦恩图表示
Metrics中文可以叫度量或者指标,首先它的典型特征就是可聚合(aggregatable).什么是可聚合的呢,简单讲可聚合就是一种基本单位可以在一种维度区间上做数学计算(累加,平均,).举个例子QPS就是一种Metrics,它的基本单位query是可聚合的,它的维度区间就是时间区间,区间长度为1s,所以QPS通过聚合得出了每秒系统被请求的次数.类似的Metrics有单个网络query的平均访问延迟,MySQL的CPU资源使用率等.
I think that the defining characteristic of metrics is that they are aggregatable: they are the atoms that compose into a single logical gauge, counter, or histogram over a span of time.
Logging的典型特征就是它和孤立的事件(Event)强关联,是因为一个事件的产生所以导致了一条日志的产生.举个例子就是一个网络query是一个事件,它被云端接到后Nginx产生了一个访问log. 大量的不同的外部事件间基本上是离散的,比如多个用户访问云端业务时产生的5个事件间没有必然关系,所以在一个服务节点的角度上看这些事件产生的日志间也是离散的
I think that the defining characteristic of logging is that it deals with discrete events.
Tracing的典型特征就是它是有范围(Scope)的.我们在链路追踪系统时,作为链路追踪系统的元数据必然会承载一些范围(Scope)信息,比如A服务RPC调用B服务的耗时(duration),通过分析元数据中的traceId流经了那些服务节点也是一种Scope.
I think that the single defining characteristic of tracing, then, is that it deals with information that is request-scoped.
Metrics、Tracing、Logging是有交集和差集的.每个交集和差集都能找到对应的实际的例子,不再一一赘述.
宏观上观察系统怎么获取/展现 Logging,Metrics和Tracing
大体上Logging占了观察系统最主要的数据来源,不过有些Metrics如上文所讲并不能完全的被Logging表现.比如redis的慢查询或者MySQL的CPU使用率并没有被日志化,它们是一段维度窗口下的瞬时信息.同时Tracing的大部分数据来源是被Logging,不过Logging也不能完全的满足Tracing的需要.比如原始的日志并没有Tracing需要的scope数据,典型的就是没有traceId(traceId也不是必须具体还看追踪系统的设计)和事件处理的启停时间.
但是我们收集数据主要是2方面:
- 直接获取: 比如上文讲的redis慢查询,没有日志文件不代表不能获取,我们可以直接连上redis后定期采样获取.此外日志文件本身就是一种直接的展现形式.这是服务主动的留下的蛛丝马迹,属于服务的主观信息
- 间接获取: 这些信息属于观察系统观察获取的,比如链路关系,MySQL服务所在的服务器的资源占用指标等. 这些信息本身不是各种类型的服务自己主动提供的,属于服务的客观信息.
在业界对于以上的实践可以看到现有系统进行的分类.例如,Prometheus开始专注于Metrics系统,随着时间的推移可能会越来越多地追踪,从而成为Tracing的指标,但可能不会太深入到日志记录中,同时基于Dapper的各类分布式链路追踪系统也在不断出现.ELK提供log的记录,滚动和聚合,并在其他领域不停的积累更多的特性,并集成进来.
值得一提的是相比Metrics和Logging,Tracing系统相对来讲代码侵入性和难度要大很多,它需要做一些顶层的设计,比如Google的Dapper选择了基于标注(annotation-based)的监控方案,它就需要在一些公共组件库上做一些装饰方便一个event流经服务节点后被标注(annotation).
典型的Tracing系统系统有Google的Dapper,AWS的X-Ray以及一些国内大厂的开源系统.
注: 我在自己的文章中有时有traceId的字样,如果不特殊说明就是带至的类似于Dapper中的annotation的概念.
本文原创链接: 观察系统中的Logging,Metrics和Tracing
本文参考: