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，參照文檔：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-namemetrics-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-oapdocker?start?skywalking-oap
2.3 運行看效果
啟動項目，然后訪問之前寫好的接口，接口中特意搞了個異常，所以每次都會報錯，錯誤率肯定是低于設置的規則80%，稍等一會就會產生告警信息；
界面上也可以看到告警信息，如下：
因為觸發告警時會調用我們編寫的WebHook接口，我們針對告警信息發送了郵件，所以同時會收到對應的告警郵件
演示代碼：https://gitee.com/CodeZoe/microservies-demo/tree/main/SkyWalkingDemo/SkyWalkingDataDemo
總結
好了，關于告警的配置和使用就簡單說這么多吧，如果有其他配置需求，可以參照官網，使用方式大同小異；后續會記錄一些使用經驗，關注“Code綜藝圈”，和我一起學習吧；
總結
以上是生活随笔為你收集整理的SkyWalking配上告警更优秀的全部內容，希望文章能夠幫你解決所遇到的問題。
