跳到主要内容

27 篇博文 含有标签「了解Kindling-OriginX」

查看所有标签

了解Kindling-OriginX

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

资深团队与前沿技术,携手云观秋毫迈向智能排障新篇章

云观秋毫 —— 开源创新引领eBPF技术,智能运维新纪元

云观秋毫,汇聚了国内eBPF技术领域的顶尖人才,致力于将创新的Trace-profiling技术应用于IT运维,为企业带来革命性的全故障域综合排障解决方案,最终企业能够成功实现1-5-10落地。

技术专精,开源创新

  • 开源贡献:云观秋毫团队是国内知名eBPF开源项目Kindling的核心贡献者,展现了团队在eBPF技术领域的领导地位和专业实力。
  • Trace-profiling技术:我们基于大神Brendan的TSA方法论独创的Trace-profiling技术,利用eBPF技术捕获程序执行的关键数据,为性能优化和故障诊断提供深度洞察。
  • 北极星排障指标:通过对Trace-profiling数据分析,我们提炼出关键的北极星排障指标,为企业标准化、高效的故障排除提供指导。
  • 智能排障流程:结合实时监控和智能算法,云观秋毫自动化诊断过程,极大提升运维效率和准确性。

开放合作,互补共赢

  • 技术社区:龙蜥社区系统运维联盟由清华、复旦、浙大、信通院、阿里云、浪潮、中兴、统信,云观秋毫、云杉网络、乘云科技作为首批联盟发起,联盟的宗旨是以推动系统运维技术进步、促进产学研合作为⽬的的⾮营利性组织。云观秋毫与复旦大学在联盟主要工作是构建故障案例集演示系统,这个故障案例集的主要目的是提供开源开放的故障案例集合,促成行业面对故障的时候能以统一的案例话术沟通,当前故障案例离真实环境还有一定距离,欢迎任何单位来贡献故障案例。
  • 集成方案:我们秉承不重复造轮子的理念,积极使用成熟的开源社区方案,形成了覆盖全域故障综合排障解决方案。

资深团队,实战经验

  • eBPF落地经验丰富:云观秋毫团队凭借在eBPF技术领域的深厚积累,已成功助力网易、好未来等领先企业及工商银行、浦发银行、兴业银行、国泰君安、华泰证券等金融巨头实现eBPF技术落地,获得业界广泛认可与赞誉。
  • 行业认可:团队的专业能力和创新技术在IT运维领域树立了良好的口碑,为云观秋毫的技术和服务提供了坚实的基础。

行动号召:

选择云观秋毫,让我们的资深团队和创新技术助力您的IT运维,共同开启智能排障的新篇章。

什么是 Trace Profiling

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

Skywalking 和 Kindling-OriginX 都对Trace Profiling做了定义,两者想要实现的目标是一致的,都是想看清楚Trace在某个环节到底是如何执行的,只是工作在不同层次,能够反应不同的问题。

Skywalking 的 Trace Profiling 工作原理是在代码层次上,看出每个线程周期性时间节点在代码上干什么,同时与Trace关联。

Kindling-OriginX 的 Trace Profiling 工作原理是在内核层次上,看出每个线程从资源上在干什么(在CPU上执行,网络等待、IO操作等),同时与Trace关联。

Trace Profiling 目标

在现代软件系统架构中,性能不仅仅是一个指标,它直接关系到用户体验和系统的可靠性。技术团队经常需要回答这样的问题:应用为什么这么慢?为什么会在这个时间点出现延迟?出现故障的原因到底是什么?故障时刻到底发生了什么?而Trace Profiling 就是一种可帮助我们找到这些问题答案的性能分析方法之一。

Trace Profiling 是一种详尽的性能分析方法,它通过记录软件运行时的具体事件来创建一个执行的时间线。这些事件可以包括函数调用、线程切换、I/O操作等。与传统的Sampling Profiling相比,Trace Profiling 提供了更细粒度的数据,使开发者能够精确地看到程序在任何给定时间点正在做什么。

Skywalking:Trace Profiling的工作原理

当你启用Trace Profiling时,分析器会跟踪程序的所有或特定部分的执行细节。通常,这涉及到插入额外的监控代码或使用特定的监控工具来捕获事件和时间戳。一旦数据被捕获,它就可以被用来生成报告,这些报告描绘了程序的行为,揭示了性能瓶颈和潜在的问题区域。更多信息可以参考 Trace Profiling - Skywalking

Kindling-OriginX:Trace Profiling的工作原理

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

利用eBPF技术能够深入内核,拦截线程执行用户代码的关键点位获取信息,在获得线程执行关键信息之后能够还原线程的执行过程。

