跳到主要内容

Kindling-OriginX 在快手 Staging 环境的异常诊断效果分享

· 阅读需 13 分钟
Kindling-OriginX
故障根因推理引擎

业务可用性问题的快速诊断,历来是行业互联网公司面临的重大挑战,快手也不外如是。Kindling-OriginX的体系化设计理念快速打动了我们的工程师。快手随即开始了内部真实业务的验证落地;落地过程中,Kindling-OriginX能高效覆盖大部分线上问题的快速定界,其中20%可直接给出根因,缩短业务影响时长。未来,我们希望与Kindling-OriginX在异常场景和诊断效率上继续深度合作,进一步缩短业务异常的恢复时长,以及提升工程师研发幸福感。

---周辉,容器云稳定性团队负责人

Originx注:快手团队对根因的要求比较高,比如一般团队遇到请求被锁住,得到锁的代码堆栈就够了,但是快手团队要求更高,更希望知道为什么代码发生了锁住originx目前还只能给出哪段代码堆栈导致锁住。

目的

愿景:缩短对线上稳定性问题的定位时长,帮助业务快速止损,减轻日常问题排查的人力成本。

1.是否能在在公司落地,给实际的问题诊断带来帮助;

2.为问题诊断提供借鉴思路:通过ebpf采集系统层面指标,打通业务请求链路。

结论

OriginX 诊断能力

结论:能够进行问题的定界。

延时耗时示意图

初步分支定界

可以对问题起到初步分支定界的作用,能初步判断出是问题哪个或哪些类别,即 :

1.CPU 执行(onCPU)

  • 是否能够下钻
  • 对 frequency 问题的判定效果?可以设置 frequency 吗【Originx 目前支持各种频率 CPU 采样,但是需要重启探针】

2.等待调度到 CPU(RUNQ)

  • 较少发生,主机有较高的负载的场景

3.读写文件(VFS 的直接读写关联存储相关问题)

  • 如何确定拿到的文件和请求是相关
  • Originx 通过与请求过程中的系统调用关联,按照时间能精准匹配到请求时的系统调用

4.请求下游节点耗时长(网络调用)

5.锁等待或内存 GC 类型(futex 等)

  • 如何确定拿到的这个锁和这个请求有关
  • Originx 通过与请求过程中的系统调用关联,按照时间能精准匹配到请求时的系统调用

Originx 不擅长的故障种类:

1.对 CPU 算力分层类、夯机类、硬件类等问题的分析 Kindling-OriginX 诊断相对比较薄弱;

2.对Java 类服务的支持友好,接入 Kindling-OriginX 需要适配公司的 “全链路追踪系统”。

Originx 存在优化空间

快手使用的 Originx 版本在确定故障报告时存在多种可能性,需要人为排除噪音干扰因素。

1.由于一个采样报告只能得出一种结论,故障发生所在的时间段内若干采样点产生的多个报告,可能结论不一致,需要自己来判断具体是哪方面原 因占主导,排除干扰因素; 有时会出现----未发现明显异常的结论,如

2.故障分为慢故障和故障两大类。对于慢故障,请求调用时长与历史数据相对比,发现其大于 24h 内历史 P90(或 p99,p95) 数据,将其判定为慢故障。假设极端情况,存在故障的实例的请求时延在 24h 内一直都很高,那么后续的请求也会被判断为正常请求,产生漏判。

3.下钻诊断能力不足,当前除了对网络故障具备更细粒度的诊断(需接入 DeepFlow,在根因报告中对于对外调用网络耗时长的问题,根 因推导能够回答网络耗时分布的根因,例如是客户端网络问题还是服务端网络问题,是 RTT 问题还是丢包重传问题),其他类型问题 有待关联更多数据提供更多的下转能力。


原理

请求故障评估标准

业务请求时延指标大于 P90(或者 P95,P99 阈值),就会判定为慢请求故障。

线程状态分析方法(TSA)

有别于从资源视角的 USE 方法是从整理上找破绽来缩小异常的范围,给出可能性的方向,TSA 是从主体(线程)角度出发进一步明确线程时间消耗在哪里的方式。

http://u6v.cn/5VZWML

TSA 与 Trace 结合

内核视角缺少业务属性,Trace-Profiling 通过 TSA 的方法论产生的数据与 Trace 打通,做到了与业务关联,这样在生产环境就可以做到某个业务因为什么原因卡住了。

skywalking 会给请求打一个 trace id,利用 ebpf 的能力将 trace 通过 PID 和 TID 底层的 syscall 相关联利用

eBPF 技术能够深入内核,拦截线程执行用户代码的关键点位获取信息,在获得线程执行关键信息之后能够还原线程的执行过程。如 果只从线程维度看程序执行过程是很难分析出故障的,因为开发和运维的谈的故障都是 URL 维度的用户请求调用,所以光有线程维度程序 执行过程是不够的,需要和 Tracing 系统关联。当线程执行过程与 Tracing 系统关联之后,即可完整还原用户一次请求的执行过程。TraceProfiling 中关联了可观测性所需要的数据。

指标说明

Kindling-OriginX 并不直接提供 Trace 能力,而是采用接入 Trace 数据的形式,即通过接入目前成熟的 Trace 产品与提供标准接入 SDK 方 式,例如 Skywalking、OpenTelemetry、ARMS 等,利用 eBPF 能力将 Trace 数据进行扩展,将其与底层的系统调用相关联,进而实现整 的可观测性,消除程序执行与 Trace 数据中的盲区。

用决策树结合 TSA 实现对内核事件的自动化翻译

基于内核事件统计分析,可以形成这样的决策树,最终给出故障的根因。

北极星排障指标-CPU 时间程序

在 CPU 资源上所消耗的时间

  • OnCPU

    程序代码执行所消耗的 CPU cycles,可以通过程序火焰图确认代码在 CPU 上执行消耗的时间与代码堆栈。

  • Runqueue

    线程的状态是 Ready,如果 CPU 资源是充分,线程应该被调度到 CPU 上执行,但是由于各种原因,线程并未调度到 CPU 执行,从而产生的等待时间。

北极星排障指标-网络时间

网络时间属于两次 OnCPU 时间之间的 OffCPU 时间

  • 网络时间打标过程

    第一次 OnCPU 最后一个系统调用执行为 sock write 与第二次 OnCPU 第一个系统调用为 sock read,也可以理解为网络包出网卡至网络包从网卡收回的时间。

  • 网络时间分类

    DNS,TCP 建连,常规网络调用。

北极星排障指标-存储时间

属于两次 OnCPU 时间之间的 OffCPU 时间

  • 存储时间打标过程

    第一次 OnCPU 最后一个系统调用执行为 VFS read/write 与第二次 OnCPU 第一个系统调用为 VFS read/wirte。

  • 存储时间真实情况

    存储真实执行情况,由于内核的 pagecache 存在,所以绝大多数 VFS read/write 从程序视 角看:执行时间不超过 1 毫秒。

北极星排障指标-等待时间

  • futex

    通常指的是一个线程在尝试获取一个 futex 锁时因为锁已经被其他线程占用而进入等待状态的时间。在这段时间内,线程不会执行任何操 作,它会被内核挂起。

  • mutex_lock

    线程在尝试获取互斥锁时,因为锁已经被其他线程持有而进入等待状态的时间长度。这段时间对于程序的性能至关重要,因为在等待期 间,线程不能执行任何有用的工作。


实际使用效果

历史稳定性分布问题

效果汇总

故障类型故障案例人工时长使用Oirignx预计定界时长召回率准确率
OnCPU(CPU执行)时间过长代码缺陷,直播服务故障16min(5+位领域专业同学投入)10min80%80%
极高的中断负载4h10min90%80%
等待调度到CPU时间过长宿主机CPU负载过高1h5min90%70%
读写文件耗时长(IO)P2P拉镜像卡死2天(需基础平台多位高级同学参与分析,链路长)8min90%70%
高磁盘读取负载1h5min90%60%
请求下游节点耗时长(网络调用耗时长)网卡时延过长(网卡上tc注入时延)4h5min90%80%
epoll耗时异常4h5min90%70%
调用中间件耗时长4h5min80%70%
锁等待或GC内核osq_lock锁竞争问题1周(基础平台累计10+位领域专业同学投入,蹲守凌晨业务高峰得以查明)10min80%80%
服务异常(内核死锁问题)1周(基础平台累计10+位领域专业同学投入)10min80%80%
Java锁耗时长4h5min80%90%
内存问题虚拟内存压力1h5min70%70%
用户页错误3h5min80%80%

Kubernetes集群中如何利用北极星因果指标设置正确的POD规格——CPU篇

· 阅读需 13 分钟
Kindling-OriginX
故障根因推理引擎

在 Kubernetes 容量规划中,追求的是集群的稳定性和资源使用效率之间的平衡:

  • 资源分配过多会造成浪费。
  • 资源分配过少则会导致用户请求时延上升,影响集群的稳定性。

背景

公众号之前翻译了一篇 Sysdig 的文章,Kubernetes 容量规划:如何合理设置集群资源介绍了如何设置合理的资源参数

虽然按照那篇文章设置可以有一定的帮助,但仍然可能存在风险。本文将详细说明这些风险,并介绍如何通过北极星指标对 POD 的规格进行调整,以达到时延和资源的完美平衡。

Kubernetes 中的 POD CPU 规格参数

在 Kubernetes 中,POD 的 CPU 规格主要包括以下两个参数:

  • requests: POD 启动时请求的 CPU 资源量。Kubernetes 调度器会根据这个参数将 POD 调度到能够满足资源需求的节点上。

  • limits: POD 运行时能够使用的最大 CPU 资源量。如果 POD 尝试使用超过这个限制的 CPU 资源,会被限制在定义的 limit 值内。

Kubernetes 中的现存指标

要判断 POD 规格是否合适,需通过合适的指标来评估。当前 Kubernetes 中常见的 CPU 指标包括:

  • CPU 利用率(container_cpu_usage_seconds_total): 通过类似 PQL 语句获得:
