【GO】LGTM_Grafana_Tempo_(1)_架构

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

Tempo 会分为 5 篇文章:

  1. Tempo 的架构
  2. 启动 Tempo 配置项文件简单说明
  3. 官网测试实操跑通
  4. gin 框架发送 trace 数据到 tempo
  5. go-zero 微服务框架使用发送数据到 tempo

第一篇是关于,tempo 的架构,其实可以直接上实操,不过了解一下 tempo 的框架感觉还是挺有意思的,而且比想象中的简单。

【GO】LGTM_Grafana_Tempo_(1)_架构_第1张图片

上图就是 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/

在内部,query frontend 将 blockID 空间分割为可配置数量的分片,并将这些请求排队。querier 通过流式 gRPC连接链接到 query frontend,以处理这些分片查询。

存完了咋么取?-> HTTP 接口查

Querier

Querier 负责在 ingester 或后端存储中查找请求的 trace id。根据参数,它将查询 ingester, 并从后端提取布隆过滤器/索引来搜索对象存储中的块。

Querier 通过 HTTP 接口获取数据:GET /querier/api/traces/,但不建议直接使用该端点。

应该将查询结果发送到查询前端。

Compator

Compator(压缩器) 在后端存储和 ingester 之间流式传输块,以减少总块数。

Metrics generator

ator

Compator(压缩器) 在后端存储和 ingester 之间流式传输块,以减少总块数。

Metrics generator

这是一个可选组件,从 ingester 的 traces 数据中派生度量指标,并将其写入度量指标存储(一般需要 prometheus 配合)。

你可能感兴趣的:(Go,微服务,golang,grafana,可观测性,tempo,trace)