基于系統(tǒng)融合的統(tǒng)一監(jiān)控平臺設(shè)計(jì)

基于系統(tǒng)融合的統(tǒng)一監(jiān)控平臺設(shè)計(jì)

【導(dǎo)讀】目前做監(jiān)控廠商的產(chǎn)品基本上都是大雜燴，各種概念和名詞很多，強(qiáng)調(diào)集成或加agent等加層的方式去實(shí)現(xiàn)，和軟件工程、系統(tǒng)化的思想其實(shí)是相矛盾的。為了厘清統(tǒng)一監(jiān)控平臺方案的設(shè)計(jì)思路，簡化設(shè)計(jì)實(shí)施的難度和復(fù)雜度，減少重復(fù)建設(shè)，本文將詳細(xì)討論統(tǒng)一監(jiān)控平臺的設(shè)計(jì)。最近聽了《業(yè)務(wù)流程重構(gòu)(BusinessProcessReengineering)》，感覺和我一直以來的一些體會和思路不謀而合。道理都是相通的，殊途同歸。fundamentalrethinking(徹底的重新思考)、radicalredesign（根本的重新設(shè)計(jì)）、dramaticimprovement（顯著的提升）。系統(tǒng)融合思路就是基于徹底的思考，重新的設(shè)計(jì)，以期獲得顯著的提升。在容器云平臺建設(shè)的時(shí)候，我們就考慮并提出過圍繞容器云平臺的監(jiān)控方案。監(jiān)控、日志等不應(yīng)該是容器云平臺的組件而應(yīng)該獨(dú)立于容器云平臺并同時(shí)支撐容器云平臺的獨(dú)立組件或獨(dú)立平臺。每個(gè)系統(tǒng)都會涉及監(jiān)控、日志等功能，所以這些功能就可以提取出來，實(shí)現(xiàn)復(fù)用，構(gòu)建獨(dú)立的統(tǒng)一監(jiān)控中心、集中日志中心等，再基于這些統(tǒng)一監(jiān)控、集中日志等平臺構(gòu)建可復(fù)用的監(jiān)控、日志等服務(wù)，建設(shè)企業(yè)級技術(shù)中臺（技術(shù)中臺服務(wù)）。圍繞容器云、DevOps、微服務(wù)等的云原生討論也很多，通常都是只重一個(gè)或幾個(gè)點(diǎn)，很少有全局的和頂層的考慮，所以監(jiān)控等也基本上沒有全局的方案。監(jiān)控能力散落于各個(gè)單體系統(tǒng)，從而導(dǎo)致了人為的部門墻。容器云、DevOps、微服務(wù)等技術(shù)相輔相成，非常適合從整體上來考慮，構(gòu)建企業(yè)級的平臺和中臺，從而支撐企業(yè)敏捷變化的業(yè)務(wù)需求，支撐企業(yè)業(yè)務(wù)實(shí)踐和轉(zhuǎn)型。而監(jiān)控是其中必不可少的部分。所以我們一直也在考慮如何和容器云平臺、DevOps融合等來通過分布式微服務(wù)架構(gòu)建設(shè)統(tǒng)一監(jiān)控平臺。目前做監(jiān)控廠商的產(chǎn)品基本上都是大雜燴，各種概念和名詞很多，強(qiáng)調(diào)集成或加agent等加層的方式去實(shí)現(xiàn)，和軟件工程、系統(tǒng)化的思想其實(shí)是相矛盾的。拔冗去繁，撥云見日，監(jiān)控?zé)o非就是監(jiān)控?cái)?shù)據(jù)采集和監(jiān)控?cái)?shù)據(jù)接入、監(jiān)控?cái)?shù)據(jù)處理（包括監(jiān)控實(shí)時(shí)數(shù)據(jù)處理和監(jiān)控歷史數(shù)據(jù)處理）、數(shù)據(jù)存儲和查詢顯示。其他的功能都是基于監(jiān)控的數(shù)據(jù)的進(jìn)一步擴(kuò)展，比如鏈路跟蹤與拓?fù)湔故?、指?biāo)管理、探針管理、故障檢測、異常處理、工單流程管理、知識庫等（如圖1統(tǒng)一監(jiān)控方案思路）。圖1統(tǒng)一監(jiān)控方案設(shè)計(jì)思路為了厘清統(tǒng)一監(jiān)控平臺方案的設(shè)計(jì)思路，簡化設(shè)計(jì)實(shí)施的難度和復(fù)雜度，減少重復(fù)建設(shè)，我們今天詳細(xì)討論下統(tǒng)一監(jiān)控平臺的設(shè)計(jì)。整體思路可以考慮縱向分層、橫向分段、側(cè)向管控的方法來設(shè)計(jì)實(shí)現(xiàn)。把應(yīng)用涉及的整個(gè)軟硬件環(huán)境當(dāng)作一個(gè)整體、一個(gè)系統(tǒng)、一個(gè)體系來看待，從而形成一個(gè)全局立體體系。一、縱向分層目前實(shí)際的業(yè)務(wù)應(yīng)用系統(tǒng)，至少是C/S、B/S兩層架構(gòu)，而分布式架構(gòu)往往層次更多，從前端、中間服務(wù)層、數(shù)據(jù)庫或數(shù)據(jù)存儲層以及中間件組件、操作系統(tǒng)、基礎(chǔ)設(shè)施資源服務(wù)器、網(wǎng)絡(luò)設(shè)備等，任何一個(gè)節(jié)點(diǎn)出現(xiàn)異常都有可能影響到業(yè)務(wù)應(yīng)用的運(yùn)行。比如說服務(wù)器磁盤損壞，可能導(dǎo)致數(shù)據(jù)庫或文件不可用，從而導(dǎo)致應(yīng)用異常等等。既然每一層都有可能出現(xiàn)故障，那么每一層都需要進(jìn)行監(jiān)控，并且需要把各層之間的關(guān)系串接起來，形成鏈路。通過鏈路實(shí)時(shí)展示就可以知道哪一層有異常，快速的定位和處理問題。這就是監(jiān)控分層的價(jià)值。監(jiān)控分層分布式系統(tǒng)帶來了運(yùn)維的復(fù)雜性，特別容器化之后，靈活性更高，但層次更多，運(yùn)維復(fù)雜化。如果有沒良好的監(jiān)控平臺和工具，一旦容器達(dá)到一定量之后，就會超出人的管控能力，遇到異常問題就需要花費(fèi)大量的時(shí)間排查問題。監(jiān)控縱向分層的思想就是把應(yīng)用監(jiān)控?cái)?shù)據(jù)采集的問題簡單化，也使應(yīng)用調(diào)用處理過程的鏈路更清晰，更好的實(shí)現(xiàn)鏈路跟蹤、鏈路拓?fù)湔故?，更好更快的定位問題，處理異常。當(dāng)然這需要提前做整體規(guī)劃、全局的設(shè)計(jì)。比如說日志為監(jiān)控提供了很重要的支撐，日志的鏈路ID就需要全局定義。從打開前端頁面到中臺服務(wù)到后臺資源等，這個(gè)鏈路能夠通過全局ID關(guān)聯(lián)起來。監(jiān)控分層可根據(jù)實(shí)際的業(yè)務(wù)鏈路進(jìn)行劃分，比如說前端渠道、前端應(yīng)用（Client）、中臺可復(fù)用服務(wù)、中間件、后端服務(wù)、服務(wù)部署運(yùn)行平臺、數(shù)據(jù)平臺/數(shù)據(jù)庫、軟件基礎(chǔ)設(shè)施、硬件基礎(chǔ)設(shè)施等。分層目的是為了簡化監(jiān)控?cái)?shù)據(jù)采集，便于實(shí)現(xiàn)鏈路跟蹤、問題下鉆定位等能力。鏈路跟蹤、拓?fù)湔故就ㄟ^分層，才能更好的實(shí)現(xiàn)鏈路跟蹤能力。其實(shí)我們需要考慮的不止是應(yīng)用服務(wù)之間的調(diào)用關(guān)系，也需要考慮支撐這些應(yīng)用服務(wù)的組件、工具、操作系統(tǒng)、基礎(chǔ)設(shè)施資源等。這樣才能形成多個(gè)相互關(guān)聯(lián)的閉環(huán)。這也我們思考規(guī)劃建設(shè)統(tǒng)一監(jiān)控平臺的原因。當(dāng)然業(yè)務(wù)應(yīng)用的鏈路跟蹤是核心。應(yīng)用部署于支撐平臺，支撐平臺運(yùn)行在容器、虛擬機(jī)、物理服務(wù)器等中，又涉及不同的操作系統(tǒng)、系統(tǒng)配置、CPU、內(nèi)存、網(wǎng)絡(luò)、磁盤、存儲等眾多的資源，在出現(xiàn)故障的時(shí)候需要抽絲剝繭，往往需要花費(fèi)大量的時(shí)間和精力來定位故障，找到rootcause。比如說節(jié)點(diǎn)磁盤空間滿了導(dǎo)致某個(gè)中間件服務(wù)停掉，無法啟動(dòng)，但異常往往是從應(yīng)用曝出，從應(yīng)用、日志、中間件、節(jié)點(diǎn)、磁盤等過程定位，雖然最終可能會解決問題，但其代價(jià)卻是很高昂的。因此，監(jiān)控從端到端實(shí)現(xiàn)分層，這樣可以明確每個(gè)層次所采集的指標(biāo)和內(nèi)容。通過統(tǒng)一的鏈路來快速定位故障，在系統(tǒng)融合階段將變得越來越重要。鏈路跟蹤需要采集各個(gè)層次對象的指標(biāo)，采集的指標(biāo)根據(jù)監(jiān)控對象的不同和監(jiān)控指標(biāo)的需求分別定義，每個(gè)應(yīng)用從前端到后端往往經(jīng)過若干個(gè)調(diào)用層次，可能涉及不同的對象和系統(tǒng)、平臺、工具等，往往比較難用統(tǒng)一的標(biāo)準(zhǔn)去套這些對象，這也是統(tǒng)一監(jiān)控落地比較難的地方，但這也是非常關(guān)鍵的。如果這些指標(biāo)都能抽象并映射到不同的對象，那么統(tǒng)一監(jiān)控平臺的建設(shè)將非常容易。有了標(biāo)準(zhǔn)化的指標(biāo)，從前端到后端實(shí)現(xiàn)端到端的數(shù)據(jù)采集則可以實(shí)現(xiàn)鏈路跟蹤，以拓?fù)湫问秸故痉?wù)/系統(tǒng)之間調(diào)用關(guān)系。在出現(xiàn)異常的情況下，可以快速下鉆到根故障點(diǎn)，從而快速定位故障并解決故障。二、橫向分段監(jiān)控?cái)?shù)據(jù)采集監(jiān)控首先是監(jiān)控?cái)?shù)據(jù)的采集。要采集數(shù)據(jù)，需要知道從哪里采集，采集什么樣的數(shù)據(jù)，怎么采集數(shù)據(jù)。這就是監(jiān)控對象、監(jiān)控指標(biāo)、和監(jiān)控?cái)?shù)據(jù)采集方法。1.監(jiān)控對象監(jiān)控對象就是我們監(jiān)控采集數(shù)據(jù)的源端，包括眾多的應(yīng)用、系統(tǒng)、組件、平臺、數(shù)據(jù)庫、服務(wù)器、網(wǎng)絡(luò)設(shè)備等等。由于這些應(yīng)用和系統(tǒng)眾多，需要監(jiān)控的點(diǎn)（指標(biāo)）也可能各不相同，這就可能導(dǎo)致我們在實(shí)施統(tǒng)一監(jiān)控項(xiàng)目時(shí)有點(diǎn)無從下手。而廠商的監(jiān)控產(chǎn)品是這些年的積累，五花八門，積累的時(shí)間越長，可能包含的東西就越多、越雜亂。國內(nèi)大部分軟件廠商的一個(gè)重要特點(diǎn)是基本上都是從做項(xiàng)目開始的，缺乏產(chǎn)品的頂層規(guī)劃和設(shè)計(jì)，所以一個(gè)產(chǎn)品可能無所不包，什么都有但什么都不夠精深，所以更像是大雜燴。這么說可能得罪很多廠商，但我們還是希望國內(nèi)的軟件廠商能真正靜下心好好思考，真正的爭口氣，真正的強(qiáng)大起來，真正的把產(chǎn)品做好做強(qiáng)。由于目前各種應(yīng)用系統(tǒng)架構(gòu)、開發(fā)語言、接口方式等很多都不相同，這無疑增加了統(tǒng)一監(jiān)控平臺的實(shí)施難度。所以很多人直接去部署一個(gè)agent來采集數(shù)據(jù)。這也導(dǎo)致了可能很多agent在運(yùn)行，使運(yùn)維工作復(fù)雜化。所以在考慮統(tǒng)一監(jiān)控平臺的時(shí)候需要梳理監(jiān)控對象，分層、分類進(jìn)行梳理。硬件服務(wù)器的監(jiān)控和軟件應(yīng)用的監(jiān)控差別一定是很大的，所以首先要明確監(jiān)控對象、監(jiān)控目標(biāo)才能確定監(jiān)控指標(biāo)和監(jiān)控?cái)?shù)據(jù)采集方式。2.監(jiān)控指標(biāo)和監(jiān)控指標(biāo)目標(biāo)每個(gè)存量應(yīng)用或每套存量系統(tǒng)或多或少都會有相應(yīng)的監(jiān)控能力。首先需要梳理下這些監(jiān)控對象的監(jiān)控能力，確定監(jiān)控采集的指標(biāo)，比如請求到來時(shí)間、請求處理等待時(shí)間、CPU時(shí)間、響應(yīng)時(shí)間計(jì)算、平均響應(yīng)時(shí)間計(jì)算、最大響應(yīng)時(shí)間記錄、線程數(shù)、進(jìn)程數(shù)、CPU、內(nèi)存使用等等，這就是監(jiān)控對象的監(jiān)控采集指標(biāo)的定義。每個(gè)監(jiān)控層次監(jiān)控指標(biāo)有一些通用性的指標(biāo)，但每個(gè)監(jiān)控對象都有自身的一些特定指標(biāo)。通用指標(biāo)和特定指標(biāo)的集合反映了監(jiān)控對象的運(yùn)行狀況。對于新的應(yīng)用和系統(tǒng)，要考慮通過標(biāo)準(zhǔn)化的監(jiān)控采集方式采集標(biāo)準(zhǔn)化的監(jiān)控指標(biāo)，這在建設(shè)統(tǒng)一監(jiān)控平臺的時(shí)候需要明確定義。這樣才能更好的基于監(jiān)控?cái)?shù)據(jù)首先更多的功能，比如鏈路跟蹤、異常定位、智能運(yùn)維等。GoogleSRE提出了在定義監(jiān)控指標(biāo)的同時(shí)要關(guān)注監(jiān)控指標(biāo)目標(biāo)。所謂監(jiān)控指標(biāo)目標(biāo)也就是服務(wù)質(zhì)量目標(biāo)，是指標(biāo)的目標(biāo)值或者目標(biāo)范圍。通過目標(biāo)值可以確定采集到的指標(biāo)值是否在合理范圍內(nèi)。通常確定一個(gè)合理的目標(biāo)值并不容易，往往需要大量實(shí)踐總結(jié)。3.監(jiān)控采集方式監(jiān)控對象不一樣，監(jiān)控需求、監(jiān)控指標(biāo)和監(jiān)控?cái)?shù)據(jù)采集方式也可能會不一樣的。數(shù)據(jù)采集，首要考慮是通過應(yīng)用或系統(tǒng)本身來提供數(shù)據(jù)，通過接口對外提供監(jiān)控?cái)?shù)據(jù)，是publish分發(fā)方式，而不是pull拉取方式。通過publish方法，所有需要這些數(shù)據(jù)的對象（接收端）都可以接收，增加接收端而不需要額外付出代價(jià)。存量系統(tǒng)往往不支持這樣的方式，所以需要通過部署agent、daemonset等方式來采集數(shù)據(jù)。不管用agent或者探針、daemonset等方式，都相當(dāng)于加了一層，是集成的方式，性能和效率都會受到影響，也會帶來額外的管理復(fù)雜度。所以監(jiān)控?cái)?shù)據(jù)采集最好是監(jiān)控對象直接吐出需要采集的監(jiān)控指標(biāo)數(shù)據(jù)，而不是通過集成方式。比如容器云平臺的運(yùn)行數(shù)據(jù)直接通過容器云平臺把數(shù)據(jù)吐出，云管平臺的虛擬機(jī)運(yùn)行數(shù)據(jù)由云管平臺來把數(shù)據(jù)吐出等。這樣每個(gè)層次的數(shù)據(jù)就可以實(shí)現(xiàn)復(fù)用。降低對接、集成工作量，降低系統(tǒng)建設(shè)復(fù)雜度，也降低運(yùn)維難度。我們理解很多時(shí)候?yàn)榱丝焖偕暇€，直接對接監(jiān)控工具，比如Prometheus、Zabbix等，但這些數(shù)據(jù)有時(shí)候跟我們期望的數(shù)據(jù)會有差別。我們在容器云平臺運(yùn)維的時(shí)候，就發(fā)現(xiàn)通過Prometheus的數(shù)據(jù)有時(shí)間會導(dǎo)致誤告警，docker的運(yùn)行數(shù)據(jù)和pod的運(yùn)行數(shù)據(jù)以及Prometheus的監(jiān)控?cái)?shù)據(jù)會有差別，因此，最好的方式是直接由容器云平臺提供docker和pod的運(yùn)行數(shù)據(jù)，而不是再經(jīng)過Prometheus等中間層。監(jiān)控?cái)?shù)據(jù)處理監(jiān)控?cái)?shù)據(jù)包括實(shí)時(shí)數(shù)據(jù)和歷史數(shù)據(jù)。實(shí)時(shí)數(shù)據(jù)和歷史數(shù)據(jù)的價(jià)值不一樣，其處理方式也有不同。實(shí)際的業(yè)務(wù)處理往往需要基于歷史數(shù)據(jù)經(jīng)驗(yàn)并結(jié)合實(shí)時(shí)數(shù)據(jù)，實(shí)現(xiàn)更準(zhǔn)備的一個(gè)預(yù)判。1.監(jiān)控實(shí)時(shí)數(shù)據(jù)處理實(shí)時(shí)數(shù)據(jù)往往價(jià)值最高，隨著時(shí)間的推移，數(shù)據(jù)逐漸失去價(jià)值。監(jiān)控的實(shí)施可以考慮分層來實(shí)現(xiàn)，從前端、中間服務(wù)（或中臺服務(wù)）到基礎(chǔ)設(shè)施平臺、資源，每個(gè)層次每個(gè)組件每個(gè)對象都需要進(jìn)行監(jiān)控以跟蹤其運(yùn)行狀態(tài)，分析其運(yùn)行情況和可能趨勢。通過實(shí)時(shí)的監(jiān)控則可以實(shí)現(xiàn)實(shí)時(shí)風(fēng)險(xiǎn)管控和實(shí)時(shí)風(fēng)險(xiǎn)處理，避免后知后覺，造成額外的損失。對于實(shí)時(shí)數(shù)據(jù)往往需要實(shí)現(xiàn)實(shí)時(shí)事件處理能力，可以建立復(fù)雜事件處理系統(tǒng)進(jìn)行實(shí)時(shí)事件處理，結(jié)合歷史數(shù)據(jù)學(xué)習(xí)所構(gòu)建的態(tài)勢感知、風(fēng)險(xiǎn)控制算法等提升實(shí)時(shí)業(yè)務(wù)處理能力。2.監(jiān)控歷史數(shù)據(jù)處理歷史數(shù)據(jù)則關(guān)注歷史趨勢和統(tǒng)計(jì)分析。比如我們提到的基于歷史數(shù)據(jù)的態(tài)勢感知分析預(yù)測能力、風(fēng)險(xiǎn)模型等。當(dāng)然對具體的客戶來說，其某個(gè)時(shí)點(diǎn)的歷史數(shù)據(jù)為該客戶提供了該時(shí)點(diǎn)的記錄，也有意義，但也僅僅查看、對比等，可能就無法基于該數(shù)據(jù)做投資等決策。3.日志日志是采集的一部分，由于日志量大，所以可以單獨(dú)對日志進(jìn)行處理，但日志的監(jiān)控和數(shù)據(jù)處理結(jié)果要回歸監(jiān)控平臺。也就是說，日志存儲可以單獨(dú)存儲在文件、數(shù)據(jù)庫、ES、或大數(shù)據(jù)平臺等，不過需要考慮實(shí)現(xiàn)日志的查詢搜索能力，支持快速日志數(shù)據(jù)查詢和過濾，支持時(shí)間區(qū)間、關(guān)鍵字等查詢或全文查詢、模糊查詢等能力。這些能力可以和技術(shù)中臺的搜索中臺、消息中臺等能力結(jié)合，實(shí)現(xiàn)日志的統(tǒng)一處理和管控。數(shù)據(jù)存儲作為企業(yè)的重要資產(chǎn)和生產(chǎn)要素，數(shù)據(jù)是需要落地的，需要保存起來以被查詢、統(tǒng)計(jì)、分析等之用。所有的數(shù)據(jù)需要存儲，可以根據(jù)實(shí)際選擇存儲的方式。并不一定存在一個(gè)地方。按照微服務(wù)架構(gòu)的思想，數(shù)據(jù)是可以分庫存放的。監(jiān)控?cái)?shù)據(jù)量往往是很大的，但監(jiān)控?cái)?shù)據(jù)的價(jià)值隨著時(shí)間快速衰減。比如說節(jié)點(diǎn)資源的使用情況監(jiān)控，像證券每工作日周期性的高峰流量，會導(dǎo)致資源使用的周期性高峰，為了查看一段時(shí)間的資源趨勢，就可以保存一個(gè)月、3個(gè)月等的數(shù)據(jù)。保存的數(shù)據(jù)和采集的數(shù)據(jù)的時(shí)間間隔往往也是不一樣的。比如數(shù)據(jù)采集可能是每2秒一次，但1周之前的數(shù)據(jù)可能只保存1分鐘一次的數(shù)據(jù)，1月之前可能保存5分鐘一次的數(shù)據(jù)。具體的策略根據(jù)實(shí)際業(yè)務(wù)需求來定義。數(shù)據(jù)可以存放在數(shù)據(jù)庫、或者大數(shù)據(jù)平臺，也可以是文件、ES等地方，通常要基于系統(tǒng)架構(gòu)和技術(shù)能力進(jìn)行決策。沒有十全十美的方案，每種方案都會有優(yōu)缺點(diǎn)，選擇適合自己的方案就好。查詢展示存儲方式的選擇很重要一點(diǎn)是為了便于查詢和搜索。數(shù)據(jù)要用起來，流轉(zhuǎn)起來，才能真正體現(xiàn)數(shù)據(jù)的價(jià)值。監(jiān)控采集的數(shù)據(jù)要能便利的展示給不同的角色人員。每個(gè)角色的權(quán)限可能是不一樣的，所以看到的數(shù)據(jù)也可能是不一樣的。這和我們前面提到的分層思想一致，不同的人員負(fù)責(zé)不同的工作，其權(quán)限也是不一樣的。通過授權(quán)等機(jī)制，在保障安全的前提下，可以實(shí)現(xiàn)故障數(shù)據(jù)的查詢展示、定位處理等，那么數(shù)據(jù)就需要根據(jù)角色及其權(quán)限進(jìn)行展示和過濾，以確保數(shù)據(jù)的安全。三、側(cè)向管控統(tǒng)一監(jiān)控平臺本身依然可以是一個(gè)獨(dú)立的系統(tǒng)，同時(shí)又是企業(yè)融合系統(tǒng)中的一個(gè)模塊或組件或子系統(tǒng)，所以實(shí)際應(yīng)用過程依然中需要對這個(gè)子系統(tǒng)進(jìn)行管控，比如訪問權(quán)限的設(shè)置控制等。還有監(jiān)控平臺自身對象和屬性的管理，比如指標(biāo)的定義和管理、指標(biāo)目標(biāo)、服務(wù)協(xié)議的定義和管理、探針的管理、腳本的管理、通用配置的管理、日志、審計(jì)等功能。這些都是平臺需要實(shí)現(xiàn)的能力。認(rèn)證權(quán)限、訪問控制管理登錄認(rèn)證、權(quán)限管理是每個(gè)系統(tǒng)都需要的基本功能，所以認(rèn)證、權(quán)限等能力就可以提取出來以可復(fù)用服務(wù)的形式作為中臺的能力，實(shí)現(xiàn)企業(yè)級共享，避免重復(fù)建設(shè)、降低成本提供效率。統(tǒng)一監(jiān)控平臺可以直接使用身份認(rèn)證中臺服務(wù)（基于認(rèn)證平臺提取沉淀）和權(quán)限管理中臺的服務(wù)（基于權(quán)限平臺）實(shí)現(xiàn)認(rèn)證和權(quán)限管理就可以了，不需要再重復(fù)開發(fā)登錄認(rèn)證和權(quán)限管理能力。指標(biāo)定義和管理對于每一次的每一個(gè)監(jiān)控對象定義其監(jiān)控指標(biāo)。比如服務(wù)的響應(yīng)時(shí)間、平均響應(yīng)時(shí)間、最大響應(yīng)時(shí)間、最小響應(yīng)時(shí)間、請求到達(dá)時(shí)間、響應(yīng)回復(fù)時(shí)間等。通過定義每個(gè)監(jiān)控對象的監(jiān)控指標(biāo)，就可以把該對象的關(guān)注點(diǎn)都可以采集起來，進(jìn)行后續(xù)的分析處理。比如一段時(shí)間內(nèi)的響應(yīng)時(shí)間就可以通過圖形的方式展現(xiàn)出來，看下響應(yīng)時(shí)間的分布，和我們期望的響應(yīng)時(shí)間這個(gè)指標(biāo)的目標(biāo)是否匹配，差距有多大。這就給我們了一個(gè)優(yōu)化和調(diào)整的參考。探針管理不同的對象可能需要不同的探針來采集數(shù)據(jù)。統(tǒng)一監(jiān)控平臺需要提供不同探針的統(tǒng)一管理、配置等能力。這是監(jiān)控平臺自我管理自我監(jiān)控能力的體現(xiàn)。我們也提到，探針其實(shí)是一種加層集成方式，帶來便利的同時(shí)也帶來新的問題，比如說不同探針類型要管理起來不得不增加探針管理功能模塊等，這也就帶來了問題的復(fù)雜性。所以，如果能夠最終都以某種標(biāo)準(zhǔn)化或規(guī)范化的方式來獲取監(jiān)控?cái)?shù)據(jù)，則可以簡化整個(gè)架構(gòu)和監(jiān)控處理邏輯。自動(dòng)化腳本管理監(jiān)控該平臺往往需要管理一些自動(dòng)化的腳本，比如一些自動(dòng)化巡檢任務(wù)的調(diào)度管理等。這些能力也和調(diào)度平臺相關(guān)聯(lián)，可以部署于調(diào)度平臺來統(tǒng)一管理。這樣就松耦合了平臺架構(gòu)，減少重復(fù)的建設(shè)。配置設(shè)置眾多的組件和工具往往都有很多的配置參數(shù)需要調(diào)整，這些配置可以在配置中心統(tǒng)一來管理，這就和我們提出來的系統(tǒng)融合思路中“配置中心組件”融合起來，在配置中心進(jìn)行配置的統(tǒng)一管理。日志和審計(jì)統(tǒng)一監(jiān)控平臺有自身的日志及操作審計(jì)需求。這些日志和審計(jì)信息也可以發(fā)送到日志中心統(tǒng)一管理起來。然后由日志中心提供查詢接口集成到監(jiān)控平臺，這樣監(jiān)控平臺的日志、審計(jì)數(shù)據(jù)不需要自己管理，按需從日志中心盡心查詢。這就實(shí)現(xiàn)了系統(tǒng)之間的融合。需要注意的是，系統(tǒng)融合采用的是分布式微服務(wù)架構(gòu)思想，可以基于云原生容器技術(shù)實(shí)現(xiàn)彈性伸縮以支持需求的擴(kuò)展和變化。它不是一個(gè)集中式的架構(gòu)，但它是一個(gè)一體化可適用不同場景架構(gòu)需求的分布式架構(gòu)。四、監(jiān)控功能擴(kuò)展基于采集到的數(shù)據(jù)可以實(shí)時(shí)或延時(shí)做故障檢測、異常處理等。多指標(biāo)復(fù)雜的數(shù)據(jù)處理可以通過AI算法平臺來實(shí)現(xiàn)，也就是智能運(yùn)維部分?？梢院臀覀兇髷?shù)據(jù)平臺、機(jī)器學(xué)習(xí)平臺、數(shù)據(jù)智能中臺等整合。在進(jìn)行監(jiān)控平臺架構(gòu)設(shè)計(jì)時(shí)，認(rèn)識到并理解系統(tǒng)融合的趨勢，將各個(gè)系統(tǒng)和模塊進(jìn)行無縫融合，則會在后期減少大量的重復(fù)建設(shè)工作量，從而提升效率。1.告警通過規(guī)則實(shí)現(xiàn)自動(dòng)告警和通知。如果需要人為介入，則通過自動(dòng)化工單來記錄并自動(dòng)分發(fā)到相應(yīng)的角色，處理完畢由利益關(guān)系人進(jìn)行主觀反饋評價(jià)。工單和評價(jià)反饋可以積累形成量化的工作業(yè)績數(shù)據(jù)，可以考慮作為量化績效考核的參考（這就是系統(tǒng)融合思想，不是單一的看待一個(gè)問題）。2.故障檢測、異常處理到知識庫基于監(jiān)控采集到的數(shù)據(jù)進(jìn)行運(yùn)行狀況分析和預(yù)測、異常處理等。隨著量的積累，可以逐步形成知識庫，反過來支持故障檢測和異常處理，使之相輔相成。3.工單處理系統(tǒng)或應(yīng)用出現(xiàn)異常時(shí)，需要人來介入才能解決，則需要分配工作給某個(gè)人。通常是誰負(fù)責(zé)誰來處理，不