http://dockone.io/article/1643
監控的價值與體系
在運維體系中， 監控是非常重要的組成部分。通過監控可以實時掌握系統運行的狀態，對故障的提前預警，歷史狀態的回放等，還可以通過監控數據為系統的容量規划提供輔助決策，為系統性能優化提供真實的用戶行為和體驗。
這幾年互聯網業務的迅速發展，用戶對系統的要求也越來越高，而做好監控成能為系統保駕護航，能有效提高系統的可靠性，可用性及用戶體驗。監控的價值體現主要體現在以下幾點：
節約成本
在生產環境中故障是避免不了的，如果能夠通過精確的監控提前發現異常提前進行預警，就可以在故障發生前就解決故障或實施應急預案，從而減少因故障帶來的經濟損失。還可以通過監控了解系統資源的使用情況，對空閑的資源可以進行重新規划，也能幫助節約成本。
提高效率
運維過去都是救火隊員，而且因為缺少系統運行數據，在做故障處理時效率很慢，而通過監控可以回放系統的歷史狀態，保存故障現場。當需要對系統進行分析時直接拉取監控數據生成趨勢圖，可以很清晰的展示系統存在什么樣的問題。比如訪問連接突增，內存回收異常，數據庫連接異常等問題，可以幫助快速定位到故障原因，解決故障。
提高質量
可以通過對系統運行的歷史監控數據進行分析，及時找到系統的性能瓶頸進行優化，可以提高系統的運行質量。不僅可以從基礎設施的性能角度，還可以從應用性能的角度進行端到端的性能優化，有效提高用戶的體驗。
但是要做好監控並不容易，一個好的監控系統需要做到以下幾點：
完整的監控體系
一個企業的監控體系包括以下幾個組成部分：
監控數據采集的時效與精確
監控數據采集存儲與歸檔
監控數據的圖形化展示
監控數據的自動化分析與聯動處理
監控的告警及自動化處理
監控工具自身的安全控制
監控告警的響應及跟蹤
從上圖我們可以看到，一個完整的監控體系是從監控數據的采集開始，再將數據進行存儲，處理從而產生價值。比如智能生成分析報告，可圖形化展示，通過監控聯動完成高可用，伸縮，限流等事件處理，還有就是監控告警了。對於運維人員而言最高興的莫過於由於一條告警短信后馬上又再收到一條自動恢復的短信了，所以在監控體系里，故障告警的自動化處理也是非常重要的。
目前監控數據的采集方式有以下幾種：
主動輸出
提前在應用中埋點，應用主動上報。比如一些應用系統的業務狀態，可以通過在日志中主動輸出狀態用於采集。
遠程接入
通過對應用進程接口調用獲取應用的狀態。比如使用JMX的方式連接到java進程中，對進程的狀態進行采集。
嵌入式
通過在進程中運行agent的方式獲取應用的狀態。如目前的APM產品都是通過將監控工具嵌入到應用內部進行數據采集。
旁路式
通過外部獲取的方式采集數據。比如對網站url的探測，模擬業務的報文 ，對服務器的ping，流量的監控。可以通過在交換機上將流量進行端口復制，將源始流量復制到另一個端口后再進行處理，這樣這業務系統是完全沒有侵入。
入侵式
不同於嵌入式，入侵式的agent是獨立運行的進程，而不是運行在進程中。這個目前監控工具比較常用的方式，比如zabbix，在主機上運行一個進程進行相關數據的采集。
CLI方式
命令行的方式是最基本的方式，比如在linux系統上使用top，vmstat，netstat寫一些shell腳本進行數據的采集，再把數據存儲在文本文件中進行處理。
在不同的場景可以選用不同的數據采集方式，比如要實時看主機的CPU使用情況，登陸到主機用CLI方式用top命令就可以看到系統CPU的使用和進程CPU的使用情況。比如有一些應用的狀態需要記錄，就一定要在日志里輸出相應的數據。而在數據采集時需要注意以下三個問題：
采集的時間間隔
對應用平台的監控數據采集的頻率非常重要，關系到數據的及時性，有效性。在做監控數據采集時，也是根據不同的監控對象設定不同的時間間隔。比如對日志的監控是實時的，對實例的狀態也是實時的，而對於一些后期用來分析的狀態性數據則采集的時間間隔會長一些，3-5分鍾的樣子。
監控工具自身的安全控制
有些監控工具可能是時時運行，特別是侵入式監控，如果運行不當，自身就可能造成故障，比如執行過程異常不釋放資源，造成高CPU占用；比如進程結束異常，不停的重啟相同的進程；比如日志級別設置過低，大量日志輸出，影響進程性能和占用大量磁盤空間。所以做監控時一定要遵循有自我安全控制的能力。監控工具在拿到生產環境中運行前，一定要先在測試環境中進行一段時間的試運行 。
觸發式的數據采集
需要關注異常點的現場數據采集，比如threaddump，heapdump，主機的性能數據等。這些故障點的數據重啟后就會失去，有些故障不能重現時，相關的分析數據就很重要了，所以對於這些數據，需要進行觸發式的數據采集。當滿足某些條件時觸發采集，而在平常不運行。
容器的監控方案
傳統的監控系統大多是針對物理機或虛擬機設計的，物理機和虛擬機的特點是靜態的，生命周期長，一個環境安裝配置好后可能幾年都不會去變動，那么對監控系統來說，監控對像是靜態的，對監控對象做的監控配置也是靜態的，系統上線部署好監控后基本就不再需要管理。
雖然物理機，虛擬機，容器對於應用進程來說都是host環境，容器也是一個輕量級的虛擬機， 但容器是動態的， 生命周期短，特別是在微服務的分布式架構下，容器的個數，IP地址隨時可能變化。如果還采用原來傳統監控的方案，則會增加監控的復雜度。比如對於一個物理機或虛擬機，我們只要安裝一個監控工具的agent就可以了，但如果在一個物理機上運行了無數個容器，也采用安裝agent的方式，就會增加agent對資源的占用，但因為容器是與宿主機是共享資源，所以在容器內采集的性能數據會是宿主機的數據，那就失去在容器內采集數據的意義了。
而且往往容器的數量比較多，那么采集到的數量也會非常多，容器可能啟動幾分鍾就停止了，那么原來采集的數據就沒有價值了，則會產生大量這樣沒有價值的監控數據，維護起來也會非常的復雜。那么應該如何對容器進行監控呢？答案是在容器外，宿主機上進行監控。這樣不僅可以監控到每個容器的資源使用情況，還可以監控到容器的狀態，數量等數據。
單台主機上容器的監控
單台主機上容器的監控實現最簡單的方法就是使用命令Docker stats，就可以顯示所有容器的資源使用情況，如下輸出：
雖然可以很直觀地看到每個容器的資源使用情況，但是顯示的只是一個當前值，並不能看到變化趨勢。而谷歌提供的圖形化工具不僅可以看到每個容器的資源使用情況，還可以看到主機的資源使用情況，並且可以設置顯示一段時間內的越勢。以下是cAdvisor的面板：
而且cAdivsor的安裝非常簡單，下載一個cAdvisor的容器啟動后，就可以使用主機IP加默認端口8080進行訪問了。
跨多台主機上容器的監控
cAdivsor雖然能采集到監控數據，也有很好的界面展示，但是並不能顯示跨主機的監控數據，當主機多的情況，需要有一種集中式的管理方法將數據進行匯總展示，最經典的方案就是 cAdvisor+ Influxdb+grafana，可以在每台主機上運行一個cAdvisor容器負責數據采集，再將采集后的數據都存到時序型數據庫influxdb中，再通過圖形展示工具grafana定制展示面板。結構如下：
這三個工具的安裝也非常簡單，可以直接啟動三個容器快速安裝。如下所示：
在上面的安裝步驟中，先是啟動influxdb容器，然后進行到容器內部配置一個數據庫給cadvisor專用，然后再啟動cadvisor容器，容器啟動的時候指定把數據存儲到influxdb中，最后啟動grafana容器，在展示頁面里配置grafana的數據源為influxdb，再定制要展示的數據，一個簡單的跨多主機的監控系統就構建成功了。下圖為Grafana的界面：
Kubernetes上容器的監控
在Kubernetes的新版本中已經集成了cAdvisor，所以在Kubernetes架構下，不需要單獨再去安裝cAdvisor，可以直接使用節點的IP加默認端口4194就可以直接訪問cAdvisor的監控面板。而Kubernetes還提供一個叫heapster的組件用於聚合每個node上cAdvisor采集的數據，再通過Kubedash進行展示，結構如下：
在Kubernetes的框架里，master復雜調度后有的node，所以在heapster啟動時，當heapster配合k8s運行時，需要指定kubernetes_master的地址，heapster通過k8s得到所有node節點地址，然后通過訪問對應的node ip和端口號(10250)來調用目標節點Kubelet的HTTP接口，再由Kubelet調用cAdvisor服務獲取該節點上所有容器的性能數據，並依次返回到heapster進行數據聚合。再通過kubedash進行展示，界面如下：
Mesos的監控方案
而Mesos提供一個mesos-exporter工具，用於導出mesos集群的監控數據prometheus，而prometheus是個集 db、graph、statistic、alert 於一體的監控工具，安裝也非常簡單，下載包后做些參數的配置，比如監控的對象就可以運行了，默認通過9090端口訪問。而mesos-exporter工具只需要在每個slave節點上啟動一個進程，再mesos-exporter監控配置到prometheus server的監控目標中就可以獲取到相關的數據。架構如下：
在Prometheus的面板上我們可以看到Prometheus的監控對象可以為mesos-export，也可以為cAdvisor。
下面為Prometheus的展示界面：
采集工具的對比
cAdvisor 可以采集本機以及容器的資源監控數據，如CPU、 memory、filesystem and network usage statistics）。還可以展示Docker的信息及主機上已下載的鏡像情況。因為cAdvisor默認是將數據緩存在內存中，在顯示界面上只能顯示1分鍾左右的趨勢，所以歷史的數據還是不能看到，但它也提供不同的持久化存儲后端，比如influxdb等。
Heapster的前提是使用cAdvisor采集每個node上主機和容器資源的使用情況，再將所有node上的數據進行聚合，這樣不僅可以看到整個Kubernetes集群的資源情況，還可以分別查看每個node/namespace及每個node/namespace下pod的資源情況。這樣就可以從cluster，node，pod的各個層面提供詳細的資源使用情況。默認也是存儲在內存中，也提供不同的持久化存儲后端，比如influxdb等。
mesos-exporter的特點是可以采集 task 的監控數據。mesos在資源調度時是在每個slave上啟動task executor，這些task executor可以是容器，也可以不是容器。而mesos-exporter則可以從task的角度來了解資源的使用情況，而不是一個一個沒有關聯關系的容器。
以上從幾個典型的架構上介紹了一些監控，但都不是最優實踐。需要根據生產環境的特點結合每個監控產品的優勢來達到監控的目的。比如Grafana的圖表展示能力強，但是沒有告警的功能，那么可以結合Prometheus在數據處理能力改善數據分析的展示。下面列了一些監控產品，但並不是嚴格按表格進行分類，比如Prometheus和Zabbix都有采集，展示，告警的功能。都可以了解一下，各取所長。
陳愛珍，七牛雲布道師。擁有多年企業級系統的應用運維及分布式系統實戰經驗，現專注於容器、微服務及DevOps落地的研究與實踐。