時序巡檢适用範圍
從業務次元看
- 網站通路流量、延時、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 - domain : 在時序巡檢中，至少要包含一個巡檢實體，友善後續的告警、查詢、可視化等操作，在這裡我們使用每個通路的域名作為我們的觀測實體對象；
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."開頭的行動政策，後續的管道的需求，無需去修改巡檢作業的配置，隻需要在【告警中心】修改對應的通知管道就可以了
- 【普通模式】和【進階模式】您可以直接去管理自己的【告警政策】和【行動政策】
4. 時序巡檢的告警顯示
- 如果有任務巡檢的告警結果，會通過【您配置的釘釘機器人管道】發送出去，具體的形式如下，您可以通過點選【誤報】和【确定】跟SLS的系統進行互動，目前點選後會【彈出空白的釘釘側邊欄】這個目前不影響您使用
- 您可以通過查詢巡檢大盤來看曆史上某個作業中觀測對象的告警曆史，具體的位址在如下位置：
- 當然，您也可以通過告警系統來檢視所有的告警曆史記錄