本文作為監(jiān)控告警產(chǎn)品的專題系列的第二篇文章，主要討論的是IAAS層的監(jiān)控（服務(wù)器狀態(tài)與性能、網(wǎng)絡(luò)設(shè)備狀態(tài)與性能、網(wǎng)絡(luò)流量分析等等），從前文所述的監(jiān)控類型來說，IAAS層一般來說屬于基礎(chǔ)監(jiān)控層面

前文回顧：監(jiān)控告警產(chǎn)品專題（1）：企業(yè)級(jí)監(jiān)控產(chǎn)品設(shè)計(jì)基礎(chǔ)

庖丁解牛

IaaS

IaaS、PaaS、SaaS這三個(gè)概念想必大家是耳熟能詳了，其實(shí)就是云計(jì)算的三個(gè)分層，Infrastructure-as-a-Service（IaaS）基礎(chǔ)設(shè)施即服務(wù)，Platform-as-a- Service（PaaS）平臺(tái)即服務(wù)，Software-as-a-Service（SaaS）軟件即服務(wù)。

IaaS層其實(shí)就是一些顯性可見的資源對象，如運(yùn)維小伙伴經(jīng)常接觸的服務(wù)器、網(wǎng)絡(luò)設(shè)備與存儲(chǔ)設(shè)備等等。用一座大廈類比的話IAAS層就好比是負(fù)責(zé)了最基礎(chǔ)的水電通信等能力。上層的服務(wù)都是依賴于IaaS層，假定IaaS層管理不好，那么PaaS與SaaS的高效與可控管理其實(shí)也是非常難了，甚至可以說空談了。IaaSI層的不穩(wěn)定會(huì)直接導(dǎo)致企業(yè)對外的服務(wù)質(zhì)量大打折扣。筆者以前在負(fù)責(zé)手機(jī)QQ業(yè)務(wù)運(yùn)維的時(shí)候，名下有4k多的機(jī)器，如果沒有一套高效與可度量的管理平臺(tái)，光憑人肉去管理4K多的機(jī)器，那基本和噩夢差不多了。

IaaS的監(jiān)控

對于IaaS層的監(jiān)控，本質(zhì)來說就是監(jiān)控組成IaaS層的各個(gè)資源對象，那么資源對象代表什么呢？ 例如物理服務(wù)器、交換機(jī)、一條專線與一個(gè)公網(wǎng)IP等等都是一個(gè)個(gè)資源對象。通常來說對于資源對象的監(jiān)控可以分為以下4個(gè)維度。

• 狀態(tài)的監(jiān)控：通指設(shè)備的的狀態(tài)，如設(shè)備的存活狀態(tài)、網(wǎng)絡(luò)設(shè)備的端口狀態(tài)、電源、風(fēng)扇狀態(tài)等。
• 性能監(jiān)控：通指設(shè)備內(nèi)存大小，端口流量包量、CPU利用率 等等
• 質(zhì)量監(jiān)控：通指設(shè)備的丟包率、錯(cuò)包率、網(wǎng)絡(luò)訪問的延時(shí)等等
• 容量監(jiān)控：通指設(shè)備的負(fù)載使用率、專線帶寬使用率、網(wǎng)絡(luò)設(shè)備的負(fù)載使用率、服務(wù)器的負(fù)載使用率等等。

監(jiān)控產(chǎn)品的分層結(jié)構(gòu)

對于絕大多數(shù)主流商用或者開源監(jiān)控告警產(chǎn)品來說，一般都是采用這種類似的分層方式，當(dāng)然這里是一種高度抽象后的產(chǎn)品分層架構(gòu)。

位于最底層的就是數(shù)據(jù)采集，采集到的原始數(shù)據(jù)是監(jiān)控的最初的輸入。

數(shù)據(jù)采集

通常來說企業(yè)級(jí)的監(jiān)控系統(tǒng)應(yīng)該是支持多種采集方式與多種采集對象的，例如可以用Agent主動(dòng)上報(bào)、也要能支持SNMP、Xflow、IPMI等多種協(xié)議。而針對于IaaS層具體支持的采集對象應(yīng)該不少于 物理服務(wù)器、操作系統(tǒng)指標(biāo)（linux&windows）、網(wǎng)絡(luò)設(shè)備、網(wǎng)絡(luò)內(nèi)會(huì)話信息、物理專線、網(wǎng)絡(luò)出口等等。不同的采集對象采用的采集方式也是不同的，例如 服務(wù)器系統(tǒng)指標(biāo)可以用Agent上報(bào)、網(wǎng)絡(luò)設(shè)備狀態(tài)、流量、包量可以用SNMP采集等，具體采用哪種采集方式要看業(yè)務(wù)場景與所需場景的數(shù)據(jù)量與類別而定。織云同樣也是支持多種采集方式與多種采集對象。

