一分鐘完成訪問數據的智能巡檢告警

時序巡檢適用範圍

從業務維度看

網站訪問流量、延時、PV
產品的活躍用戶數
業務較為穩定的機器的CPU利用率、內存使用情況、系統負載指標
雲上SLB中的出入網流量
K8S中Ingress訪問日誌的流量、延時情況

從指標形態維度看

具有一定業務規律的時序曲線

從指標異常維度看

關注指標中的突變（突刺）
關注指標中的漂移
關注指標中的局部擾動
關注指標中的形態改變（變點：某個觀測維度上的統計指標發生了變化）
關注指標中的局部數據缺失、斷流

典型場景：訪問日誌類型

對於 OSS 訪問日誌、Nginx訪問日誌、Apache訪問日誌、IIS訪問日誌來說，是重要的衡量業務整體穩定性的重要觀測數據，那麼如何通過訪問日誌來進行監控告警呢？藉助《Google：Site Reliability Engineering》（具體SRE的解釋參考如下引用）提供的手段我們需要對整體的訪問行為進行度量。

SRE is what you get when you treat operations as if it’s a software problem. Our mission is to protect, provide for, and progress the software and systems behind all of Google’s public services — Google Search, Ads, Gmail, Android, YouTube, and App Engine, to name just a few — with an ever-watchful eye on their availability, latency, performance, and capacity.

問題回顧

通過訪問日誌，我們可以獲取到如下基礎指標：

每分鐘訪問的次數（PV）
每分鐘成功請求的次數（200請求的PV）
每分鐘失敗請求的次數（非200請求的PV）
每分鐘嚴重異常請求的次數（5XX請求的PV）
每分鐘平均請求的延時、每分鐘請求的延時的分位數大小
每分鐘不同請求的訪問次數、成功訪問次數、異常訪問次數
每分鐘不同請求的平均訪問延時、請求延時的分位數大小
每分鐘、每個域名、每個請求方法在請求次數和延時上的指標
其它相關指標。。。。。。

面對上面的多維度的指標，我們先來使用生動形象的圖標來刻畫一下目前的配置現狀，通過自己維度一堆執行腳本（SQL查詢）和各自規則的閾值來實現對於上述指標的檢測。關於規則的閾值，往往是需要反覆的調整，且需要按照時間（節假日、工作日、白天、晚間等）進行調整。

針對以上問題，我們可以通過以下SQL來完成觀測指標的智能檢測。

解決方案

這裡我們按照訪問日誌為例子進行配置的拆解：

數據已經存儲在SLS中，並且相關字段已經配置好索引
數據已經存儲在SLS中，並且存儲超過1天以上（數據的可觀測時間長度在2周左右最好，大部分業務數據是按照周有一定的規律的）

1. 對全部域名進行指標監控

在這個場景中，需要關注網站的核心PV情況，已經延時的均值和分位數情況：

* |
select
  __time__ - __time__ % 60 as time,
  'all_domain_instance' as target,
  COUNT(*) as total,
  count_if(request_status = '200') as succ,
  count_if(request_status != '200') as fail,
  count_if(request_status like '50%') as fata,
  avg(response) * 1000 as response_avg,
  approx_percentile(response, 0.95) * 1000 as response_p95
from log
group by
  time, target
order by
  time
limit 100000

這裡我們拿到了如下結果，說明下對應字段的含義和使用的注意事項：

time : 在時序巡檢中，需要有一個維度是表明時間信息的；
target : 在時序巡檢中，至少要包含一個巡檢實體，方便後續的告警、查詢、可視化等操作，在這裡我們使用"all_domain_instance"作為我們的觀測實體對象；
實體對象的觀測特徵：[total, succ, fail, fata, response_avg, responce_p95]，需要注意的是，在巡檢特徵中，提供的設計時間維度的指標最好按照毫秒來表示，這樣算法學習的會更加準確；
在SQL語句的左右，一定要添加上 limit 1000000 這部分；

2. 對核心域名的指標進行監控

上部分僅僅解決了宏觀層面指標的提取問題，那麼寫下來，我們一起來生成下關於某個核心域名的指標監控問題，所涉及到的數據如上面的數據格式說明所示，具體指標提取函數如下：

domain: 'a.b.c'
or domain: 'd.e.f\:8888' |
select
  __time__ - __time__ % 60 as time,
  domain,
  COUNT(*) as total,
  count_if(request_status = '200') as succ,
  count_if(request_status != '200') as fail,
  count_if(request_status like '50%') as fatal,
  avg(
    case
      when response is null then 0.0
      else response
    end
  ) * 1000 as response_avg,
  approx_percentile(case
      when response is null then 0.0
      else response
    end, 0.95) * 1000 as response_p95
