因此接下來(lái)一段時(shí)間，我可能會(huì )陸續分享運維過(guò)程中對一些問(wèn)題的思考，希望給大家帶來(lái)一定的啟發(fā)。

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

1.如何監控？

硬件、基礎狀態(tài)、應用、業(yè)務(wù)，監控對象多而且雜，如何能夠全部覆蓋？

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

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

2.如何告警？

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

告警泛濫，如何進(jìn)行收斂，避免告警的狂轟濫炸？

3.如何處理？

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

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

以上問(wèn)題是在建設監控系統時(shí)面臨的一些問(wèn)題，以前我總是想用一個(gè)監控產(chǎn)品來(lái)實(shí)現所有的需求，避免我們在多個(gè)產(chǎn)品間來(lái)回切換，看來(lái)有點(diǎn)舍本逐末。

首先，我們先從監控的本質(zhì)出發(fā)：監控系統的目的是為了及時(shí)發(fā)現問(wèn)題，解決問(wèn)題，直至預測問(wèn)題，不是為了整合系統。

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

最后，在認清以上監控治理的現狀后，我們需要實(shí)現監控建設的思路轉變：由產(chǎn)品化思路向平臺化思路轉變。即：由要找一個(gè)大而全的監控產(chǎn)品，囊括全部的監控訴求轉變?yōu)樾枰粋€(gè)具備功能生長(cháng)性的監控平臺，來(lái)承載核心監控訴求，并能統一集成外部的各種監控產(chǎn)品，服務(wù)于業(yè)務(wù)監控的目標。

構建功能可持續成長(cháng)的監控平臺，關(guān)鍵在于監控平臺需要具備paas屬性：

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

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

總結大體布局如下：

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

雖然以上統一監控完成了監控由產(chǎn)品到平臺的轉變，也同樣存在以下優(yōu)缺點(diǎn)：

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

2. 業(yè)務(wù)和應用無(wú)法有效關(guān)聯(lián)，導致告警在一定程度上是脫離業(yè)務(wù)的，需要運維人員自行腦圖總結；

3. 由于不同工具的接入，平臺層和場(chǎng)景層如何聯(lián)動(dòng)，需要運維人員統一API接入；

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

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

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