前言
Skywalking作为一个优秀的国产开源APM监控框架,前面已经有三篇文章,介绍过了Java服务、Python服务如何接入Skywalking,以及如何适配容器化部署场景。今天就来说一说我们费尽心思的把服务正常接入之后,如何利用收集到的指标为我们解决问题,因为打开Skywalking的仪表盘有点像第一次来北京南站时的地标,乍一看花花世界迷人眼,一时之间不知道该干啥。
先把之前的文章链一下,有不熟悉的jym可以回顾一下
- 【SkyWalking】Java服务从零接入全链路追踪解决方案
- 【SkyWalking】Python服务从零接入全链路追踪解决方案
- 【Skywalking】Docker容器化部署灵活开关Skywalking监控
问题排查步骤
先从我个人工作中遇到的情况,最常遇到的都是些服务整体慢的问题,这时候就需要首先分析出在哪一个阶段慢。
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数据实例