如果只从线程维度看程序执行过程是很难分析出故障的,因为开发和运维的谈的故障都是URL维度的用户请求调用,所以光有线程维度程序执行过程是不够的,需要和tracing系统关联。

当线程执行过程与tracing系统关联之后,即可完整还原用户一次请求的执行过程。

Trace Profiling中关联了可观测性所需要的数据:

  • 指标
  • 日志

Kindling-OriginX : Trace Profiling能够实现的效果

Kindling-OriginX 的Trace Profiling工作在内核中,所以能够反应程序的所有执行情况,比如程序执行过程当中,出现了CPU时间片用完,排队等待调度都可以被Kindling Trace Profiling所发现,这些数据从代码层面是获取不到的。

  1. 所有线程的执行情况都被记录下来,并可以被重放。
  2. 执行跟踪跨度的确切线程被突出显示。
  3. 每个线程打印的日志被收集并与相应线程的时间戳相关联。
  4. 代码执行火焰图与 CPU 繁忙时间序列相关联。
  5. 与网络系统调用执行相关的网络相关指标与时间序列相关联。
  6. 与文件系统调用执行相关的文件相关指标与时间序列相关联。

正是因为Trace Profiling完整的记录了请求是如何被执行的,所以可以被用来构建排障北极星指标,用以标准化排障。

参考资料:

The TSA Method - Brendan Gregg

Trace Profiling - Skywalking

Trace profiling: Scalable event tracing on high-end parallel systems

Profiling and Tracing in Linux

什么是eBPF

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

eBPF 技术

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

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

eBPF 技术在多个领域得到应用,包括网络编程(例如网络包过滤、路由)、性能分析、安全监控、容器技术等。它已经成为许多现代系统中实现高级功能和控制的重要工具之一。 这里可以简单概括为 eBPF 是一套通用执行引擎,提供了可基于系统或程序事件高效安全执行特定代码的通用能力,通用能力的使用者不再局限于内核开发者;eBPF 可由执行字节码指令、存储对象和 Helper 帮助函数组成,字节码指令在内核执行前必须通过 BPF 验证器 Verfier 的验证,同时在启用 BPF JIT 模式的内核中,会直接将字节码指令转成内核可执行的本地指令运行。 68747470733a2f2f7069632e6372617a7974617869692e636f6d2f6f766572766965772d62663436333435356135363636666333666238343162393234306435383866662e706e67.png

什么是北极星排障指标体系

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

简介

北极星排障指标体系是一组指向性明确的指标,通过这些标准化的指标体系指出问题根因和结论,在排障过程中给予参与人员明确的方向指导,给出问题的明确界限。通过北极星排障指标体系,可以根据企业业务流程和自身工具情况构建出标准化的排障流程,进而真正能够在实际生产环境中落地1-5-10。

北极星指标

北极星指标也叫唯一关键指标(OMTM,One metric that matters),产品现阶段最关键的指标,其实简单说来就是公司制定的发展目标,不同阶段会有不同的目标。为什么叫“北极星”指标,其实大概的寓意就是要像北极星一样指引公司前进的方向,目标制定最好是能符合SMART原则,具体指具体(Specific)、可以衡量的(Measurable)、可实现(Attainable)、相关性(Relevant)、有明确的截止期限(Time-bound)。 北极星指标通常具有三个价值,指引未来、团队协同和结果导向。例如电子商务类的商业模式,他们的核心价值通常是用户下单购物,因此常见的北极星指标是GMV或订单量。对于媒体网站或内容类商业框架,企业更关注用户的阅读和创作,那么北极星指标通常为阅读量、停留时长、作品数等。而即时通讯类APP的核心价值是用户间的信息传输,所以企业通常会把消息数、发送消息的用户数等作为北极星指标。

北极星排障指标

目前问题

  • 传统可观测性工具存在盲区

目前虽然 Tracing、Metrics、Logging 已经成为绝大多数云原生业务的标配,但在实际生产环境中可观测性工具仍旧存在着很多盲区。实际应用过程中,大多数情况下往往仍旧采用填坑的方式,一方面在有可能有问题的部分增加日志及相关追踪信息,另一方面根据历史数据和经验在发生过问题的部分增加指标和相关事件记录信息,导致很容易丢失故障现场信息,同时无法真正发现问题根因。同时,传统可观测工具提供和记录的各类相关指标往往只有专家才能对其进行解读,并将其理解运用解决生产环境中的实际问题,这便使得数据、指标记录了,但是盲区却仍旧存在。

  • 排障周期不可预期

