背 景

在云原生 + 微服務的體系下, 服務觀測是治理服務的重要依據和抓手，知之才能治之。在觀測領域的三架馬車中，監控 (Metrics) 無疑是最為重要的, 它是最常被查看的, 同時穩定性和準確性要求也是最嚴格的。

作業幫的監控體系是隨著云原生一起成長起來的, 支持著公司所有集群和服務的監控任務。在實踐中我們認為一套優秀的監控系統需要支持以下幾個點

• 穩定：穩定不只有系統穩定, 我們還要保障數據穩定, 盡量減少采集和傳輸階段造成的數據抖動

• 實時：監控數據有很強的時效性, 我們要保證最新的數據最快地呈現在用戶前面

• 全面: 全面的觀測才是好的觀測, 我們要保證監控數據是多維度, 能夠廣泛覆蓋

• 高吞吐：監控的數據量與監控對象的數量成正比, 在做全面監控的時候必然會有龐大的數據量. 我們需要支持大數據量的存儲和訪問

• 長期存儲: 監控數據雖然有很強的時效性, 但也有訪問歷史數據的需求；我們需要有一個合適的方式來保存這些冷數據。

作業幫監控現狀

目前作業幫高峰每秒有 800w 的監控數據采集和寫入，活躍時間序列達到 300w，每天新增 800GB 監控數據寫入。

隨著作業幫業務的持續拓展，監控規模也在迅速擴大，這給監控系統帶來了極高的挑戰性，意味著監控系統需要處理大量的實時監控數據，保證數據的準確性和及時性，同時能夠有效可靠地存儲和分析這些數據，因此需要建設更強大靈活且具有成本優勢的監控系統支撐公司業務的持續發展。

作業幫選擇使用 Prometheus 作為監控的采集組件，并使用 VictoriaMetrics 作為監控存儲，選型 Prometheus+VictoriaMetrics 搭建監控系統的主要原因在于：

• Prometheus 是一個開源的監控系統，具有高度可擴展性和靈活性，支持多種數據模型，能夠適應不同類型和規模的監控需求。

• VictoriaMetrics 具有高效的存儲和查詢性能，可以快速處理大規模的時間序列數據，而且具有較低的存儲和計算成本，能夠降低系統的總體成本和復雜度。

• VictoriaMetrics 作為 Prometheus 數據的存儲和查詢引擎，其高效的時間序列數據庫，能夠快速存儲和查詢大規模的時間序列數據。因此，這兩者的結合可以滿足作業幫大規模監控數據的存儲、查詢和分析需求。

• 同時 VictoriaMetrics 對 Prometheus 的良好兼容，使其可以無縫對接 Prometheus，并與其他常用的監控工具和系統集成，如 Grafana 等，為作業幫提供更全面、靈活的監控解決方案。

作業幫多云多地域的監控體系是如何構建

作業幫的服務部署是多云多地域的，除了數個核心集群外，還有多個小集群分散在多個地域上，我們的監控系統需要完成所有集群的監控覆蓋。整體架構如下圖：

架構圖

監控系統可以分為以下 3 個部分

監控采集

我們采用了 prometheus 作為監控數據采集組件，并按實際需求往集群中部署對應的 prometheus 實例負責采集。每個集群中的 prometheus 只負責采集本集群中的監控數據，并統一通過 remote-write 寫入到監控數據存儲（VictoriaMetrics）中。同時還存在部分小集群只能走公網通信的情況，為此我們會部署一個代理組件，負責承接公網監控流量，完成鑒權后再代理寫入到存儲中去。

Prometheus 在集群中的部署我們采用了橫向 + 縱向拆分的模式。每個采集任務會按監控數據類型拆分到不同類的 prometheus 實例中去，同一類的 prometheus 會通過 hashmod 方式進行分片，從而將所有采集對象均勻分配。

監控存儲

Prometheus 只支持單機部署，無法集群化, 在大數據量的場景下無法作為監控數據的存儲中心，因此我們選擇了 VictoriaMetrics 來存儲監控數據。

