基于Skywalking-UI指标问题排查指南

前言

Skywalking作为一个优秀的国产开源APM监控框架,前面已经有三篇文章,介绍过了Java服务、Python服务如何接入Skywalking,以及如何适配容器化部署场景。今天就来说一说我们费尽心思的把服务正常接入之后,如何利用收集到的指标为我们解决问题,因为打开Skywalking的仪表盘有点像第一次来北京南站时的地标,乍一看花花世界迷人眼,一时之间不知道该干啥。

先把之前的文章链一下,有不熟悉的jym可以回顾一下

问题排查步骤

先从我个人工作中遇到的情况,最常遇到的都是些服务整体慢的问题,这时候就需要首先分析出在哪一个阶段慢。

APM#Global

首先访问Skywalking-UI点APM进入Global界面,这里有几个很重要的指标方便判断。

  1. Services load,表示系统当前的负载情况,当前应用每分钟接收的请求数量。如果Services load列看到有应用的请求数量远远高出了其负载能力,就可以直接下结论是应用负载导致的问题,此时就应该考虑扩展应用去分散请求。
  2. Slow Services,表示当前系统中出现的慢服务,通过计算服务接口的平均响应时间统计得出。如果系统熔断做的好的话可以通过观察此指标缩小排查服务的范围。
  3. Slow Endpoint,这个指标是统计了当前系统中的慢接口,数值代表了消耗的时间,单位默认为毫秒。通过该指标可以判断系统重是否出现接口层的性能瓶颈

我个人感觉这三个指标最有用,其余的一些指标比较鸡肋,看起来也不方便就暂不赘述。

APM#Service 维度

通过上一步的排查基本可以确定系统中的哪个具体service导致的系统响应慢,如果没能得出结论问题也不是很大,接下来可以从service模块寻找出蛛丝马迹,点到service是具体选中的某一个服务的具体指标,可以通过上方的下拉框切换。

  1. Service Avg Response Times,过了英语四级的都能直译过来,服务的平均响应时间,默认所有的指标都是以毫秒为单位。这个指标可以判断出当前服务是不是性能瓶颈。
  2. Service Load,折线图比较重要,含义与Global同名指标一样,折线图可以看出每分钟的请求数
  3. Servce Instances Load:如果是单实例部署的话这个指标跟Service Load一样,多实例部署的情况下是某个服务实例下的负载情况

看完这些基本确定哪个服务的哪个实例导致的服务慢,如果还不确定那就从头再看一遍。

APM#EndPoint维度

skywalking中的端点其实统计的就是真实的uri接口,如果上述的指标还不足以定罪某个服务慢的话,用Endpoint的指标则直接可以说是实锤了,这里只需要关注两个指标数据。

  1. Endpoint Load in Current Service:当前服务的接口每分钟请求数量
  2. Slow Endpoints in Current Service:当前服务的接口最慢请求时间

APM#Instance 维度

接下来开始排查原因,一般的原因要么是服务本身出了问题,要么是sql导致的性能问题。Instance模块主要通过定位服务自身的运行时相关指标是否出了问题。这模块应该是最重要的一项指标,可以通过UI页面看出服务JVM的运行情况。可以排查一些gc导致的CPU或者内存问题

  1. Service Instance Load,当前服务当前实例下的负载情况
  2. Service Instance Latency,当前服务当前实例下的响应延时
  3. JVM CPU,当前服务当前实例下jvm占用CPU的百分比
  4. JVM Memory,当前服务当前实例下JVM内存大小,单位MB
  5. JVM GC Time,当前服务当前实例下JVM垃圾回收时间,整体GC时间不区分YGC和OGC
  6. JVM GC Count,当前服务当前实例下JVM垃圾回收次数,整体GC时间不区分YGC和OGC
  7. JVM Thread Count,当前服务当前实例下JVM线程数;

Database

提供了不同的数据库类型选项(Mysql, ElasticSearch,MongoDB...),然后显示不同数据库相关数据统计指标

  1. Slow Statements,慢sql统计,重中之重,可以直观看出慢sql的耗时
  2. Database Avg Response Time,数据库平均响应时间,判断是否db层是性能瓶颈
  3. All Database Loads(CPM - calls per minute),数据库负载情况,负载高了重启就完了,还有问题找运维

拓扑图

通过拓扑图可以查看服务基本情况,如果响应成功率小于95%则标为红色异常状态

性能剖析

agent端每隔20秒向服务端发起请求,来向服务端询问本agent是否有分析任务,如果接受到这个任务之后,就会在当前时间或者将来的某个时间开始监控操作。在服务端如果已经感知到agent端已经知道这个任务的时候,在profile页面的任务详情中,点开任务详情的页面,在弹出框的下方会展示一条日志:包括:实例信息、操作类型、操作时间等。

这块我还没整明白所以先不分享了。

告警WebHook推送

还可以通过配置告警来处理一些可靠性比较高的场景。

告警配置: /apache-skywalking-apm-bin-es7/config/alarm-settings.yml

内置报警规则

rules内置了报警规则,新建规则名称需要_rule结尾

  1. 过去 3 分钟内服务平均响应时间超过 1 秒。
  2. 过去 2 分钟服务成功率低于80%。
  3. 过去 3 分钟内服务响应时间超过 1s 的百分比
  4. 服务实例在过去 2 分钟内平均响应时间超过 1s,并且实例名称与正则表达式匹配。
  5. 过去 2 分钟内端点平均响应时间超过 1 秒。
  6. 过去 2 分钟内数据库访问平均响应时间超过 1 秒。
  7. 过去 2 分钟内端点关系平均响应时间超过 1 秒。

配置规则

基本都可以根据模板创建,metrics-name要与内置脚本类型一致,各类功能可以根据内置规则对比。

webhook

SkyWalking的告警消息会通过 HTTP 请求进行发送,请求方法为 POST,Content-Type 为 application/json ,其JSON 数据实基于List<org.apache.skywalking.oap.server.core.alarm.AlarmMessage> 进行序列化的。

Json数据实例

相关推荐
张保瑞32 分钟前
十八:Spring Boot 依赖(3)-- spring-boot-starter-data-jpa 依赖详解
数据库·spring boot·后端
大叔是90后大叔2 小时前
go生成4位随机数字
开发语言·后端·golang
2401_857617622 小时前
共享汽车管理:SpringBoot框架的创新应用
spring boot·后端·汽车
mit6.8242 小时前
[Docker#3] LXC | 详解安装docker | docker的架构与生态
linux·运维·后端·docker·容器
2401_857439692 小时前
汽车共享管理:SpringBoot技术的应用与挑战
spring boot·后端·汽车
小菜日记^_^3 小时前
增删改查基础项目总结
java·数据库·spring boot·后端·spring·servlet·tomcat
说书客啊4 小时前
计算机毕业设计 | SpringBoot咖啡商城 购物采买平台 后台管理软件(附源码)
java·数据库·人工智能·spring boot·后端·毕业设计·课程设计
陈随易4 小时前
wangEditor,从开源、停更到重生
前端·后端·程序员
亚洲第一中锋_哈达迪4 小时前
漫谈分布式唯一ID
分布式·后端
小扳5 小时前
RabbitMQ 篇-深入了解延迟消息、MQ 可靠性(生产者可靠性、MQ 可靠性、消费者可靠性)
java·分布式·后端·spring·rabbitmq