【GO】LGTM_Grafana_Tempo(1)_架构

最近在尝试用 LGTM 来实现 Go 微服务的可观测性，就顺便整理一下文档。

Tempo 会分为 4 篇文章：

1. Tempo 的架构
2. 官网测试实操跑通
3. gin 框架发送 trace 数据到 tempo
4. 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 配合)。