排障周期是指从发现问题到最终解决问题的整个过程。在理想情况下,这个周期应该是可预测的,这意味着团队可以估计出从识别问题到解决问题所需的时间。然而,在实际操作中,排障周期往往是不可预期的。主要原因有:排障极大程度上依赖参与排障人员的主观经验,排障知识的积累因人而异,导致其周期没法预估,受当次故障处置参与人员的经验和能力影响大;另一方面排障周期往往取决于故障发生时或发生前先看到什么现象,其会对处置人员的定位思路和处置决策产生影响,存在一定运气成分,进而使得同样的故障,即使是相同的根因,也会由于不同的现象导致排障周期不同。

北极星排障指标体系理论

基于目前的问题及困境,龙蜥社区与 Kindling 社区联合发布了北极星排障指标体系,通过将传统北极星指标的概念和方法论引入到排障流程中,构建出了一套排障指标体系与标准化的步骤,力求在目前困境中找到一条可操作可落地的标准化排障之道。

北极星排障指标-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

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

实现要点

  • OnCpu时间

进程真正获取cpu的时间,从获取cpu(sched_switch)到失去cpu(sched_switch)的时间。

  • Runqueue时间

进程在运行队列中的时间,记录线程从被唤醒(sched_wakeup)到获取cpu(sched_switch)的时 间;如果线程主动让出cpu,则记录失去cpu到重新获取cpu的时间。

  • 等待时间

进程从失去cpu(sched_switch)到被唤醒(sched_wakeup)的时间,然后通过sched_switch off 时抓的堆栈,进行阻塞原因分析。

  • 等待网络的时间

通过系统调用来辨别:__sys_recvfrom, sendmsg, recvmsg。

  • 等待存储的时间

通过系统调用来辨别: vfs_write, vfs_read, do_sys_openat。

  • 等待锁时间

futex: futex_wait, mutex_lock lock: mutex_lock, mutex_lock_interruptible

  • server端实际执行时间

应用采用同步方式向其他服务器发送请求或者发起新链接,或者进行 DNS,记录发送请求时的四元组: S1=(source_ip, source_port, dest_ip, dest_port);在 server 端进行监听,若获取的四元组 S2 和 S1 相同,则记录 server 端开始执行的时间戳 T1;当 server 端进行请求响应,获取四元组 S3,若 S3 的四元组与 S1 对应相同,则记录结束执行的时间戳 T2;T2 - T1 则为 server 端实际执行时间。

什么是根因分析

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

根因分析(Root Cause Analysis,RCA)是一种问题解决方法,用于识别问题的根本原因,然后通过解决这些原因来防止问题再次发生。它是一种回溯性过程,旨在发现问题的深层原因,而不仅仅是处理表面的症状或后果。

在可观测领域和IT领域内,根因分析是指在软件工程和系统管理中,当服务或应用出现故障时,通过监控和日志数据来识别导致问题的基本原因的过程。可观测性通常涉及三个主要的数据源:日志(记录事件的详细信息)、指标(系统性能的定量数据)和跟踪(记录请求流程的路径)。

不同人眼中的根因分析

运维工程师眼中的根因分析

在运维工程师或SRE部门承担着业务稳定的职责,所以出现问题之后,第一职责是确认到底该如何操作才能恢复业务。那么这里面需要根因分析吗?可能会有部分人认为运维不需要对故障做根因分析,只需关注进程是否存在,机器是否正常就好了,如果没有问题,就无脑重启业务就应该恢复业务了。 在一些IT架构不复杂,问题故障原因单一的情况下,很多时候是可以通过重启、回滚等手段恢复,但是IT架构一旦庞大起来,或问题根因比较复杂,特别是以微服务架构运行在云原生环境中时,重启能够恢复业务的几率就大大降低了,往往重启也只是一种无目的的猜测手段了。 在云原生环境中,运维工程师需要通过根因分析来达到恢复业务的目的。所谓根因就是运维工程师在故障发生时能够依据的结论,其后依靠这些结论来指导业务的恢复和故障的处置。 在这里例举下运维工程师可以采取的恢复手段,即使同类故障仍旧会在不久的将来再次发生。

  • 识别是代码缺陷,例如内存泄露、GC频率过高等,重启恢复业务。
  • 识别是代码缺陷导致CPU飙升、数据库QPS过高,在允许代码回滚的情况下通过回滚恢复业务。
  • 识别是流量过大的问题,如果确认是流量过大超过系统设计负载能力,在不变更架构设计的情况下,只能通过扩容或者限流措施来快速恢复业务。
  • 识别是共享资源的问题,取得明确的证据,减少跨公司跨团队的协作沟通成本,提交工单提供数据或相关日志,协助公有云或者云供应商更快的解决故障,恢复业务。
  • 识别是第三方软件依赖的问题,取得明确的证据,减少跨公司跨团队的协作沟通成本,督促第三方软件依赖快速解决故障,恢复业务。

