Tempo - 分布式Loki链路追踪利器

云原生实验室

共 4531字,需浏览 10分钟

 ·

2020-11-28 14:15


更多奇技淫巧欢迎订阅博客:https://fuckcloudnative.io

前言

Tempo是Grafana Labs在ObservabilityCON 2020大会上新开源的一个用于做分布式式追踪的后端服务。它和Cortex、Loki一样,Tempo也是一个兼备高扩展低成本效应的系统。

之前小白有提到Grafana Labs的云原生Observability宇宙只剩下trace部分,那么今天就拿Loki的分布式追踪来体验下这Observability的最后一环吧。正式开始前,先看下小白精心准备的Tempo体验视频吧。

关于Tempo

Tempo本质上来说还是一个存储系统,它兼容一些开源的trace协议(包含Jaeger、Zipkin和OpenCensus等),将他们存在廉价的S3存储中,并利用TraceID与其他监控系统(比如Loki、Prometheus)进行协同工作。

可以看到Tempo的架构仍然分为distributoringesterqueriertempo-querycompactor这几个架构,熟悉Loki和Cortex的朋友可能光看名字就知道他们大概是做什么的。不熟悉的同学也没关系,下面简单说下各模块的作用:

  • distributor

监听多个端口,分别接受来自Jaeger、Zipkin和OpenCensus协议的数据,按照TraceID进行哈希并映射到哈希环上,并交由ingester进行存储处理。当前distributor支持的trace协议如下:

ProtocolPort
OpenTelemetry55680
Jaeger - Thrift Compact6831
Jaeger - Thrift Binary6832
Jaeger - Thrift HTTP14268
Jaeger - GRPC14250
Zipkin9411
  • ingester

具体负责trace数据的块存储(memcache、GCS、S3)、缓存(Memcache)和索引的处理

  • querier

负责从ingester和后端存储里面捞取trace数据,并提供api给查询者

  • compactor

负责后端存储块的压缩,减少数据块数量

  • tempo-query

tempo的一个可视化界面,用的jaeger query,可以在上面查询tempo的trace数据。

Loki链路跟踪

要体验的同学,可以先下载小白在GitHub上的Docker-Compose,推荐配合本篇内容一起实践
https://github.com/CloudXiaobai/loki-cluster-deploy/tree/master/demo/docker-compose-with-tempo

Loki方面

在做之前我们先看下Loki的文档是怎么描述的:

The tracing_config block configures tracing for Jaeger. Currently limited to disable auto-configuration per environment variables only.

可以看到当前Loki对于Trace的支持集中在Jaeger,而且配置是默认开启的,并且只能在环境变量里面读取jaeger的信息。docker-compose下的案例如下:

querier-frontend:
image: grafana/loki:1.6.1
runtime: runc
scale: 2
environment:
- JAEGER_AGENT_HOST=tempo \\tempo的地址
- JAEGER_ENDPOINT=http://tempo:14268/api/traces
- JAEGER_SAMPLER_TYPE=const \\采样率类型
- JAEGER_SAMPLER_PARAM=100 \\采样率100

API网关方面

API网关并不是Loki的原生组件,而是在Loki分布式部署的情况下,需要有一个统一的入口对Loki API进行路由。之前小白用的Nginx,但是原生的Nginx并不支持OpenTracing。小白根据nginx1.14版本做了一个带jaeger模块的镜像用于Loki入口的trace生成和日志采集。

gateway:
image: quay.io/cloudxiaobai/nginx-jaeger:1.14.0
runtime: runc
restart: always
ports:
- 3100:3100
volumes:
- ./nginx.conf:/etc/nginx/nginx.conf
- ./jaeger-config.json:/etc/jaeger-config.json
- 'gateway_trace_log:/var/log/nginx/'

对于支持OpenTracing的Nginx,我们需要修改nginx.conf配置文件如下:

