智能巡檢雲監控指標的最佳實踐

簡介：在真實的企業生產中，對研發和運維的同學都會面臨一個十分繁復且艱難的問題，就是對指標的監控和告警。具體我枚舉一些特定的問題請對號入座，看看在算力爆炸的時代能否通過算力和算法一起解決！

背景介紹

在真實的企業生產中，對研發和運維的同學都會面臨一個十分繁復且艱難的問題，就是對指標的監控和告警。具體我枚舉一些特定的問題請對號入座，看看在算力爆炸的時代能否通過算力和算法一起解決！

• 問題一：當一個新業務上線前，運維人員都需要明確服務的部署情況，確定監控對象，以及監控對象的一些可觀測性指標，並根據此完成相關日志數據的采集和處理；這里面會涉及到很多日志采集、指標加工等一系列臟活累活；
• 問題二：當確定了監控對象的黃金指標后，往往都需要先適配一組規則：某個接口每分鍾的平均請求延時不要超過多少毫秒；單位分鍾內的錯誤請求數量，不要超過多少等等；就如上圖所示，從操作系統維度去看，每個個體有上百種形態各異的指標，切指標的形態有不盡相同，試問要多少種規則才能較好的覆蓋到上述監控；
• 問題三：隨着業務逐步對外提供服務，以及各種運營活動的加推，我們運維監控同學一定會面臨兩個突出的問題：誤報太多和漏報的風險，那么這兩個問題都在現階段都需要人工介入，進行閾值的調整；尤其是漏報的問題，更加需要人工盯屏的形式，設計新的監控規則去覆蓋一些事件；

​

隨着各個雲上服務的SLA要求的提升，企業服務也需要不斷的提供問題發現的准確性和速度，在這一點上，自動化的主動巡檢監控和秒級別的監控越來越被廣大客戶所重視。SLS提供了對於指標數據的高效的存儲格式，並完全兼容Prometheus協議的時序數據，並在這個場景中，提供了對於海量指標線的智能巡檢，讓您可以丟掉繁復的規則配置，通過簡單的選擇就可以實現通用的異常檢測。

時序存儲的介紹

SLS的日志存儲引擎在2016年對外發布，目前承接阿里內部以及眾多企業的日志數據存儲，每天有數十PB的日志類數據寫入。其中有很大一部分屬於時序類數據或者用來計算時序指標，為了讓用戶能夠一站式完成整個DevOps生命周期的數據接入、清洗、加工、提取、存儲、可視化、監控、問題分析等過程，我們專門推出了時序存儲的功能，與日志存儲一道為大家解決各類機器數據的存儲問題。

​

在SLS平台中，可以較為簡單的將主機的監控數據、Prometheus監控數據通過Logtail直接寫入，同時也有多種數據源的導入能力（阿里雲監控數據）。本章主要通過對ECS機器數據和阿里雲監控數據來說明如何對接SLS智能時序巡檢能力。

智能異常分析介紹

智能異常分析應用是一個可托管、高可用、可擴展的服務，主要提供智能巡檢、文本分析和根因診斷三大能力。本文介紹智能異常分析應用的產品架構、功能優勢、適用場景、核心名詞、使用限制和費用說明等信息。

智能異常分析應用圍繞運維場景中的監控指標、程序日志、服務關系等核心要素展開，通過機器學習等手段產生異常事件，通過服務拓撲關聯分析時序數據和事件，最終降低企業的運維復雜度，提高服務質量。產品架構圖如下所示。

​

在如下場景中，推薦使用智能異常分析應用。

• 觀察對象多且每個觀察對象的觀測維度也多。
• 觀測對象沒有明確的閾值規則，但需要關注指標的形態。
• 需要對觀測對象編寫大量的業務規則。
• 處理非結構化的日志數據時，需要對文本日志中的模式進行挖掘。

 

接下來我們在雲監控指標數據場景中使用下

場景實驗

智能監控雲監控指標

雲監控數據接入

通過[官網文檔](導入雲監控數據 - 日志服務 - 阿里雲)可以較好的配置雲監控的導入任務。通過配置后，可以按照如下截圖去查看對應的導入任務

​