运维工程师不可能在不了解故障根因的情况下,依靠穷举猜测试验的方式恢复故障,所以运维工程师非常需要了解到底发生了什么故障,该故障的根因是什么,才能真正的快速恢复业务,做到快速止血。所以针对运维工程师,故障根因结论是以下几种:

  • 位于哪个微服务节点的内存泄露、代码死锁——重启能够解决,确认是否能够重启还是扩容机器,减少风险。
  • 位于哪个服务节点的CPU飙升——确认是否能够回滚,或者扩容机器,减少风险。
  • 访问量激增——确认是扩容哪些节点还是限流某些节点来恢复业务。
  • 共享资源的问题
    • 如果是网络问题,确定哪个节点与节点之间的网络有问题,还是整个网段都有网络问题,提取证据,提交给公有云或者云供应商。
    • 如果是存储问题,确定是何种存储,提取证据,提交给供应商解决。
    • 如果是节点硬件或者配置故障,迁移机器。
  • 第三方依赖的问题,提交证据,交于第三方依赖厂商解决问题。

开发工程师眼中的根因分析

开发工程师往往承担业务实现的职责,但在系统故障时常需协助运维工程师定位运维中的根本原因。同时,开发工程师还需要承担软件缺陷和架构设计问题所致故障的复盘工作,以避免未来类似故障再次发生,并确保对系统及时进行优化。

因此,开发工程师视角下的根因分析需要有效指导故障复盘,能更好地还原故障现场,帮助开发人员理解故障发生的代码层或配置层原因,并及早发现业务架构设计层面的潜在风险。

常见的开发人员视角下的根因包括:

  • 代码死锁现象——开发工程师想知道的根因是锁住的代码块是哪些,代码分别持有锁的时间长度是多久。
  • CPU飙升——开发工程师想知道哪段代码导致的CPU飙升。
  • 内存泄露——开发工程师想知道哪些函数申请的内存具体多少。
  • 网络问题——开发工程师想知道具体访问哪些请求,做了哪些操作从而提取优化思路。
  • 存储问题——开发工程师想知道具体访问了什么文件,I/O是多少,访问频度如何,从而提前设计优化方案。

故障根因分析实践中的困境

虽然在现代IT系统中,各环境参与人员都急需合适的根因分析工具介入来提高效率,优化故障处置流程,但是目前根因分析在真正落地实施时面临多种挑战和困境:

  • 复杂性

现代系统的分布式和微服务架构增加了系统的复杂性,特别是云原生环境下资源服务的动态变化和基础设施故障也会对定位造成干扰,这些都使得故障的定位和根因分析难以实现。

  • 信噪比

系统可能会产生大量的日志和各类指标数据,特别是发生故障时尤为突出,但并非所有数据都与问题相关。过滤出有用信息并从中识别和定位出故障根因非常具有挑战性。

  • 文化和流程

组织文化和相关流程需要能够有所支持,一方面组织内部必须能够切实有效的认识到根因分析对于提高系统可靠性和发生故障时真正快速止血的必要性,另一方面团队内部也需要有适宜的协作机制和流程,促进各团队间能够快速修复问题,并且深入挖掘其根本原因,能够做到快速止血的同时也能够彻底解除隐患,落地实践 1-5-10 等高效的故障处置流程。

关于故障注入平台

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

开源模拟故障案例集系统soma-chaos是针对train-ticket注入故障,并实时查看故障状态的图形化故障案例模拟系统。 龙蜥社区系统运维联盟由清华大学、复旦大学、浙大大学、信通院、阿里云、浪潮集团、中兴通讯、统信软件,云观秋毫、云杉网络、乘云科技作为首批联盟发起成立,联盟的宗旨是以推动系统运维技术进步、促进产学研合作为⽬的的⾮营利性组织。开源模拟故障案例集项目由龙蜥社区系统运维联盟发起,联合各大运维厂商、平台厂商和科研院校、事业单位共同参与的,旨在通过建立一套故障演练平台,为平台厂商、运维厂商和广大客户建立起沟通的桥梁和纽带,让客户对运维产品拼图有全局认识。 云观秋毫与复旦大学在系统运维联盟中的主要工作是负责构建故障案例集演示系统,提供开源开放的故障案例集合,推动并促成行业面对故障的时候能以统一的案例话术沟通。更多信息可参考: 故障注入平台

故障注入使用指南

[gitee] soma

Chaos Mesh

