所有请求都保存完整链路，成本可能很高；采样比例过低，又可能难以找到偶发故障。采样设计需要说明排查目标、流量规模和数据管道能力，而不是直接复制一个固定比例。
先确定哪些问题需要证据
高流量普通查询、低频关键交易和异常路径的重要性不同。根据业务影响设计保留策略，并明确不能观察到的范围。没有找到某条链路，不应被当成请求没有发生的证明。
理解采样发生的位置
头部采样在较早阶段决定是否保留，尾部采样可利用更多完成后的信息，但需要缓存、路由与容量设计。采用哪种方式，应结合现有采集架构和故障排查需求判断。
多服务策略需要协调
如果各服务独立丢弃数据，跨服务链路可能不完整。检查上下文传播、采样决策与导出配置，明确哪些组件会过滤哪些数据。采样规则变更也应保留版本与时间。
验收可见范围与资源消耗
在测试负载下制造慢请求和错误，检查目标证据是否保留，同时观察 Collector、网络和存储压力。最终方案应说明收益、盲区和超出容量时的行为。
常见问题：是否只保存错误链路就够了？
正常请求提供对照和分布信息，完全没有正常样本可能妨碍分析。应根据排查目标保留合理证据。
技术参考：OpenTelemetry：采样。具体接口与配置请结合使用版本核对。
将评估落实到你的系统
如果你的 .NET 应用还缺少可重复的部署、观察或恢复流程，可以通过容器化与自动化交付服务梳理现状，约定实施内容、演练场景与运维交接方式。