简介：并查看Sysak如何建立一个小型性能开销，安全，可靠和灵活的控制中断检测工具。
文本 /系统操作和维护SIG
编者注：我仍然记得曾经很受欢迎的Di Renjie的访问系列“他颤抖和颤抖，io诊断为我的手中”，“ Netinfo：揭幕网络抖动”，“ Coredump Slimming Storm”和其他人享受所有人。Internet，IO，内存和其他字段的绿色SAC的魅力。如前所述，内核模块已处理IO。今天，我将继续分享EBPF硬携带系统中断。让我看看Sysak如何创建一个小型的开销，安全可靠，安全可靠。并灵活地封闭的中断检测工具。
日常企业通常会受到各种干扰，以产生震动和影响客户体验。干扰的来源之一是中断。当中断长时间中断时，可能会导致业务流程计划的失败以及接收和接收的数据延迟。这种干扰长期以来一直伴有Linux内核。因此，Linux核心包括行业。无关的中断检测方法。这里是几个典型的解决方案：
1.内核的最大中断检查
内核本身将TRACE_IRQ_OFF跟踪指向系统中的所有控件/打开中断路径，以监视系统中的所有打开/关闭中断。
优点：断开中断检测是准确且全面的。同时，消除中断甚至堆栈的时间。
缺点：依靠config_irqsoff_tracer内核配置，配置不受许多分布版本的支持。有太多的堆点和热路径，对性能产生了更大的影响。
2.看门狗/硬锁检测器
内核注册了PMU硬件事件，定期检查注册的监视hrtimer中断的看门狗HRTIMER中断是否在及时更新。
优点：对性能影响很小的周期性检测适用于系统中断或中断处理的情况。
缺点：监视的粒度太大，无法提供精细的系统观察指标。如果没有PMU硬件事件，该解决方案对某些虚拟化环境没有生效。
3. trace_irq_handler_exit/trace_irq_handler_exit && irq_enter/irq_exit
在所有中断处理函数的入口/退出跟踪跟踪和时间记录。
优点：提供所有中断处理持续时间的原始数据。
缺点：它只能观察中断治疗的时间。对于其他不间断的路径，无法监控，没有阈值触发机制，并且需要在人工工作后分析人工工作。
4.其他开源检查工具
GitHub上还有许多相关的中断检查工具。它们由.KO模块提供，以检查HRTIMER计时器的到期时间是否超过预期的时间。
优点：周期采样系统的周期不大，提供毫秒级别的监视粒径。
缺点：由第三党模块提供，无法保证稳定性。HRTIMER是正常的中断，需要检测到它在恢复中断之前。不能保证准确性。在同一时间，中断功能的延迟将丢失先前的中断信息。
上面的每种测试机制都有自己的缺陷和不舒服的场景。并查看Sysak如何创造少量的性能费用，安全，可靠和灵活的闭合中断检测工具。
上述工具上面选择的技术，实施方法和检测逻辑在不同情况下在不同情况下导致了不同的优势和缺点。对于生产环境，监视工具的稳定性和工具的费用是更重要的考虑因素。，在内核热路径中使用桩和内核模块不是理想的选择：前者在某些情况下可能会对性能产生更大的影响。部署太棒了。
面对以上两个问题，是否有任何解决方案或技术手段？
为了应对内核模块的安全问题，EBPF绝对是Linux行业的最佳解决方案。它不仅是安全的，而且还提供了大量简单的库来改善编程体验。
热路径插入桩的性能问题可以在中断时间的及时采样和检查场景中解决。
根据先前的背景和应用程序方案分析，最初完成了技术选择。
如果系统支持Perf Hardware采样（HW）事件，请先使用EBPF启动内核批准计时器，计时器周期会中断，并且在中断处理函数中更新了徽标。确定时钟中断是否发生或按时延迟。
对于不支持Perf HW的系统，我们不能使用PERF HW事件。第二，我们还需要通过EBPF启动内核批准计时器。计时器中断函数将检查此计时器中断的时间是否与确定中断是否延迟的预期时间不同。
实际上，要达到上述功能，需要解决以下问题：
1. EBPF安装计时器
在先前的设计和分析中，我们了解到，使用EBPF启动大概时间的启动器来制作中断样本。不幸的是，ebry，Linux-5.15下方的EBPF的内核版本不支持计时器创建。穿过道路的道路，Perf_COUNT_SW_CPU_CLOCK事件中的事件是在Linux内核的底部通过较高的准则时钟实现的。我们需要实现EBPF计时器。
2. EBPF PROG处理功能与Perf HW/SW事件溢出回调功能有关
尽管Perf提供了Perf_ovent_open系统调用和IOCTL方法来创建Perf HW和Perf Perf SW事件采样（例如perf_count_sw_cpu_clock事件，以及perf硬件事件perf_count_cpu_cycles，它传统是传统的，但要查看更详细的信息）。触发这些事件后，我们希望在内核中进入内核。例如，我们需要执行控制检测的回调函数只能用于调用perf_event_create_counter_counter以注册回调函数，我们需要在PERV事件中实现Overflow_handler的目的。
但是，随着EBPF.Perf事件的出现，此困境已改变，为EBPF提供了特殊的IOCTL频道，以使其在内核中为EBPF执行其超级大国（别忘了EBPF代码在内核中实质上是执行的）。与用户态度的自然“亲和力”，因此用户状态可以非常方便地将回调处理的逻辑挂在ioctl事件中。在代码级别，使用：
来将EBPF PROG处理功能注册到Perf事件的Overflow_handler背部处理处理。
3.选择系统是否支持Perf HW事件的不同检查策略
称为perf_event_open系统的返回价值判断系统支持Perf HW事件。
同时，在EBPF中定义了两组PROG。如果支持Perf HW，则附件HW事件检测到的Progs，否则附件SW事件检测到的ProGS。
本章主要对工具的实现进行详细的分解。下图是工具操作的简单原理图：
整个过程如下：
1.首先执行参数分析，包括分析参数，例如阈值，运行时间，记录文件规范等。
2.初始化EBPF，此步骤主要是加载EBPF程序。
3.安装EBPF事件。首先创建完善事件，然后将EBPF Prog附件与PERF Event相关联，最后创建一个民意调查事件并进行监视。在同一时间，Perf Event开始工作。经过完善事件触发后，EBPF PROG程序将运行。EBPFPROG程序检测到阈值事件，并唤醒用户的情况到投票任务。
4.用户唤醒后，用户中度的民意调查结果到日志文件。
安装SYSAK后，使用以下命令：
-t：中断的近极限制，单元是MS。
-f：指定IRQOFF结果记录的文件。
持续时间：如果未指定默认值，该工具的运行时间将继续运行。
通过内核模块创建一个工人，以构建一个长时间的中断场景。以下是Irqoff显示的结果。
结果中有几个组成：
第一行是日志标头。总共5列，从左到右，时间戳（模块信息），Guanzhong的长CPU，剪切 - 长的当前线程ID和总关闭中断延迟。
第二行对应于日志标头的实际信息。
第三行和后来是中断的on -stite堆栈信息，可在下一步中促进源代码的分析。
原始链接
本文是阿里巴巴云的原始内容，未经许可就无法重印。
原始：https：//juejin.cn/post/7101880926803591199