故障案例集

故障注入平台中涉及的案例集来源于开源开放的故障案例合集,欢迎各团队和组织共享相关案例集。构建该案例集宗旨是:

  • 覆盖主流开发技术
  • 开源开放,欢迎所有人一起完善故障案例
  • 任何人都可以在私有环境构建部署
  • 任何人可以产生一致理解的典型故障
  • 绝大多数故障案例可以恢复,案例可以重复实验

关于Train Ticket

"Train Ticket" 是由复旦大学开源的微服务基准系统,用于教学、研究和实践微服务技术和云原生应用开发。该项目模拟了一个在线火车票预订平台,包含一系列协作的微服务,每个服务都承担着不同的业务职责,如用户认证、票务查询、订单管理等。项目为学生、研究者和开发者提供了一个实际的微服务系统案例,帮助他们学习现代软件工程的实践,尤其是在微服务架构设计和运维方面。更详细的资料可参见该项目 GitHub 主页: Train Ticket:A Benchmark Microservice System

故障注入简介

故障注入(Fault Injection),也称为错误注入或故障注射,是一种软件测试技术,用于增强系统的鲁棒性和可靠性。这种方法通过人为地在系统中引入故障或异常条件,来模拟软件、硬件或网络的潜在错误,目的是为了验证系统在面对真实世界中可能遇到的故障时的行为。

故障注入的作用

  • 验证系统的错误处理和恢复能力

确保当系统遇到故障时,构建的日志与监控系统能够正确地记录错误信息,响应的容错与恢复机制能够执行必要的回滚操作,并在可能的情况下自动恢复服务。

  • 评估系统的容错能力

测试系统在面对故障时是否能够继续运行,即使是以降低的性能或功能。

  • 提高系统的可靠性

通过发现和修复在故障注入测试中暴露出的问题,提高系统的整体可靠性,优化系统整体架构和设计。

  • 理解系统的行为

在极端情况下,更好地了解系统可能的行为,以便在设计和实施阶段对这些极端情况加以合理的容错和恢复机制,保证在条件允许的情况下尽可能的提高系统的可靠性和稳定性。

内核视角下持续剖析 VS 代码视角下的持续剖析

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

内核视角下持续剖析 VS 代码视角下的持续剖析

火热的eBPF技术当下在可观测性领域的应用热点有两个主要的方向:

  • 从内核中打开网络黑盒拿到相关的数据
  • 利用eBPF技术实现Continues Profiling

在GitHub上,国内外的 eBPF 主流开源软件是打开网络黑盒提高可观测性,另外一部分就是Continues Profiling,其中Continues Profiling最有名的就是Pyroscope项目,并被Grafana收购。

什么是Continues Profiling?

以下内容来自于GPT4的回答:

持续剖析(Continuous Profiling)是一种软件性能优化技术,旨在实时收集程序运行时的性能数据,如CPU使用率、内存分配、线程锁等待时间等。这些数据通常通过在代码中嵌入剖析器(Profiler)来收集,剖析器能够监测和记录应用程序在执行过程中的各种性能指标。

持续剖析的目标是帮助开发者理解应用程序在生产环境中的实际运行性能,从而发现性能瓶颈和优化机会。与传统的剖析(通常在开发或测试阶段进行)不同,持续剖析强调在应用程序的整个生命周期内,尤其是在生产环境中不断进行性能监控和优化。

持续剖析的好处包括:

  • 实时性能监控:通过持续收集性能数据,开发者可以实时监控应用性能,及时发现和解决问题。
  • 发现隐蔽的性能问题:某些性能问题可能只在特定条件下或在生产环境中出现,持续剖析帮助发现这些难以在测试阶段发现的问题。
  • 优化资源使用:分析性能数据可以帮助开发者优化代码,减少资源浪费,提升应用效率和响应速度。
  • 提升用户体验:通过优化应用性能,可以直接提升最终用户的体验。

持续剖析通过集成到CI/CD流程、自动化工具和监控系统中,成为现代软件开发和运维的重要组成部分。它使得性能优化成为一个持续的过程,而不是一次性的任务,有助于构建更高效、更稳定的软件系统。

最原始的Continues Profiling概念主要停留在CPU代码上的采集,形成火焰图帮助大家理解代码在CPU上是如何运行的。但是这点对于分析清楚线上的性能问题是不够的,因为线上代码是复杂的,程序依赖的条件不仅仅有CPU,还有锁、网络IO、磁盘iO等各种事件, 所以可观测性巨头如Datadog在他们的Continues Profiling理解中已经增加了很多。

代码视角下的持续剖析

Datadog对Continues Profiling的理解,可观测性的终极大杀器

