Zi 字媒體

構建智能運維平台，運行監控和故障報警是兩個繞不過去的重要部分。本次分享主要是數人云工程師介紹引入 SRE 理念后的基於時間序列數據存儲的報警工程實踐。SRE 報警介紹今天我分享的主題是 SRE 基於時間序列數據的報警實踐，既然是基於時間序列。首先，我先簡單介紹一下什麼是時間序列數據。時間序列（ time series ）數據是一系列有序的數據。通常是等時間間隔的採樣數據。時間序列存儲最簡單的定義就是數據格式里包含 timestamp 欄位的數據。時間序列數據在查詢時，對於時間序列總是會帶上一個時間範圍去過濾數據。同時查詢的結果里也總是會包含 timestamp 欄位。監控數據大量呈現為時間序列數據特徵，所以，為了應對複雜的監控數據格式，在每一份數據中加上時間欄位。區別於傳統的關係型資料庫，時間序列數據的存儲、查詢和展現進行了專門的優化，從而獲得極高的數據壓縮能力、極優的查詢性能，特別契合需要處理海量時間序列數據的物聯網應用場景。Google 的監控系統經過 10 年的發展，經歷了從傳統的探針模型、圖形化趨勢展示的模型到現在基於時間序列數據信息進行監控報警的新模型。這個模型將收集時間序列信息作為監控系統的首要任務，同時發展了一種時間序列信息操作語言，通過使用該語言將數據轉化為圖標和報警取代了以前的探針腳本。監控和報警是密不可分的兩個部分，之前我們公司的 CTO 肖德時曾經做過關於基於時間序列數據監控實踐的分享，在本次分享中就不重複介紹前面的監控部分，感興趣的同學可以去看看老肖的文章。運維團隊通過監控系統了解應用服務的運行時狀態，保障服務的可用性和穩定性。監控系統也通常會提供 Dashboard 展示服務運行的指標數據，雖然各種折線圖看著很有趣，但是監控系統最有價值的體現，是當服務出現異常或指標值超過設定的閥值，運維團隊收到報警消息，及時介入並恢復服務到正常狀態的時候。SRE 團隊認為監控系統不應該依賴人來分析報警信息，應該由系統自動分析，發出的報警要有可操作性，目標是解決某種已經發生的問題，或者是避免發生的問題。監控與報警監控與報警可以讓系統在發生故障或臨近發生故障時主動通知我們。當系統無法自動修復某個問題時，需要一個人來調查這項警報，以決定目前是否存在真實故障，採取一定方法緩解故障，分析故障現象，最終找出導致故障的原因。監控系統應該從兩個方面提供故障的信息，即現象和原因。黑盒監控與白盒監控黑盒監控: 通過測試某種外部用戶可見的系統行為進行監控。這是面向現象的監控，提供的是正在發生的問題，並向員工發出緊急警報。對於還沒有發生，但是即將發生的問題，黑盒監控無能為力。白盒監控依靠系統內部暴露的一些性能指標進行監控。包括日誌分析， Java 虛擬機提供的監控介面，或者一個列出內部統計數據的 HTTP 介面進行監控。白盒監控能夠通過分析系統內部信息的指標值，可以檢測到即將發生的問題。白盒監控有時是面向現象的，有時是面向原因的，這個取決於白盒監控提供的信息。Google 的 SRE 大量依賴於白盒監控。設置報警的幾個原則通常情況下，我們不應該僅僅因為「某個東西看起來有點問題」就發出警報。緊急警報的處理會佔用員工寶貴的時間，如果該員工在工作時間段，該報警的處理會打斷他原本的工作流程。如果該員工在家，緊急警報的處理會影響他的個人生活。頻繁的報警會讓員工進入「狼來了」效應，懷疑警報的有效性和忽略報警，甚至錯過了真實發生的故障。設置報警規則的原則：發出的警報必須是真實的，緊急的，重要的，可操作的。報警規則要展示你的服務正在出現的問題或即將出現的問題。清晰的問題分類，基本功能是否可用；響應時間；數據是否正確等。對故障現象報警，並提供儘可能詳細的細節和原因，不要直接對原因報警。基於時間序列數據進行有效報警傳統的監控，通過在伺服器上運行腳本，存儲返回值進行圖形化展示，並檢查返回值判斷是否報警。 Google 內部使用 Borgmon 做為監控報警平台。在 Google 之外，我們可以使用 Prometheus 作為基於時間序列數據監控報警的工具，進而實踐 SRE 提供的白盒監控理念。監控報警平台架構圖：監控報警組件cAdvisro 為用戶提供理解容器運行時的資源使用和性能特徵的工具。 cAdvisor 作為一個後台運行的程序，收集，聚合，處理並導出容器運行時的信息。 Link:https://github.com/google/cadvisorPrometheus 是 SoundCloud 開發的開源的系統監控報警工具集。 Prometheus 從 cAdvisor 的 HTTP 介面採集容器運行時的信息，保存在內部的存儲里，利用 PromQL 對時序數據進行查詢展示和設置報警。報警信息推送到 Alertmanager 。 Link:https://prometheus.io/Alertmanager 處理由 Prometheus 服務發送過來的報警，進行去重，分組，路由，靜默和降噪等操作。 Link:https://prometheus.io/docs/alerting/alertmanager/Alerta 是一個用戶友好的報警可視化展示工具，用於展示和管理從 Alertmanager 推送過來的報警數據。 Link ：http://alerta.io/搭建測試環境為了方便測試，我們在測試伺服器上用容器運行以上組件，測試伺服器地址 192.168.1.188 。啟動兩個 Nginx 容器，並分配不同的 label 標識一個屬於 Dev 組的應用，一個屬於 Ops 組的應用。啟動 cAdvisor 容器，埠映射 8080 。啟動 Alertmanager 容器，埠映射 9093 ，配置文件中指定 Alerta 的地址作為 Webhook 的通知地址。啟動 Prometheus 容器，埠映射 9090 ， CMD 指定「-alertmanager.url 」地址為 Alertmanager 的地址。啟動 MongoDB 作為 alerta 的資料庫啟動 Alerta ，埠映射為 8181容器運行截圖：應用指標收集cAdvisor 原生提供 http 介面暴露 Prometheus 需要收集的 metrics ，我們訪問http://192.168.1.188:8080/metrics。在 Prometheus 的配置文件里配置 cAdvisor 的地址作為 target 地址，可以在 Prometheus 的 Web 頁面查看 Targets 的狀態。在 Prometheus 的 Graph 頁面，可以對收集的數據進行查詢和圖形化展示。報警規則配置我們針對容器應用的 CPU 使用率配置報警規則，規則如下：圖中分別針對 dev 組和 ops 組設置了應用容器的報警規則，報警規則的格式：「 Alert 」是報警規則的名字，名字間不能有空格，可以用下劃線鏈接；「 IF 」是數據的查詢表達式，截圖中的語句內容查詢指標「 containercpuusagesecondstotal 」， label 「 containerlabeldatamanservice 」等於「 web 」， label 「 containerlabeldatamangroup 」 等於「 dev 」，用函數 irate計算指標在上一個 5 分鐘內每秒鐘 CPU 使用時間的差值的比率。簡單點說計算了 CPU 佔用時間的百分比。這裡兩個報警規則中的表達式有點區別，是為了區分兩個組的應用。「 FOR 」是報警狀態持續超過 1 分鐘后，將報警由狀態「 PENDING 」改為「 FIRING 」，報警將交給 Alertmanager 處理。「 LABELS 」為自定義數據，我們在這裡指定了報警的級別和顯示「 IF 」中表達式的值。「 ANNOTATIONS 」為自定義數據，我們在這裡提供報警的現象和原因介紹。觸發報警我們用 stress 對兩個容器的 CPU 進行加壓，使得容器的 CPU 使用率超過報警的閥值。在 Prometheus 的頁面我們看到了產生的報警。在 Alertmanager 頁面看到從 Prometheus 發過來的報警。可以看到 Alertmanager 還把報警消息推送給了 alerta 。報警消息展示Alerta 對接收到的報警進行保存並展示。選擇某條報警信息，可以進入詳情，在詳情頁可以對報警進行 Ack ，關閉等操作。報警結束后，可以在 alerta 中查看報警的歷史，即處於關閉狀態的報警。結束語這裡我們簡要的介紹了下如何運用 cAdvisor ， Prometheus ， Alertmanager 和 Alerta 實現 Google SRE 中介紹的基於時序數據的報警實踐，針對性能指標的報警只是最基礎的報警方式，我們後續還會介紹如何配置和採集應用的內部數據指標，並進行監控報警的配置。應用系統的監控是一個複雜的過程，需要不斷的調整以應對服務的運行狀況和服務質量，也需要我們不斷的吸取 SRE 的運維理念並在實踐中落地。 SRE 可以說是 DevOps 在運維方面的具體實現，它既包括了理念、文化也包括了像監控報警這樣具體的運維和工程實踐。現在國內越來越多的企業開始關注 SRE 如何在整個生命周期為項目提供持續性支持。但是如何能夠讓 SRE 理念在本土落地，如何尋找到適合企業自身的 SRE 之路，數人云也在不斷摸索並持續將現有的經驗分享給大家，期望大家都能共同汲取 SRE 的營養以不斷提升企業的運維和工程實踐的水平。謝謝！Q&AQ ：告警信息收到后，系統有沒有能力自動解決告警報告的問題？還是需要人工解決問題？謝謝A ：這個要分情況，好的機制是報警應該發出的是新的問題，然後通過反饋機制，讓同類的問題不再發生，或者由監控系統自身解決。Q ： InfluxDB 系列方案是否有考慮， Grafana 最新版也有了很好的告警機制，是否有嘗試？A ：曾經考慮並實踐過 InfluxDB 的 TICK 組合方案，非常方便可以實現數據收集存儲處理展示的完整流程。通過對比，我們發現 Prometheus 更符合 Google SRE 對於監控的理念，自身社區也非常活躍，就轉向 Prometheus 的方案了。 Grafana 實現了強大的可視化配置報警規則的功能，對於原本只做為展示的工具，是很好的增強，這個對我們的啟發也很大，也在學習中。Q ：報警規則配置是什麼語法，是否可以可視化？A ： Prometheus 是在配置文件中描述報警規則。可以自己動手實現可視化。Q ：數據量龐大的情況怎麼解決，比如說萬台機器， 500 個指標數據等 一分鐘一個點 60243050010000 的數據量，如何保存，如何快速查詢數據。 需要什麼樣的架構和硬體？A ：簡單回答， Prometheus 可以通過分組支持大規模的集群，但是達到某個確定的規模，那就需要實踐給出答案了。Q ：請問在監控報警方面有沒有考慮或實踐過智能預警，比如基於歷史監控數據，通過機器學習，實現提前預警等？A ：這個不是 SRE 推薦的方式，報警應該簡單，高級的功能會模糊真實的意圖。Q ：請問基於此方案部署的主機和容器規模有多大，基於什麼頻率進行監控收集？A ：本次分享的是測試環境，規模不大。 Prometheus 定時從 cAdvisor 收集數據，抓取頻率 5s 。Q ： cAdvisor 採集數據的性能表現怎麼樣，佔用主機的資源大嘛？A ：性能表現優異，擔心佔用資源，可以在啟動容器時進行資源限制。Q ： APP 自身業務邏輯需要監控的數據，比如 Counter ， Gauge 等，傳統用 Zabbix 等可以進行數據採集。我明白 cAdvisor 是對 Container 進行數據採集。但是有沒有可能把 APP 自身的監控和 Container 的監控結合？A ：後續話題，我們會實踐有關應用的監控報警。 Prometheus 的邏輯是定時從 exporter 抓取數據，然後對存儲的時序數據，通過 PromQL 進行查詢和分析，所以是可以實現 APP 自身的監控和容器監控的結合的。