在大數(shù)據(jù)的時(shí)代背景下，數(shù)據(jù)采集這部分建議針對某一個(gè)具體的對象盡量采集的大而全，可能有些數(shù)據(jù)暫時(shí)看采集上來沒有直接用途，但是隨著數(shù)據(jù)量級(jí)與數(shù)據(jù)間關(guān)聯(lián)性的變化，對大量的原始數(shù)據(jù)，清洗、分析、加工后便能催生更多的數(shù)據(jù)消費(fèi)場景。

基礎(chǔ)概念

監(jiān)控告警是對某一個(gè)具化的對象做采集、存儲(chǔ)、分析、展示、告警、處理的過程。

為了便于讀者對于后文與后續(xù)系列文章的理解，這里筆者先集中描述一下設(shè)計(jì)織云監(jiān)控告警平臺(tái)時(shí)應(yīng)用的一些概念。對于監(jiān)控告警織云的理念是先納管對象在監(jiān)控對象，這也是海量運(yùn)維的最佳實(shí)踐。

告警（監(jiān)控）對象

• 定義：CMDB中管理的一個(gè)具體資源對象或者是一個(gè)自定義邏輯CI
• 示例：一臺(tái)物理服務(wù)器、一個(gè)三級(jí)業(yè)務(wù)、一個(gè)TDSQL實(shí)例，這些均是對象
• 備注：對象與對象之間也有是關(guān)聯(lián)、包含、繼承等關(guān)系

告警（監(jiān)控）指標(biāo)

• 定義：一個(gè)或多個(gè)特性id（或特性間的四則運(yùn)算產(chǎn)生的結(jié)果）的集合
• 示例：CPU使用率、內(nèi)存使用率均是特性id; 而 例如 成功率=（成功的請求總數(shù)/總請求數(shù)）*100 這個(gè)就是多個(gè)特性id的四則運(yùn)算。
• 備注：并不是所有監(jiān)控指標(biāo)都可以用來做有效的告警指標(biāo)，這部分是按需所用。

告警（監(jiān)控）類型

• 定義：確定了一部分的告警對象的告警指標(biāo)采取一類的算法計(jì)算
• 示例：單機(jī)性能告警（就包含了多個(gè)針對于服務(wù)器這個(gè)對象的監(jiān)控告警指標(biāo)，如 cpu使用率、內(nèi)存使用率、應(yīng)用程序內(nèi)容使用量等）

告警規(guī)則

• 定義：告警對象+告警指標(biāo)+告警產(chǎn)生條件+告警通知收斂規(guī)則（閾值、發(fā)生次數(shù)、統(tǒng)計(jì)時(shí)長等等），應(yīng)用于告警策略
• 示例：例如對某臺(tái)交換機(jī)創(chuàng)建了，cpu使用率>80時(shí)的告警規(guī)則

告警策略

• 定義：告警對象+告警類型+告警規(guī)則（可多個(gè)） 對應(yīng)一個(gè)告警策略
• 示例：對一個(gè)三級(jí)業(yè)務(wù)下的全量服務(wù)器創(chuàng)建了一條基礎(chǔ)告警策略，下圖中的每一條都是一個(gè)告警規(guī)則，

備注：對于告警策略，織云的理念的是對象精簡化，為什么會(huì)這樣說？在實(shí)際的生產(chǎn)環(huán)境匯中，一個(gè)運(yùn)維同學(xué)負(fù)責(zé)幾十個(gè)業(yè)務(wù)是常態(tài)，如果這幾十個(gè)業(yè)務(wù)對應(yīng)的不同的告警策略有上百個(gè)，在實(shí)際的運(yùn)維過程中其實(shí)是不可量化的管理的。 所以告警策略要同時(shí)包含不同的告警類型與具備可繼承性。

告警

• 定義：告警對象的告警指標(biāo)滿足告警產(chǎn)生條件后產(chǎn)生的對象
• 示例：[騰訊織云] [ping告警] [15:38:10] [Ping 192.192.192.192 不可達(dá)]

限于篇幅這里先介紹以上最基礎(chǔ)的概念，后續(xù)隨著討論的逐步深入，會(huì)在介紹告警分級(jí)、告警收斂、告警恢復(fù)、告警事件、告警訂閱、告警合并等概念，下面主要討論下網(wǎng)絡(luò)設(shè)備監(jiān)控、網(wǎng)絡(luò)流量分析與服務(wù)器監(jiān)控這幾個(gè)業(yè)務(wù)運(yùn)維同學(xué)們強(qiáng)關(guān)注的運(yùn)維對象。

