可观测性数据采集原理：Agent、采样、Sidecar 模式归纳总结
聊到数据采集，很多人第一反应是“装个 Agent 不就完事了？”其实没那么简单。尤其是在加密链路里，流量被层层封装，签名、密钥交换、加密隧道……你要是不把采集点放对位置，收上来的全是噪声。我自己这几年踩过的坑，几乎都出在“采集”这一步。所以这一章，我把 Agent、采样、Sidecar 这三种模式拆开揉碎讲清楚。你想想看，弄懂了它们各自的脾气，才能搭出真正可靠的观测管道。
1. Agent 模式 – 轻量级数据采集
Agent 模式是最常见的做法，说白了就是在每台机器或每个容器里跑一个常驻进程，负责读日志、抓指标、收链路。我习惯把它叫做“搬运工”——不管你上面跑的是什么业务，Agent 只管从本地的文件、socket、proc 里拿数据，然后发给后端。
优点： 对业务代码零侵入，运维也可以完全控制采集节奏。我在项目中遇到过最极端的例子：生产环境不允许改容器镜像，但又要快速加监控。Agent 外挂模式两天就上线了。
缺点： 数据先落盘再采集，延迟高；采集点在应用外部，拿不到进程内部的上下文细节（比如内存里的 trace ID）。加密链路里，Agent 能看到报文大小、频率，但解密后的 payload 内容它碰不到。
所以我的建议是：Agent 模式适合做“粗粒度”的指标和日志，不适合做全链路的分布式追踪。除非你在 Agent 里嵌入了 eBPF，那又是另一套玩法了。
2. 采样 – 用精度换开销
全量采集在加密链路里基本行不通。数据量太大，网络、存储、计算都会爆炸。采样的核心思想很简单：只保留一部分可代表全貌的数据。
常见的采样策略有四种：
| 策略 | 工作原理 | 典型场景 |
|---|---|---|
| 固定率采样 | 每 N 条取 1 条，比如 10% | 对延迟不敏感，成本优先 |
| 自适应采样 | 根据吞吐量动态调整比率 | 流量波动大的系统 |
| 头采样 | 请求入口处就决定是否跟踪 | 需要保证低概率错误能捕获 |
| 尾采样 | 请求结束后根据结果（如错误、慢）决定是否保留 | 高价值链路分析 |
我曾经犯过一个错误：在加密网关里用固定率采样，结果所有出错的请求都集中在低风险用户上，运维团队复盘时完全找不到规律。后来改了尾采样 + 错误率触发条件，才真正把问题暴露出来。
3. Sidecar 模式 – 与业务解耦
Sidecar 模式在云原生里已经是标配。它不是独立进程，而是作为一个独立的容器和业务容器共享一个 Pod。换句话说，业务的网络流量先经过 Sidecar，Sidecar 再转发到业务进程。这样一来，采集、限流、TLS 卸载都可以在 Sidecar 里完成。
我最早接触 Sidecar 是在 Istio 的 Envoy 里，后来自己用 Go 写了一个轻量的加密流量观测 Sidecar。体会最深的是：解耦得彻底，但复杂度也高。
优点：
- 采集逻辑和业务代码完全分离，更新 Sidecar 不用改业务镜像。
- 可以拿到网络层的原始流量（包括加密握手阶段的数据包），适合做 SSL/TLS 指标分析。
- Sidecar 能注入自定义的 trace header，实现全链路透传。
缺点：
- 每次请求多经过一层代理，延迟增加 1-5ms（加密链路里更明显）。
- 管理 Sidecar 的版本、配置、资源消耗本身就是运维痛点。
- Sidecar 本身也可能出错，需要单独的可观测性——哦，这就套娃了。
4. 模式对比与选型建议
三种模式并不是互斥的。实际项目中，我经常混合使用：Agent 收基础指标，尾采样收高价值 trace，Sidecar 做加密流量中继和额外标注入。你把它们放在一起对比，选型思路就清晰了。
上面这张图从左到右展示了三种模式的典型拓扑。你可以看到：Agent 和应用是平级关系，Sidecar 在流量路径中间，采样则是一个独立决策节点。我在项目里会用类似的分层设计——底层 Agent 收基础指标，中间 Sidecar 做加密流量上下文注入，最后采样按需裁切数据量。
5. 选型核心原则
- 加密链路优先考虑 Sidecar：因为解密、签名验证等操作需要与请求同步，Sidecar 能拿到完整报文。
- 采样策略必须端到端一致：否则 trace 分裂，根本汇聚不起来。
- Agent 适合批量日志和指标：别用它做链路追踪，尤其是跨服务场景。
- 不要迷信全量：加密链路的数据量放大倍数很高，采样不是选项，是必选项。
嗯，关于数据采集这部分，核心就这些。Agent、采样、Sidecar 三者的组合，占了我过去三年 80% 的可观测性架构设计。每次做新链路加密项目，我都是先从这三点画草图，然后再往里填细节。希望对你也一样管用。