基于阿里云可觀測產品構建企業級告警體系的通用路徑與最佳實踐

前言

1.1 日常生活中的告警

任何連續穩定運行的生產系統都離不開有效的監控與報警機制。通過監控，我們可以實時掌握系統和業務的運行狀態；而報警則幫助我們及時發現并響應監控指標及業務中的異常情況。

在日常生活中，我們也經常遇到各種各樣的告警。例如，在駕駛傳統機動車時，儀表盤就如同一個高效的監控面板，清晰地顯示了行駛速度、發動機轉速、燃油量等關鍵指標。此外，車輛內部還監控著更多細節指標，如水溫、胎壓、剎車片磨損程度和冷卻液量等。一旦發現異常，如水溫過高、胎壓過低、剎車片磨損或冷卻液不足等問題，儀表盤會立即發出警告，確保駕駛員能夠迅速察覺并采取相應措施。

1.2 告警是 IT 系統穩定性建設的基石

報警在日常生活中隨處可見，同時起到了關鍵的作用。在 IT 領域，告警同樣是確保系統可靠性的基石。我們知道，沒有任何一套IT系統能夠達到 100% 的可靠性，因此我們的策略是不斷提升服務的可靠性。為了實現這一目標并確保服務的連續性，有許多不同的路徑可以選擇。在深入分析這些路徑之前，我們先來探討一下 IT 系統的可用性及相關理論基礎。

1.2.1 IT 系統可用性

在講解告警之前我們首先簡單聊一下 IT 系統的可靠性。2017 年，ufried 在《Resilient software design in a nutshell》中，對 IT 系統可用性的定義如下：

那么，不難看出系統可用性的指標從 2 個方面，即 MTTF（不出故障的時間）和 MTTR（出故障后的恢復時間）

  • MTTF： 全稱是 Mean Time To Failure，平均無故障時間。系統平均能夠正常運行多長時間，才發生一次故障。也就是說系統的可靠性越高，平均無故障時間越長。
  • MTTR： 全稱是 Mean Time To Repair，平均修復時間。即系統出故障后的恢復時間，MTTR 越短表示易恢復性越好，系統可用性越高。

1.2.2 IT 系統穩定性建設理論

在 IT 系統穩定性建設中，穩定性建設的中心指導思想就是提高 MTTF（無故障時間）以及降低 MTTR（故障后的恢復時間）。

那么我們仔細來分析一下這個過程：

1）提高 MTTF： 換言之，使用各種技術、流程機制等手段去規避故障的發生，降低故障的發生概率，盡可能提高業務的連續性。比如：

  • 技術維度：在架構設計階段考慮高可用設計、同城/異地容災、彈性架構等能力；在編碼階段遵守相關編碼規約、考慮防護編程、遠程超時、資源隔離、有界隊列、合理的設計模式等；測試階段嚴格考慮單元測試覆蓋率、集成測試、性能測試、回歸測試、故障演練等；這里暫不一一展開。
  • 機制維度：推行變更 3 板斧-可灰度、可觀測、可回滾；引入故障等級機制；獎懲機制等。
  • 文化上：穩定性相關制度與文化的宣導、培訓、考試等。

2）降低 MTTR： 我們知道 MTTR 越短，表明系統故障恢復得越快，服務的可用性也就越高，MTTR 可以進一步細分為以下幾個部分：MTTR = MTTI + MTTK + MTTF + MTTV。

  • MTTI： 全稱 Mean Time To Identify，平均故障發現時間，即從故障發生到被識別的時間。
  • MTTK： 全稱 Mean Time To Know，平均故障認知時間，即從故障被識別到被確認的時間。
  • MTTF： 全稱 Mean Time To Fix，平均故障解決時間，即從故障確認到實際解決問題的時間。
  • MTTV： 全稱 Mean Time To Verify，平均故障修復驗證時間，即從故障解決到驗證修復效果的時間。

狹義 MTTR 為 MTTR = MTTI + MTTK + MTTF。

在穩定性建設中，MTTR 的縮短是核心目標之一。而告警能力建設可以有效縮短 MTTI， 同時好的告警體系建設同樣可以助力縮短 MTTK 的過程，從而加快整個 MTTR 的進程。

1.2.3 安全生產理念

在數字化轉型加速的當下，企業業務不斷向數字化邁進，服務用戶數量激增，導致 IT 系統的復雜性日益增加。特別是在政府和金融等行業，業務連續性和穩定性已成為制約發展的關鍵因素。微服務架構與容器化的引入雖然提高了應用的靈活性，但也帶來了龐大而復雜的系統關系，使得故障頻發且難以定位。針對這一挑戰，阿里云推出了云原生安全生產解決方案。該方案以故障管理為核心，遵循“1-5-10”原則（即 1 分鐘內發現問題、5 分鐘內定位問題、10 分鐘內恢復），并圍繞故障生命周期的三個階段——事前預防、事中快速響應及恢復、事后防止再發生，構建全面的應對機制。通過提供專業的技術咨詢和支持，確保這些機制能夠有效實施，從而保障業務持續穩定運行，并將資產損失控制在最低限度。

個人理解 1-5-10 安全生產體系本質上是對 MTTR（平均修復時間）的一種 SLA（服務水平協議）承諾。而我們今天關注的核心和主題是“告警”。告警在整個安全生產體系中扮演著至關重要的角色，它是 1-5-10 理念中第一個環節——1 分鐘內發現問題（即 MTTI，平均檢測時間）的具體體現。告警系統不僅能夠及時發現潛在問題，還能迅速觸發響應機制，確保在最短時間內定位并解決問題。因此，告警功能直接牽引著整個安全生產體系的運行，其效果直接影響到安全生產體系實施的成敗。可以說，告警是保障系統穩定性和可靠性的基石。通過高效的告警機制，我們可以更早地識別和處理故障，從而最大限度地減少業務中斷和資產損失。

今天的文章我們將圍繞告警進行展開，重點討論企業級告警體系構建的通用思路和方法論，比如如何設置報警、如何有效地管理告警、如何與安全生產體系結合等，最后給出相關客戶的實踐案例和落地方案，通過這些內容，我們希望能夠為企業提供一套全面且實用的告警體系建設指南。

告警體系建設通用流程

首先我們分析一下完成系統監控報警的一般流程是什么樣的？我們可以抽象為如下的幾個環節：

1）監控對象梳理

首先，必須明確需要監控的對象，分析出哪些對象需要被監控。通過對系統進行分層梳理，識別出關鍵組件和服務，確保所有重要部分都不會被遺漏。在此基礎上，對當前的監控配置進行逐層檢查，查找不足之處，以提升系統的監控覆蓋率。

2）監控指標分析

其次，分析出監控這些對象的哪些維度和指標。通過監控對象分層梳理、對象的指標維度分析，綜合監控的評價標準，得到業務系統配置監控所需的「對象和指標表」，為后續的監控實施奠定基礎。

3）監控指標采集

一旦確定了監控指標，接下來就是數據的采集工作。選定可靠的數據來源以及合適的采集周期，將監控指標的數據匯集至相關的可觀測系統（如阿里云云監控、SLS、ARMS 等）。在此過程中，對采集到的數據進行必要的清洗和處理，最終借助可視化工具，以圖表的形式展示數據，便于對系統狀態進行直觀分析和理解。

4）告警規則配置最后，合理配置告警規則與通知策略是告警建設的重要一步。通過設定統計閾值，來判斷某一監控指標是否出現異常，并基于告警等級，通過即時消息工具（如釘釘）、短信或電話等方式，迅速通知相關的運維值班人員，以便他們能夠及時響應和處理潛在問題。

2.1 監控對象梳理

為實現全局視角下的監控覆蓋，關鍵在于采用分層架構對監控對象進行全面梳理，識別各層級的關鍵監控要素。一個完備的監控體系通常包含以下層級結構：

分層分層說明分層主要對象可用于監控的對象
業務層（含終端體驗層）業務本身以及業務入口載體業務邏輯、終端入口業務邏輯、業務核心鏈路，如電商場景的購物車、下單、支付等關鍵環節
應用層業務的“系統”載體應用（微服務）本身應用本身，如進程狀態、API接口
依賴層（服務/系統）業務的服務/系統依賴下游微服務依賴或者中間件（云服務）下游依賴的微服務、中間件和基礎服務，比如常見的阿里云云服務Kafka、RocketMQ、RDS、Redis等
基礎設施層業務的物理承載容器、主機、網絡可用對象的屬性或者子對象進行替代，如CPU、MEM、DISK、端口、網絡等

通過上述層級劃分可見，不同層級的監控對象對業務連續性的影響程度呈現遞減趨勢。舉例而言，單臺服務器的異常可能不會直接影響業務運行，但核心業務流程（如訂單處理）的故障必然導致業務中斷。因此，在實際監控策略制定中，應依據層級重要性差異設置相應的告警級別和響應機制，將監控重點放在那些對業務影響較大的層面上。

2.2 監控指標分析

監控對象需要進行數字化衡量，那么指標是最佳的度量方式與形態，通過指標與維度從而實現監控對象的分析。那么有哪些常用的指標呢？下面列舉四大類常用“黃金指標”如下：

指標類型指標類型描述數量和質量指標示例
流量類型指標請求對象的量級情況（單位時間）次數、頻率，吞吐量、吞吐率業務層如：頁面或者功能的QPS、PV、UV服務/系統依賴層如：請求下游服務QPS、Redis讀寫QPS基礎設施層如：磁盤和網卡IO
錯誤類型指標對象發生錯誤情況錯誤數、錯誤率業務層如：核心功能錯誤應用層如：端口掛掉、進程假死服務/系統依賴層如：請求下游服務錯誤、寫DB錯誤基礎設施層如：宕機數、網絡丟包率等
延遲類型指標請求對象所需時間情況RT、超時數、超時率業務層如：核心功能響應時長應用層如：接口RT服務/系統依賴層如：請求下游服務RT、讀DB RT基礎設施層如：IO wait
飽和度類型指標對象被利用的情況（總量有限）利用數、利用率業務層如：業務能處理的閾值應用層如：流量占比接口限流閾值等服務/系統依賴層如：請求量占比下游服務限流閾值、DB實例連接數、MQ消息堆積數基礎設施層如：CPU、內存、磁盤和網絡利用率、文件句柄數

結合上面的分層對象和四類指標，分析出各個分層對象的“具體指標”：

基于維度的分析

在指標分析中，維度分析是重要組成部分。常見的監控告警主要采用時間維度，即對比監控對象在時間序列上的變化。此外，屬性維度也是重要的分析視角。

多維度結合分析

在監控指標分析中，雖然單一維度的分析至關重要，但僅依賴單維度配置往往容易產生誤告，或增加問題根因定位的復雜度。此時，采用多維度的告警策略顯得更為合理。以應用的 QPS（每秒查詢率）為例，如果僅基于固定閾值設置告警，可能會因流量波動或業務周期性變化而頻繁觸發誤報。通過引入多維度分析（如結合時間趨勢、業務場景、資源利用率等），可以更精準地識別異常，減少誤告率，并提升問題排查效率。

以下針對 QPS 閾值場景進行細化分析，并結合 RT（響應時間）指標設計檢測機制，列舉幾種典型場景及其應對策略：

  • 場景 1： 流量上升、RT 變化不明顯。表明系統當前處理能力充足，尚未達到性能瓶頸，但仍需持續監控，以防潛在風險。
  • 場景 2： 流量上升、RT 也同步增加。此場景提示系統性能可能接近上限，RT 與流量呈正相關關系。此時需重點關注 QPS 指標，并結合 RT 閾值設置合理的告警規則，以便及時預警性能瓶頸。
  • 場景 3： 流量無明顯變化、RT 增加。可能由服務依賴（如網絡延遲、下游服務性能下降）或系統內部問題引起。需深入排查依賴服務狀態，并結合其他指標進行根因分析。
  • 場景 4： 流量下降、RT 變化不明顯。該情況可能為正常的入口流量降低，也可能為異常場景，需要結合其他指標或者業務場景經驗進行綜合判斷。
  • 場景 5： 流量下降、RT 降低。與場景二類似，但表現為反向趨勢。可能反映系統負載減輕，仍需結合上下文分析是否為正常現象或潛在問題。

2.3 監控指標采集

基于阿里云可觀測產品構建有效的全棧監控體系，這里不進行展開，詳細參考文檔：https://www.aliyun.com/product/arms

2.4 告警規則配置

2.4.1 告警設置基本原則

在進行告警規則配置之前，我們需要明確以下告警的基本原則。

  • 告警具備真實性： 告警的真實性是最為關鍵的原則。每一條告警都必須基于實際存在的問題或潛在風險，確保其能夠真實地反映出服務當前的狀態，而非偶發性波動或外部干擾。這樣能及時預警并采取行動，避免更嚴重的問題發生。
  • 反模式示例：若請求失敗量因臨時網絡抖動而觸發告警，實則系統本身無故障，此類告警即喪失真實性。
  • 常用最佳實踐：引入異常檢測算法區分正常波動與真實異常；對告警觸發條件疊加多維度過濾（如請求來源 IP、用戶行為特征、業務場景標簽）等。
  • 告警表述需詳細： 從內容上，告警要近可能詳細的描述現象，包括具體的時間、地點和異常情況等，比如服務器在某個時間點具體發生了什么異常，便于快速定位和處理問題。
  • 告警具備可操作性： 每當收到告警時，相關人員通常需要采取一定的措施來處理問題，對于某些無須做出操作的告警，最好取消或者調整。告警系統設計應確保僅在確實需要執行操作時觸發通知，避免信息過載和資源浪費。
  • 反模式規避：對無需人工介入的告警（如自動恢復的瞬時錯誤），應降級為日志記錄或納入統計報表。
  • 最佳實踐：定義分級策略、明確報警責任歸屬、設置自動化聯動策略（自動觸發應急預案）等。
  • 新告警使用保守閾值： 在配置告警之初采用保守閾值+寬覆蓋策略，應盡可能擴大監控告警覆蓋面，選取保守的閾值，盡可能避免漏報，然后逐步收斂至精準狀態。

  • 告警需要持續優化： 通過 PDCA 循環（Plan-Do-Check-Act）實現告警系統的自我進化與持續優化，我們應該持續對告警進行統計分析，對誤報現象加以研究并采取有效應對措施，如屏蔽無效告警、簡化信息反饋、調整閾值或更精準地反映異常原因。這是一個長期而持續的過程，需要不斷迭代和完善。

以請求失敗舉例，如僅當請求的失敗量超過某一閾值時告警，可能存在多種原因，如一些惡意構造的請求，也觸發失敗量告警。這樣的告警既不具備真實性，也不具備可操作性，因為確實無需任何處理。對于此類情況，我們應該盡可能通過特性加以識別，從而更加精準地區分不同原因的告警，以提高告警的準確性和有效性。

2.4.2 告警等級定義

使用告警時，一個典型的問題就是告警信噪比低，工程師往往被海量低質量告警淹沒，解決這類問題，有一個非常好的突破口就是定義告警等級標準。告警等級定義可以參考阿里巴巴集團關于故障級別的定義。這一方法的基本思路是根據預警的影響程度和業務特性來劃分告警等級，從而確定信息傳播的媒介、受眾以及相應的標準操作流程（SOP）。通過這一方式，不同級別的告警可以被更合理地分類和處理，使得工程師能夠迅速識別最關鍵信息，集中精力應對高優先級的問題。此外，建立清晰的告警等級體系還可以促進團隊之間的溝通與協作，提高整體響應效率和質量。

在阿里云可觀測系統（如 ARMS）中一般采用通用 P 等級進行衡量（P1、P2、P3、P4）。

1）方式 1：按照客觀的標準進行 P 級定義

如下為針對應用重要性進行劃分，按照影響面進行告警的 P 級別定義參考的標準。

2）方式 2：按照主觀進行 P 級定義

等級定義方式
P4需要采取行動的小問題，但是不影響客戶的使用
P3需要運維人員立即關注的穩定性問題或者影響客戶使用的小問題
P2嚴重言行需要客戶使用的產品的關鍵性系統問題
P1需要立即聯系管理/運維團隊進行處理的關鍵性問題，如果不處理后果非常嚴重

該方式需要相關領域的同學（研發/運維）參與，結合專家經驗進行主觀評估。在實際的執行過程中不同的報警設置人員可能在定義上存在隨意的現象，所以建議進行報警等級的 review。

2.4.3 告警通知策略標準

上面提到了告警等級，依據告警等級以及告警觸發場景進行分渠道通知，保障核心告警不被忽略，同時非核心告警可以在一定時間窗口響應，減少工程師響應疲勞度，提升工程師幸福度。阿里云可觀測產品多種通知策略（如常用的語音、短信、郵件、IM 即時消息和群組通知），每種方式都有其特定的應用場景，具體如下表所示：

通知渠道適用場景
語音核心告警，一定是可能或者已經產生故障且需要告警接收人立刻響應的場景；非核心告警，一律不準使用語音
短信核心告警，一定要推送短信，語音通常難以辨識告警內容；非核心告警，除了需要及時響應的場景除外，一律不需要推送短信
IM消息（如釘釘）核心告警，推送語音、短信的同時也需要推送一份釘釘消息，方便開發者查看；非核心告警，不需要推送語音、短信的，推送釘釘群的同時推送釘釘消息
IM群（如釘群）核心告警；多群、多人聯動等場景

那么結合報警P級別的定義，建議采用如下的通知渠道：

等級定義方式
P4IM通知（如釘釘）
P3短信+IM通知（如釘釘）
P2短信+IM通知（如釘釘）配合升級策略確保問題在規定的時間內得到處理
P1語音+短信+IM通知（如釘釘）配合升級策略確保問題在規定的時間內得到處理

告警的幾個重要問題

在告警系統選型以及告警體系的建設當中，如下的幾個問題需要重點關注。

3.1 多平臺告警問題

在云原生時代，企業 IT 基礎設施的規模越來越大，越來越多的系統和服務被部署在云環境中。為了監控這些復雜的 IT 環境，企業通常會選擇使用異構監控系統，例如 Prometheus、Grafana、Zabbix 等，以獲取更全面的監控數據，然而，這種異構監控系統也帶來了一些問題，其中最顯著的是告警信息的分散。由于不同的監控系統可能會產生不同的告警信息，這些信息可能會分散在各個系統中，導致企業很難全面了解其 IT 系統的告警狀況。這使得響應告警變得更加困難，同時也增加了人工管理的復雜性和工作量。如何針對這些異構的告警事件進行管理是一個需要考慮的問題。如下是常見的幾個潛在的場景：

場景一：

企業遷移上云后，云上產品的告警不統一

在一個典型的云原生業務應用部署架構中，通常會使用到如下產品 ACK、ECS、RDS，應用通過 Kubernetes 部署在阿里云的 ECS 上并訪問云上的 RDS。在這個架構中通常會用到如下監控產品來對系統進行監控。

  • 通過 CloudMonitor 對阿里云基礎設施 ECS 和 RDS 進行監控，當資源出現異常時進行告警。
  • 通過 Prometheus 對 Kubernetes 以及部署在 Kubernetes 上的 Pod 進行監控，當 Kubernetes 出現異常時進行告警。
  • 通過 ARMS 對部署在 Kubernetes 上的應用進行監控，包括應用直接的調用量。當應用異常時進行告警。
  • 通過 SLS 對應用產生的日志進行監控，當日志出現異常時進行告警。

場景二：

多云、混合云架構下，異構監控系統告警不統一

場景三：

自研監控系統、自定義事件告警接入

所以企業在構建或者選型告警系統的時候需要提前考慮這種多平臺告警的問題，是否需要引入管理多源告警問題。

3.2 告警誤報問題

在選擇告警系統、配置告警規則的時候，告警誤報是我們需要考慮的重要因素。理想中的告警，不存在誤報（即本來正常的，告警為異常），出現告警就需要處理，如果誤報的告警太多，處理的告警的同學會產生困擾、造成資源的浪費，同時也容易產生“狼來了”的問題。

盡可能精細化告警設置

告警一般是通過“現象”來判斷，而是否有問題要看產生現象的原因判斷。相同的現象引起的原因可能不同，這種“可能性”是導致誤告警的最核心原因。如果能減少到唯一的原因或者盡可能少的原因，那就能很明確問題所在。

考慮告警的齊全度齊全度是一段時間內實際采集落盤的指標樣本數量占期望收集到的樣本數量的比率（%），是個時序數據，但是隨著時間推移會發生變化。比如監控一千個副本的交易應用的 QPS，這個指標需要結合一千個數據進行疊加，如果沒有數據齊全度的概念，若配置 QPS 相比降低 2% 告警，由于網絡波動，超過 20 個副本上報的數據延遲幾秒，那就會觸發誤報。因此在配置告警的時候還需要結合數據齊全度數據進行綜合考慮。

3.3 告警風暴問題

在告警系統的選型以及告警設置中，告警風暴問題的重要性尤為突出，每個研發/運維同學單日處理的告警數據量是有限的，如果產生告警風暴，重要的告警將會淹沒，同時也會加劇運維同學的負擔，降低幸福感。如下為常見的一些原則：

  1. 告警等級劃分： 將不同等級的告警進行分開管理；
  2. 過濾無關告警： 基于預設的規則過濾掉不重要的告警；
  3. 使用壓縮、靜默等手段進行告警收斂， 所以在告警系統選型的時候需要重點關注是否具備該項能力；
  • 壓縮：將匹配到的告警事件壓縮為一個告警或者按照分組壓縮為多個告警。可以進一步設置是否需要按照指定 Label 進行分組，每個分組有單獨的告警觸發、發送和恢復的生命周期，可以單獨進行發送、恢復和管理。如下的是常見的幾種壓縮策略：
  • 基于標簽壓縮：當滿足條件的多條事件包含相同的標簽時，將會自動壓縮成一條告警進行通知。

  • 基于時間壓縮：標簽相同的告警如果開始時間和結束時間有交集，則會合并為一個告警事件，合并后的告警事件的開始時間和結束時間取這兩個告警事件的并集。

  • 靜默：將匹配到的告警事件全部標記為靜默，這意味著其他通知策略無法再匹配到這些事件。可以進一步設置靜默規則生效的時間段，任何符合條件的告警事件都會被標記為靜默事件，并在此期間內無法被任何通知策略觸發。

3.4 告警如何處置

當告警觸發時，需要設計一套完整的處理機制，而不僅僅是簡單的通知發送。一個完善的告警處理流程應包含認領、屏蔽、回調、標注、升級和關閉等關鍵環節，以確保告警得到有效管理和快速響應。

告警認領

當告警觸發后，相關人員可主動認領該告警，認領后相同告警將僅發送給認領人。這一機制旨在避免告警被多人重復處理，同時明確責任人，提升處理效率。認領狀態支持取消，以便靈活調整處理人員。

告警屏蔽

針對已知問題或特定場景（如故障定位期間或服務發布過程中），可設置告警屏蔽規則，屏蔽期間相關告警將不再發送。屏蔽支持按周期或時間段配置，也可隨時取消。此功能有效減少無效告警對運維人員的干擾，提升告警管理的精準性。

告警回調

告警規則可配置回調接口，當告警觸發時自動執行預設的恢復操作。通過自動化手段快速恢復服務，縮短故障修復時間（MTTR），尤其在緊急情況下，能夠顯著提升系統可用性。

誤告標注

用戶可對告警進行誤報標注，記錄告警是否為誤報。誤告標注的主要目的是通過標注讓系統開發人員知道異常檢測過程中，哪些點還需要提升優化，提高告警的準確性，為用戶提供真實有效的告警提供保障。

告警升級當告警發生一定時間仍沒有恢復，那么系統就會根據配置自動進行告警升級處理，然后將告警升級信息通過配置發送給對應的人員。告警升級一定程度上是為了縮短 MTTA，當告警長時間未恢復，可以認為故障沒有及時得到響應，這時就需要更高級別的人員介入處理。

案例分享

4.1 客戶背景

某著名垂直電商 A 公司目前已經進入深度用云的階段，公司目前面臨如下的問題：

  • 監控覆蓋不足與告警配置欠佳： 公司初期主要依賴云監控工具對云資源進行監控，忽視了應用層和業務層的監控需求，導致無法全面掌握應用的實際運行狀態。同時，告警閾值設置缺乏科學性，存在漏報、誤報和錯報現象，且告警等級劃分不清晰，難以區分問題的緊急程度和優先級。
  • 告警資源權責劃分： 公司云資源及應用分散在 30 多家供應商中，作為統一運維團隊，需要在告警信息中明確標注資源歸屬，以便快速劃分責任。同時，需將歸屬明確的告警信息及時傳遞給相應供應商，由其進行處理和響應。

  • 全局告警管理與供應商能力評估： 公司管理層（如 CTO、架構師）及運維團隊亟需建立統一的告警管理平臺，實現對多源告警事件的集中監控和分析。運維團隊期望通過單一視圖整合所有供應商的告警數據，便于進行橫向（供應商間）和縱向（時間維度）的對比分析，從而科學評估各供應商的服務水平與能力。

4.2 設計思路與實現

方案的建設思路：

  • 針對現有的監控資源進行梳理，明確需要監控的對象。
  • 制定標簽的標準，針對現有的資源進行全面打標；對于新增的資源納入開服/新增資源的 SOP 中下發到各個供應商。
  • 為了防止資源打標的遺漏或者后續供應商尚未按照規范對云資源進行打標，內部建立腳本巡檢程序針對資源進行每日的檢測，不符合規范的進行透出、報警、通曬治理（當前策略已經同步，正在治理中）。
  • 選擇、設計相應的監控指標，基于現有阿里云可觀測產品的能力進行監控指標的接入與告警配置，部分不支持的監控指標采用自研的方式進行實現。
  • 使用 ITSM 進行告警策略的分發。
  • 定制統一的告警管理大盤。

4.2.1 監控對象梳理

客戶 A 的大部分資源都部署在阿里云上，整個的技術架構也是比較典型的電商微服架構體系，部分應用部署在阿里云容器服務 ACK 中，少部分應用由于技術或者客觀原因部署在阿里云 ECS 上，底層中間件/存儲使用了 RDS、MongoDB、Redis、Clickhouse、Kafka、RabbitMQ、ES、OpenSearch、Flink、SLS、OSS、NAS等，接入層使用了DDos、WAF、SLB（CLB）等。

按照分層設計（自上而下）的理念，用戶進行如下的分層劃分：

4.2.2 定標準

用戶這里的定標準涉及多個方面，本質上都是立足安全生產，圍繞業務高效、可靠、穩定的運行展開。

標簽規范

用戶之前標簽規范有多個版本（但是都存在一些問題），在進行交流后最后成型，關于標簽的設計與最佳實踐可以參考《一文詳解阿里云可觀測體系下標簽最佳實踐》。

日志規范

用戶在日志規范部分詳細地介紹了輸出日志的原則與標準，這里摘錄部分信息。

1、如何打印日志：

  • 日志需接入阿里云SLS方便查詢和分析，同時按照應用進行區分。
  • 打印日志時一定要打印方便定位和排查的字段，例如用戶的id，request內容等。
  • 生產環境敏感信息進行mask打印。
  • 手機號僅顯示后四位（手機號有可能作為排查日志的唯一標記，建議保留后四位，如果有其他唯一標識，建議不打印手機號）。
  • 用戶郵箱不打印日志。
  • 用戶詳細地址不打印日志。
  • 涉及到錢賬戶的不打印日志，如銀行卡、微信/支付寶賬號。
  • 開啟日志Tracing功能，這樣同一個請求會生成同樣的trace，可以串聯和分析整個請求鏈路。
  • 調用第三方服務前，打印請求內容。
  • 調用第三方服務后，打印原始返回結果。
  • 操作數據庫/Redis/Kafka后打印結果。
  • 系統出現異常時，打印錯誤具體信息
  • 核心業務計算時，打印重要步驟結果，方便出錯時回溯計算流程。
  • 經常會引起客訴的情況。

2、審計日志

  • 敏感數據：上傳、下載、查看敏感數據等動作。
  • 敏感操作：刪除、更新等動作。

3、日志等級

  • 目前常見的日志分為四種，生產環境一般開啟info及以上的日志，測試環境可以開始debug級別的日志
  • debug: 打印一些debug信息，比如每個步驟結果，主要是為了測試環境排查問題而用，生產環境一般只會打印info及以上。
  • info：常規的信息，例如接收到的請求。
  • warn：代碼發現異常情況但又不影響業務邏輯繼續情況，如某個重要參數為空（但不影響業務邏輯往下繼續）
  • error：影響業務邏輯的異常情況，包括但不限于以下情況如調用第三方失敗、接口參數校驗失敗、數據庫/Redis/Kafka調用失敗、系統異常。
  • 日志需要按照應用/類型進行物理區分隔離，方便日志檢索與告警設置。

這里有一個核心的點就是定義了日志接入了 SLS 的規范，按照應用進行區分，這就為后續基于日志進行報警配置供應商的分發打下的基礎。

4.2.3 標準實施

標準實施包含多個環節，如下為標簽的實施細則，其他標準的實施不在這里展開。

1）存量資源進行打標的動作

標簽關系的建立目前主要分為手工頁面配置方式以及 API 方式，詳細參考文檔《一文詳解阿里云可觀測體系下標簽最佳實踐》。

  • 手工頁面方式：進入到各個云產品控制臺以及可觀測控制臺中體驗監控、應用監控等模塊，手工將對應的標打上即可。
  • API 方式：可以使用阿里云標簽服務的接口 TagResources [ 1] 完成打標，如下 Git 倉庫的 demo [ 2] 為使用 Tag API 替 SAE 應用、ARMS 應用監控進行打標。
  • 其他：對于無法通過 API 或者頁面配置的主要集中在容器場景，可以在對應的 yaml 中進行聲明。

2）新資源接入規范

該部分主要為客戶 A 運維團隊在新應用、資源申請的時候，內部 SOP 中規定的一個必要步驟。為了防止有漏網之魚，運維團隊內部編寫了定時腳本針對線上資源進行掃描，強制檢查規范，對于不符合規范的資源進行通知以及通曬。

4.2.4 監控指標梳理

客戶 A 主要使用云監控對云產品資源進行進行監控，按照分層梳理監控對象的里面重新進行監控的梳理，補齊相關缺失項，覆蓋應用/前端監控（ARMS）、業務監控（使用 SLS 日志監控），如下為部分應用監控告警梳理截圖，詳細配置列表樣例可以提工單聯系 ARMS 服務賬號。

4.2.5 報警配置

4.2.5.1 告警配置

客戶 A 的報警配置主要集中在 ARMS（應用監控、Prometheus）、云監控以及日志服務上。

  • 云監控告警配置：可參考 https://help.aliyun.com/zh/cms/user-guide/create-an-alert-rule
  • ARMS 告警配置
    • 應用監控告警配置：可參考 https://help.aliyun.com/zh/arms/application-monitoring/user-guide/create-and-manage-alert-rules-in-application-monitoring-new
    • 前端監控告警配置：可參考 https://help.aliyun.com/zh/arms/browser-monitoring/user-guide/create-and-manage-browser-monitoring-alert-rules
    • Prometheus 監控告警配置：可參考 https://help.aliyun.com/zh/arms/prometheus-monitoring/create-alert-rules-for-prometheus-instances
  • SLS 告警配置：可參考 https://help.aliyun.com/zh/sls/user-guide/alerting/
4.2.5.2 基于標簽進行告警事件分發

通過在云資源上進行打標，進而在告警事件上支持相關標簽，從而實現告警事件的分發。

圖中為解決方案的示意圖，其中階段1&階段2中的綠色部分表示阿里云當前已經支持的能力，灰色部分為正在支持中。

1）ARMS 應用監控告警配置

應用監控的告警規則需要打上這個標簽 enrich_app_labels:true，這樣應用標簽和實例標簽就會富化到對應的告警事件里面。然后自定義的應用標簽會自動加上這個前綴：arms_app_lable_{自定義應用標簽key}，自定義的實例標簽會自動加上這個前綴：arms_app_host_lable_{自定義實例標簽key}。

2）Prometheus 告警設置

用戶的場景為配置相關容器的監控告警，Node、Service、Pod 等這些資源在部署的時候會嚴格按照規范帶上相關的 label。如下為用戶針對節點設置節點相關的報警“容器節點內存使用率超過 85%”。

  • 前提-針對容器節點進行打標。
  • 在 ARMS 控制臺 [ 3] 的 Prometheus 監控 > Prometheus 告警規則進行 Prometheus 告警的設置，告警名稱為容器節點內存使用率超過 85% ，檢測類型為自定義 PromQL，自定義 PromQL 語句設置為 (sum(container_memory_working_set_bytes{id!=“/”,container!=“”}) BY (instance, name,container, pod_name , namespace) / sum(container_spec_memory_limit_bytes{id!=“/”} > 0) BY (instance, name, container, pod_name , namespace) * 100) > 85，其他告警參數的配置，請參見 Prometheus 告警規則 [ 4] 。
  • 告警中使用注釋對告警進行打標，相關 node 的標從 kube_node_labels 獲取。

  • 鍵：_aliyun_arms_enrich_desc。
  • 值：可執行的 PromQL，支持通過 KaTeX parse error: Expected '}', got 'EOF' at end of input: …de_labels{node={node_name}}，示例中使用了 ${node_name} 來引用節點名稱。
  • 結果：告警事件中會增加 node 相關的 label。

擴展案例：

通過阿里云標簽（Tag）分發告警

通過Kubernetes Label分發告警

3）日志服務告警設置

日志服務 SLS 的告警設置詳細參考文檔：https://help.aliyun.com/zh/sls/user-guide/sls-alerting/

由于用戶在規范中定義了各個微服務應用按照不同的 logstore 進行區分，所以針對 logstore 的告警設置能夠明確地知道當前日志歸屬于哪個應用。該部分目前采用靜態標簽(標注)進行設置如下所示：

4）云監控告警設置

當前云監控側站點撥測不支持靜態與動態打標的方式、基礎云監控報警不支持動態標簽的方式。目前可以支持將云服務接入 Prometheus [ 5] , 使用 Prometheus 的方式進行繞開解決。

4.2.6 對接 ITSM

客戶 A 采用 ARMS 作為統一告警管理平臺 [ 6] ，首先需要集成云監控以及 SLS 中的告警（ARMS 中告警默認支持）, 最后進行通知策略的配置。

4.2.6.1 告警集成

  • 集成云監控告警
  • 創建集成并接入云監控，獲取云監控集成回調地址

  • 創建集成并接入云監控，獲取云監控集成回調地址
  • 修改云監控告警規則，將告警發送至 ARMS

  • 集成 SLS 告警
  • 創建集成并接入日志服務

  • 日志服務創建 webhook 集成，在對應的 project 的告警中心創建 webhook 集成，用于告警回調

  • 修改日志服務告警規則，將告警發送至 ARMS

  • ARMS 中配置通知策略，詳細參考通知策略最佳實踐

4.2.7 報警事件統一大盤

如下為客戶 A 基于 ITSM 構建的告警事件統一大盤，通過該大盤用戶能夠直觀將來自云監控、日志服務、ARMS 的告警事件進行集中的展示、管理。

當前客戶正在推動度量供應商的服務水平與能力，這個涉及到 SLO 相關的能力建設，該部分將在后續的文章中繼續展開探討。

總結

本文圍繞告警進行展開，重點討論企業級告警體系構建的通用思路以及在進行告警系統選型或者建設中需要關注的重點問題，最后結合阿里云可觀測產品給出線上客戶的實踐案例，希望能夠為企業提供一套全面且實用的告警體系建設指南與參考。

參考文檔：

[1] 面向多告警源，如何構建統一告警管理體系？

https://my.oschina.net/u/3874284/blog/9914048

