菜单
文档面包屑箭头 Grafana Tempo面包屑箭头 管理面包屑箭头 配置 TraceQL 指标
开源 此页面内容适用于开源版本。

配置 TraceQL 指标

注意

TraceQL metrics 是一个实验性功能。不提供工程和待命支持。文档有限或仅在代码注释中提供。不提供 SLA。在 Grafana 中启用功能开关即可使用此功能。联系 Grafana Support 以在 Grafana Cloud 中启用此功能。

TraceQL 语言提供指标查询作为实验性功能。指标查询通过对跟踪查询结果应用函数来扩展跟踪查询。此强大功能可以从跟踪创建指标,这与 LogQL 指标查询从日志创建指标的方式非常相似。

有关可用查询的更多信息,请参阅TraceQL 指标查询

开始之前

要使用从跟踪生成的指标,您需要

  • metrics-generator 配置中将 local-blocks 处理器设置为 active
  • 在 Grafana 或 Grafana Cloud 中配置 Tempo 数据源
  • 访问 Grafana Cloud 或 Grafana 10.4 或更高版本

激活并配置 local-blocks 处理器

必须启用 local-blocks 处理器才能开始使用 { } | rate() 等指标查询。如果未启用,则指标查询将失败,并显示错误 localblocks processor not found。可以在每个租户或所有租户中启用 local-blocks 处理器。

要为所有用户激活 local-blocks 处理器,请将其添加到 Tempo 配置的 overrides 块中的处理器列表中。

yaml
# Global overrides configuration.
overrides:
  metrics_generator_processors: ['local-blocks']

要按租户配置处理器,请使用 metrics_generator_processor override。

按租户 overrides 中的每租户示例

yaml
  overrides:
    'tenantID':
      metrics_generator_processors:
        - local-blocks

默认情况下,主配置中的所有租户

yaml
overrides:
  defaults:
    metrics_generator:
      processors: [local-blocks]

添加此配置以对所有 Span(而不仅仅是服务器 Span)运行 TraceQL 指标查询

yaml
metrics_generator:
  processor:
    local_blocks:
      filter_server_spans: false

要在历史数据上运行指标查询,您必须将 local-blocks 处理器配置为将 RF1 块刷新到对象存储

yaml
metrics_generator:
  processor:
    local_blocks:
      flush_to_storage: true

flush_to_storage 设置为 true 可确保将指标块刷新到存储中,从而可以对历史数据运行 TraceQL 指标查询。

如果您使用 tempo-distributed Helm chart 配置了 Tempo,您也可以使用 values.yaml 文件设置 traces_storage。请参阅Helm chart 查看示例

有关 overrides 的更多信息,请参阅标准 overrides

评估查询超时

由于这些查询的开销较大,可能需要很长时间才能运行完成。因此,请考虑增加系统中各处的超时设置,以便为数据返回预留足够的时间。

增加超时时考虑以下方面

  • Grafana 前面的任何代理
  • 指向 Tempo 的 Grafana Prometheus 数据源
  • Tempo 配置
    • querier.search.query_timeout
    • server.http_server_read_timeout
    • server.http_server_write_timeout

设置 TraceQL 指标查询选项

query_frontend.metrics 配置块控制所有 TraceQL 指标查询。配置取决于环境。

注意

指标查询的默认最大时间范围为 3 小时,使用 query_frontend.metrics.max_duration 参数配置。

这与 TraceQL 默认的最大时间范围 168 小时(7 天)不同。

例如,在云环境中,由于后端规模的特性,可能需要并发度更高、但任务规模更小的作业。

yaml
query_frontend:
    metrics:
        concurrent_jobs: 1000
        target_bytes_per_job: 2.25e+08 # ~225MB
        interval: 30m0s

对于本地后端,您可以通过降低并发度,同时增加作业规模来提高查询时间。

yaml
query_frontend:
    metrics:
        concurrent_jobs: 8
        target_bytes_per_job: 1.25e+09 # ~1.25GB