版本 2.0 发布说明
Tempo 团队很高兴宣布 Tempo 的最新主要版本：2.0 版！
Tempo 2.0 的主要亮点是引入了 TraceQL。TraceQL 是一种基于 PromQL 和 LogQL 构建的查询语言，允许您交互式地从追踪数据中提取洞察。它提供了一种强大、灵活的方式来精确查找您需要回答关于系统问题的追踪，并根据其结构分析追踪。
秉承 Tempo 与 Grafana 紧密集成作为可视化层的传统，我们还在 Grafana 的 Tempo 数据源中添加了 TraceQL 查询编辑器。该编辑器可在 Grafana Cloud 和 Grafana 9.3.2 的开源用户中使用。我们鼓励开源用户在 Grafana 9.4 发布后尽快升级，以利用一些额外的增强功能和错误修复。
除了 TraceQL，Tempo 2.0 还将 Apache Parquet 块格式提升为新的默认存储格式。通过这一更改，Tempo 维护者表明此新格式已通过足够的测试，可供广泛采用。
这两项更改实际上是相辅相成的：如果没有 Apache Parquet 块格式带来的搜索速度提升，就无法实现 TraceQL 所支持的复杂查询。
注意：有关更改和增强功能的完整列表，请参阅 Tempo 2.0 变更日志。
功能和增强
下面重点介绍 Tempo 2.0 中一些最重要的功能和增强。
TraceQL，追踪查询语言
TraceQL 受 PromQL 和 LogQL 启发，是专为在 Tempo 中选择追踪而设计的查询语言。TraceQL 可以查找 Tempo 现有搜索难以甚至无法识别的追踪。它还可以帮助您理解事件序列的广泛上下文。要详细了解我们构建 TraceQL 的原因以及我们认为它能解锁的用例，请参阅我们的博客文章。
在此版本中，我们实现了 TraceQL 完整语言的子集。用户可以基于以下内容选择追踪：
- Span 和资源属性、时间以及持续时间
- 基本聚合：
count()和avg()
要了解更多关于 TraceQL 语法的知识，请参阅TraceQL 文档。有关我们计划如何扩展 TraceQL 语言的信息，请参阅未来工作。
您可以通过向 Tempo 的search API 端点的 q 参数发出 TraceQL 查询来运行它，或者对于与 Grafana 结合使用 Tempo 的用户，可以使用下面描述的 Grafana TraceQL 查询编辑器。
TraceQL 需要 Tempo 的 Parquet 列式格式，这是 Tempo 2.0 中的默认块格式。更多信息，请参阅 Tempo Apache Parquet 块格式文档。
Grafana 中的 TraceQL 查询编辑器
为了更轻松地运行和可视化 TraceQL 查询结果，我们在 Grafana 的 Tempo 数据源中添加了 TraceQL 查询编辑器。该编辑器可在 Grafana 的 Explore 界面中使用，始于 Grafana 9.3.2 版本。
查询编辑器通过提供自动完成功能帮助您学习 TraceQL。
更多信息，请参阅 TraceQL 查询编辑器文档。
Apache Parquet 块格式成为新默认格式
在 Tempo v1.5 中引入的实验性 Apache Parquet 列式块格式已提升为稳定版，并成为 Tempo 2.0 的默认追踪存储格式。我们很高兴切换到它，因为它为搜索提供了更高的速度和效率。
使用之前的块格式，我们注意到搜索追踪数据的能力上限约为每秒 40-50 GB。切换到 Parquet 后，在常见查询中，我们的搜索速度可达 300 GB/s，并且计算量更少。如果我们将处理的字节定义为扫描的追踪总字节数，那么此示例查询的结果约为 1.2 TB/s
{ resource.cluster ="foo" }而此查询的结果约为 550 GB/s
{ span.foo ="bar" }Parquet 块格式相对于我们之前格式的另一个优点是，用户现在可以利用现有的庞大 Parquet 工具和库生态系统来处理和转换他们的追踪数据。我们期待看到人们利用这一能力创造出什么样的下游应用程序。
Parquet 块格式可以作为 Tempo 现有块格式的直接替代品。无需数据转换或升级过程。启用 Parquet 格式后，Tempo 将开始以该格式写入数据，保留现有数据不变。
Tempo 搜索将返回来自旧格式和 Parquet 块格式的结果。然而，旧块格式的搜索已被标记为弃用，并将在 Tempo 2.1 中移除。
TraceQL 查询将只搜索存储在 Parquet 块中的追踪数据。更多信息，请参阅Parquet 文档。
注意：加载 Tempo 1.5 的实验性 Parquet 存储块时可能存在问题。您可能会在压实机中看到错误甚至崩溃。我们仅能在 1.5 和 2.0 之间的临时提交中重现此问题，但如果您遇到任何问题，请报告给我们，以便我们隔离并修复此问题。
搜索和 Metrics-generator 默认启用
在 Tempo 2.0 中，搜索和 metrics-generator 现已默认启用，并且其相应的配置参数（search_enabled 和 metrics_generator_enabled）已被移除。
我们对这两个功能的反馈感到兴奋，并且对其稳定性感到满意，因此我们希望所有 Tempo 新用户从第一天起就能使用它们。
虽然 metrics-generator 组件现在默认启用，但在设置某些租户特定的配置参数之前，不会生成实际指标。更多信息，请参阅 metrics-generator 配置文档。
注意：Grafana Cloud 客户需要联系 Grafana 支持以启用指标生成。
作为将 metrics-generator 提升为默认开启的一部分，我们对其进行了以下改进：
- metrics-generator 现在处理用户定义维度和默认维度之间的冲突。与默认维度冲突的用户定义维度将带有
__前缀。PR 1794 - metrics-generator 现在使固有维度可配置，并默认禁用
status_message。PR 1960。 - metrics-generator 现在计算一个指标，告诉您按团队、服务或其他相关标签细分的接收 Span 的大小（以字节为单位）。由于 Span 量大致与运营 Tempo 的成本相关，因此此指标有助于成本分摊和回计目的。PR 1662。
- 在聚合指标之前，较旧的 Span 现在会被过滤掉。这很有帮助，因为在指标计算中包含这些较旧的 Span 可能会导致误导性或不正确的结果。PR 1612。
- 超出可配置长度的标签名称和值将被截断。通过这种方式，Tempo metrics-generator 在将指标发送到接收时序数据库（通常有自己的最大标签长度限制）之前对其进行净化。PR 1897。
Ingester 的区域感知复制
区域感知是一种确保数据在故障域（我们称之为“区域”）之间复制以提供更高可靠性的功能。故障域可以由您自行定义，但通常可能是可用区、数据中心或服务器机架。
当为 Ingester 启用区域感知时，传入的追踪数据保证会被复制到不同区域的 Ingester。这使得系统能够承受一个或多个区域的丢失（取决于复制因子）。
感谢社区成员 manohar-koukuntla 的贡献！
# use the following fields in _config field of jsonnet config, to enable zone aware ingesters.
multi_zone_ingester_enabled: false,
multi_zone_ingester_migration_enabled: false,
multi_zone_ingester_replicas: 0,
multi_zone_ingester_max_unavailable: 25,升级注意事项
升级到 Tempo 2.0 时，请注意这些重大更改。
默认值更新
以下配置参数已更新为新的默认值。这些默认值已更改，以更好地与新的 Parquet 块格式配合使用。PR 1978
如果您仍然使用 v2 格式，您可能更喜欢旧值。
query_frontend:
max_oustanding_per_tenant: 2000
search:
concurrent_jobs: 1000
target_bytes_per_job: 104857600
max_duration: 168h
query_ingesters_until: 30m
trace_by_id:
query_shards: 50
querier:
max_concurrent_queries: 20
search:
prefer_self: 10
ingester:
concurrent_flushes: 4
max_block_duration: 30m
max_block_bytes: 524288000
storage:
trace:
pool:
max_workers: 400
queue_depth: 20000
search:
read_buffer_count: 32
read_buffer_size_bytes: 1048576已移除和重命名的配置参数
下表描述了已移除或重命名的参数。(PR#1978)
已移除
| 参数 | 说明 |
|---|---|
query_frontend: | 被 trace_by_id.query_shards 取代 |
querier: | 被两个不同的设置取代：search.query_timeout 和 trace_by_id.query_timeout |
ingester: | 已移除，并根据块格式自动确定 |
| 已移除。现在默认为 true。 |
| 已移除。现在默认为 true。 |
storage: | 已移除，并固定到 block.version |
已重命名
| 参数 | 说明 |
|---|---|
query_frontend: | 重命名为 query_frontend.trace_by_id.query_shards |
querier: | 重命名为 querier.trace_by_id.query_timeout |
以下 compactor 配置参数已重命名。
| 参数 | 说明 |
|---|---|
compaction: | 重命名为 v2_in_buffer_bytes |
compaction: | 重命名为 v2_out_buffer_bytes |
compaction: | 重命名为 v2_prefetch_traces_count |
以下 storage 配置参数已重命名。
| 参数 | 说明 |
|---|---|
wal: | 重命名为 v2_encoding |
block: | 重命名为 v2_index_downsample_bytes |
block: | 重命名为 v2_index_page_size_bytes |
block: | 重命名为 v2_encoding |
block: | 重命名为 parquet_row_group_size_bytes |
其他升级注意事项
PR 1879。Azure Storage 配置现在使用蛇形命名法，带有下划线（_），而不是连字符（-）。在 Azure Storage 配置上使用蛇形命名法。以下是 Azure Storage 配置使用蛇形命名法的示例
# config.yaml
storage:
trace:
azure:
storage_account_name:
storage_account_key:
container_name:PR 1678。Parquet 是新的默认块版本。要继续使用 v2 块格式，请参阅Parquet 配置文档。
PR 1810。我们已从 mixin 中删除了 TempoRequestErrors 警报。依赖此警报的任何 Jsonnet 用户应将其复制到自己的环境中。
PR 1754。我们已向 vulture 添加了 TLS 支持。内部类型已更新为使用 scope 而不是 instrumentation_library。如果请求 JSON，则这是“按 ID 追踪”类型查询中的一个重大更改。
错误修复
2.0.1
增强
错误修复
- PR 2058 在禁用指标生成器时，抑制单二进制模式下的日志垃圾信息。
- PR 2055 在读取 1.5 和 2.0 之间的临时提交写入的一些块时，更优雅地处理错误。
- PR 2095 合并 Parquet 追踪时，正确合并追踪级别数据。
- PR 2114 在 AWS Lambda 中解除查询参数转义，以使 TraceQL 查询工作。
2.0 错误修复
版本 2.0 包含以下修复：
- PR 1887 在 OTel 接收器发生致命错误时停止 Distributor。
- PR 1700 新的 WAL 文件分隔符
+用于 NTFS 文件系统，并向后兼容旧分隔符:。 - PR 1697 按 ID 查找追踪时遵循缓存和缓冲设置。
- PR 1723 正确地将错误从迭代器层向上层 Querier 传播。
- PR 1781 使多租户与 HTTP 配合工作。
- PR 1799 修复 Parquet 搜索中
http.status_code的错误，该错误可能导致返回不正确的结果。 - PR 1813 修复启动后
SearchTagValues端点失败的问题。 - PR 1913 tempo-mixin：调整仪表盘以支持不存在集群标签的指标。
- PR 1920 修复 docker-compose 示例无法在 Apple M1 硬件上运行的问题。
- PR 1939 修复 TraceQL 对大多数二进制操作的解析，使其不再需要空格。
- PR 1947 不要在 Ingester 中持久化没有块的租户。
- PR 1948 TraceQL：Span 范围无法与范围查询一起工作。
- PR 1997 TraceQL：跳过实时追踪搜索。
- PR 2003 通过合并部分追踪来返回更一致的搜索结果。
