背景
現(xiàn)狀
- 某司概況：
- PaaS/SaaS 公司，業(yè)務(wù)面向全球，包括 東南亞/南亞/中東/歐洲/非洲/美洲/東亞...
- 生產(chǎn) k8s 集群數(shù)十套，生產(chǎn)非生產(chǎn) >100 套(多種集群類型，各種公有云/專有云/私有云/數(shù)據(jù)中心...)
- 疫情以來，持續(xù)推進成本優(yōu)化。
- 某司監(jiān)控概況，由于歷史原因和出于成本考慮：
- 基于 原生 Prometheus 深度定制+自研部分 exporter/sd, 沒用使用 kube-prometheus-stack（不兼容，成本會增加）
- 監(jiān)控覆蓋：k8s/pod/各類中間件/微服務(wù)/url...
- 每個集群一套 Prometheus 監(jiān)控
- 監(jiān)控所占用的計算存儲等資源受限
- 監(jiān)控部署方式：ansible 安裝監(jiān)控組件及后續(xù)使用 jenkins devops CI/CD 的自動發(fā)布
綜上，監(jiān)控可以稱得上：
- 全球化的
- 大規(guī)模的
- 混合云的
- Kubernetes 的
- 低成本監(jiān)控
問題
近期因監(jiān)控覆蓋不足（具體為某集群缺少了 url 監(jiān)控部分的配置）導(dǎo)致告警漏報，對此進行了深入復(fù)盤，核心問題可歸納為兩點：
- 缺乏唯一可信配置來源，各集群監(jiān)控配置分散，存在版本不一致、規(guī)則遺漏等問題；
- 手動操作導(dǎo)致配置漂移，無法實時同步全球集群狀態(tài)，故障預(yù)警能力受限。
為避免此類問題再次發(fā)生，規(guī)劃改進如下：
采用 GitOps(Git 作為唯一事實來源)+ Prometheus Operator 為核心的標準化監(jiān)控架構(gòu)，具體方案如下：
一、問題根源與改進方向
-
當(dāng)前挑戰(zhàn)
- 碎片化管理：全球數(shù)百套集群的 Prometheus 監(jiān)控配置部分仍依賴人工維護，易出現(xiàn)規(guī)則遺漏、閾值不統(tǒng)一。
- 手動管理風(fēng)險：手動管理監(jiān)控組件和監(jiān)控配置和閾值，存在過期或誤配置隱患（如近期故障）。
- 監(jiān)控數(shù)據(jù)噪音：因配置不一致，告警誤報/漏報頻發(fā)，影響故障響應(yīng)效率。
-
目標方案
- 唯一事實來源（Single Source of Truth）：通過 Git 倉庫統(tǒng)一管理所有監(jiān)控配置（Prometheus 規(guī)則、ServiceMonitor、AlertManager 等），消除人工干預(yù)。
- GitOps 自動化同步 (reconcile) 與自愈：利用 ArgoCD 等相關(guān) GitOps 專業(yè)工具實現(xiàn)配置實時同步，確保集群狀態(tài)與 Git 聲明一致。
- 集中式可觀測性：通過 Prometheus Operator 標準化部署，如有必要，后續(xù)可以考慮結(jié)合 Thanos/Cortex/Mimir 實現(xiàn)跨集群監(jiān)控數(shù)據(jù)聚合。
二、技術(shù)實現(xiàn)路徑
-
GitOps (Git 作為唯一事實來源) 的標準化流程
- GitOps：將所有監(jiān)控資源（Prometheus CRD、Grafana 儀表盤）存儲在 Git 倉庫，版本控制+Code Review 機制保障變更可追溯。
- 自動化同步 (reconcile)：通過 ArgoCD 等相關(guān) GitOps 專業(yè)工具監(jiān)聽 Git 倉庫變更，自動推送至各集群，避免人工誤操作（這里參考了紅帽 OpenShift GitOps 最佳實踐）。
- 緊急修復(fù)流程：任何生產(chǎn)變更必須通過 Git 提交，僅允許 Git 倉庫作為修改入口，杜絕“臨時補丁”。
-
Prometheus Operator 強化能力
- 統(tǒng)一部署模板：使用 Helm Chart 封裝 Prometheus Stack（AlertManager、BlackBox 等），確保各集群版本與配置一致。
- 動態(tài)服務(wù)發(fā)現(xiàn)：通過 ServiceMonitor 自動識別微服務(wù)端點，避免手動添加 Exporter 導(dǎo)致的遺漏。
三、預(yù)期收益
- 降低運維風(fēng)險：配置漂移減少 90%以上，監(jiān)控組件/閾值/配置實現(xiàn)全自動化管理。
- 提升故障響應(yīng)：通過集中告警視圖與標準化規(guī)則，MTTD（平均故障檢測時間）縮短 50%。
- （待定）成本優(yōu)化：避免重復(fù)開發(fā)監(jiān)控組件，資源利用率提升 30%（通過 Prometheus 聯(lián)邦集群優(yōu)化數(shù)據(jù)存儲，如 Thanos/Cortex/Mimir 等）。
四、后續(xù)計劃
- 試點推進：計劃先搭建一個臨時環(huán)境，進行一段時間的 PoC 驗證，輸出標準化模板及自動化流水線。
-
全球推廣：
- 監(jiān)控專用管理集群搭建。
- 分階段遷移至 GitOps(Git 作為唯一事實來源) + Prometheus Operator 體系，考慮到規(guī)模較大，預(yù)計需要持續(xù)投入。
- 培訓(xùn)與協(xié)同：組織團隊內(nèi)部分享會，同步 GitOps(Git 作為唯一事實來源)+ Prometheus Operator 協(xié)作規(guī)范（分支策略、項目結(jié)構(gòu)策略、Review 流程等）。
??? 參考文檔
- OpenShift GitOps Recommended Practices | Red Hat Developer
- Lightning Talk: Best Practices on Organizing GitOps Repositories - Konstantinos Kapelonis, Codefresh
三人行, 必有我?guī)? 知識共享, 天下為公. 本文由東風(fēng)微鳴技術(shù)博客 EWhisper.cn 編寫.