from log
group by time, domain
limit
  1000000

這裡我們拿到了如下結果，說明下對應字段的含義和使用的注意事項：

time : 在時序巡檢中，需要有一個維度是表明時間信息的；
domain : 在時序巡檢中，至少要包含一個巡檢實體，方便後續的告警、查詢、可視化等操作，在這裡我們使用每個訪問的域名作為我們的觀測實體對象；
實體對象的觀測特徵：[total, succ, fail, fata, response_avg, responce_p95]，需要注意的是，在巡檢特徵中，提供的設計時間維度的指標最好按照毫秒來表示，這樣算法學習的會更加準確；
在SQL語句的左右，一定要添加上 limit 1000000 這部分；

PS：在SLS平臺中，查詢語句前面可以進行快速的過濾，最多可以開放三十個關鍵詞的查詢，如果遇到較多的域名需要進行查詢，可以在文章下面留言，下一期提供大量過濾條件下的最佳配置實踐。

通過上述步驟1和步驟2，我們完成了基於訪問日誌的指標的提取，接下來就是進入到快速配置巡檢的階段！

3. 時序巡檢配置步驟

找到巡檢配置在SLS的訪問入口
在SLS的控制檯中，進入需要巡檢數據的Project/LogStore
在左側的邊框導航欄中，可以通過如下截圖中的步驟，找到【智能巡檢】的入口
根據圖(2)提供的標記，找到作業創建的入口

完成基礎數據源的選擇，還有相關權限的授予
按照規範完成作業名的填寫
配置好對應的數據源（待巡檢對象的數據存儲的位置）
【默認配置】：這裡是關於權限的配置，具體的可以參考文末鏈接，同時我們會將結果創建存儲巡檢結果的logstore - internal-ml-log，關於該logstore的說明，可以文末鏈接

進入到巡檢作業的主體配置頁面【數據特徵配置】
數據類型：選擇【非指標化數據】，咱們是通過【原始的訪問日誌】通過SQL的操作生成待觀測的指標，點擊【查詢】後會返回對應的表格結果
針對數據樣例，填充對應的配置
【時間列】：根據結果選擇 "time" 這個字段，因為咱們的SQL是通過 "__time__ - __time__ % 60 as time" 進行聚合的，因此我們的時序是按照【分鐘粒度】進行統計的，所以【粒度】這裡填充 60 單位是秒
【實體】：就是我們的觀測對象，在當前的Query結果中是來監控全局的各種指標的，因此選擇 "target" 這個字段來表示實體維度
【特徵】：選擇查詢結果中的數值列（bigint、double類型的數據）作為我們觀測對象的監控維度；

【算法參數】配置部分
目前我們提供了一個穩定的算法：流式圖算法
對應的算法參數可以詳見我們的官方文檔
預覽採樣數據：我們會按照您提供的SQL去獲取指定時間長度的數據，完成算法的預覽，便於您去調整算法的效果
關於檢測結果的異常分數可以詳見參考文檔

【調度配置】部分
這裡是當前的巡檢任務開始獲取數據的時間點
如果您的數據保存的時間比較長，建議從當前時間計算開始2天前的時間點；
如果您的數據保存的時間比較短，建議從當前時間計算開始12小時前的時間點；
需要說明的一點是：巡檢作業會從指定的時間開始，順序讀取數據，當作業追到當前的提交的時間點後，會逐步輸出巡檢解決，具體的進度可以在 internal-ml-log 中進行查詢

【告警配置】部分

SLS平臺會內置提供【行動策略】和【內容模板】，具體的配置內容可在【告警中心】中進行查看。

默認的行動策略：SLS 智能巡檢內置行動策略 - sls.app.ml.builtin

默認的內容模板：SLS智能巡檢內置內容模板 - sls.app.ml.anomaly.cn

【極簡模式】：默認指定的是告警策略是【極簡模式】，在該模式下，默認提供的是【釘釘-自定義】的通知渠道，您只需要將自己的釘釘機器人填寫到【請求地址】中就可以的。默認的【內容模板】是我們提供的【SLS智能巡檢內置內容模板】
PS：當完成該操作時，會在【告警中心】【行動策略】中自動創建一個以 "alert.simple."開頭的行動策略，後續的渠道的需求，無需去修改巡檢作業的配置，只需要在【告警中心】修改對應的通知渠道就可以了