skywalking监控php,Skywalking微服务监控分析

二、业务调用链路监控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日志我们可以很快就定位到问题所在，在最短的时间内解决问题。三、服务性能指标监控

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

在服务调用拓扑图上点击相应的节点我们可以看到该服务的SLA: 服务可用性(主要是通过请求成功与失败次数来计算)

CPM: 每分钟调用次数

Avg Response Time: 平均响应时间

从应用整体外部来看我们可以监测到应用在一定时间段内的服务可用性指标SLA

每分钟平均响应数

平均响应时间

服务进程PID

服务所在物理机的IP、HostName、Operation SystemService JVM信息监控

还可以监控到Service运行时的CPU、堆内存、非堆内存使用率、以及GC情况。这些信息来源于JVM。注意这里的数据可不是机器本身的数据。四、服务告警

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

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

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

一份告警配置由以下几部分组成：service_resp_time_rule：告警规则名称 ***_rule (规则名称可以自定义但是必须以’_rule’结尾

indicator-name：指标数据名称： 定义参见

op: 操作符： > , < , = 【当然你可以自己扩展开发其他的操作符】

threshold：目标值：指标数据的目标数据 如sample中的1000就是服务响应时间，配合上操作符就是大于1000ms的服务响应

period: 告警检查周期：多久检查一次当前的指标数据是否符合告警规则

counts: 达到告警阈值的次数

silence-period：忽略相同告警信息的周期

message：告警信息

webhooks：服务告警通知服务地址

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

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

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

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