摘要： 用一個最最常用的案例（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 則產生告警：

status:500 | select count(1) as c

這種方式比較簡單，但往往過于敏感，對于一些業(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 1440

3. 是否有流量急跌或暴漲？
服務器端自然流量一般符合概率上的分布，會有一個緩慢上漲或下降過程。流量急跌或暴漲（短時間內變化非常大）一般都是不正常的現(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)計：

* | select sum(inflow)/(max(__time__)-min(__time__)) as inflow , __time__-__time__%60 as window_time from log group by window_time order by window_time limit 15

從結果分布上看，每個窗口內的平均流量 sum(inflow)/(max(time)-min(time)) 應該是均勻的：

3.2 計算窗口內的差異值（最大值變化率）
這里我們會用到子查詢，我們寫一個查詢，從上述結果中計算最大值 或 最小值 與平均值的變化率（這里的max_ratio)，例如如下計算結果max_ratio 為 1.02。我們可以定義一個告警規(guī)則，如果max_ratio > 1.5 （變化率超過50%）就告警。

* | select max(inflow)/avg(inflow) as max_ratio from (select sum(inflow)/(max(__time__)-min(__time__)) as inflow , __time__-__time__%60 as window_time from log group by window_time order by window_time limit 15)

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 代替

* | select max_by(inflow, window_time)/1.0/avg(inflow) as lastest_ratio from (select sum(inflow)/(max(__time__)-min(__time__)) as inflow , __time__-__time__%60 as window_time from log group by window_time order by window_time limit 15)

總結
日志服務查詢分析能力是完整SQL92，支持各種數(shù)理統(tǒng)計與計算等，只要會用SQL都能進行快速分析，歡迎嘗試！

總結

以上是生活随笔為你收集整理的打通钉钉+WebHook：日志服务告警升级的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內容還不錯，歡迎將生活随笔推薦給好友。