Skywalking微服务监控分析

转载本文需注明出处：EAWorld，违者必究。

引言：

微服务框架落地后，分布式部署架构带来的问题就会迅速凸显出来。服务之间的相互调用过程当中，若是业务出现错误或者异常，如何快速定位问题？如何跟踪业务调用链路？如何分析解决业务瓶颈？...本文咱们来看看如何解决以上问题。

目录：

1、SkyWalking初探
2、业务调用链路监控
3、服务性能指标监控
4、服务告警

1、SkyWalking初探

Skywalking 简介

Skywalking是一款国内开源的应用性能监控工具，支持对分布式系统的监控、跟踪和诊断。

它提供了以下的主要功能特性：

Skywalking 技术架构

SW整体能够分为四部分：

1.Skywalking Agent：使用Javaagent作字节码植入，无侵入式的收集，并经过HTTP或者gRPC方式发送数据到Skywalking Collector。

2. Skywalking Collector ：链路数据收集器，对agent传过来的数据进行整合分析处理并落入相关的数据存储中。

3. Storage：Skywalking的存储，时间更迭，sw已经开发迭代到了6.x版本，在6.x版本中支持以ElasticSearch、Mysql、TiDB、H二、做为存储介质进行数据存储。

4. UI ：Web可视化平台，用来展现落地的数据。

Skywalking Agent配置

经过了解配置，能够对一个组件功能有一个大体的了解。让咱们一块儿看一下skywalking的相关配置。

解压开skywalking的压缩包，在agent/config文件夹中能够看到agent的配置文件。

从skywalking支持环境变量配置加载，在启动的时候优先读取环境变量中的相关配置。



agent.namespace: 跨进程链路中的header，不一样的namespace会致使跨进程的链路中断
agent.service_name:一个服务（项目）的惟一标识，这个字段决定了在sw的UI上的关于service的展现名称
agent.sample_n_per_3_secs: 客户端采样率，默认是-1表明全采样
agent.authentication: 与collector进行通讯的安全认证，须要同collector中配置相同
agent.ignore_suffix: 忽略特定请求后缀的trace
collecttor.backend_service: agent须要同collector进行数据传输的IP和端口
logging.level: agent记录日志级别

skywalking agent使用javaagent无侵入式的配合collector实现对分布式系统的追踪和相关数据的上下文传递。

Skywalking Collector关键配置

Collector支持集群部署，zookeeper、kubernetes（若是你的应用是部署在容器中的）、consul（GO语言开发的服务发现工具）是sw可选的集群管理工具，结合你们具体的部署方式进行选择。详细配置你们能够去Skywalking官网下载介质包进行了解。

Collector端口设置



downsampling: 采样汇总统计维度，会分别按照分钟、【小时、天、月】（可选）来统计各项指标数据。
经过设置TTL相关配置项能够对数据进行自动清理。

Skywalking 在6.X中简化了配置。collector提供了gRPC和HTTP两种通讯方式。

UI使用rest http通讯，agent在大多数场景下使用grpc方式通讯，在语言不支持的状况下会使用http通讯。

关于绑定IP和端口须要注意的一点是，经过绑定IP，agent和collector必须配置对应ip才能够正常通讯。

Collector存储配置

在application.yml中配置的storage模块配置中选择要使用的数据库类型，并填写相关的配置信息。



Collector Receiver

Receiver是Skywalking在6.x提出的新的概念，负责从被监控的系统中接受指标数据。用户彻底能够参照OpenTracing规范来上传自定义的监控数据。Skywalking官方提供了service-mesh、istio、zipkin的相关能力。



如今Skywalking支持服务端采样，配置项为sampleRate，比例采样，若是配置为5000则采样率就是50%。

关于采样设置的一点注意事项

关于服务采样配置的一点建议，若是Collector以集群方式部署，好比：Acollector和Bcollector，建议Acollector.sampleRate = Bcollector.sampleRate。若是采样率设置不相同可能会出现数据丢失问题。



假设Agent端将全部数据发送到后端Collector处，A采样率设置为30%，B采样率为50%。

假设有30%的数据，发送到A上，这些数据被所有正确接受并存储，极端状况（与指望的采样数据量相同）下，若是剩下20%待采样的数据发送到了B，这个时候一切都是正常的，若是这20%中有一部分数据被送到了A那么，这些数据将是被忽略的，由此就会形成数据丢失。

2、业务调用链路监控

Service Topology监控

调用链路监控能够从两个角度去看待。咱们先从总体上来认识一下咱们所监控的系统。

经过给服务添加探针并产生实际的调用以后，咱们能够经过Skywalking的前端UI查看服务之间的调用关系。

咱们简单模拟一次服务之间的调用。新建两个服务，service-provider以及service-consumer，服务之间简单的经过Feign Client 来模拟远程调用。



从图中能够看到:

有两个服务节点：provider & consumer
有一个数据库节点：localhost【mysql】
一个注册中心节点

consumer消费了provider提供出来的接口。

一个系统的拓扑图让咱们清晰的认识到系统之间的应用的依赖关系以及当前状态下的业务流转流程。细心的可能发现图示节点consumer上有一部分是红色的，红色是什么意思呢？

