最近在尝试用 LGTM 来实现 Go 微服务的可观测性，就顺便整理一下文档。
Tempo 会分为 4 篇文章：
- Tempo 的架构
- 官网测试实操跑通
- gin 框架发送 trace 数据到 tempo
- go-zero 微服务框架使用发送数据到 tempo
第一篇是关于，tempo 的架构，其实可以直接上实操，不过了解一下 tempo 的框架感觉还是挺有意思的，而且比想象中的简单。
上图就是 tempo 的架构图，分为 7 个模块。大体上又可以分成，收集，处理，存储，检索。中间的过程，又包含，监控，压缩。其实跟我们普通的一个系统差不多，在我们设计一个数据处理中心的时候，也可以分为这几个部分。
- 怎么收？收什么？
- 收到了怎么处理，怎么做归一化？
- 处理完了怎么存？
- 存完了咋么取？
Distributor
distributor 接收多种格式的 spans ，包括 Jaeger、OpenTelemetry(http/grpc) 和 Zipkin。它通过对 traceID 进行哈希处理，并使用分布式一致性哈希环将 span 路由到 ingester 。distributor 使用了 OpenTelemetry Collector 的接收器层。为了获得最佳性能，建议使用 Otel Proto。因此，Grafana Agent 使用 otlp 导出器/接收器将 span 发送到Tempo。
怎么收？收什么？ -> HTTP/GRPC接口收集符合 protocol 的 traces 数据
Ingester
ingester 将 traces 数据批量处理成 block ，创建布隆过滤器和索引，然后将其全部刷新到后端。后端中的 block 按以下布局生成：
<bucketname> / <tenantID> / <blockID> / <meta.json>/ <index>/ <data>/ <bloom_0>/ <bloom_1>.../ <bloom_n>
怎么处理？-> 已 block 形式存储(泛)
直接存可能会影响读，所以要以某种数据结构存，来优化查
Storage
经过 ingester 处理后的数据可以存在 OSS 也可以存在 local，OSS 目前对接的是 S3、GCS 和 Azure。
怎么存？存哪里？-> 存本地，或者云上
Query Frontend
Query frontend 负责将传入查询的搜索空间(search space)进行分片。
traces 数据通过简单的 HTTP 接口获取：GET /api/traces/<traceID>
在内部，query frontend 将 blockID 空间分割为可配置数量的分片，并将这些请求排队。querier 通过流式 gRPC连接链接到 query frontend，以处理这些分片查询。
存完了咋么取？-> HTTP 接口查
Querier
Querier 负责在 ingester 或后端存储中查找请求的 trace id。根据参数，它将查询 ingester， 并从后端提取布隆过滤器/索引来搜索对象存储中的块。
Querier 通过 HTTP 接口获取数据：GET /querier/api/traces/<traceID>，但不建议直接使用该端点。
应该将查询结果发送到查询前端。
Compator
Compator(压缩器) 在后端存储和 ingester 之间流式传输块，以减少总块数。
Metrics generator
ator
Compator(压缩器) 在后端存储和 ingester 之间流式传输块，以减少总块数。
Metrics generator
这是一个可选组件，从 ingester 的 traces 数据中派生度量指标，并将其写入度量指标存储(一般需要 prometheus 配合)。
