最近一直在搞基于K8S的監控告警平臺建設，查找了不少資料，也實驗了不少次，目前算是有一定的成果了，分享一下，以下是我們的系統架構。

圖片

采集端

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

存儲端

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

報警配置

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

圖片

展現層

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

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

圖片

補充

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