作者:

李光:現任職於騰訊社交網路運營部/織雲產品團隊，負責織雲監控告警平臺規劃與運維新產品開發工作，具有多年業務運維、運營規劃經驗。

導語：本文作為監控告警產品的專題系列的第二篇文章，主要討論的是IAAS層的監控（伺服器狀態與效能、網路裝置狀態與效能、網路流量分析等等）

概述

本文作為監控告警產品的專題系列的第二篇文章，主要討論的是IAAS層的監控(伺服器狀態與效能、網路裝置狀態與效能、網路流量分析等等)，從前文所述的監控型別來說，IAAS層一般來說屬於基礎監控層面。

IaaS

IaaS、PaaS、SaaS這三個概念想必大家是耳熟能詳了，其實就是雲端計算的三個分層，Infrastructure-as-a-Service(IaaS)基礎設施即服務，Platform-as-a- Service(PaaS)平臺即服務，Software-as-a-Service(SaaS)軟體即服務。

IaaS層其實就是一些顯性可見的資源物件，如運維小夥伴經常接觸的伺服器、網路裝置與儲存裝置等等。用一座大廈類比的話IAAS層就好比是負責了最基礎的水電通訊等能力。上層的服務都是依賴於IaaS層，假定IaaS層管理不好，那麼PaaS與SaaS的高效與可控管理其實也是非常難，甚至可以說空談了。

IaaS層的不穩定會直接導致企業對外的服務質量大打折扣。筆者以前在負責手機QQ業務運維的時候，名下有4K多的機器，如果沒有一套高效與可度量的管理平臺，光憑人肉去管理4K多的機器，那基本和噩夢差不多了。

IaaS的監控

對於IaaS層的監控，本質來說就是監控組成IaaS層的各個資源物件，那麼資源物件代表什麼呢？ 例如物理伺服器、交換機、一條專線與一個公網IP等等都是一個個資源物件。通常來說對於資源物件的監控可以分為以下4個維度。

• 狀態的監控：通指裝置的的狀態，如裝置的存活狀態、網路裝置的埠狀態、電源、風扇狀態等。
• 效能監控：通指裝置記憶體大小，埠流量包量、CPU利用率 等等
• 質量監控：通指裝置的丟包率、錯包率、網路訪問的延時等等
• 容量監控：通指裝置的負載使用率、專線頻寬使用率、網路裝置的負載使用率、伺服器的負載使用率等等。

監控產品分層結構

對於絕大多數主流商用或者開源監控告警產品來說，一般都是採用這種類似的分層方式，當然這裡是一種高度抽象後的產品分層架構。

位於最底層的就是資料採集，採集到的原始資料是監控最初的輸入。

資料採集

通常來說企業級的監控系統應該是支援多種採集方式與多種採集物件的，例如可以用Agent主動上報、也要能支援SNMP、Xflow、IPMI等多種協議。

而針對於IaaS層具體支援的採集物件應該不少於物理伺服器、作業系統指標(linux&windows)、網路裝置、網路內會話資訊、物理專線、網路出口等等。

不同的採集物件採用的採集方式也是不同的，例如：伺服器系統指標可以用Agent上報、網路裝置狀態、流量、包量可以用SNMP採集等，具體採用哪種採集方式要根據業務場景與所需場景的資料量與類別而定。織雲同樣也支援多種採集方式與多種採集物件。

在大資料的時代背景下，資料採集這部分建議針對某一個具體的物件儘量採集的大而全，可能有些資料採集上來暫時沒有直接用途，但是隨著資料量級與資料間關聯性的變化，對大量的原始資料，清洗、分析、加工後便能催生更多的資料消費場景。

基礎概念

監控告警是對某一個具化的物件做採集、儲存、分析、展示、告警、處理的過程。

為了便於讀者對於後文與後續系列文章的理解，這裡筆者先集中描述一下設計織雲監控告警平臺時應用的一些概念。對於監控告警，織雲的理念是先納管物件再監控物件，這也是海量運維的最佳實踐。

告警(監控)物件

• 定義：CMDB中管理的一個具體資源物件或者是一個自定義邏輯CI
• 示例：一臺物理伺服器、一個三級業務、一個TDSQL例項，這些均是物件
• 備註：物件與物件之間也有是關聯、包含、繼承等關係

告警(監控)指標

• 定義：一個或多個特性ID(或特性間的四則運算產生的結果的集合。
• 示例：CPU使用率、記憶體使用率均是特性ID; 而例如：成功率=(成功的請求總數/總請求數)*100 這個就是多個特性ID的四則運算。
• 備註：並不是所有監控指標都可以用來做有效的告警指標，這部分是按需所用。

告警(監控)型別

• 定義：確定了一部分的告警物件的告警指標採取一類的演算法計算。
• 示例：單機效能告警(就包含了多個針對於伺服器這個物件的監控告警指標，如 CPU使用率、記憶體使用率、應用程式內容使用量等)。

告警規則

• 定義：告警物件+告警指標+告警產生條件+告警通知收斂規則(閾值、發生次數、統計時長等等)，應用於告警策略。
• 示例：例如對某臺交換機建立了CPU使用率>80時的告警規則。

告警策略

• 定義：告警物件+告警型別+告警規則(可多個) 對應一個告警策略。
• 示例：對一個三級業務下的全量伺服器建立了一條基礎告警策略，下圖中的每一條都是一個告警規則。
• 備註：對於告警策略，織雲的理念的是物件精簡化。為什麼會這樣說？在實際的生產環境匯中，一個運維同學負責幾十個業務是常態，如果這幾十個業務對應的不同的告警策略有上百個，在實際的運維過程中其實是不可量化管理的。 所以告警策略要同時包含不同的告警型別與具備可繼承性。

告警

• 定義：告警物件的告警指標滿足告警產生條件後產生的物件。
• 示例：[騰訊織雲] [ping告警] [15:38:10] [Ping 192.192.192.192 不可達]。

限於篇幅這裡先介紹以上最基礎的概念，後續隨著討論的逐步深入，會在介紹告警分級、告警收斂、告警恢復、告警事件、告警訂閱、告警合併等概念，下面主要討論下網路裝置監控、網路流量分析與伺服器監控這幾個業務運維同學們強關注的運維物件。

網路流量

對於網路出口與網路專線的有效監控與分析，既能協助業務運維同學有效地定位業務異常、評估業務服務質量等，也能有效地度量業務整體運營成本，畢竟現在頻寬的使用成本在整體運營成本中也是佔比越來越大。相信運維同學多少都會遇到下面等較高頻的使用場景：

• 這條專線當前利用率多少？
• 在已經使用的流量中，某個IP使用了多少流量？
• 這些所產生的流量是基於什麼協議與方向？
• 專線與網路出口的丟包率與時延是怎麼樣的？
• 每條專線中主要是哪些務在用？哪個是“地主客戶”？

對於網路流量的監控來說，其實核心是一個分析平臺，通過把採集到的各種流量包抓取過來，然後再把相應的流量送入分析叢集。織雲採用的也是基於Flow的監控。

什麼是Flow呢？

Flow是一種資料交換方式，其工作原理是：Flow利用標準的交換模式處理資料流的第一個IP包資料，生成Flow快取，隨後同樣的資料基於快取資訊在同一個資料流中進行傳輸，不再匹配相關的訪問控制等策略，Flow快取同時包含了隨後資料流的統計資訊。

一個Flow流定義為在一個源IP地址和目的IP地址間傳輸的單向資料包流，且所有資料包具有共同的傳輸層源、目的埠號。

相對於會話(“Session”)而言，“Flow”具備更細緻的標識特徵，在傳統的TCP/IP五元組的基礎上增加了一些新的域值，至少包括以下幾個欄位：

| 源IP地址 | 目的IP地址 | 源埠 | 目的埠 | IP層協議型別 | ToS服務型別（dscp） | 輸入物理埠（ifindex） |  

以上七個欄位可以唯一地確定任意一個數據包屬於哪個特定的Flow。

換而言之，任何一個欄位出現了差異都意味著一個新Flow的發生。對於Flow的分析展示同樣也是要基於多維度的：

IP(目的與源)、port(目的與源)、業務、網路架構、城市、IDC等。

具體所需的維度依賴於自己的業務場景。

Flow是廠商的私有協議，業界也有多種的Flow格式。例如CISCO、華為、juniper等等的主流廠商的Flow也是均有一定差異性與優劣的，常用的有NetFlow與SFlow 。所以這部分的後臺能力是需要有異構性的，織雲基於騰訊複雜的網路運維經驗，目前是支援CISCO、華為、juniper 的不同Flow。

網路裝置

對於網路裝置的監控，也一般從裝置效能、質量、狀態等維度入手。對於每臺網絡裝置來說運維同學一般會關注如下等高頻場景：

• 網路裝置的執行狀態syslog(裝置執行日誌)的監控與告警

• 裝置堆疊狀態下的(例如交換機堆疊)的監控與告警

• 網路裝置上每個物理埠的、流量、包量、錯包與埠狀態的監控與告警。

• 網路裝置上邏輯埠(物理埠組合)的效能與狀態

• ……………

對於網路裝置的syslog告警來說，同樣也會面臨諸如：不同的廠商、裝置型別與裝置型號日誌標準不統一等問題。

所以對於網路裝置syslog監控告警來說，首先是將眾多的網路裝置進行邏輯分組，以便於在一個分組內的裝置均可以響應同一個告警關鍵字，並且這個分組粒度建議較細，這樣才能保障告警關鍵字的有效性與獨立性。

在這裡根據多年的運維經驗，建議syslog告警的分組模型由四個維度組成:

廠商+型別+型號+用途

例如: CISCO+交換機+EX43000-24T+內網接入層交換機，通過這個公式就描述出一個裝置的邏輯分組。

伺服器

對於伺服器的監控同樣也是從狀態、效能與容量這幾個維度入手。雖然SNMP也可以用於伺服器監控，但相對於agent主動上報指標與資料會少很多。伺服器的狀態監控主要包含伺服器是否ping的通、agent上報是否超時與電源執行狀態等等。

對於效能與容量這兩類維度，主要依賴當前OS的資料捕獲，一般來說對於伺服器監控來說在通用場景下主要關注CPU、記憶體、流量與包量這四個指標即可，但是別的指標也建議儘量捕獲。 單個監控物件的資料豐富了會有如下好處:

• 避免物件的監控盲點
• 不同的監控資料點可以部分對應出該伺服器所承載的業務特性指標，例如儲存類業務也會關注 disk_total_read、svctm_time_max、await_time_max等等系統指標
• 生產的資料足夠豐富能夠催生出更加豐富的運維資料消費場景。

伺服器監控相對是很標準的監控模型，針對於物理伺服器與虛擬機器都有共性指標。這部分主要做到採集的資料豐富與上報的準確性(演算法準確)。

後續文章主題預告:

1. 資料銀行 CMDB的建設

2. 形態各異的公有云元件通用監控模型建設之路

總結

IAAS層的監控從IAAS層的組成這個維度來說，可以分為一個個獨立的資源物件來分類監控，針對每一類物件可以分別從狀態、效能、容量、質量這幾個維度描述，將不同的資料綜合為開發與運維的統一視角。監控告警產品的建設是任重而道遠的過程，坑也非常多。要考慮多種因素，技術後臺能力只是其中的一部分。

例如在DevOps的文化下，需要從更高的層面來統一視角(開發視角&運維視角)避免將監控做成”開發的監控”與 “運維的監控”。也需要更多的考慮監控產品使用的雙態(使用者態&系統態)與不同的許可權(行業屬性)如何分類設計。