原创 基于 Grafana LGTM 可观测平台的构建

原标题：基于 Grafana LGTM 可观测平台的构建

- K6 B$ @) |1 {$ V% W$ A# E

可观测性目前属于云原生一个比较火的话题，它涉及的内容较多，不仅涉及多种遥测数据（信号），例如日志（log）、指标(metric)、分布式追踪（trace）、连续分析(continuous profiling)、 事件（event）；还涉及遥测数据各生命周期管理，比如暴露、采集、存储、计算查询、统一看板。

目前社区相关开源产品较多，各有各的优势，今天我们就来看看如何使用 Grafana LGTM 技术栈（Grafana、Loki、Tempo、Mimir）快速构建一个自己的可观测性平台。

通过本文你将了解：

4 ~0 Y% t9 d# V3 i4 q$ j

如何在 Go 程序中导出 metric、trace、log、以及它们之间的关联 TraceID

如何使用 OTel Collector 进行 metric、trace 收集

7 u6 c: p9 h# s

如何使用 OTel Collector Contrib 进行日志收集

: G& C: p4 ?4 K, K0 g, ^* ~

如何部署 Grafana Mimir、Loki、Tempo 进行 metric、trace、log 数据存储

如何使用 Grafana 制作统一可观测性大盘

为了本次的教学内容，我们提前编写了一个 Go Web 程序，它提供 /v1/books 和 /v1/books/1 两个 HTTP 接口。

当请求接口时，会先访问 Redis 缓存，如果未命中将继续访问 MySQL；整个请求会详细记录相关日志、整个链路各阶段调用情况以及整体请求延迟，当请求延迟 >200ms 时，会通过 Prometheus examplar 记录本次请求的 TraceID，用于该请求的日志、调用链关联。

4 I8 B% x. o9 v0 Y# ~. ~/ Y

下载并体验样例

& n& ?9 k5 |% J; E6 O0 d q

我们已经提前将样例程序上传到 github，所以您可以使用 git 进行下载：

git clone https://github.com/grafanafans/prometheus-exemplar.git

: i; X/ C0 W0 ~" ?" I

cd prometheus-exemplar

- T' f. x/ P" f D: p, ~9 k/ P

使用 docker-compose 启动样例程序:

docker-compose up -d

这个命令会启动以下程序：

使用单节点模式分别启动一个 Mimir、Loki、Tempo

启动一个 Nginx 作为统一可观测平台查询入口，后端对接 Mimir、Loki、Tempo

1 {% X( m9 P2 H( g1 s) v G, L

启动 demo app, 并启动其依赖的 MySQL 和 Redis， demo app 可以使用 http://localhost:8080 访问

启动 Grafana 并导入预设的数据源和 demo app 统一看板，可以使用 http://localhost:3000 访问

整个部署架构如下：

# }( j' v/ F, C, @0 i8 @* k' f

, H/ H$ F1 a3 t. F8 Y

当程序部署完成后，我们可以使用 wrk 进行 demo app 接口批量请求：

3 C ^7 X3 H) h7 f* Q( R( U$ f3 o) O0 r

wrk http://localhost:8080/v1/books

wrk http://localhost:8080/v1/books/1

/ k9 Q7 m* ^& P9 j% D) _, H3 u

最后通过 http://localhost:3000 页面访问对应的看板：

细节说明

& C: m6 q2 I: T5 h3 j' ^/ i

使用 Promethues Go SDK 导出 metrics

在 demo app 中，我们使用 Prometheus Go SDK 作为 metrics 导出，这里没有使用 OpenTelmetry SDK 主要因为当前版本（v0.33.0）还不支持 exemplar， 代码逻辑大致为：

func Metrics(metricPath string, urlMapping func(string) string) gin.HandlerFunc <{p> httpDurationsHistogram := prometheus.NewHistogramVec(prometheus.HistogramOpts<{p> Name: "http_durations_histogram_seconds",

0 E$ g3 I M, E) K, x# q% E( p

Help: "Http latency distributions.",

% I2 E: m1 ^" Q+ \

Buckets: []float64{0.05, 0.1, 0.25, 0.5, 1, 2},

}, []string{"method", "path", "code"})

$ H3 O0 @- V# h; V+ ^

prometheus.MustRegister(httpDurationsHistogram)

. w" e) a! j# \; z, `2 f: }

return func(c *gin.Context) <{p> .....

observer := httpDurationsHistogram.WithLabelValues(method, url, status)

$ @" q, S/ f7 z5 x

observer.Observe(elapsed)

2 ]0 ]" Z0 B; {/ X! O* W4 S

if elapsed > 0.2 <{p> observer.(prometheus.ExemplarObserver).ObserveWithExemplar(elapsed, prometheus.Labels<{p> "traceID": c.GetHeader(api.XRequestID),

})

}

}

}