红色表明当前流经consumer节点的请求有一断时间内是响应异常的。当节点所有变红的时候证实服务现阶段内就完全不可用了。运维人员能够经过Topology迅速发现某一个服务潜在的问题，并进行下一步的排查并作到预防。

Skywalking Trace监控

Skywalking经过业务调用监控进行依赖分析，提供给咱们了服务之间的服务调用拓扑关系、以及针对每一个endpoint的trace记录。

咱们在以前看到consumer节点服务中发生了错误，让咱们一块儿来定位下错误是发生在了什么地方又是什么缘由呢？



在每一条trace的信息中均可以看到当前请求的时间、GloableId、以及请求被调用的时间。咱们分别看一看正确的调用和异常的调用。

Trace调用链路监控


图示展现的是一次正常的响应，这条响应总耗时19ms，它有4个span：

span1 /getStore = 19ms  响应的总流转时间
span2 /demo2/stores = 14ms  feign client 开始调用远程服务后的响应的总时间
span3 /stores = 14ms 接口服务响应总时间
span4 Mysql = 1ms  服务提供端查询数据库的时间

这里span2和span3的时间表现相同，实际上是不一样的，由于这里时间取了整。

在每一个Span中能够查看当前Span的相关属性。

组件类型: SpringMVC、Feign 
Span状态: false
HttpMethod: GET
Url: http://192.168.16.125:10002/demo2/stores



这是一次正常的请求调用Trace日志，可能咱们并不关心正常的时候，毕竟一切正常不就是咱们期待的么！

咱们再来看下，异常状态下咱们的Trace以及Span又是什么样的呢。



发生错误的调用链中Span中的is error标识变为true，而且在名为Logs的TAB中能够看到错误发生的具体缘由。根据异常状况咱们就能够轻松定位到影响业务的具体缘由，从而快速定位问题，解决问题。

经过Log咱们看到链接被拒，那么多是咱们的网络出现了问题（可能性小，由于实际状况若是网络出现问题咱们连这个trace都看不到了），也有多是服务端配置问题没法正确创建链接。经过异常日志，咱们迅速就找到了问题的关键。

实际状况是，我把服务方停掉了，作了一次简单的模拟。可见，经过拓扑图示咱们能够清晰的看到众多服务中哪一个服务是出现了问题的，经过trace日志咱们能够很快就定位到问题所在，在最短的时间内解决问题。

3、服务性能指标监控 

Skywalking还能够查看具体Service的性能指标，根据相关的性能指标能够分析系统的瓶颈所在并提出优化方案。

Skywalking 性能监控

在服务调用拓扑图上点击相应的节点咱们能够看到该服务的

SLA: 服务可用性（主要是经过请求成功与失败次数来计算）
CPM: 每分钟调用次数
Avg Response Time: 平均响应时间



从应用总体外部来看咱们能够监测到应用在必定时间段内的

服务可用性指标SLA
每分钟平均响应数
平均响应时间
服务进程PID
服务所在物理机的IP、HostName、Operation System

Service JVM信息监控



还能够监控到Service运行时的CPU、堆内存、非堆内存使用率、以及GC状况。这些信息来源于JVM。注意这里的数据可不是机器自己的数据。

4、服务告警

前文咱们提到了经过查看拓扑图以及调用链路能够定位问题，但是运维人员又不可能一直盯着这些数据，那么咱们就须要告警能力，在异常达到必定阈值的时候主动的提示咱们去查看系统状态。

在Sywalking 6.x版本中新增了对服务状态的告警能力。它经过webhook的方式让咱们能够自定义咱们告警信息的通知方式。诸如:邮件通知、微信通知、短信通知等。

Skywalking 服务告警

先来看一下告警的规则配置。在alarm-settings.xml中能够配置告警规则，告警规则支持自定义。


一份告警配置由如下几部分组成：

service_resp_time_rule：告警规则名称 ***_rule （规则名称能够自定义可是必须以’_rule’结尾
indicator-name：指标数据名称： 定义参见http://t.cn/EGhfbmd
op: 操做符： > , < , = 【固然你能够本身扩展开发其余的操做符】
threshold：目标值：指标数据的目标数据 如sample中的1000就是服务响应时间，配合上操做符就是大于1000ms的服务响应
period: 告警检查周期：多久检查一次当前的指标数据是否符合告警规则
counts: 达到告警阈值的次数
silence-period：忽略相同告警信息的周期
message：告警信息
webhooks：服务告警通知服务地址

Skywalking经过HttpClient的方式远程调用在配置项webhooks中定义的告警通知服务地址。



了解了SW所传送的数据格式咱们就能够对告警信息进行接收处理，实现咱们须要的告警通知服务啦！

咱们将一个服务停掉，并将另一个服务的某个对外暴露的接口让他休眠必定的时间。而后调用必定的次数观察服务的状态信息以及告警状况。



总结：

本文简单的经过skwaylking的配置来对skywlaking的功能进行一次初步的了解，对skwaylking新提出的概念以及新功能进行简单的诠释，方便你们了解和使用。经过使用APM工具，可让咱们方便的查看微服务架构中系统瓶颈以及性能问题等。


关于做者：赵瑞栋，普元java工程师，从事Eclipse插件开发，参与普元EOS8 Platform开发，现主要参与EOS8微服务管理平台开发工做。 


 

关于EAWorld：微服务，DevOps，数据治理，移动架构原创技术分享。长按二维码关注！