Kindling 程序摄像头——Trace-Profiling 功能正式发布
“ Trace-Profiling 通过 eBPF 技术将程序代码执行过程转换成操作系统资源消耗过程,并融合 tracing、logging、metrics 等多种可观测性技术,形成一个类似光学摄像头的程序摄像头。主要可以帮助开发者了解程序执行过程当中每一毫秒在干什么。”
Q:Trace Profiling 可以解决什么场景下的问题?
A:请参考:Kindling程序摄像头——Trace-Profiling功能正式发布
Q:Trace Profiling 捕捉的是一次请求下,所有工作线程的执行实况,这些线程是指请求执行这段时间内,执行了事件的线程吗?
A:捕捉的是所有工作线程的执行情况。从 eBPF 角度是分不出来哪些线程是与请求有关,所以我们有个关键线程概念,关键线程概念就是执行此次请求的线程,之所以展示所有线程的执行情况目的是为了能够发现关键线程在执行过程中被挂起的原因,很可能是由于其它线程如 JVM 虚拟机线程执行 GC 操作导致的。我们当前没有办法完全识别所有的场景,到底哪些线程的执行行为会影响关键线程的执行过程。为了能够真实还原程序的执行情况,所以我们将所有工作线程的执行情况都记录展示出来,之后靠人为对比分析关键线程被挂起时,其它线程在做什么,从而判断是哪些线程导致关键线程被挂起的。
Q: 这么多工作线程,什么是本次请求的关键线程?判定依据是什么?
A:关键线程是在此进程当中,处理此次请求的线程。判定依据是通过与 tracing 系统做集成,比如与 skywalking 集成,可以清晰无误的判定处理此次请求的线程。
Q:Kindling agent 是怎么捕捉到线程的执行事件的?又是怎么划分某个事件具体是在 net?lock?futex?cpu on?file?epoll?other?
A:通过对多次 switch 做判断,从而判断出 oncpu 的时间。通过对关键系统调用进行区分判断 offcpu 类型,比如 write read 归属到 IO,再根据 fd 的属性是网络还是文件从而判断是网络 IO 还是文件 IO。epoll 就是网络系统调用。futex 是一个比较难以解释的系统调用,因为程序在太多场合使用了 futex,目前已经识别主要场景有如下:
线程空闲
线程执行锁操作
线程被挂起
java 程序的 sleep 操作实现
我们是通过如下规则判断 futex 到底是何意义的:
在关键线程的 trace start 时间之前的 futex 是空闲状态
从 JVM 中获取 java 虚拟机层面锁相关信息,通过此信息解释在关键线程 trace start 与 trace end 的 futex 时间
在排除以上两种情况之后,在关键线程 trace start 与 trace end 之间的 futex,绝大多数情况我们认为就是被其他线程干扰导致的挂起时间。在执行一次 trace 当中的业务代码当中,我们认为基本不会有开发写 sleep 操作,如果有写,确实在当前情况下,是比较难以区分 sleep 的 futex 与线程干扰的挂起操作。
Q:一次请求的 IO/Trace start、End 分别从哪一刻开始算?
A:对于一次请求过程而言,实际执行流程是操作系统先完成数据准备,也就是 IO start,等有可用执行线程之后,线程会将 IO http 数据转成序列化对象,然后调用 springcloud 的 control 或者 dubbo 的服务接口开始一次 trace,所以 IO start 是早于 trace start 的,但是在显示的时候,两者时间可能非常接近,所以基本重合了,但是如果出现线程不够的情况下,可以明显看出 io start 早于 trace start。当请求 trace 在业务代码层被处理结束之后,也就是 tracing 系统将 trace 发出来的时候 trace end 会被记录,之后当请求对应的响应通过系统调用写回的时候点,我们记录为 io end。
Q:Kindling agent 安装为什么要基于 k8s 的环境?如果小公司没有装 k8s 环境,不装 docker 可以用 Trace Profiling 吗?
A:理论上非 k8s 环境是可以使用,但是 kindling 目标用户是云原生的用户,非 k8s 的用户不是我们的目标用户。主要有以下几点考虑。
在非云原生的环境中操作系统版本对 eBPF 的支持可能性较低
在非云原生的环境中,遇到比较复杂的问题可能性较小,简单问题可以使用 tracing、logging、metrics 工具解决
Q:使用 Trace Profiling 前,为什么要安装 Skywalking 探针?它在里面采集了哪些数据?和 Kindling agent 是怎么分工合作的?
A:之所以叫 Trace profiling 就是要分析一次 trace 中的 span 实际执行情况,所以一定需要和 trace 系统对接才能得到 trace 相关信息。因为我们目前只对接了国内常用的 skywalking,所以要求用户先安装 skwwalking 探针,skywalking 探针采集的数据就是按照其原有工作正常工作,我们没有改造 skywalking 探针。对接原理就是我们需要 trace 探针或者 sdk 通知我们当前执行的请求的线程是哪一个线程,以及 trace 开始时间和结束时间。
Q: 如何安装 Kindling,并开启 Trace Profiling 功能?
A:请参考安装教程:http://120.26.58.66/docs/usage/enable-trace-profiling/
项目开源地址:https://github.com/CloudDectective-Harmonycloud/kindling
官网地址:http://kindling.harmonycloud.cn
Q: 如何操作使用 Trace Profiling?
A:请参考操作教程:http://120.26.58.66/cn/docs/usage/trace-profiling-manual/
Q:我还有别的疑问和想法,或者使用上遇到问题,该怎么联系你们?
A:可以添加小编微信、关注我们的公众号哦~
版权声明: 本文为 InfoQ 作者【KINDLING】的原创文章。
原文链接:【http://xie.infoq.cn/article/6b50e582b0df40da158c83136】。
本文遵守【CC-BY 4.0】协议,转载请保留原文出处及本版权声明。
评论