跳到主要内容

可观测性工具的盲区与故障排查困局

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

云原生常见可观测性工具的用法

Tracing

Tracing 可以追踪一次用户的请求,从而大致定位问题节点。如果运气好,是可以直接呈现某段代码的问题,比如问题就是SQL语句慢,或者执行了非常多次的redis操作导致整个请求慢,但是仍然有很多的时候只呈现了 Controller 方法执行时间长。

Logging

如果请求出现错误,在整个 Logging 体系中搜索错误日志是很快能够定位出错误的原因的,但是如果是请求发生了慢的现象,就得结合 Tracing。Tracing 基本定位到某个Controller 的问题,日志提供进一步的问题,排查到底是为什么慢,能否排查出问题取决于日志记录完备情况,所以经常出现的情况是补充日志进一步排查问题。

Metrics

通过 Metrics 中的SRE黄金指标能够很快确定业务是否正常,是否需要人为干预。但是一旦到某个业务慢,通过tracing和日志也没有发现直接线索,这个时候就只能通过 Metrics 找到有问题节点资源饱和度指标,看各种指标异常,不断地猜测试错验证了。

这里面存在两个大的问题:工具集成性差和盲区导致排障困难

集成性差是工程性问题,是次要问题

根据前文提到 Tracing、Logging、Metrics 工具在不同场景下使用,在不同工具之间跳转很麻烦会导致排查故障效率不高,但这是个工程问题,很多开源项目都在致力于解决这个问题。比如 OpenTelemetry 社区就致力于解决这个问题,会将三者从不同的线头糅合成一个线头,包括很多商业工具也都在界面跳转等易用性上发力,这个问题终将能够解决。 trace_metrics_logs

盲区是理论问题,是主要问题

盲区从理论上分析就存在的,不管是何种可观测性工具都没有办法完全还原程序的执行过程。Tracing 理论上就不可能针对每行代码执行都做插桩,因为会导致程序的执行性能下降很快。 Skywalking 有 trace-profiling 技术,目标就是动态探测某个程序在干什么,这个有一定的价值,能够发现用户代码层面的盲区。

国内使用很广泛的 Arthas 也是起着类似的作用,就是发现用户代码层面的盲区。国外一些在线debug工具,lightingRun 等工具也是往这个目标努力。

用户代码盲区并不意味着真实的程序执行盲区

程序执行过程是用户代码调用公共库、公共库调用JVM虚拟机代码、然后触发glibc库,最终触发syscall。

用户熟悉程度

现有工具理论上也只是工作在用户代码和公开库之上来帮助用户理解程序执行过程。

打开用户代码盲区之后仍然存在哪些可能的盲区

  • 用户在代码层执行一次带域名的http请求,实际在glibc中会分成两次网络请求,一次是获得dns解析,一次是真实的网络请求。用户代码层面无法理解到底是如何执行的。

  • 程序执行过程中,由于CPU时间片使用完,无法获得CPU执行,用户代码层面会将等待CPU时间片执行时间算成代码执行时间

  • 隐藏锁的使用,前文介绍了用户代码不可能对每行代码都做插桩,这样就会导致某些代码执行过程中可能在调用过程中使用了锁,但是对于用户而言是完全无意识的。典型就是Java常用的池化技术,连接池、线程池都是用锁来确保逻辑的正确执行。

  • 背锅的网络质量,用户代码调用网络发送代码,网络数据真的发送出去了吗?程序这个时候如果执行了GC操作或者CPU时间片用完了呢?从用户代码和日志层面看出应该是发出网络数据了,但是中间可能存在各种原因导致网络数据发送是滞后的,开发人员会倾向于认为网络质量有问题,但是网络运维人员发现不了网络质量问题。

如何才能在理论上真实还原程序执行过程,打开所有盲区

学习过操作系统的同学稍微回忆下基础知识,从操作系统层面看程序的执行过程,才是程序的真实执行过程,这里面是没有任何遗漏的。重点回忆下图。 程序执行过程 程序代码是以线程为载体进行执行,线程执行过程中可能会因为disk、sleep、lock、idle等各种原因放弃CPU上执行转入等待状态。 等待事件完成之后,线程状态变成Runnale等待cpu调度,如果此时CPU资源紧张,就会出现很长的等待时间。 开源项目 Kindling 的 trace-profiling 就是利用eBPF获取各个点位信息,同时结合Trace,真实地还原出程序的执行过程。从 Kindling 的 trace-profiling 去看trace的完整执行过程,每一个毫秒都知道程序在干什么。

Kindling-OriginX 利用trace-profiling理念构建故障推理引擎

Kindling-OriginX 相比于 Kindling 开源探针而言,使用Rust语言完全重构了eBPF探针。主要目的是获得更好的性能和稳定性。Kindling 开源探针使用go语言,由于go gc的存在,导致内存资源消耗相对而言比较大,而且go gc的时间不可控。 Kindling-OriginX 商业产品定位为故障推理引擎,通过分析各种开源工具的数据,补充 trace-profiling 的指标,比如通过 trace-profiling 已经能够看出网络执行慢了,这个时候通过补充网络质量指标如RTT、重传等进一步确认网络到底为什么慢。

Kindling-OriginX 完美解决集成性问题,同时彻底消除所有盲区

Kindling-OriginX 的故障报告中,完成了相关指标,日志和tracing的完美集成,只呈现用户需要看的故障传播链路分支和指标,旁路无关分支和故障不相干指标也不会呈现,日志也是故障时刻前后的相关节点日志。同时利用 eBPF 结合 trace-profiling 技术打开程序执行和系统调用盲区,从根本上彻底还原程序执行过程。 故障推理引擎利用智能算法结合 trace-profiling 自动化推导出故障根因,想更多了解 Kindling-OriginX,请点击阅读原文访问 Kindling-OriginX 官方网站。

如何找到并发请求中的锁

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

如何找到并发请求中的锁

经常听大家讲到在业务平峰期间一切正常,但当并发上升时用户端延时上升,体验急剧下降,往往这时候是由于应用锁导致。例如用户端访问时延是3s,数据库访问耗时500ms,而数据库索引和慢请求也都已优化,那么其他的2.5s到底是消耗在哪里?如果这其中的体验差距是由锁导致,那么又该如何快速定位这些锁,并将他们消除呢?

一方面受制于现有可观测性工具能力的限制,我们并不能有效地发现然后将其解决,另一方面传统的压测方法也并不能完美复刻生产环境的全部真实情。对于这些并发上升导致的问题,以及应用中看不见的锁,Kindling-OriginX 提出新的解决方法。

历史经验不准

实际工作中往往习惯于使用个人历史经验判断是哪些服务出现故障,哪些应用容易出现锁,微服务架构下,应用缩容扩容,应用实例数的不同,相同的问题常常表现出不同的现象。这就导致使用历史经验判断并不能有效的找到问题。

Kindling-OriginX 能够快速给出全部异常节点的根因报告,同时报告已给出分析结论,不论问题表现的现象如何,用户都能够快速简单的进行统一分析。例如下图的拓扑结构中,同样的性能问题,因为每个节点的实例数的不同,都会导致表现出不同的现象。Kindling-OriginX 已经分别对报告做了聚合,对数据做了分析,用户只需要简单查阅报告即可。 如何找到并发请求中的锁-历史经验不准

无法找到锁在哪里

实际生产环境中,一方面不可能事无巨细将应用所有变化都记录在日志中,另一方面很多数据也无法直接进行观测得到。往往知道应用里有锁,但是根本没有有效手段去找到锁在哪里。

Kindling-OriginX 通过实时监控和深度分析,快速识别性能瓶颈的同时,对每一个慢请求从系统调用级别进行拆解分析,究竟是GC、CPU等待、或是代码质量问题一目了然。

