共计 2017 个字符,预计需要花费 6 分钟才能阅读完成。
背景
随着博主这边折腾的服务越来越多,服务之间接口相互调用,A-》B-》C又或者是A-》(B,C)等,此时作为运维的博主来说,排查每个服务的请求的指标是相当繁琐的(在没做tracer的情况下),因为一个请求经过太多服务协调处理,所以博主在排查长尾接口时得一层一层抓包和测试….
面对这种复杂的调用链路,急需一款链路追踪工具自动帮我们去追踪每一次的调用链:
- 请求链路追踪
- 可视化链路阶段耗时,接口捕获进行性能分析
- 可视化服务依赖关系
- 其他服务监控指标(耗时,错误率,QPS,TPS等)
在2021年初时,博主当时是使用阿里的arms去监控服务中的调用链路,对于资金充足的企业来说,该产品是个不错的选择。以下是arms的一些截图
如果想要自建,也有很多开源方案,如:skywalking,ziklin,jaeger等。此篇文章不讲如何搭建,而是讲博主之前的flask商品服务如何接入到skywalking中。
flask服务接入skywalking
接入skywalking
要使用skywalking我们需要pip安装以下依赖包
pip3 install apache-skywalking
配置skywalking接入
# 引入skywalking
from skywalking import agent
from skywalking import config as sw_config
sw_config.init(agent_collector_backend_services='192.168.44.149:11800', agent_name='products-center', agent_instance_name='products-center-01')
# 启动agent
agent.start()
测试链路追踪
启动后我们可以去skywalking UI界面看到一个普通服务
点进这个普通服务后可以看到该服务的一些指标信息
- Service Apdex 数字:Apdex性能指标
- Service Apdex 折线图:一段时间的Apdex分数
- Service Avg Response Time:服务平均响应时间
- Service Response Time Percentile:百分比响应延时
- Successful Rate(%)数字:请求成功率
- Successful Rate(%)折线图:一段时间的请求成功率
- Service Load(CPM – calls per minute):每分钟调用数
- Service Load(CPM – calls per minute):一段时间的每分钟调用数
- Service Instances Load(CPM – calls per minute):每个实例每分钟请求数
- Slow Service Instance:每个服务实例平均延时topN
- Service Instance Successful Rate:服务实例的请求成功率 topN
首次调用获取商品列表接口,在没有redis缓存时的链路
此处是以列表的形式展示,右侧一个类似瀑布流的时序图显示了接口中数据库步骤调用耗时
也可以换成表格的形式去查看
首次请求会初始化数据库连接(所以你会看到上面有很多层mysql操作),再之后便是从mysql中获取数据,将数据缓存到redis中
再次调用获取商品列表接口,此时的链路还会比第一次调用少,是因为少了一些数据库的初始化连接(因为连接keepalive,不会每次都重建立连接)。从下面可以看到商品总页数是查的mysql,因为博主没有把这个缓存。而商品列表数据则是从redis中获取
trace Profiling
如果在运维过程中,上面的链路调用(一般都是查看长尾链路)中分析不出耗时耗再哪里,比如其中某一层时间跨度大,但是服务间的调用很快,此时就有可能是方法栈内执行了一些耗时久的数据处理操作,此时就可以使用trace profiling来定位
创建trace profiling任务
之后选取一个接口进行profiling,此时就可以看到对应的代码堆栈执行情况
注意:每个服务,相同时间只能添加一个任务,且添加的任务不能更改也不能删除,只能等待过期后自动删除
查看每个服务间的拓扑
直接点击服务中topology即可查看该服务调用拓扑关系。什么时候会用到拓扑呢?博主在之前接手电商微服务运维时,便是从拓扑中摸清链接关系,开发团队太大,各自中心负责各自的服务,别人没有必要向你汇报~~~,另外一个场景就是遇到有些数据库类产品需要升级,期间会闪断,业务需要做好自动重连机制,这时就需要们去排哪个服务用到这个库了然后做好人员通知
后面博主增加了bff层和inventory-center,此时的拓扑如下
此时的调用链:bff->product->inventory
就目前而言博主的服务还是少的可怜的,在过往实际运维中,70+服务再加上各中心服务的中间件mq/redis/mysql等,拓扑就跟蛛网一样,你可能感到全局时看不清,局部时理不清┑( ̄Д  ̄)┍