本節書摘來異步社群《大型網站伺服器容量規劃》一書中的第3章，第3.1節，作者： 鄭鋼 責編： 張濤，更多章節内容可以通路雲栖社群“異步社群”公衆号檢視。
任何一家網際網路公司都會有自己的運維系統，在運維系統之中，重中之重的是監控系統。
監控的方法有很多，最簡單的就是利用一些系統指令，如用df指令來檢視磁盤使用率，然後每天出報表，通過檢視報表運維人員便監控到系統壓力及容量，當逼近系統壓力上限時，發出報警，提醒擴容。
但這種方法不能作為主要的監控手段，僅用來做輔助監控之用，畢竟監控是為了實時了解系統的狀态。這方面都是用監控系統來完成，目前開源的監控系統有很多，如cacti、zabbix等，大多數監控系統都是以圖表方式展示監控名額，如圖3.1所示。
大多數監控系統都是基于snmp（simple network management protocol），即簡單網絡管理協定。snmp是度量性能名額的通用标準，大部分網絡裝置和伺服器裝置都支援該協定，是以，我們的監控系統才能通過該協定擷取到裝置的監控名額。既然是“簡單”網絡管理協定（其實snmp一點都不簡單），這說明僅憑snmp的話還是不能滿足所有監控需求，是以，這些監控系統也支援自定義采集程式。
擴充一下，如果公司業務比較複雜，一般的開源監控系統無法滿足需求的話，公司會開發出适合的監控系統。這通常是為滿足自定義監控，自定義的監控一般包括。
（1）日志監控，從日志檔案中比對出關鍵字，統計相應的個數，比如統計狀态碼的個數，或者處理時間大于一定時間的個數。
（2）端口監控，探測端口是否存活，一般用來判斷server程式是否“健在”，但不是很可靠，有時候server端口還占據着但已經無響應了，此時端口監控依然表示正常。
（3）語義監控，這種就相對可靠多了，它是模拟用戶端向server發送請求，然後server給予響應的方式來監控。
（4）結構體監控，這種監控要與特定程序綁定到一起才行得通，也就是那個被監控的子產品會處理這種結構體。
除此之外，還可以通過模拟使用者單擊的方式來監控，也就是模拟使用者行為，這是最真實的監控，效果最好，但由于此類模拟程式是要捕捉網頁中的dom标簽元素，是以，隻要網頁改變，監控就要重新寫，比較麻煩。
回到正題，在監控系統中我們都會設定報警門檻值，在監控圖中我們都會看到逼近報警門檻值的緊迫程度。如果接近了門檻值，運維人員便開始擴容。
擴容的前提是壓力趨近于子產品的極限，如某子產品每秒最大處理的請求數（qps）是300個，當實際qps接近于250左右時就要考慮擴容了。如何判斷子產品已經接近了最大處理極限呢？一種方法是在程式的日志檔案中增加請求處理時間的字段，這樣針對每個請求的處理時間我們便清楚了，如果任何頁面的處理時間太長的話就要考慮擴容了。這裡所說的處理時間長度沒有固定的大小，還是要和業務結合，如果該頁面主要消耗cpu資源，在不考慮阻塞的情況下，該頁面的處理時間就不應該太大，最大不超過幾百毫秒，如果該頁面功能和存儲或外網相關，就會相對長一些，超過1秒是很正常的。
一般情況下我們也會把子產品各種請求的處理數量或大于某值的請求統計出來，按分鐘或更小的時間粒度在監控系統中繪圖。如圖3.2的mysql的增、删、改、查和慢查詢監控圖所示。
除此之外，大多數子產品都會有請求逾時的設定，例如某子產品設定了請求的最大處理時間是30秒，超過30秒的請求會在日志中寫入報錯資訊，一般會有warning、error或fatal等關鍵字，我們可以在監控日志中比對這些關鍵字來統計機關時間内因逾時而報錯的請求數，當達到某個極限值時就表示離擴容不遠了。
為了将監控可視化，通常情況下也會把這類日志監控添加到監控系統中，同樣，如果監控系統不支援這類監控的話，我們可以自己寫監控程式，然後自己輸出圖像。一般開發語言中都有現成的圖形函數可以調用，或者使用第三方工具，如可以利用rrdtool或者前端圖形庫highcharts、amcharts等。