...
#加载opentracing库
load_module modules/ngx_http_opentracing_module.so;
http {

#启用opentracing
opentracing on;

#加载jaeger库
opentracing_load_tracer /usr/local/lib/libjaegertracing_plugin.so /etc/jaeger-config.json;

#日志格式,打印traceid
log_format opentracing '"traceID":"$opentracing_context_uber_trace_id"';

server {
listen 3100 default_server;
location = / {
#向upstream转发时带上trace的头信息
opentracing_operation_name $uri;
opentracing_trace_locations off;
opentracing_propagate_context;
proxy_pass http://querier:3100/ready;
}
}
}

以上小白只截取了Nginx部分配置,完整的要参考docker-compose里的nginx.conf

此外,nginx还需要一个jaeger-config.json,用于将trace数据转给agent处理。

{
"service_name": "gateway", \\服务名
"diabled": false,
"reporter": {
"logSpans": true,
"localAgentHostPort": "jaeger-agent:6831" \\jaeger-agent地址
},
"sampler": {
"type": "const",
"param": "100" \\采样率
}
}

为了方便演示,小白配置的采样率均为100%

最后,我们为API网关启用一个Jaeger-agent用于收集trace信息并转给Tempo,它的配置如下:

jaeger-agent:
image: jaegertracing/jaeger-agent:1.20
runtime: runc
restart: always
# 转发给tempo
command: ["--reporter.grpc.host-port=tempo:14250"]
ports:
- "5775:5775/udp"
- "6831:6831/udp"
- "6832:6832/udp"
- "5778:5778"

为什么API网关不直接发给Tempo要经过Jaeger-agent转发一下,小白认为用agent的方式更加灵活一些。

以上,我们就完成了Loki分布式追踪的配置部分,接下来我们用docker-compose up -d将服务都运行起来。

Grafana方面

当docker的所有服务运行正常后,我们访问grafana并添加两个数据源

  • 添加tempo数据源

  • 添加Loki数据源,并解析API网关TraceID

Loki提取TraceID的正则部分是从API网关的日志中匹配

体验Tempo

数据源设置OK后,我们进入Explore选择loki查询trace.log就可以得到API网关的日志了。

从Parsed Fields里面我们就可以看到,Grafana从API网关的日志里面提取了16位字符串作为TraceID了,而它关联了Tempo的数据源,我们点击Tempo按钮就可以直接切到Trace的信息如下:


展开Trace信息,我们可以看到Loki的一次查询的链路会经过下面几个部分


gateway -> query-frontend -> querier -> ingester
|-> SeriesStore.GetChunkRefs

并且得出结论,本次查询的耗时主要落在Ingeter上,原因是查询的日志还没被flush到存储当中,querier需从ingester中取日志的数据。

我们再来看一个Loki接收日志的案例:

从trace的链路来看,当日志采集端往Loki Post日志时,请求的链路会经过如下部分:

gateway -> distributor -> ingester

同时,我们还看到了这次的提交的日志流经过两个ingester实例的处理,且处理时间没有明显差异。

总结

关于LoggingTracing两部分在Grafana上的展示还没有达到ObservabilityCON 2020上的流畅度,不过根据会上的消息,更精细话的trace <--> logmetrics <--> tracemetrics <--> log这三部分互相协作部分应该很快会发布。届时Grafana将是云上可观测性应用系统里的王者级产品(虽然有额外的各种查询语句学习成本)


你可能还喜欢

点击下方图片即可阅读

Pod 一直停留在 Terminating 状态,我等得花儿都谢了~

云原生是一种信仰 ?



码关注公众号

后台回复◉k8s◉获取史上最方便快捷的 Kubernetes 高可用部署工具,只需一条命令,连 ssh 都不需要!



点击 "阅读原文" 获取更好的阅读体验!

❤️给个「在看」,是对我最大的支持❤️
浏览 51
点赞
评论
收藏
分享

手机扫一扫分享

分享
举报
评论
图片
表情
推荐
点赞
评论
收藏
分享

手机扫一扫分享

分享
举报