irate(container_cpu_usage_seconds_total{namespace="XXXX", container="XXXX"}[5m])

该指标反映了 CPU 利用率。

  • 系统负载:node_load1、node_load5、node_load15 表示系统在 1 分钟、5 分钟和 15 分钟内的平均负载。一般认为负载与 CPU 核数相当即可。

  • CPU 节流(throttle):container_cpu_cfs_throttled_seconds_total, 通过类似 PQL 语句获得:

irate(container_cpu_cfs_throttled_seconds_total{namespace="XXXX", container="XXXX"}[5m])

该指标表示容器由于 CPU 配额不足而被节流的 CPU 核心时间总量。

尽管这些指标对了解 CPU 资源使用情况有帮助,但各自存在局限性,难以单独作为唯一且关键的指标。


北极星指标的应用

所谓北极星指标,是指唯一且最关键的指标。在 Kubernetes 中,该用哪个指标来衡量容器的 CPU 资源是否充足呢?

CPU 利用率指标的局限性

CPU 利用率指标的主要局限性在于:

  • 单一性: CPU 利用率反映了容器对 CPU 资源的需求和使用情况。如果利用率持续高企,可能表明容器需要更多的 CPU 资源。然而,仅凭这一指标无法全面反映系统的性能状态。
  • 响应时间和性能: 需要考虑容器内应用的响应时间和性能。如果响应时间变长或性能下降,即使 CPU 利用率不高,也可能意味着 CPU 资源不足。
  • 并发负载: 在高并发场景下,瞬时的负载高峰可能导致性能问题。CPU 利用率可能无法及时反映这些短期高峰负载的影响。

Load指标的局限性

Load 指标代表有多少执行单元等待调度器执行,但它无法单独衡量 CPU 资源是否充足。

CPU节流指标的局限性

container_cpu_cfs_throttled_seconds_total 指标用于衡量容器因 CPU 资源不足而遭受的 CPU 节流(throttling)。如果该指标的值不为零并且持续增加,通常意味着:

1. CPU 资源不足: 容器的 CPU 使用需求超出了为其分配的 CPU 配额,导致它无法获得足够的 CPU 时间来执行其任务。

2. 性能影响: CPU 节流可能会导致容器内应用的性能下降,因为它们没有足够的 CPU 时间来及时完成任务。

虽然该指标能够直接反映容器是否遭受 CPU 节流,但仅凭它来判断资源是否充足可能会忽略其他重要的性能指标和系统状态。即使 container_cpu_cfs_throttled_seconds_total 不增长,但如果 CPU 调度器队列很长,仍然可能出现 CPU 资源不足的情况。


北极星因果指标中的 CPU 调度耗时

北极星因果指标中的 CPU 调度耗时能够反映出 CPU 节流和高负载下的 CPU 调度延时,包括以下几种情况:

  • CPU 调度队列长: 当程序执行完数据库等网络操作后,如果CPU充分,应该被立马执行,但是当调度队列长时,就会产生等待被调度到 CPU 上的时间。

  • CPU 节流: 代码执行时间片被执行完后,等待下一个调度周期才能被调度到 CPU 上执行的时间。

北极星因果指标中的 CPU 调度耗时能够反映出 CPU 节流和高负载下的 CPU 调度延时。只要该指标不高,即可说明容器的 CPU 资源是充分的;如果该指标高,则说明容器的 CPU 资源是不充分的。

通过准确监控和调整这些指标,可以实现 Kubernetes 集群的稳定可靠性和资源使用效率之间的最佳平衡。


北极星因果指标的CPU调度耗时实际用法举例

Demo环境的route-service的CPU调度耗时异常修复过程

在云观秋毫的Demo环境中,通过北极星因果指标巡检,发现route-service的CPU调度耗时较长,其90分位线经常超过10ms,甚至达到20ms左右。 此时指标已经说明了route-service的CPU资源不充分。

怎么解决呢?是不是直接去增加POD limit的设置呢?

POD规格调整原则一:如果发现CPU节流(throttling)时间高,才需要增加POD limit的配置

通过查询route-service的CPU节流(throttling)指标,发现其CPU节流时间很少,几乎没有波动。这与route-service北极星因果指标中每次请求都有10ms左右情况不符合,说明北极星因果指标中的CPU调度耗时并不是由于CPU节流导致的,也就意味着提高POD limit无法解决问题。

那这种情况只能说明当时的CPU队列很长,当一次任务如数据库调用完成之后,程序需要重新调度到CPU上而产生了调度耗时。为了验证这点,我们继续查看下其CPU利用率指标和节点的Load指标。

CPU利用率显示其CPU资源是非常充足的,因为route-service所在机器的节点CPU核数为8核,load指标最高位7.13,也是符合预期的。 此时如果没有北极星因果指标,也不知道每次请求有这么高的CPU调度耗时,但是要优化性能,提高容量也就无从谈起了。

为了证明北极星因果指标的正确性,我们将route-service调度到另外一台机器上,在调度之前其load如下:

当调度完成之后,我们再次查看北极星因果指标,发现每次请求CPU调度耗时已经降低了很多,此时调度耗时在90分位线最高也只有8ms,绝大多数请求CPU调度耗时在4ms以下。

此时我们再去查看rout-service的相应延时,发现延时也有了显著的优化:可以看到平均延时在重新调度之前延时是普遍大于20ms的,而调整之后rout-service的延时已经没有高于20ms的了。

Demo环境的order-service的CPU调度耗时异常修复过程

在云观秋毫的Demo环境中,通过北极星因果指标巡检,发现order-service的CPU调度耗时较长,其90分位线经常超过80ms,甚至达到90ms左右。 此时指标已经说明了order-service的CPU资源不充分。

根据POD规格调整原则一,先去查看容器的CPU节流指标,发现其节流时间确实很大,说明POD的规格Limit设置过小了。

如果只看CPU 利用率,其实还好,并不是一直很高,而是周期性飙高。

POD规格调整原则二:调整POD Limit设置之时,不需要翻倍的增加CPU核数,而是一个核增加完之后,观察数据,确保最省资源的方式满足业务需求

当对order-service的limit增加之后,再看节流指标,此时节流已经很少发生了。

然后我们再看北极星因果指标中的每次请求CPU调度耗时指标,数据从原来的80-90ms 降到了1~2ms左右,甚至90分线最高值才5ms,说明其CPU现在是充分供应了。

最后我们再看看调整前后的时延对比,从调整之前的90分位线100ms降到了调整之后不到10ms左右。


利用北极星因果指标轻松识别POD运行的应用是CPU密集型还是IO密集型,并完成调度,保证应用的健康状态是最佳的

在计算机知识中,大家都知道不同应用有着不同特征,典型的分类就是CPU密集型和IO密集型,但是我们怎么判断应用是IO密集型还是CPU密集型呢?绝大多数情况下大家是通过主观经验判断,缺少证据证明。

POD调度原则:根据POD应用类型来实现调度

如果根据北极星因果指标中每次请求CPU执行时间超过了响应时间的一半,一般认为其应用为CPU密集型。 根据这个原则发现绝大多数在线业务都不属于CPU密集型,只有那些执行时间非常短的应用不到20ms的应用,其cpu时间才有可能超过一半。

所以调度原则简化成可以把响应时间短的应用和响应时间长的应用混合调度在一台机器上能够保证应用健康状态是最佳的。

排障指标革命性新突破,北极星指标让故障无所遁形--北极星因果指标产品正式发布

· 阅读需 14 分钟
Kindling-OriginX
故障根因推理引擎

传统排障方法的局限性

传统故障排查的痛点

在复杂的分布式系统中,故障排查一直是一个让人头疼的问题,其中机器宕机、进程存活、程序异常报错等故障相对而言比较好排查,有直接的指标能够反应出问题,难排查的问题是流量突增,时延变化等故障,特别是在分布式系统中,这类故障更难排查。传统的方法往往需要工程师逐一排查各种可能性,耗费大量时间和精力,效率低下且盲目。

传统故障排查方法的低效性主要源于以下几点:

  • 时间消耗巨大: 需要逐一检查系统中的各个组件和指标,排查流程繁琐,耗时长。
  • 盲目性: 没有明确的线索指引,排查过程中往往需要凭借经验和直觉,试错成本高。
  • 数据分散: 各类监控指标彼此独立,缺乏统一的视图,导致难以全面了解系统状态。

这些痛点的根源在于我们所使用的指标大多是结果性指标,指向性不明确。例如,CPU利用率、内存使用率等指标只能反映系统的当前状态,却无法直接指出问题的根源,给故障排查带来了巨大的挑战。

常规的指标局限

在实际应用中,工程师们常常依赖于各种常规的性能指标,例如:

  • CPU指标: 反映系统的计算资源使用情况。高CPU使用率可能是由于多个原因导致的,例如某个服务在进行高计算密集型操作。但是,CPU指标并不能告诉我们具体是哪个请求导致了高CPU使用率,通过人为分析才能知道是哪个进程的CPU使用率高,然后借助更多的工具才能知道可能是哪一段代码导致的,但是业界还缺少业务视角关联,没有办法知道哪个URL导致了CPU升高。
  • 网络指标: 反映网络传输的性能。无法明确是哪一个具体请求导致的带宽占用,例如一个文件服务器在处理多个文件上传和下载请求。网络指标只能显示整体的网络带宽使用情况上升,却不能确定是哪个具体请求导致的带宽占用增加,也缺少业务视角关联。
  • 文件指标: 反映磁盘I/O操作的效率。高磁盘IO使用可能是因为某些请求涉及大量的文件读写操作。然而无法具体指明是哪一个请求导致的磁盘IO高使用,缺少业务关联视角。
  • 内存指标: 反映系统的内存使用情况,同理缺少业务关联视角。
  • GC指标: 反映垃圾回收的频率和时间,同理缺少业务关联视角。