例如在下图示例中,futex耗时远大于历史基线值(futex是一种用于用户空间应用程序的通用同步机制,这里简单起见可以将其理解为一种锁机制),再结合自动化GC关联分析,得出故障根因是有锁,且该锁是由于系统发生GC导致 如何找到并发请求中的锁-无法找到锁在哪里1 如何找到并发请求中的锁-无法找到锁在哪里2

人工分析不可行

实际生产环境中,时时刻刻产生大量的 Trace 数据,要从这些大量的低价值数据中找出问题的根源,需要耗费大量时间进行人工分析,几乎不可能通过人工的方式找到关键数据。这不仅增加了工作负担,而且没有任何时效性可言。

Kindling-OriginX 通过异常占比与报告收敛的方式进行数据聚合,即使在大量 Trace 数据的情况下,也能对数据情况一目了然,快速找到所关心的数据。

如何找到并发请求中的锁-无法找到锁在哪里2 如何找到并发请求中的锁-无法找到锁在哪里2

干扰数据导致无法找到锁

系统整体性能急剧下降时,所有机器往往都处于高负载状态,越多的连接也会导致CPU需要处理的上下文切换越多,内存对象频繁的创建和释放也可能会导致出现因垃圾收集(GC)造成的延迟。这些干扰信号都可能会导致真正的问题被掩盖。

Kindling-OriginX 针对干扰数据多的问题,一方面将报告数据收敛聚合,避免数据过多造成的干扰,另一方面报告中直接给出根因结论,只需快速查阅就能得到结论,无需再进行人工分析和有效性判别。 如何找到并发请求中的锁-干扰数据导致无法找到锁

传统的可观测性工具在面对并发请求中的锁时无法提供有效的定位方式和解决方案,个人历史经验的误判,海量数据的分析、噪声信号的干扰,以及在动态复杂环境下的有效诊断,都要求更先进的技术和方法。Kindling-OriginX 提供全新的自动化、智能化关联分析 Log、Metrics、Trace 数据解决方案,通过 eBPF 和TraceProfiling 技术还原每一次请求过程,精准定位分析并发上升时应用中的各类问题。

如何让程序员过一个没有烦恼的假日

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

如何让程序员过一个没有烦恼的假日

每逢假期、周末,总是被各种排障会和线上问题折磨,做什么都做不进去,也没法好好休息……

常听身边的同行们这样描述自己的假期。说实话,这感觉我可太熟悉不过了,因为这状态困扰了我好几年……

不管你是正吃着火锅还是唱着歌,只要服务器有故障,百米冲刺回到电脑前。“我曾经跨过山河大海...”满大街找网吧,只为轻敲那几个命令。格子衫、双肩包,出门时刻背电脑,这样还怎么好好玩耍。

刚刚过去的春节假期是一个难得的休息和充电的机会,然而,由于程序员的工作性质,我们常常会面临一些不一样的挑战,常常由于线上业务稳定性要求和担心出现bug,很难真正度过一个没有烦恼的假日。

经常是好不容易到了假期,工作项目也暂时有所舒缓,想回趟家或者出去走走,一想还要带电脑回,临时都可能要处理报警,买票的欲望就会随理智渐渐消退,依旧选择原环境待上几天。


如何让程序员过一个没有烦恼的假日

以前和朋友闲聊常常互相调侃到:只要你是名程序员,那么,你的电脑就比女朋友重要。你可以出去玩不带女朋友,但是你不能抛弃电脑!

“男友是程序员,和我出去约会拿着电脑,有紧急情况处理就带我去咖啡馆,他方便处理问题。还有一次,我们去内蒙古旅游,进沙漠他都背电脑,他说你不懂,带着电脑有安全感,长剑在手,谁与争锋!”


北上广深通勤时间普遍都要很久,在地铁上写代码这事已经算是比较常见了,尤其是线上如果出了问题,有时候直接在马路上、垃圾桶上开始处理问题。

如何让程序员过一个没有烦恼的假日


地铁上一大哥正在改bug

如何让程序员过一个没有烦恼的假日


为了马上处理问题,采取了面向红绿灯编程

如何让程序员过一个没有烦恼的假日


婚礼上,一样可以加班扩容改bug

如何让程序员过一个没有烦恼的假日


夜晚的街头,一样可以改bug

如何让程序员过一个没有烦恼的假日


如何让程序员过一个没有烦恼的假日

我想各位同行们看完这些段子在内心哈哈无奈自嘲一笑的同时,回想自己吃着火锅改bug,爬着山被紧急拉进故障处置群里的种种场景,也是有着些许的无奈。每一个项目的上线及平稳运行,是所有人员起早贪黑、披星戴月、夙兴夜寐、通宵达旦、夜以继日、废寝忘食的工作换来的,但这也让大家想到假期总会忐忑不安,难以好好休息,过一个没有烦恼的假期。

随着技术的发展和各种工具的完善,Kindling-OriginX 故障推理引擎通过专家智慧经验精准梳理各类分散监控指标与日志,自动化 Tracing 关联分析生成可解释的故障根因报告,为故障排查提供标准化、可行动、可解释的自动化排障流程。让bug修复、根因定位、团队故障定界、协作排障都将变得简单清晰,不用被休息日的OnCall骚扰,不再为无尽的排障协调小组群而烦恼。希望借此能够将大家解放出来,让之后的每一个假日都没有烦恼,好好恋爱,享受美食,全身心的体验运动后酣畅淋漓。

如何集成 DeepFlow 的数据增强网络故障的解释力

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

如何集成 DeepFlow 的数据增强网络故障的解释力

DeepFlow 是基于 eBPF 的可观测性开源项目,旨在为复杂的云基础设施及云原生应用提供深度可观测性。DeepFlow 基于 eBPF 采集了精细的链路追踪数据和网络、应用性能指标,其在网络路径上的全链路覆盖能力和丰富的 TCP 性能指标能够为专业用户和网络领域专家提供充足的排障定界支撑。

Kindling-OriginX 是一款故障根因推导产品,目标是提供给用户一个可解释的故障根因报告,让用户能够直接了解故障根因,并附有根因的推理过程以便验证根因的准确性。网络故障是故障当中比较难以简单解释的,仅仅告知用户哪段网络有问题是不够的,用户需要更多指标以及图解,才能帮助用户更好的理解网络到底发生了什么故障,以及发生在哪个环节。

本文介绍 Kindling-OriginX 通过结合 DeepFlow 完备的网络数据能力,自动化生成可解释的故障根因报告。

soma-chaos模拟网络故障

如何集成 DeepFlow 的数据增强网络故障的解释力

  • 针对seat-service注入200ms延时的网络模拟故障。
  • 接下来我们先使用 DeepFlow 来识别200ms的网络故障,并做出相应的action。

人工最简化排障过程

步骤一:利用Trace系统缩小范围

在微服务场景中,某个接口突然慢了,排障的第一步骤应该是看Tracing系统,找到Trace慢在哪个环节,以及慢的具体表现是什么。

用户通过Tracing系统能够找到具体的Trace,通过分析Trace能够发现seat-service执行时间很长,同时出现了一条非常长的config-service调用,但是config-service执行不慢。这个时候需要联动网络指标,来定位网络问题。

步骤二:利用DeepFlow火焰图确定故障发生在哪段网络

将故障代表traceid的输入DeepFlow在火焰图中,找到Trace在网络层面上的表现,然后深入分析这个火焰图,如果对火焰图比较了解,同时有具备网络知识的专家经验,是能够根据火焰图人为分析出:这个故障应该是发生在调用者也就是seat-service上,而且问题是发生了syscall到网卡的时间段,也就是容器网络时段出了问题(和故障注入是吻合的)。

如何集成 DeepFlow 的数据增强网络故障的解释力

