因此接下來一段時(shí)間，我可能會(huì)陸續(xù)分享運(yùn)維過程中對(duì)一些問題的思考，希望給大家?guī)硪欢ǖ膯l(fā)。

本次分享的是確立一套運(yùn)維監(jiān)控體系，構(gòu)建可持續(xù)成長(zhǎng)的監(jiān)控平臺(tái)。

1.如何監(jiān)控？

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

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

監(jiān)控工具之間的信息孤島如何處理？

2.如何告警？

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

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

3.如何處理？

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

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

以上問題是在建設(shè)監(jiān)控系統(tǒng)時(shí)面臨的一些問題，以前我總是想用一個(gè)監(jiān)控產(chǎn)品來實(shí)現(xiàn)所有的需求，避免我們?cè)诙鄠€(gè)產(chǎn)品間來回切換，看來有點(diǎn)舍本逐末。

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

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

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

構(gòu)建功能可持續(xù)成長(zhǎng)的監(jiān)控平臺(tái)，關(guān)鍵在于監(jiān)控平臺(tái)需要具備paas屬性：

監(jiān)控平臺(tái)層，負(fù)責(zé)提供面向各類監(jiān)控對(duì)象的基本的監(jiān)控采集、存儲(chǔ)、分析和告警的能力和工具；同時(shí)需要提供paas集成能力，能夠?qū)雍图赏獠勘O(jiān)控工具和系統(tǒng)。

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

總結(jié)大體布局如下：

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

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

1. 集成不同的監(jiān)控工具，一定程度上實(shí)現(xiàn)了監(jiān)控?cái)?shù)據(jù)之前的共享和融合；

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

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

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

了解過藍(lán)鯨的小伙伴，可能對(duì)以上內(nèi)容比較熟悉，但重點(diǎn)是我們?nèi)绾握驹诰奕说募绨蛏蟻砜辞逦覀兊牟蛔?，從什么角度去思考問題。

以上的平臺(tái)化監(jiān)控架構(gòu)可以為我們構(gòu)建系統(tǒng)監(jiān)控體系提供了思路，剩下的就是我們?nèi)绾螐募?xì)節(jié)性問題入手，利用技術(shù)手段去解決問題了。