Grafana Tempo 可观测性指南四大支柱、Trace 关联机制与落地实践【免费下载链接】tempoGrafana Tempo is a high volume, minimal dependency distributed tracing backend.项目地址: https://gitcode.com/GitHub_Trending/tempo1/tempo可观测性Observability由指标Metrics、日志Logs、追踪Traces与性能剖析Profiles四大支柱构成本指南以 Grafana Tempo 文档库中的《Traces and telemetry》为骨架系统讲解四大信号各自的定位与相互关系并深入 Tempo 仓库源码与配套文档给出从指标跳转 Trace、从日志跳转 Trace 及反向关联的完整实践方案。读完本文你将掌握四大支柱的协同原理理解 Tempo 如何在自我追踪、指标生成Exemplar与自动日志记录等场景中打通信号间的关联并能据此搭建自己的可观测性链路。可观测性的四大支柱各司其职的信号Metrics、logs、traces 和 profiles 构成了可观测性的四大支柱。它们各自从不同维度回答系统发生了什么这一问题而将这四类信号相互关联才能形成对应用与基础设施的整体视图。这也是理解 Tempo 这类分布式追踪后端在整个可观测性体系中所处位置的前提。指标Metrics量化系统状态的基石指标从宏观层面描述系统的状态是告警体系的基础原因在于指标是数值型数据可以与已知阈值直接比较告警规则可以在后台持续运行当数值超出预期范围时触发通知指标异常通常是第一信号是问题发现Discovery的起点。一句话概括指标告诉你有事情正在发生Metrics indicate that something is happening。例如请求速率突然飙升、错误率越过阈值都是通过指标最先感知的。日志Logs单进程活动的审计轨迹日志来自单一进程以原子事件的形式记录服务内部正在发生的事提供丰富的上下文信息指标是定量的numeric、结构化的日志是定性的textual、非结构化或半结构化的日志细节丰富但代价是显著更高的数据量higher data volumes日志告诉你应用正在发生什么whats happening to your application。在排障时日志能回答具体报了什么错、参数是什么但缺少跨组件的交互上下文。追踪Traces数据通路上的分步地图追踪在可观测性图景上更进一步它告诉你数据通路中每一步发生了什么相当于一张哪里出了问题的地图一个 trace 以图形化方式展示数据流中每个步骤耗时多少例如一次 HTTP 请求、一次数据库查询、一次第三方服务调用分别耗时多少它能展示请求从哪里发起、在哪里结束以及系统如何响应这种能力帮助你在从未预料到的地方定位问题区域并评估影响——没有追踪能力这些瓶颈往往难以发现。关于 trace 与 span 的基础模型可参考仓库中的 Trace structure 文档 与 Glossarytrace 由若干 span 组成span 是 trace 中的工作单元带起始时间、持续时长与操作名并可通过 parent 引用形成 span 树。性能剖析Profiles定位可优化代码行剖析帮助理解应用如何利用 CPU 时间、内存等计算资源进而定位具体的代码行或函数进行优化提升性能与效率。它是四大支柱中最微观的一类信号。为什么需要 Trace单靠指标与日志无法根治复杂问题指标自身不足以定位根因它只能告诉你出问题了无法告诉你为什么日志虽信息量大但缺乏复杂环境中各组件之间交互与依赖的上下文每一类信号在根因定位上都有独特优势要最大化可观测性战略的价值必须把它们关联起来correlate them。Trace 的独特能力在于展示服务之间的关系识别你的服务**上游upstream**有哪些服务——这有助于理解当你的服务出问题时哪些服务会受负面影响识别你的服务**下游downstream**有哪些服务——由于你的应用依赖这些下游服务它们的故障很可能正是你服务报错或延迟升高的根源例如你可以直接看到正在失败的数据库以及所有受影响的边缘端点。换句话说trace 是在微服务架构中把指标异常翻译成服务依赖关系的关键桥梁。从指标到 TraceExemplar 关联机制指标与 trace 的关联核心是Exemplar示例。借助 exemplar你可以从某个指标数据点直接跳到与之关联的 trace例如从某个百分位延迟异常直接打开对应的一次完整请求追踪。在 Tempo 中Exemplar 有两种典型来源1. metrics-generator 自动生成 ExemplarTempo 的 metrics-generator 组件在处理传入 span 时会基于 span 计算 RED 指标Rate 请求速率、Error 错误率、Duration 持续时长直方图并自动生成 exemplar从而支持指标 → trace的一键跳转。该能力在 Metrics from traces 文档中有明确说明。从源码看service graphs 处理器在观测直方图时会携带 trace ID在 servicegraphs.go 中处理器通过e.TraceID()取得当前 span 的 trace ID并在ObserveBorrowed(..., traceID, ...)时将 trace ID 写入指标观测这正是 exemplar 携带 trace 标识的实现路径。在配置层面你可以通过metrics_generator.processor.span_metrics.trace_id_label_name指定生成指标中保存 trace ID 的标签名默认值为traceID详见 configuration/_index.md该标签名必须是合法的 Prometheus 标签名校验逻辑位于 validation/fields.go。2. TraceQL 指标查询中的 ExemplarTempo 的 TraceQL 指标metrics queries为所有 range 查询提供 exemplar 能力你可以在 query-frontend 中通过参数query_frontend.metrics.max_exemplars配置默认100设置为0表示禁用见 configuration/_index.md也可以在查询中直接加 hint{ span:name GET /:endpoint } | quantile_over_time(duration, .99) by (span.http.target) with (exemplarstrue)这样查询返回的时间序列上就会带上具体 trace 的引用点开数据点即可跳转到完整 trace。详细说明见 TraceQL metrics 文档。从 Trace 到日志、从日志到 Trace双向跳转除指标外trace 与日志之间同样需要双向关联从 trace 到日志查看某一次请求的 trace 时能看到沿途服务产生的日志条目从而补充 trace 之外的异常细节从日志到 trace在日志中发现可疑的 trace ID 后直接跳转到该 trace 查看完整调用链。在 Tempo 生态中实现日志 ↔ trace 关联最典型的手段是Grafana Alloy 的自动日志记录Automatic logging。其原理与配置在 automatic-logging.md 中有完整说明自动日志记录通过otelcol.connector.spanlogs连接器从 trace span 生成日志行每个 span/root/process 生成一条logfmt风格的日志包含svc服务名、spanspan 名、durspan 时长纳秒、tidtrace ID、status显式状态等默认键该连接器不会转发原始 trace因此必须同时把 trace 发送给 trace 后端如 Tempo避免丢数据生成的日志可写入 Loki配合 Grafana 的 Loki 数据源Derived fields配置匹配tid字段并指向 Tempo 数据源即可在日志界面点击跳转到对应 trace。例如下面的 Alloy 配置将 root span 记录为日志并发送到 OTLP 端点同时把 trace 转发给同一端点otelcol.receiver.otlp default { grpc {} http {} output { traces [ otelcol.connector.spanlogs.default.input, otelcol.exporter.otlp.default.input, ] } } otelcol.connector.spanlogs default { roots true output { logs [otelcol.exporter.otlp.default.input] } } otelcol.exporter.otlp default { client { endpoint env(OTLP_ENDPOINT) } }生成的 root span 日志行示例spanHTTP GET dur150200000ns http.methodGET http.target/api/v1/query svcmy-service tid7bba9f33312b3dbb8b2c2c62bb7abe2d也可以直接用 LogQL 查询自动日志例如筛选慢请求{tracesroot} | logfmt | dur 2s and svcmy-service值得说明的是Tempo 原生也提供等价的 TraceQL 搜索无需 Loki例如{ resource.service.name my-service span:duration 2s }即可实现同样的慢请求发现。让 Tempo 自己成为观测对象自追踪与元监控理解了四大支柱之后一个自然的延伸问题是追踪系统本身如何被观测Tempo 仓库提供了两个层面的实践Tempo 自追踪Self-tracingTempo 使用 OpenTelemetry SDK 对自身进行插桩可以通过环境变量导出自身产生的 trace详见 self-tracing.md。其底层初始化逻辑在 pkg/tracing/tracing.go 中实现InstallOTelOrJaegerFromEnv从OTel 或 Jaeger 环境变量初始化全局 tracer两者都未配置时为空操作no-op服务名默认为tempo-targettarget为-target标志的值可用OTEL_SERVICE_NAME或JAEGER_SERVICE_NAME覆盖且JAEGER_SERVICE_NAME优先见 tracing.go该函数由 cmd/tempo/main.go 在启动早期调用并传入config.SpanProfiling以决定是否启用 span profiling。关键环境变量包括类别环境变量说明OTelOTEL_EXPORTER_OTLP_ENDPOINTOTLP 端点 URL例如http://tempo:4318OTelOTEL_EXPORTER_OTLP_TRACES_ENDPOINT仅 traces 的端点覆盖上述端点OTelOTEL_TRACES_EXPORTERtraces 导出器默认otlp设为none时仅传播上下文不导出OTelOTEL_TRACES_SAMPLER/OTEL_TRACES_SAMPLER_ARG采样器与参数支持always_on、always_off、traceidratio、parentbased_*以及jaeger_remote等OTelOTEL_PROPAGATORS上下文传播器默认tracecontext、baggage、jaegerOTelOTEL_RESOURCE_ATTRIBUTES附加的自定义 resource 属性JaegerJAEGER_AGENT_HOST/JAEGER_ENDPOINTJaeger agent 主机 / collector 端点JaegerJAEGER_SAMPLER_TYPE/JAEGER_SAMPLER_PARAM采样类型const、probabilistic、remote与参数JaegerJAEGER_AGENT_PORTJaeger agent 端口默认6831JaegerJAEGER_TAGS以key1value1,key2value2格式附加 resource 属性仓库中的 tracing_test.go 对采样行为做了直接验证例如always_on采样所有 trace、always_off不采样、traceidratio按比例采样以及jaeger_remote/parentbased_jaeger_remote对initialSamplingRate的解析与非法参数缺少endpoint的报错校验。此外还支持强制采样单次请求在请求上设置Jaeger-Debug-IdHTTP 头Tempo 将无视采样配置强制采样该请求并把头值作为jaeger-debug-idspan 属性写入需激活jaeger传播器。Span profiling 则可通过配置span_profiling: true或--span-profiling标志开启为 span 附加 pprof goroutine 标签与pyroscope.profile.id属性将 trace span 与运行期间采集的 profile 关联起来——这正对应四大支柱中trace 与 profile 的关联。Tempo 元监控Metamonitoring若想完整观测 Tempo 自身的指标与日志可使用 set-up-monitoring.md 与共享文档 metamonitoring.md 描述的方案通过 Grafana Kubernetes Helm chartk8s-monitoring配置 Grafana Alloy 抓取 Tempo 的prom-metrics端口指标与 Pod 日志分别 remote-write 到 Prometheus/Mimir 与 Loki。其values.yml核心片段如下integrations: tempo: instances: - name: traces # instance 标签名 namespaces: - traces # 搜索 Tempo 实例的命名空间 metrics: enabled: true portName: prom-metrics logs: enabled: true labelSelectors: app.kubernetes.io/name: tempo destinations: - name: metrics type: prometheus url: url # 例如 https://prometheus host/api/prom/push - name: logs type: loki url: url # 例如 https://loki host/loki/api/v1/push之后可从仓库的operations/tempo-mixin-compiled目录导入 8 个监控 Dashboard如tempo-operational.json并使用mimirtool上传rules.yaml与alerts.yaml分别对应 recording rules 与告警规则实现指标 → 告警 → 日志 → trace的完整闭环监控。Mixin 源文件位于 operations/tempo-mixin编译产物位于 operations/tempo-mixin-compiled。总结让四类信号协同工作可观测性的价值不在于单个信号而在于关联信号回答的问题与其他信号的关联方式Metrics是否有事情发生Exemplar 跳转到 traceLogs具体发生了什么trace IDtid跳转到 trace反之 trace 可下钻日志Traces在哪一步、哪个服务出了问题关联上下游服务、关联指标与日志Profiles哪些代码需要优化通过 span profiling 与 trace span 关联Tempo 在整个体系中扮演 trace 的存储、检索与关联枢纽借助 metrics-generator 与 TraceQL 指标生成携带 exemplar 的指标、借助自动日志记录打通日志侧入口、借助自追踪让自身也被四类信号观测。在实际部署中建议结合 部署模式文档 与 架构文档 规划组件形态再按本文所述逐步配置信号关联最终形成指标发现问题 → trace 定位链路 → 日志补充细节 → profile 优化性能的完整排障工作流。【免费下载链接】tempoGrafana Tempo is a high volume, minimal dependency distributed tracing backend.项目地址: https://gitcode.com/GitHub_Trending/tempo1/tempo创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Grafana Tempo 可观测性指南：四大支柱、Trace 关联机制与落地实践
Grafana Tempo 可观测性指南四大支柱、Trace 关联机制与落地实践【免费下载链接】tempoGrafana Tempo is a high volume, minimal dependency distributed tracing backend.项目地址: https://gitcode.com/GitHub_Trending/tempo1/tempo可观测性Observability由指标Metrics、日志Logs、追踪Traces与性能剖析Profiles四大支柱构成本指南以 Grafana Tempo 文档库中的《Traces and telemetry》为骨架系统讲解四大信号各自的定位与相互关系并深入 Tempo 仓库源码与配套文档给出从指标跳转 Trace、从日志跳转 Trace 及反向关联的完整实践方案。读完本文你将掌握四大支柱的协同原理理解 Tempo 如何在自我追踪、指标生成Exemplar与自动日志记录等场景中打通信号间的关联并能据此搭建自己的可观测性链路。可观测性的四大支柱各司其职的信号Metrics、logs、traces 和 profiles 构成了可观测性的四大支柱。它们各自从不同维度回答系统发生了什么这一问题而将这四类信号相互关联才能形成对应用与基础设施的整体视图。这也是理解 Tempo 这类分布式追踪后端在整个可观测性体系中所处位置的前提。指标Metrics量化系统状态的基石指标从宏观层面描述系统的状态是告警体系的基础原因在于指标是数值型数据可以与已知阈值直接比较告警规则可以在后台持续运行当数值超出预期范围时触发通知指标异常通常是第一信号是问题发现Discovery的起点。一句话概括指标告诉你有事情正在发生Metrics indicate that something is happening。例如请求速率突然飙升、错误率越过阈值都是通过指标最先感知的。日志Logs单进程活动的审计轨迹日志来自单一进程以原子事件的形式记录服务内部正在发生的事提供丰富的上下文信息指标是定量的numeric、结构化的日志是定性的textual、非结构化或半结构化的日志细节丰富但代价是显著更高的数据量higher data volumes日志告诉你应用正在发生什么whats happening to your application。在排障时日志能回答具体报了什么错、参数是什么但缺少跨组件的交互上下文。追踪Traces数据通路上的分步地图追踪在可观测性图景上更进一步它告诉你数据通路中每一步发生了什么相当于一张哪里出了问题的地图一个 trace 以图形化方式展示数据流中每个步骤耗时多少例如一次 HTTP 请求、一次数据库查询、一次第三方服务调用分别耗时多少它能展示请求从哪里发起、在哪里结束以及系统如何响应这种能力帮助你在从未预料到的地方定位问题区域并评估影响——没有追踪能力这些瓶颈往往难以发现。关于 trace 与 span 的基础模型可参考仓库中的 Trace structure 文档 与 Glossarytrace 由若干 span 组成span 是 trace 中的工作单元带起始时间、持续时长与操作名并可通过 parent 引用形成 span 树。性能剖析Profiles定位可优化代码行剖析帮助理解应用如何利用 CPU 时间、内存等计算资源进而定位具体的代码行或函数进行优化提升性能与效率。它是四大支柱中最微观的一类信号。为什么需要 Trace单靠指标与日志无法根治复杂问题指标自身不足以定位根因它只能告诉你出问题了无法告诉你为什么日志虽信息量大但缺乏复杂环境中各组件之间交互与依赖的上下文每一类信号在根因定位上都有独特优势要最大化可观测性战略的价值必须把它们关联起来correlate them。Trace 的独特能力在于展示服务之间的关系识别你的服务**上游upstream**有哪些服务——这有助于理解当你的服务出问题时哪些服务会受负面影响识别你的服务**下游downstream**有哪些服务——由于你的应用依赖这些下游服务它们的故障很可能正是你服务报错或延迟升高的根源例如你可以直接看到正在失败的数据库以及所有受影响的边缘端点。换句话说trace 是在微服务架构中把指标异常翻译成服务依赖关系的关键桥梁。从指标到 TraceExemplar 关联机制指标与 trace 的关联核心是Exemplar示例。借助 exemplar你可以从某个指标数据点直接跳到与之关联的 trace例如从某个百分位延迟异常直接打开对应的一次完整请求追踪。在 Tempo 中Exemplar 有两种典型来源1. metrics-generator 自动生成 ExemplarTempo 的 metrics-generator 组件在处理传入 span 时会基于 span 计算 RED 指标Rate 请求速率、Error 错误率、Duration 持续时长直方图并自动生成 exemplar从而支持指标 → trace的一键跳转。该能力在 Metrics from traces 文档中有明确说明。从源码看service graphs 处理器在观测直方图时会携带 trace ID在 servicegraphs.go 中处理器通过e.TraceID()取得当前 span 的 trace ID并在ObserveBorrowed(..., traceID, ...)时将 trace ID 写入指标观测这正是 exemplar 携带 trace 标识的实现路径。在配置层面你可以通过metrics_generator.processor.span_metrics.trace_id_label_name指定生成指标中保存 trace ID 的标签名默认值为traceID详见 configuration/_index.md该标签名必须是合法的 Prometheus 标签名校验逻辑位于 validation/fields.go。2. TraceQL 指标查询中的 ExemplarTempo 的 TraceQL 指标metrics queries为所有 range 查询提供 exemplar 能力你可以在 query-frontend 中通过参数query_frontend.metrics.max_exemplars配置默认100设置为0表示禁用见 configuration/_index.md也可以在查询中直接加 hint{ span:name GET /:endpoint } | quantile_over_time(duration, .99) by (span.http.target) with (exemplarstrue)这样查询返回的时间序列上就会带上具体 trace 的引用点开数据点即可跳转到完整 trace。详细说明见 TraceQL metrics 文档。从 Trace 到日志、从日志到 Trace双向跳转除指标外trace 与日志之间同样需要双向关联从 trace 到日志查看某一次请求的 trace 时能看到沿途服务产生的日志条目从而补充 trace 之外的异常细节从日志到 trace在日志中发现可疑的 trace ID 后直接跳转到该 trace 查看完整调用链。在 Tempo 生态中实现日志 ↔ trace 关联最典型的手段是Grafana Alloy 的自动日志记录Automatic logging。其原理与配置在 automatic-logging.md 中有完整说明自动日志记录通过otelcol.connector.spanlogs连接器从 trace span 生成日志行每个 span/root/process 生成一条logfmt风格的日志包含svc服务名、spanspan 名、durspan 时长纳秒、tidtrace ID、status显式状态等默认键该连接器不会转发原始 trace因此必须同时把 trace 发送给 trace 后端如 Tempo避免丢数据生成的日志可写入 Loki配合 Grafana 的 Loki 数据源Derived fields配置匹配tid字段并指向 Tempo 数据源即可在日志界面点击跳转到对应 trace。例如下面的 Alloy 配置将 root span 记录为日志并发送到 OTLP 端点同时把 trace 转发给同一端点otelcol.receiver.otlp default { grpc {} http {} output { traces [ otelcol.connector.spanlogs.default.input, otelcol.exporter.otlp.default.input, ] } } otelcol.connector.spanlogs default { roots true output { logs [otelcol.exporter.otlp.default.input] } } otelcol.exporter.otlp default { client { endpoint env(OTLP_ENDPOINT) } }生成的 root span 日志行示例spanHTTP GET dur150200000ns http.methodGET http.target/api/v1/query svcmy-service tid7bba9f33312b3dbb8b2c2c62bb7abe2d也可以直接用 LogQL 查询自动日志例如筛选慢请求{tracesroot} | logfmt | dur 2s and svcmy-service值得说明的是Tempo 原生也提供等价的 TraceQL 搜索无需 Loki例如{ resource.service.name my-service span:duration 2s }即可实现同样的慢请求发现。让 Tempo 自己成为观测对象自追踪与元监控理解了四大支柱之后一个自然的延伸问题是追踪系统本身如何被观测Tempo 仓库提供了两个层面的实践Tempo 自追踪Self-tracingTempo 使用 OpenTelemetry SDK 对自身进行插桩可以通过环境变量导出自身产生的 trace详见 self-tracing.md。其底层初始化逻辑在 pkg/tracing/tracing.go 中实现InstallOTelOrJaegerFromEnv从OTel 或 Jaeger 环境变量初始化全局 tracer两者都未配置时为空操作no-op服务名默认为tempo-targettarget为-target标志的值可用OTEL_SERVICE_NAME或JAEGER_SERVICE_NAME覆盖且JAEGER_SERVICE_NAME优先见 tracing.go该函数由 cmd/tempo/main.go 在启动早期调用并传入config.SpanProfiling以决定是否启用 span profiling。关键环境变量包括类别环境变量说明OTelOTEL_EXPORTER_OTLP_ENDPOINTOTLP 端点 URL例如http://tempo:4318OTelOTEL_EXPORTER_OTLP_TRACES_ENDPOINT仅 traces 的端点覆盖上述端点OTelOTEL_TRACES_EXPORTERtraces 导出器默认otlp设为none时仅传播上下文不导出OTelOTEL_TRACES_SAMPLER/OTEL_TRACES_SAMPLER_ARG采样器与参数支持always_on、always_off、traceidratio、parentbased_*以及jaeger_remote等OTelOTEL_PROPAGATORS上下文传播器默认tracecontext、baggage、jaegerOTelOTEL_RESOURCE_ATTRIBUTES附加的自定义 resource 属性JaegerJAEGER_AGENT_HOST/JAEGER_ENDPOINTJaeger agent 主机 / collector 端点JaegerJAEGER_SAMPLER_TYPE/JAEGER_SAMPLER_PARAM采样类型const、probabilistic、remote与参数JaegerJAEGER_AGENT_PORTJaeger agent 端口默认6831JaegerJAEGER_TAGS以key1value1,key2value2格式附加 resource 属性仓库中的 tracing_test.go 对采样行为做了直接验证例如always_on采样所有 trace、always_off不采样、traceidratio按比例采样以及jaeger_remote/parentbased_jaeger_remote对initialSamplingRate的解析与非法参数缺少endpoint的报错校验。此外还支持强制采样单次请求在请求上设置Jaeger-Debug-IdHTTP 头Tempo 将无视采样配置强制采样该请求并把头值作为jaeger-debug-idspan 属性写入需激活jaeger传播器。Span profiling 则可通过配置span_profiling: true或--span-profiling标志开启为 span 附加 pprof goroutine 标签与pyroscope.profile.id属性将 trace span 与运行期间采集的 profile 关联起来——这正对应四大支柱中trace 与 profile 的关联。Tempo 元监控Metamonitoring若想完整观测 Tempo 自身的指标与日志可使用 set-up-monitoring.md 与共享文档 metamonitoring.md 描述的方案通过 Grafana Kubernetes Helm chartk8s-monitoring配置 Grafana Alloy 抓取 Tempo 的prom-metrics端口指标与 Pod 日志分别 remote-write 到 Prometheus/Mimir 与 Loki。其values.yml核心片段如下integrations: tempo: instances: - name: traces # instance 标签名 namespaces: - traces # 搜索 Tempo 实例的命名空间 metrics: enabled: true portName: prom-metrics logs: enabled: true labelSelectors: app.kubernetes.io/name: tempo destinations: - name: metrics type: prometheus url: url # 例如 https://prometheus host/api/prom/push - name: logs type: loki url: url # 例如 https://loki host/loki/api/v1/push之后可从仓库的operations/tempo-mixin-compiled目录导入 8 个监控 Dashboard如tempo-operational.json并使用mimirtool上传rules.yaml与alerts.yaml分别对应 recording rules 与告警规则实现指标 → 告警 → 日志 → trace的完整闭环监控。Mixin 源文件位于 operations/tempo-mixin编译产物位于 operations/tempo-mixin-compiled。总结让四类信号协同工作可观测性的价值不在于单个信号而在于关联信号回答的问题与其他信号的关联方式Metrics是否有事情发生Exemplar 跳转到 traceLogs具体发生了什么trace IDtid跳转到 trace反之 trace 可下钻日志Traces在哪一步、哪个服务出了问题关联上下游服务、关联指标与日志Profiles哪些代码需要优化通过 span profiling 与 trace span 关联Tempo 在整个体系中扮演 trace 的存储、检索与关联枢纽借助 metrics-generator 与 TraceQL 指标生成携带 exemplar 的指标、借助自动日志记录打通日志侧入口、借助自追踪让自身也被四类信号观测。在实际部署中建议结合 部署模式文档 与 架构文档 规划组件形态再按本文所述逐步配置信号关联最终形成指标发现问题 → trace 定位链路 → 日志补充细节 → profile 优化性能的完整排障工作流。【免费下载链接】tempoGrafana Tempo is a high volume, minimal dependency distributed tracing backend.项目地址: https://gitcode.com/GitHub_Trending/tempo1/tempo创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考