测验：API、SDK 与埋点

根跨度持续时间为 3,204 毫秒，但两个子跨度的总和为 672 毫秒。下一步最合适的行动是什么？

• 提高采样率以收集更多痕迹
• 子跨度的持续时间测量不正确，因此请升级 SDK。
• 找到自拍时间 2,532ms 部分并添加手动跨度。
• 将根跨度拆分为多个段

部署Canary时，service.name被指定为checkout-api-canary。结果如何？

• 采样率加倍
• 在服务图中创建了单独的节点，扭曲了调用关系。
• 跟踪 ID 冲突
• 资源属性被忽略

我们将 OTEL_TRACES_SAMPLER 设置为traceidratio，并将 0.1 应用于所有服务。预计会出现什么问题？

• 仅存储总痕迹量的 10%，降低了成本
• 采样标志不会传播，因此所有跟踪都会被保存
• 每项发球均独立评审，痕迹中途切断。
• 仅保存根跨度，并丢弃子跨度。

当仅打开自动测量时，什么清楚地创建了跨度？

• 用于序列化响应 JSON 的部分
• 使用 HTTP 客户端调用另一个服务的部分
• 连接池中的等待时间
• 评估业务规则的循环

单个跨度增长到数百千字节的正确原因和响应是什么？

• 属性的数量没有上限——我们设置了数量上限。
• 属性值长度没有默认上限 — 指定值长度上限
• 批量大小较大 — 减少 send_batch_size
• 采样关闭——开启比率采样

在短批处理作业中，只有部分跨度到达后端。最可能的原因是什么？

• 当进程退出时，它会在不清除队列的情况下死亡。
• 采样器无法识别批处理作业
• 资源属性不足
• 迹线 ID 长度不足