步骤三:确定容器网络到底什么网络指标异常

根据故障排查经验,用户需要查看seat-service与config-service的pod的网络指标。这个时候用户需要跳转至DeepFlow的Pod级别的网络指标页面。通过该页面,用户能够查看出建连有200ms的延时突变以及RTT指标有突变。

如何集成 DeepFlow 的数据增强网络故障的解释力 如何集成 DeepFlow 的数据增强网络故障的解释力

步骤四:排除可能的干扰因素

根据经验,宿主机的CPU被打满和带宽被占满之时,虚拟网络也会出现丢包和时延,所以要排查当时seat-service与config-service所在node的CPU以及node级别的带宽,确保Node级别资源没有饱和。

通过k8s命令确认了两个pod所在的node节点,然后去DeepFlow的node指标监控页面查看相应指标,发现node的bps,pps等指标均在合理范围内。

如何集成 DeepFlow 的数据增强网络故障的解释力 如何集成 DeepFlow 的数据增强网络故障的解释力 如何集成 DeepFlow 的数据增强网络故障的�解释力 由于node级别的网络指标没有出现明显异常,最终确定是seat-service的pod级别rtt指标异常。

人工排障总结

经过一系列的排查过程,最终用户是能够排查出故障的,但是对用户有以下要求:

  • 网络知识非常丰富
  • 深入理解网络火焰图
  • 熟练使用相关工具

Kindling-OriginX 如何结合 DeepFlow 指标,生产可解释的故障报告

Kindling-OriginX 针对不同的用户需求和使用场景,Kindling-OriginX 对 DeepFlow 的数据进行了加工呈现。

类比人工最简化排障过程,利用 Kindling-OriginX 的排障过程如下:

针对每一条 Tracing 自动化分析

针对此时的故障,自动化分析每条Trace,并按照故障节点对所列的Trace进行归集。Travel-service是由于级联故障导致的,本文不重点论述级联故障,如果有兴趣可以参考微服务级联故障该如何处理。 如何集成 DeepFlow 的数据增强网络故障的解释力

Review故障节点为seat-service的故障根报告

故障根因结论:对于子请求10.244.1.254:50332->10.244.5.79:15679 rtt指标出现200ms左右的延时

如何集成 DeepFlow 的数据增强网络故障的解释力

故障的推理验证

由于Kindling-OriginX 已经识别出是seat-service调用config-service的网络有问题,所以不用完全把 DeepFlow 的火焰图所有数据呈现给用户,只需要与 DeepFlow 对接,仅仅拿到seat-service调用config-service那段网络调用的相关数据即可。

利用 DeepFlow 的seat-service调用config-service数据自动分析出了客户端pod的容器网络出现了201ms的延时

如何集成 DeepFlow 的数据增强网络故障的解释力

Kindling-OriginX 会模拟专家分析经验,进一步关联DeepFlow的重传指标与RTT指标,从而确定到底是什么原因导致了seat-service调用config-service出现了延时的现象。

如何集成 DeepFlow 的数据增强网络故障的解释力

Kindling-OriginX 还会集成node的CPU利用率以及带宽指标,排除干扰因素。

如何集成 DeepFlow 的数据增强网络故障的解释力 Kindling-OriginX 将整个故障推理都在一页报告中完成,并且每个数据来源都是可信可查的。


总结

Kindling-OriginX 与 DeepFlow 都使用了 eBPF 技术,立求在不同的场景中为不同需求的用户提供灵活高效解决方案,也期待未来能看到国内有更多能力互补产品的出现。

DeepFlow 能提供非常完备的全链路网络基础数据,能够让云原生应用具有深度可观测性,对于排查网络问题非常有用。

Kindling-OriginX 是利用eBPF采集排障北极星指标、AI算法和专家经验构建故障推理引擎,给用户提供可解释的根因报告。

故障推理引擎加持下的告警理念转变

· 阅读需 10 分钟

在故障推理引擎加持下如何实现减少告警,做到精准告警

在 Kindling-OriginX 中只有业务请求受到故障影响才会告警,其他时候指标异常、故障都不会告警。为什么要这样设计呢?主要有以下几个主要原因:

  • 传统基于指标的告警:误报与漏报的告警非常多,信噪比非常高,会导致运维人员疲劳而忽略了真实的告警,而延误了告警的处理时间,导致严重的故障后果。
  • 基于指标的告警的本质是基于经验的设计告警的大杂烩,每个运维团队的告警都是在不断采坑中,不断完善指标告警,但是这个告警处理依赖于设计这个规则的人。但是人员是流动的,这些经验往往不会及时调整,而是不断累积,形成一个庞大而复杂告警体系。
  • 庞大而复杂的告警体系中,多指标是在技术上其实关联的,但是由于指标告警的时候是没有理解其内在关联性,一旦真实故障产生,各种误告警会不断产生,引发告警风暴。
  • 告警还有一个作用,就是当业务发生真实告警之时,期望指标告警能够为故障定位提供指导,但是没有专家经验治理的情况下,会产生告警太多的困惑,到底哪个是因,哪个是果不清楚,该往哪里排查也不清楚。

在Kindling-Originx中不需要传统告警提示排查方向

Kindling-Originx的核心能力就是故障根因推导,能够分钟级甚至秒级出故障报告,直接给出故障定位的初因。在这种情况下,无需配置指标告警来提示根因了,用户直接在故障根因推导的报告中能够得到定位的初因,同时也能够完整查看故障根因推导的过程,看出在整个推导过程中,有哪些指标是异于平常,同时可以通过Grafana大盘去观测更多的相关指标,进一步确认故障根因推导的正确与否。

基于API的SLO告警是Kindling-OriginX的使用入口

为了能够在生产环境中真正完成“1-5-10”,即1 分钟发现-5 分钟处置-10 分钟恢复的目标,通过 Kindling-OriginX 用户只需要设定和关注 API的SLO,并通过 SLO 关注系统状态结合 Kindling-OriginX 精准高效的故障根因分析技术,就能够使用户在极短的时间内响应并解决问题,发现各种隐患。这意味着即使是没有深厚技术背景和强大专家团队的用户也能够利用 Kindling-OriginX 来达成“1-5-10”目标,大大降低了技术门槛,提升了效率和可靠性。

推荐步骤

  1. 定义 API SLO (系统默认以历史数据设定)
  2. 当 SLO 违反时,查看对应时间段所生成的故障报告
  3. 根据故障报告内的根因分析数据,定位并解决问题,或根据推荐操作启动对应处置方案。
  4. 针对存疑根因分析结果,查看其详细推导数据与过程。

推荐流程

flow2.png

通过 Kindling-OriginX 只需要简单几步就能在不改变组织内原有应急策略和响应流程的情况下,快速提高故障发现速度与故障处理时长,帮助用户找到切实有效的方法落地实践“1-5-10”。

直接使用 Kindling-OriginX 基于SLO业务级别的告警,是否会有滞后性,是否会导致早期潜在故障发展成严重故障?

例子:传统运维视角,配置了JVM内存使用量告警,一旦JVM内存使用量达到一定阀值意味着内存可能存在泄露的可能,JVM内存使用量告警可以及早的请相关人员介入,避免潜在的风险演变成严重的内存OOM问题导致用户在业务接口上延时和错误率上升。

