开发者小白的亮点反击：我一眼就可以断定生产环境接口响应慢是磁盘性能问题s或以上导致的，接口实现逻辑包括数据库操作、文件操作、下游微服务调用,等业务逻辑计算代码。如何快速排除故障？团队其他开发同学还是急着按照以下常规步骤排查问题：确定问题根源：分析日志、代码等数据信息，判断是哪部分逻辑代码导致时间异常——consing根据问题的根源，逐步排查是否是资源故障：检查磁盘、CPU、内存利用率，看是否有资源被过度使用；检查磁盘是否存在性能瓶颈；检查网络利用率以查看是否存在网络拥塞。检查硬件……这个是用排除的方法推回去，靠经验，排除故障的时间因人而异。另外，查看一些指标需要运维配合，指标也是通过时间范围进行历史查找。如果看的是近似值，可能会有误差。02养成小白高光逆袭，一目了然定位病根，就像案发现场的监控录像让警察一眼就能看出谁是真凶。有一位机智的开发者，利用Kindling程序摄像头，准确还原了界面执行场景的能力。一目了然地找到根本原因。他用程序摄像头拍下了这个接口在生产环境中的执行轨迹。从Span分析来看，他只看到文件操作比较耗时，并不能确定原因。因此，像Skywalking这样的常见踪迹追踪工具只能进行勾选。至此，无法知道程序在1.47s的异常耗时期间做了什么。而Kindling也可以看到下层的“接口执行现场”信息：生产环境：问题接口Trace中的Span分析当他继续点击span看到Trace执行主线程的事件分析时，发现了problem:productionEnvironment:问题界面的Trace分析如上图所示。Trace的主线程花费了大量时间来处理文件打开事件。理论上，fileopen（即操作系统打开存储在磁盘上的目标文件）只需要几毫秒。继续。主要耗时应该只是CPU完成的运行事件，即系统将文件数据从内核态拷贝到用户态。于是，他又用程序摄像头在测试环境下抓取了界面的Trace：测试环境：问题的界面Trace分析很明显。测试环境下fileopen事件正常耗时，所以界面响应时间正常。由此，他断定生产环境中界面响应时间异常是磁盘性能问题造成的。03故障排除总结下面思路简单明了。检查磁盘，最后发现磁盘损坏，更换后恢复正常。当您遇到云服务器磁盘性能问题时，可以通过以下方法解决：优化磁盘读写性能：如果发现磁盘读写性能不佳，可以考虑格式化文件系统以更有效的格式并启用磁盘缓存。更换磁盘：如果磁盘的读写性能确实很差，可以考虑更换磁盘以获得更好的性能。更改云服务器硬件配置：如果云服务器磁盘性能不够，可以考虑更改云服务器硬件配置，提升云服务器磁盘性能。优化系统配置：考虑修改系统配置以优化磁盘读写性能，例如更改文件系统缓存大小。检查磁盘状态：如果无法解决磁盘性能问题，请考虑检查磁盘状态以识别磁盘故障。按照常规的排查思路，其他同事终于可以定位到磁盘性能的问题，但是期间投入的时间是不可控的。下面介绍使用Kindling程序摄像头技术进行故障排除。我认为这是一个颠覆性的工具，欢迎感兴趣的同学继续阅读。04附录-Kindling程序摄像头技术介绍Kindling程序摄像头精准还原场景，10分钟排错黄金时间。许多公司愿意花高薪聘请高级开发人员。很大一部分原因是花钱买他的经验，靠专家能力保证系统稳定。性和性能。但是很多普通的开发者在这个行业有着不同程度的经验。我们不是专家。难道我们遇到生产故障就直接敲CURD代码，完全没有头绪吗？kindling程序摄像头的初衷是帮助所有开发者以分钟级标准步骤，对各类资源故障进行根源定位，降低专家门槛。在标准化步骤中查找：通过Trace系统，结合时间点，找出可能有问题的关键点我一开始就拒绝了，故障千奇百怪，怎么可能通过3个标准找出根本原因脚步？这牛是不是有点太夸张了？但是，经过多次实验和反复论证，我渐渐明白了Kindling之所以敢这么“带”的原因：生产环境是一个黑盒子，大多数情况下，我们都是从失败结果逆向过程，排除各种可能.找出根本原因。Kindling程序摄像头从系统内核级线程事件分析角度，精准还原程序执行场景。它让我们从过程中分析根源，“雁过留痕”，所有的故障在程序??执行过程中都会产生不同于正常情况下的痕迹。这三个标准步骤将引导我们找到这个痕迹，然后定位根本原因。分钟级定位：行业故障排除时效性目标，1分钟发现-5分钟响应-10恢复没有Kindling，我依然可以排查故障根源。话虽如此，条条大路通罗马，但生产环境故障排查及时性是关键。没有人，没有故障排除工具可以保证1-5-10的及时性目标。在之前的排查过程中，我们需要在数据库、日志、终端、apm等排查工具之间来回切换，配合运维从海量数据中筛选整理有效信息。这个过程是最耗时的，也是最依赖个人经验的。而Kindling的程序摄像头技术恰恰是帮助开发运维完成这个过程。它基于eBPF技术，集成了Tracing、Logging和Metrics。换句话说，它已经筛选并捕获了与接口相关的所有数据（例如，mysql、redis、日志、堆栈、锁信息、文件IO信息等网络请求的连接信息和消息信息），以及附加到相应的线程事件上。下图是一个数据库网络连接事件的示例。点击事件查看具体信息：基于此，我们将不再对问题毫无头绪，无从下手，也不再需要看这个查那个，浪费时间，我们只需要看哪个指标与预期不同并分析根本原因。定位各类资源故障根源上一点提到，Kindling程序摄像头技术集成了很多指标数据，会持续采集网络指标（如带宽、rtt等）、CPU利用率，以及接口执行时的磁盘性能指标。、内存利用率等信息抓取并集成到Trace分析中，从而实现对各类资源故障的根因定位。
