后端可观测性链路追踪【免费下载链接】tempoGrafana Tempo is a high volume, minimal dependency distributed tracing backend.项目地址https://gitcode.com/GitHub_Trending/tempo1/tempo点击查看免费下载导读本文围绕 Tempo 官方文档中Set up Alloy to work with Tempo一节系统讲解如何在微服务环境中使用 Grafana Alloy 搭建 tracing pipeline从 Alloy 的 receiver / processor / exporter 架构、OTLP gRPC/HTTP 双通道接入、批量与属性处理到自动日志automatic logging、尾采样tail-based sampling和服务图指标等高级能力最后给出 Kubernetes Helm 部署下通过 OTLP 远程写入 Tempo 的完整可运行配置。读完本文你将掌握一条无需改动应用代码即可集中采集、加工、采样并落地 Tempo 的完整链路并能结合本仓库源码理解每一环节的底层行为。Alloy 在 Tempo 追踪链路中的角色Grafana Alloy 为 Tempo、OpenTelemetry、Prometheus、Pyroscope、Loki 以及众多指标、日志、Trace 与 Profiling 工具提供原生 pipeline同时兼容 OpenTelemetry Collector 与 Prometheus Agent。在追踪场景下Alloy 最典型的用途是充当 tracing pipeline把 Trace 从应用侧卸载offload下来统一转发到存储后端即 Tempo。使用 Alloy 收集并转发 Trace 的核心收益在于无侵入当你的系统由多个应用或多个微服务构成时不必逐一修改应用的代码库只需集中维护一套 Alloy 配置即可把分散在各服务的追踪数据汇聚到 Tempo。你既可以把 Alloy 当作 OTel Collector 或 Prometheus Agent 的替代方案也可以把它与这些组件混合组成多采集器的混合系统。Alloy 可以部署在 IT 基础设施的任何位置与自建的 Grafana LGTM 栈、Grafana Cloud 遥测后端或其他厂商的兼容后端搭配使用支持纯本地、纯云端或混合部署。Alloy 的配置文件使用 Alloy 配置语法编写与 OpenTelemetry Collector 的 YAML 风格不同它是一种声明式的块结构语言每个功能模块receiver、processor、exporter、connector都是一个组件块。Pipeline 架构receivers、processors 与 exportersAlloy 可以运行一组 tracing pipeline从应用采集数据并写入 Tempo。Pipeline 基于 OpenTelemetry 构建由三类组件串联而成receivers负责接收数据的入口决定链路从何处开始processors负责在数据流转过程中加工数据批量、改属性、采样等exporters负责把加工后的数据发送到下游后端。这一架构与 OpenTelemetry Collector 的设计保持一致。你可以在一条配置中定义多条彼此独立的 tracing pipeline每条 pipeline 分别采集各自的 span 并发送到不同的后端例如把生产环境的 Trace 发往 Tempo、把另一份副本发往调试后端。从 Tempo 侧看这条链路的终点是distributor模块。在本仓库源码 modules/distributor/config.go 中Tempo 默认启用jaeger与otlp两类 receiver其中 OTLP 默认开启grpc协议modules/distributor/receiver/shim.go 则通过otelcol.MakeFactoryMap注册了jaegerreceiver、zipkinreceiver、otlpreceiver与kafkareceiver四种采集工厂最终由TracesPusher.PushTraces把数据推入 Tempo 内部链路。也就是说Alloy 侧支持的 OTLP 导出目标端口与 Tempo distributor 默认监听的 OTLP gRPC 端口4317是天然对齐的。让 Alloy 接收 Trace多协议接入Alloy 支持多种 Trace 摄取 receiverOTLPOpenTelemetry、Jaeger、Zipkin以及Kafka。每条 pipeline 都可以被配置为同时接收上述所有格式的 Trace到达 pipeline 的 Trace 会依次经过该 pipeline 定义的 receivers → processors → exporters。要把 Alloy 用于追踪官方给出的三步流程是安装并启动 Grafana Alloy确保 Alloy 进程可访问配置 Grafana Alloy编写接收、处理、导出的组件块按需启用附加功能自动日志、采样、服务图指标等。基础示例OTLP gRPC HTTP 双通道接收并导出到 Tempo下面的配置让 Alloy 同时通过 OTLP gRPC端口 4317与 OTLP HTTP端口 4318接收 Trace并原样转发给 Tempootelcol.receiver.otlp default { grpc { endpoint 0.0.0.0:4317 } http { endpoint 0.0.0.0:4318 } output { traces [otelcol.exporter.otlp.default.input] } } otelcol.exporter.otlp default { client { endpoint env(TEMPO_ENDPOINT) } }注意当 Alloy 运行在 Docker 或 Kubernetes 中时receiver 的 endpoint 必须显式设置为0.0.0.0:port如上例。默认会绑定到localhost这会导致同一网络中的其他容器或 Pod 无法把 Trace 发送给 Alloy。上例中env(TEMPO_ENDPOINT)从环境变量读取 Tempo 地址例如tempo:4317或distributor.tempo.svc.cluster.local:4317。otelcol.receiver.otlp块的所有可用选项TLS、认证、压缩等可查阅 Alloy 组件参考中的otelcol.receiver.otlp章节。设置 Pipeline 处理能力Trace 在 pipeline 中流转时会经过一系列处理器目的有两个一是让分布式追踪系统更可靠如批量合并降低连接数二是让数据能服务于更多场景如 Trace 发现、尾采样、指标生成。Batching批量Alloy 支持对 Trace 做批量处理。批量能带来三方面收益更好地压缩数据降低存储与传输体积减少对外发出的连接数量属于官方推荐的 trace pipeline 最佳实践。对应组件为otelcol.processor.batch块。建议把它放在 receiver 之后、exporter 之前例如把上面的基础示例改造为 receiver → batch → exporter 的链式结构。Attributes 操作Alloy 允许对流经 pipeline 的 span 属性做通用操作一个常见用途是为 Trace 补充环境或集群变量例如deployment.environment、cluster.name。可用于属性操作的处理器包括otelcol.processor.attributes按 key 增删改 span/resource 属性otelcol.processor.transform基于 OpenTelemetry Transformation LanguageOTTL做更复杂、更灵活的转换。后文自动日志一节还会看到otelcol.processor.attributes的另一个典型用法为日志打上loki.attribute.labels提示把属性提升为 Loki label。用 Prometheus Service Discovery 附加元数据Prometheus 的服务发现机制可以让你把与指标相同的元数据附加到 Trace 上。对 Kubernetes 用户而言这意味着可以动态地为发送 span 的 Pod 附加 namespace、Pod 名、容器名等元数据从而实现指标与 Trace 同源、可互相串联otelcol.receiver.otlp default { http {} grpc {} output { traces [otelcol.processor.k8sattributes.default.input] } } otelcol.processor.k8sattributes default { extract { metadata [ k8s.namespace.name, k8s.pod.name, k8s.container.name ] } output { traces [otelcol.exporter.otlp.default.input] } } otelcol.exporter.otlp default { client { endpoint env(OTLP_ENDPOINT) } }Trace 发现Automatic logging自动日志自动日志为每条经过 tracing pipeline 的 span、root span 或 process 生成格式良好的日志行解决不知道系统里存在哪些 Trace的发现难题。它可以让你在 Loki 中按 key-value 对搜索 Trace ID并在 Grafana 中从日志直接跳转到对应 Trace 视图。其详细用法可参考文档 Automatic logging。自动日志使用otelcol.connector.spanlogsconnector 从 span 生成日志行。需要特别注意的是该 connector 只接收 Trace 并生成日志不会转发原始 Trace因此你必须把 Trace 同时发送给spanlogsconnector 与 Trace 后端否则会丢失 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 日志发往 Loki并在 Loki 中按日志类型过滤可以参考下面这个更完整的示例。注意otelcol.exporter.loki默认不会把日志属性提升为 Loki label需要借助otelcol.processor.attributes添加loki.attribute.labels提示把traces属性提升为 labelotelcol.receiver.otlp default { grpc {} http {} output { traces [ otelcol.connector.spanlogs.default.input, otelcol.exporter.otlp.tempo.input, ] } } otelcol.connector.spanlogs default { roots true span_attributes [http.method, http.target] output { logs [otelcol.processor.attributes.default.input] } } otelcol.processor.attributes default { action { key loki.attribute.labels action insert value traces } output { logs [otelcol.exporter.loki.default.input] } } otelcol.exporter.loki default { forward_to [loki.write.local.receiver] } loki.write local { endpoint { url http://loki:3100/loki/api/v1/push } } otelcol.exporter.otlp tempo { client { endpoint tempo:4317 } }自动日志生成的每条日志使用logfmt风格默认字段如下Key说明svcspan 所属 resource 中的服务名。spanspan 名称。durspan 时长纳秒例如150200000ns。tidTrace ID。statusspan 状态。仅当状态被显式设置非STATUS_CODE_UNSET时出现取值STATUS_CODE_OK或STATUS_CODE_ERROR。可通过span_attributes、process_attributes、event_attributes增加更多 key也可用overrides块自定义所有 key 名称。例如一条 root span 日志行可能长这样spanHTTP GET dur150200000ns http.methodGET http.target/api/v1/query svcmy-service tid7bba9f33312b3dbb8b2c2c62bb7abe2d每条日志还带有一个traces属性标识日志类型span、root、process或event。若按上文示例配置了loki.attribute.labels提示该属性会成为 Loki label。之后便可在 Grafana Explore 中用 LogQL 查询例如查找所有 root span 日志{tracesroot}或过滤特定服务的慢请求{tracesroot} | logfmt | dur 2s and svcmy-service。文档还特别指出Tempo 的原生 TraceQL 搜索已能提供与自动日志相同的 Trace 发现能力且无需 Loki 实例或额外日志量。例如查找某服务的全部 Trace{ resource.service.name my-service }、查找慢 Trace{ resource.service.name my-service span:duration 2s }、查找错误 Trace{ status error }。如果你的工作流以 Loki 为中心希望在排查日志时顺带发现 Trace自动日志依然很有价值。要在 Grafana 中实现从日志跳转 Trace可在 Loki 数据源的Derived fields中新增字段Name填TraceIDType选LabelMatch field name填tid并启用指向 Tempo 数据源的Internal link。Tail-based sampling尾采样Alloy 为分布式追踪系统和多实例 Alloy 部署实现了尾采样。与仅依赖概率的头采样不同尾采样可以基于整条 Trace 的数据做出采样决策。例如只采样包含错误的 Trace或只采样请求时长超过阈值的 Trace——这类判断在数据流经时无法即时作出需要等待 Trace 的几乎全部 span 到达。尾采样对高遥测量的大型系统是官方推荐策略代价是配置、实现与维护更复杂。详细原理与策略可参考文档 Tail sampling 与 Sampling policies and strategies。以 policies-strategies.md 中的基础示例为例接收 OTLP 数据并送入尾采样处理器处理器按概率策略随机采样 10% 的 Trace// Expose receiving OTLP data otelcol.receiver.otlp example { // Allow OTLP HTTP data on all interfaces on port 4318 http { endpoint 0.0.0.0:4318 } // Allow OTLP gRPC data on all interfaces on port 4317 grpc { endpoint 0.0.0.0:4317 } // Send all received trace spans to the tail sampling processor output { traces [ otelcol.processor.tail_sampling.example.input ] } } // Make decisions on whether to sample or discard traces otelcol.processor.tail_sampling example { // Define a single probabilistic processor to determine sampling policy { // The name of the policy, each policy name must be unique for this tail sampling instance name example_probabilistic // The policy type is probabilistic type probabilistic // Each policy type is defined by a block for the policy with specific parameters for it probabilistic { // The overall ratio of traces that have been received to randomly sample. // In this case 1 in 10. sampling_percentage 10 } } }可用的采样策略类型包括完整列表见 policies-strategies.md策略类型行为典型场景always_sample采样全部 Trace调试或全量收集and用逻辑AND组合多个策略同时满足多个条件才采样boolean_attribute依据布尔属性resource/record采样功能开关、调试模式composite按顺序与比例分配组合多个 sampler匹配多个不同条件latency依据 Trace 时长采样识别慢性能numeric_attribute依据数值属性采样捕获大响应等ottl_condition依据 OTTL 布尔条件span/span event采样复杂精细过滤probabilistic随机采样指定百分比的 Trace降低数据量status_code依据 span 状态码采样保留错误/成功 Trace**决策周期decision period**是尾采样的关键参数Alloy 按 Trace ID 对 span 分组并缓冲一段可配置的时间期满后判定 Trace 是否完整。若某条 Trace 的实际时长超过决策周期它会被拆成多段分别决策可能导致同一 Trace 部分 span 被采样、部分被丢弃最终在 Tempo 中形成碎片化 Trace。决策周期越长采样判断越准但缓冲 span 的内存开销也越大。为此 OTel 尾采样处理器还提供两个缓存sampled cache已决定保留的 Trace ID 列表与non-sampled cache已决定丢弃的 Trace ID 列表均按可缓存的最大 Trace 数配置可独立或同时启用。同时启用两个缓存能在首个决策周期后短路后续所有决策、降低缓冲内存但要注意超长 Trace 的后续 span 也可能因此被误判。多实例负载均衡多实例 Alloy 部署中同一 Trace 的 span 可能到达不同实例而采样决策通常要求同一 Trace ID 的全部 span 落到同一实例。可通过otelcol.exporter.loadbalancing组件按traceID键做一致性哈希路由常见做法是两层 collector第一层接收并分发第二层执行采样策略并可用静态 IP、多 IP 的 DNS A 记录或 Kubernetes headless service 解析器来动态扩缩第二层实例数。从 span 生成指标span metricsAlloy 可以在 pipeline 内从 Trace 生成 span 指标。需要注意的是如果你在 Trace 到达 Tempo 之前就做了采样需要先想清楚指标在哪里生成——在 collector 侧生成则指标覆盖全量流量交给 Tempo 生成则只覆盖采样后保留的 Trace。决策依据可参考 Choose where to generate metrics from tracesAlloy 的具体配置可参考 Use Alloy to generate metrics from spans。Service graph metrics服务图指标服务图指标刻画分布式系统中服务与服务的依赖关系。服务图处理器通过分析 Trace 构建服务地图目标是找出edges边edges 是具有父子关系的 span 对代表一次服务之间的跳转如一次请求。请求次数与其耗时会被记录为指标进而用于绘制服务依赖图。实现细节可参考 Service graphs。在两层 collector 的尾采样架构中服务图 connector 与 span metrics connector 通常作为 pipeline 的分叉fork放在尾采样之前确保即使 Trace 被丢弃指标仍然完整生成尾采样处理器之后再接 OTLP exporter 把采样后的 Trace 发送到 Grafana Cloud / Tempo。导出 span把数据写到 Tempo 及其他后端每条 tracing pipeline 都可以把 Trace 导出到多个不同的后端。导出机制基于 OpenTelemetry Collector 的 OTLP exporterAlloy 支持以OTLP 格式导出 Trace。除 endpoint 与认证外exporter 还内置了两种可靠性机制失败重试retrying on failure导出失败时按策略重试队列缓冲queue buffering为网络抖动等瞬时故障提供内存队列缓冲避免数据直接丢失。可用组件包括otelcol.exporter.otlpgRPC与otelcol.exporter.otlphttpHTTP全部选项见 Alloy 组件参考对应章节。实战用 Helm 部署 Alloy 远程写入 Tempo文档 remote-write-tempo.md 给出了一条基于 Grafana Alloy Helm chart 的完整落地路径把 Trace 以 OTLPprotobuf格式发送到 Tempo。步骤如下新建values.yaml作为 Alloy Helm 安装的配置alloy: extraPorts: - name: otlp-grpc port: 4317 targetPort: 4317 protocol: TCP configMap: create: true content: |- // Creates a receiver for OTLP gRPC. // You can easily add receivers for other protocols by using the correct component // from the reference list at: https://grafana.com/docs/alloy/latest/reference/components/ otelcol.receiver.otlp otlp_receiver { // Listen on all available bindable addresses on port 4317 (which is the // default OTLP gRPC port) for the OTLP protocol. grpc { endpoint 0.0.0.0:4317 } // Output straight to the OTLP gRPC exporter. We would usually do some processing // first, most likely batch processing, but for this example we pass it straight // through. output { traces [ otelcol.exporter.otlp.tempo.input, ] } } // Define an OTLP gRPC exporter to send all received traces to Tempo. // The unique label tempo is added to uniquely identify this exporter. otelcol.exporter.otlp tempo { // Define the client for exporting. client { // Send to the Tempo distributor on port 4317 (OTLP gRPC). endpoint distributor.tempo.svc.cluster.local:4317 // Disable TLS for OTLP export. tls { // The connection is insecure. insecure true // Do not verify TLS certificates when connecting. insecure_skip_verify true } } }根据实际部署方式更新 distributor 端点Tanka 部署distributor.NAMESPACE.svc.cluster.local:4317Helm 部署RELEASE-NAME-distributor.NAMESPACE.svc.cluster.local:4317用 Helm 安装 Alloyhelm install -f values.yaml grafana-alloy grafana/alloy如果需要部署到指定 namespace先创建 namespace再在命令末尾追加--namespacegrafana-alloy-namespace。关于迁移若你正从 OpenTelemetry Collector、Prometheus 或 Promtail 迁移到 Alloy可参考文档 Migrate to Alloy 中提供的迁移指南链接。与 Tempo 内部链路的衔接把 Alloy 配置完成后Trace 实际到达的是 Tempo 的 distributor。本仓库中 distributor 的默认 receiver 配置见 modules/distributor/config.go默认启用jaegergrpc thrift_http与otlpgrpc协议若需让 Tempo 也接收 OTLP HTTP 或其他协议可在此 receivers 配置中扩展。receiver 的装配在 modules/distributor/receiver/shim.go 完成OTLP receiver 工厂来自otlpreceiver.NewFactory()。该文件中的TracesPusher接口shim.go定义了PushTraces与RetryInfoEnabled两个方法前者把采集到的ptrace.Traces推入 Tempo 处理链后者配合RetryAfterOnResourceExhausted配置见 config.go在资源耗尽ResourceExhausted时向客户端返回带RetryInfo的重试提示与 Alloy 侧 exporter 的失败重试机制形成闭环。理解这一衔接点有助于你判断 Alloy 端配置协议、端口、TLS与 Tempo 端 receiver 配置是否匹配。总结把上述内容串成一条最小可用链路应用 → Alloy receiverOTLP gRPC/HTTP绑定0.0.0.0:4317/4318→ processorbatch / attributes / k8sattributes / tail_sampling / 指标与服务图生成→ exporterOTLP → Tempo distributor:4317。需要强调的要点receiver 在容器化环境中务必绑定0.0.0.0否则其他 Pod 无法上报otelcol.connector.spanlogs只产日志不转发 Trace须与 exporter 分叉并行避免丢 Trace尾采样决策周期与 sampled / non-sampled 缓存直接决定 Trace 是否会碎片化多实例部署需用 loadbalancing exporter 按 trace ID 保持一致性路由exporter 自带重试与队列缓冲可在网络瞬时故障时兜底Tempo 默认 OTLP gRPC 端口为 4317与 Alloy 导出端天然对齐二者通过 distributor receiver 配置衔接。赞分享后端可观测性链路追踪【免费下载链接】tempoGrafana Tempo is a high volume, minimal dependency distributed tracing backend.项目地址https://gitcode.com/GitHub_Trending/tempo1/tempo点击查看免费下载相关推荐Grafana Tempo 接入指南使用 OpenTelemetry Collector 采集并转发 Trace 到 TempoGrafana Tempo 接入指南使用 OpenTelemetry Collector 采集并转发 Trace 到 Tempo OpenTelemetry后端可观测性链路追踪使用 Grafana Alloy 以 Pull 模式采集 Go 应用性能剖析数据并接入 Pyroscope使用 Grafana Alloy 以 Pull 模式采集 Go 应用性能剖析数据并接入 Pyroscope 本指南讲解如何在 Pyroscope 生态中以 pu可观测性性能剖析后端运维观测Grafana Tempo 尾采样策略完全指南Alloy Tail Sampling Policies 配置与实战Grafana Tempo 尾采样策略完全指南Alloy Tail Sampling Policies 配置与实战 在 Grafana Tempo 的遥测收集后端可观测性链路追踪上一篇OpenCode环境变量终极配置指南从零到精通的完整教程下一篇告别传统验证码AJ-Captcha行为验证让用户体验提升300%的5个技巧创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