对于所有存在潜在问题发展成严重事故的故障,都会遵循以下的演变规律:

  1. 初始阶段(无明显影响)
  • 比如CPU使用率高:一开始,系统可能有足够的资源来处理增加的负载,所以高CPU使用率不会立即影响业务性能。
  • 比如内存泄露:同样,内存泄露在早期可能不会立即耗尽可用内存,因此不会直接影响业务请求的处理。
  1. 渐进阶段(轻微影响)
  • 随着时间的推移,如果CPU持续高负载运行,可能会导致处理能力下降,开始影响到处理请求的速度,出现轻微的延时增加。
  • 内存泄露逐渐消耗更多内存,开始影响系统的性能。这可能首先体现为偶尔的性能下降或轻微的延时增加。
  1. 加速阶段(逐渐增加的影响)
  • CPU使用率高:随着系统负载的继续增加,CPU可能无法有效地处理所有请求,导致响应时间显著增加,甚至影响到其他并行运行的服务或应用。
  • 内存泄露:内存消耗接近或达到系统上限时,可能导致内存不足,影响到新的请求处理,甚至引发系统的虚拟内存使用,进一步降低系统性能。
  1. 临界阶段(严重影响)
  • 此时,系统可能变得过载,无法有效响应请求,导致大量请求延时显著增加,错误率上升。
  • 在极端情况下,系统可能完全无响应或崩溃,需要重启或其他紧急措施来恢复服务。
  1. 恢复和分析
  • 一旦问题被识别并解决(如优化资源使用、修复内存泄露问题),系统性能会逐渐恢复正常。
  • 通过分析导致问题的根本原因和过程,可以采取措施预防未来类似问题的发生。

传统的指标阀值告警模式也许能够在初始阶段就告警,从而为潜在风险提供更多的处理时间,如果告警能够做到精而准确实能够帮助用户争取更多的时间来处理潜在的风险。但是实际情况往往是告警误报过多,从而导致疲劳忽略了告警,别说争取时间了,就是故障已经发展到3或者4阶段的告警都可能被忽略,反而影响了告警的高效处理。

目前 Kindling-OriginX 基于SLO围绕业务告警,针对慢性问题发展成严重故障,基本上做到在3阶段-加速阶段实现告警,这个时候告警完全有时间进行快速处理。未来 Kindling-OriginX 争取发展到2阶段,在早期尽量给用户争取更多的时间来处理潜在的风险。

故障根因报告解读之:CPU篇

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

本系列文章将以云原生环境下分布式系统的不同类型故障入手,从真实系统出发,分别以不同类型的故障为例,对故障根因报告进行介绍和解读。

本篇将通过实际案例对故障根因报告进行解读。将会使用开源模拟故障案例集系统 soma-chaos 作为故障注入平台,在 Kindling-OriginX 在线Demo上进行故障报告的解读,可以通过点击阅读全文进入 Kindling-OriginX 官方网站,实际体验故障注入和 Kindling-OriginX 的故障根因推理能力。

报告解读

  • 在 ts-order-service 中注入故障:运行额外任务抢占Pod可用的CPU资源。

    注入完成后稍等片刻,进入 Kindling-OriginX 的「服务健康检测诊断」页面,在「SLO实时异常检测」Tab页下我们可以看到 ts-order-service 涉及的服务入口出现 SLO 告警。 SLO告警

  • 在这里可以看到目前异常根因节点占比 ts-order-service 和 ts-seat-service 各占一半,他们都处于报警服务入口调用链路中。具体情况我们通过诊断报告详细展开。

    进入故障列表后也可以看到,这里分别有ts-seat-service和ts-order-service两个节点的多份故障报告,同时已经做了聚合。 故障报告列表 点击ts-seat-service的TraceID后进入该节点最新的故障报告。一份故障根因诊断报告有部分内容及多种相关Log、Trace、Metrics数据聚合分析而成,这里分别简单介绍。

  • 诊断报告概要。包括TraceID、故障发生时间、请求耗时、耗时对比信息等基本信息。 诊断报告概要

  • 单次调用链路信息。故障链路的调用详细信息及耗时信息。 单次调用链路信息

  • 故障根因。即该故障报告的最终结论信息及建议处置方法。该报告显示故障根因并不在 ts-seat-service 处,判定根因节点在下游服务处。接下来在对报告中关联的各类指标介绍过程中简要说明为什么会得到这个故障根因结论。 故障根因

  • 故障节点分析。报告中会对响应时间与历史基线进行比对,同时自动关联异常时间段的日志信息,无需再去通过其他手段查找。 故障节点分析

  • 接口执行耗时分析。这部分报告会对本次调用的北极星排障指标与历史基线值进行比对。主要包括CPU时间、网络时间、等待时间、其他时间(主要为存储时间等)。这里可以看到本次调用耗时最长的是网络时间 183.35ms,而且远超历史基线值。分析到这里往往会认为该服务可能存在网络问题。接下来我们对该指标继续下钻,对网络层面的指标进行更加深入地钻取。 接口执行耗时分析

  • 对外调用具体信息。 对外调用具体信息

  • 请求网络耗时详细分析。这部分报告针对网络指标进行了更加详细的拆分和数据钻取,对广义上的网络耗时进行的更细致的分析,为判定网络是否出现问题提供更有说服力的证据。 请求网络耗时详细分析

  • 网络质量指标。同时 Kindling-OriginX 会对整体的网络质量进行分析,即结合分段的网络时间和网络质量来综合判定网络耗时长是由于网络问题还是由于其他问题导致。所以在本例中分析后得出的故障根因结论为下游服务可能出现问题 网络质量指标

  • 接下来继续分析ts-order-service的故障根因报告。同样打开一份ts-order-service的诊断报告。故障根因显示:Runq耗时高,存在CPU抢占。从接口执行耗时分析中也可以看到,runq耗时占比最大,耗时180.27ms。根据这份报告,先来解释下什么是runq。

    runq(Run Queue Latency) 是一项描述操作系统性能、稳定性的重要指标,它描述了线程从进入就绪态到运行态的等待时间。CPU runqueue是一个表示等待CPU时间的概念。它是一个系统的活动队列,用于存储正在等待CPU资源的进程。当一个进程请求CPU资源时,它会被添加runqueue,等待CPU分配时间片。

    ts-order-service的故障根因报告 ts-order-service接口执行耗时分析

  • 结合runq的定义和 Kindling-OriginX 给出的根因报告,我们可以得到的结论是ts-order-service节点 CPU资源不足。

    到目前为止,报告解读完成,目前根据得到故障报告可以得到两个结论,分别是:

    1. ts-seat-service 网络指标正常,但网络耗时高,可能为下游节点故障。

    2. ts-order-service CPU资源不足。

级联故障处理

  • 在微服务系统中,任何单一故障往往都会以级联故障的形式表现出来,在该例子中即为ts-seat-service 和 ts-order-service 都发生了故障。从调用链路图中可以看到,ts-seat-service 是ts-order-service的上游节点。结合目前的结论和调用链路图,可以判定出ts-seat-service的调用慢非常有可能是由于ts-order-service慢导致的,根据级联故障处置优先级原则,应当优先解决被依赖节点的故障及ts-order-service。

    服务拓扑图

  • 在 ts-order-service 的故障根因报告中显示「Runq耗时高,存在CPU抢占」即表明该节点CPU资源不足,执行业务过程中耗费了大量的时间等待CPU资源。即CPU资源被我们注入的故障「运行额外任务抢占Pod可用的CPU资源」所抢占,导致链路中的请求在此处产生大量的等待,所以同时也会看到ts-seat-service的网络调用变慢,因为ts-seat-service的下游服务有锁。

小结

故障根因报告在 Kindling-OriginX 中扮演着重要的角色,它综合分析和展示了各种分散的Log、Trace、Metrics数据,结合专家经验自动完成关联聚合,避免了可能的信息断片和数据交叉误解,真正做到了从表面现象到深层次原因的逐步剖析。通过直观的报告展示方式,以全新的思路为故障排查定位以及故障根因的确定提供更加高效和便捷的解决方案,为实现分钟级定位级联故障,落地 1-5-10 故障响应机制提供一条可行之路。

故障注入是检验可观测性建设成熟度的有效方法

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

