关于elasticsearch:观察系统中的LoggingMetrics和Tracing

43次阅读

共计 3052 个字符，预计需要花费 8 分钟才能阅读完成。

在上一篇文章察看零碎解决了什么它又须要什么我讲述了察看零碎的必要性以及察看零碎须要什么数据. 然而以什么样的眼光对待传递给察看零碎的数据是含糊的, 而事实上对待数据的眼光或者格局会作为顶层设计间接影响整个察看零碎的最初的性能体现和技术水平的高下.

很多公司喜爱把一些对分布式的察看零碎叫做日志解决零碎, 告警零碎, 监控零碎等, 诚实讲都是全面的或者没有真正的了解 察看 零碎和 监控 零碎字面用词区别下的实质理念区别. 一个优良的察看零碎不单是日志解决, 监控, 告警这些单维的性能组件. 它是基于日志数据, 指标数据等根底数据并联合链路追踪技术做数据综合解决后造成的齐备的无缝的察看平台.

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 如上文所讲并不能齐全的被 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

本文参考: