監控系統三要素
Metrics 的特點：它自己提供了五種基本的度量類型 Gauge、Counter、Histogram、Timer、Meter。
Tracing 的特點：提供了一個請求從接收到處理完畢整個生命周期的跟蹤路徑，通常請求都是在分布式的系統中處理，所以也叫做分布式鏈路追蹤。
Logging 的特點：提供項目應用運行的詳細信息，例如方法的入參、運行的異常記錄等。
這三者在監控系統中缺一不可，它們之間的關系是：基於 Metrics 的異常告警事件，然后通過 Tracing 定位問題可疑模塊，根據模塊詳細的日志定位到錯誤根源，最后再返回來調整 Metrics 的告警規則，以便下次更早的預警，提前預防出現此類問題。
檢測算法
基礎性能類指標，一般選擇靜態閾值檢測算法。
觸發條件
時序類指標(CPU、內存等)的檢測周期默認為采集周期，事件類告警為分鍾（事件類告警無固定的采集周期）。
建議 : 默認選擇5個周期滿足N次檢測算法 （1）抖動類的指標如CPU總使用率，N可選擇3；非抖動類的如磁盤使用率，N可選擇1。 （2）為告警收斂的恢復檢測做准備。比如5分鍾內滿足2次檢測算法，則恢復檢測的觸發條件是檢查前5個周期滿足少於2次檢測算法。
告警狀態
一旦這些警報存儲在Alertmanager，它們可能處於以下任何狀態：
Inactive：這里什么都沒有發生。
Pending：已觸發閾值，但未滿足告警持續時間（即rule中的for字段）
Firing：已觸發閾值且滿足告警持續時間。警報發送到Notification Pipeline，經過處理，發送給接受者。
這樣目的是多次判斷失敗才發告警，減少郵件。
告警收斂手段：
分組（group）：將類似性質的警報分類為單個通知
抑制（Inhibition）：當警報發出后，停止重復發送由此警報引發的其他警報
靜默（Silences）：是一種簡單的特定時間靜音提醒的機制
告警收斂：告警產生后狀態未恢復，N小時內不再產生告警
場景：一段時間內持續滿足告警的觸發條件，容易出現告警風暴，將郵箱塞滿。
方案：如果告警持續產生，但未恢復，則一段時間內僅通知1次
告警恢復檢測：和告警檢測條件相反，例如觸發條件為“5個周期內，滿足3次檢測算法”，則 告警恢復檢測的觸發條件是“當滿足觸發條件時，會檢查是否滿足 前5個周期少於3次檢測算法"
告警產生后狀態未恢復，24小時內不再產生告警
告警產生后狀態未恢復，0小時內不再產生告警：表示滿足觸發條件將直接發出告警，不再收斂。
持續產生數據，突然不上報數據時，則產生無數據告警
若上報數據不連續，則不建議開啟。
告警模塊
1.輪詢式告警
業務方配置好需要告警的接口、閾值和告警方式，我們通過crontab運行一組腳本，定期掃描存儲中的相關指標，滿足條件即觸發告警
存在以下幾個問題
延遲:從存儲中輪詢指標，這意味着已經有了一段時間的延遲。
靈活性差:系統是動態發展的，業務量在不斷增長，固定的規則，閾值很難適應這種情況，網絡抖動引起的短暫異常也會引發大量的誤報。
2.流式告警
一方面，雖然還少不了有一些人工培植告警的工作，但已經可以根據推送數據自動提取告警規則，在很大程度上簡化了告警配置；
另一方面，告警數據不再存儲，而是經過流式計算后存入redis隊列，滿足閾值和觸發條件的會被消費(告警)，不滿足的會被定期從隊列中清除
流式告警的幾個好處:
1.實時性:數據流過就會計算是否符合規則，不用再走存儲流程。
2.規則抽象:我們按照幾個層次(業務線、服務池、IP、接口)抽象了告警邏輯。
最小級別的接口異常標准按照SLA或者KPI指標自動設定。
逐層向上收斂。在服務池級別有多少IP發生異常即觸發本級別的告警事件(比如5%的IP響應時間超過SLA設定，為服務池warning時間，
超過10%為服務池error事件)，到了業務線級別，告警的判斷標准是有多少服務池發生異常(warning，error，fatal等)。每一層的告警事件都會向上收斂，
如果不超出上一層的SLA設定，則只會展示在九宮格中或者事件列表里，而不會直接報給用戶，最終向上匯總的最高級，用戶在宏觀層面即可整體把握可用性(
不影響整體的話可以不用立刻干預)，又可逐級向下追溯具體的問題節點
3.規則自動提取:只要推送數據符合協議(包含業務線，服務池等信息)，報警規則和收斂方式就會自動進入配置庫(mysql)，后面的九宮格、郵件、推送都
自動生成，不需要人工干預(這里生成的都是抽象出來的通用規則，用戶也可以通過后台定制自己的專屬規則)
4.告警API:除針對單個指標設置規則外，還可以通過API批量導入告警規則，尤其是在指標特別多的時候。(在某些情況下，業務方對告警邏輯的抽象和我們不同，
因此不適用自動提取規則)。
流式告警上線后，基本上自動規則就能解決80%的告警需求，但仍有一些特殊化的需求還不能覆蓋，比如徒增突降告警，同比環比等復雜的需要經過統計運算的告警。
這個階段可以稱之為"重服務質量，輕告警"，真正需要通知到用戶的告警數量比較少，大部分告警事件都因為對整體服務影響不大而被“降噪”了。
3.智能告警階段是通過算法，對告警的數量和質量(誤報率)進行不斷修正的過程。在智能告警階段主要的方法包括:
1.將告警聚合成“關聯事件”
2.合並重復的告警
3.自動恢復策略
4.告警分類
1.數據聚合/關聯技術
1.數據聚合
數據聚合對實時、時序數據(監控數據和運維事件)的聚合。而數據分析屬於離線計算模式，是對數據的深加工、二次利用。
有兩個層面,一是對數據的聚合運算(計算，平均，抽樣等)；二是多維度的聚合(在實際應用中維度通常指時間,地點,業務線,服務,接口等)，也可稱為是標簽，用來標注看待數據的不同角度。
沒有聚合這一層，不得不存儲所有的原始數據，但在運維監控工作中基本上不需要，讀取時也需要讀出原始數據后再計算結果，這樣寫入量和讀取量就會比不做聚合時大得多，在海量數據場景下，對系統復雜度和穩定性都是一個考驗。
2.降低維度
告警事件的收斂和聚合一直是運維工作中的重要環節。收斂和聚合一方面可以減少噪音和干擾，另一方面可以確定主要因素、定位故障、如果每天有上萬個告警事件，如何收斂到人可以處理的程度(少於10個)