SkyWalking配上告警更優秀

2021 年 10 月 30 日
筆記
微服務那些事, 運維

前言

對於監控系統來說，不可能讓人一直盯着監控看板，而更多的是以自動提醒的方式，比如郵件、短訊或微信推送等，當達到或超出預設的告警指標時，就自動發送消息提醒，下面就來說說如何配置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，參照文檔：//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時間內，忽略相同的告警消息；

更多告警規則詳情，請參照這個地址：//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
```