網(wǎng)絡(luò)流量

對于網(wǎng)絡(luò)出口與網(wǎng)絡(luò)專線的有效監(jiān)控與分析，即能有效的協(xié)助業(yè)務(wù)運(yùn)維同學(xué)有效的定位業(yè)務(wù)異常、評(píng)估業(yè)務(wù)服務(wù)質(zhì)量等，也能有效的度量業(yè)務(wù)整體運(yùn)營成本，畢竟現(xiàn)在帶寬的使用成本在整體運(yùn)營成本中也是占比越來越大。相信運(yùn)維同學(xué)多少都會(huì)遇到下面的場景

• 例如這條專線當(dāng)前利用率多少？
• 在已經(jīng)使用的流量中，某個(gè)ip使用了多少流量？
• 這些所產(chǎn)生的流量是基于什么協(xié)議與方向？
• 專線與網(wǎng)絡(luò)出口的丟包率與時(shí)延是怎么樣的？
• 每條專線中主要是哪些務(wù)在用？哪個(gè)是“”地主客戶“”？

等等較高頻的使用場景。對于網(wǎng)絡(luò)流量的監(jiān)控與分析來說主要依靠的FLOW。

那么什么是FLOW呢？

Flow是一種數(shù)據(jù)交換方式，其工作原理是：Flow利用標(biāo)準(zhǔn)的交換模式處理數(shù)據(jù)流的第一個(gè)IP包數(shù)據(jù)，生成Flow 緩存，隨后同樣的數(shù)據(jù)基于緩存信息在同一個(gè)數(shù)據(jù)流中進(jìn)行傳輸，不再匹配相關(guān)的訪問控制等策略，F(xiàn)low緩存同時(shí)包含了隨后數(shù)據(jù)流的統(tǒng)計(jì)信息。

一個(gè)Flow流定義為在一個(gè)源IP地址和目的IP地址間傳輸?shù)膯蜗驍?shù)據(jù)包流，且所有數(shù)據(jù)包具有共同的傳輸層源、目的端口號(hào)。

相對于會(huì)話（“Session”）而言，“Flow”具備更細(xì)致的標(biāo)識(shí)特征，在傳統(tǒng)的TCP/IP五元組的基礎(chǔ)上增加了一些新的域值，至少包括以下幾個(gè)字段： ?| 源IP地址 | 目的IP地址 | 源端口 | 目的端口 | IP層協(xié)議類型 | ToS服務(wù)類型（dscp） | 輸入物理端口（ifindex） |?? 以上七個(gè)字段可以唯一地確定任意一個(gè)數(shù)據(jù)包屬于哪個(gè)特定的Flow，換而言之任何一個(gè)字段出現(xiàn)了差異都意味著一個(gè)新Flow的發(fā)生

對于FLOW的分析展示同樣也是要基于多維度的，ip（目的與源）、port（目的與源）、業(yè)務(wù)、網(wǎng)絡(luò)架構(gòu)、城市、IDC等等眾多的維度，具體所需的維度依賴于自己的業(yè)務(wù)場景。

FLOW是廠商的私有協(xié)議，業(yè)界也有多種的Flow格式。例如CISCO、華為、juniper等等的主流廠商的flow也是均有一定差異性與優(yōu)劣的，所以這部分的后臺(tái)能力是需要有異構(gòu)性的，織云基于騰云復(fù)雜的網(wǎng)絡(luò)運(yùn)維經(jīng)驗(yàn)，目前是支持CISCO、華為、juniper 的不同F(xiàn)LOW。

網(wǎng)絡(luò)設(shè)備

對于網(wǎng)絡(luò)設(shè)備的監(jiān)控，也一般從設(shè)備性能、質(zhì)量、狀態(tài)等維度入手。對于每臺(tái)網(wǎng)絡(luò)設(shè)備來說運(yùn)維同學(xué)一般會(huì)關(guān)注如下場景：

• 網(wǎng)絡(luò)設(shè)備的運(yùn)行狀態(tài)Syslog（設(shè)備運(yùn)行日志）的監(jiān)控與告警
• 設(shè)備堆疊狀態(tài)下的（例如交換機(jī)堆疊）的監(jiān)控與告警
• 網(wǎng)絡(luò)設(shè)備上每個(gè)物理端口的、流量、包量、錯(cuò)包與端口狀態(tài)的監(jiān)控與告警。
• 網(wǎng)絡(luò)設(shè)備上邏輯端口（物理端口組合）的性能與狀態(tài)
• ……………

