[[149634]]

【引自Reboot運維開發的博客】寫在前面

　　我從事運維自動化相關的工作，也已經8年了。當初剛開始做的時候，運維開發(devops)這詞還不火，很少人知道。國內對運維的理解，也就是機房、服務器、苦逼的7*24小時值班。甚至當時還流傳著段子，招運維要人高馬大，扛得動服務器。

　　很幸運的主導了兩個一線互聯網公司的公司級的運維自動化。這倆公司的服務器，都是幾十萬臺級的，IDC都是幾十個。很多事情都是摸索著來。一路走來也形成了一些對運維自動化的理解。***家公司好容易做的七七八八的時候，到第二家實施發現原有的很多理解都被打爛了重新來。但這種經歷反而凝練了一些經驗。我個人性格原因，不喜歡到外面去講。偶爾實在沒法推辭過去的，也誠惶誠恐的準備，到***發現很多干貨還是沒辦法一言以蔽之。***留在外面的都是一些只言片語，不成系統，更不敢說能指導多少。

　　終于下定決心要把我個人的一些理解，通過系列文章來寫一寫。文筆有限，可能寫的不盡人意。也歡迎大家加入運維開發討論交流群來交流，群號：365534424

　　廢話少說，直接上文。

　　庖丁解監控(一)

　　我始終認為監控對于運維來說，猶如眼睛對人來說一樣重要。不管說的多么高大上，運維工作里面很大一部分還是響應型的工作。來自于架構調整、服務變更或者來自于監控。說監控是整個運維或者服務生命周期里面最重要的一環都不為過。從事前發現，預警或者故障報警，到事后提供監控現場供回溯追查，監控系統貫穿了運維整個環節。怎么才能有一副好視力，今天我們就來稍微談談。

　　正因為監控系統如此重要和通用，所以業內最成熟、最多的產品也是監控系統。商用的、開源的監控系統比比皆是。也有一些很優秀的開源系統應用很廣泛。比如Zabbix、cacti、nagios、ganglia等。對于使用開源系統，還是自己開發(相信看這個文章的，應該都不會有購買監控系統的打算)，是使用者自己決定的。業務和團隊規模都不足夠的時候，直接拿來主義，開源的系統能解決基本問題，性價比高。業務如果后期發展的好，規?？焖贁U大，復雜度迅速增加的情況下，開源系統就難以為繼了。具體表現在時效性、擴展性、二次開發、支持的服務規模(或者叫系統容量)、良好的權限控制等各方面。

　　從上面幾點來看，一個監控系統需要具備的是數據采集、擴展性、告警管理、高可用、歷史數據存儲與展示、權限管理等幾個方面。

　　監控本質上就是對被監控對象的狀態進行判定。這個監控對象可以是服務器、交換機，也可以是一個幾千臺服務器的集群，還可以是帶寬、CPU利用率，甚至深入到服務內部，監控服務內部的進程、線程、cache***率等。

　　監控對象多種多樣，既有實體的，也有虛擬的。 對被監控對象的狀態進行判定，這句話里面有三個要素。被監控對象、狀態、判定。所以監控系統要能夠適配足夠多的監控對象類型、收集并能轉換為可衡量的狀態值，才能支持下一步的判定動作。例如，一臺服務器上的nginx服務的連接數。服務器上的nginx服務，就是被監控的對象;連接數就是被監控對象的指標，那么狀態呢?我們可以定義為，超過1萬就是不正常，否則是正常。

　　從這個角度做框，我們來看看監控系統的核心指標都有哪些。首先是能監控的對象范圍要越多越好(當然你可以說小而精的也挺美。但維護多套監控系統也是代價)。也就是數據采集，能采集的渠道、支持的方式、采集的指標越多越好。

　　關于擴展性的定義

　　可伸縮性(可擴展性)是一種對軟件系統計算處理能力的設計指標，高可伸縮性代表一種彈性，在系統擴展成長過程中，軟件能夠保證旺盛的生命力，通過很少的改動甚至只是硬件設備的添置，就能實現整個系統處理能力的線性增長，實現高吞吐量和低延遲高性能。

　　可伸縮性和純粹性能調優有本質區別， 可伸縮性是高性能、低成本和可維護性等諸多因素的綜合考量和平衡，可伸縮性講究平滑線性的性能提升，更側重于系統的水平伸縮，通過廉價的服務器實現分布式計算；而普通性能優化只是單臺機器的性能指標優化。他們共同點都是根據應用系統特點在吞吐量和延遲之間進行一個側重選擇，當然水平伸縮分區后會帶來CAP 定理約束。

