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，参照文档：skywalking/oal.md at master · apache/skywalking · GitHub

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

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

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

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

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

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

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

更多告警规则详情，请参照这个地址：skywalking/backend-alarm.md at master · apache/skywalking · GitHub

配置规则文件简单修改

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

  # 告警规则名称，必须唯一，以_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
```