Datadog其官网对Continues Profiling的能力定义:

  • Never miss production issues originating from your code by continuously profiling every line across all hosts and containers.
  • Enable engineers of all levels to swiftly spot and resolve problems using Watchdog AI's insights and suggested fixes.
  • Pinpoint methods and code lines that are inefficient under production load, despite having performed well in pre-production environments.
  • Find the root cause of slow requests by correlating spans with profiling data.
  • Gain thread-level visibility into your requests to investigate parallelization, deadlocks, inefficient garbage collection, locks, and more.
  • Determine exactly what your slow methods are spending time on — CPU, locks, I/O, garbage collection, and more.

从能力角度来看,Datadog的Continues Profiling能力像银弹一样,成为了可观测性的终极方案,无论什么问题,CPU, locks, I/O, garbage collection等各种问题,Datadog的Continues profiling都能够给轻松给出答案。

开源项目对Continues Profiling的理解,像Datadog学习

以Pyroscope为例,最开始的Pyroscope提供了eBPF为内核的OnCPU数据采集和内存相关数据采集能力,主要的分析的能力是CPU、内存分配对象、内存分配空间、在用对象、在用空间、Goroutines等多种类型。

最近去Pyroscope的官方Demo上看,发现其演进思路也基本上往Datadog的方向靠近了,出现了对于lock的持续剖析功能。

内核视角下持续剖析 VS 代码视角下的持续剖析

国内同行业专家也是非常认可Datadog的思路

某公有云可观测性软件发版了其持续剖析的功能,虽然没有实际使用过,从功能列表来看,已经很接近Datadog的能力了。

国内其他的可观测性公司也在致敬Datadog的方法论,提供类似的数据。

Datadog的Continues Profiling核心设计哲学

  • 内核是稳定的

  • 代码是业务开发的,开发者只关心代码要如何修改才能解决问题

  • 火焰图长时间执行的代码块能帮助用户理解问题,并启发用户产生解决思路

  • 正因为Datadog是沿着这个思路设计产品的,其持续剖析功能的实现就是从代码层面上去剖析问题,但是这样的设计哲学有一定局限性。

Datadog代码层面的持续剖析局限性

为了让大家更好的理解问题,举例说明,如果大家看到了这张火焰图能够得出什么结论:

内核视角下持续剖析 VS 代码视角下的持续剖析

从代码层面的持续剖析数据来看,代码是由于记录日志时间很长,那为什么呢?可能有常见的排查思路继续深入排查:

  • 日志由于并行写,产生了锁

  • 磁盘可能出现了问题,导致日志写变慢了

  • 长时间的GC

如果上述的排查思路都没有结果,方向就比较迷茫了。

从内核视角的持续剖析

基于TSA的性能定位问题方法论

有兴趣的朋友可以深入理解大神brendan的文章The TSA Method,或者参阅TSA方法:基于线程时间分布分析性能瓶颈

对于没有耐心的朋友,这里做个快速简介:就是将线程在不同状态下切换过程,按照下图所示对程序执行过程进行分析,从而理解线程在执行程序的时候到底卡在哪个环节。

内核视角下持续剖析 VS 代码视角下的持续剖析

从内核视角的持续剖析有什么优势和劣势

优势

  • 真实反应程序正卡在什么地方

  • 准确与精准没有任何其他可能性

  • 内核反应出来的卡住的问题比代码卡住的问题场景少很多,线程只可能卡在以下几个方面:CPU执行,CPU调度,网络IO,磁盘IO,锁。这个为后续的智能化分析提供很好的基础

劣势

  • 内核视角缺少业务属性,不知道哪个线程在哪个时间段为哪个业务服务,除非在性能压测场景,URL访问单一,可以在线程行为中找到模式匹配业务开始与结束,否则人很难分析

  • 内核系统调用和相关知识对于普通业务开发人员而言太陌生,导致即便看到了内核相关系统调用比如说futex执行时间很长,不能理解这在代码层面上意味着什么

TSA的方法论结合Trace带来不一样的视角

开源项目Kindling的Trace-Profiling解决了单独TSA的持续剖析方法的劣势之一:内核视角缺少业务属性。Trace-Profiling通过TSA的方法论产生的数据与Trace打通,做到了与业务关联,这样在生产环境就可以做到某个业务因为什么原因卡住了。

还是以这个火焰图为例,代码剖析反应程序卡住在了日志代码之上。

内核视角下持续剖析 VS 代码视角下的持续剖析 如果使用Trace-Profiling,应该能够明确给出当时业务是卡住下列事件之一

  • RunQ

  • Futex

  • CPU

  • DISKIO