虽然这些指标在一定程度上帮助我们了解系统的运行状态,但它们彼此独立,无法构建出一个完整的故障图景。这种独立性导致了以下问题:

  • 无法关联: 各个指标之间缺乏关联,难以看出它们之间的因果关系。
  • 片面视角: 只能看到单个指标的表现,无法形成整体视图。
  • 低效排查: 无法通过单一指标判断问题的根源,需要逐一排除各种可能性,效率低下。

常规指标的这种局限性导致在排障过程中,我们常常需要逐一排查每一个可能的原因,耗费大量时间和精力,难以快速定位问题。


北极星指标带来的革命性变化

业界提供因果性的工具

为了应对复杂系统中的故障排查问题,业界提出了一些具有间接因果性的工具。然而,这些工具和方法也有其局限性:

  • 分布式追踪(Distributed Tracing):

优点: 提供请求的完整路径信息,详细展示每个服务调用的耗时,帮助识别系统中的延迟和瓶颈。

局限性: 在稍微复杂的场景下,因噪音和故障级联的存在,瓶颈点经常会被误判。需要结合业务逻辑和经验分析,才能推断因果关系,找到真正的瓶颈点。

  • 依赖图(Dependency Graph):

优点: 展示系统组件之间的依赖关系,便于理解系统架构,帮助识别关键路径和潜在的瓶颈。

局限性: 依赖图是静态分析工具,无法实时反映系统运行状态。随着系统规模的增加,依赖图的复杂性也增加,难以管理和维护。

  • 日志(Logging):

优点: 详细记录系统运行状态和事件,便于追踪和分析,具有高度的定制性,可以记录各种所需的信息。

局限性: 需要精心设计和管理日志记录策略,否则会产生大量无用数据。分析日志数据需要强大的工具和技术,如ELK栈。日志数据分散,难以直接构建因果关系,需要结合其他数据进行综合分析。

  • 事件监控(Event Monitoring):

优点: 可以实时监控系统中的各种事件,如错误、警告等,帮助快速响应和处理异常事件。

局限性: 事件监控通常是离散的,难以直接构建事件之间的因果关系。需要结合历史数据和上下文信息进行分析和推断。

利用eBPF技术获取北极星指标

北极星因果指标的获取依赖于先进的分布式追踪技术和内核级数据关联。具体过程如下:

  1. 分布式追踪: 首先,通过分布式追踪技术,捕获每个请求的完整路径信息。这包括请求在不同服务节点之间的传递和处理时间。
  2. eBPF在内核追踪线程信号: 在系统内核中,追踪执行请求的线程信号。这些信号反映了线程在处理请求过程中的各个状态变化和资源使用情况。
  3. eBPF在内核实现系统调用信号关联: 将分布式追踪数据与系统调用信号关联起来,形成对请求处理全过程的详细分解。这一步骤涉及将应用层的请求数据与内核层的系统调用数据进行关联,确保每个请求的所有资源使用情况都被捕获和分析。

通过这种方法,我们能够生成北极星因果指标。该指标不仅提供了各个性能指标的详细数据,还展示了它们之间的因果关系,从而帮助工程师快速定位故障根源,提升排障效率。

北极星因果指标的组成: 一次业务视角的请求耗时被完美且完整拆解成以下指标

CPU耗时

  • 定义和意义

○指请求在CPU上消耗的时间。

  • 如何影响请求处理

○高CPU耗时可能指向计算密集型任务比如循环和递归。

网络耗时

  • 定义和意义

○指请求在网络传输中消耗的时间。

  • 如何影响请求处理

○高网络耗时可能指向网络延迟、带宽不足或下游节点代码执行异常,典型的就是SQL语句执行慢。

文件读写耗时

  • 定义和意义

○指请求在文件系统读写操作中消耗的时间。

  • 如何影响请求处理

○高文件读写耗时可能指向磁盘I/O瓶颈或文件系统问题。

内存消耗耗时

  • 定义和意义

○指请求在内存分配和管理中消耗的时间。

  • 如何影响请求处理

○高内存耗时可能指向内存泄漏、内存分配不当或频繁触发Pagefault。

锁耗时

  • 定义和意义

○指请求在等待锁资源中消耗的时间。

  • 如何影响请求处理

○高锁耗时可能指向锁争用、死锁或锁机制设计不合理, 绝大多数都是代码类库使用了隐藏锁而开发人员不自知,比如数据库连接池锁等。

GC耗时

  • 定义和意义

○指请求在垃圾回收过程中消耗的时间。

  • 如何影响请求处理

○高GC耗时可能指向内存管理不当或垃圾回收频繁触发。

CPU调度耗时

  • 定义和意义

○指请求在执行过程中,由于CPU调度而产生的延时

  • 如何影响请求处理

○高CPU调度耗时,意味着容器的CPU资源不充分。

为什么北极星因果指标是排障的最关键指标

基于北极星因果指标排障,立刻获得了多个性能指标的关联分析结果,有了系统的整体视图。

北极星因果指标具有以下独特优势:

  • 因果性:

○北极星指标通过数据关联和因果关系分析,提供了请求处理过程中的详细分解。各个指标之间的因果关系明确,能够帮助工程师快速定位问题根源。

  • 全面性且无盲区遗漏:

○北极星指标覆盖了请求处理的全过程,从CPU耗时、网络耗时、文件读写耗时,到内存消耗耗时、锁耗时和GC耗时,确保了指标的全面性并且没有盲区。

  • 高效性:

○通过提供因果关系视图,北极星指标可以快速定位故障根源,减少排障时间和降低排障复杂性。工程师无需逐一排查每一个可能的原因,而是能够通过整体视图快速确定问题所在。

  • 一体化视图:

○北极星指标将多个独立的性能指标整合为一体化视图,便于综合分析和决策。这样,工程师在查看指标时,不再需要切换不同的监控工具,而是可以在一个视图中看到所有关键性能指标及其关联关系。


总结

北极星因果指标的引入,彻底改变了故障排查的方式。通过提供因果关系和全面视图,它不仅提升了排障效率,还显著减少了排障过程中的盲目性和试错成本,真正实现了高效、精准的故障排查。

●永久免费

●多语言支持:Java、Python、Nodejs、一键安装

●标准PQL语句查询数据

Originx 创新解法——应用依赖故障篇

· 阅读需 17 分钟
Kindling-OriginX
故障根因推理引擎

依赖故障指应用运行所依赖的环境包括网络、中间件、缓存故障导致应用出现故障。这部分故障的根因并不是应用代码的问题,但是其最终表现形式和应用代码故障表现形式类似,很难区分。本文重点呈现Originx如何针对应用环境所依赖的故障进行根因分析,之前的系列文章请参考:

之前的系列文章: 在线业务的常见全栈故障种类与定位手段

文章中对常见的全栈故障的传统定位方法进行了阐述。

Originx的创新解法之:应用程序故障篇

文章中呈现了如何利用Originx的功能对应用程序故障的根因定位。

网络故障

网络连接中断、延迟或丢包

○ 案例:2023年4月,某互联网金融云平台因内部容器云平台的COREDNS服务器群集发生异常,导致整个私有云内的核心交易系统无法正常解析内部服务地址。在接下来的3个小时内,平台的放贷、风控等多个交易系统出现大面积延迟和连接中断,账户查询、委托下单等关键业务无法正常使用。据初步统计,这次故障给金融机构带来的直接经济损失高达数亿元人民币。最终通过手动配置绕过DNS解析,临时恢复关键系统连接,但整体恢复所需时间超过10个小时。事后分析发现,DNS集群全军覆没是由于COREDNS升级之后的bug导致,但是没有完善的监控导致故障发现严重滞后。

如果出现案例描述中的网络故障,需要安装专业的网络流量监控工具,并配备相关专业网络专家才能很好分析出问题。此外,网络监控的基线是非常难建立的,以丢包为例,出现丢包就应该告警吗?那会产生非常多的错误告警

Originx轻松能够帮助用户分析出根因:

Originx的解决之道:

1、在Originx首页,Originx的SLO告警就会针对SLO违约告警

2、同时会分析出可能的故障根因节点,当点击详情之后,每个节点的故障初因列表会被呈现出来

3、根据依赖关系,在疑似的故障根因节点中找到最下游疑似故障节点的故障初因列表,故障初因为“请求下游节点耗时长”,其上游节点多半初因也是这个初因特征,但是上游节点更大概率是由于故障节点级联影响导致,所以应该先验证下游节点的故障根因之后,再排查上游节点的故障根因

4、在故障报告的报告头部呈现的是故障概览,这里关联了TraceId以及发生的时间,如果有必要可以使用TraceId去关联分析Tracing数据

5、在故障报告左边栏中,确认故障传播链路,近似于下图,通过这个数据可以确认在此次报告中故障节点判定是否正确

6、在故障根因中,能够看到根因结论,在多份报告中看到同样的根因报告,这个时候其实可以采取应急手段来恢复业务了,针对本案例的情况: 应急手段就是迁移应用或者切流量了,具体应急措施要看企业之前应急措施准备了哪些条件,如果什么应急手段都没有准备,而且又在云上,可以向云厂商提交工单请求协助处理

7、在故障报告中,以下的数据都是为了提供证据链条来确认故障报告的准确性

北极星指标(通过北极星指标,Originx给出了异常幅度最大的异常方向,本截图的方向就是网络方向,反映出问题有两种可能,是网络真实有问题也可能是下游执行程序缓慢,网络可能存在真实问题,或者下游执行程序运行缓慢。在后续的分析中,我们将通过评估网络质量来确定是否确实存在网络问题)

接下来会列出所有程序在此次请求中执行过的所有网络请求(某些APM产品可能没有实现插裝就发现不了一些隐藏的网络调用,而Originx从内核判断网络,所有的网络调用一定会出现在这里)

接下来,将深入分析网络请求中耗时最长的部分,以精准定位网络层面的时间损耗原因。(此截图反映网络故障出现在容器网络pod,也就是容器网络有问题)

