这篇文章主要讲述,jaeger的使用方法,以及常用的显示含义

首页

Lookup by Trace ID

该搜索框的使用方式需要配置日志采集系统使用,比如说日志采集系统采集到了日志,如果是错误日志,找到Trace ID.到jaeger中进行搜索,就可以快速定位那里出现了错误.从而快速解决问题

Search

Service

通过服务名进行筛选

Operation

Service下的操作,例入请求 方法名等

Tags

请求失败,成功 ,url port 等方式进行过滤,具体支持过滤方式请看下面连接

https://github.com/opentracing/specification/blob/master/semantic_conventions.md

Lookback

时间过滤

Min Duraton Max Duration

最小最大请求持续时间,可以通过该条件,找到用时长和用时短的请求

Limit Result

显示的个数

搜索结果

可以通过上述条件进行搜索,有符合条件的就会初见在右半部分.

![在这里插入图片描述](https://img-blog.csdnimg.cn/20200701164541104.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxcTEyNTUzNjAzOQ==,size_16,color_FFFFFF,t_70
接下来看搜索出来的结果

1. 左上角标识 名字为consumer服务的 consumer 方法名为consumer的接口 Trace ID的前半部分
2. 右上角整个请求的持续时间
3. 5 Span 表示经过了5 次操作 看中间每个服务分别操作的次数
4. 左上角的方块,使用者可以选择多个,之后使用Compare进行比较.比如在微服务的场景中,同样的业务逻辑可能用时却不一样.这时可以选取两个进行比较,比较后可以很容易知道哪个环节出了问题

视图

jaeger提供了四种试图,分别为Trace Timeline 、 Trace Graph 、 Trace JSON

Trace Timeline

以时间为主线进行分析,方便使用者观看在某个时间点观看程序信息,它是所有试图里最直观切详细的

1. Duration 总用时
2. Service 3 总共用到了三个服务
3. Depth 5 发生了5次调用
4. Total Spans 5 这个调用由5个Span组成
5. find 页面展示的数据由json组成,可以通过json里的数据快速定位
6. 进入详情先看左半部分,展示了整个请求的调用链,黑色代表服务,灰色小子代表方法名 ,以及Feign调用发送Get请求
7. 右半部分代码调用的持续时间,需要注意的是,它代表的是由当前Span触发整个调用链的耗时,而不是它自己的用时

详细信息

点击时间条可以看到一下信息

1. Tags 包含了一系列的信息,通过上图可以知道 该请求是web请求 请求方式 以及请求结果 还有url 等等 ,它包含的所有信息,都可以通过首页的Tags进行过滤
2. Process 可以通过该数据定位具体是哪个服务器
3. Logs 在这个时间的日志信息

Trace Graph

该试图可以更加直观的看到整个调用链,同时知道每个Span 具体用时 ,以及百分比供使用者参考.

consumer 服务的consumer接口收到web请求,完了consumer发起feign调用 为get请求,请求了provide服务,方法名为provide的接口

1. 左侧 14.175 表示整个调用所用的时间
2. 右侧代表,在整个用时14.18的请求中,自用4.825 .占整个请求用时的百分之34.
3. 整个调用连的左半部分加起来等于总用时 也就是14.18

通过这个视图使用者很容易知道系统瓶颈,快速定位问题.

Trace JSON

原始JSON数据

Compare

上图所展示的是同一个业务逻辑的四次请求,但是可以看到它们的用时差距很大,在微服务的场景下出现这种情况是很常见的事情,很可能是因为,在多个服务中某一台服务出现了问题.这个时候可以通过这种方式快速定位到底是哪个服务器.

Dependencies

展示整个系统的链路调用情况,需要注意的是生产环境下需要使用Spark Dependencies进行分析才能展示

Force Dircted Graph

宏观的展示整个系统的链路调用

DAG

显示服务调用链,以及调用次数

总结

Jaeger相对与Zipkin更好的以及更详细的展现的整个系统的运行情况,同时更方便使用者进行系统的分析