[2] 通知策略最佳實踐

https://help.aliyun.com/zh/arms/alarm-operation-center/best-practices-for-notification-policies

[3]《一文詳解阿里云可觀測體系下標簽最佳實踐》

[4] 通知策略配置流程

https://help.aliyun.com/zh/arms/alarm-operation-center/create-and-manage-notification-policies

[5] 告警通知群@指定處理人

https://help.aliyun.com/zh/arms/alarm-operation-center/mention-contacts-with-at-sign-in-single-group-chat

[6] 通過 Kubernetes Label 分發告警

https://help.aliyun.com/zh/arms/alarm-operation-center/use-k8s-labels-to-dispatch-alerts

[7] 通過阿里云標簽（Tag）分發告警

https://help.aliyun.com/zh/arms/alarm-operation-center/use-alibaba-cloud-tags-to-dispatch-alerts

相關鏈接：

[1] TagResources

https://help.aliyun.com/zh/resource-management/tag/developer-reference/api-tag-2018-08-28-tagresources

[2] demo

https://github.com/OuyangKevin/CloudAssistantTool/tree/main

[3] ARMS 控制臺
https://account.aliyun.com/login/login.htm?oauth_callback=https%3A%2F%2Farms.console.aliyun.com%2F#/home

[4] Prometheus 告警規則

https://help.aliyun.com/zh/arms/prometheus-monitoring/create-alert-rules-for-prometheus-instances?spm=a2c4g.11186623.0.0.2ad9dc86qV6dTL#task-2121615

[5] 云服務接入 Prometheus

https://help.aliyun.com/zh/arms/prometheus-monitoring/data-access-via-access-center

[6] 統一告警管理平臺

https://help.aliyun.com/zh/arms/alarm-operation-center/product-overview/alarm-management-overview

本文來自互聯網用戶投稿，該文觀點僅代表作者本人，不代表本站立場。本站僅提供信息存儲空間服務，不擁有所有權，不承擔相關法律責任。
如若轉載，請注明出處：http://www.pswp.cn/diannao/76796.shtml
繁體地址，請注明出處：http://hk.pswp.cn/diannao/76796.shtml
英文地址，請注明出處：http://en.pswp.cn/diannao/76796.shtml

如若內容造成侵權/違法違規/事實不符，請聯系多彩編程網進行投訴反饋email:809451989@qq.com，一經查實，立即刪除！

相關文章

智能多媒體處理流水線——基于虎躍辦公API的自動化解決方案

智能多媒體處理流水線——基于虎躍辦公API的自動化解決方案

在內容爆炸的時代，多媒體文件處理（圖片壓縮、視頻轉碼、音頻降噪）已成為內容生產者的日常挑戰。本文將演示如何基于虎躍辦公的多媒體處理API，構建自動化處理流水線，實現： 批量文件智能分類格式自動轉換質量…
閱讀更多...
01-STM32（介紹、工具準備、新建工程）p1-4

01-STM32（介紹、工具準備、新建工程）p1-4

文章目錄 工具準備和介紹硬件設備stm32簡介和arm簡介stm32簡介STM32命名規則STM32選型STM32F103C8T6最小系統板引腳定義STM32啟動配置STM32最小系統電路ARM簡介 軟件安裝注冊器件支持包安裝ST-LINK驅動安裝USB轉串口驅動 新建工程創建stm32工程STM32工程編譯和下載型號分類及縮…
閱讀更多...
【ABAP】REST/HTTP技術（一）

【ABAP】REST/HTTP技術（一）

1、概念 1.1、SAP 如何提供 Http Service 如果要將 SAP 應用程序服務器 （application server）作為 http 服務提供者，需要定義一個類，這個類必須實現 IF_HTTP_EXTENSION 接口。IF_HTTP_EXTENSION 接口只有一個方法 HANDLE_REQUEST。…
閱讀更多...
[實戰] linux驅動框架與驅動開發實戰

[實戰] linux驅動框架與驅動開發實戰

linux驅動框架與驅動開發實戰 Linux驅動框架與驅動開發實戰一、Linux驅動框架概述1.1 Linux驅動的分類1.2 Linux驅動的基本框架 二、Linux驅動關鍵API詳解2.1 模塊相關API2.2 字符設備驅動API2.3 內存管理API2.4 中斷處理API2.5 PCI設備驅動API 三、Xilinx XDMA驅動開發詳解3.1…
閱讀更多...
1. hadoop 集群的常用命令

1. hadoop 集群的常用命令

1.上傳文件 1)hadoop fs -put words.txt /path/to/input/ 2)hdfs dfs -put words.txt /path/wc/input/ 2.獲取hdfs中的文件 hadoop fs -get /path/wc/input/words.txt 3.合并下載多個文件 hadoop fs -getmerge /path/wc/input/words.txt /path/wc/input/words2.txt 4.查…
閱讀更多...
Keepalived+LVS+nginx高可用架構

Keepalived+LVS+nginx高可用架構

注明：所有軟件已經下載好，防火墻和SELinux已經全部關閉 一.搭建NFS 1.服務端 1.創建文件 [rootnfs ~]# mkdir -p /nfs/data 2、修改權限 [rootnfs ~]# chmod orw /nfs/data 3、寫配置文件 [rootnfs ~]# cat /etc/exports /nfs/data 192.168.111.118(r…
閱讀更多...
深度學習處理文本（13）

深度學習處理文本（13）

我們使用基于GRU的編碼器和解碼器來在Keras中實現這一方法。選擇GRU而不是LSTM，會讓事情變得簡單一些，因為GRU只有一個狀態向量，而LSTM有多個狀態向量。首先是編碼器，如代碼清單11-28所示。 代碼清單11-28　基于GRU的編碼器 fro…
閱讀更多...
HashMap 底層原理詳解

HashMap 底層原理詳解

1. 核心數據結構 JDK 1.7 及之前&#xff1a;數組 鏈表 JDK 1.8 及之后&#xff1a;數組 鏈表/紅黑樹&#xff08;鏈表長度 ≥8 時轉紅黑樹&#xff0c;≤6 時退化為鏈表&#xff09; // JDK 1.8 的 Node 定義&#xff08;鏈表節點&#xff09; static class Node<K,V&g…
閱讀更多...
使用MySQL時出現 Ignoring query to other database 錯誤