之后就是通过网络质量指标丢包和延时来进一步证实

同时还会判断网络拥塞指标,如果当时节点的CPU快耗尽的时候,虚拟网络也会出现丢包,重传的现象

网络配置错误

○ 案例:2022年12月,世界杯决赛期间,某大型视频直播平台由于网络设备配置问题,导致导致网络丢包比例较大,数百万在线用户观看比赛直播受到严重影响,画面频频卡顿中断。该故障持续近2小时,给平台带来了广告收益损失,也影响了品牌声誉。经过紧急处理和优化,网络质量逐步恢复,但已错过了决赛最关键时段。

如果出现案例描述中的网络故障,是交换机的配置错误导致丢包增加,排障流程和之前所说的网络故障是一样的,唯一的区别就是交换机等物理设备导致网络出现重传和丢包之时,故障耗时是在物理网络段,而不是在虚拟网络段。(由于没法用TC模拟出物理网络出现问题,所以没有办法贴出物理网络有延时的截图,如果真实物理网络有问题应该反映在下图中标红的位置)


缓存故障

缓存命中率下降

○ 案例:2023年6月8日早高峰,某知名新闻平台首页及文章详情页出现加载延迟、频繁超时。原因是缓存服务配置错误导致数据过早过期,高流量下未能及时刷新,与数据库产生数据不一致。经紧急调整缓存策略,禁用部分过期机制并扩容缓存集群,系统逐步恢复。但此次事故影响约200万访问,广告收益损失近百万元。

如果出现案例描述中的缓存命中率下降故障,Originx暂时没有直接给出根因结论。但是Originx仍然能够助力用户更高效的排查出故障根因。缓存命中率下降,意味着程序执行需要额外执行数据查询操作,还有更新缓存操作,这些额外的操作会导致程序执行时的网络时间相较于正常情况有所增加,所以在表现形式上和网络故障很像

Originx的解决之道:

1、在Originx首页,Originx的SLO告警就会针对SLO违约告警

2、同时会分析出可能的故障根因节点,当点击详情之后,每个节点的故障初因列表会被呈现出来

3、根据依赖关系在疑似的故障根因节点中找到最下游疑似故障节点的故障初因列表,故障初因应该都是“请求下游节点耗时长”,其上游节点多半初因也是这个故障初因特征,考虑级联影响,应该先验证下游节点的故障

4、在故障报告的报告头部呈现的是故障概览,这里关联了TraceId以及发生的时间,如果有必要可以使用TraceId去关联分析Tracing数据(具体截图可以参考之前的案例)

5、在故障报告左边栏中,确认故障传播链路,通过这个数据可以确认在此次报告中故障节点判定是否正确(具体截图可以参考之前的案例)

6、在故障根因报告中,由于Originx现在推理流程还未覆盖缓存对比,现在能看到的报告很可能是未分析出故障根因,如下图所示。故障初因是下游调用耗时长,点击故障报告分析并没有直接给出故障结论,但是初因的结论是准确的,因为实际上网络指标没有任何异常,而且下游节点也没有线程被打满。Originx的推理流程还未覆盖此场景,在不久将来会覆盖此种场景,该场景主要会对比异常网络调用次数和正常网络调用次数,从而判断缓存失效的场景。该故障报告仍然是有用的,可以看出很多问题

7、通过对比北极星指标和具体网络调用次数,可以发现所有的网络调用的执行过程,从中可以发现比正常调用多出了数据库的调用,和缓存调用


消息队列故障

消息堆积或消费者延迟

○案例:2023年5月15日,某知名电商平台消息中间件所在一台服务器磁盘出现坏道,导致消息写入延迟超10秒。高峰期部分订单消息阻塞,下游服务处理速度骤降80%,造成大量订单挤压及库存操作失败。由于该故障出现较少,SRE专家没有经验,排查期很长,长达1小时才排查出有问题的消息中间件实例,最后经磁盘热插拔修复坏道、调大消息队列容量等应急措施,系统逐步恢复。

如果出现案例描述中消息中间件交互延时下降的场景,不管中间件是由于案例中磁盘坏道导致,还是其它原因导致的,都应该会出现和网络时延类似的场景,故障初因表现为“请求下游节点耗时长”

Originx正在努力支持各种中间件,力争能够针对各种中间件直接给出原因,在还没有覆盖的场景中,仍然可以通过类似于缓存分析的方法,通过分析网络调用细节,从而得到故障根因。具体使用方式和缓存命中率下降是一样的


外部依赖故障

下游第三方服务调用延迟或失败

○案例:2023年7月6日,某金融科技公司接入第三方支付平台时,遭遇DNS故障导致解析异常,支付请求被调度至香港远程服务节点,网络延时高达200毫秒。当日下午2点开始,订单高峰期大量请求超时失败,支付接入率仅30%。经过一天的排查,终于确定了是第三方支付的DNS解析出现问题,临时固定域名,调用国内支付接口。但仍损失千万元订单手续费收入。

常规公司一般都会对第三方调用做监控,比如利用一些程序做周期访问来判断第三方服务是否正常,如果不正常即告警报错。这种方法固然能够起到一定作用,但是遇到案例中的问题还是比较麻烦,会先入为主的判断第三方服务是没有问题,但是实际业务程序在执行第三方调用和监控程序执行第三方调用并不是按照同一套DNS解析结果执行,这样带来的后果实际两者执行效果不一致。这种问题隐藏很深,很难发现

Originx的排障逻辑其实是一致的,就是当成下游调用去判断,并且得到真实的网络调用IP去判断,如果发现客户端调用异常的数据,然后还会同时判断网络质量是不是正常,最终给出结论,本质上和消息队列故障是一样的判断逻辑

用户仍然是从调用下游耗时长的故障初因切入,然后分析报告得到结论

Originx 的创新解法之:应用程序故障篇

· 阅读需 21 分钟
Kindling-OriginX
故障根因推理引擎

Originx 并不期望做一个完整覆盖全栈的监控体系,而是利用北极星指标体系标准化找出故障方向,然后联动各种成熟的监控数据形成证据链条,并将各种数据融合在一个故障报告之中。更多信息请参考文章 Log | Metrics | Trace 的联动方式探讨

Oringinx 智能化实现全栈故障定位

Originx 的设计目标是力争实现全栈故障种类的定位,自身的 eBPF 探针采集北极星排障指标,然后北极星排障指标引导到故障根因,Originx 的核心工作原理请参考下方网址或者或者扫描下方二维码 http://u6v.cn/6wIL7w

在已经识别出故障方向之后,利用各种成熟的开源监控作为数据来源,形成完整的证据链条,最终形成用户能够直接使用的故障根因报告。

下面我们将呈现如何利用 Originx 的功能实现应用程序故障的根因定位。


应用程序故障

代码缺陷导致应用崩溃或错误

○ 案例:2023 年双 11 期间,某汽车在线订单平台的 Tomcat 服务节点出现了严重的线程池耗尽问题。事发当天上午 10 点多,随着大促活动的用户流量激增,结算服务的响应时间明显下降。到中午时,大量来自北京地区的用户反馈在提交订单结算时,页面卡顿严重,部分直接超时失败。经过一天的紧张排查,最终发现是 Java 结算模块存在循环等待的死锁问题。该模块中存在太多的锁粒度,再加上连接池等配置不合理,并发压力下更容易发生死锁。临时解决方案是扩容结算服务的资源,并重启 Tomcat 释放线程。次日即行修复死锁代码,并持续优化相关模块的并发能力。这次事故虽然只持续了一天,但给用户造成了极差的下订体验

如果出现案例描述中 Tomcat 服务节点由于代码锁粒度太大出现了严重的线程池耗尽问题, Originx 轻松能够帮助用户分析出根因:

Originx 的解决之道:

1、在 Originx 首页,Originx 的 SLO 告警就会针对 SLO 违约告警

2、同时会分析出可能的故障根因节点,当点击详情之后,每个节点的故障初因列表会被呈现出来

大概率是真实故障原因的疑似故障根因节点效果如下:(因为真正故障点的初因应该是一致的,或者有极少数的初因不一致的情况)

被级联影响的疑似故障根因节点效果如下:(Originx 会将 Trace 数据中突变变化前 3 的节点当成疑似根因节点,所以被级联影响的节点由于突变较大大概率会被当成疑似节点,而被级联影响的故障根因点大部分初因应该是下游节点耗时长,同时也可能存在因为采用池化调用框架导致出现隐藏锁而得到初因为锁的情况)

Originx 下个版本会呈现所有疑似根因的依赖关系,这样就能让人更好的理解谁是根因节点了,大概率是被依赖最深的节点,但是其他节点的根因报告不能完全忽略,最好能够也随机花几秒钟查看下其他根因报告

3、在确认故障根因节点之后,可以从故障根因节点的任意根因报告中查看根因报告详情

4、在故障报告的报告头部呈现的是故障概览,这里关联了 TraceId 以及发生的时间,如果有必要可以使用 TraceId 去关联分析 Tracing 数据

5、在故障报告左边栏中,确认故障传播链路,近似于下图,通过这个数据可以确认在此次报告中故障节点判定是否正确

6、在故障根因中,能够看到根因结论,在多份报告中看到同样的根因报告,这个时候其实可以采取应急手段来恢复业务了,针对本案例的情况:比如重启应用或者扩容,具体的应急策略需要根据公司的政策来确定,有些企业的业务是不能重启的,那就只能扩容,有些企业的资源是有限的,那就只能在对业务影响最小的时候重启

7、在故障报告中,以下的数据都是为了提供证据链条来确认故障报告的准确性

日志数据,关联了 Trace 在节点执行(也就是故障概览呈现的故障发生时间)时间段的日志数据

北极星指标(通过北极星指标,Originx 给出了异常幅度最大的异常方向,本案例的方向就是 Futex 也就是锁的方向)

