[[150271]]

這一篇我們來聊聊監(jiān)控系統(tǒng)的架構(gòu)。歡迎大家加入運(yùn)維開發(fā)討論交流群來交流，群號(hào) 365534424，本文僅授權(quán)51reboot、51cto上發(fā)布。

　　架構(gòu)這個(gè)詞太大了，這里我們縮小一下，只來談?wù)労暧^的監(jiān)控系統(tǒng)整體架構(gòu)。在這個(gè)范圍里面，web由于負(fù)責(zé)統(tǒng)一的系統(tǒng)管理和操作功能，縮減為一個(gè)模塊。

　　最簡單的架構(gòu)如下圖：

　　這是監(jiān)控系統(tǒng)***層的架構(gòu)。比照百度地圖的話，我們可以認(rèn)為這個(gè)是全國地圖。最粗粒度的幾個(gè)模塊就是這三個(gè)：web、數(shù)據(jù)采集、數(shù)據(jù)處理。

　　PUSH和PULL

　　我們先來關(guān)注數(shù)據(jù)采集模塊到數(shù)據(jù)處理和報(bào)警模塊的這個(gè)環(huán)節(jié)。

　　推和拉，技術(shù)選型里面常常遇到的一個(gè)選擇題。 在Client/server結(jié)構(gòu)中，信息獲取方式是按“拉”(Pull)的模型進(jìn)行的：服務(wù)器根據(jù)用戶終端發(fā)送的服務(wù)請(qǐng)求進(jìn)行處理并返回用戶所需的結(jié)果。在Push模型中，服務(wù)器把信息“推”給Client。雖然兩者數(shù)據(jù)傳輸?shù)姆较蚨际菑姆?wù)器流向Client，但操作的發(fā)起者是不同的。從“信源”與 “用戶”的關(guān)系來看，信息的流動(dòng)可分為兩種模式，即信息推送與信息拉取模式。

　　兩種模型的對(duì)比見表格：

　　其中PUSH的好處是及時(shí)性好。但缺點(diǎn)是服務(wù)端要有比較復(fù)雜的狀態(tài)管理。同時(shí)在到達(dá)率等方面都會(huì)有一些糾結(jié)的地方。而PULL的好處則是服務(wù)端簡單，狀態(tài)管理簡單，但缺點(diǎn)是時(shí)效性上不可控。體現(xiàn)在監(jiān)控系統(tǒng)上，如果所有要監(jiān)控的監(jiān)控項(xiàng)，都是需要Server端PUSH給Client，假設(shè)Client所在服務(wù)器關(guān)機(jī)了，那PUSH的時(shí)候就是不可達(dá)的。Server端就得想辦法記錄下來，并且再做重試等失敗處理。而如果是Client端主動(dòng)來PULL就好辦了，服務(wù)器開機(jī)啟動(dòng)之后，Client立刻來拉取。到達(dá)率肯定要好，對(duì)Server的管理也簡化了。但缺點(diǎn)就是想生效一個(gè)監(jiān)控項(xiàng)，只能等著Client來 PULL，而無法立即生效。

　　這里還有一個(gè)比較經(jīng)典的例子，也是我面試別人的時(shí)候總喜歡問的一個(gè)問題。當(dāng)然我問面試者的時(shí)候主要是想去看看TA的邏輯思維能力。

　　題目：微博大家都用過。里面你可以關(guān)注一個(gè)人，也可以被人關(guān)注。當(dāng)你發(fā)一條微博時(shí)，關(guān)注你的人都會(huì)收到一條提示。當(dāng)你關(guān)注的人發(fā)一條微博時(shí)，你會(huì)收到一條提示。 請(qǐng)問這個(gè)提示，是PUSH 還是 PULL到你的微博客戶端(瀏覽器或者手機(jī)微博)上的?

　　面試者：肯定會(huì)有人說，PUSH唄。

　　面試官：OK，然后我就會(huì)問了，姚晨在新浪微博上的粉絲數(shù)是5000多萬，她發(fā)一條微博，是不是得PUSH 5000多萬個(gè)消息到各個(gè)賬號(hào)去?

　　面試者：額，那就是定時(shí)PULL

　　面試官：確定嗎?幾千萬個(gè)客戶端都PULL?

　　面試者：額。。。 面試者開始額頭黑線了。

　　面試官：請(qǐng)問該怎么辦?

