隨著業(yè)務(wù)和IT信息化的發(fā)展建設(shè)，為確保基礎(chǔ)設(shè)施的全面監(jiān)控，企業(yè)積極采購了多樣化的監(jiān)控設(shè)施，這些設(shè)施廣泛覆蓋了操作系統(tǒng)、關(guān)鍵組件以及硬件等多個層面，從而初步完成了IT技術(shù)設(shè)施和運維管理工具的建設(shè)。然而，隨著業(yè)務(wù)的迅速增長，現(xiàn)有的運維設(shè)施和系統(tǒng)開始暴露出諸多挑戰(zhàn)，資源分散，缺乏有效的統(tǒng)一規(guī)范化管理，導(dǎo)致監(jiān)控覆蓋不全，告警治理變得困難重重。此外，監(jiān)控配置成本高昂、效率低下，且團隊協(xié)作難度增加，這些因素都使得企業(yè)難以迅速響應(yīng)業(yè)務(wù)的變化和需求。在這個背景下，建設(shè)一體化監(jiān)控平臺的訴求逐漸成為各個企業(yè)的監(jiān)控建設(shè)重心。

面對這些問題，某大型運營商企業(yè)基于嘉為藍鯨監(jiān)控中心，啟動了基礎(chǔ)設(shè)施運維管理系統(tǒng)建設(shè)工程，通過重塑運維體系，構(gòu)建統(tǒng)一的一體化監(jiān)控平臺，全方位提升監(jiān)控管理水平，提升運維管理效率，為IT系統(tǒng)的安全、持續(xù)、不間斷運行提供有力的支撐。

01. 業(yè)務(wù)場景

該企業(yè)在多年的運維監(jiān)控中，通過自行搭建Zabbix、Prometheus等開源監(jiān)控平臺，自行實施了大量操作系統(tǒng)、組件服務(wù)的監(jiān)控，同時外采了硬件監(jiān)控產(chǎn)品補足硬件監(jiān)控能力。但隨著企業(yè)的發(fā)展，這種缺乏完整監(jiān)控體系的管理模式逐漸暴露出監(jiān)控缺乏監(jiān)管——覆蓋率低、沒有統(tǒng)一規(guī)范——策略配置混亂、各監(jiān)控系統(tǒng)混合部署——運維管理復(fù)雜等問題。傳統(tǒng)的監(jiān)控管理模式越發(fā)難以推進，亟需建設(shè)統(tǒng)一的監(jiān)控平臺。

02. 分析痛點

該公司目前的監(jiān)控建設(shè)正處于煙囪工具式監(jiān)控建設(shè)階段，且各類監(jiān)控場景尚不完備。客戶期望在補足監(jiān)控能力的同時，建立成熟的一體化監(jiān)控平臺。從各個運維場景下看，企業(yè)目前具備以下痛點：

• 操作系統(tǒng)監(jiān)控：已部署Zabbix和Prometheus，由各業(yè)務(wù)系統(tǒng)自行配置監(jiān)控，沒有統(tǒng)一的指標(biāo)體系、閾值規(guī)范，整體監(jiān)控處于缺乏管控狀態(tài)；
• 組件監(jiān)控：原監(jiān)控系統(tǒng)對于組件監(jiān)控過于簡單，缺少核心指標(biāo)的采集，且沒有策略模板，不清楚如何配置監(jiān)控；
• 容器監(jiān)控：容器監(jiān)控能力缺失，容器資源及容器組件服務(wù)整體處于未監(jiān)控狀態(tài)，系統(tǒng)運行保障風(fēng)險極高；
• 統(tǒng)一監(jiān)控平臺：已采購第三方硬件監(jiān)控產(chǎn)品，獨立管理，每次使用時都需單獨登錄硬件管理平臺進行配置，授權(quán)和管理體系復(fù)雜，使用不便。期望能通過一體化監(jiān)控平臺進行統(tǒng)一管理。

03. 解決方案

1）操作系統(tǒng)監(jiān)控 —— 基于藍鯨Agent的指標(biāo)采集

嘉為藍鯨監(jiān)控中心以藍鯨Agent為核心，內(nèi)置操作系統(tǒng)采集插件，只要部署了藍鯨Agent，就會自動采集操作系統(tǒng)相關(guān)指標(biāo)數(shù)據(jù)，無需手動配置。通過One Agent的方式，該公司實現(xiàn)內(nèi)部操作系統(tǒng)的統(tǒng)一監(jiān)控、采集。

2）組件監(jiān)控 —— 強大的采集擴展能力，積累豐富