% F0 X8 K# v! R. R0 i

使用 OTLP HTTP 导出 traces

2 P0 O! R: @# a, c; w

使用 OTel SDK 进行 trace 埋点：

func (*MysqlBookService) Show(id string, ctx context.Context) (item *Book, err error) <{p> _, span := otel.Tracer().Start(ctx, "MysqlBookService.Show")

span.SetAttributes(attribute.String("id", id))

defer span.End()

// mysql qury random time duration

% Z3 N, M/ o a. t( g8 K

time.Sleep(time.Duration(rand.Intn(250)) * time.Millisecond)

err = db.Where(Book{Id: id}).Find(&item).Error

6 L _- D: \# `; V- X+ b+ R3 O

return

( R, w. L( |( W8 v- s9 e" h6 j1 j# P

}

7 W- @5 K0 z$ ?) B

使用 OLTP HTTP 进行导出：

func SetTracerProvider(name, environment, endpoint string) error <{p> serviceName = name

client := otlptracehttp.NewClient(

otlptracehttp.WithEndpoint(endpoint),

' h- m2 r" r& s# |4 @) q

otlptracehttp.WithInsecure(),

4 c' e8 {. a, o" W) i; s

)

4 F8 I; w1 U }! o# E

exp, err := otlptrace.New(context.Background(), client)

) E4 J! j v/ Z$ l% D

if err != nil <{p> return err

}

' ~, M. o$ y+ u

tp := tracesdk.NewTracerProvider(

tracesdk.WithBatcher(exp),

tracesdk.WithResource(resource.NewWithAttributes(

semconv.SchemaURL,

. R7 Q8 S0 h9 J6 B6 }

semconv.ServiceNameKey.String(serviceName),

attribute.String("environment", environment),

* g! N2 i: @4 y! m$ {# [& f

)),

)

# s/ n* ]6 \2 T: e& G7 X9 Y) o

otel.SetTracerProvider(tp)

return nil

}

0 |. g4 U2 J" j# H6 |+ M

结构化日志

! ~4 w \; m# S) c9 p' W# Y% A

这里我们使用 go.uber.org/zap 包进行结构化日志输出，并输出到 /var/log/app.log 文件，每个请求开始时，注入 traceID：

" w. r8 A2 ?# p$ n' T$ b' q/ |

cfg := zap.NewProductionConfig()

cfg.OutputPaths = []string{"stderr", "/var/log/app.log"}

7 S5 E) B) F7 c) D

logger, _ := cfg.Build()

4 m2 p: v( _6 p/ t5 ]' }

logger.With(zap.String("traceID", ctx.GetHeader(XRequestID)))

使用 OTel Collector 进行 metric、trace 收集

- E4 c; W3 s+ E% Y

因为 demo app 的 metrics 使用 Prometheus SDK 导出，所以 OTel Collector 需要使用 Prometheus recevier 进行抓取，然后我们再通过 Prometheus remotewrite 将数据 push 到 Mimir。

