什么是RPC追踪
分布式追踪定义
Google Dapper早在10年前就提出了针对RPC调用环境的分布式追踪方法，它是APM工具或Zipkin的基础。APM工具几乎都使用类似的逻辑来进行分布式追踪。因此，它是微服务环境的流行概念，每个人都需要它。
RPC追踪背景
在中国的银行系统和电信系统中，关键业务系统都是由供应商提供的，供应商已经为客户提供了很长时间的服务。供应商不喜欢APM工具，因为APM工具会为了分布式追踪自动编写代码，而供应商要对关键业务系统的稳定性负责。他们不能冒任何风险，但是APM工具在理论上修改了没有经过充分测试的代码。所以在中国，即使是世界领先的APM供应商也不能把他们的产品卖给很多银行或电信公司。
在中国，银行和电信公司确实需要分布式追踪，但他们的供应商讨厌APM。因此，对于大公司来说，他们手动进行检测，并且严重依赖日志进行分布式追踪。大公司投入了大量的资金手动测试并确保所有的代码都经过了测试。然而，小公司无法支付这么高的价格来手动检测和验证所有的应用程序。他们在他们的产品环境中找到了一个替代分布式追踪的解决方案，这个方案不像大公司那么复杂，但这个解决方案对他们来说很有效。这个解决方案是分析所有的网络数据包，以获得仅带有RPC调用延迟的service-map。我们受到了他们的解决方案的启发，并想知道为什么它有效。最后，我们找出原因，因为在大多数情况下，如果发生了一些问题，这个问题将影响两个endpoint之间的所有RPC调用。因此，从service-map的角度来看，将会有一条表示一个进程到另一个进程的调用出问题。
Kindling RPC追踪是什么？
场景：当用户访问应用程序时，应用程序代码将请求内核以接受传入的网络请求，并接收所有的网络字节。之后，应用程序代码将执行一些业务逻辑，或调用其他服务，或要求内核读取一些文件或将一些日志数据写入文件。处理完成后，应用程序代码将请求内核通过网络将响应发送回用户。
RPC调用处理的详细信息
从上面的描述来看，应用程序代码将与内核一起工作来处理用户请求，但在传统环境中，内核侧被认为是静态和稳定的。在云原生环境中，所有的基础设施层都严重依赖于内核，并且会不断发展，所以传统的跟踪应用代码行为的方法是不够的。例如，如果pod从一个k8s节点迁移到另一个k8s节点，则需要相应地修改iptables规则和路由表，因此如果此项工作不正确，则调用可能会失败。
eBPF可以用来跟踪内核行为，因此我们发现它对于跟踪内核行为和关联每个RPC调用的所有信息是很有帮助的。我们将每个RPC调用命名为"RPC trace"(RPC追踪)。
对于前面提到的场景，使用Kindling RPC trace，我们希望我们可以为每个RPC调用回答以下问题:
- 请求已经发送了多少字节？以及需要多长时间？
- 在请求处理过程中，对于用户请求，哪个文件已经被打开进行写或读？需要多长时间？以及读取或写入了多少字节？
- 在请求处理过程中，对于用户请求，是否有任何出站请求被发送？发送了多少字节？需要多长时间？需要多长时间才能得到响应?
- 有多少字节作为响应发送给用户？需要多长时间？
- 如果进程在请求处理过程中等待一个互斥信号，它需要多长时间?
基本上，使用Kindling RPC追踪，我们想要回答的问题是内核是如何与应用程序代码一起工作，从而完成用户请求的。
扩展阅读（下面的论文提到了这个理论）：
分布式追踪和RPC追踪
RPC追踪是针对特定RPC调用的分布式追踪的一部分。它不能替代APM工具，而应该与APM工具协同工作来为基础架构层提供详细的内核行为描述。如果请求头已经填充了Span信息，Kindling可以使用该信息提供详细的APM概览的链接，该概览用于应用程序代码判断。但如果您不相信任何自动检测机制，或者您负担不起手动检测的成本，您的产品环境也没有大公司那么复杂。您可以只用Kindling的service-map和RPC追踪来确定进一步挖掘的方向。