SkyWalking 配上告警更優秀
本文轉載自微信公眾號「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
總結
好了，關于告警的配置和使用就簡單說這么多吧，如果有其他配置需求，可以參照官網，使用方式大同小異;后續會記錄一些使用經驗;