故障注入是检验可观测性建设成熟度的有效方法

随着云原生、微服务等技术给企业带来竞争力的同时,也使得系统更加的复杂。日趋复杂的系统让故障根因难以排查,导致处理故障的大部分时间都用在了对问题的定位上。能够明确知道系统发生了什么是进行问题定位的前提之一,所以如何对系统进行监控,如何获取到规模庞大的系统的运行状态,也都成为了新的挑战,这种挑战反过来也促进了可观测性领域的发展。

可观测性的目标

故障注入是检验可观测性建设成熟度的有效方法

对于很多成熟企业,很多已经构建了APM、NPM等监控体系,以及Trace、Log分析系统等。而对于一些起步不久的企业,可能还处于可观测性建设的初期阶段。

那么对于不同阶段的企业和技术团队,是否对可观测性的要求有所差异呢?

总体上来说,可观测性代表了当前对系统形成洞察的能力,可观测性成熟度越高,对系统的洞察能力就越深入越完整,即系统的可观测性成熟度越高,就能越迅速、越准确地从发现的问题中找到根本原因。因此无论企业目前处于什么阶段,当前可观测能力的建设水平如何,其对于可观测性能力建设的目标应当都是一致的。

目标具体包括:

  • 更全面的数据采集
  • 更有效的关联各种类型数据
  • 更快速与自动化的确认问题根因

各个企业在观测性建设成熟度上的差异,也主要体现在对这些目标的达成程度的差异。

可观测性成熟度

故障注入是检验可观测性建设成熟度的有效方法

为了能够更好的帮助与指导企业进行可观测性的建设,衡量及评估自身当前可观测性建设水平,有很多机构与公司都发布过对可观测性成熟度模型的定义,本文以龙蜥社区与信通院稳定性保障实验室联合发布的《2023年可观测性成熟度模型白皮书》为例进行说明。该模型是一种用于衡量和评估企业软件系统内部可观测性的框架或方法,同时也是一种用于反馈企业可观测性体系建设成熟度水平的框架或方法。

该模型包含五个级别,分别是:

  • Level 1:监控。确定系统组件是否按预期正常工作。

  • Level 2:基础可观测性。确定系统为什么不工作。

  • Level 3:因果可观测性。找到问题的根本性原因,并确定它的影响面,避免再次发生。

  • Level 4:主动可观测性。自动化的找到问题根本性原因,自动化的响应处置,智能化的预测预防,阻止异常风险发展成为问题故障。

  • Level 5:业务可观测性。确定对业务的影响,如何降低成本、增加业务营收、提升转化率、辅助商业决策。

可观测性建设成熟度越高,团队越能够通过合适的数据自动发现和修复问题,甚至主动识别和预防问题。可以简单理解为越多的故障能够通过可观测性工具发现,甚至主动预防,说明其成熟度越高,如果仍旧有较多问题通过客服侧或其他渠道上报而来发现,那么说明其成熟度还不够。

使用故障注入对可观测性成熟度进行检验

什么是故障注入

混沌工程是一种方法论,而混沌工程的核心就是注入故障。通俗理解,以应用为出发点,在各种环境和条件下,给应用系统注入各种可预测的故障,以此来验证应用在面对各种故障发生的时候,它的服务质量和稳定性等能力。

故障注入是衡量可观测性建设质量的有效标准

在实际生产环境中,对可观测性建设成熟度及质量的最直接的衡量方式就是评估有多少故障是通过可观测性工具发现甚至预防的。

这是一个最直观的标准,如果花了很多精力、物力、人力做了完备的可观测体系建设,但是仍旧有大量的故障没有能够被观测到,甚至仍旧出现P0级别的故障,是没有人能够认同这个体系的建设是成熟的、是高质量的,只是单纯的可观测性数据和工具的堆砌。

而故障注入作为真实故障的模拟,与真实场景最为接近,也最能够有效地评估系统在面对实际故障时的响应和恢复能力,也最能够有效的反映出可观测性体系在实际问题场景中是否能够真实有效的发挥作用,为解决问题提供最切实有效的价值。业内技术领先的公司,也经常采用故障注入演练的方式对自身系统的健壮性进行检验,查漏补缺不断提高可观测性工具对问题发现和预防的比例。

故障注入虽不能涵盖全部的故障问题,但目前主流工具已能将大部分常见的网络、系统、代码、容器问题进行模拟,能够有效帮助组织评估、改进和发展其可观测性能力。Kindling-OriginX 在产品设计与开发过程中也使用这种方式进行能力的检验和产品的迭代。

总结

如果想要对自身可观测能力进行检验,也可与Kindling-OriginX Demo采用类似方式,在目标环境中部署soma-chaos。

soma-chaos 目前已支持的故障类型有:

  • 网络类故障案例。例如丢包率较高、重传率较高、带宽限制打满、DNS故障、TCP建连延时高

  • 存储类故障案例。例如IO延时高

  • CPU类故障案例。代码自身CPU使用率高、共享环境其它进程抢占CPU

  • 内存类故障案例。FULL GC频率很高、共享环境其他进程抢占Memory

  • 代码类故障。代码抛出异常导致错误码返回、HTTP请求返回错误码

soma-chaos 是一个开源模拟故障案例集系统。该项目开源在龙蜥社区系统运维联盟之下,其中包括复旦大学SELab开源的业务模拟系统Train-Ticket、Chaos-Mesh开源云原生混沌工程平台、收集整理的真实故障案例集。欢迎任何单位和个人提交贡献故障案例,一起讨论故障注入实践或在使用过程中产生的任何想法和问题。

参考资料

Train Ticket:A Benchmark Microservice System

gitee-soma

Chaos Mesh

故障注入使用指南

最佳实践解读:互联网公司线上故障标准化排障流程

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

最佳实践解读:互联网公司线上故障标准化排障流程

线上故障通常是指影响线上服务可用性的问题或者事件,包括服务性能的降低、出现影响用户体验的问题、不同程度的服务不可用等。为了确保服务稳定性和用户体验,线上排障的第一目标是恢复线上服务或者降低影响。随着技术的发展,产生了诸如Google、Amazon、Twitter、淘宝、得物、字节等新兴互联网公司,其业务体量大,系统复杂程度高,时时刻刻服务成千上百万的用户,这都对故障处理的能力和及时性都提出了更高的要求。本文对互联网公司线上故障标准化排障流程做一简单分析,总结一些肤浅的方法论,以求共同探讨,共同提高。

最佳实践解读:互联网公司线上故障标准化排障流程

故障处理目标

故障管理的目标是“尽快恢复服务到正常运行,并且最小化对业务运营的不利影响,从而尽可能地保证服务质量和可用性的水平”,即所谓的止血。即使不能立刻完全恢复,也要想办法将其影响降到最低,迅速止血。所以往往重启服务、扩容、降级、熔断等方法都是在紧急情况下首先想到的方法,先试试再说,之后再彻查问题,从根本上解决问题。

实际工作中,找到了问题的根因原因,解决问题之后,并不代表本次处置就完成了。对于任何一个故障,其真正的处理目标应该是两方面,一方面尽快恢复服务,完成止血;另一方面要及时复盘总结,举一反三,不断完善流程处理机制,弥补操作过程中的规范问题,形成报告,在公司层面分享总结经验,提高应对能力的同时也要能够减少同类故障的发生。

故障处理思路

线上故障处理的目标是最快速度恢复线上服务或者降低对线上服务的影响,“快速”是对其最基本的要求之一,所以要要求故障发生时候需要能够最短时间发现,发现后要能最快对其进行评估和分类,同时根据评估结果能够充分调动各方资源最短时间内制定出可执行的应对方案,同时在整个处置过程中也都需要运维、业务研发、产品、基础设施等多团队互相协作,保持高效的沟通。基本的处理思路如下:

