11 分布式服务链路监控以及报警方案 上一讲我们主要讲解了硬件的命令行资源监控，相信你已经学会了通过命令行的方式查看硬件瓶颈。

那我提一个问题，为什么会有硬件瓶颈呢？或者我说得更直白一点，如果服务器上没有应用还会造成硬件瓶颈吗？显然是不会的，所以我想向你传递一个观点：呈现出来的硬件瓶颈绝大多数是表象问题，我们往往需要在系统应用上寻找问题的根因。而寻找系统问题的根因，对于系统链路监控也是必不可少的，所以这一讲我将带你学习如何进行基于系统链路的监控。

为什么要链路监控？

随着微服务的流行，链路监控越来越受重视。微服务架构是根据业务进行拆分，对外统一暴露API 接口，而内部可能是分布式服务、分布式对象存储等，如图 1 所示。

1shangchuan.png

图 1：微服务架构

这些组件共同构成了复杂的分布式网络。而分布式系统一旦出现问题，比如一个请求经过多个微服务之后出现了调用失败的问题，或者一个请求经过多个微服务之后 Response 时间过长，但具体是哪个微服务节点的问题我们并不知道。只能去服务器上查看调用经过的每个微服务的日志，当然这种方式的效率是比较低的，相当于人肉运维。

随着业务体系越来越复杂，加上服务间的相互依赖关系，微服务其中一个节点出现了问题，很可能牵一发而动全身，导致严重的后果。在这样的情况下，分布式链路监控的价值就体现出来了，它可以让你清晰地知道跨服务调用的链路耗时信息、执行方法等，并从整体到局部将信息呈现出来，可以帮助你节约故障排查时间。

全链路监控选择依据

全链路监控系统有很多，可以从这几方面选择：

  • 探针的性能消耗，探针是搜集信息的“情报员”，尤其是在多节点情况下，搜集数据的成本会越来越高，监控组件服务的影响应该做到足够小、数据分析快、性能占用小；
  • 对代码的非侵入性，减少开发的维护成本；
  • 监控、分析的维度尽可能多。

目前市面上的全链路监控工具很多，比如 CAT、SkyWalking、Pinpoint 等，对于工具的选型来说最重要的是采样数据对系统的性能消耗足够小、数据分析和展示快、监控的维度尽可能丰富，简单比较下这几个工具。

  • CAT：是由美团和携程的同学开发的，通过代码埋点的侵入式方式，对应用日志分析、监控、展示等，不过侵入式的方式会带来开发以及维护成本的增加。
  • SkyWalking：也是由国人开发，目前项目已经提交到 Apache 孵化组织，无侵入性、UI 展示简洁清晰。
  • Pinpoint：由韩国人开发，相对于 SkyWalkingg 提供了更为详尽的链路监控信息，不过数据采集带来的性能损耗相对于 SkyWalking 来说比较大。

综上我将以 SkyWalking 为例给你介绍下链路监控，希望通过介绍，你可以掌握 SkyWalking 的具体使用步骤和链路监控工具可以给我们带来什么好处，通过本讲的学习你也可以自由选择链路监控工具去实践。

SkyWalking 的模块分析

首先来看下 SkyWalking 的组件示意图：

Drawing 1.png

图 2：SkyWalking 的组件示意图

  • Tracing 和 Metric ： 在应用上采集 Tracing（调用链数据）和 Metric（指标）信息通过 HTTP 或者 gRPC 方式发送数据到 Analysis Platform。
  • Analysis Platform：数据的采集和计算，将传输的 Tracing 和 Metric 数据进行整合分析，通过 Analysis Core 模块把数据写入相关的数据库中。
  • Storage：SkyWalking 的存储，支持以 ElasticSearch、MySQL、TiDB 等数据库进行数据存储，其中 ElasticSearch、MySQL 用的居多。
  • SkyWalking UI：Web 可视化平台，用来展示落地的数据以及图表，比如链路调用、服务结构等。

1.安装部署过程以及相关的注意事项

首先下载 SkyWalking 安装包并进行解压： wget https://github.com/apache/SkyWalking/archive/v8.0.1.tar.gz tar -zxvf v8.0.1.tar.gz

解压后可以看到如下文件夹：

Drawing 2.png

我们讲解下这个主要文件的作用。

