前言

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

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

问题排查步骤

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

APM#Global

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

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

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

APM#Service 维度

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

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

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

APM#EndPoint维度

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

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

APM#Instance 维度

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

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

Database

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

Slow Statements，慢sql统计，重中之重，可以直观看出慢sql的耗时
Database Avg Response Time，数据库平均响应时间，判断是否db层是性能瓶颈
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结尾

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

配置规则

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

webhook

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

Json数据实例

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

前言