VP of DeepFlow here. Thank you for your interest in DeepFlow!
Yes, we have implemented distributed tracing using eBPF. In simple terms, we use thread-id, coroutine-id, and tcp-seq to automatically correlate all spans. Most importantly, we use eBPF to calculate a syscall-trace-id (without the need to propagate it between upstream and downstream), enabling automatic correlation of a service's ingress and egress requests. For more details, you can refer to our paper presented at SIGCOMM'23: https://dl.acm.org/doi/10.1145/3603269.3604823.
would it be reasonable to assume that because this entirely network-based, it would work best with systems which really emphasize the "micro" in microservices?
how well does this work if, say, my system has a legacy monolith in addition to microservices?
The advantage of eBPF lies in *request granularity* (i.e. PRC, API, SQL, etc ...) distributed tracing. To trace the internal functions of an application, instrumentation is still required for coverage. Therefore, the finer the service decomposition, the more effective eBPF's distributed tracing becomes.
Yes, we have implemented distributed tracing using eBPF. In simple terms, we use thread-id, coroutine-id, and tcp-seq to automatically correlate all spans. Most importantly, we use eBPF to calculate a syscall-trace-id (without the need to propagate it between upstream and downstream), enabling automatic correlation of a service's ingress and egress requests. For more details, you can refer to our paper presented at SIGCOMM'23: https://dl.acm.org/doi/10.1145/3603269.3604823.
Of course, this kind of Zero Code distributed tracing currently has some limitations. For specific details, please see: https://deepflow.io/docs/features/distributed-tracing/auto-t...
These limitations are not entirely insurmountable. We are actively working on resolving them and continually making breakthroughs.