打通钉钉+WebHook:日志服务告警升级
摘要: 用一個最最常用的案例(Nginx日志分析)來說明當前使用場景,告警要解決的3個問題:是否有錯誤;是否有性能問題;是否有流量急跌或暴漲
阿里云日志服務是針對實時數(shù)據(jù)一站式服務,用戶只需要將精力集中在分析上,過程中數(shù)據(jù)采集、對接各種存儲計算、數(shù)據(jù)索引和查詢等瑣碎工作等都可以交給日志服務完成。
9月日志服務升級實時分析功能(LogSearch/Analytics),可以使用查詢+SQL92語法對日志進行實時分析,并在結果分析可視化上,支持自帶Dashboard、DataV、Grafana、Tableua(通過JDBC)、QuickBI等可視化方式。
在監(jiān)控場景中光有可視化是不夠的,日志服務提供告警與通知功能如下:
將查詢(SavedSearch)保存下來
對查詢設置觸發(fā)周期(間隔),并對執(zhí)行結果設定判斷條件并且告警
設置告警動作(如何通知),目前支持通知方式有3種:
通知中心:在阿里云通知中心可以設置多個聯(lián)系人,通知會通過郵件和短信方式發(fā)送
WebHook:包括釘釘機器人,及自定義WebHook等
(即將支持)寫回日志服務(logstore):可以通過流計算,函數(shù)服務進行事件訂閱;也可以對告警生成視圖和報表
告警功能配置與使用可以參見告警文檔。
告警設置案例(Nginx日志為例)
我們用一個最最常用的案例(Nginx日志分析)來說明當前使用場景,告警要解決的3個問題:
是否有錯誤
是否有性能問題
是否有流量急跌或暴漲
準備工作(Nginx日志接入)
日志數(shù)據(jù)采集。詳細步驟請參考5分鐘快速入門 或 直接在Logstore頁面 數(shù)據(jù)源接入向導 中設置。
索引設置,詳細步驟請參考索引設置與可視化或最佳實踐網(wǎng)站日志分析案例。
對關鍵指標設置視圖 + 告警。
(在做完1、2步驟后,在查詢頁面可以看到原始日志)
Sample視圖(例子):
1. 是否有錯誤
錯誤一般有這樣幾類:404(請求無法找到地址)/502/500(服務端錯誤),我們一般只需關心500(服務端錯誤),將這個query保存下來,統(tǒng)計單位時間內錯誤數(shù)c。告警可以設定一個規(guī)則c > 0 則產生告警:
這種方式比較簡單,但往往過于敏感,對于一些業(yè)務壓力較大的服務而言有零星幾個500是正常的。為了應對這種情況,我們可以在告警條件中設置觸發(fā)次數(shù)為2次:只有連續(xù)2次檢查都符合條件后再發(fā)告警。
2. 是否有性能問題
服務器運行過程中雖然沒有錯誤,但有可能會出現(xiàn)延遲(Latency)增大情況,因此我們可以針對延遲進行告警。
例如我們可以通過以下方式計算某個接口(“/adduser”)所有寫請求(”Post“)延時。告警規(guī)則設置為 l > 300000 (當平均值超過300ms后告警)。
Method:Post and URL:"/adduser" | select avg(Latency) as l利用平均值來報警簡單而直接,但這種方法往往會使得一些個體請求延時被平均掉,反饋不出問題。例如我們對該時間段的Latency可以計算一個數(shù)學上的分布(劃分20個區(qū)間,計算每個區(qū)間內的數(shù)目),從分布圖上可以看到大部分請求延時非常低(<20ms),但最高的延時有2.5S。
Method:Post and URL:"/adduser" | select numeric_histogram(20, Latency)為應對這種情況,我們可以用數(shù)學上的百分數(shù)(99%最大延時)來作為報警條件,這樣既可以排除偶發(fā)的延時高引起誤報,也能對整體的演示更有代表性。以下的語句計算了99%分位的延時大小 approx_percentile(Latency, 0.99) ,同樣我們也可以修改第二個參數(shù)進行其他分位的劃分,例如中位數(shù)的請求延時 approx_percentile(Latency, 0.5)
Method:Post and URL:"/adduser" | select approx_percentile(Latency, 0.99) as p99在監(jiān)控的場景中,我們也可以在一個圖上繪出平均延時,50%分位延時,以及90%分位延時。以下是按一天的窗口(1440分鐘)統(tǒng)計各分鐘內延時的圖:
* | select avg(Latency) as l, approx_percentile(Latency, 0.5) as p50, approx_percentile(Latency, 0.99) as p99, date_trunc('minute', time) as t group by t order by t desc limit 14403. 是否有流量急跌或暴漲?
服務器端自然流量一般符合概率上的分布,會有一個緩慢上漲或下降過程。流量急跌或暴漲(短時間內變化非常大)一般都是不正常的現(xiàn)象,需要留意。
(例如下圖的監(jiān)控中,在2分鐘時間內流量大小下跌30%以上,在2分鐘內后又迅速恢復)
急跌和暴漲一般會有如下參考系:
上一個時間窗口:環(huán)比上一個時間段
上一天該時間段的窗口:環(huán)比昨天
上一周該時間段的窗口:環(huán)比上周
我們這里以第一種情況來作為case討論,計算流量infow數(shù)據(jù)的變動率(也可以換成QPS等流量)。
3.1 首先定義一個計算窗口
例如我們定一個1分鐘的窗口,統(tǒng)計該分鐘內的流量大小,以下是一個5分鐘區(qū)間統(tǒng)計:
從結果分布上看,每個窗口內的平均流量 sum(inflow)/(max(time)-min(time)) 應該是均勻的:
3.2 計算窗口內的差異值(最大值變化率)
這里我們會用到子查詢,我們寫一個查詢,從上述結果中計算最大值 或 最小值 與平均值的變化率(這里的max_ratio),例如如下計算結果max_ratio 為 1.02。我們可以定義一個告警規(guī)則,如果max_ratio > 1.5 (變化率超過50%)就告警。
3.3 計算窗口內的差異值(最近值變化率)
在一些場景中我們更關注最新的數(shù)值是否有波動(是否已經(jīng)恢復),那可以通過max_by方法獲取最大windows_time中的流量來進行判斷,這里計算的最近值為lastest_ratio=0.97。
注意:
這里的max_by函數(shù)計算結果為字符類型,我們需要強轉成數(shù)字類型
如果要計算變化相對率,可以用(1.0-max_by(inflow, window_time)/1.0/avg(inflow)) as lastest_ratio 代替
總結
日志服務查詢分析能力是完整SQL92,支持各種數(shù)理統(tǒng)計與計算等,只要會用SQL都能進行快速分析,歡迎嘗試!
總結
以上是生活随笔為你收集整理的打通钉钉+WebHook:日志服务告警升级的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 2017双11技术揭秘—分布式缓存服务T
- 下一篇: HIRO 部署新一代可扩展边缘微型数据中