测验：采样与运营
我们希望在 1% 头部采样的环境中每小时调查 5 个错误。保留了哪些错误痕迹？
- 每小时 5 次（始终保留错误）
- 每小时约0.5箱
- 无论采样如何，错误都存储在单独的路径中。
- 每小时大约 0.05 个病例 — 平均等待 20 小时才能看到 1 个病例
引入尾部抽样不会降低哪些成本？
- 后端产生的存储成本
- 后端索引成本
- 从代理到收集器的网络传输量
- 后端查找的查询成本
为什么 tail_sampling 不应该在部署为 DaemonSet 的收集器中使用？
- 因为DaemonSet内存限制较低
- 因为DaemonSet不支持处理器
- 这是因为一条踪迹的跨度分布在多个节点的代理上，每个节点只能看到其中的一部分并做出决定。
- 因为它是冗余存储的，有多个节点
在将网关收集器的数量增加到3个的同时，我们在前面放置了一个通用的循环负载均衡器。预期的症状是什么？
- 同一跟踪的跨度分散在多个实例中，导致跟踪被随机截断。
- 负载均衡并减少内存使用。
- Decision_wait增加3倍
- 抽样政策适用3次
在峰值流量为 10,000 Trace/s、decision_wait 为 30s 的环境中，num_traces 设置为 50,000。结果如何？
- 节省内存，运行稳定
- 超过上限的旧迹线将被强制判断，并存储不完整的结果。
- Decision_wait自动减少
- 过多溢出到磁盘
我们希望从 tail_sampling 策略中排除健康检查路由。正确的方法是什么？
- 根本没有政策
- 在 string_attribute 策略中开启 invert_match 仅保留不对应的路由
- 将概率策略的比率设置为 0
- 将过滤处理器放在tail_sampling之后