Grafana Tempo Service Graph View 实战指南基于 Span 指标的服务拓扑监控与 RED 信号分析【免费下载链接】tempoGrafana Tempo is a high volume, minimal dependency distributed tracing backend.项目地址: https://gitcode.com/GitHub_Trending/tempo1/tempo本文是 Grafana Tempo 中Service graph view服务图视图的完整使用指南。该视图是 Grafana 为 Tempo 数据源预置的仪表盘式视图利用 metrics-generator 或 Grafana Alloy 从链路数据中生成的 span 指标与服务图指标直观展示各服务的请求速率、错误率、延迟即 RED 信号并可下钻到具体 trace。读完本文你将掌握服务图视图的启用前置条件、表格式 span 指标与节点式服务图的解读方法、底层 PromQL 查询原理以及基于标签过滤实现精细化下钻的完整操作流程。本文对应的原始文档位于 docs/sources/tempo/metrics-from-traces/service_graphs/service-graph-view.md并结合仓库中的服务图处理器源码modules/generator/processor/servicegraphs/与 span 指标处理器源码modules/generator/processor/spanmetrics/spanmetrics.go进行深度佐证。什么是 Service graph viewService graph view 是 Grafana 中基于metrics-generator或Grafana Alloy生成的指标来驱动的可视化视图。它并非直接查询 trace而是查询预先生成的指标因此可以发现持续报错的 span并掌握这些错误的出现频率纵览各服务之间 span 调用的整体速率确定服务中最慢查询p90 延迟的完成时间基于速率Rate、错误率Error Rate、耗时Duration三类 RED 信号定位并下钻到包含特定 span 的全部 trace。只要满足前置条件该视图是开箱即用的预配置视图无需额外编写仪表盘 JSON。服务图视图同时提供两类可视化span 指标表表格和服务图节点图并通过统一的过滤器定制展示的数据范围。需要说明本仓库 docs 中引用的是 Grafana 官方在线文档中的截图路径仓库本身不携带这些图片资源因此本文以文字和查询语句说明为主读者可以在自己的 Grafana 实例中对照查看。Requirements使用服务图视图的前置条件要在 Grafana 中使用服务图视图首先需要保证Tempo 后端已生成并落库 trace 对应的指标。具体而言需要满足Tempo 或 Grafana Cloud Traces启用并配置好 metrics-generator或启用并配置 Grafana Alloy使其将数据发送到 Prometheus 兼容的指标存储服务图Services graphs在 Grafana 中默认启用Grafana 9.0.4 之前需要 feature toggletempoServiceGraphSpan metricsspan 指标在 Tempo 数据源配置中启用。服务图视图所需的指标既可以由metrics-generator生成也可以由Grafana Alloy生成两种数据来源最终都汇入 Prometheus 兼容后端供 Grafana 查询。关于上述特性的完整配置方法可参阅 Tempo 数据源文档。从 metrics-generator 启用服务图指标在 Tempo 侧启用服务图的完整流程参见 Enable service graphs核心是在 metrics-generator 的 overrides 配置中启用service-graphs处理器overrides: defaults: metrics_generator: processors: - service-graphs而 span 指标服务图视图表格部分的数据来源则通过启用span-metrics处理器生成详见 Use the metrics-generator to create metrics from spans。在 Grafana 数据源中关联 PrometheusGrafana 侧需要把 Tempo 数据源与存放指标数据的 Prometheus 数据源关联起来通过serviceMap.datasourceUid指向 PrometheusapiVersion: 1 datasources: # Prometheus backend where metrics are sent - name: Prometheus type: prometheus uid: prometheus url: prometheus-url jsonData: httpMethod: GET version: 1 - name: Tempo type: tempo uid: tempo url: tempo-url jsonData: httpMethod: GET serviceMap: datasourceUid: prometheus version: 1通过 Grafana Alloy 生成服务图若选择由 Alloy 而非 Tempo 生成服务图可在 Alloy 配置中使用otelcol.connector.servicegraph组件。下面示例在生成服务图指标前将http.method与http.target两个 span 属性作为 Prometheus 标签附加到指标上随后把指标写入 Grafana OTLP 网关同时 trace span 也会被直接转发到 OTLP 网关otelcol.receiver.otlp default { grpc {} http {} output { traces [ otelcol.connector.servicegraph.default.input, otelcol.exporter.otlp.default.input, ] } } otelcol.connector.servicegraph default { dimensions [http.method, http.target] output { metrics [otelcol.exporter.otlp.default.input] } } otelcol.exporter.otlp default { client { endpoint env(OTLP_ENDPOINT) } }官方建议对于较大规模的部署优先使用 Tempo 内置的 metrics-generator 生成服务图效率更高。Service graph view 展示了什么进入服务图视图后表格的Name列会列出top 5 个 type 为 server 的 span。你可以通过过滤器进一步精炼数据也可以点击任何数据点查看更具体的信息表格中带下划线的条目均可点击点击后展示更详细的信息服务图节点图中的任意节点同样可点击点击后弹出更多数据选项。错误率下钻示例假设你想了解为什么cortex.Ingester的错误率最高。操作方式为在表格Error rate列的对应行第二行点击该数值右侧新窗口即会展示该 span 的详细指标信息。同时生成这些数据所用的PromQL 查询会出现在Metrics browser字段中方便你直接查看、复制甚至复用这条查询。这正是服务图视图“从可视化到查询语言”双向打通的设计界面上的每个数字背后都对应一条可审计的指标查询。Span metrics 表格详解服务图视图中的表格部分展示的是span metrics由 metrics-generator 或 Grafana Alloy 从已摄入的 trace 数据中生成其中就包括 RED 指标请求速率、错误率、耗时。在 Tempo 的 span 指标处理器实现中modules/generator/processor/spanmetrics/spanmetrics.gospan 指标对应以下三个核心指标名traces_spanmetrics_calls_total——计算请求数的countertraces_spanmetrics_latency——追踪所有请求耗时分布的histogramtraces_spanmetrics_size_total——追踪摄入 span 总大小的 counter可在配置中按需开启/关闭。其中请求计数与耗时直方图即服务图视图表格中 Rate / Error Rate / Duration 三列的数据来源。完整的 span 指标与计算方式说明见 Span metrics 文档。表格的七列与五个列标题span 指标表共7 列、5 个列标题点击列标题可按升序或降序排序列说明对应的 span PromQL 查询Namespan 名称。OTel 语义约定通常要求 span name 是 http 路由或数据库操作的**低基数low cardinality**标识。N/ARateLCD 仪表横向条形图。该 span 每秒的实例数。点击该字段可跳转到对应指标。sum(rate( traces_spanmetrics_calls_total{ span_name, filters }[$__range]))Error Rate数值 LCD 仪表横向条形图。点击该字段展示更详细的指标。sum(rate( traces_spanmetrics_calls_total{ span_name, span_statusSTATUS_CODE_ERROR, filters }[$__range]))Durationp90 耗时该 span 全部发生次数的 90% 在此时间内完成。点击该字段展示相应指标。histogram_quantile(.9, sum(rate( traces_spanmetrics_duration_seconds_bucket{ span_name, span_statusSTATUS_CODE_ERROR, filters }[$__range]) by (le))Links依据 span 名称与其他已应用的过滤器提供指向示例 trace 的链接。链接可跳转到同一 Tempo 数据源下同名 span 的搜索。N/A提示表格中的 Duration 查询在计算 p90 时同时限定了span_statusSTATUS_CODE_ERROR即默认展示的是错误请求的 p90 延迟。若需查看全部请求的延迟分布可去掉该标签约束并参考 Analyze service graph data 中的直方图查询写法。span 指标表的底层标签在 Tempo 的 span 指标处理器中modules/generator/processor/spanmetrics/config.go默认会为每条指标附加service、span_name、span_kind、status_code等标签其中span_name对应服务图视图表格中的 Name 列status_code取值为STATUS_CODE_UNSET/STATUS_CODE_OK/STATUS_CODE_ERROR这正是上表 Error Rate 查询中span_statusSTATUS_CODE_ERROR筛选条件的来源。status_message、job、instance等标签为可选需要额外配置enable_target_info/enable_instance_label才会出现。Service graphs节点图可视化服务图节点图是各服务之间相互关系的可视化表示它帮助你理解分布式系统的结构以及组件之间的连接与依赖。具体价值体现在推断分布式系统拓扑系统越复杂服务图越能帮助看清整体结构提供系统健康度的高层概览服务图展示错误率、延迟等关键数据提供系统拓扑的历史视图分布式系统变更频繁服务图可以反映拓扑随时间如何演化。服务图的布局支持默认default与网格grid两种。当使用 metrics-generator 时处理器会消费 trace 并生成时间序列形式的服务图指标例如traces_service_graph_request_total{clientapp, serverdb} 20每条序列带有client发起请求的服务与server接收请求的服务两个标签。服务图的完整工作原理与指标清单见 Service Graphs 文档。服务图指标是如何生成的在 servicegraphs 处理器 中处理器会检查 trace 并寻找具有父子关系、能代表一次请求的 span 对基于 OpenTelemetry 语义约定识别多种请求类型两个服务间的直接请求出站 span 的span.kind为client入站 span 为server跨消息系统的请求出站 span 的span.kind为producer入站 span 为consumer数据库请求span 同时带span.kindclient以及db.namespace、db.name、db.system、db.system.name中的任一属性可用database_name_attributes配置自定义。处理器会把能组成请求对的 span 保存在内存存储store中直到配对的 span 到达或超过最大等待时间wait默认 10 秒见 config.go。两种条件任一满足时处理器记录该请求并将其从本地存储移除。服务图处理器导出的完整指标清单包括指标类型说明traces_service_graph_request_totalCounter两个节点之间的总请求数traces_service_graph_request_failed_totalCounter两个节点之间的失败请求总数traces_service_graph_request_server_secondsHistogram从服务端视角看到的两个节点间请求耗时traces_service_graph_request_client_secondsHistogram从客户端视角看到的两个节点间请求耗时traces_service_graph_request_messaging_system_secondsHistogram默认关闭消息系统场景下生产者与消费者之间的耗时traces_service_graph_connection_infoGauge默认关闭服务到服务边的存在性信号每条活动边取值 1traces_service_graph_unpaired_spans_totalCounter未配对 span 的总数traces_service_graph_dropped_spans_totalCounter被丢弃 span 的总数connection_type标签的可能取值为未设置、virtual_node、messaging_system、database。处理器同时从客户端和服务端两侧测量耗时。此外由于服务图处理器必须处理一条边的两侧因此它需要处理 trace 的全部 span如果同一条 trace 的 span 分散在多个实例上处理器将无法可靠配对。虚拟节点Virtual nodes虚拟节点是 trace 生命周期的一部分、但没有采集到对应 span 的节点例如用户无法触达或未埋点的外部服务。处理器通过两种方式识别虚拟节点未埋点客户端缺少 client span根 span 的span.kind为server或consumer且没有匹配的 client span说明请求由外部未埋点系统发起如调度器、前端应用或使用curl的工程师。在 Tempo metrics-generator 中处理器会先在 server span 上检查配置的peer_attributes命中则以其值作为客户端节点名否则默认命名为user而在 Grafana Alloy / OTel Collector 的 servicegraph connector 中该场景下客户端节点名始终默认为user不可覆盖。未埋点服务端缺少 server spanclient span 没有匹配的 server span但存在 peer 属性说明客户端调用了不发送 span 的外部服务处理器以 peer 属性值作为虚拟服务端节点名。默认 peer 属性为peer.service、db.name、db.system、db.system.name按顺序搜索并取第一个命中的值。数据库节点的识别与命名也遵循明确规则当 span 带db.namespace、db.name、db.system、db.system.name任一属性时识别为数据库节点节点命名按peer.service→server.address→network.peer.address:network.peer.port→database_name_attributes中首个命中的属性依优先级取用。使用过滤器揭示细节服务图视图由一组固定fixed的指标查询驱动这些底层查询无法修改但你可以通过过滤来选择哪些 trace 参与指标计算从而定制视图内容。探索数据有两种方式点击可选项或使用过滤器。点击表格条目或图节点查看详情表格中Rate、Error Rate、Duration (p90)、Links四列均可点击点击后展示该 span 的指标详情服务图中可以查看任意节点的请求速率、请求直方图、失败请求速率与 traces。选中节点后从弹出菜单中选择对应选项即可。关于服务图Node graph 面板的导航细节可参考 Grafana 的 Node graph 面板文档。使用指标查询过滤屏幕顶部的过滤器可以基于span 属性键值对 / 标签收窄数据集。过滤器会构建一条查询从而精炼服务图与 span 指标中展示的内容并且支持添加一个或多个标签过滤器。操作步骤如下在 Service Graph 顶部点击Filter后的文本框显示可用标签列表为该标签选择或搜索一个值。示例中server标签的值等于tempo-ingester默认运算符为等于可选点击从下拉列表中选择其他运算符可选添加更多键值对来精炼数据集。后续添加的标签过滤器使用AND逻辑即多个键值对必须同时满足才算匹配点击Run query运行查询。要移除过滤器点击对应过滤器的下拉框并选择– remove filter –。每个字段/标签都表示一个键值对。例如第一个键值对以service为标签、值为Go-http-client第二个键值对以client为标签、值为02e807。如果指标查询过于具体可能不返回任何结果。此时把过滤器放宽到较不具体的条件即可返回结果——在官方示例中放宽后的结果只展示了span_name标签值为/base.Ruler/Rules的 span 指标数据而服务图部分没有可用数据因为该 span 没有对应的 client/server 边。进阶直接编写 PromQL 分析服务图指标服务图视图的界面查询本质上是 PromQL。如果你希望脱离预置视图、程序化地分析服务间连接关系可以直接对traces_service_graph_request_*系列指标编写查询。完整的查询集合见 Analyze service graph data这里摘录几类典型用法查看近 7 天每个 client/server 对的总调用量Instant Querysum(increase(traces_service_graph_request_server_seconds_count{}[7d])) by (server, client) 0只看某个服务作为服务端/客户端时的调用量sum(increase(traces_service_graph_request_server_seconds_count{serverfoo}[7d])) by (client) 0 sum(increase(traces_service_graph_request_server_seconds_count{clientfoo}[7d])) by (server) 0计算一段时间内的调用速率Range Query使用 5m 窗口获得更灵敏的曲线sum(rate(traces_service_graph_request_server_seconds_count{serverfoo}[5m])) by (client) 0 sum(rate(traces_service_graph_request_server_seconds_count{clientfoo}[5m])) by (server) 0计算服务间延迟分位数.9即 p90可替换为 p50/p95/p99histogram_quantile(.9, sum(rate(traces_service_graph_request_server_seconds_bucket{clientfoo}[5m])) by (server, le))消息系统中间件延迟需要启用traces_service_graph_request_messaging_system_seconds直方图histogram_quantile(.9, sum(rate(traces_service_graph_request_messaging_system_seconds_bucket{}[5m])) by (client, server, le))此外服务图指标支持按子处理器粒度裁剪service-graphs-request、service-graphs-latency、service-graphs-connection-info以及span_multiplier_key、database_name_attributes、filter_policies、dimensions、enable_virtual_node_label等配置项这些都定义在 servicegraphs/config.go 中完整 YAML 模式与默认值可参考 Enable service graphs 与 Service Graphs 索引文档。小结Service graph view 是 Grafana Tempo 链路监控体系中“从指标看拓扑、从拓扑回 trace”的关键入口它把 span 指标Rate / Error Rate / Duration与服务图指标client/server 边关系合并在一个预置视图中让你无需编写查询即可完成 RED 信号的监控与下钻同时视图背后全部是标准的 PromQL 查询既可通过界面过滤定制也可直接提取复用甚至可以在 Analyze service graph data 的指引下编写自定义查询构建属于你自己的服务依赖分析应用。使用前请务必确认metrics-generator或 Alloy已启用并生成指标、指标已写入 Prometheus 兼容后端、Grafana Tempo 数据源已通过serviceMap.datasourceUid关联 Prometheus——满足这三项服务图视图即可立即投入使用。【免费下载链接】tempoGrafana Tempo is a high volume, minimal dependency distributed tracing backend.项目地址: https://gitcode.com/GitHub_Trending/tempo1/tempo创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考