[[149634]]

【引自Reboot運(yùn)維開(kāi)發(fā)的博客】寫在前面

　　我從事運(yùn)維自動(dòng)化相關(guān)的工作，也已經(jīng)8年了。當(dāng)初剛開(kāi)始做的時(shí)候，運(yùn)維開(kāi)發(fā)(devops)這詞還不火，很少人知道。國(guó)內(nèi)對(duì)運(yùn)維的理解，也就是機(jī)房、服務(wù)器、苦逼的7*24小時(shí)值班。甚至當(dāng)時(shí)還流傳著段子，招運(yùn)維要人高馬大，扛得動(dòng)服務(wù)器。

　　很幸運(yùn)的主導(dǎo)了兩個(gè)一線互聯(lián)網(wǎng)公司的公司級(jí)的運(yùn)維自動(dòng)化。這倆公司的服務(wù)器，都是幾十萬(wàn)臺(tái)級(jí)的，IDC都是幾十個(gè)。很多事情都是摸索著來(lái)。一路走來(lái)也形成了一些對(duì)運(yùn)維自動(dòng)化的理解。***家公司好容易做的七七八八的時(shí)候，到第二家實(shí)施發(fā)現(xiàn)原有的很多理解都被打爛了重新來(lái)。但這種經(jīng)歷反而凝練了一些經(jīng)驗(yàn)。我個(gè)人性格原因，不喜歡到外面去講。偶爾實(shí)在沒(méi)法推辭過(guò)去的，也誠(chéng)惶誠(chéng)恐的準(zhǔn)備，到***發(fā)現(xiàn)很多干貨還是沒(méi)辦法一言以蔽之。***留在外面的都是一些只言片語(yǔ)，不成系統(tǒng)，更不敢說(shuō)能指導(dǎo)多少。

　　終于下定決心要把我個(gè)人的一些理解，通過(guò)系列文章來(lái)寫一寫。文筆有限，可能寫的不盡人意。也歡迎大家加入運(yùn)維開(kāi)發(fā)討論交流群來(lái)交流，群號(hào)：365534424

　　廢話少說(shuō)，直接上文。

　　庖丁解監(jiān)控(一)

　　我始終認(rèn)為監(jiān)控對(duì)于運(yùn)維來(lái)說(shuō)，猶如眼睛對(duì)人來(lái)說(shuō)一樣重要。不管說(shuō)的多么高大上，運(yùn)維工作里面很大一部分還是響應(yīng)型的工作。來(lái)自于架構(gòu)調(diào)整、服務(wù)變更或者來(lái)自于監(jiān)控。說(shuō)監(jiān)控是整個(gè)運(yùn)維或者服務(wù)生命周期里面最重要的一環(huán)都不為過(guò)。從事前發(fā)現(xiàn)，預(yù)警或者故障報(bào)警，到事后提供監(jiān)控現(xiàn)場(chǎng)供回溯追查，監(jiān)控系統(tǒng)貫穿了運(yùn)維整個(gè)環(huán)節(jié)。怎么才能有一副好視力，今天我們就來(lái)稍微談?wù)劇?/p>

　　正因?yàn)楸O(jiān)控系統(tǒng)如此重要和通用，所以業(yè)內(nèi)最成熟、最多的產(chǎn)品也是監(jiān)控系統(tǒng)。商用的、開(kāi)源的監(jiān)控系統(tǒng)比比皆是。也有一些很優(yōu)秀的開(kāi)源系統(tǒng)應(yīng)用很廣泛。比如Zabbix、cacti、nagios、ganglia等。對(duì)于使用開(kāi)源系統(tǒng)，還是自己開(kāi)發(fā)(相信看這個(gè)文章的，應(yīng)該都不會(huì)有購(gòu)買監(jiān)控系統(tǒng)的打算)，是使用者自己決定的。業(yè)務(wù)和團(tuán)隊(duì)規(guī)模都不足夠的時(shí)候，直接拿來(lái)主義，開(kāi)源的系統(tǒng)能解決基本問(wèn)題，性價(jià)比高。業(yè)務(wù)如果后期發(fā)展的好，規(guī)模快速擴(kuò)大，復(fù)雜度迅速增加的情況下，開(kāi)源系統(tǒng)就難以為繼了。具體表現(xiàn)在時(shí)效性、擴(kuò)展性、二次開(kāi)發(fā)、支持的服務(wù)規(guī)模(或者叫系統(tǒng)容量)、良好的權(quán)限控制等各方面。