　　PUSH的話，姚晨的一條微博，在系統(tǒng)里面就要產(chǎn)生5000萬條消息要處理。如果她一天發(fā)個(gè)100條，估計(jì)新浪微博瘋了。這還沒有考慮很多客戶端不登陸，消息就得緩存著。還有很多客戶端一下子通知不到，還得處理失敗。

　　PULL的話，如果大量用戶在使用的生產(chǎn)系統(tǒng)，對(duì)存儲(chǔ)和緩存是一個(gè)很大的挑戰(zhàn)。

　　具體的，大家可以再去google一下，這個(gè)事情其實(shí)有很多方案。

　　經(jīng)驗(yàn)比較豐富的研發(fā)一定會(huì)同意我的一個(gè)說法：兩個(gè)爭(zhēng)論不休的技術(shù)方案，最終能達(dá)成一個(gè)融合了二者的第三個(gè)方案。就好像兩個(gè)特別對(duì)立的談判方，到***談判結(jié)果是一個(gè)融合或者叫妥協(xié)的方案。PUSH和PULL也可以二者融合，將做到取長補(bǔ)短，使二者優(yōu)勢(shì)互補(bǔ)。根據(jù)推、拉結(jié)合順序及結(jié)合方式的差異，又分以下四種不同推拉模式：

　　◆先推后拉——先由服務(wù)端PUSH，再由Client端有針對(duì)性地拉;

　　◆先拉后推——根據(jù)Client端PULL的信息，服務(wù)端進(jìn)一步主動(dòng)PUSH與之相關(guān)的信息;

　　◆推中有拉——在數(shù)據(jù)推送過程中，允許Client隨時(shí)中斷并PULL更有針對(duì)性的信息;

　　◆拉中有推——根據(jù)Client端PULL的過程，Server主動(dòng)推送相關(guān)的***信息

　　#p#

幾個(gè)開源監(jiān)控系統(tǒng)的PUSH、PULL選擇

　　zabbix：帶agent方式。agent主動(dòng)推送數(shù)據(jù)到服務(wù)端。 從client的角度看，是PUSH數(shù)據(jù)到Server。

　　Cacti：SNMP協(xié)議，無Client，或者說Client是SNMP Client。從Client角度看，是PULL。

　　ganglia：從Client角度看，是PUSH。

　　在我過去生產(chǎn)環(huán)境所構(gòu)造的監(jiān)控系統(tǒng)里面，我們采用了PUSH和PULL結(jié)合的方式來達(dá)到及時(shí)性、到達(dá)率的同時(shí)解決。我們站在Client的角度來描述這個(gè)解決方案。對(duì)于監(jiān)控項(xiàng)的生效，Web端變更之后立即使用PUSH的方式來通知Client。但這里一定有達(dá)到率的問題。比如Client所在服務(wù)器死機(jī)了、重啟了、當(dāng)時(shí)網(wǎng)絡(luò)有問題不可達(dá)等等。所以我們?cè)贑lient端，支持定時(shí)PULL。定時(shí)去主動(dòng)聯(lián)系Server端，獲取自己應(yīng)該生效的監(jiān)控內(nèi)容。

　　HASH

　　怎么突然又說到HASH了呢?HASH先來個(gè)概念普及吧!看完概念還是不了解的同學(xué)，自行面壁去，你計(jì)算機(jī)數(shù)據(jù)結(jié)構(gòu)一定沒好好學(xué)。

　　我說HASH是因?yàn)橐獮楹竺娼榻B高可用性架構(gòu)有關(guān)系的。

　　HASH你別直接拿去搜，用百度的結(jié)果就是哈士奇。

　　關(guān)鍵詞可以是哈希。

　　Hash，一般翻譯做“散列”，也有直接音譯為“哈希”的，就是把任意長度的輸入(又叫做預(yù)映射， pre-image)，通過散列算法，變換成固定長度的輸出，該輸出就是散列值。這種轉(zhuǎn)換是一種壓縮映射，也就是，散列值的空間通常遠(yuǎn)小于輸入的空間，不同的輸入可能會(huì)散列成相同的輸出，所以不可能從散列值來唯一的確定輸入值。簡單的說就是一種將任意長度的消息壓縮到某一固定長度的消息摘要的函數(shù)。

　　Hash在算法里面是很基礎(chǔ)但使用非常廣泛的。特別是在大數(shù)據(jù)量的情況下。

