運維思索：系統監控體系 ｜ 8月更文挑戰

簡述

各位小夥伴，近期技術文感受發的有點多，不知是否給你們在工做中解決實際問題帶來了一些靈感。爲何這麼說呢？由於正是文章中涉及的細小知識點聚沙成塔，讓我從零碎繁忙的運維工做中獲得了必定程度的解放。相信認真讀過的小夥伴，必定會以爲工做中並不是只有什麼高大上的技術才能解決痛點，偏偏相反，正是那些咱們平時忽視的細節纔是問題的要害。那麼只有切中要害，咱們才能對症下藥。

所以接下來一段時間，我可能會陸續分享運維過程當中對一些問題的思考，但願給你們帶來必定的啓發。

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

系統監控現狀及問題

1.如何監控？

硬件、基礎狀態、應用、業務，監控對象多並且雜，如何可以所有覆蓋？ 企業內部的各類監控工具，咱們應該如何管理？ 監控工具之間的信息孤島如何處理？

2.如何告警？

告警太多，如何沉澱有效告警？ 告警氾濫，如何進行收斂，避免告警的狂轟濫炸？

3.如何處理？

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

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

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

平臺化監控思路轉變

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

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

最後，在認清以上監控治理的現狀後，咱們須要實現監控建設的思路轉變：由產品化思路向平臺化思路轉變。即：由要找一個大而全的監控產品，囊括所有的監控訴求轉變爲須要一個具有功能生長性的監控平臺，來承載核心監控訴求，並能統一集成外部的各類監控產品，服務於業務監控的目標。

PaaS屬性

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

1. 監控iPaaS層

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

2. 監控aPaaS層

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

總結大致佈局以下：

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

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

1. 集成不一樣的監控工具，必定程度上實現了監控數據以前的共享和融合；
2. 業務和應用沒法有效關聯，致使告警在必定程度上是脫離業務的，須要運維人員自行腦圖總結；
3. 因爲不一樣工具的接入，平臺層和場景層如何聯動，須要運維人員統一API接入；

看到這，小夥伴會想：爲何問題都是會不期而至呢？由於這些就是咱們平時會忽略的細節問題。若是咱們能集中資源從細節入手，那麼咱們可能就會獲得意想不到的收穫！

總結

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

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