SkyWalking配上告警更优秀

男娘i 2022-08-28 00:55 222阅读 0赞

### 前言 ###

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

### 正文 ###

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

#### 1. 跟踪数据库请求 ####

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

##### 1.1 环境准备 #####

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

##### 1.2 项目集成EF Core #####

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

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

![a01c27e64fbfe58bd125f938ed7abbef.png][]

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

##### 1.3 看效果 #####

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

![09e91b3fd08b51cba69c8bc0ec0464ad.png][]

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

![b7fd4c2612ff394e6a165509bc66c089.png][]

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

![25f7e7b98b7d19f14e5feba2042df299.png][]

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

#### 2. 告警配置及使用 ####

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

##### 2.1 告警规则配置 #####

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

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

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

*  **进入容器，并到对应的配置目录**
    
    执行如下命令进入到SkyWalking后台容器；如果不是以容器启动的，直接进到配置文件目录修改对应文件即可；
    
        docker exec -it skywalking-oap /bin/bash
    
    ![e7f5fb4e01fe7733ea43bd62c2c626f5.png][]
 *  **查阅配置规则文件及配置规则解读**
    
    通过`cat alarm-settings.yml`可以查阅文件内容，如下：
    
    ![35b874a70e827444468bfe852242768f.png][]
    
    **规则常用指标解读**：
    
    **rule name**：规则名称，必须唯一，必须以 **\_rule**结尾；
    
    **metrics name**：oal(Observability Analysis Language)脚本中的度量名；名称在SkyWalking后端服务中已经定义，进入容器skywalking-oap之后，进入如下目录就可以找到。
    
    ![6722a9aa3dde9ce37e422055032e1c46.png][]
    
    如果想更多了解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**，如下：
    
    ![87797352a5dfd3e87d919279ff97b896.png][]
    
    这里只是一个常规的API，关于发邮件的配置，之前在一篇文章中分享的很详细([来，Consul 服务发现入个门(一看就会的那种)][Consul]
 *  **配置WebHook地址**
    
    由于SkyWalking的环境搭建在了我的云服务器，本地电脑没有配置外网访问，所以只能将API发布到云服务器上，这样SkyWalking后端服务调用告警接口就可以了，所以这里就在规则配置文件的最下面配置WebHook调用的接口地址即可；步骤如下：
    
    ![1bbe32ac1f4e6effd9aab4e117e91130.png][]
    
    修改alarm-settings.yml的文件，在文件最后配置WebHook地址，可以配置多个，如下：
    
    ![2e107d36d5350e016f49499802bcd8ab.png][]
    
    告警规则和WebHook地址配置完毕之后，重启一下容器，如下：
    
        docker stop skywalking-oap
         docker start skywalking-oap

##### 2.3 运行看效果 #####

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

![42e1d36da1624c2d70e79a1e8625f8cc.png][]

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

![f050236b638da5dbe3fdf8de99c89662.png][]

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

![7057e3dfba9f5c74902d29ea252ba4b6.png][]

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

### 总结 ###

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

[APM_SkyWalking]: https://blog.csdn.net/woshinidadaye_/article/details/114529367
[.NetCore_EF Core]: https://blog.csdn.net/weixin_39990138/article/details/111632435
[a01c27e64fbfe58bd125f938ed7abbef.png]: /images/20220828/aa205e74b54f4d8d8b2ce492c7d9cdaa.png
[Link 1]: https://mp.weixin.qq.com/s?__biz=MzU1MzYwMjQ5MQ==&mid=2247485811&idx=1&sn=9a60e9f260240d539f0e985f765d0f44&chksm=fbf115a7cc869cb1f874073d2b48e8da9baf62d2ebb72835ebc9378cdc75ef84e37b604caf95&token=840287067&lang=zh_CN&scene=21#wechat_redirect
[09e91b3fd08b51cba69c8bc0ec0464ad.png]: /images/20220828/3d4e55b802a3410f8b92337d7f904f80.png
[b7fd4c2612ff394e6a165509bc66c089.png]: /images/20220828/1442e8ac852f438b9fd67866f574237b.png
[25f7e7b98b7d19f14e5feba2042df299.png]: /images/20220828/61b83b31db2b483aa665948b447ee3c3.png
[e7f5fb4e01fe7733ea43bd62c2c626f5.png]: /images/20220828/3a19e8467cdf416a905ac167aa1349c5.png
[35b874a70e827444468bfe852242768f.png]: /images/20220828/2d884983846c43128733e6e80c471415.png
[6722a9aa3dde9ce37e422055032e1c46.png]: /images/20220828/08d9e70420fd4122bea6d87878bc5c83.png
[87797352a5dfd3e87d919279ff97b896.png]: /images/20220828/12b11b5003d742e3a170cd4834a8c6cc.png
[Consul]: https://blog.csdn.net/weixin_45583158/article/details/112210991
[1bbe32ac1f4e6effd9aab4e117e91130.png]: /images/20220828/b7f89dc10fbd471ca65ae68e0f2552b8.png
[2e107d36d5350e016f49499802bcd8ab.png]: /images/20220828/1bad1427a98f42e693aea0471fac154e.png
[42e1d36da1624c2d70e79a1e8625f8cc.png]: /images/20220828/31daa65e4fa74f07acd2277c0d52e0c4.png
[f050236b638da5dbe3fdf8de99c89662.png]: /images/20220828/b18008d986a94bb2b678f09e51c6b546.png
[7057e3dfba9f5c74902d29ea252ba4b6.png]: /images/20220828/5608625a6f7c444fae78d091f2bb8dd9.png