在skywalking上查看我的flask商品中心链路

990次阅读
没有评论

共计 2017 个字符,预计需要花费 6 分钟才能阅读完成。

在skywalking上查看我的flask商品中心链路

背景

随着博主这边折腾的服务越来越多,服务之间接口相互调用,A-》B-》C又或者是A-》(B,C)等,此时作为运维的博主来说,排查每个服务的请求的指标是相当繁琐的(在没做tracer的情况下),因为一个请求经过太多服务协调处理,所以博主在排查长尾接口时得一层一层抓包和测试….

面对这种复杂的调用链路,急需一款链路追踪工具自动帮我们去追踪每一次的调用链:

  • 请求链路追踪
  • 可视化链路阶段耗时,接口捕获进行性能分析
  • 可视化服务依赖关系
  • 其他服务监控指标(耗时,错误率,QPS,TPS等)

在2021年初时,博主当时是使用阿里的arms去监控服务中的调用链路,对于资金充足的企业来说,该产品是个不错的选择。以下是arms的一些截图

在skywalking上查看我的flask商品中心链路
在skywalking上查看我的flask商品中心链路
在skywalking上查看我的flask商品中心链路

如果想要自建,也有很多开源方案,如: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界面看到一个普通服务

在skywalking上查看我的flask商品中心链路

点进这个普通服务后可以看到该服务的一些指标信息

在skywalking上查看我的flask商品中心链路
  • 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缓存时的链路

此处是以列表的形式展示,右侧一个类似瀑布流的时序图显示了接口中数据库步骤调用耗时

在skywalking上查看我的flask商品中心链路

也可以换成表格的形式去查看

在skywalking上查看我的flask商品中心链路

首次请求会初始化数据库连接(所以你会看到上面有很多层mysql操作),再之后便是从mysql中获取数据,将数据缓存到redis中

再次调用获取商品列表接口,此时的链路还会比第一次调用少,是因为少了一些数据库的初始化连接(因为连接keepalive,不会每次都重建立连接)。从下面可以看到商品总页数是查的mysql,因为博主没有把这个缓存。而商品列表数据则是从redis中获取

在skywalking上查看我的flask商品中心链路
在skywalking上查看我的flask商品中心链路
在skywalking上查看我的flask商品中心链路

trace Profiling

如果在运维过程中,上面的链路调用(一般都是查看长尾链路)中分析不出耗时耗再哪里,比如其中某一层时间跨度大,但是服务间的调用很快,此时就有可能是方法栈内执行了一些耗时久的数据处理操作,此时就可以使用trace profiling来定位

创建trace profiling任务

在skywalking上查看我的flask商品中心链路

之后选取一个接口进行profiling,此时就可以看到对应的代码堆栈执行情况

在skywalking上查看我的flask商品中心链路

注意:每个服务,相同时间只能添加一个任务,且添加的任务不能更改也不能删除,只能等待过期后自动删除

查看每个服务间的拓扑

直接点击服务中topology即可查看该服务调用拓扑关系。什么时候会用到拓扑呢?博主在之前接手电商微服务运维时,便是从拓扑中摸清链接关系,开发团队太大,各自中心负责各自的服务,别人没有必要向你汇报~~~,另外一个场景就是遇到有些数据库类产品需要升级,期间会闪断,业务需要做好自动重连机制,这时就需要们去排哪个服务用到这个库了然后做好人员通知

在skywalking上查看我的flask商品中心链路

后面博主增加了bff层和inventory-center,此时的拓扑如下

在skywalking上查看我的flask商品中心链路

此时的调用链:bff->product->inventory

在skywalking上查看我的flask商品中心链路

就目前而言博主的服务还是少的可怜的,在过往实际运维中,70+服务再加上各中心服务的中间件mq/redis/mysql等,拓扑就跟蛛网一样,你可能感到全局时看不清,局部时理不清┑( ̄Д  ̄)┍

正文完
 
xadocker
版权声明:本站原创文章,由 xadocker 2023-03-08发表,共计2017字。
转载说明:除特殊说明外本站文章皆由CC-4.0协议发布,转载请注明出处。
评论(没有评论)