（1）修改配置文件 config/application.yml。在这里先进行数据库的配置，我使用当前服务器上的 mysql 来进行存储： mysql: properties: jdbcUrl: ${SW_JDBC_URL:”jdbc:mysql://127.0.0.1:3306/swtest”} dataSource.user: ${SW_DATA_SOURCE_USER:root} dataSource.password: ${SW_DATA_SOURCE_PASSWORD:123456}

将上述的配置文件根据自己的数据库实际地址修改，修改完成后进行启动：

$ bin/oapService.sh SkyWalking OAP started successfully!

（2）接着来看 SkyWalking UI 的相关配置，由于 SkyWalking UI 的默认端口是 8080，这个端口是很多应用的默认端口，容易产生冲突，你可以修改一下，如下所示：

/# 修改webapp/webapp.yml server: port: 18080

然后启动 SkyWalking UI 服务，启动完成后你会看到如下信息：

$ bin/webappService.sh SkyWalking Web Application started successfully!

这里我强烈建议，不管是第一步还是第二步中的 started successfully，都并不意味着真正的启动成功，一般在提示 started successfully 后，还需要去 logs 文件夹下查看相关日志来判断启动过程中是否存在异常。

UI 界面启动成功后示意图如下：

Drawing 3.png

（3）本地启动微服务。我 demo 里包含 system、auth、user 等服务，通过配置 SkyWalking Agent 的方式启动服务，示意如下： nohup java -server -Xms256m -Xmx256m -Dspring.profiles.active=dev -Dspring.cloud.nacos.discovery.server-addr=127.0.0.1:8848 -javaagent:/root/apm/apache-SkyWalking-apm-bin/agent/SkyWalking-agent.jar=agent.service_name=cctuser -Dspring.cloud.nacos.config.server-addr=127.0.0.1:8848 -jar blade-user.jar > log.file 2>&1 &

-javaagent 后的启动参数是 SkyWalking 的 agent 配置路径。

启动本地的微服务成功后，就可以访问服务，同时通过 SkyWalking 监控你可以看到服务部署图以及链路监控等，如下图所示：

图 3：服务部署图

Drawing 5.png

图 4：链路追踪图

在我们进行链路追踪后，可能会出现一些超时、访问错误等异常，那我们如何能够更快地收到这些异常信息呢？

2.常见的报警方式

首先很多人想到了报警机制，那我带你了解下常见的几种报警方式。

（1）短信或者电话报警

这样的报警方式更适合高级别的报警提醒，用于处理紧急情况。出现级别不高而又频繁地发送短信会让人产生排斥感，而且电话或者短信的报警方式也存在一定的成本。

（2）邮件报警

邮件报警更适用于工作时的提醒，但是系统往往是不能区分你是不是在工作，有时候夜间的报警邮件你很难及时关注到，所以说邮件报警也存在一定的局限性。

（3）钉钉报警

随着钉钉越来越普及，很多公司都已经使用钉钉。员工在公司需要使用钉钉管理自己的考勤以及进行工作上的沟通，如果将监控报警信息推送到钉钉上其实就很方便的。不过也存在有的企业用的是其他沟通工具，不过对于报警推送到沟通软件上的原理都是类似的，接下来我会以钉钉作为模版来讲解如何进行报警信息的推送。

3.如何配置钉钉机器人？

（1）打开机器人管理页面。以 PC 端为例，打开 PC 端钉钉，进入首页面点击头像，在弹出框里选择机器人管理，打开管理页面后可以选择自定义，如下图所示：

Drawing 6.png

（2）在打开的机器人详情页面点击添加按钮，如下图所示：

Drawing 7.png

（3）在打开的添加机器人页面输入机器人名字，选择要接收报警的钉钉群 ，设置机器人头像。根据需要勾选安全设置等就可以，点击完成之后，在页面拷贝出 Webhook 地址保存好，向这个地址发送 HTTP POST 请求，设置的 SkyWalking 钉钉报警群便能收到钉钉报警消息，如下图所示：

Drawing 8.png

配置好之后我们可以看到设置报警的钉钉群“SkyWalking 钉钉报警”出现了报警机器人消息，如下图所示：

Drawing 9.png

我们可以用 Linux 命令行工具 curl 快速验证是否可以推送成功，curl 命令行示意如下： [root@JD ~]/# curl ‘https://oapi.dingtalk.com/robot/send?access_token=xxxxxxx’ -H ‘CONTENT-TyPE: application/json’ -d ‘{“msgtype”: “text”,”text”: {“content”: “业务报警”}}’ {“errcode”:0,”errmsg”:”ok”}

你可以看到通过 curl 后可以得到基本响应 {“errcode”:0,“errmsg”:“ok”}。

4.如何将 SkyWalking 和钉钉报警完美结合？

上述已经配置完成了钉钉机器人，那如何将 SkyWalking 的报警信息自动推送到钉钉机器人呢？我们可以实现一个接口作为它们沟通的“桥梁”。

首先在 pom 里面引入相关的 jar 包，如下所示：

com.aliyun alibaba-dingtalk-service-sdk

然后自定义 DingTalkUtils 工具类，暴露接口访问路径 /dingdingAlarm。

@RequestMapping(value = “/dingdingAlarm”, method = RequestMethod.POST) public void alarm(@RequestBody List alarmList){ //示意代码 alarmList.forEach(alarm-> { DingTalkUtils.sendMsg(alarm.getAlarmMessage()); }); }

SkyWalking 告警推送到钉钉

SkyWalking 提供了告警的配置，我们可以很方便地配置上面暴露的接口。在 SkyWalking 程序包里的 config 文件夹下有个 alarm-settings.yml 文件，该文件专门用来配置相关的报警。在该配置文件中我们可以搜索到 webhooks，把上面暴露的接口写上去就好了。 webhooks:-http://ip:port/dingdingAlarm

接下来我们测试下，比如 auth 服务获取验证码的接口出现错误，我们是可以在 SkyWalking 追踪页面清楚地看到的。同时对于其他相关的业务同学，也都可以在钉钉群收到报警信息，这样的方式在实际工作中非常实用。业务报错图和钉钉报警图如下所示：

Drawing 10.png

图 5：业务报错图

Drawing 11.png

图 6：钉钉报警图

总结

这一讲主要讲解了关于 SkyWalking 的使用背景以及价值，在实操层面讲解了 SkyWalking 是如何追踪监控中出现的错误，并且把出现的错误通过钉钉通知给相关人员，相信通过这一讲的学习，你也对微服务下的报警方案会有一个更深刻的认识。

参考资料

https://learn.lianglianglee.com/%e4%b8%93%e6%a0%8f/%e8%af%b4%e9%80%8f%e6%80%a7%e8%83%bd%e6%b5%8b%e8%af%95/11%20%20%e5%88%86%e5%b8%83%e5%bc%8f%e6%9c%8d%e5%8a%a1%e9%93%be%e8%b7%af%e7%9b%91%e6%8e%a7%e4%bb%a5%e5%8f%8a%e6%8a%a5%e8%ad%a6%e6%96%b9%e6%a1%88.md