　　從上面幾點(diǎn)來(lái)看，一個(gè)監(jiān)控系統(tǒng)需要具備的是數(shù)據(jù)采集、擴(kuò)展性、告警管理、高可用、歷史數(shù)據(jù)存儲(chǔ)與展示、權(quán)限管理等幾個(gè)方面。

　　監(jiān)控本質(zhì)上就是對(duì)被監(jiān)控對(duì)象的狀態(tài)進(jìn)行判定。這個(gè)監(jiān)控對(duì)象可以是服務(wù)器、交換機(jī)，也可以是一個(gè)幾千臺(tái)服務(wù)器的集群，還可以是帶寬、CPU利用率，甚至深入到服務(wù)內(nèi)部，監(jiān)控服務(wù)內(nèi)部的進(jìn)程、線程、cache***率等。

　　監(jiān)控對(duì)象多種多樣，既有實(shí)體的，也有虛擬的。 對(duì)被監(jiān)控對(duì)象的狀態(tài)進(jìn)行判定，這句話里面有三個(gè)要素。被監(jiān)控對(duì)象、狀態(tài)、判定。所以監(jiān)控系統(tǒng)要能夠適配足夠多的監(jiān)控對(duì)象類型、收集并能轉(zhuǎn)換為可衡量的狀態(tài)值，才能支持下一步的判定動(dòng)作。例如，一臺(tái)服務(wù)器上的nginx服務(wù)的連接數(shù)。服務(wù)器上的nginx服務(wù)，就是被監(jiān)控的對(duì)象;連接數(shù)就是被監(jiān)控對(duì)象的指標(biāo)，那么狀態(tài)呢?我們可以定義為，超過(guò)1萬(wàn)就是不正常，否則是正常。

　　從這個(gè)角度做框，我們來(lái)看看監(jiān)控系統(tǒng)的核心指標(biāo)都有哪些。首先是能監(jiān)控的對(duì)象范圍要越多越好(當(dāng)然你可以說(shuō)小而精的也挺美。但維護(hù)多套監(jiān)控系統(tǒng)也是代價(jià))。也就是數(shù)據(jù)采集，能采集的渠道、支持的方式、采集的指標(biāo)越多越好。

　　關(guān)于擴(kuò)展性的定義

　　可伸縮性(可擴(kuò)展性)是一種對(duì)軟件系統(tǒng)計(jì)算處理能力的設(shè)計(jì)指標(biāo)，高可伸縮性代表一種彈性，在系統(tǒng)擴(kuò)展成長(zhǎng)過(guò)程中，軟件能夠保證旺盛的生命力，通過(guò)很少的改動(dòng)甚至只是硬件設(shè)備的添置，就能實(shí)現(xiàn)整個(gè)系統(tǒng)處理能力的線性增長(zhǎng)，實(shí)現(xiàn)高吞吐量和低延遲高性能。

　　可伸縮性和純粹性能調(diào)優(yōu)有本質(zhì)區(qū)別， 可伸縮性是高性能、低成本和可維護(hù)性等諸多因素的綜合考量和平衡，可伸縮性講究平滑線性的性能提升，更側(cè)重于系統(tǒng)的水平伸縮，通過(guò)廉價(jià)的服務(wù)器實(shí)現(xiàn)分布式計(jì)算；而普通性能優(yōu)化只是單臺(tái)機(jī)器的性能指標(biāo)優(yōu)化。他們共同點(diǎn)都是根據(jù)應(yīng)用系統(tǒng)特點(diǎn)在吞吐量和延遲之間進(jìn)行一個(gè)側(cè)重選擇，當(dāng)然水平伸縮分區(qū)后會(huì)帶來(lái)CAP 定理約束。

　　可擴(kuò)展與過(guò)度設(shè)計(jì)的矛盾