针对 traces，demo app 使用 OTLP HTTP 进行了导出，所有 Collector 需要用 OTP HTTP recevier 进行接收，最后再使用 OTLP gRPC 将数据 push 到 Tempo，对应配置如下：

- y" x: w# K" J8 d* D! e a8 j

receivers:

+ y* @: o: _6 N9 {" j

otlp:

protocols:

grpc:

http:

prometheus:

config:

scrape_configs:

- job_name: app

$ y, K( \, Q) ^. |

scrape_interval: 10s

. T! d i1 ^% z& {0 r( W+ w

static_configs:

- targets: [app:8080]

exporters:

2 ?' F1 T- i% Y! {

otlp:

5 c: e$ s2 y8 w+ s

endpoint: tempo:4317

/ _6 {: d1 T6 `4 o

tls:

insecure: true

prometheusremotewrite:

endpoint: http://mimir:8080/api/v1/push

, {; k( v _$ V! W* S

tls:

- m" G* \6 `& D) A! j0 Y

insecure: true

7 S& K. j4 f( P, o7 f, Y( m

headers:

5 U$ Z5 f" n% [/ m9 @+ O1 ?; W

X-Scope-OrgID: demo

processors:

0 W @& F* |$ d1 k1 ^9 k9 m( b. v

batch:

: m# o3 Q+ F5 i3 m& q

service:

9 v7 {# M3 y" P! `# z

pipelines:

traces:

- Y1 T8 T$ M$ v, n

receivers: [otlp]

processors: [batch]

9 d/ x4 f4 {; k" d- t7 {% v' s2 D

exporters: [otlp]

metrics:

receivers: [prometheus]

; j6 d" _/ t# q/ s" B* I' B

processors: [batch]

/ c( f* l3 N- a% X: K9 D9 L8 z

exporters: [prometheusremotewrite]

使用 OTel Collector Contrib 进行 log 收集

因为我们结构化日志输出到了/var/log/app.log 文件，所以这里使用 filelog receiver 进行最新日志读取，最后再经过loki exporter 进行导出，配置如下：

receivers:

H- N {6 e% A- w2 A) q

filelog:

: K+ N7 s* u# _/ S) U% X

include: [/var/log/app.log]

exporters:

1 R2 B/ m& d: A R% t+ V

loki:

! z( {1 { A- z( G

endpoint: http://loki:3100/loki/api/v1/push

* S3 D7 p% {5 \) K" u( q

tenant_id: demo

labels:

attributes:

log.file.name: "filename"

processors:

batch:

! Z) [$ ^$ u( ?$ K5 S0 I4 A

service:

6 g4 c/ A. J5 |: Q$ f! _! V9 X

pipelines:

logs:

8 m6 R! ^( ~) Y

receivers: [filelog]

$ k+ [+ |( k" I

processors: [batch]

exporters: [loki]

! @* O5 s- a8 c$ X9 `

以上就是有关 demo app 可观测性与 Grafana LGTM 技术栈集成的核心代码与配置，全部配置请参考 https://github.com/grafanafans/prometheus-exemplar 。

( C2 P4 a1 E$ K5 R9 y7 j0 K! z5 k- h

总结

本文我们通过一个简单的 Go 程序，导出了可观测性相关的遥测数据，其中包括 metrics、traces、logs, 然后统一由 OTel Collector 进行抓取，分别将三种遥测数据推送到 Grafana 的 Mimir、 Tempo、Loki 进行存储，最后再通过 Grafana 统一看板并进行 metrics、traces、logs 关联查询。

这里关联的逻辑为使用 Prometheus 的 exemplar 记录采样对应的 traceID，然后通过该 traceID 进行相关日志和 trace 查询。返回搜狐，查看更多

7 }9 H/ W7 k) m# W

责任编辑：

+ Z& u+ f3 ?# s1 O ( t/ M, X' ^/ i) q' I2 { ! X F: C* e9 j0 y" Q; _ . A# N5 J2 Q, [4 x+ z/ V 6 `6 f5 Q: w: _) b