故障识别与告警

线上故障一般通过多种途径传递到开发、运维团队中,例如主动巡检发现,各纬度各类型监控告警,关联故障追溯,生产事件上报。首先需要对上报的信息判定是个例问题,还是确实是线上故障。以主动发现为根本建设目标,例如可观测性建设的目标和价值体现就是能够将故障主动、及早发现和定位。

故障评估与分类

针对识别出的问题,进行严重性评估,判断问题的影响范围和严重性。根据评估结果,将问题进行分类,设定问题处理的优先级,同时通知各相关业务、技术部门人员故障情况,准备参与排查。进行评估分类需要多维度的数据支撑,往往缺失数据或存在盲区时更多依赖人员经验和能力。

故障定位与分析

确定故障后,需要快速定位到问题点,找到原因,以便针对性的采取合适的应对方案。在这过程中需要该故障涉及到的业务、开发、运维人员各负其责,分析系统日志,查找错误信息和异常行为,收集与问题相关的数据,如流量统计、错误率等,为问题解决提供依据。

该阶段是排障过程中最关键的阶段,往往无法估计具体时间,具体步骤往往也根据业务种类、问题表征、可观测性建设成熟度、团队能力等不同而有所差异,现阶段难以进一步标准化,所以也导致该阶段也是最难得一步。

这里举一个简单的例子,排查中往往是排查三板斧:模拟复现,找相关数据,分析完整请求链路。这其中找相关数据需要在各个可观测性工具里找到相关的数据,并将其关联,这是一个非常复杂且耗费时间的任务。同时,需要将这些数据,与其对应的 Trace 数据相对应,才能尽可能真实地还原出问题现场。但实际生产环境下,Trace数据茫茫多,人工分析几乎不可能,这也是为什么经常会重启服务、扩容、降级先试试看的原因。

故障排除与管理

根据问题定位和分析结果,制定相应的行动措施,执行对应的预案或采取合适的措施修复问题。同时在解决问题时,也需要遵循变更管理流程,确保每一步更改都有记录,以免派生出新的故障。

故障验证

在完成恢复或修复操作后,进行必要的测试,查看相应的监控指标数据,确保问题已经解决。同时恢复服务后,继续监控以确保系统稳定。将信息同步反馈到各干系人,如有需要,配合业务方完成故障期间受损的数据。

故障复盘

一般在故障处理结束后24小时内产出故障报告,包括故障过程回顾、故障原因分析、改进预防措施制定、故障定级等。故障定级分为P0、P1、P2和P3四个等级(依次降低),各公司都有特定的等级定义,主要从业务影响面和影响时间来确定。一些团队或公司会总结故障知识库,作为排障知识的传递方式,以期保证人员能力和经验能够进行复制。

排障流程的标准化

最佳实践解读:互联网公司线上故障标准化排障流程

排障流程的标准化是指将故障处理的各个环节规范化、流程化,以确保在面对系统或服务故障时,团队能够快速、有效地采取行动。

通过对故障处理思路的总结,可以看到排障流程标准化存在的主要问题一方面是故障定位和分析难以快速完成,同时也无法标准化;另一方面人员能力和经验的差异也导致标准化处理的过程在很多团队难以落地。

相关案例

下面以一些互联网公司的故障处理流程为例以供参考,图片和资料均来自于网络。

得物容器SRE响应流程

最佳实践解读:互联网公司线上故障标准化排障流程

有赞故障处理流程

最佳实践解读:互联网公司线上故障标准化排障流程

美团大数据运维故障处理流程

最佳实践解读:互联网公司线上故障标准化排障流程

标准化排障流程需要体系和工具支撑

从上面的案例可以看到,标准化排障流程需要一套完整的体系支撑,以确保流程的顺利执行和持续优化。以下是构建支撑体系的几个关键要素:

1. 技术工具

  • 成熟的可观测性体系:建立成熟完善的可观测性体系,能够确保尽早发现问题,同时排障过程中能够覆盖尽可能多的数据,以期最大限度消除观测盲区。

  • 故障响应平台:能够对故障生命完整生命周期进行追踪,同时对各类指标数据进行治理,在故障时刻提炼相关联的数据,帮助处理人员聚焦核心指标。

  • 知识库:建立和维护故障知识库,用于存储故障案例、解决方案和预防措施,为各类问题提供可执行的预案。

2. 流程文档

  • 标准化手册:制定能够对于不同类型的故障能够统一执行的操作方法。

  • 操作指南:为常见故障类型提供操作指南,帮助不同经验和能力水平的团队成员快速定位问题和解决方案。

3. 组织结构

  • 专业团队:建立专业的技术和运维团队,负责监控、响应和解决系统故障。

  • 角色定义:明确团队成员的角色和职责,确保在故障发生时,每个人都清楚自己的任务。

小结

最佳实践解读:互联网公司线上故障标准化排障流程

线上故障处理的目标是快速止血,标准化排障流程是实现其方式的关键因素之一。通过建立一套完整的体系支撑,并不断优化排障流程,以期能够更好地应对系统故障,提高服务质量和用户满意度。

标准化排障流程的成功实施需要一套完整的体系和工具支撑。这包括组织结构、流程文档、技术工具、沟通机制、团队培训、持续改进等多方面因素。一方面很多团队很难像这些大型互联网公司一样真正落地故障处置规范,建立完备的可观测性体系,花费人力物力进行数据指标的治理。另一方面很多企业建立的完善的可观测性体系,但是仍旧无法通过现有工具弥补人员经验、能力、操作方式、使用习惯的差异。这都使得标准化排障流程难以真正落地实施,致使可观测性数据价值无法被有效发掘。这些问题都需要平台化的能力和更先进的工具来解决。

随着技术的发展,特别是可观测性领域的发展,目前也出现了一些新工具能够帮助我们缩小这其中的差距,例如Datadog、Kindling-OriginX、X-Ray、Dynatrace等都通过各自不同的方法和理念去实现故障标准化排障流程。

最佳实践:深入理解线程池参数设置

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

最佳实践:深入理解线程池参数设置

在现代编程中,线程池已经成为了不可或缺的一部分,特别是在Java编程开发中,线程池更是绕不开技术点。然而,要想取得优秀的性能表现,需要对线程池的参数进行调优。本文将深入讲解 Java 线程池的调优方法和技巧,帮你提高编程技能和优化系统性能,并介绍如何使用 Kindling-OriginX 来深入理解线程池参数设置。

最佳实践:深入理解线程池参数设置

什么是线程池

线程池是一种管理和重用线程资源的机制,是利用池化思想设置和管理多线程的工具。线程池维护一定数量的空闲线程,当有任务需要时,就从中选择一个空闲的线程用来执行任务,当使用完成后该线程就会被重新放回线程池中,通过这样循环使用的方式来节省创建线程和销毁线程的各项资源开销。

线程池重要参数解析

线程池中有多个关键参数,需要在创建线程池时对其进行设置,合理的参数设置能够达到最佳的性能,适应任务场景。这里以ThreadPoolExecutor为例,对几个重要的参数进行解析说明。

corePoolSize

核心线程池中线程的数量。当提交一个新任务时,如果当前线程池中的线程数量少于corePoolSize,就会创建新的线程。即使此时有空闲的非核心线程可使用,也会创建线程,直到达到corePoolSize配置数量。

maximumPoolSize

线程池中最大的线程数量。包括核心线程池和非核心线程池,即在任务队列已满的情况下,可以创建的最大线程数。当线程数量超过maximumPoolSize时会执行配置的拒绝策略。

keepAliveTime

线程存活时间。当线程池中的线程数量大于corePoolSize时,超出的空闲线程最大能存活的时间,超过这个时间,线程就会被回收,直到线程数等于corePoolSize。

