2. 程式人生 > 其它 >智慧巡檢雲監控指標的最佳實踐

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

阿新 • • 發佈：2021-12-21

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

背景介紹

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

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

​

隨著各個雲上服務的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智慧巡檢內建內容模板】。這樣可以將【告警配置】與【巡檢作業配置】解耦開來，後續使用者需求修改【巡檢作業】配置就可以實現告警配置的更新。至此，我們在【雲監控資料】中配置巡檢演算法的操作就完成了。

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

​

相關推薦

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

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

高安全效能強，5G智慧巡檢機器人為智慧園區帶來幫助!

隨著中國智慧技術的提升，5G生活已經漸漸來到我們的身邊，它不僅僅能給您帶來網速上的提升，還能給智慧領域帶來更好的幫助，其中智慧巡檢機器人就是其中一種，目前智慧巡檢機器人已經在我國不少園區中使用

YARN 運維、巡檢、監控、調優、排障

1、巡檢YARN 為 Hadoop 叢集的上層應用，包括 MapReduce、Spark 等計算服務在內，提供了統一的資源管理和排程服務。每日早晚巡檢YARN 服務，主要檢查資源池內主機的健康狀態，保障 YARN 服務可用性。1.1、YARN CM 執

Aggregated APIServer 構建雲原生應用最佳實踐

作者 張鵬，騰訊雲容器產品工程師，擁有多年雲原生專案開發落地經驗。目前主要負責騰訊雲 TKE 雲原生 AI 產品的開發工作。

宜信智慧監控平臺建設實踐|分享實錄

摘要：介紹宜信智慧運維平臺UAVStack的設計思想、技術架構和核心功能，及落地實踐經驗。

彈性配置為構建提速 - CODING & 騰訊雲 CVM 最佳實踐

CODING 中提供了內建雲主機用來執行持續整合（CI）中的構建計劃，能夠勝任大部分構建任務。但如果碰上了大型專案的構建，或者需要在本地伺服器生成構建成果，單個計算資源就顯得有點捉急了。針對這一部分需求，CODIN

基於AM5728 DSP+ARM的智慧電力巡檢機器人設計

基於AM5728的智慧電力巡檢機器人設計 國家十二五規劃對電力系統固定資產投資建設的高峰結束，投資重點由基礎建設轉向智慧運維，電力裝置的監控、維護、保養等龐大的需求將得到充分釋放。傳統的人工巡檢的方

直播預告丨雲時代的資料庫客戶端——CloudQuery最佳實踐

在這個資料庫百花齊放的時代，資料庫相關產品正在迎來成長和發展的絕佳機遇，而資料平臺作為獲取資料、生產加工資料、交付資料的集合體，更是新基建的重要組成。CloudQuery作為一個優秀的資料操作平臺，能

騰訊雲容器服務日誌採集最佳實踐

概述 本文介紹如何利用騰訊雲容器服務 TKE 的日誌功能對日誌進行採集、儲存與查詢，分析各種功能用法與場景，給出一些最佳實踐建議。

直播預告 | 雲時代的資料庫客戶端——CloudQuery最佳實踐

在當前的工作中，我們開發人員在傳統資料操作過程中通常會遇到這樣一些問題： ①缺乏一致性。不同的資料庫使用不同的操作客戶端，像PL/SQL Developer、SQL Server Studio，不僅增加了操作成本，也加大了資料

直播預告 | 雲時代的資料庫客戶端 —— CloudQuery最佳實踐

在這個資料庫百花齊放的時代，資料庫相關產品正在迎來成長和發展的絕佳機遇，而資料平臺作為獲取資料、生產加工資料、交付資料的集合體，更是新基建的重要組成。CloudQuery 作為雲原生資料操作平臺，能夠幫

竣達機房環境微信雲監控技術，讓機房監控變得更智慧與簡便

一、裝置概述： 竣達機房環境雲監控終端（以下簡稱：4G·PRO）是一款基於UPS機房環境支援4G全網通（電信、移動、聯通）的監控產品。可支援監控1路UPS、多達5路的感測器輸入介面和3路的遠端控制輸出介

雲原生時代，企業多活容災體系構建思路與最佳實踐

​簡介：對於雲原生的概念解讀，大家經常會聽到微服務、容器這些，那麼這些技術跟企業容災到底有什麼樣的關係？其實容災的需求各行各業都有，比如金融行業對於容災也有強烈的需求。但是怎麼把容災和多活能力構建起來

最佳實踐丨使用雲函式+雲呼叫，四步搞定微信支付

概述 微信支付是雲開發原生支援的微信生態能力之一，開發者只需要簡單呼叫相應的函式即可完成整套支付流程，安全又高效。部分優勢包括：

MySQL checkpoint和巡檢指標說明

目錄 四個引數能反應出來什麼 引子 check point是做什麼的 作用 Checkpoint所做的事情

騰訊雲TDSQL PostgreSQL版 -最佳實踐 ｜優化 SQL 語句

檢視是否為分佈鍵查詢 postgres=# explain select * from tbase_1 where f1=1; QUERY PLAN --------------------------------------------------------------------------------

雲效自建測試自動化最佳實踐

雲效自建測試自動化最佳實踐，對於現代軟體研發來說，持續、快速、高質量、低風險地交付需求特性，是業務對研發的主要訴求。而要做到這一點，除了要有良好的架構設計、卓越的工程能力，快速可靠的測試反饋也是其非常

最佳實踐丨企業上雲後資源容量如何規劃和實施

簡介：企業上雲後，雲上的預算直接影響上雲的優先順序、進度、深度。預算投入的多少，與業務發展和資源需求的容量評估緊密相關。精準的容量評估，可以使企業上雲的預算規劃更科學，同時也更貼合業務發展階段的需要。

最佳實踐丨雲開發CloudBase多環境管理實踐

背景 雲開發 CloudBase 提供環境複製能力，方便開發者進行多環境下專案開發。

【手把手教程】uniapp + vue 從0搭建仿微信App聊天應用：騰訊雲TXIM即時通訊的最佳實踐

基於uniapp + vue 實現仿微信App聊天應用實踐，實現以下功能 1: 使用者登陸 2: 聊天會話管理