由于北极星指标已经明确了异常方向是锁的方向,所以以下的证据链条会重点分析锁的方向。在 JVM 实现中,GC 也会采用内核 Futex 机制来实现线程等待,所以当分析 Futex 异常之时,Originx 会先确认此时是否发生了 GC,如果有 GC 发生,就会关联 GC 相关的数据

接下来 Originx 会关联程序锁的相关数据

在锁具体相关信息中,可以看到锁的执行堆栈

8、总结:通过锁的堆栈分析,可以确认程序出现了长时间的锁,这个时候可以进行 patch 快速修复,或者回滚代码至之前的版本规避锁的问题,或者扩容来人为提高并发


资源不足(CPU、内存、磁盘)

○  案例: 2023 年 5 月 12 日,一家大型商业银行的新版网上银行系统在上线后不久遭遇了某些业务场景执行超时的错误。由于代码中存在一个未被发现的逻辑错误,导致在特定参数组合场景下,系统会重复执行某项业务逻辑,造成 CPU 使用率异常飙升。这种情况在测试环境中难以复现,因此未被及时发现。故障发生后,客户在进行转账和查询等操作时遇到了明显的延迟,严重时甚至导致服务不可用。银行紧急协调开发团队进行排查,在生产环境中利用 jstack 等工具查找 CPU 飙升的原因,最终在 4 小时内定位到了问题源头。通过快速发布补丁修复了 BUG,并重新部署了服务。此次事件导致银行损失了大量客户交易,并对其声誉造成了一定影响

如果出现案例描述中代码在某些参数特定组合场景下,导致代码会递归执行导致 CPU 飙高,人为分析是比较困难的,只能等待场景复现才能去故障现场使用 jstack 等命令分析 CPU 高的线程在干什么,Originx 轻松帮助用户分析出根因:

Originx 的解决之道:

1、在 Originx 首页,Originx 的 SLO 告警就会针对 SLO 违约告警

2、同时会分析出可能的故障根因节点,当点击详情之后,每个节点的故障初因列表会被呈现出来

3、根据不同节点的初因情况来确认根因节点,在这种案例中根因节点会是以下几种情况:

根因节点的表现形式应该有“初因 CPU 耗时长”的报告,同时根据容器或者虚拟机的资源规格,如果资源规格较小,CPU 资源不足,就会出现很多请求“等待调度 CPU 耗时长”的初因表现

注意过滤掉其他受影响的级联节点,如果不确定节点是否是被级联影响,可以查看根因报告,稍微花个一分钟确认下

4 、在故障报告的报告头部呈现的是故障概览,这里关联了 TraceId 以及发生的时间,如果有必要可以使用 TraceId 去关联分析 Tracing 数据(具体截图可以参考之前的案例)

5、在故障报告左边栏中,确认故障传播链路,近似于下图,通过这个数据可以确认在此次报告中故障节点判定是否正确(具体截图可以参考之前的案例)

6、在故障根因中,能够看到根因结论,在多份报告中看到同样的根因报告,这个时候其实可以采取应急手段来恢复业务了,针对本案例的情况:

比如回滚或者扩容,具体的应急策略需要根据公司的政策来确定,有些企业的业务是不能回滚的,那就只能扩容

7、在故障报告中,以下的数据都是为了提供证据链条来确认故障报告的准确性

日志数据这里不再截图和之前案例类似

北极星指标(通过北极星指标,Originx 给出了异常幅度最大的异常方向,本截图的方向就是 CPU)

北极星指标(通过北极星指标,Originx 给出了异常幅度最大的异常方向,本截图方向就是 RunQ 方向,如果是 RunQ 方向,Originx 会同时查看 CPU 是否也突变了很大幅度, 如果 CPU 也突变了很大幅度,那说明 RunQ 的产生就是由于 CPU 消耗过高导致线程等待调度所致,如果 CPU 没有太大突变,说明是由于其它进程抢占 CPU 导致的调度等待)

如果是 RunQ 突变较大,还会关联 cpu_throuttled 相关指标来证明程序存在此问题

在 CPU 火焰图中可以看到哪些代码在循环执行


应用配置问题

○  案例: 2023 年 3 月 15 日,一家领先的金融支付服务公司遭遇了支付处理延迟的问题。由于对高峰时段的实例数扩缩容配置人为操作错误,导致在线支付服务的实例数量未能满足既定需求。在随后的高峰交易时段,支付系统出现了严重的延迟,部分交易无法完成,影响了客户的支付体验,并导致公司损失了数百万的潜在交易额。经过紧急扩展服务实例并重新配置负载均衡策略,服务在 2 小时内逐步恢复。此次事件突显了容量规划在金融服务中的重要性,并促使公司加强了对服务容量和性能监控的投资

如果出现案例描述中实例数配置出错导致不足以应对高峰流量时, Originx 轻松能够帮助用户分析出根因:

Originx 的解决之道:

1、在 Originx 首页,Originx 的 SLO 告警就会针对 SLO 违约告警

2、同时会分析出可能的故障根因节点,当点击详情之后,每个节点的故障初因列表会被呈现出来

3、根据不同节点的初因情况来确认根因节点,在这种案例中根因节点会是以下几种情况:

  • 此种情况并不常见,但是应用如果是CPU密集型的,产生以下这个现象还是非常有可能的。由于实例配置错误,扛不住流量高峰,表现为整个微服务链路上的容量瓶颈节点的出现CPU资源不足的初因,因为每个请求都需要消耗较多的CPU,流量高峰导致其CPU不足,从而产生以下这种根因节点。排查思路和资源不足思路基本类似。

  • 接下来讲的情况比较常见,对于绝大多数在线业务而言是IO密集型,所以当实例配置错误,扛不住流量高峰,表现和第一种情况不一致。表现出来是故障根因节点的上游节点出现很多调用下游的故障初因。主要原因是由于非CPU密集型不会消耗很多的CPU,但是其线程数量有限,每个线程都会被消耗在某些网络IO等待上,这里和锁场景又不一样,并不会产生很多代码锁。如果从APM视角来看就是发现客户端执行时间很长,服务端执行时间完全不匹配客户端执行时间的APM经典问题。如果从网络监控来看,能够看出故障节点有问题,但是并不清楚为什么有问题,也不知道该如何应急和复盘。本质的原因是故障节点由于配置错误,导致在流量高峰时所有的业务线程都被耗尽,但是由于Accept线程和IO线程仍然能够读取请求,只是找不到可用线程来处理业务,所以看到的现象是server端网络时间比Trace开始时间早一段时间。在Originx未来规划中,会接入线程满指标,这样结合线程满指标和下游节点耗时长更容易确认故障根因节点。

4、  在故障报告的报告头部呈现的是故障概览,这里关联了 TraceId 以及发生的时间,如果有必要可以使用 TraceId 去关联分析 Tracing 数据(具体截图可以参考之前案例)

5、在故障报告左边栏中,确认故障传播链路,近似于下图,通过这个数据可以确认在此次报告中故障节点判定是否正确(具体截图可以参考之前案例)

6、在故障根因中,能够看到根因结论,在多份报告中看到同样的根因报告,这个时候其实可以采取应急手段来恢复业务了,针对此种故障,恢复业务最好的手段就是扩容。这个故障其实还有其他几个可能,就是故障执行了长时间的 GC 导致线程不能执行,产生同样的现象。如何区分 GC 和线程慢?就是 GC 一般不会分布超过一分多钟,如果同样故障根因的故障报告分布在不同的时间段,那就明确了故障就是线程满

7、在故障报告中,以下的数据都是为了提供证据链条来确认故障报告的准确性

北极星指标(通过北极星指标,Originx 给出了异常幅度最大的异常方向,本截图的方向就是网络)

然后列出来所有的对外网络调用,这个网络调用是从内核层获取,可能会比 APM 看到的数据要多

针对最长的网络层面耗时,会对耗时进行分析,判断网络到底消耗在哪个网卡,我们可以看到标红的时间段说明了这段时间就是由于没有业务线程处理业务请求导致请求被 io 读取之后,而产生的额外时延

为了进一步证实不是由于网络导致的故障,会关联网络重传和丢包指标以证明网络没有问题

在线业务的常见全栈故障种类与定位手段

· 阅读需 18 分钟
Kindling-OriginX
故障根因推理引擎

在线系统的稳定性和可靠性是企业数字化转型成功的关键。然而,由于云环境和系统演进的复杂性,故障的发生几乎不可避免。本系列文章将对在线系统可能遇到的全栈故障进行分类,并结合网上的案例分析,对比常规分析诊断手段与Originx推理引擎是如何能够轻松找到全栈故障的根因。

本文为该系列的第一篇,主要介绍常见故障以及全栈故障定位的难点,后续系列文章将重点介绍如何使用Orginx高效定位故障。

常见故障分类与常规的分析定位手段

应用程序故障

代码缺陷导致应用崩溃或错误

○ 案例:2023年双11期间,某汽车在线订单平台的Tomcat服务节点出现了严重的线程池耗尽问题。事发当天上午10点多,随着大促活动的用户流量激增,结算服务的响应时间明显下降。到中午时,大量来自北京地区的用户反馈在提交订单结算时,页面卡顿严重,部分直接超时失败。经过一天的紧张排查,最终发现是Java结算模块存在循环等待的死锁问题。该模块中存在太多的锁粒度,再加上连接池等配置不合理,并发压力下更容易发生死锁。临时解决方案是扩容结算服务的资源,并重启Tomcat释放线程。次日即行修复死锁代码,并持续优化相关模块的并发能力。这次事故虽然只持续了一天,但给用户造成了极差的下订体验。

