共计 2405 个字符，预计需要花费 7 分钟才能阅读完成。
01 问题背景
某接口在测试环境耗时 600～700ms 左右，但在生产环境耗时在 1.4s 以上，接口实现逻辑蕴含数据库操作、文件操作、上游微服务调用和其余业务逻辑计算代码，该如何疾速排查？
团队里的其余开发同学还在慌手慌脚地按以下这些惯例步骤排查：
- 确定问题源：剖析日志、代码等数据信息，确定接口是因为哪一部分逻辑代码引起的异样耗时
- 依据问题源，逐渐排查是否是资源故障：查看磁盘、CPU、内存的利用率，看是否有任何资源被适度应用；查看磁盘是否有性能瓶颈；查看网络利用率，是否存在网络拥挤。
- 查看硬件
- ……
这是采纳排除法倒推，依赖教训，排查工夫因集体的能力而异。另外查看某些指标还须要和运维合作，而且指标也是通过工夫范畴去进行历史搜寻，看个大略值，可能存在误差。
02 开发小白高光逆袭，一眼定位根因
就像犯罪现场的监控视频能让警察一眼看到真正的凶手是谁一样，有一个机智的开发同学借助 Kindling 程序摄像头精准还原接口执行现场的能力，一眼定位根因。
他用程序摄像头捕获了生产环境该接口的执行 Trace，从 Span 剖析上看，只看到文件操作占了大量耗时，无奈确定其中起因，所以像 Skywalking 这种常见的 Trace 追踪工具，只能排查到这一步，无奈晓得在 1.47s 异样耗时内，程序做了哪些事件。而 Kindling 还能看到更底层的“接口执行现场”信息：生产环境：该问题接口 Trace 中的 Span 剖析
当他持续点击 span，看到 Trace 执行主线程的事件剖析，他发现了问题苗头：生产环境：该问题接口 Trace 剖析
如上图，该 Trace 的工作主线程，消耗了大量的工夫在做 fileopen 事件，实践上，fileopen(即操作系统关上存储在磁盘上的指标文件)只需几个 ms 足矣。次要耗时应该只是 cpu 做的 running 事件，即零碎将文件数据从内核态拷贝到用户态。于是，他再次用程序摄像头捕获了测试环境下该接口的 Trace：测试环境：该问题接口 Trace 剖析
不言而喻，测试环境 fileopen 事件耗时失常，所以接口响应工夫失常。由此他判定该接口响应工夫在生产环境异常是因为磁盘性能问题导致的。
03 排障总结
接下来的思路就简略分明了，查看磁盘，最初发现该磁盘损坏，替换后恢复正常。当大家遇到云服务器磁盘性能呈现问题时，能够通过下列办法解决：
- 优化磁盘读写性能：如果发现磁盘读写性能较差，能够思考将文件系统格式化为更高效的格局，并且启用磁盘缓存。
- 更换磁盘：如果磁盘读写性能的确过差，能够思考更换磁盘，以便取得更好的性能。
- 更改云服务器硬件配置：如果云服务器磁盘性能不够，能够思考更改云服务器硬件配置，以进步云服务器磁盘性能。
- 优化系统配置：能够思考批改系统配置，以便优化磁盘读写性能，如更改文件系统缓存大小等。
- 查看磁盘状态：如果磁盘性能问题无奈解决，能够思考查看磁盘状态，以便找出磁盘故障。
其余共事依照惯例排障思路，最初也能定位到是磁盘性能的问题，但期间投入的工夫是不可控的，下文是对于应用 Kindling 程序摄像头技术排障的介绍，我认为它是颠覆性的工具，有趣味的同学欢送持续往下看。
04 附录 – Kindling 程序摄像头技术介绍
kindling 程序摄像头精准还原现场，10 分钟黄金时间排障很多公司违心花高薪招聘资深开发，有很大一部分起因是花钱买他的教训，借助专家能力保障系统的稳定性和性能。但很多一般开发者从业教训深浅不一，咱们不是专家，难道咱们就只能吭哧吭哧敲 CURD 代码，一遇到生产故障就毫无脉络，只能找大佬吗？kindling 程序摄像头的初衷就是，以标准化步骤，帮忙所有开发实现分钟级定位全资源品种故障根因，升高专家门槛。
- 以标准化步骤
- 找：通过 Trace 零碎，联合工夫点，找出相干可能存在问题的要害 Trace
- 查：通过要害 Trace，查问其对应的 Span 信息
- 剖析：剖析 Span 信息中的何种指标与预期不符
其实这个观点一开始我是回绝的，故障千奇百怪，怎么可能通过 3 条规范步骤就排查出根因？这牛是不是吹得有点过了？然而，通过屡次试验重复论证，我逐步意识到 Kindling 敢这么“吹牛”的起因：
生产环境是黑盒子，大多数状况下，咱们都是从故障后果反推过程而后排除各种可能性，最初失去根因。而 Kindling 程序摄像头以零碎内核级别线程事件剖析的角度，精准还原程序执行现场。它让咱们从过程剖析根因，“雁过留痕”，所有故障都会在程序执行过程中产生和失常状况下不同的痕迹，这 3 条规范步骤就是带咱们找到这个痕迹，进而定位根因。
- 分钟级别定位：行业内排障时效性指标，1 分钟发现 - 5 分钟响应 -10 复原
没有 Kindling，我照样还是能排查出故障根因，话虽如此，条条路线通罗马，但生产环境排障时效性是要害。没有任何人、任何排障工具能保障 1 -5-10 的时效性指标。在以往排障过程中，咱们须要在数据库、日志、终端、apm 等排查工具来回切换，和运维合作，从海量的数据中筛选组织出无效的信息。这一过程是最耗时、最依赖集体教训的。而恰好 Kindling 的程序摄像头技术就是帮开发 & 运维实现了这一过程，它基于 eBPF 技术交融了 Tracing，logging，metrics。换句话说，它曾经把该接口相干的所有数据（比方，mysql、redis 等网络申请的连贯信息和报文信息、日志、堆栈、锁信息、文件 IO 信息等等）都筛选捕获进去，附着在对应的线程事件上。如下图是数据库网络连接事件样例，点击事件即可查看具体信息：
基于此，对于问题咱们不会再毫无脉络、无从下手，也不再须要去看这个查那个，浪费时间，咱们只须要查看哪个指标异于预期，进而剖析根因。
- 定位全资源品种故障根因
正如上一点提到的，Kindling 程序摄像头技术交融了很多指标数据，后续也会持续把接口执行时刻的网络指标（比方带宽、rtt 等），CPU 利用率，磁盘性能指标、内存利用率等等信息捕获交融到 Trace 剖析中，以实现全资源品种故障根因定位。