unit

时间单位

workQueue

任务队列实现。用于存储已提交未被执行的任务。线程池根据任务队列的策略来进行等待任务的调度。常见的队列有:

  • ArrayBlockingQueue:数组实现的有限队列,可以指定队列长度。

  • LinkedBlockingQueue:基于链表的无限队列,长度可以无限扩展。

  • PriorityBlockingQueue:优先级队列,可以设定队列里任务的优先级。

参数设置原理

最佳实践:深入理解线程池参数设置

为了最大程度利用线程池的资源,充分发挥线程池的执行效率,需要对线程池的主要参数进行合理的设置,对于不同的业务和场景,也需要根据实际情况来进行调整。

  • 核心线程池大小corePoolSize和最大线程池大小maximumPoolSize一般需要根据实际场景设置,主要与执行任务的类型和数量相关。一般最佳实践建议是将核心线程池设置为CPU核心数 + 1,最大线程池大小设置为CPU核心数 x 2。

  • KeepAliveTime线程存活时间,一般根据任务处理的耗时配置。如果任务密集且耗时长,则可以适当增加空闲线程的存活时间,根本目的是尽可能减少线程的创建和销毁操作,原则上不超过60s。

  • workQueue阻塞队列的类型及大小需要根据具体场景来设置。通常来讲任务数量多或并发高,选择无界队列,避免任务被拒绝。任务数量可控选择有界队列。


虽然参数设置原理看似简单,但实际使用中仍存在一些问题:

  • 人员经验和能力不同,经常以个人习惯或理解进行设置,没有标准或者数据依据。

  • 执行情况和任务类型、并发情况、机器配置都有关系,导致同样参数也可能运行起来情况有差异。

  • 同一个应用中可能存在多个不同业务类型的线程池。

常见线程池参数配置方案及其问题

上面参数设置大多基于经验,是否有科学的方式能够根据场景对其进行计算或者评估?

常见理论方案

这里以美团技术团队调研的业界一些线程池参数配置方案为例:

最佳实践:深入理解线程池参数设置

  • 第一种方案过于理论化,偏离任务场景。

  • 第二种方案也不符合实际情况,应用中往往不可能只存在一个线程池。

  • 第三种方案过于理想,正常情况下流量存在高峰低谷,同时大促、秒杀等运营活动期间流量更不可能是均衡的。

其他方案

在《linux多线程服务器端编程》中有一个思路,CPU计算和IO的阻抗匹配原则,根据这个原则可以推出估算公式:

最佳线程数目 = (线程等待时间与线程CPU时间之比 + 1)* CPU数目

这也是网络上流传的比较多的方法之一,包括其衍生出的案例:

假如一个程序平均每个线程CPU运行时间为0.5s,而线程等待时间(非CPU运行时间,比如IO)为1.5s,CPU核心数为8,那么最佳的线程数应该是?

根据上面这个公式估算得到最佳的线程数:((0.5+1.5)/0.5)*8=32。

这个方法看似严谨,但也存在很大问题,因为其结论可以简单等价为线程等待时间所占比例越高,需要越多线程,忽略了线程切换开销和锁,同时也忽略应用CPU密集型、IO密集型、内存型区别,以及硬件环境不同带来的差异性。

上面的这些方案看似合理,但是在实际场景下却未必合理,实际情况下都需要结合系统实际情况和硬件环境,通过合适的工具尝试达到一个符合实际场景需求的合理估算值。

使用 Kindling-OriginX 进行参数调优

最佳实践:深入理解线程池参数设置

这里以 Kindling-OriginX 为例,说明如何使用其提供的北极星指标体系进行线程参数配置的优化。

北极星指标

cpu

程序代码执行所消耗的CPU cycles

runq

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

net

网络时间,主要包括DNS,TCP建连,常规网络调用

futex

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

file

存储操作时间

通过上述指标的具体时间,我们就可以知道每一次调用程序具体耗时在哪些地方,该从哪些方向进行优化,cpu资源是否被充分使用,还是时间都被消耗在了线程切换上等等。

调优案例解析

下面以使用 Kindling-OriginX 为例,说明如何对线程池进行参数设置与优化,并找出系统链路中的真实性能瓶颈。对于单一线程池可以通过 Kindling-OriginX 确定其是cpu密集型还是说IO密集型任务,对于多线程池可以通过 Kindling-OriginX 以数据为基础,对多个线程池综合调优,使应用达到最佳状态。

案例一

最佳实践:深入理解线程池参数设置

从北极星指标中可以看到,该次调用futex时间很长,可能是存在Full GC导致,也可能是程序中产生了锁等待,锁的竞争非常激烈,此时增大线程池也并不可能提高性能,可以考虑从优化任务执行代码入手。如果该服务是上游服务,则可以考虑加大下游服务的线程池尝试增强处理能力。

案例二

最佳实践:深入理解线程池参数设置

runq是一个表示cpu等待的概念,它是一个系统活动的队列,用于存储正在等待cpu资源的进程,本例中runq数值很高,说明cpu资源紧张,没有资源分配给线程使用,可以认为该线程池处理的任务为cpu密集型任务,一方面配置参考Ncpu + 1的方式,尽可能提高利用率,减少上下文切换,同时考虑减少目前配置大小,合理配置线程池队列长度,设置合理的拒绝策略,避免导致上游方法或服务产生大量锁等等。另一方面需要考虑扩充资源或查看机器监控等指标,分析是否出现了异常的资源抢占。

案例三

最佳实践:深入理解线程池参数设置

在北极星指标中,file一般指代存储相关操作。该例中,主要操作耗时是磁盘存储操作,在不考虑存储设备异常的前提下,该线程池可被认为是一个负责处理IO密集型任务的线程池,这种情况下可以考虑对该线程池采用Ncpu * 2的方式进行配置,并酌情增大。

对于单个或多个线程池的参数调优,亦可以Trace的角度出发,通过链路分析的方式,对单一节点的调用耗时进行分析来判断该服务中线程池的优化方向,单个线程池可以根据任务类型参考业内最佳实践,多个线程池可以根据北极星指标分别针对性的调整后综合分析,以求达到多个线程池的最佳资源利用状态。

小结

对于业务中的线程池问题,需要对线程池的工作原理及各参数含义有深入理解,同时也需要能合理根据实际场景选用合理的工具对其参数进行调优,不能一味生搬硬套业内经验。可以通过 Kindling-OriginX 等工具对程序执行的各项指标进行分析,以数据为导向,合理调配,才能真正提高线程的复用和效率,适用不同的业务场景,提供系统性能,结合实际情况和真实数据才是最佳实践。

最佳实践:高并发之扩容思路

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

最佳实践:高并发之扩容思路

系统在业务平峰期间运行稳定、性能良好,但在大流量时就会出现各种各样的问题,例如接口时延变大,CPU占用率升高、频繁发生Full GC、代码中出现死锁等等。大流量意味着高并发,高并发也是很多开发人员所期望拥有的经验,一方面能够接触更加复杂的业务场景,提高自身能力,另一方面对于高并发的解决思路需要依靠经验积累,通过踩坑填坑的方式不断精进。而这其中扩容又是最常见的应对高并发场景的思路。

最佳实践:高并发之扩容思路

什么是扩容

扩容,通常指为了提高系统的处理能力,而采取的增加计算或其他资源的一系列措施,以此来提升系统的性能。

传统意义上的扩容一般只单单针对硬件计算资源,策略上可以分为两种,一种是对单机整体扩容,也就是整机的CPU、内存、磁盘等等;另一种就是扩容对应的组件,例如提高CPU性能,升级读写性能更优秀的磁盘等。而在云原生、微服务等技术越来越普及后,扩容的概念也不再单单指计算资源,而是扩展到架构领域,例如流量高峰期针对某一中间件资源进行扩容,或针对某一核心服务进行扩容,这使得扩容能够更高效、更有目的性。

