长时间运行的 traces
当 Tempo 接收到某个 trace 的 spans 后，出现延迟，然后 Tempo 又接收到该 trace 的额外 spans 时，就会产生长时间运行的 traces。如果 spans 之间的延迟足够长，这些 spans 最终会存储在不同的块中，这可能会导致几种不一致的情况
使用 TraceQL 搜索时，持续时间信息仅与包含某个 trace 的块子集相关。这是因为 Tempo 只查询足够多的块来获取匹配 spans 的 TraceID。执行 TraceID 查找时，Tempo 会在所有匹配的块中搜索 trace 的所有部分，这在结合后会获得更高的准确性。
使用
spanset运算符时，Tempo 只评估当前块中连续的 trace。这意味着对于单个块，条件可能评估为 false，但考虑所有块中的 trace 的所有部分则会评估为 true。
您可以调整 ingester.trace_idle_period 配置，以更好地控制 traces 何时写入块。将此值延长到默认的 10s 以上可以让长时间运行的 trace 共存于同一块中，但这需要考虑 ingesters 的内存消耗等其他因素。当前此设置不是按租户进行的，因此调整会影响所有 ingester 实例。
Tempo 从多个组件发布 tempo_warnings_total 指标，这有助于了解何时出现此情况。特别是，以下查询可用于了解刷新到 WAL 的 traces 中有多少百分比是相互连接的。
1 - sum(rate(tempo_warnings_total{reason="disconnected_trace_flushed_to_wal"}[5m])) / sum(rate(tempo_ingester_traces_created_total{}[5m]))如果您的 traces 运行时间较长，您可能也对 rootless_trace_flushed_to_wal 原因感兴趣，以便了解 trace 何时在没有根 trace 的情况下刷新到 WAL。
您可以使用此查询中的 reason 字段进行发现
sum(rate(tempo_warnings_total{}[5m])) by (reason)一般来说，当 trace 的所有部分都存储在尽可能少的块中时，Tempo 的性能最佳。现实中有各种各样的 tracing 模式，因此不可能针对所有模式进行优化。
虽然上述信息有助于确定 Tempo 的行为，但可能值得稍微修改一下使用模式。例如，您可能希望使用 span 链接，以便将 traces 分割开来，允许一个 trace 完成，同时指向因果链中的下一个 trace。这使得两个 traces 都能在较短的时间内完成，并增加了最终存储在同一块中的机会。