使用MySQL時出現 Ignoring query to other database 錯誤

Ignoring query to other database 錯誤 當在遠程連接軟件中輸入MySQL命令出現該錯誤 導致錯誤原因是&#xff1a;登錄mysql時賬戶名沒有加上u 如果出現該錯誤&#xff0c;退出mysql&#xff0c;重新輸入正確格式進入即可&#xff01;
閱讀更多...
哈爾濱工業大學：大模型時代的具身智能

哈爾濱工業大學：大模型時代的具身智能

大家好&#xff0c;我是櫻木。 機器人在工業領域&#xff0c;已經逐漸成熟。具身容易&#xff0c;智能難。 機器人-》智能機器人&#xff0c;需要自主能力&#xff0c;加上通用能力。 智能機器人-》人類&#xff0c;這個階段就太有想象空間了。而最受關注的-類人機器人。 如何…
閱讀更多...
Javascript代碼壓縮混淆工具terser詳解

Javascript代碼壓縮混淆工具terser詳解

原始的JavaScript代碼在正式的服務器上,如果沒有進行壓縮,混淆,不僅加載速度比較慢,而且還存在安全和性能問題. 因此現在需要進行壓縮,混淆處理. 處理方案簡單描述一下: 1. 使用 terser 工具進行 安裝 terser工具: # npm 安裝 npm install terser --save-dev# 或使用 yarn 安…
閱讀更多...
Java String 常用方法詳解

Java String 常用方法詳解

目錄 一、獲取字符串信息（一）獲取字符串長度（二）獲取指定索引處的字符（三）獲取子字符串二、字符串比較（一）比較字符串內容（二）忽略大小寫比較三、字符串轉換（一）轉換為大寫（二）轉換為小寫四、字符串查找（一）查找子字符串的位置（二）從指定位置開始查找五、字符…
閱讀更多...
Linux驅動開發練習案例

Linux驅動開發練習案例

1 開發目標 1.1 架構圖 操作系統&#xff1a;基于Linux5.10.10源碼和STM32MP157開發板&#xff0c;完成tf-a(FSBL)、u-boot(SSBL)、uImage、dtbs的裁剪&#xff1b; 驅動層&#xff1a;為每個外設配置DTS并且單獨封裝外設驅動模塊。其中電壓ADC測試&#xff0c;采用linux內核…
閱讀更多...
leetcode-代碼隨想錄-哈希表-贖金信

leetcode-代碼隨想錄-哈希表-贖金信

題目 題目鏈接&#xff1a;383. 贖金信 - 力扣&#xff08;LeetCode&#xff09; 給你兩個字符串&#xff1a;ransomNote 和 magazine &#xff0c;判斷 ransomNote 能不能由 magazine 里面的字符構成。 如果可以&#xff0c;返回 true &#xff1b;否則返回 false 。 maga…
閱讀更多...
精品可編輯PPT | “新基建”在數字化智慧高速公路中的支撐應用方案智慧建筑智慧交通解決方案施工行業解決方案

精品可編輯PPT | “新基建”在數字化智慧高速公路中的支撐應用方案智慧建筑智慧交通解決方案施工行業解決方案

本文詳細闡述了“新基建”在數字化智慧高速公路中的支撐應用方案&#xff0c;從政策背景出發&#xff0c;指出國家在交通領域的一系列發展規劃和指導意見&#xff0c;強調了智慧交通建設的重要性。分析了當前高速公路存在的問題&#xff0c;如基礎感知設施不足、協同水平低、服…
閱讀更多...
C語言求3到100之間的素數

C語言求3到100之間的素數

一、代碼展示 二、運行結果 三、感悟思考 注意: 這個題思路他是一個試除法的一個思路 先進入一個for循環 遍歷3到100之間的數字 第二個for循環則是 判斷他不是素數 那么就直接退出 這里用break 是素數就打印出來 在第一個for循環內 第二個for循環外
閱讀更多...
英語—四級CET4考試—蒙猜篇—匹配題

英語—四級CET4考試—蒙猜篇—匹配題

蒙猜方法一 匹配題的做題&#xff1a; 方法一&#xff1a; 首先&#xff0c;什么都不想&#xff0c;把問題中ing形式的&#xff0c;大寫字母的&#xff0c;人名&#xff0c;地名&#xff0c;最后幾個依次框起來。 然后&#xff0c;比如46題&#xff0c;口里默念meaningful lif…
閱讀更多...
股票日數據使用_未復權日數據生成前復權日周月季年數據

股票日數據使用_未復權日數據生成前復權日周月季年數據

目錄 前置&#xff1a; 準備 代碼&#xff1a;數據庫交互部分 代碼&#xff1a;生成前復權 日、周、月、季、年數據 前置&#xff1a; 1 未復權日數據獲取&#xff0c;請查看 https://blog.csdn.net/m0_37967652/article/details/146435589 數據庫使用PostgreSQL。更新日…
閱讀更多...
系統與網絡安全------Windows系統安全（6）

系統與網絡安全------Windows系統安全（6）

資料整理于網絡資料、書本資料、AI&#xff0c;僅供個人學習參考。 共享文件夾 發布共享文件夾 Windows共享概述 微軟公司推出的網絡文件/打印機服務系統 可以將一臺主機的資源發布給其他主機共有 共享訪問的優點 方便、快捷相比光盤 U盤不易受文件大小限制 可以實現訪問…
閱讀更多...
BN 層的作用, 為什么有這個作用?

BN 層的作用, 為什么有這個作用?

BN 層&#xff08;Batch Normalization&#xff09;——這是深度神經網絡中非常重要的一環&#xff0c;它大大改善了網絡的訓練速度、穩定性和收斂效果。 &#x1f9e0; 一句話理解 BN 層的作用&#xff1a; Batch Normalization&#xff08;批歸一化&#xff09;通過標準化每一…
閱讀更多...
最新文章

Copyright @ 2022~2023