随着技术的发展和业务的复杂度的上升,也要求扩容更有目标性,更快速,这就要求在实践中对于扩容的目标、策略、方法,以及系统的架构设计都要有深入的理解,同时也需要有合适的工具对其进行技术支撑。

扩容目标

扩容是为了确保系统在面临高并发访问、大数据处理等场景时,能够保持良好的性能和稳定性,不会因为资源不足而出现服务响应缓慢、系统崩溃等问题。

扩容是一个系统性的工程,需要综合考虑成本、性能、可靠性等因素,并采取适当的策略和技术来实现。目标具体来看主要有以下几点。

提高系统并发能力:通过增加系统资源,提高系统处理请求的能力,从而应对高并发访问。

保证系统稳定性:在扩容过程中,确保系统运行稳定,避免因资源分配不当导致的性能波动。

降低成本:在满足业务需求的前提下,合理利用现有资源,降低扩容成本。

易于实现:能够快速做出响应,同时不影响正常的业务功能设计和开发。

常见扩容思路

最佳实践:高并发之扩容思路

架构层面

从架构上来看扩容可以分为两大类:

横向扩展(scale-out)

又名水平扩展,即用更多的机器来支撑大量的请求。常见的集群模式往往就是这种思路。以运送货物为例,当大量货物需要运输时,使用更多的货车进行运输。

纵向扩展(scale-up)

又名垂直扩展,扩展一个节点或单一机器的能力,使一个点能够支撑更大的请求。例如使用高性能计算服务器,其往往有更强的单体计算能力。同样以运送货物为例,当大量货物需要运输时,将货车升级,让每个货车更大更快。

业务层面

从业务类型上来看扩容也可以分为:

读操作扩展

如果系统中读操作占大多数,那么可以通过找到关键的资源瓶颈,对其进行扩容或增加其资源进行扩展。例如MySQL是资源瓶颈,那么增加多个只读从库,业务高峰期扩展只读库副本数进行横向扩展,亦可以提高MySQL服务器的性能采用垂直扩展的思路增强其处理能力;增加一个或多个redis将热点数据进行缓存等。这都是通过读写分离的思想,针对性的以业务角度出发对读操作进行扩展。

写操作扩展

如果系统中写操作为主,往往提高单个节点的能力性价比较低,通常考虑使用HBase、MiniIO等分布式存储方案,方便后期不断进行水平扩展。

异步处理

将一些有延迟、等待任务放入消息队列中,利用中间件实现业务功能,提高系统吞吐量。或通过异步的方式对服务进行解耦,一方面便于针对性进行扩容,另一方面将时延敏感度较低的业务分离,提高核心资源利用率。

利用云服务、CDN等第三方能力

对于一些静态资源或大文件读写场景,使用CDN缓存的方式来减少自身服务器的压力,同时云服务厂商很多功能目前都已提供弹性扩容能力,按需付费即可获得自动化的扩容缩容能力。以阿里云函数计算为例,预留模式中只需要配置好弹性伸缩规则,即可自动根据流量情况进行实例的扩容缩容。

实际业务场景中,往往不是单一地使用某一种扩容方法就能解决问题,选择哪种扩容思路取决于具体的业务需求、系统架构、预算以及预期的性能目标。最佳实践应当是结合多种扩容策略,实现灵活、高效、成本合理的系统扩展。

评估扩容需求的步骤和方法

最佳实践:高并发之扩容思路

评估是否需要扩容以及需要扩容哪些资源,通常需要进行全面的系统分析和性能监控,并且要能够准确地识别系统运行状态。

1. 性能监控:

使用监控工具(如Prometheus)来收集系统的性能数据,包括CPU使用率、内存使用率、磁盘I/O、网络流量、响应时间等。

分析性能数据,找出系统的瓶颈所在。例如CPU使用率经常处于高位,则可能需要增加计算资源;如果磁盘I/O压力大,可能需要升级磁盘或使用更快的存储解决方案。

2. 容量规划:

根据业务增长趋势和用户需求预测,进行容量规划。考虑未来的数据增长、用户增长和交易量增长等,预测所需的资源量。

对比当前资源容量和预测的资源需求,确定是否需要扩容以及需要扩容的规模。

3. 压力测试:

通过模拟高负载场景来测试系统的性能极限。这可以帮助确定系统在压力下的表现,以及哪些资源会成为瓶颈。

分析负载测试结果,找出系统在哪些方面需要改进或增加资源。

4. 应用分析和优化:

分析应用代码和架构,找出性能优化点。通过优化代码或改进架构,减少对资源的依赖。

使用 Kindling-OriginX 确定扩容策略

这里以 Kindling-OriginX 为例,说明如何使用其提供的北极星指标体系找到高并发场景下的瓶颈点,为扩容方向提供明确指引。

北极星指标

cpu

程序代码执行所消耗的CPU cycles

runq

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

net

网络时间,主要包括DNS,TCP建连,常规网络调用

futex

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

file

存储操作时间

通过上述指标的具体时间,我们就可以知道每一次调用程序具体耗时在哪些地方,结合SLO实时异常检测确认是否出现了影响用户体验的问题,即可快速对是否需要进行扩容,哪些节点,哪些资源需要扩容做出判断。

实战案例解析

下面以使用 Kindling-OriginX 为例,说明在实际生产环境中,如何有针对性地确定和实施扩容策略。以数据为导向,告别盲目使用扩容、升配试一试的方式应对高并发场景下的各种问题。

案例一

业务高峰期间通过SLO入口检测发现业务入口延迟变大,已经影响到用户体验。

最佳实践:高并发之扩容思路

通过查看慢调用的链路传播链,定位到造成影响的服务节点是ts-train-service

最佳实践:高并发之扩容思路

查看节点的北极星指标可以看到runq耗时异常,参照runq指标的含义,说明当前CPU不足,这种情况下优先考虑对该服务进行扩容。

最佳实践:高并发之扩容思路

案例二

该案例中定位到产品问题的节点是ts-order-service

最佳实践:高并发之扩容思路

同样利用北极星指标分析,发现是由于file耗时异常导致, 此时盲目进行横向扩容并不能解决问题,对该存储相关操作异常的原因继续下钻分析。

最佳实践:高并发之扩容思路

下钻后 Kindling-OriginX 将会定位到具体文件,及该文件具体的读写指标数据,通过这些数据首先分析该读写操作是否是正常业务行为,如果是正常业务行为,接下来根据读写情况来看是否需要对其进行读或者写扩展。如果文件读写较为平均,那么考虑对问题节点或机器的磁盘性能进行增加,采取垂直扩展的思路先解决问题,之后从代码设计层面和系统架构层面考虑重新设计该文件操作的业务流程。

最佳实践:高并发之扩容思路

最佳实践:高并发之扩容思路

通过上面两个案例可以看到,高并发场景下很多性能问题都可以通过扩容解决,但同样不存在银弹,盲目的扩大服务容量或提高机器性能,都可能只是无效扩容。没有合适的工具发现瓶颈点,选择了错误的扩容策略和方向,只会浪费时间、金钱、人力,却不能真正解决问题。

小结

最佳实践:高并发之扩容思路

在高并发场景中选择合适的扩容策略,往往要对系统整体架构和各个业务系统非常熟悉,同时也要对常见系统性能优化方式有深入了解,这都需要大量的经验积累和技术能力,也需要能合理根据实际场景选用先进的工具获取系统中的关键运行信息,不能一味生搬硬套业内经验。可以通过 Kindling-OriginX 等工具对系统执行过程进行无盲区的观测,以数据为导向,采取对症下药的扩容方式。