　　具體討論到監(jiān)控系統(tǒng)的可擴(kuò)展性，我們這里特指系統(tǒng)可以隨著被監(jiān)控對(duì)象的規(guī)模擴(kuò)大而無(wú)需對(duì)架構(gòu)做大的變更修改。一千臺(tái)服務(wù)器的時(shí)候，是這個(gè)架構(gòu)，一萬(wàn)臺(tái)服務(wù)器的時(shí)候還是這個(gè)架構(gòu)，***十萬(wàn)臺(tái)的時(shí)候只需要增加服務(wù)器就可以，架構(gòu)還是那個(gè)架構(gòu)。聽(tīng)起來(lái)很棒吧!這也是每個(gè)系統(tǒng)架構(gòu)設(shè)計(jì)者的夢(mèng)想。但現(xiàn)實(shí)照進(jìn)理想的時(shí)候，發(fā)現(xiàn)理想很殘酷。首先是對(duì)于設(shè)計(jì)者來(lái)說(shuō)，當(dāng)他在一家只有幾百臺(tái)服務(wù)器規(guī)模的公司時(shí)，很難去想到自己的系統(tǒng)可能有一天會(huì)在跑在幾萬(wàn)臺(tái)的服務(wù)器規(guī)模上。這里面也有一個(gè)架構(gòu)設(shè)計(jì)的原則，就是要盡量避免過(guò)度設(shè)計(jì)。如果一個(gè)幾百臺(tái)服務(wù)器規(guī)模的公司的運(yùn)維開(kāi)發(fā)，對(duì)他的老板說(shuō)要做一個(gè)系統(tǒng)可以支撐幾萬(wàn)臺(tái)服務(wù)器，但因此要多花了多少時(shí)間去架構(gòu)和重構(gòu)，我想老板會(huì)認(rèn)為自己的運(yùn)維開(kāi)發(fā)一定是瘋了。架構(gòu)原則之一也是要盡量避免過(guò)度設(shè)計(jì)。

　　但軟件設(shè)計(jì)依然還是推崇良好的架構(gòu)、良好的可擴(kuò)展性。否則架構(gòu)設(shè)計(jì)的價(jià)值就會(huì)打很大的折扣，代碼復(fù)用和系統(tǒng)實(shí)現(xiàn)成本會(huì)隨著規(guī)模的擴(kuò)大而線性增長(zhǎng)。良好的架構(gòu)可以通過(guò)迭代得出之后，反過(guò)來(lái)指導(dǎo)低階的系統(tǒng)設(shè)計(jì)。但低階的無(wú)法預(yù)測(cè)高階的。這就是架構(gòu)的用處之一。所以這里稍后我會(huì)介紹一下，我對(duì)于監(jiān)控系統(tǒng)架構(gòu)的一些經(jīng)驗(yàn)和心得。

　　一個(gè)稱職的設(shè)計(jì)者，是可以站在幾百臺(tái)服務(wù)器的規(guī)模時(shí)，考慮到幾千臺(tái)的情況的。但他考慮幾萬(wàn)臺(tái)的話就有點(diǎn)過(guò)度了。這里并非說(shuō)能支撐幾萬(wàn)臺(tái)的系統(tǒng)架構(gòu)不優(yōu)秀。只是如果他不知道，那也沒(méi)必要過(guò)度考慮。如果能提前知道，甄嬛就會(huì)說(shuō)，那顯然是極好的。

　　但很顯然需要考慮的內(nèi)容會(huì)越來(lái)越多。幾十臺(tái)的時(shí)候，你可能只需要考慮一個(gè)機(jī)房了，幾百臺(tái)的時(shí)候會(huì)有2、3個(gè)機(jī)房，當(dāng)幾千臺(tái)的時(shí)候可能依然在10個(gè)IDC以內(nèi)，但當(dāng)幾萬(wàn)臺(tái)的時(shí)候很可能已經(jīng)超過(guò)15個(gè)IDC了。而且，地理位置的分布會(huì)更廣泛，由此而帶來(lái)的運(yùn)營(yíng)商的覆蓋、網(wǎng)絡(luò)的復(fù)雜度、業(yè)務(wù)的復(fù)雜度也會(huì)完全不同。非逼著一個(gè)運(yùn)維開(kāi)發(fā)去完全臆想著來(lái)做是不現(xiàn)實(shí)的。他沒(méi)有經(jīng)歷過(guò)實(shí)際的這種需求場(chǎng)景，是沒(méi)有辦法考慮到這樣那樣的各種問(wèn)題的。所以我完全理解一些大公司對(duì)于開(kāi)源項(xiàng)目的態(tài)度。好一點(diǎn)的可能拿來(lái)改改用，進(jìn)一步可能單獨(dú)拉一個(gè)分支開(kāi)始改，更甚的就改的完全和主干不一樣了 ，其實(shí)還有就是自己造輪子的。但有時(shí)候就是這樣，自己不造輪子，開(kāi)源的輪子用著的確不好使。

