如何定位微服务异常之链路跟踪APM工具？

时间 2019-11-08

原文原文链接

前言

微服务框架落地后，分布式部署架构带来的问题就会迅速凸显出来。尤为线上出现问题，不知道如何排查，**问题出如今哪一个服务？如何快速定位问题？**如何跟踪业务调用链路？**如何分析解决业务瓶颈？**今天老顾来跟小伙伴们看看如何解决以上问题。前端

什么是链路追踪

微服务架构是经过业务来划分服务的，使用REST调用。对外暴露的一个接口，可能须要不少个服务协同才能完成这个接口功能，若是链路上任何一个服务出现问题或者网络超时，都会造成致使接口调用失败。随着业务的不断扩张，服务之间互相调用会愈来愈复杂。java

上图中，user调用A，A会调用C，C再调用E；这条调用链路，咱们还可以看清楚；可是一旦 微服务不少， 调用依赖复杂就看不清楚了，以下图

上图是否是看到后，有密集恐惧症，像个线团，一团乱麻；若是这个时候出现了调用异常，那咱们依据调用接口入口，一步步、一个服务一个服务的去跟踪调试；这个流程会把人搞疯的，也许1个小时后，也不知道什么问题；就像咱们之前找线头，而后一步步的去从新卷圈。mysql

面对以上状况，咱们就须要一些能够帮助理解系统行为、用于分析性能问题的工具，以便发生故障的时候，可以快速定位和解决问题，这就是所谓的 APM（应用性能管理）。web

什么是 SkyWalking

Skywalking是一款国内开源的应用性能监控工具，支持对分布式系统的监控、跟踪和诊断。目前主要的一些 APM 工具备: Cat、Zipkin、Pinpoint、SkyWalking。SkyWalking也是Apache的孵化项目之一，拥有顶级二级域名。它提供了以下的主要功能特性：sql

功能特性： * 多种监控手段， 语言探针和服务网格(Service Mesh) * 多语言自动探针，Java，.NET Core 和 Node.JS * 轻量高效，不须要大数据 * 模块化，UI、存储、集群管理多种机制可选 * 支持告警 * 优秀的 可视化方案

技术架构

上图看了是否是比较乱， 其实Skywalking整体能够分为四部分： 一、Skywalking Agent：使用Javaagent作字节码植入，无侵入式的收集，并 经过HTTP或者gRPC方式发送数据到 Skywalking Collector。 二、Skywalking Collector ：链路数据收集器，对 agent传过来的数据进行整合 分析处理并落入相关的数据存储中。 三、Storage：Skywalking的存储，在6.x版本中支持以 ElasticSearch（推荐）、Mysql、TiDB、H二、做为存储介质进行数据存储。 四、UI ：Web可视化平台，用来展现落地的数据。

下载并启动 SkyWalking

官方已经为咱们准备好了编译过的服务端版本，如今最新版本为6.4.0数据库

下载地址为 skywalking.apache.org/downloads/apache

配置 SkyWalking

下载完成后解压缩vim

# tar -xvf apache-skywalking-apm-6.4.0.tar
# mv apache-skywalking-apm-bin /usr/local/skywalking
# cd /usr/local/skywalking
复制代码

修改配置浏览器

# cd config
复制代码

vim application.yml@

配置存储方式，默认H2，官方推荐elasticsearch 这里须要作三件事：bash

注释 H2 存储方案
启用 ElasticSearch 存储方案
修改 ElasticSearch 服务器地址

clusterNodes: ${SW_STORAGE_ES_CLUSTER_NODES:localhost:9200}

启动 SkyWalking

修改完配置后，进入 skywalking\bin 目录，运行startup.bat启动服务端

经过浏览器访问 http://localhost:8080 出现以下界面即表示启动成功

默认的用户名密码为：admin/admin，登陆成功后，效果以下图

Java Agent 服务器探针

agent简单的理解就是放一个插件，随着应用程序启动，监控数据、收集数据、发送数据的做用。 探针文件在skywalking/agent目录下

启动方式

在之前启动应用程序时，加上一些参数

java -javaagent:/path/to/skywalking-agent/skywalking-agent.jar 
    -Dskywalking.agent.service_name=shop-goods-provider 
    -Dskywalking.collector.backend_service=localhost:11800 
    -jar yourApp.jar
复制代码

参数含义：

**-javaagent：**用于指定探针路径
**-Dskywalking.agent.service_name：**用于重写 agent/config/agent.config 配置文件中的服务名
**-Dskywalking.collector.backend_service：**用于重写 agent/config/agent.config 配置文件中的服务地址

启动后，访问连接，就会发现 Service 与 Endpoint 已经成功检测到了

表示 SkyWalking 链路追踪配置成功。

Service Topology监控

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

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

从图中能够看到:

有两个服务节点：provider & consumer 有一个数据库节点：localhost【mysql】 consumer消费了provider提供出来的接口。

一个系统的拓扑图让咱们清晰的认识到系统之间的应用的依赖关系以及当前状态下的业务流转流程。

细心的小伙伴们可能发现图示节点consumer上有一部分是红色的，红色是什么意思呢？

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

Skywalking Trace监控

Skywalking经过业务调用监控进行依赖分析，提供给咱们了服务之间的服务调用拓扑关系、以及针对每一个endpoint的trace记录。咱们在以前看到consumer节点服务中发生了错误，让咱们一块儿来定位下错误是发生在了什么地方又是什么缘由呢？

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

Trace调用链路监控

上图展现的是一次正常的响应，这条响应总耗时19ms；能够详细点击每一个span查看详细信息

Service JVM信息监控

Skywalking还能够监控到 Service运行时的CPU、堆内存、非堆内存使用率、以及GC状况。这些信息 来源于JVM。

Skywalking 服务告警

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

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

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

一、service_resp_time_rule：告警规则名称 ***_rule （规则名称能够自定义可是必须以’_rule’结尾

二、indicator-name：指标数据名称：定义参见t.cn/EGhfbmd

三、op: 操做符： > , < , = 【固然你能够本身扩展开发其余的操做符】

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

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

六、counts: 达到告警阈值的次数

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

八、message：告警信息

文件结尾有最后一个webhooks属性：服务告警通知服务地址

webhooks:
# - http://127.0.0.1/notify/
# - http://127.0.0.1/go-wechat/
复制代码

总结

本文简单了介绍了Skywalking简单的知识，能够经过Skywalking，可让咱们方便的查看微服务架构中系统瓶颈以及性能问题等。小伙伴们能够去尝试操做一下哦，谢谢！！！

你的赞和关注是我继续创做的动力~