因此接下來一段時間，我可能會陸續分享運維過程中對一些問題的思考，希望給大家帶來一定的啟發。

本次分享的是確立一套運維監控體系，構建可持續成長的監控平臺。

1.如何監控？

硬件、基礎狀態、應用、業務，監控對象多而且雜，如何能夠全部覆蓋？

企業內部的各種監控工具，我們應該如何管理？

監控工具之間的信息孤島如何處理？

2.如何告警？

告警太多，如何沉淀有效告警？

告警泛濫，如何進行收斂，避免告警的狂轟濫炸？

3.如何處理？

告警處理無記錄，和企業運維流程脫節，怎樣形成知識沉淀？-----所謂的知識庫，線下整理不及時，增加工作負擔。

告警處理純靠手動，每個月都在重復處理相同故障，如何避免？-----手動處理效率不高，牽扯太多的精力。

以上問題是在建設監控系統時面臨的一些問題，以前我總是想用一個監控產品來實現所有的需求，避免我們在多個產品間來回切換，看來有點舍本逐末。

首先，我們先從監控的本質出發：監控系統的目的是為了及時發現問題，解決問題，直至預測問題，不是為了整合系統。

其次，隨著公司技術棧的不斷升級，業務系統的架構也在不斷演進，而原來傳統監控可能就不能夠滿足監控需求。此時就需要不斷補充監控手段，例如Grafana、Prometheus、ELK，實現圖形化監控、容器監控、日志監控。因此監控平臺一定是多種監控產品并存，而運維需要構建可持續成長的監控平臺。

最后，在認清以上監控治理的現狀后，我們需要實現監控建設的思路轉變：由產品化思路向平臺化思路轉變。即：由要找一個大而全的監控產品，囊括全部的監控訴求轉變為需要一個具備功能生長性的監控平臺，來承載核心監控訴求，并能統一集成外部的各種監控產品，服務于業務監控的目標。

構建功能可持續成長的監控平臺，關鍵在于監控平臺需要具備paas屬性：

監控平臺層，負責提供面向各類監控對象的基本的監控采集、存儲、分析和告警的能力和工具；同時需要提供paas集成能力，能夠對接和集成外部監控工具和系統。

監控場景工具層，通過調用平臺層的監控能力和監控工具，面向具體的應用和業務，提供組裝式的、復合的監控場景工具，例如：統一告警中心、監控可視化、故障自愈等。

總結大體布局如下：

從這套監控架構來看，相信很多小伙伴都已經實現到了iPaaS（監控平臺層）級別的監控，往往忽視了aPaaS（監控場景層）的多樣性需求，如統一告警中心、故障自愈等的需求。而我們建立監控系統就是通過場景去發現問題、解決問題、甚至是預測問題。

雖然以上統一監控完成了監控由產品到平臺的轉變，也同樣存在以下優缺點：

1. 集成不同的監控工具，一定程度上實現了監控數據之前的共享和融合；

2. 業務和應用無法有效關聯，導致告警在一定程度上是脫離業務的，需要運維人員自行腦圖總結；

3. 由于不同工具的接入，平臺層和場景層如何聯動，需要運維人員統一API接入；

看到這，小伙伴會想：為什么問題都是會不期而至呢？因為這些就是我們平時會忽略的細節問題。如果我們能集中資源從細節入手，那么我們可能就會得到意想不到的收獲！

了解過藍鯨的小伙伴，可能對以上內容比較熟悉，但重點是我們如何站在巨人的肩膀上來看清我們的不足，從什么角度去思考問題。

以上的平臺化監控架構可以為我們構建系統監控體系提供了思路，剩下的就是我們如何從細節性問題入手，利用技術手段去解決問題了。