○ 定位方法:人为分析日志,分析代码,对线程池进行监控,对代码定制化锁的监控(很难实现,没有办法覆盖所有场景

资源不足(CPU、内存、磁盘)

○ 案例:2023年5月12日,一家大型商业银行的新版网上银行系统在上线后不久遭遇了某些业务场景执行超时的错误。由于代码中存在一个未被发现的逻辑错误,导致在特定参数组合场景下,系统会重复执行某项业务逻辑,造成CPU使用率异常飙升。这种情况在测试环境中难以复现,因此未被及时发现。故障发生后,客户在进行转账和查询等操作时遇到了明显的延迟,严重时甚至导致服务不可用。银行紧急协调开发团队进行排查,在生产环境中利用jstack等工具查找CPU飙升的原因,最终在4小时内定位到了问题源头。通过快速发布补丁修复了BUG,并重新部署了服务。此次事件导致银行损失了大量客户交易,并对其声誉造成了一定影响。

○ 定位方法:借助java分析工具,在故障能复现的时机,人为分析问题

应用配置问题

○ 案例: 2023年3月15日,一家领先的金融支付服务公司遭遇了支付处理延迟的问题。由于对高峰时段的实例数扩缩容配置人为操作错误,导致在线支付服务的实例数量未能满足既定需求。在随后的高峰交易时段,支付系统出现了严重的延迟,部分交易无法完成,影响了客户的支付体验,并导致公司损失了数百万的潜在交易额。经过紧急扩展服务实例并重新配置负载均衡策略,服务在2小时内逐步恢复。此次事件突显了容量规划在金融服务中的重要性,并促使公司加强了对服务容量和性能监控的投资。

○ 定位方法:人为分析日志,分析代码,结合资源使用指标(单纯依赖CPU、内存、磁盘指标很难发现实例不够)


数据库故障

数据库连接问题

○ 案例:2022年春节假期前最后一个工作日,某大型在线商城的数据库连接池曾出现被耗尽的严重故障。当天上午10点前后,随着流量的激增,商城首页以及各大类目页的查询请求突然出现大量超时和失败。SRE在慌乱中排查了30分钟,最终确定是数据库连接池的问题,由于促销引起了流量波动,而数据库连接池配置仍是原来配置并不足以支撑大流量,可用连接资源在高峰时段几乎被同时耗尽所致。

○ 定位方法:建立数据库连接池监控关键指标

性能瓶颈(锁、查询等)

○ 2022年8月20日,某知名在线旅游预订平台出现数据库死锁导致机票预订业务中断数小时。高峰期时大量并发订单涌入,引发系统内部事务互相等待访问同一资源,造成死锁并耗尽连接池。经过大面积业务重启,瘫痪2小时之后才恢复。事后,该平台对业务代码进行重构优化, 从根本解决死锁风险。此次事故造成约2000万元订单收入损失。

○ 定位方法:建立数据库监控,建立死锁监控找到初始SQL语句的应用实例

网络故障

网络连接中断、延迟或丢包

○ 案例:2023年4月,某互联网金融云平台因内部容器云平台的COREDNS服务器群集发生异常,导致整个私有云内的核心交易系统无法正常解析内部服务地址。在接下来的3个小时内,平台的放贷、风控等多个交易系统出现大面积延迟和连接中断,账户查询、委托下单等关键业务无法正常使用。据初步统计,这次故障给金融机构带来的直接经济损失高达数亿元人民币。最终通过手动配置绕过DNS解析,临时恢复关键系统连接,但整体恢复所需时间超过10个小时。事后分析发现,DNS集群全军覆没是由于COREDNS升级之后的bug导致,但是没有完善的监控导致故障发现严重滞后。

○ 定位方法:对应用日志和网络流量做监控,单独定制DNS解析关键指标

网络配置错误

○ 案例:2022年12月,世界杯决赛期间,某大型视频直播平台由于网络设备配置问题,导致导致网络丢包比例较大,数百万在线用户观看比赛直播受到严重影响,画面频频卡顿中断。该故障持续近2小时,给平台带来了广告收益损失,也影响了品牌声誉。经过紧急处理和优化,网络质量逐步恢复,但已错过了决赛最关键时段。

○ 定位方法:网络流量监控,对网络交换机、路由器建立监控体系


缓存故障

缓存命中率下降

○ 案例:2023年6月8日早高峰,某知名新闻平台首页及文章详情页出现加载延迟、频繁超时。原因是缓存服务配置错误导致数据过早过期,高流量下未能及时刷新,与数据库产生数据不一致。经紧急调整缓存策略,禁用部分过期机制并扩容缓存集群,系统逐步恢复。但此次事故影响约200万访问,广告收益损失近百万元。

○ 定位方法:建立APM监控体系,检查Trace的缓存访问次数和延时数据

消息队列故障

消息堆积或消费者延迟

○案例:2023年5月15日,某知名电商平台消息中间件所在一台服务器磁盘出现坏道,导致消息写入延迟超10秒。高峰期部分订单消息阻塞,下游服务处理速度骤降80%,造成大量订单挤压及库存操作失败。由于该故障出现较少,SRE专家没有经验,排查期很长,长达1小时才排查出有问题的消息中间件实例,最后经磁盘热插拔修复坏道、调大消息队列容量等应急措施,系统逐步恢复。

○ 定位方法:建立APM监控体系 队列监控、人为分析日志

外部依赖故障

下游第三方服务调用延迟或失败

○案例:2023年7月6日,某金融科技公司接入第三方支付平台时,遭遇DNS故障导致解析异常,支付请求被调度至香港远程服务节点,网络延时高达200毫秒。当日下午2点开始,订单高峰期大量请求超时失败,支付接入率仅30%。经过一天的排查,终于确定了是第三方支付的DNS解析出现问题,临时固定域名,调用国内支付接口。但仍损失千万元订单手续费收入。

○ 定位方法: 建立APM监控体系,同时在日志中建立关键指标

基础架构故障

硬件故障(服务器、存储、网络设备)

○案例:2022年6月18日,618购物节期间, 某电商北京西单数据中心两台机架服务器主板同时发生故障,导致一个重要的订单系统服务中断。受影响的约6000名用户在下单支付环节遭遇失败,由于这个服务与商品库存管理直接相连,错过这个高峰期将可能导致损失数亿元营收。经过5小时的故障排查和系统切换,终于恢复正常。此次事故再次凸显了硬件冗余以及容灾能力对于电商业务的重要性。

○ 定位方法:硬件监控体系的建设

系统软件故障(操作系统、虚拟化层、软负载)

○案例:2023年3月,某热门视频直播平台在一场体育赛事直播过程中,由于负载均衡器组件发生故障,无法正确分发流量至下游转码服务器集群,导致部分转码节点超负荷宕机。此次事故造成大量用户无法观看直播画面,持续约2小时。经过现场工程师的快速响应和临时调度,负载得以重新分配,服务逐步恢复。但由于高峰期直播中断,给平台带来了可观经济损失和品牌声誉影响。事后分析发现,除了流量突发之外,负载均衡器在高压力下表现异常也是导致故障的重要原因。

○ 定位方法:研究中间件负载均衡器的指标体系,构建软负载的监控指标体系


覆盖全栈的监控体系建设和使用难度都很高

假设我们有能力建设一套统一的全栈监控体系和运维大数据平台,但对使用者而言,全栈系统仍存在以下两个主要难点:

使用难度高

数据量与信息过载: 在云环境下,监控系统的数据生成速度和体量是巨大的。这不仅涉及到数据的海量收集,更在于如何从这些数据中迅速提取出真正有价值的信息。用户面临的挑战是,要在不断涌入的数据流中,识别哪些是关键性能指标的异常,哪些是日常波动的“噪声”。信息过载不仅仅是技术问题,它还可能导致决策迟滞,增加操作复杂性,甚至可能掩盖真正的系统问题。

人员技能与知识要求: 全栈监控体系要求使用者不仅要对单一技术有深入了解,还要对整个技术栈有全面的认识。在技术迭代迅速的今天,要求团队成员不断学习新技术、新工具,并能够将这些知识应用于问题的诊断和解决中。这种跨领域的知识要求对人才的选拔和培养提出了更高的标准,同时也增加了团队管理的难度。

团队协作难: 在故障排查的时候,全栈的监控体系不同模块可能由不同团队或个人管理维护,比如网络团队、硬件团队、应用团队等。但是,由于噪声的存在,不同人对故障可能有不同理解,容易出现相互推诿的情况,导致故障排查难以找到真凶。

建设难度高

实际上,建设统一的全栈监控体系也是很难的,主要难点体现在:

数据存储与管理的现实性: 期望一个单一的存储系统能够无缝地处理所有类型的可观测性数据(如日志、指标、追踪等)是不现实的。每种数据类型都有其特定的存储需求和访问模式,这就要求存储解决方案必须具备高度的可扩展性和灵活性。同时,数据的生命周期管理、安全性和合规性也是需要重点考虑的因素。

技术整合的持续性: 技术的不断演进要求监控系统能够适应新的工具和服务。这不仅仅是一个技术问题,更涉及到组织的战略规划和资源分配。随着新组件的引入,现有的监控架构可能需要不断地调整和优化,以保持其有效性和相关性。这个过程需要持续的投入,包括时间、资金以及专业知识。

解密北极星指标体系如何实现根因分析

· 阅读需 8 分钟
Kindling-OriginX
故障根因推理引擎

解密北极星指标体系如何实现根因分析

在之前的文章中提过我们的观点,AIOps实践中常见的挑战:故障根因与可观测性数据的割裂 认为依赖算法给出根因建议缺乏可解释性,本篇文章重点介绍下我们的根因定位的思路, 按照这个思路去快速实现根因定位,我们认为是能够落地1-5-10的,如果对文章的思路有任何疑问,欢迎联系我们一起探讨。

为什么高效定位故障根因定位难

排障过程本质是我们拿着程序最后的执行结果去猜测验证程序执行异常的过程

当前人为定位故障主要依赖于指标告警,但是现在绝大多数指标反映的程序执行结果,并未对程序执行过程提供更多的信息。举例说明,CPU利用率是程序执行完代码之后的CPU的被使用的反映,内存利用率是程序已经使用内存的执行结果,所以排障过程本质是我们拿着程序最后的执行结果去探索程序执行异常的过程。

在探索程序执行异常的过程中,有哪些数据能反映程序执行过程呢?能反映程序执行过程数据目前常规就是日志以及各种事件(将APM数据称之为程序执行的事件数据,比如执行的代码堆栈、慢方法等)。

由于可观测性盲区的存在导致猜测验证过程依赖专家经验

不管是日志、APM数据所反映出程序执行过程其实都存在很多盲区,关于程序执行盲区,可以参考团队在KubeCon,eBPF大会等会议上分享内容。也可以参考可观测性工具的盲区与故障排查困局 这篇文章,里面有更加详细讨论。

什么数据能够对故障定位起到决定性作用

基于以上的论述,我们认为要能够实现故障定位的关键数据要满足以下特点:

  • 覆盖程序执行的盲区,不管程序任何操作都应该有数据能够和程序执行过程对应起来
  • 数据分类要足够抽象,便于排障的人员能理解,这点很重要因为团队之前拿着程序依赖内核的行为数据去和用户沟通之时,绝大多数开发不能理解这些数据,就别提用这些数据进行排障
  • 每个数据分类要足够隔离,不要相互影响

北极星指标体系是故障定位中的关键数据

北极星指标体系是基于TSA方法论得到的程序执行过程完整数据,关于TSA的方法论,有兴趣的朋友可以参考大神的博客,https://www.brendangregg.com/tsamethod.html 也可以参考这篇公众号的文章,TSA方法:基于线程时间分布分析性能瓶颈http://u6v.cn/5yDFVr

从这套方法论来看,采集的数据是覆盖了程序的完整执行过程,第一个要求满足了,那第二个要求就是我们将程序与内核交互的数据进行抽象而得到的。第三个就是因为我们是根据进程在操作系统上执行On与Off数据而来,所以数据是隔离没有影响的,这里也许有内核专家会疑惑比如由于网络包产生的软中断会消耗很多的CPU,所以CPU时间和网络时间不能隔离,但是我们是基于On与Off数据而来,由于网络包产生的软中断CPU消耗会被计算到ON的CPU时间之上,并能通过内核火焰图反应出最终的问题。

一次接口执行的北极星指标

围绕着北极星排障指标的建模

在有了一次接口执行的北极星数据之后,我们可以对历史数据进行基线判断,也就可以形成以下的数据

当某一次异常执行过程和基线对比之后,我们可以很快知道故障方向,比如以下的示例,问题明显就是文件方向:

问题:多分项的异常怎么办?

同时出现CPU耗时超出历史基线和net耗时超出历史基线怎么办?该往哪个方向排查?

针对一次请求的异常,我们认为应该聚焦突变最大的异常,所以只会关心突变最大的异常方向,但是并不是忽略其他突变的异常,对于根因定位而言,不能因为一次请求的异常就完全定出根因,应该对请求进行全面的分析。其它异常突变的分项如果真的是根因,在其它请求中一定也会有所反应,而偶发的噪音在其它请求中就能被过滤掉。

基于北极星指标的初因判断

对于突变最大的异常,我们会做一个初因判断,也就是某单次请求的初因异常,这样每个异常请求都会一个初因的标签了。

对请求全面分析之后的节点级故障特征

单次请求的异常可能是偶发因素,但是对节点所有请求进行全面分析之后,并统计之后,就能够形成故障特征,准确度大幅提高。比如某节点其故障特征如下:

对该特征的解释如下:

  • 有些请求是幸运儿,没有经过长时间的锁等待就调用成功了下游服务节点,但是由于下游服务节点异常从而产生了网络调用耗时长的初因故障
  • 更多的请求由于对外调用连接池的限制,产生了长时间的锁等待,所以产生了锁等待的故障

所以对于该特征的节点,大概率不是故障根因节点,因为其长时间的等待都是由于下游故障而导致的。

AIOps实践中常见的挑战:故障根因与可观测性数据的割裂

· 阅读需 8 分钟
Kindling-OriginX
故障根因推理引擎

AIOps实践中常见的挑战:故障根因与可观测性数据的割裂

运维的挑战与责任

在数字化时代,运维团队面临的挑战前所未有。他们不仅要确保系统的高可用性和高性能,还要快速响应并解决故障,以减少对业务的影响。在这种背景下,运维团队急需工具和技术,能够帮助他们提高效率,减轻负担。AIOps(人工智能运维)应运而生,旨在通过应用人工智能和机器学习技术来自动化监控、预测、优化和故障排除过程。

AIOps实践中常见的挑战:故障根因与可观测性数据的割裂

AIOps当前技术与输出

AIOps核心功能包括事件聚合、异常检测、自动化根因分析等。这些技术能够帮助运维团队从海量的监控数据中快速识别问题,预测潜在故障,并自动化常见问题的解决过程。通过AIOps,许多组织已经显著提高了故障响应时间,减少了误报,优化了运维流程,提升了IT系统的整体可靠性和性能。

AIOps仍然存在挑战:故障根因与可观测性数据割裂

尽管AIOps技术取得了显著进步,但在故障根因分析方面仍面临一个重大挑战:故障根因与可观测性数据(如日志、指标、追踪)之间的割裂。AIOps系统虽然能够推荐可能的故障根因,但往往难以直接将这些推荐与具体的可观测性数据紧密关联。这就要求运维人员依靠自己的经验和知识,在海量的数据中寻找证据来验证这些推荐,这一过程既耗时又容易出错。

Gartner 魔力象限中领先象限做到的效果

Dynatrace 效果

Dynatrace 的AI故障推理效果和介绍详情可参见 Dynatrace 官方网站。

AIOps实践中常见的挑战:故障根因与可观测性数据的割裂

从 Dynatrace 的视频中,如果发生了故障之后,AI推荐出AI根因之后,用户仍然需要使用根据 Visual resolution path 去从众多的Trace以及各种可观测性数据中筛选出证据来证明这个AI的推断。

Dynatrace 做到全球最牛的地方,就是能够将各种可观测性数据融为一体,并以时间线为维度还原故障现场,这个本质上还是人为分析,所谓的AI推荐,给出的是关键节点。

如果没有这个故障根因推荐,用户使用 Dynatrace 怎么做呢?仍然是围绕着故障时间点,利用 Dynatrace 的 Visual resolution path 人为分析故障根因。

结论:故障根因的推荐聊胜于无,还是需要人为在可观测性数据中分析找证据。

Datadog 效果

AIOps实践中常见的挑战:故障根因与可观测性数据的割裂

AIOps实践中常见的挑战:故障根因与可观测性数据的割裂

Datadog 的 Watchdog RCA给出仍然是可能性,具体从可观测性中找证据来证明这点,仍然需要用户自己来做。

结论:故障根因的推荐聊胜于无,还是需要人为在可观测性数据中分析找证据。

可观测性盲区的存在导致AIOps的根因结论与可观测性数据存在割裂

AIOps实践中常见的挑战:故障根因与可观测性数据的割裂

举例说明:Dynatrace 的根因例子为节点CPU利用率达到100%,其实绝大多数运维人员都能识别出100% CPU利用率是有问题的。但是如果CPU利用率是50%,这个时候人是很难判断程序是否会受到CPU供给瓶颈,需要额外提供更多的数据去判断CPU利用50%的时候,程序的执行是否会受到调度器的影响,这取决于很多因素,比如机器上需要调度的程序多少,CPU调度器排队的长度等,总而言之,可观测性数据存在盲区。

可观性数据由于存在盲区,导致人都很难根据可观测性数据推理出故障,只能根据事后的结论去关联出CPU利用率50%在某些场景下也是存在可能性导致故障根因的(资深运维人员在判断这两点的时候CPU利用率为50%,是故障根因也是需要非常深厚的经验)。

可观测性数据盲区更详细的介绍,请参考之前的文章。

内核视角持续剖析解决AIOps的故障根因结论与可观测性的割裂问题

在之前的文章介绍了可以使用内核视角下持续剖析,能够形成基于北极星指标的排障体系。可参见:内核视角下持续剖析 VS 代码视角下的持续剖析

AIOps实践中常见的挑战:故障根因与可观测性数据的割裂

基于这个标准化排障体系进行故障根因推导的时候,就能够同时自动化关联相关指标。比如如果发现网络时间很长,这个时候就可以关联网络相关性指标,必要时还可以同步 DeepFlow 等关键网络事件及数据,提供证据证明网络确实有问题。

Kindling-OriginX工作原理

· 阅读需 9 分钟

传统可观测性产品在落地过程中的局限性

很多公司已经落地了 Tracing、Metrics、Logging,但是在实际使用中效果不如预期主要由以下几个原因:

  • Tracing、Metrics、Logging 数据之间归属于不同产品,排查问题之时需要再不同产品之间跳转,对于问题排查效率影响较大。
  • Tracing、Metrics 对于开发和运维而言不熟悉,不会使用,对指标代表的技术含义理解不深入,最终排障都是依赖于专家牛人的个人经验。可观测性系统推广之后,业务团队使用起来效果差强人意。
  • 专家排障的时候也受限于已有经验,缺乏标准化流程,在不断猜测验证过程中,容易丢失掉 1-5-10 的目标。
  • 耗费人力和物力资源建设了一系列的可观测性项目,但是最终仍然很难落地1分钟识别故障、5分钟识别故障初因、10分钟回复业务。

什么是 eBPF 技术

eBPF(extended Berkeley Packet Filter)是一种先进的系统内核技术,最初源自于 Berkeley Packet Filter(BPF)。它是一种在 Linux 内核中执行高度优化的程序的框架,允许用户编写并插入小型程序(称为 eBPF 程序)来对系统内核的行为进行扩展和控制。 eBPF 允许用户在不更改内核源代码或重新编译的情况下,通过加载在内核中运行的小型程序来扩展内核功能。这些程序可以捕获和分析系统运行时的事件、执行网络分析、实现安全策略、执行性能调优等操作。 eBPF 的一些关键特性和优势包括:

  • 安全性:eBPF 程序在一个受限的虚拟机中运行,不会影响系统稳定性和安全性。
  • 灵活性:可以动态加载、卸载和更新eBPF程序,无需重新启动系统。
  • 性能:eBPF 程序经过优化,能够在内核中高效执行。
  • 可观察性:能够捕获和分析系统运行时的各种事件,有助于故障排除和性能分析。

eBPF 技术在多个领域得到应用,包括网络编程(例如网络包过滤、路由)、性能分析、安全监控、容器技术等。它已经成为许多现代系统中实现高级功能和控制的重要工具之一。

什么是 TraceProfiling 技术

用户开发的代码都是以线程形式运行在操作系统之上,即便Go语言有协程的概念,go协程在执行过程中仍然绑定在操作系统内核线程上执行。操作系统内核线程的完整运行周期如下图所示。

image.png

利用 eBPF 技术能够深入内核,拦截线程执行用户代码的关键点位获取信息,在获得线程执行关键信息之后能够还原线程的执行过程。 如果只从线程维度看程序执行过程是很难分析出故障的,因为开发和运维的谈的故障都是URL维度的用户请求调用,所以光有线程维度程序执行过程是不够的,需要和 Tracing 系统关联。 当线程执行过程与 Tracing 系统关联之后,即可完整还原用户一次请求的执行过程。 TraceProfiling中关联了可观测性所需要的数据:

  • 指标
  • 日志

北极星排障指标体系(龙蜥社区与 Kindling 社区联合发布了北极星排障指标体系)

通过分析 TraceProfiling 数据,能够得到一次请求在Span中执行具体花了多少时间在CPU、网络、存储、等待。将 TraceProfiling 数据进行聚合可以得到北极星排障指标体系,从而指导标准化的排障过程。 image.png

指标说明

北极星排障指标-CPU时间

程序在CPU资源上所消耗的时间

  • OnCPU

程序代码执行所消耗的CPU cycles,可以通过程序火焰图确认代码在 CPU上执行消耗的时间与代码堆栈.

  • Runqueue

线程的状态是Ready,如果CPU资源是充分,线程应该被调度到 CPU上执行,但是由于各种原因,线程并未调度到CPU执行,从而产生的等待 时间。

北极星排障指标-网络时间

网络时间属于两次OnCPU时间之间的OffCPU时间

  • 网络时间打标过程

第一次OnCPU最后一个系统调用执行为sock write与第二次 OnCPU第一个系统调用为sock read,也可以理解为网络包出网卡至网络包从网卡收回的 时间。

  • 网络时间分类

DNS,TCP建连,常规网络调用

北极星排障指标-存储时间

属于两次OnCPU时间之间的OffCPU时间

  • 存储时间打标过程

第一次OnCPU最后一个系统调用执行为VFS read/write与第二次 OnCPU第一个系统调用为VFS read/wirte。

  • 存储时间真实情况

存储真实执行情况,由于内核的pagecache存在,所以绝大多数VFS read/write从程序视 角看:执行时间不超过1毫秒。

北极星排障指标-等待时间

  • futex

通常指的是一个线程在尝试获取一个futex锁时因为锁已经被其他线程占用而进入等待状态的时间。在这段时间内,线程不会执行任何操作,它会被内核挂起。

  • mutex_lock

线程在尝试获取互斥锁时,因为锁已经被其他线程持有而进入等待状态的时间长度。这段时间对于程序的性能至关重要,因为在等待期间,线程不能执行任何有用的工作。

Kindling-OriginX 的故障根因推导

依据标准北极星排障指标体系,Kindling-OriginX 能够自动化推导出故障根因,从根本上解释一次请求慢的根源是在于CPU、网络、磁盘中的具体哪一部分。 Kindling-OriginX 不仅仅给出依据北极星排障指体系的故障根因,还将整个故障根因的推导过程呈现出来,帮助用户更好的理解系统运行的过程。 Kindling-OriginX 为了能够让结论更有可解释性,Kindling-Originx通过与Skywalking,deepflow, prometheus等数据对接获得更多的指标,并依赖专家经验自动化组织和关联分散的监控指标与日志,用户在一个界面就可以将所需要的指标与日志收集齐全,并确认故障根因是否推导合理。

更多信息参考

KubeCon 2023 中国 :Trace-Profiling: A New Way About How to Track Application Behavior - Cheng Chang

KCD 杭州 :基于 eBPF 采集的排障北极星指标构建故障根因推导流程

Log | Metrics | Trace的联动方式探讨

· 阅读需 9 分钟
Kindling-OriginX
故障根因推理引擎

可观测性三大支柱联动性不好

曾经询问已经使用可观测性相关软件的用户群体,对于他们来说最需什么功能的时候,很多用户的反馈都是Trace、Metrics、Log三者的联动性不好,是未来想完善可观测性的重要方向。

业界有很多专家都在研究这个问题,但是体验效果似乎仍然不好,这里谈下我们的理解,抛砖引玉,欢迎更多的探讨。

Log、Metrics、Trace三者集成难题

可观测性三大支柱集成难题主要因为以下几点

缺乏标准与协议

在opentelemetry没有成熟的2021之前,很多公司至少已经完成了统一日志的建立,Metrics的建立,Trace可能在最近两年逐步覆盖至所有业务系统,所以三大支柱在不同时期建设导致了三者没有办法按照日后成熟的opentelemetry协议进行很好的集成。

已有系统改造的成本大

将三者打通的工程工作量比较大,有些公司是因为不同供应商配合起来比较困难,有些公司是则因为之前建设系统的人员流动,导致系统被动陷入维护状态。

三大支柱的互动逻辑复杂

即便业务系统是新建立的,这个时候完全可以使用opentelmentry规范将三者数据在理论上做好集成的准备,但是三者的流畅的集成,仍然面临着不少的问题。

  • 完美用户体验设计界面非常难:用户排障过程是没有标准化的,也就意味着用户在看到某现象的时候,比如某个指标异常,可能接下来想看当时节点的日志,也可能想看当时的trace数据,这就导致界面要灵活的设计非常复杂。国外datadog的解决方案就是将页面设计成了可观测性数据搜索平台,用户可以添加很多的过滤条件对数据进行过滤,从而快速找到相关数据。国内如果也这样做会导致用户一上来看到如此复杂的界面,不知道该如何着手去排查问题,很难落地。

  • 不同背景用户述求不一样:可观测性数据是海量低价值的数据,界面上应该先呈现什么样有价值的数据很难权衡。不同的部门用户有自己的习惯,开发者最习惯看的是日志,不管是bug,还是系统故障,第一诉求就是看日志,因为这是开发者长期职业过程中形成的习惯,SRE可能会想先了解指标,并且根据自己的经验,配置不同的大盘,然后能够根据不同大盘一层层剖析。那能不能干脆分不同页面进行设计,比如有日志首页,指标首页,追踪首页等,现在很多公司确实就是这么做的,但是导致的问题也就是三者虽然在技术上能打通,但是使用体验上仍是割裂的。

  • 在一定规模下,可观测性数据查询性能差:可观测性数据的海量低价值特性,导致查询数据很慢,大家一定碰到过查询ELK的日志转个几秒才出来,追踪也是转个几秒出来,Prometheus server还可能由于维度问题,不断重启等现象。在这种场景下,用户在探索三者数据的时候是非常崩溃的,体验非常不好。即便有天才的设计师完成了三大支柱很好的界面交互,但是这缓慢的查询体验会让完美界面交互的价值降到无。

Kindling-Originx提供了不一样的思路

一种思路是加大资源投入,如果任何查询慢,就通过分布式扩资源的方式解决,然后期望业界有天才的设计师能够设计完美符合大部分用户习惯的界面交互设计。

Kindling-Originx认为可能还有另外一种方式可以解决此三者难以集成的问题。

Kindling-OriginX 提供了标准化的排障方式简化了用户体验设计

在排障过程中,什么时候该看什么数据,已经根据专家经验在界面流程当中设计好了,排障的特异化需求就能被固化并同步下来。

Kindling-OriginX 提供了自动化智能化查询分析功能

如果只有文档化的标准排障理论,没有通过机器自动化智能化分析故障,并将标准化排障过程当中所需的数据自动化关联查询出来,完全依赖人去落地标准化排障是非常难的。

Kindling-OrginX 智能化给出结论

Kindling-Originx报告给出了故障根因结论,但并不是仅仅给出了故障根因而已,而是将故障的完整推导过程所需的log、metrics、trace都查询好了,并集成至故障报告当中,这样就不是临时再去查询log、metrics、trace。用户如果怀疑故障根因分析得不对,可以一次性针对故障所需数据做出结论性判断,再也不用因为某些数据查询慢而打断思路。

Kindling-OriginX 联动方式实例

在 Kindling-OriginX 的故障根因报告中,已将 Log、Metrics、Trace 数据相关联后进行集成,并完成了故障根因的推导分析,具体可参见下面各类数据的实例。

链路数据Trace

Trace数据中给出了本地调用的链路相关数据,以及各种耗时信息与历史基线的对比情况。 Log、Metrics、Trace三者集成难题-链路数据Trace

故障根因结论

故障根因是故障报告的结论,是结合报告各类数据综合分析后得到的最终结果。 Log、Metrics、Trace三者集成难题-故障根因结论

故障节点分析及相关日志

Kindling-OriginX 会抽取出相关联时间段内的关键日志数据,以供查阅。 Log、Metrics、Trace三者集成难题-故障节点分析及相关日志

各类关联指标数据

Kindling-OriginX 自动化关联了与故障相关的各类指标数据,如接口具体的执行耗时情况,runq、网络质量指标等数据, 既是推导的过程依据,又可方便进行统一的二次分析。 Log、Metrics、Trace三者集成难题-各类关联指标数据 Log、Metrics、Trace三者集成难题-各类关联指标数据 Log、Metrics、Trace三者集成难题-各类关联指标数据