从LinuxeBPF世界回顾DTrace的一些想法

作为在OmniOS上大量使用本地编写的DTrace脚本并从现今的文件服务器的 OmniOS迁移到Linux 的人，我自然而然地关注Linux的eBPF工具的增长，并引起了极大的兴趣(有些失望，因为他们仍在进行中)。这使我对Solaris上的DTrace体验以及然后在OmniOS上的Linux与eBPF体验形成对比。


在Linux上，eBPF及其周围的工具比我认为的DTrace更粗糙，更原始，而且肯定比我积极使用的任何版本的DTrace都要粗糙。到我开始使用它时，DTrace基本上已经在Solaris上完全成熟，因此在我的DTrace经验开始和结束之间几乎没有什么变化(我认为DTrace仍在处理IP地址，但没有重大变化)。但是与此同时，Linux作为一个整体如何开发eBPF及其周围的工具，使Linux eBPF成为DTrace从未有过的具有多个接口(和接口级别)的开放系统，这使得我至少从未见过有人在Solaris和Illumos上做过。
在DTrace世界中，几乎每个人都应该用来处理DTrace的接口是dtrace命令及其语言(DTrace库在其手册页中明确标记为不稳定和私有)。你可能以各种方式运行命令并通过模板或其他方式为其生成程序，但这就是你与事物进行交互的方式。如果记录了其他级别的接口(例如，您自己构建原始DTrace程序并将其馈入内核)，则绝对不推荐使用它们，因此，我从不对它们做太多事情。


(人们肯定使用DTrace系统构建了一些工具，这些工具不会产生来自的处理后的文本dtrace，但是显然，这些是来自专门的工程师团队的产品级工作，而不是为小规模产品生产的东西。通常它们来自Sun或Illumos发行提供商，因此有权使用私有接口。)


相比之下，Linux eBPF生态在堆栈的各个级别创建了一套完整的工具。等效于 dtrace，但是你也可以在大量不同的编程环境中设置某些东西的eBPF工具，并使用它产生的信息进行很多操作。这导致了非常灵活的事情，例如Cloudflare eBPF Prometheus导出器 (使你可以针对可编写eBPF程序的任何内容显示Prometheus指标)。


我忍不住感到Linux eBPF生态已经从开发eBPF的零散和分离方式中受益匪浅。没有一个小组从上到下拥有整个堆栈，因此，涉及的多个小组都被默示地彼此提供或多或少的文档化或或多或少的稳定接口。这些接口的存在使其他人可以利用它们，在一个或另一个之上编写自己的工具，并重新设定其用途，例如 创建有用的Grafana仪表板(通过在此处评论)。DTrace的单一统一开发为我们提供了更完善的dtrace命令，并且早得多(并使它在支持DTrace想法的所有Solaris版本中均可使用)，仅此而已。