基于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数据实例

相关推荐
2401_8543910814 分钟前
城镇住房保障:SpringBoot系统功能概览
java·spring boot·后端
陈随易19 分钟前
兔小巢收费引发的论坛调研Node和Deno有感
前端·后端·程序员
聪明的墨菲特i24 分钟前
Django前后端分离基本流程
后端·python·django·web3
hlsd#1 小时前
go mod 依赖管理
开发语言·后端·golang
陈大爷(有低保)1 小时前
三层架构和MVC以及它们的融合
后端·mvc
亦世凡华、1 小时前
【启程Golang之旅】从零开始构建可扩展的微服务架构
开发语言·经验分享·后端·golang
河西石头1 小时前
一步一步从asp.net core mvc中访问asp.net core WebApi
后端·asp.net·mvc·.net core访问api·httpclient的使用
2401_857439691 小时前
SpringBoot框架在资产管理中的应用
java·spring boot·后端
怀旧6661 小时前
spring boot 项目配置https服务
java·spring boot·后端·学习·个人开发·1024程序员节
阿华的代码王国2 小时前
【SpringMVC】——Cookie和Session机制
java·后端·spring·cookie·session·会话