因收到Google相关通知,网站将会择期关闭。相关通知内容

11 实战 2:基于可观测性数据进行问题分析和根因定位

你好,我是翁一磊。

在上节课的实战中,我为你介绍了如何采集一个微服务系统各方面的可观测性数据。收集好所有需要的数据之后,我们就可以在可观测平台方便地查看系统和应用软件的运行情况了。

这节课,我们就来看看在遇到问题的时候,怎么使用可观测性数据进行关联分析,定位到问题原因。

可观测性数据的联合

我在第 2 讲的时候曾经说过,可观测性应该是支持高基数、高维度和可探索性的工具,可探索性从另一个角度来说,也是需要将采集到的各种数据能够关联起来,方便在分析问题的时候有效地定位问题。

构建一个可观测系统的核心就是把丰富的数据关联在一起,比如我们需要知道一个访问请求的故障对应的日志是什么,同时它所在的主机(虚拟化环境)或是 Pod(容器环境) 的一些信息,以及它所依赖的中间件、数据库是否存在异常等等。

以前我们往往需要花费大量的时间成本人工在不同的监控、日志、管理系统中调取相关的 UI,即便使用一些工具实现了统一的数据展示,这个实施过程也非常非常复杂。

观测云这个我们进行可观测性实战的平台,构建了完整的数据标签,也就是 Tag 的体系,而且保证了这些标签在整个系统中是唯一的 Key 且拥有一致性的表达。如: host, pod_name, trace_id, project, cloud_provider, status 等,这样我们在查询不同数据的时候,在构建相关的视图的时候,就可以获得完整的统一认知,也可以快速方便地构建不同数据直接的关联关系了。

下面我从高基数、高维度还有关联性的角度分别给你举一些例子。

高基数

基数对于可观测性很重要,因为高基数信息在调试或理解系统的数据时是最有用的。如果能够按照这些字段,根据其中的唯一 ID 来查询数据,就能够确定问题具体的影响范围。

我们以观测云 RUM 数据为例来看一下高基数的维度。上一节我们就说过,观测云提供对 RUM(也就是用户访问数据)的采集和分析,你可以快速了解用户访问环境、回溯用户的操作路径、分解用户操作的响应时间,了解用户操作导致的后端应用一系列调用链的性能指标情况。观测云采集的用户访问数据包括 6 种数据类型:

图片

这 6 种数据类型的层次结构如下图:

图片

这些数据中包含以下的高基数:

  • app_id:用户访问应用唯一的 ID 标识,在控制台上面创建应用时自动生成。
  • session_id:会话 id。
  • user_id:默认获取浏览器 cookie 作为 user_id。如果使用自定义用户标识设置用户 ID,那么 user_id 就会跟定义的保持一致。
  • ip:用户访问的源 IP 地址。
  • city:用户访问的来源城市。
  • view_id:每次访问页面时产生的唯一 ID。
  • view_referrer:页面来源。
  • view_url:页面 URL。
  • ……

这些高基数的数据能够帮助我们在分析问题的时候,定位到问题的具体影响范围,帮助我们更准确地进行故障排查。

高维度

一个原始数据在产生的时候,产生这个数据的对象本身可能只会知道有限的相关数据,例如:一个日志刚产生的时候,只有时间和消息体,但我们需要根据其输出的路径来赋予标签,形成多维度的数据。如果我们要知道这个日志是在哪台主机或者容器中产生的,那就要追加 host,或是 container_name 和 pod_name,还有容器相关的 deployment, namespace, node, project, version, cloudprovider 等各维度的信息。这些信息会在数据入库前,在全路径上追加标签来与对象进行关联。

下面这个例子,是观测云针对主机中产生的日志所赋予的相关标签:

class_name
create_time
date_ns
filename
filepath
host
index
line
log_read_lines
log_read_offset
log_read_time
message_length
method_name
msg
service
source
span_id
status
thread_name
trace_id

关联性

由于我们面对的是海量的实时数据,为了建立数据相互之间的关联,观测云的数据采集器 DataKit 在收集数据的过程中统一定义了标签。其中, DataKit 在兼容其他第三方工具或框架(例如Prometheus、各种日志采集器、OpenTelemetry 的各种 Instrument SDK)时,都会将其本身的字段转换为观测云自身的标签。

针对不同来源的数据,可能存在不同的数据结构,会出现一些非结构化数据,或者标签的原始数据不统一的情况,我们需要将这些数据结构化。又因为这些数据都是海量的实时数据,不可能像关系型数据那样进行 ETL(抽取、转换和加载),而是需要像流(Stream)一样处理,完成流(Streaming)、转换 (Transforming) 和输出 (Output) 这样一个过程,这就是可观测性的流水线(Pipeline)。

我们最终想要达到的效果就是让标签都关联起来。这种关联不仅仅是为了管理数据,更重要的是方便使用者观测。

