1. 课程导论：Tempo在可观测性中的定位、值班台场景下的查询痛点、课程目标与学习路径
1.1 可观测性三支柱与Tempo的定位
在云原生可观测性体系中，指标（Metrics）、日志（Logs）、追踪（Traces） 并称为三大支柱。Grafana Tempo 专注于分布式追踪领域，其核心定位是提供高性价比、大规模、与Grafana生态深度集成的追踪后端。
| 维度 | Prometheus（指标） | Loki（日志） | Tempo（追踪） |
|---|---|---|---|
| 数据模型 | 时序数值 | 非结构化文本 | Span 树 / TraceID 关联 |
| 核心查询 | PromQL 聚合 | LogQL 过滤 | TraceID 检索 + TraceQL |
| 存储侧重 | 高基数压缩 | 流式写入 + 索引 | 对象存储 + 局部索引 |
| 典型延迟 | 秒级 | 秒级 | 秒级（TraceID）~ 分钟级（TraceQL 扫描） |
关键认知：Tempo 不存储应用日志或指标，它只负责高效地存储和检索 Span 数据。其“无索引”设计哲学（默认只建 TraceID 索引）带来了极低的存储成本，但也将查询性能压力转移到了存储层和查询引擎的调优上。
1.2 值班台场景下的查询痛点
在“值班台”或“On-Call”场景中，工程师收到告警后，第一反应往往是：“这个错误影响到了哪些请求？慢在哪一环？”。此时，Tempo 的查询性能直接决定了故障定位的 MTTR（平均修复时间）。以下是值班台最常见的三大查询痛点：
- TraceID 查询超时：用户从日志或告警中复制 TraceID 到 Tempo，页面长时间 loading 后返回 504 或“查询超时”。根本原因通常是后端存储（如 S3/GCS）的 GET 请求延迟过高，或缓存未命中。
- TraceQL 扫描缓慢：当只知道“服务 A 返回了 500 错误”但不知道 TraceID 时，需要使用 TraceQL 按属性（如
status=error）扫描。在数据量大的集群中，一次全量扫描可能耗时数分钟，值班台无法接受。 - 高并发查询导致 Tempo 自身 OOM：多个值班同事同时查询，或自动化脚本频繁拉取追踪数据，导致 Tempo Query Frontend 或 Ingester 内存飙升，最终进程被 OOMKill。
值班台血泪教训：某电商大促期间，核心支付链路出现 P0 故障。值班同学通过 TraceID 查询追踪，Tempo 因后端对象存储限流，单次查询耗时 45 秒，导致故障定位窗口被严重拉长。事后分析发现，存储层并发度配置和缓存策略是主要瓶颈。
1.3 课程目标与学习路径
本课程旨在帮助 SRE、平台工程师和高级后端开发者，系统性地掌握 Tempo 存储调优的核心技能，从而在值班台场景下实现秒级追踪查询。课程不涉及基础安装，而是直击生产环境中的性能瓶颈。
课程三大目标
- 目标一：理解 Tempo 存储架构（Block、Ingester、Compactor）与查询链路，能够准确诊断慢查询根因。
- 目标二：掌握对象存储（S3/GCS/MinIO）的性能调优参数、缓存策略（内存 + 磁盘）以及 TraceQL 索引优化。
- 目标三：具备生产级 Tempo 集群的容量规划、限流配置和故障演练能力。
学习路径（6大模块）
| 模块 | 核心内容 | 实战产出 |
|---|---|---|
| 模块1：基础与诊断 | 存储架构、查询链路、Grafana 面板分析 | 慢查询根因分析清单 |
| 模块2：对象存储调优 | S3 并发、请求合并、Backend 配置 | 存储延迟降低 50%+ |
| 模块3：缓存策略 | 内存缓存、磁盘缓存、缓存预热 | TraceID 查询 P99 进入 1s |
| 模块4：TraceQL 加速 | Span 属性索引、专用标签、查询重写 | TraceQL 扫描提速 10x |
| 模块5：高并发与稳定性 | 限流、队列、内存预算、HPA | 集群抗压能力提升 3x |
| 模块6：综合实战与演练 | 故障注入、压测、调优报告 | 值班台 SOP 手册 |
1.4 谁应该学习本课程
- SRE / 运维工程师：负责 Tempo 生产集群的稳定性与性能，需要快速响应值班台查询延迟问题。
- 平台工程师：构建内部可观测性平台，需要将 Tempo 查询延迟控制在 SLA 以内。
- 高级后端开发者：深入理解分布式追踪存储原理，优化自家服务的 Span 上报与查询模式。
前置要求：建议学员具备基本的 Kubernetes 操作经验，了解 Grafana 面板使用，并对分布式追踪概念（Span、TraceID、Baggage）有初步认识。本课程不涉及 Tempo 的初次安装部署。