SkyWalking 配上告警更优秀

发布时间：2021-11-01 16:02 所属栏目：53 来源：互联网

导读：前言对于监控系统来说，不可能让人一直盯着监控看板，而更多的是以自动提醒的方式，比如邮件、短信或微信推送等，当达到或超出预设的告警指标时，就自动发送消息提醒，下面就来说说如何配置SkyWalking的告警。正文在说告警之前呢，给小伙伴先演示一下SkyW

前言

对于监控系统来说，不可能让人一直盯着监控看板，而更多的是以自动提醒的方式，比如邮件、短信或微信推送等，当达到或超出预设的告警指标时，就自动发送消息提醒，下面就来说说如何配置SkyWalking的告警。

正文

在说告警之前呢，给小伙伴先演示一下SkyWalking跟踪数据库操作链路及监控数据库指标，支持EF Core的形式操作数据库，可以显示对应的SQL语句和执行时间等信息。

1. 跟踪数据库请求

对于项目来说，直接或间接访问数据库是避免不了的;对于业务数据量比较大或高并发场景，很多时候会因为数据库操作过慢或不及时返回数据，导致整个系统体验极差，所以对系统操作数据库的跟踪和监控少不了，以下就来演示一下SkyWalking对数据库操作的跟踪和监控。

1.1 环境准备

这里的SkyWalking环境搭建就不重复操作了，可以参考上一篇(分布式/微服务必配APM系统，SkyWalking让你不迷路)。

1.2 项目集成EF Core

关于EF Core的使用，之前分享过一篇很详细的文章，可参考查阅(跟我一起学.NetCore之EF Core 实战入门，一看就会)。

集成EF Core之后，为方便演示看效果，得增加一个API进行访问，这个API就是简单的通过EF访问数据库，如下：

注：这里的项目需要集成SkyWalking，和上一篇一样，不需要做额外处理。

1.3 看效果

运行项目，访问上一步编写的GetUser接口，然后再看SkyWalking的记录情况，如下：

可以切换成列表的形式，看着相对更直观一点：

点击对应每层可显示对应的详细信息，如点击数据库操作相关层，可显示具体的SQL语句及其他信息，如下：

更多操作演示，就留给小伙伴自己操作吧。

2. 告警配置及使用

自动告警基本上是监控系统的标配，接下来看看在SkyWalking中是如何使用的。

2.1 告警规则配置

所谓告警规则其实就是配置的告警条件及检查周期，根据业务需要进行配置。

在SkyWalking中配置告警条件是在后台服务端进行的，即环境搭建中启动的容器skywalking-oap，见上篇文章;

由于演示是采用Docker的形式启动的容器，也没有进行数据卷挂载，所以我们需要进入对应的容器进行配置，如下：

进入容器，并到对应的配置目录

执行如下命令进入到SkyWalking后台容器;如果不是以容器启动的，直接进到配置文件目录修改对应文件即可;

查阅配置规则文件及配置规则解读

通过cat alarm-settings.yml可以查阅文件内容，如下：

规则常用指标解读：

rule name：规则名称，必须唯一，必须以 _rule结尾;

metrics name：oal(Observability Analysis Language)脚本中的度量名;名称在SkyWalking后端服务中已经定义，进入容器skywalking-oap之后，进入如下目录就可以找到。

如果想更多了解oal，参照文档：https://github.com/apache/skywalking/blob/master/docs/en/concepts-and-designs/oal.md

include names：本规则告警生效的实体名称，如服务名，终端名;

exclude-names：将此规则作用于不匹配的实体名称上，如服务名，终端名;

threshold：阈值，可以是一个数组，即可以配置多个值;

op：操作符, 可以设定 >, <, =;

period：多久检查一次当前的指标数据是否符合告警规则;以分钟为单位

count：超过阈值条件，达到count次数，触发告警;

silence period：在同一个周期，指定的silence period时间内，忽略相同的告警消息;

更多告警规则详情，请参照这个地址：https://github.com/apache/skywalking/blob/master/docs/en/setup/backend/backend-alarm.md

配置规则文件简单修改

这里挑一个模板规则稍微改一下，用于后续演示，如下：

# 告警规则名称，必须唯一，以_rule结尾

service_sla_rule:

# 指定metrics-name

metrics-name: service_sla

# 小于

op: "<"

# 指定阈值

threshold: 8000

# 10分钟检测一次告警规则

period: 10

# 触发2次告警规则就告警

count: 2

# 设置的3分钟时间段有相同的告警，不重复告警.

silence-period: 3

# 配置告警消息

message: Successful rate of service {name} is lower than 80% in 2 minutes of last 10 minutes

规则概要：服务成功率在过去2分钟内低于80%

2.2 告警API编写

有了规则之后，如何进行自动发送告警信息呢?

这个本质还是SkyWalking根据规则进行检查，如果符合规则条件，就通过WebHook、gRPCHook、WeChat Hook、Dingtalk Hook等方式进行消息通知;接收到告警数据信息之后，可以自行处理消息。这里为了方便，就采用WebHook的方式进行演示，即触发告警条件之后，SkyWalking会调用配置的WebHook 接口，并传递对应的告警信息;

传递的告警信息

SkyWalking后端服务会以Post的方式调用WebHook的接口，并以Json的形式向接口传递告警信息，如下格式：

[

{

"scopeId": 1, // 范围ID

"name": "serviceA", //实体名称

// 实体ID

"id0": "12",

// 用于标识实体关系中的目标实体ID，没有关系就为空

"id1": "",

// 规则名称 alarm-settings.yml中配置的规则名称

"ruleName": "service_resp_time_rule",

// 触发告警时发送的消息

"alarmMessage": "alarmMessage xxxx",

// 告警的时间戳

"startTime": 1560524171000

{

"scopeId": 1,

"name": "serviceB",

"id0": "23",

"id1": "",

"ruleName": "service_resp_time_rule",

"alarmMessage": "alarmMessage yyy",

"startTime": 1560524171000

}

]

知道传递告警的信息的格式后，写API的时候就得以此格式接收。

编写告警时调用的API，如下：

这里只是一个常规的API，关于发邮件的配置，之前在一篇文章中分享的很详细(来，Consul 服务发现入个门(一看就会的那种))。

配置WebHook地址

由于SkyWalking的环境搭建在了我的云服务器，本地电脑没有配置外网访问，所以只能将API发布到云服务器上，这样SkyWalking后端服务调用告警接口就可以了，所以这里就在规则配置文件的最下面配置WebHook调用的接口地址即可;步骤如下：

修改alarm-settings.yml的文件，在文件最后配置WebHook地址，可以配置多个，如下：

告警规则和WebHook地址配置完毕之后，重启一下容器，如下：

docker stop skywalking-oap

docker start skywalking-oap

2.3 运行看效果

启动项目，然后访问之前写好的接口，接口中特意搞了个异常，所以每次都会报错，错误率肯定是低于设置的规则80%，稍等一会就会产生告警信息;

界面上也可以看到告警信息，如下：

因为触发告警时会调用我们编写的WebHook接口，我们针对告警信息发送了邮件，所以同时会收到对应的告警邮件

演示代码：https://gitee.com/CodeZoe/microservies-demo/tree/main/SkyWalkingDemo/SkyWalkingDataDemo

总结

好了，关于告警的配置和使用就简单说这么多吧，如果有其他配置需求，可以参照官网，使用方式大同小异;后续会记录一些使用经验;

（编辑：ASP站长网）