監(jiān)控中心采用Agent+Plugins的設(shè)計模式，支持通過系統(tǒng)腳本、SQL語句、Exporter、Datadog插件等模式快速擴展各類監(jiān)控對象的監(jiān)控，解決Agent模式下各類組件對象的監(jiān)控數(shù)據(jù)采集問題。

同時監(jiān)控中心支持通過協(xié)議/接口（支持SNMP、IPMI、JMX、SQL、BK-Pull等）模式進行擴展，遠程收集數(shù)據(jù)，解決了各種無代理場景下的組件監(jiān)控問題。

基于上述模式，監(jiān)控中心同時還積累內(nèi)置了大量標(biāo)準(zhǔn)化插件，覆蓋絕大部分主流數(shù)據(jù)庫、中間件。同時具備成熟的指標(biāo)體系建設(shè)，提供最佳實踐配置模板，引導(dǎo)用戶進行監(jiān)控檢測。

3）容器監(jiān)控 —— 覆蓋容器資源、容器服務(wù)指標(biāo)，全方位監(jiān)控

基于K8s原生的Prometheus監(jiān)控方案優(yōu)化改造，該公司實現(xiàn)以下場景的容器監(jiān)控：

支持對容器內(nèi)各類資源對象進行發(fā)現(xiàn)，并采集相關(guān)性能指標(biāo)，包括Cluster、Workload、Pod、Container、Node

支持容器上部署的組件服務(wù)監(jiān)控，可通過以下方式進行數(shù)據(jù)采集：
- 支持serviceMonitor（主推）和podMonitor
- sidecar 方式（ 以sidecar模式部署exporter抓取器暴露出metrics，結(jié)合serviceMonitor進行采集）
- 中心遠程統(tǒng)一采集 (組件本身暴露了/metrics，結(jié)合serviceMonitor進行采集)

4）統(tǒng)一監(jiān)控 —— 第三方監(jiān)控源數(shù)據(jù)接入，建立一體化監(jiān)控平臺

該公司通過嘉為藍鯨監(jiān)控系統(tǒng)，實現(xiàn)第三方監(jiān)控數(shù)據(jù)接入，通過開發(fā)監(jiān)控源插件進行對接，抓取或接收其他監(jiān)控系統(tǒng)數(shù)據(jù)。如果對數(shù)據(jù)進行一定的數(shù)據(jù)結(jié)構(gòu)清洗，還可將接入數(shù)據(jù)與藍鯨CMDB實例進行關(guān)聯(lián)，從而在指標(biāo)管理、數(shù)據(jù)檢測、可視化等能力上與嘉為藍鯨監(jiān)控中心自采集數(shù)據(jù)完全持平，建設(shè)真正的一體化監(jiān)控平臺。

04. 成果展示

1）操作系統(tǒng)監(jiān)控 —— 基于藍鯨Agent的指標(biāo)采集

2）組件監(jiān)控 —— 企業(yè)內(nèi)核心數(shù)據(jù)庫、中間件監(jiān)控接入，策略配置

3）容器監(jiān)控 —— K8s容器管理平臺監(jiān)控接入

4）統(tǒng)一監(jiān)控 —— 第三方監(jiān)控源數(shù)據(jù)接入，建立一體化監(jiān)控平臺

05. 建設(shè)成效

06. 場景適用性

嘉為藍鯨監(jiān)控中心目前已在各個運維分層場景中，具備了完整的監(jiān)控方案和最佳實踐引導(dǎo)，可以幫助企業(yè)盡可能多地完成監(jiān)控覆蓋；同時提供成熟的監(jiān)控數(shù)據(jù)集成方案，既能與第三方監(jiān)控系統(tǒng)進行數(shù)據(jù)對接，也能在數(shù)據(jù)處理、存儲、可視化等層面提供完全一致的能力與體驗。適用于以下類型的企業(yè)：

• 監(jiān)控接入不規(guī)范，各個業(yè)務(wù)系統(tǒng)獨立運行，監(jiān)控體系沒有統(tǒng)一治理的企業(yè)；
• 已實施了基礎(chǔ)的監(jiān)控采集，但是缺乏有效的指標(biāo)體系建設(shè)，監(jiān)測告警配置不規(guī)范的企業(yè)；
• 監(jiān)控覆蓋率不高，容器監(jiān)控、硬件監(jiān)控等場景缺失，希望補足這些場景的監(jiān)控能力的企業(yè)；
• 煙囪式監(jiān)控環(huán)境，各類場景監(jiān)控系統(tǒng)雖具備，但完全獨立，管理復(fù)雜，亟需建設(shè)統(tǒng)一監(jiān)控平臺的企業(yè)。