【GO】Grafana Tempo (1) --- 架构
最近在尝试用 LGTM 来实现 Go 微服务的可观测性,就顺便整理一下文档。
Tempo 会分为 5 篇文章:
Tempo 的架构
启动 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 按以下布局生成:
怎么处理?-> 已 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
这是一个可选组件,从 ingester 的 traces 数据中派生度量指标,并将其写入度量指标存储(一般需要 prometheus 配合)。
评论