　　監(jiān)控的可擴(kuò)展性

　　具體到監(jiān)控系統(tǒng)，可擴(kuò)展性體現(xiàn)在哪些方面呢?我們從頭捋一下。監(jiān)控系統(tǒng)的輸入是監(jiān)控到的各項(xiàng)監(jiān)控?cái)?shù)據(jù)。這些數(shù)據(jù)經(jīng)過(guò)一系列的處理，最終存儲(chǔ)下來(lái)用于事后分析和離線分析，同時(shí)更主要的作用是要實(shí)時(shí)的報(bào)警。整個(gè)過(guò)程我們可以視為是一個(gè)流式計(jì)算的過(guò)程。說(shuō)到流式計(jì)算其實(shí)大家想到的是storm這些。這倒是另外一個(gè)我曾經(jīng)想過(guò)的思路，就是把所有處理過(guò)程放到strom上去。balabalabala.... 說(shuō)遠(yuǎn)了。但我們仔細(xì)去看，strom也好，流式計(jì)算平臺(tái)也罷，都是分布式的。分布式架構(gòu)的一個(gè)特性就是良好的擴(kuò)展性。隨著服務(wù)器規(guī)模的擴(kuò)大，對(duì)于中間的數(shù)據(jù)處理層的可擴(kuò)展性要求，就是計(jì)算能力要能具備擴(kuò)展性。簡(jiǎn)單來(lái)說(shuō)就是數(shù)據(jù)多了，通過(guò)加服務(wù)器或者升級(jí)服務(wù)器就能搞定。

　　還有幾個(gè)邊界的地方需要把擴(kuò)展性支持好。***個(gè)就是入口。或者叫做數(shù)據(jù)的接收口。外面的數(shù)據(jù)源源不斷的進(jìn)入，如果要想做到擴(kuò)展性良好，***個(gè)需要考慮的就是接收環(huán)節(jié)。數(shù)據(jù)可以走TCP、UDP、SNMP、HTTP等多種協(xié)議進(jìn)入到監(jiān)控系統(tǒng)。考慮到數(shù)萬(wàn)服務(wù)器的規(guī)模，這個(gè)地方比較考驗(yàn)技術(shù)底子。如果走SNMP、HTTP當(dāng)然可以，但這兩個(gè)協(xié)議都走在應(yīng)用層，必然會(huì)帶來(lái)額外的開(kāi)銷。拿HTTP舉例子，我們拿Nginx或者apache做server，其實(shí)天然帶有可擴(kuò)展性。數(shù)據(jù)收到以后，存到一個(gè)存儲(chǔ)即可(不管這個(gè)存儲(chǔ)是緩存還是***存儲(chǔ))。這個(gè)過(guò)程，不帶有狀態(tài)，所以天然具有可擴(kuò)展性。一個(gè)Nginx 實(shí)例扛不住了，再來(lái)一個(gè)，再來(lái)一個(gè)，再來(lái)十個(gè)。這樣就解決了接口的可擴(kuò)展問(wèn)題。

　　另外一個(gè)可擴(kuò)展是存儲(chǔ)環(huán)節(jié)。這個(gè)存儲(chǔ)主要是監(jiān)控?cái)?shù)據(jù)的持久化存儲(chǔ)。前面我們說(shuō)，數(shù)據(jù)接收、計(jì)算環(huán)節(jié)都可以通過(guò)一些方式支持可擴(kuò)展。那存儲(chǔ)必然會(huì)成為一個(gè)瓶頸。這個(gè)在很多系統(tǒng)里面都是這樣，前端可以通過(guò)Web Server實(shí)現(xiàn)可擴(kuò)展，但最終大家都跑到一個(gè)數(shù)據(jù)庫(kù)上讀寫。哪怕是讀寫分離的，還是一個(gè)主庫(kù)。主庫(kù)壓力山大。

　　這個(gè)地方我推薦用一些分布式存儲(chǔ)來(lái)解決這個(gè)問(wèn)題。但不是很推薦mango這種比較奇葩的。因?yàn)閷懭氲哪芰Σ皇呛芎谩ｋm然它后來(lái)又有一些改進(jìn)方案來(lái)緩解這個(gè)問(wèn)題，但注意，只是緩解。

　　綜上，對(duì)于可擴(kuò)展性，我們的思路是：分布式、無(wú)狀態(tài)。（未完待續(xù)）