SkyWalking配上告警更优秀

前言

对于监控系统来说，不可能让人一直盯着监控看板，而更多的是以自动提醒的方式，比如邮件、短信或微信推送等，当达到或超出预设的告警指标时，就自动发送消息提醒，下面就来说说如何配置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后台容器；如果不是以容器启动的，直接进到配置文件目录修改对应文件即可；
```
 docker exec -it skywalking-oap /bin/bash
```
查阅配置规则文件及配置规则解读

通过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

总结

好了，关于告警的配置和使用就简单说这么多吧，如果有其他配置需求，可以参照官网，使用方式大同小异；后续会记录一些使用经验，关注“Code综艺圈”，和我一起学习吧；