我們可以在SLS控制台上查看對應的導入指標，對應各個指標的名稱可以參考[這篇文檔](https://metricmeta.oss-cn-hangzhou.aliyuncs.com/listMetricMeta_zh.html)。我們可以通過如下查詢語句查看下聚合的數據格式：

* | select promql_query_range('acs_ecs_dashboard:cpu_system:Average') from metrics limit 100000

​

雲監控數據預覽

通過【查詢頁面右上角的查詢頁面】按鈕，可以跳轉過去查看下具體的數據格式。

​

* | select __time_nano__  / 1000000 as time, __name__ as metric_name, element_at(__labels__, 'instanceId') as instanceId from "test01.prom" where __name__ != '' and __name__ = 'acs_ecs_dashboard:cpu_system:Average' order by time, instanceId limit 100000

通過這條SQL語句，我們可以詳細的分析出，寫入到SLS中的具體的指標（某個監控對象，某個指標在什么時間的值是多少）。上述SQL語句僅僅羅列了在 2021-12-12 19:37~2021-12-12 19:38 這個時間區間的全部監控對象的監控指標，接下來，我們通過簡單的改寫，僅僅顯示某個單獨的監控對象在一分鍾的數據形態。

* | select date_trunc('second', time) as format, * from ( select __time_nano__  / 1000000 as time, __name__ as metric_name, element_at(__labels__, 'instanceId') as instanceId from "test01.prom" where __name__ != '' and __name__ = 'acs_ecs_dashboard:cpu_system:Average') where instanceId = 'xxxx' order by time limit 100000

​

我們可以看到對於監控指標等於“acs_ecs_dashboard:cpu_system:Average”而言，某個特定的實例是每隔15秒一個監控指標。但是由於我們使用的數據導入，將結果寫入到SLS的MetricStore中，因此是每分鍾寫入如一分鍾的監控數據。

這里要在強調一下：SLS側是是通過OpenAPI去獲取雲監控的指標數據的，數據導入SLS是有一定的延時的，具體延時大約在3分鍾左右，也就是說在 T0 時刻，SLS中的數據只能保證 [T0-300s] 之前的數據時一定按時寫入的。這一點在后續的巡檢任務配置過程中至關重要。

我們通過PromQL在簡化下上邊的描述，我們繼續使用對應的指標 "acs_ecs_dashboard:cpu_system:Average"，通過如下的語句可以得到預期的結果，這已經距離我們創建巡檢任務已經很接近了。

* | select promql_query_range('avg({__name__=~"acs_ecs_dashboard:cpu_system:Average"}) by (instanceId, __name__) ', '15s') from metrics limit 1000000

​

篩選監控指標

通過如下的Query可以大概知道在雲監控關於ECS提供了多少監控指標：

* | select COUNT(*) as num from ( select DISTINCT __name__ from "test01.prom" where __name__ != '' and __name__ like '%acs_ecs_dashboard%' limit 10000 )

得到的結果是295個結果，但是我們沒有比較全部都進行巡檢配置，因此第一步就是要根據[指標說明文檔](https://metricmeta.oss-cn-hangzhou.aliyuncs.com/listMetricMeta_zh.html)選擇需要監控的指標項，這里我提供一份簡單整理出來的比較重要的指標集合，供大家參考：

• acs_ecs_dashboard:CPUUtilization:Average
• acs_ecs_dashboard:DiskReadBPS:Average
• acs_ecs_dashboard:DiskReadIOPS:Average
• acs_ecs_dashboard:DiskWriteBPS:Average
• acs_ecs_dashboard:DiskWriteIOPS:Average
• acs_ecs_dashboard:InternetIn:Average
• acs_ecs_dashboard:InternetInRate:Average
• acs_ecs_dashboard:InternetOut:Average
• acs_ecs_dashboard:InternetOutRate:Average
• acs_ecs_dashboard:InternetOutRate_Percent:Average
• acs_ecs_dashboard:IntranetIn:Average
• acs_ecs_dashboard:IntranetInRate:Average
• acs_ecs_dashboard:IntranetOut:Average
• acs_ecs_dashboard:IntranetOutRate:Average
• acs_ecs_dashboard:cpu_idle:Average
• acs_ecs_dashboard:cpu_other:Average
• acs_ecs_dashboard:cpu_system:Average
• acs_ecs_dashboard:cpu_total:Average
• acs_ecs_dashboard:cpu_user:Average
• acs_ecs_dashboard:cpu_wait:Average
• acs_ecs_dashboard:disk_readbytes:Average
• acs_ecs_dashboard:disk_readiops:Average
• acs_ecs_dashboard:disk_writebytes:Average
• acs_ecs_dashboard:disk_writeiops:Average
• acs_ecs_dashboard:load_1m:Average
• acs_ecs_dashboard:load_5m:Average
• acs_ecs_dashboard:memory_actualusedspace:Average
• acs_ecs_dashboard:memory_freespace:Average
• acs_ecs_dashboard:memory_freeutilization:Average
• acs_ecs_dashboard:memory_totalspace:Average
• acs_ecs_dashboard:memory_usedspace:Average
• acs_ecs_dashboard:memory_usedutilization:Average
• acs_ecs_dashboard:net_tcpconnection:Average
• acs_ecs_dashboard:networkin_errorpackages:Average
• acs_ecs_dashboard:networkin_packages:Average
• acs_ecs_dashboard:networkin_rate:Average
• acs_ecs_dashboard:networkout_errorpackages:Average
• acs_ecs_dashboard:networkout_packages:Average
• acs_ecs_dashboard:networkout_rate:Average

根據上述配置，生成對應的查詢PromQL如下：

* | select promql_query_range('avg({__name__=~"acs_ecs_dashboard:CPUUtilization:Average|acs_ecs_dashboard:DiskReadBPS:Average|acs_ecs_dashboard:DiskReadIOPS:Average|acs_ecs_dashboard:DiskWriteBPS:Average|acs_ecs_dashboard:DiskWriteIOPS:Average|acs_ecs_dashboard:InternetIn:Average|acs_ecs_dashboard:InternetInRate:Average|acs_ecs_dashboard:InternetOut:Average|acs_ecs_dashboard:InternetOutRate:Average|acs_ecs_dashboard:InternetOutRate_Percent:Average|acs_ecs_dashboard:IntranetIn:Average|acs_ecs_dashboard:IntranetInRate:Average|acs_ecs_dashboard:IntranetOut:Average|acs_ecs_dashboard:IntranetOutRate:Average|acs_ecs_dashboard:cpu_idle:Average|acs_ecs_dashboard:cpu_other:Average|acs_ecs_dashboard:cpu_system:Average|acs_ecs_dashboard:cpu_total:Average|acs_ecs_dashboard:cpu_user:Average|acs_ecs_dashboard:cpu_wait:Average|acs_ecs_dashboard:disk_readbytes:Average|acs_ecs_dashboard:disk_readiops:Average|acs_ecs_dashboard:disk_writebytes:Average|acs_ecs_dashboard:disk_writeiops:Average|acs_ecs_dashboard:load_1m:Average|acs_ecs_dashboard:load_5m:Average|acs_ecs_dashboard:memory_actualusedspace:Average|acs_ecs_dashboard:memory_freespace:Average|acs_ecs_dashboard:memory_freeutilization:Average|acs_ecs_dashboard:memory_totalspace:Average|acs_ecs_dashboard:memory_usedspace:Average|acs_ecs_dashboard:memory_usedutilization:Average|acs_ecs_dashboard:net_tcpconnection:Average|acs_ecs_dashboard:networkin_errorpackages:Average|acs_ecs_dashboard:networkin_packages:Average|acs_ecs_dashboard:networkin_rate:Average|acs_ecs_dashboard:networkout_errorpackages:Average|acs_ecs_dashboard:networkout_packages:Average|acs_ecs_dashboard:networkout_rate:Average"}) by (instanceId, __name__) ', '1m') from metrics limit 1000000

對於一般場景而言，我們可以在簡化一些指標，這里直接提供對應的PromQL如下：

* | select promql_query_range('avg({__name__=~"acs_ecs_dashboard:CPUUtilization:Average|acs_ecs_dashboard:DiskReadBPS:Average|acs_ecs_dashboard:DiskReadIOPS:Average|acs_ecs_dashboard:DiskWriteBPS:Average|acs_ecs_dashboard:DiskWriteIOPS:Average|acs_ecs_dashboard:InternetIn:Average|acs_ecs_dashboard:InternetInRate:Average|acs_ecs_dashboard:InternetOut:Average|acs_ecs_dashboard:InternetOutRate:Average|acs_ecs_dashboard:InternetOutRate_Percent:Average|acs_ecs_dashboard:IntranetOut:Average|acs_ecs_dashboard:IntranetOutRate:Average|acs_ecs_dashboard:cpu_idle:Average|acs_ecs_dashboard:cpu_other:Average|acs_ecs_dashboard:cpu_system:Average|acs_ecs_dashboard:cpu_total:Average|acs_ecs_dashboard:cpu_user:Average|acs_ecs_dashboard:cpu_wait:Average|acs_ecs_dashboard:disk_readbytes:Average|acs_ecs_dashboard:disk_readiops:Average|acs_ecs_dashboard:disk_writebytes:Average|acs_ecs_dashboard:disk_writeiops:Average|acs_ecs_dashboard:load_1m:Average|acs_ecs_dashboard:load_5m:Average|acs_ecs_dashboard:memory_freespace:Average|acs_ecs_dashboard:memory_freeutilization:Average|acs_ecs_dashboard:memory_totalspace:Average|acs_ecs_dashboard:memory_usedspace:Average|acs_ecs_dashboard:memory_usedutilization:Average"}) by (instanceId, __name__) ', '1m') from metrics limit 1000000

配置智能巡檢任務

​

在【[SLS控制台](阿里雲登錄 - 歡迎登錄阿里雲，安全穩定的雲計算服務平台)】中找到【智能異常分析】的入口，經過簡單的初始化后，可以通過【智能巡檢】的任務入口進入，找到對應的配置頁面。在作業配置的過程中，應該注意這里要選擇時序庫，否則無法找到存儲雲監控數據的MetricStore。

​

在特征配置中，通過如下的Query進行配置，這里也有幾點需要注意的說明：

• 通過SQL轉寫一下，並對time字段進行處理，因為在巡檢中，接受的時間的單位是秒，而PromQL得到的結果中time是毫秒；
• 通過element_at算子，提取出對應的實例ID(instanceId)；
• 目前在配置粒度時，最小只支持60秒；

* | select time / 1000 as time, metric, element_at(labels, 'instanceId') as instanceId, value from ( select promql_query_range('avg({__name__=~"acs_ecs_dashboard:CPUUtilization:Average|acs_ecs_dashboard:DiskReadBPS:Average|acs_ecs_dashboard:DiskReadIOPS:Average|acs_ecs_dashboard:DiskWriteBPS:Average|acs_ecs_dashboard:DiskWriteIOPS:Average|acs_ecs_dashboard:InternetIn:Average|acs_ecs_dashboard:InternetInRate:Average|acs_ecs_dashboard:InternetOut:Average|acs_ecs_dashboard:InternetOutRate:Average|acs_ecs_dashboard:InternetOutRate_Percent:Average|acs_ecs_dashboard:IntranetOut:Average|acs_ecs_dashboard:IntranetOutRate:Average|acs_ecs_dashboard:cpu_idle:Average|acs_ecs_dashboard:cpu_other:Average|acs_ecs_dashboard:cpu_system:Average|acs_ecs_dashboard:cpu_total:Average|acs_ecs_dashboard:cpu_user:Average|acs_ecs_dashboard:cpu_wait:Average|acs_ecs_dashboard:disk_readbytes:Average|acs_ecs_dashboard:disk_readiops:Average|acs_ecs_dashboard:disk_writebytes:Average|acs_ecs_dashboard:disk_writeiops:Average|acs_ecs_dashboard:load_1m:Average|acs_ecs_dashboard:load_5m:Average|acs_ecs_dashboard:memory_freespace:Average|acs_ecs_dashboard:memory_freeutilization:Average|acs_ecs_dashboard:memory_totalspace:Average|acs_ecs_dashboard:memory_usedspace:Average|acs_ecs_dashboard:memory_usedutilization:Average"}) by (instanceId, __name__) ', '1m') from metrics ) limit 10000

​

在下面的【算法配置】、【調度配置】中需要注意如下：

​

【時間范圍】- 要選擇當前時間的兩天前，讓算法有充足的數據進行學習，這樣效果更好；

【數據延時時長】- 由於我們處理的是通過導入服務導入的雲監控的數據，一般整體的鏈路延時最多不會超過300s，因此這里要選擇300秒，防治觀測丟點。

配置告警

通過SLS中提供的[新版告警](告警（新版） - 日志服務 - 阿里雲)可以非常方便的對接機器學習的告警配置。您可以使用一整套告警的能力，對您的告警進行管理。

​

建議您使用普通模式卻設置告警，在【行動策略】這一欄中，選擇我們內置的行動策略(sls.app.ml.builtin)，這里我們已經配置好了，具體可以在告警配置中進行查看，查看地址具體：

https://sls.console.aliyun.com/lognext/project/${projectName}/alertcenter?tab=action_policy

​

這里您要制定對應的請求地址（釘釘機器人的地址webhook），內容模板選擇【SLS智能巡檢內置內容模板】。這樣可以將【告警配置】與【巡檢作業配置】解耦開來，后續用戶需求修改【巡檢作業】配置就可以實現告警配置的更新。至此，我們在【雲監控數據】中配置巡檢算法的操作就完成了。

原文鏈接
本文為阿里雲原創內容，未經允許不得轉載。 

​