　　我這里強(qiáng)調(diào)Hash，是想說它的一個(gè)作用之一就是散列。把輸入散列到幾個(gè)地方去。提到Hash不得不提一個(gè)詞叫做一致性Hash，這個(gè)算法對(duì)于解決緩存***率有很大好處。在內(nèi)存緩存、CDN等存儲(chǔ)系統(tǒng)中經(jīng)常使用。

　　Hash的精髓之一就是按照某種計(jì)算規(guī)則，把輸入散列到不同的輸出通道上去。

　　無狀態(tài)和有狀態(tài)

　　我們拿無狀態(tài)協(xié)議來體驗(yàn)一下無狀態(tài)是個(gè)什么概念。

　　協(xié)議的狀態(tài)是指下一次傳輸可以“記住”這次傳輸信息的能力。典型的如HTTP協(xié)議是不會(huì)為了下一次連接而維護(hù)這次連接所傳輸?shù)男畔?，由于Web服務(wù)器要面對(duì)很多瀏覽器的并發(fā)訪問，為了提高Web服務(wù)器對(duì)并發(fā)訪問的處理能力，在設(shè)計(jì)HTTP協(xié)議時(shí)規(guī)定Web服務(wù)器發(fā)送HTTP應(yīng)答報(bào)文和文檔時(shí)，不保存發(fā)出請(qǐng)求的Web瀏覽器進(jìn)程的任何狀態(tài)信息。這有可能出現(xiàn)一個(gè)瀏覽器在短短幾秒之內(nèi)兩次訪問同一對(duì)象時(shí)，服務(wù)器進(jìn)程不會(huì)因?yàn)橐呀?jīng)給它發(fā)過應(yīng)答報(bào)文而不接受第二期服務(wù)請(qǐng)求。由于Web服務(wù)器不保存發(fā)送請(qǐng)求的Web瀏覽器進(jìn)程的任何信息，因此HTTP協(xié)議屬于無狀態(tài)協(xié)議(Stateless Protocol)。

　　監(jiān)控系統(tǒng)里面的HASH和狀態(tài)

　　監(jiān)控系統(tǒng)對(duì)數(shù)據(jù)的處理，主要是過濾異常數(shù)據(jù)出來并報(bào)警。比如某個(gè)服務(wù)器的CPU利用率超過了95%，需要報(bào)警。但這個(gè)時(shí)候突然數(shù)據(jù)處理模塊所在服務(wù)器宕機(jī)了。那么，這個(gè)異常數(shù)據(jù)很有可能就丟掉了。

　　監(jiān)控系統(tǒng)常見的報(bào)警條件是： CPU利用率超過95%，算一次異常。如果5分鐘內(nèi)有3次異常，報(bào)警給運(yùn)維。

　　這里就有幾個(gè)數(shù)字需要處理，5分鐘，3次。前面提到的宕機(jī)，會(huì)導(dǎo)致一次異常數(shù)據(jù)丟掉了。假設(shè)5分鐘內(nèi)出現(xiàn)了3次，丟掉了一次，那自然不會(huì)報(bào)警出來。這就是一個(gè)有狀態(tài)的場(chǎng)景。

　　有狀態(tài)的情況下，做自動(dòng)切換或者負(fù)載均衡，需要把狀態(tài)也帶過去才行。

　　比較典型的還有session的問題。如果web是多臺(tái)主機(jī)負(fù)載均衡的時(shí)候，session存本地是會(huì)出問題的。因?yàn)橛脩粲锌赡芡ㄟ^負(fù)載均衡的調(diào)度，多次請(qǐng)求落在不同的主機(jī)上。 本來HTTP協(xié)議是無狀態(tài)的，支持負(fù)載均衡的調(diào)度。但因?yàn)閟ession這個(gè)有狀態(tài)的產(chǎn)物，必須要把session放在公共存儲(chǔ)上才行。

　　結(jié)合前面提到的那個(gè)架構(gòu)圖。數(shù)據(jù)進(jìn)入到了數(shù)據(jù)計(jì)算和報(bào)警模塊。我們?nèi)绾伪ＷC這個(gè)數(shù)據(jù)計(jì)算和報(bào)警模塊是個(gè)高可用的架構(gòu)。

　　答案是，把輸入的監(jiān)控?cái)?shù)據(jù)Hash到不同的數(shù)據(jù)計(jì)算和報(bào)警模塊實(shí)例上去，并且***是無狀態(tài)或者弱狀態(tài)的計(jì)算過程。（未完待續(xù)）