在實際使用中，VictoaMetrics 在性能表現上十分優秀，單核可以支持 5W/S 的指標寫入，查詢的平均耗時在 50ms 左右，P99 在 2s 以內。

監控訪問

我們的監控數據會在以下 3 個場景提供訪問：

• 監控大盤：我們選擇 grafana 作為監控數據的展示面，收斂所有的可視化需求。

• 指標告警：告警上我們復用了 grafana 的告警能力，從而在告警時做到與可視化界面的聯動。

• 服務巡檢：我們提供了巡檢系統定期掃描服務的健康度，通過可信任的 API 來訪問監控數據， 從而提前發現提前治理。

• 根因分析：當線上服務遇到問題時，我們提供了根因分析服務來快速分析定位問題。根因分析系統會通過可信任的 API 獲取日志、監控、追蹤和事件等數據，按策略進行分析定位。

多維度的監控指標采集是怎么建設的

我們將監控層級從下到上分為 4 層, 并按所屬層次劃分管理對應的采集任務，每一層的指標會由對應的 prometheus 實例來負責采集。

系統指標建設

系統指標里主要包括K8S 集群，網絡，基礎組件，Pod，Node的各種指標。

通過這一層的指標我們了解系統的運行狀態，通過監控數據知曉系統中的各種問題。

存儲指標建設

存儲是整個系統中極為重要的一部分，我們會為每類存儲建立它們的指標數據。

存儲指標里主要包括了 Mysql，Redis，ES，MQ 等各種存儲的指標，以感知它們的運行情況。

另外我們會讀取服務與存儲的請求關系，為每個存儲綁定服務依賴關系，從而完成存儲與服務監控指標數據的聯動。

服務指標建設

服務是整個系統的核心部分，我們會圍繞著服務建立各類監控指標，自動完成指標的采集和匯聚，從而向用戶提供全面的服務監控指標。

當前主要包含以下幾類數據：

服務入流量指標

• 服務出流量指標

• 存儲（mysql、redis、es 等）訪問指標

• MQ 生產 / 消費指標

• 服務運行時指標（Runtime）

服務指標建設致力于提供覆蓋服務的通用指標數據，上線的服務無需額外配置就可以看到自己的大盤數據。

業務指標建設

服務運行時有很多業務指標需要觀測，這些指標我們無法直接觀測到，需要服務主動暴露出來。這種監控需求之前一般是通過服務增加打點日志然后進行統計分析完成的。這種實踐方式會有幾個問題在：

• 依賴日志鏈路：可用性和準確性強依賴日志鏈路，而日志的可用性保證一般會低于服務的可用性保證。

• 依賴分析服務：對分析統計的服務強依賴，并且這個依賴會帶來額外的資源開銷。

• 使用門檻高：需要額外配置日志解析和數據統計的規則，有一定的使用門檻。

在業務指標的實踐上，我們建議服務通過 prometheus sdk 來統計關心的業務指標數據，并通過 metrics 接口暴露出來最后交由 proemtheus 自動完成采集。這種方式有幾個優點：

• 更高的可靠性：RPC 請求比日志投遞的方式，在數據傳輸上更加可靠，延遲也更低

• 更好的靈活性：服務可以在代碼里撰寫數據統計邏輯，不用受限于分析服務能力范圍。

如何高效可靠地保存監控數據, 同時降低存儲成本為原來的 1/6

在使用 VcitoriaMetrics 的過程中我們遇到了兩個問題

• 副本與可用性: 可用性依賴于副本, 不過額外的副本會提高整體成本

• 歷史數據: 監控數據需要保存一定時間, 但額外的磁盤占用會提高整體存儲成本

為了解決上述問題, 我們自研了 vm-proxy, 作為 VictoriaMetrics 集群的讀寫代理，并采用了一套新的存儲架構。如下圖：

我們將 VictoriaMetrics 分為了標準集群和降準集群, 其中標準集群負責存儲最近一個月的標準精度數據，而降準集群則負責存儲降低精度后的歷史數據。vm-proxy 主要起到以下作用：

• 數據寫入復制

• 數據采樣降精度

• 數據讀取路由

vm-write-proxy

vm-write-proxy 會承接 prometheus 的所有 remote-write 流量，然后再將監控數據往標準集群和降準集群都寫入一份數據。

• 標準數據策略：不對監控數據做額外處理，原樣寫入到標準集群中

• 降準數據策略：

• • 按一定比例對監控數據進行降采樣，再寫入到標準集群中

  • 過濾部分數據指標（高基數的指標和不要求長期保存的數據），不再寫入降準集群

數據降準

觀測數據都有冷熱之分, 最近的數據訪問頻率越大, 而歷史數據訪問頻率則會顯著降低，于此我們需要對歷史數據選擇一種合適的方法存儲以降低整體成本。在日志場景下我們一般會采用壓縮的方式處理日志數據，而在監控場景里則會采取降準的方式處理監控數據。

在做監控數據采集的時候, 我們會為不同的數據設置一個合適采集的頻率，而數據采集的頻率則直接影響著監控的精度。如果一個指標的采集頻率是 10s 和 60s, 我們可以看到 10s 采集頻率的監控曲線會更細致, "分辨率"更高。

而我們數據降準的實現十分直接，就是降采樣，比如將原本 10s 精度的數據降采樣為 60s 精度的監控數據。vm-write-proxy 組件在接受到監控數據寫入的時候, 會對時序數據進行采樣，按比例剔除掉部分時序數據后再寫入到降準集群中。

vm-read-proxy

vm-read-proxy 會承接 grafana 和 API 過來的所有查詢流量, 并遵循以下策略進行流量分發

• 時間路由: 一個月內的查詢請求會被發送到標準集群進行查詢, 而一個月前的查詢請求會被發送到降準集群。

• 降級路由: 當標準集群不可用, 所有查詢請求會被重新路由到降準集群上。這樣的操作會導致查詢結果精度降低，但可以保證監控系統可以繼續提供服務。

在將請求發送到降準集群時, 因為數據精度的不同, vm-read-proxy 會自動將查詢語句調整為合適精度的查詢, 從而保證監控數據連續。

流量鑒權

所有查詢流量都會通過 vm-read-proxy 進行，因此我們在 proxy 上打通了公司的用戶系統和權限系統，從而實現了監控數據用戶身份 + 服務粒度的自動鑒權能力，從底層上杜絕了權限混亂的問題。

故障轉移和恢復

實際運行中我們發現 VictoriaMetrics 單集群穩定性不足, 當集群負載較高、大流量進入時可能會導致部分節點不可用，而 VictoriaMetrics 的 Reroute 機制會自動將流量分攤到其余節點上，如果剩余節點無法承擔全部流量則可能會引起雪崩，從而影響整個集群的可用性。通過雙集群部署 VictoriaMetrics，我們通過構建數據副本的方式來保證存儲的高可用，如果遇到單集群故障, 我們采用以下方式進行故障轉移和恢復

• 標準集群故障：當集群中故障節點超過冗余數量時，vm-read-proxy 會自動進行降級路由，將所有的查詢請求路由至降準集群，同時 vm-write-proxy 不再對降準集群的數據進行采樣處理而是原樣寫入，此時對標準集群進行擴容或者觀察流量過去標準集群恢復后，再將讀流量切回至標準集群，同時恢復降準集群的采樣策略。

• 降準集群故障：當降準集群故障時，不會影響實時監控數據展示，因此不需要切流量，直接進行集群恢復即可。

收益

之前我們的監控系統的瓶頸主要在磁盤上, 歷史數據和副本數據占用了大量空間。而在使用了這套架構后,整體的機器成本下降到了之前的 1/6, 并且歷史數據的查詢速度也有顯著的提升，集群雙活部署能保證監控數據的高可用，SLA 達到 99.95%。

大量的監控指標如何進行治理

監控數據的來源多種多樣，我們當前有源于機器、組件、服務、業務、日志的各種指標。在其中存在著許多指標冗余, 設計不合理, 精度不合理的情況。這些不僅會導致查詢耗時長，資源消耗大，也會導致數據存儲空間的浪費。

我們如果想保證監控系統高效、穩定、成本可控，就需要對我們大量的指標數據進行治理，做到去蕪存菁。一般可以通過以下三種方式做指標的治理:

高基數指標巡檢

時序數據的設計支持了靈活的 label 屬性, 但如果指標的 label 設計不合理, 就會造成指標數據量的極大膨脹。

針對這個問題, victoriaMetrics 提供了 vmui 組件, 我們可以借助這個組件來發現基數過大的指標。

而針對這些基數過大的指標, 我們可以看看這個 label 是否有被使用到, 也可以去優化 label 設計減少數據量。

監控數據是動態變化，所以我們會周期巡檢并做周期性的高基數指標治理，以我們的經驗一般每次治理可以去掉 10%~20% 左右的無效指標數據。

指標長度限制

此外還有另外一個指標設計不合理的情況, 就是 label 的 key 或者 value 設置得過長, 如果數據量比較大的話同樣會影響存儲和查詢。

為此我們在 vm-write-proxy 中增加了功能，來實現過長指標的監視和裁剪，所有 label 長度默認都會限制在 256 字節內。

指標老化

作業幫監控系統中的數據有很大一部分是來源于對日志的解析。日志數據會由處理程序解析后匯聚成 Exporter 數據，再輸出給 prometheus。我們發現部分指標數據存在生命周期過長的問題, 比如 pod 維度和 url 維度的數據 (pod 銷毀后基于日志的監控數據沒有跟隨一起停止, 部分 url 只請求過寥寥幾次卻同樣有著全時段的時序數據)。

針對這種情況，我們重寫了 prometheus 采集和匯聚的邏輯，給每個時間序列記錄生命周期，定期清理掉不活躍的指標數據。在上線指標老化能力，整體的時間序列寫入量下降了 20%。

監控系統如何更加貼近研發

自動適配的服務監控大盤

作業幫所有容器化的服務，監控系統都會默認根據服務語言、資源依賴等為服務生成通用監控大盤，納涵所有服務核心指標，包括服務資源、出 / 入流量、存儲 /MQ 等外部依賴、語言運行時、網關監控等，無需研發手動配置直接提供統一監控視圖。基于這個大盤，研發可以直接了解自己服務的運行狀態，健康程度。

自定義的業務監控大盤

對于一些業務強相關的指標，服務通用監控無法進行觀測，為此我們提供了業務監控大盤來滿足此類監控需求。

對于業務監控數據，我們采用 prometheus 的標準做業務自定義指標的采集。服務可以在服務內部將業務指標進行統計匯聚，然后通過 metrics 接口暴露指標采集數據。之后研發可以通過工單來申請 prometheus 采集和創建監控面板，最后便可以創建出符合業務需求的業務監控大盤。

基于模版和推薦的告警體系

為保障服務持續健康運行，針對服務核心監控指標預設報警規則，用戶可基于推薦快速應用，降低配置成本。

我們為各種服務提供了基礎的告警模版, 用戶可以一鍵應用模版快速給服務創建告警規則, 保證了對服務核心指標的關注，也支持對告警規則進行微調，用戶可按需靈活配置。同時會自動生成服務維度的告警統計報表，幫助研發了解服務狀態，關注告警原因并實際解決問題。

此外服務是持續演化的，我們發現會存在監控告警無法及時覆蓋的情況，比如服務新接入消息隊列但卻忘了添加對應的監控告警。針對這種情況，我們的服務巡檢系統會持續關注服務的監控告警設置，并基于服務的模版和配置進行監控告警項的推薦，研發老師可以按需應用。

監控系統聯動其他觀測工具

為提升問題排查效率，我們將監控系統與其他觀測工具如日志檢索、根因分析工具等進行打通。

當用戶在查看監控面板時，會自動提取對應指標的關鍵信息，如服務名稱、集群、URL、狀態碼等生成日志檢索鏈接，研發可直接點擊跳轉到日志查看對該監控指標的詳細日志。

當報警觸發時，監控系統會提取報警關鍵信息一在告警卡片提供日志、監控、追蹤數據的快速入口，提升問題定位效率。

同時告警事件會推送到根因分析服務，完成分析后分析結果也會自動推送給研發以協助線上問題定位。