代表代码执行的线程卡在什么地方知道了,那接下来就是如何理解和翻译了。

开发人员对内核的理解是推广TSA方法论的阻碍

云原生环境内核由于资源竞争带来的问题

绝大多数开发人员在正常业务开发当中较少接触内核,而且也会认为内核是不会产生问题。也许从单机而言,出现任何问题都极少的可能是内核调度产生的。但是一旦涉及到云原生环境,要提高资源利用率的场景,就需要多业务都在竞争对内核的使用,这个时候产生的竞争就超出了普通开发人员的常规认识,也就意味着云原生产生的问题比以往问题更多。

开发者对于内核理解有限

CPU调度产生的RunQ对于绝大多数开发而言太遥远,上述例子可能事件中也就DISKIO是开发人员能够快速理解的,其它都需要花费更多的精力去学习。学习成本带来了推广难度,所以业界几乎没有看到基于TSA方法论的工业化产品在推广。

问题总结

  1. 基于代码的持续剖析虽然对于开发而言足够友好,开发能看懂哪段代码带来的问题,但是由于代码的丰富多样性,看到代码卡住了,很多时候仍然不知道代码为什么卡住,并且现象可能有一定随机性。

  2. 基于TSA内核持续剖析的方法虽然能够精准定位业务卡在了什么内核事件之上,但是对于开发者不友好,不利于推广。

智能运维中的决策树结合TSA实现对内核事件的自动化翻译,完美解决当前持续剖析存在的问题

对于可观测性领域,AIOPS已经推广了很久,但是由于缺少一锤定音的数据特征,从而难以高准确率方式判定故障根因。

基于TSA的线程模型机制给出了程序的精准内核事件,相比于代码或者日志的N种场景,内核事件要精简得多。

举例说明:

一旦线程出现上内核事件RunQ,这说明线程在执行代码的时候,由于内核CPU调度的原因卡住了,这个时候在代码层面上可能在做一些做普通业务操作,比如前文例子觉得记录日志的代码卡住了,在代码层面上也可能是做了个网络操作卡住,从代码层面分析非常复杂,可能性非常多。但是从RunQ事件分析,就非常精准,只有这一个事件特征,不存在其他事件特征。

为了帮助用户理解,这个RunQ的事件就可以翻译成为当前CPU资源不足,应该扩容了,这样开发和运维就能很容易理解。

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

内核视角下持续剖析 VS 代码视角下的持续剖析

可观测性体系建设后,该如何挖掘数据及工具价值?

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

可观测性体系建设后,该如何挖掘数据及工具价值?

在现代企业的运维管理中,构建高效且可靠的可观测性体系是保障系统稳定性和业务连续性的关键。然而,运维团队成员的技术能力参差不齐往往成为实现这一目标的障碍。尤其在处理复杂系统故障时,高度依赖专业知识和经验的可观测性工具很难被全员有效利用,进而影响到其建设价值的体现。

可观测性体系建设后,该如何挖掘数据及工具价值?

可观测体系建设的意义

可观测性体系建设后,该如何挖掘数据及工具价值?

可观测性是近几年来最热门的话题之一,许多企业和团队都投入了很多人力、物力来进行可观测体系的建设,以期能获得可观测性的核心价值:快速排障(troubleshooting)。可观测性体系是指通过一系列技术手段和方法,对系统的运行状态、性能指标、业务流程等进行实时监控、分析、预警和优化的一种体系。它可以帮助企业及时发现和解决问题,提高运维效率,降低故障风险,为业务发展提供有力支持。

1. 提高运维效率

通过实时监控云原生应用的运行状态,运维人员可以快速发现并解决问题,减少故障排除时间,提高运维效率。

2. 保障系统稳定性

可观测性体系可以帮助开发者及时了解应用在云环境中的表现,发现并修复潜在的性能瓶颈和错误,从而保障系统的稳定性。

3. 优化资源利用率

通过收集应用的性能数据,可以对资源的使用情况进行分析,实现资源的合理分配和优化利用。

4. 持续迭代与优化

可观测性体系建设和数据挖掘是一个持续的过程。企业应不断收集反馈,优化体系架构和数据处理方法,实现体系的持续迭代和提升。同时,关注行业新技术、新理念的发展,将先进经验融入自身建设中,保持体系的竞争力。

可观测体系建设完成后存在的问题和挑战

可观测性体系建设后,该如何挖掘数据及工具价值?

很多团队在完成了一定规模的可观测性体系建设后,却在具体落地推广,乃至实际价值体现上都遇到了阻碍,这些问题和挑战主要体现在两方面,管理层面与技术层面:

管理层面的挑战

技术能力的不均衡

团队内技能水平的差异导致高级工具和数据的利用率低下。可观测性体系建设完成后,需要将其向各相关团队推广,期望能帮助各团队提效,协助开发团队排查定位问题。

但实际情况下,往往把可观测工具提供给开发团队后,一方面业务开发团队使用工具存在学习使用成本,另一方面不是所有开发都有能力看懂和定位问题。这需要有平台或工具提供整合能力,来解决人员能力差异性。

经验知识难以传递

缺乏有效的机制将高级用户的经验和知识快速传递给新手或非专家用户。导致仍旧是依靠团队专家和骨干才能完成诸如故障排查等工作,团队内部长期存在差异性。

故障响应的差异性

在发生故障时,需要快速有效的响应,但技术水平不一致可能导致延迟处置,甚至处置结果不一致,这种差异性也导致不利于故障响应流程的标准化和故障处理手段的规范化。

技术培训和能力提升存在成本

提升团队整体技术水平需要大量的时间和资源投入,且往往是一项需要长期坚持的工作,只有这样才能逐步对齐各团队间对于可观测性工具和数据的理解和使用水平。但仍旧会存在长时间不使用导致的生疏问题。

技术层面的挑战

工具使用和指标含义都会生疏遗忘

对于一些团队来说,可观测性工具并不是需要经常使用,加之其存在一定的学习成本,所以会导致每次使用的时候都得学习或者咨询专家。同理对于一直较深入的指标数据,其具体含义也会遗忘,使用的时候也需要查阅相关文档,这都加大的使用门槛。

使用方式和术语不统一

对于工具的使用和可观测数据的理解,不同团队都有其各自的使用场景和理解,这也导致了需要团队协作时增大了沟通成本,例如用户中心的团队使用Skywalking,负责消息推送的团队使用了OpenTelemetry。

故障响应的差异性

在发生故障时,需要快速有效的响应,但技术水平不一致可能导致延迟处置,甚至处置结果不一致,这种差异性也导致不利于故障响应流程的标准化和故障处理手段的规范化。

工具和标准的不统一

作为当今热门话题之一,各类可观测性工具及产品百花齐放,导致很多团队为了建设可观测性而不停的追热点,忙于工具的更新换代,方法和思路越没有同步进行更迭,更没有能够真正挖掘出可观测数据的价值。

需要更先进的工具和方法挖掘可观测性体系价值

可观测性体系建设后,该如何挖掘数据及工具价值?

Kindling-OriginX 通过Trace-profiling关键数据,以专家经验串联起来所有的可观测性数据,并推理成故障结论,最大程度发挥可观测性数据的价值。通过推理分析能力来平衡团队内的技术能力差异,确保每位团队成员都能有效利用可观测性数据,从而提升其建设价值的认可。

很多企业可观测性数据上了很多,但是推广效果不是很好,价值体现不佳。其主要原因是故障并不是经常发生,所以导致用户对于可观性工具使用生疏,加上一些疑难杂症的故障需要看深入的指标,这些指标含义不用就会忘记。这都需要有更先进的工具对数据指标进行提炼分析,直接给出可解释的结论。

  • 简化的操作界面

    为所有技术水平的用户提供易于理解和操作的界面,降低使用门槛。直接根据故障结论进行预案执行。

  • 自动化智能故障推理

    利用 eBPF 技术与自动化 Tracing 分析将多而杂的链路数据、指标数据、日志数据转化为直观的故障分析报告,无需深入的专业知识即可理解。

  • 最大化可观测性数据价值

    自动关联各类可观测性数据,完成可观测性数据价值挖掘。

  • 内化的排障知识库

    既是推理引擎,也是一个排障专家经验知识库,借助专家经验知识库平台能力能够迅速提升团队能力。

结语

本文探讨了可观测性体系的建设的意义及其根本目的,同时随着可观测性体系的建设也遇到了很多问题和挑战,对于这些问题和挑战都需要更先进的工具和方法,这样才能够充分挖掘和发挥可观测性工具和数据的价值。

在实践中,应当持续优化可观测性体系,确保数据的全面性和准确性,同时不断提升数据处理和分析能力。这不仅需要技术的进步,更需要方法的革新,一方面将可观测性融入到我们的开发和运维文化中,另一方面通过使用诸如 Kindling-OriginX 的创新型工具里帮助快速提升对于可观测性数据的使用水平,帮助提高团队综合能力。

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

· 阅读需 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 官方网站。

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

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

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

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

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

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

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

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


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

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

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


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

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


地铁上一大哥正在改bug

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


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

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


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

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


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

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


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

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

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