Cloud-Neutral 资讯雷达｜可观测系统与真相层 · DeepFlow
DeepFlow
是一款以 eBPF + 流量数据 为核心的可观测系统， 定位非常明确：从“系统内部真实发生了什么”出发，还原分布式系统的运行事实。与以 Metrics 为起点的传统可观测体系不同， DeepFlow 更关注网络、调用链与运行时行为本身，试图回答一个更底层的问题：
当系统出现问题时，真实的数据流与调用路径到底发生了什么变化。
项目主要特性
- eBPF 驱动的数据采集 ：无侵入获取网络、进程、调用行为等运行时数据
- 流量即真相（Traffic as Truth）：从 L3–L7 流量中还原服务依赖、调用关系与性能特征
- 自动生成服务拓扑与调用链： 不依赖手工埋点，适合复杂与遗留系统
- 与 Kubernetes / 云原生环境深度适配： 感知 Pod、Service、Namespace 等运行时对象
- 可与 Metrics / Logs / Traces 体系并行使用： 不取代 Prometheus 或 Grafana，而是补充“事实层”
优缺点
| 优点 | 局限 |
|---|---|
| 特别适合排查复杂依赖问题 | 学习曲线偏陡 |
| 可自建 | 日志/指标能力偏弱，功能相对“鸡肋” |
| 无侵入，减少埋点与改造成本 | 对内核与 eBPF 依赖较高 |
| 从流量层还原真实系统行为 | 高吞吐场景下，环形缓冲队列存在丢包风险 |
| 擅长网络分析与系统级诊断 | 业务指标、应用日志依赖第三方系统 |
| 与 Prometheus / OTel 并行使用 | 不适合作为 BI 或报表系统 |
适用场景
| 适合 | 不适合 |
|---|---|
| 微服务 / Kubernetes 集群 | 作为唯一的可观测系统 |
| 网络分析、流量路径还原 | 替代常规监控体系（Metrics/Logs） |
| 系统依赖复杂、调用关系不清晰 | 只关心业务 KPI / SLA |
| 问题回溯、事后分析、根因定位 | 作为实时告警系统 |
| 多团队、多语言、难以统一埋点的系统 | 期望“开箱即用”的监控方案 |
DeepFlow vs OpenTelemetry
不是竞品，是分工，它们解决的问题不在同一层
-
OpenTelemetry（OTel）：是规范与数据通道（API/SDK/Collector/协议语义）。它让你“能发出一致的指标/日志/链路”。
-
DeepFlow：是eBPF 驱动的运行时事实采集与关联系统，更像“从流量与内核行为还原真相”。它擅长回答：请求怎么走、依赖怎么变、哪里慢、哪里丢。
OTel 的协议与生态是开放标准；DeepFlow 的核心采集与上报链路更偏“系统内闭环”——即使代码开源，协议/组件边界也未必鼓励你把 agent 拿出去单独做通用采集器。
工程判断
DeepFlow 试图成为“统一可观测平台”，但实际应该站在 “运行时真相层” 这一工程责任边界上：
当指标和日志已经不足以解释问题时，你需要回到流量与系统行为本身。
在 Cloud-Neutral 可观测体系中，它更适合的位置是：Prometheus 负责量化健康度， Grafana 负责可视化， 而 DeepFlow 负责还原网络请求的真实运行轨迹。
项目地址
- GitHub：https://github.com/deepflowio/deepflow
- 官网：https://deepflow.io
- 文档：https://docs.deepflow.io
如果说 Metrics 是系统的“体温计”，那 DeepFlow 更像是一台直接观察血液流动的医学影像设备。更多工程判断，见「云原生工坊 · 工程技术雷达」。
