如何追踪两个Docker容器间的RPC调用？

当然有可行方案，核心是绕开应用层插桩，从容器网络流量或内核层入手实现透明追踪，下面是几个靠谱的实践方向：

方案1：Docker网络插件+流量分析工具联动 #

• 选用支持流量镜像的Docker网络插件（比如Calico、Weave），将容器间的流量镜像至专门的分析容器；
• 在分析容器中部署协议解析工具，针对目标RPC协议做解码：
  • 若使用gRPC，可通过tshark配合自定义Lua脚本解析HTTP/2帧中的gRPC调用信息，比如方法名、请求ID；
  • 若使用Dubbo这类自定义协议，可先用tcpdump抓包，再通过Dubbo协议解析工具提取关键调用字段；
• 将解析出的RPC调用信息，与容器ID、名称、IP等元数据关联，生成完整的追踪链路。

方案2：基于eBPF的高效透明追踪 #

eBPF是内核层技术，无需修改应用或容器配置即可捕获网络调用：

• 编写轻量eBPF程序，拦截容器的socket系统调用，记录连接建立、数据收发事件；
• 搭配协议解析逻辑，从流量中提取RPC关键标识（如请求ID、调用方法名）；
• 通过Docker API或cgroup信息，将事件与源/目标容器的元数据关联，生成追踪数据后上报至监控系统；
• 不想自行开发的话，可直接使用Pixie这类开源项目，它已针对容器环境做了无插桩RPC追踪优化。

方案3：容器日志+网络流量关联（局限性较强） #

如果你的RPC框架会将调用日志输出到容器stdout，可尝试这种方式：

• 收集容器标准输出日志，从中提取RPC调用的请求ID、时间戳；
• 同时追踪容器间的网络连接记录，根据时间戳、源/目标IP将日志与网络事件匹配；
• 该方式依赖RPC框架的日志格式，通用性不如前两种，适合特定场景应急使用。

注意事项 #

• 协议兼容性：不同RPC协议的解析难度不同，基于HTTP/2的gRPC比自定义二进制协议更易解析；
• 性能开销：流量镜像或eBPF拦截会带来少量性能损耗，可根据业务场景调整采样率；
• 元数据关联：需确保能准确获取容器ID、名称等信息，Docker API或cgroup均可实现。

内容的提问来源于stack exchange，提问作者MissSirius