中间件该不该「自带仪表」：可观测性默认开启还是让用户自己接？

背景 最近几次给业务方交付自研中间件（MQ 客户端、缓存 SDK、RPC 框架），被追问最多、也最容易「各说各对」的，不是功能，而是可观测性：这个组件「装上去之后」到底能不能被看见。

打个比方：中间件就像一台新装进机房的水泵。有人主张出厂就该配好流量计、压力表、漏损报警，插上电就能看；也有人主张出厂只给裸泵，表要不要装、装哪块、精度多高，全交给用泵的人自己配。两种我都见过了，而且两边都踩过坑。

几种常见做法（分歧点）

1. 零配置全开：metrics（QPS/延迟/错误率）、结构化日志、trace 上下文透传，默认全打开，业务方不用配一行就有数。
2. 全默认关、按需开：默认零开销，要观测谁谁自己接，避免给不想用的人添负担。
3. 分级默认：轻量指标默认开（几乎无成本），重量级（trace、慢调用明细、逐请求日志）默认关、按需开。
4. 只提供 hook，不给默认：暴露埋点扩展点，但完全不管默认形态，「你爱怎么观测怎么观测」。

我的倾向与理由 我偏 3（分级默认），核心就一条：「看不见」是最贵的一种故障。指标默认全关，等出事时用户才发现「哦原来这块没接埋点」，这时再补，往往连历史数据都没有，复盘只能靠猜。所以「低成本、高价值」的指标（吞吐、延迟分位、错误码分布）我主张默认开、且要克制——别把基数撑爆（比如别把 user_id、order_id 塞进 label）。而 trace 和逐请求日志这类「贵」的，默认关、留清晰的开关，避免给所有人强制背上开销。一句话：默认给够「救命」的最小集，把「锦上添花」的留成选项。

想听大家怎么选（几个具体场景）

• 你的组件是内部工具还是对外发布的 SDK？这两种场景下默认形态会不会不一样？
• 你踩没踩过「指标默认全关 → 出事后才发现没数据」或「默认全开 → 把监控系统基数/成本撑爆」的坑？
• trace 上下文透传，你倾向默认关还是默认开？怎么决定？
• 「该给多少」的边界，你们团队是拍脑袋还是有明确准则？

欢迎把你的默认值清单和踩坑贴出来，咱们对着聊。