在微服务规模不断扩大的今天，一次外部请求往往会穿过十几个甚至几十个服务节点，传统的日志排查方式很难还原完整的调用路径。Tempo作为Grafana生态中的分布式链路追踪后端，专门用于存储和查询trace数据，它不依赖复杂的索引，而是通过对象存储来保存海量跨度信息，因此在云服务器上部署时具备较好的成本优势。要让Tempo真正发挥作用，既要完成基础环境搭建，也要设计合理的采样配置，避免数据爆炸或关键链路丢失。
一、Tempo在云服务器上的部署架构
Tempo本身是一个无状态的计算组件集群，核心职责是接收来自代理或网关的trace数据、将其整理后写入对象存储，并响应前端的查询请求。在云服务器环境中，我们通常将Tempo部署为多个实例组成的集群，前面通过负载均衡分发接收流量，后端对接云厂商提供的对象存储桶（如S3兼容存储）。这种架构下，计算资源和存储资源可以分别扩缩容，不会因链路数据增长而被迫升级整台机器。
除了Tempo服务本身，完整的追踪系统还需要采集端与分析端配合。采集端一般使用Grafana Agent或者OpenTelemetry Collector，它们部署在业务所在的云主机或容器内，负责从应用侧拉取或接收trace跨度，再做批量压缩后发给Tempo。分析端则是Grafana，通过配置Tempo数据源，让用户能够以服务地图、单次trace瀑布图的形式查看调用链。三者分开部署，既清晰又便于按负载独立调优。
1.1 基础组件与端口规划
在单台云服务器做测试时，可以用Docker Compose拉起一个Tempo单节点，暴露3200端口供查询、4317端口接收OTLP gRPC数据。但在生产集群中，建议将接收端口、查询端口和管理端口分开绑定内网网卡，避免公网直接触碰追踪接口。同时，对象存储的访问密钥应通过云服务器的密钥管理服务注入，而不是明文写在配置文件中。
下面的表格列出了典型Tempo部署中需要关注的组件与对应职责，方便在规划云服务器资源时做对照：
| 组件名称 | 部署位置 | 主要作用 |
|---|---|---|
| Tempo | 云服务器集群 | 接收trace、写对象存储、提供查询API |
| OTel Collector | 业务侧或独立网关 | 采集跨度、做批处理与转发 |
| Grafana | 运维内网 | 可视化trace与关联指标日志 |
| 对象存储 | 云厂商存储服务 | 持久化保存压缩后的trace块 |
二、分布式链路追踪的采样配置核心
采样指的是从全部请求链路中挑选一部分进行记录与上报。如果不采样，每一个请求都生成完整trace，在日均亿级调用的系统里，存储费用和网络开销都难以承受；如果采样过低，偶发的超时或异常可能因为未被抽取而消失在黑盒中。Tempo的采样策略主要在采集端配置，Tempo服务端更多负责接收和存储，但也可以通过网关层做尾部决策。
常见的采样方式分为头部采样和尾部采样。头部采样在请求一开始就被决定要不要记录，实现简单、资源占用低，但无法根据请求最终结果动态调整；尾部采样则等请求结束、知道成功或失败后再决定是否保留，能精准留住错误和慢请求，不过需要在采集端缓冲一定时间的跨度，对内存有更高要求。
2.1 头部采样的基础配置
以OpenTelemetry Collector为例，可以在processor中配置probabilistic sampler，例如设置采样率为0.1，代表大约十分之一的链路会被发往Tempo。这种方式适合流量极为平稳、错误率可被整体指标覆盖的业务。配置时需注意，采样率不要频繁大幅变动，否则会导致基于trace计算的百分比指标出现断层，影响容量评估。
如果某些核心接口无论如何都要追踪，可以配合attribute filter，在头部采样前先对带有特定标签（如api_version=v1且path=/pay）的请求做全量保留。这样既能控制总体数据量，又不漏掉关键支付链路的细节，是很多电商云架构中的实用做法。
2.2 尾部采样在Tempo体系中的落地
尾部采样通常借助Collector的tail sampling processor实现，它支持按错误状态、耗时阈值、特定字段组合来决策。举例来说，可以设定规则：状态码为5xx的全部保留，耗时超过800毫秒的保留百分之五十，其余正常请求仅保留百分之一。这样的分层策略让Tempo中存储的trace更有排查价值，而不是充斥大量健康但无用的短链路。
需要注意的是，尾部采样要求Collector在内存中暂存一个 trace 的所有跨度直到决定发出，因此云服务器的内存规格要留足余量。当实例重启或滚动发布时，正在缓冲的链路会丢失，所以重要业务最好搭配至少两个Collector节点做高可用，并控制单个trace的最大等待时间在两秒内。
三、部署与采样联调的常见问题
很多团队在云服务器上跑通Tempo后，发现Grafana里搜不到trace，第一反应是Tempo挂了，其实多半是采样配置把数据拦在了采集端。排查时可以先在Collector侧临时把采样率调成1，确认链路能进对象存储，再逐步回收比例。同时检查时间字段，Tempo默认按UTC存储，如果Grafana时区没对齐，会看起来像查不到最近数据。
另一个常见误区是认为Tempo单机就能扛住高并发写入。虽然它不建索引，但接收端仍要做序列化与块整理，云服务器CPU到点后会出现数据堆积。此时应优先横向加Tempo实例，而不是盲目调大单实例线程数，否则对象存储的并发写入限制反而会先被触发。合理的部署加分层采样，才能让分布式链路追踪既省钱又管用。
链路追踪的价值不在于记录一切，而在于用可控的成本留住足够定位问题的那部分真相。