我们需要将标签以一种对象的方式表达出来。例如,当我们看到任何数据存在 Host 这个标签时,就能把它和对应这个 Host 值的对象视图关联起来,这样无论在分析日志数据、应用性能还是用户访问数据时,都可以指向对应数据所在主机的相关视图,从而能够关联性地分析这台主机当时的负载情况以及其他相关信息。

建立 SLO 可观测

有了可观测的数据,我们就可以从系统和应用的各个维度来定义 SLI,衡量系统的服务可靠性也就是 SLO 了。在第8讲我们强调说,要选取会影响最终用户体验的指标作为 SLI,然后根据实际 SLO 和错误预算来跟踪问题。如果你记不太清了,可以回去复习一下。

在观测云中,建立 SLO 之后,可以通过仪表盘来持续跟踪,并将相关的 SLI 统一展示出来,下图便是一个例子。同时,我们也可以针对 SLI 和 SLO 的状态设定监控器,及时获取异常事件的告警。

图片

通过可观测性数据进行问题分析

当你通过仪表盘直接查看整个服务 SLO 和错误余额的情况时,也能够同时查看相关 SLI 的情况。比如说,如果发现页面错误率有异常,你可以进一步进行分析,查看错误的详细情况。

图片

在错误分析页面,我们还能进一步查看多个维度的错误统计。例如,想了解具体哪些页面有报错,可以查看“页面错误率排行”,然后进一步下钻去查看这个页面(也就是 View 查看器)的详细信息。

图片

通过 View 页面,我们可以看到用户访问时的页面性能数据,包括页面地址、页面加载类型、页面加载时间、用户停留时间等。如果列表最左侧出现红色小三角的标记,说明这个页面是有报错的,点击其中一条可以查看详细的信息。

图片

因为之前我们已经做了数据的关联,所以我们可以继续下钻,查看相关的链路、日志和指标信息,还能够直接查看相关联的视图。也就是说,在一个界面中,我们可以多维度地查看各种数据。

就像我之前说过的,在现今复杂的系统中,面对一个问题,我们很可能并不知道问题的原因是什么,因此只有将数据统一和关联起来,才能够“自由”地分析问题,找到问题的应对策略。

比如说,点击“Fetch/XHR”的标签页,我们就可以查看用户在访问时,向后端应用发出的每一个网络请求,包括发生时间、请求的链路和持续时间;如果网络请求存在对应的 TraceID,而且已经和前端用户访问的数据进行了关联,那么我们就可以点击列表中的某个请求,进一步下钻来分析问题。

图片

点开具体的请求之后会跳转至对应链路的详情页,这里我们可以看到链路 Tracing 的详细信息,包括整条链路中每个 Span 的流转和执行时间。如下图所示,这时候我们可以注意到有一条红色标记的 Span,这表示系统有报错,我们可以在详情中查看详细的报错信息,定位问题的原因。

图片

还有的时候,问题的情况比较复杂,所以我们希望不仅能够查看链路的属性和耗时,也能够直接查看相关的日志、主机的性能、网络情况以及相关联的视图,将各维度的数据综合在一个界面来分析。

在观测云中,如下图所示,当我们查看链路的详细信息时,也能够同时关联地分析链路发生时相关主机的负载情况(包括指标和网络)、相关的日志等信息。

图片

同时,我们可以在观测云中自定义绑定视图到查看器,在上图中,“链路详情”右侧的各种视图就都是动态关联的。将内置视图与链路服务、应用、日志源、项目、或其他自定义字段进行绑定,匹配字段值的查看器,然后通过侧滑详情页查看新增被绑定的内置视图。

我们可以根据服务的类型、应用 ID 或者标签等维度来进行关联,而不是写死一个维度,只能往固定方向排查。例如在下图中,可以将 MySQL 数据库的监控视图与 MySQL 相关的服务绑定在一起,这样在查看 MySQL 相关的链路时,也能够同时查看数据库的负载情况,更加全面地分析问题。

图片

小结

好了,这节课就讲到这里。通过这节课的实战,相信你已经看到了,建立了可观测之后,在调试或排查问题时,你可以通过探索数据来迭代调查你关心的条件,看看它能揭示系统的什么状态。

在这个过程中,你不需要提前预测问题,只需要按照你的思路去提出问题,去寻找线索或答案,然后提出下一个问题,再下一个。这样一遍又一遍地重复这个模式,就能在大海中找到你要找的那根针。

所以说,能够跟踪代码并知道时间花在了哪里,或者从用户的角度再现行为总是很有帮助的。无论你的软件架构是什么样子,可观测性无疑可以提高团队效率,发现和解决生产环境中不可预测的问题。在现代分布式系统中,可观测性工具就像我们的手术刀和探照灯,变得越来越不可或缺。

课后题

在这节课的最后,我留给你一道作业题。

请根据我们这节课的内容,通过可观测性的数据分析一下你负责的系统,查找一下平时你可能不知道的一些问题。如果有所收获或者发现,欢迎你在留言区和我交流讨论。

我们下节课见!