等等高頻場景。

對于網(wǎng)絡(luò)設(shè)備的syslog告警來說，同樣也會(huì)面臨不同的廠商、設(shè)備類型與設(shè)備型號(hào)日志標(biāo)準(zhǔn)不統(tǒng)一，所以對于網(wǎng)絡(luò)設(shè)備syslog監(jiān)控告警來說，首先是將眾多的網(wǎng)絡(luò)設(shè)備進(jìn)行邏輯分組，以便于在一個(gè)分組內(nèi)的設(shè)備均可以響應(yīng)同一個(gè)告警關(guān)鍵字，并且這個(gè)分組粒度建議較細(xì)，這樣才能保障告警關(guān)鍵字的有效性與獨(dú)立性。在這里根據(jù)多年的運(yùn)維經(jīng)驗(yàn)，建議syslog告警的分組模型由四個(gè)維度組成廠商+類型+型號(hào)+用途，例如 CISCO+交換機(jī)+EX43000-24T+內(nèi)網(wǎng)接入層交換機(jī)，通過這個(gè)公式就描述出一個(gè)設(shè)備的邏輯分組。

服務(wù)器

對于服務(wù)器的監(jiān)控同樣也是從狀態(tài)、性能與容量這幾個(gè)維度入手。雖然SNMP也可以用于服務(wù)器監(jiān)控，但相對于agent主動(dòng)上報(bào)指標(biāo)與數(shù)據(jù)會(huì)少很多。服務(wù)器的狀態(tài)監(jiān)控主要包含 服務(wù)器是否ping的通、agent上報(bào)是否超時(shí)與電源運(yùn)行狀態(tài)等等。對于性能與容量這兩類維度，主要依賴當(dāng)前OS的數(shù)據(jù)捕獲，一般來說對于服務(wù)器監(jiān)控來說在通用場景下主要關(guān)注cpu、內(nèi)存、流量與包量這四個(gè)指標(biāo)即可，但是別的指標(biāo)也建議盡量捕獲。 單個(gè)監(jiān)控對象的數(shù)據(jù)豐富了會(huì)有如下好處。

• 避免對象的監(jiān)控盲點(diǎn)
• 不同的監(jiān)控?cái)?shù)據(jù)點(diǎn)可以部分對應(yīng)出該服務(wù)器所承載的業(yè)務(wù)特性指標(biāo)，例如存儲(chǔ)類業(yè)務(wù)也會(huì)關(guān)注 disk_total_read、svctm_time_max、await_time_max等等系統(tǒng)指標(biāo)
• 生產(chǎn)的數(shù)據(jù)足夠豐富能夠催生出更加豐富的運(yùn)維數(shù)據(jù)消費(fèi)場景。

服務(wù)器監(jiān)控相對是很標(biāo)準(zhǔn)的監(jiān)控模型，針對于物理服務(wù)器與虛擬機(jī)都有共性指標(biāo)。這部分主要做到采集的數(shù)據(jù)豐富與上報(bào)的準(zhǔn)確性（算法準(zhǔn)確）。

后續(xù)文章主題預(yù)告

• 數(shù)據(jù)銀行CMDB的建設(shè)
• 形態(tài)各異的公有云組件通用監(jiān)控模型建設(shè)之路

總結(jié)

IAAS層的監(jiān)控從IAAS層的組成這個(gè)維度來說，可以分為一個(gè)個(gè)獨(dú)立的資源對象來分類監(jiān)控，針對每一類對象可以分別從狀態(tài)、性能、容量、質(zhì)量這幾個(gè)維度描述，將不同的數(shù)據(jù)綜合為開發(fā)與運(yùn)維的統(tǒng)一視角。監(jiān)控告警產(chǎn)品的建設(shè)是任重而道遠(yuǎn)的過程，坑也非常多。要考慮多種因素，技術(shù)后臺(tái)能力只是其中的一部分。例如在DevOps的文化下，需要從更高的層面來統(tǒng)一視角（開發(fā)視角&運(yùn)維視角）避免將監(jiān)控做成”開發(fā)的監(jiān)控”與”運(yùn)維的監(jiān)控”。也需要更多的考慮監(jiān)控產(chǎn)品使用的雙態(tài)（用戶態(tài)&系統(tǒng)態(tài)）與不同的權(quán)限（行業(yè)屬性）如何分類設(shè)計(jì)。

相關(guān)閱讀

監(jiān)控告警產(chǎn)品專題（1）：企業(yè)級(jí)監(jiān)控產(chǎn)品設(shè)計(jì)基礎(chǔ)

本文由 @李光 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載。

題圖來自PEXELS，基于CC0協(xié)議