本文转载自微信公众号「Code综艺圈」，作者Code综艺圈。转载本文请联系Code综艺圈公众号。
前言
对于监控系统来说，不可能让人一直盯着监控看板，而更多的是以自动提醒的方式，比如邮件、短信或微信推送等，当达到或超出预设的告警指标时，就自动发送消息提醒，下面就来说说如何配置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
总结
好了，关于告警的配置和使用就简单说这么多吧，如果有其他配置需求，可以参照官网，使用方式大同小异;后续会记录一些使用经验;