　　可擴展與過度設計的矛盾

　　具體討論到監控系統的可擴展性，我們這里特指系統可以隨著被監控對象的規模擴大而無需對架構做大的變更修改。一千臺服務器的時候，是這個架構，一萬臺服務器的時候還是這個架構，***十萬臺的時候只需要增加服務器就可以，架構還是那個架構。聽起來很棒吧!這也是每個系統架構設計者的夢想。但現實照進理想的時候，發現理想很殘酷。首先是對于設計者來說，當他在一家只有幾百臺服務器規模的公司時，很難去想到自己的系統可能有一天會在跑在幾萬臺的服務器規模上。這里面也有一個架構設計的原則，就是要盡量避免過度設計。如果一個幾百臺服務器規模的公司的運維開發，對他的老板說要做一個系統可以支撐幾萬臺服務器，但因此要多花了多少時間去架構和重構，我想老板會認為自己的運維開發一定是瘋了。架構原則之一也是要盡量避免過度設計。

　　但軟件設計依然還是推崇良好的架構、良好的可擴展性。否則架構設計的價值就會打很大的折扣，代碼復用和系統實現成本會隨著規模的擴大而線性增長。良好的架構可以通過迭代得出之后，反過來指導低階的系統設計。但低階的無法預測高階的。這就是架構的用處之一。所以這里稍后我會介紹一下，我對于監控系統架構的一些經驗和心得。

　　一個稱職的設計者，是可以站在幾百臺服務器的規模時，考慮到幾千臺的情況的。但他考慮幾萬臺的話就有點過度了。這里并非說能支撐幾萬臺的系統架構不優秀。只是如果他不知道，那也沒必要過度考慮。如果能提前知道，甄嬛就會說，那顯然是極好的。

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

　　監控的可擴展性

　　具體到監控系統，可擴展性體現在哪些方面呢?我們從頭捋一下。監控系統的輸入是監控到的各項監控數據。這些數據經過一系列的處理，最終存儲下來用于事后分析和離線分析，同時更主要的作用是要實時的報警。整個過程我們可以視為是一個流式計算的過程。說到流式計算其實大家想到的是storm這些。這倒是另外一個我曾經想過的思路，就是把所有處理過程放到strom上去。balabalabala.... 說遠了。但我們仔細去看，strom也好，流式計算平臺也罷，都是分布式的。分布式架構的一個特性就是良好的擴展性。隨著服務器規模的擴大，對于中間的數據處理層的可擴展性要求，就是計算能力要能具備擴展性。簡單來說就是數據多了，通過加服務器或者升級服務器就能搞定。

　　還有幾個邊界的地方需要把擴展性支持好。***個就是入口?；蛘呓凶鰯祿慕邮湛?。外面的數據源源不斷的進入，如果要想做到擴展性良好，***個需要考慮的就是接收環節。數據可以走TCP、UDP、SNMP、HTTP等多種協議進入到監控系統?？紤]到數萬服務器的規模，這個地方比較考驗技術底子。如果走SNMP、HTTP當然可以，但這兩個協議都走在應用層，必然會帶來額外的開銷。拿HTTP舉例子，我們拿Nginx或者apache做server，其實天然帶有可擴展性。數據收到以后，存到一個存儲即可(不管這個存儲是緩存還是***存儲)。這個過程，不帶有狀態，所以天然具有可擴展性。一個Nginx 實例扛不住了，再來一個，再來一個，再來十個。這樣就解決了接口的可擴展問題。

　　另外一個可擴展是存儲環節。這個存儲主要是監控數據的持久化存儲。前面我們說，數據接收、計算環節都可以通過一些方式支持可擴展。那存儲必然會成為一個瓶頸。這個在很多系統里面都是這樣，前端可以通過Web Server實現可擴展，但最終大家都跑到一個數據庫上讀寫。哪怕是讀寫分離的，還是一個主庫。主庫壓力山大。

　　這個地方我推薦用一些分布式存儲來解決這個問題。但不是很推薦mango這種比較奇葩的。因為寫入的能力不是很好。雖然它后來又有一些改進方案來緩解這個問題，但注意，只是緩解。

　　綜上，對于可擴展性，我們的思路是：分布式、無狀態。（未完待續）