最近一直在搞基于K8S的監(jiān)控告警平臺建設(shè)，查找了不少資料，也實驗了不少次，目前算是有一定的成果了，分享一下，以下是我們的系統(tǒng)架構(gòu)。

圖片

采集端

由于Prometheus的生態(tài)過于組件豐富，所以k8s以及Prometheus協(xié)議的指標(biāo)采集這些還是擁抱Prometheus，使用開源的 exporter，雖然現(xiàn)在的exporter 是比較多，但是良莠不齊、有的 Exporter 寫的非常棒，有的則并不完善，同時寫法各異，每次基礎(chǔ)不同的expoter 都要研究一遍配置，心累，所以針對常用的中間件，使用categraf 進行監(jiān)控，比如 kafka、Mysql、Redis、Mongo等。

存儲端

使用VictoriaMetrics作為的Prometheus長期存儲，因為他性能足夠強悍，占用資源小，并且完全兼容Prometheus，如果指標(biāo)小于100w/s，可以采用他的單機版本，并且安裝到k8s集群外，這樣也避免k8s集群出問題，無從下手。

報警配置

由于prometheus的告警配置實在繁瑣而且對國內(nèi)的通訊工具支持度不好，需要第三方實現(xiàn)，所以我們放棄使用 altermanager進行報警，直接采用夜鶯進行報警配置，這也是目前業(yè)內(nèi)常用玩法。

圖片

展現(xiàn)層

由于VictoriaMetrics后兼容 PromQL。我們都可以按照理解的 PromQL 語法來進行查詢，所以在 Grafana中配置 Prometheus的數(shù)據(jù)源時，填入VictoriaMetrics的地址即可。

同時這里VictoriaMetrics數(shù)據(jù)一部分是prometheus 采集的，一部分是categraf，所以針對categraf采集的，需要自行配置報表，因為可能無法與現(xiàn)有 expoter報表兼容，需要微調(diào)，不過這種都是一次性的工作。

圖片

補充

可能有些人有疑問，說VictoriaMetrics兼容Prometheus，可以完全替換掉Prometheus，是的沒錯，但是我們已經(jīng)用了Prometheus，目前沒有精力去做遷移，等后期有時間逐步過渡到VictoriaMetrics完全替換掉Prometheus。