作者：林帆，ThoughtWorks公司DevOps技術咨詢師。熱衷于對DevOps和容器技術應用的推廣，在容器規?；\維方面有較豐富實踐經驗。
　　本文節選自程序員雜志，謝絕轉載，更多精彩，請訂閱程序員雜志
　　都說『下層基礎決定上層建筑』，然而在互聯網軟件的實踐里，設計規劃時往往是至上而下進行的，從用戶需求到技術架構，再到框架選型、方案設計、模塊拆分，直到了最后才會發現是不是應該也考慮一下服務的運維設施，但畢竟那是上線以后的事情了，先實現能帶來業務價值的功能再說。隨著業務規模的逐步擴大，基礎設施的不完善會讓許多線上問題發生得措手不及，磁盤不足、內存泄露、服務器故障，設計上的缺陷以及運行環境的脆弱時刻都可能成為壓垮系統的那根稻草。而到此時，由于沒有必要的預警措施和預先留置的調試手段，解決故障的過程也處處捉襟見肘。
　　DevOps的理念一直倡導將運維設施的設計提前到服務設計的階段，尤其是在規模不大、沒有專用運維平臺的產品團隊中，這種理念的價值尤其顯著。在運維基礎設施中，服務狀態和性能的監控預警是降低潛在故障風險最有效的措施，而對運行日志進行匯總收集則是在意外事故發生后快速定位問題、回溯故障現場的可靠手段。
　　這次我們就來聊一聊在容器技術架構中實施 性能監控和 日志管理的話題。
　　微服務●容器●集群
　　伴隨著微服務架構的流行，容器和集群的運用近年來如雨后春筍般的鋪開。不過，實踐過微服務的企業都不難發現，微服務帶來的靈活性和擴展性其實是以基礎設施的復雜性作為代價的，這一點尤其體現在服務的部署、依賴和版本管理、線上調試、狀態監控等方面。作為微服務的好搭檔，容器技術簡化了服務的部署和版本管理方面的問題，因此凡談微服務實施的文章，十有八九也會談及容器。
　　容器使得微服務的運維變得高效和輕量，然而根據我們的實際經驗，容器對于微服務也是一把雙刃劍。微服務系統做到一定程度必然逐步發展成分布式結構，相應的基礎設施也會由單機過渡到集群。由于微服務系統中的每個單獨服務都是分別部署、獨立伸縮的，服務運行的位置、個數、IP地址隨時可能變化，對這樣的環境進行管理本來就不是容易的事情，引入容器實際上又增加了一層變數。從運維成本來看，容器的運用對于微服務集群的故障調試和監控方面不僅不能帶來什么幫助，使用不得當還可能會弄巧成拙：許多曾經在虛擬機集群上廣泛使用的監控和管理工具對于容器化的服務不再適用了。
　　容器的運維有什么玄機？這事情得從容器的原理說起。
　　容器友好的基礎設施
　　容器對服務的隔離運行基于的是內核的Namespace和Chroot等特性，這些特性使得在容器中運行的服務擁有獨立的系統環境、網絡棧和文件存儲空間，幾乎就是一個微型虛擬機。使用者在創建容器實例時通常會為每個容器起一個直觀且有意義的名字，這個信息對于排查問題時定位出錯的服務十分有用。
　　以性能監控的場景為例，通常的實施方式有在主機上收集數據和在容器內部收集數據兩種。若是在主機上收集性能數據，傳統的監控工具是以系統進程為對象記錄的，由于容器的場景常常會在同一個主機上部署多個獨立服務，這些服務對外提供的功能各不相同，可以說是毫不相干的服務類型，但從進程的角度上看卻并無差異（例如都是Tomcat進程），因此在監控系統中難以快速的區分并與相應容器實例進行關聯。若是從容器內部收集數據，服務與容器的對應關系就很容易找到了，但這與Docker提出的每個容器中只有一個清楚明確任務的哲學相悖，并且大量的數據收集客戶端也會增加很多額外系統開銷。
　　日志收集的場景十分相似。用戶或者將日志輸出到容器的控制臺，在主機上的容器日志目錄里翻找容器中打印出的數據，或者將日志輸出到文件，在容器里收集實例內的日志文件內容。前者會面臨日志文件和容器名稱對應的難題（以Docker容器為例，日志路徑能夠推測出容器實例的ID，但無法快速識別出實例名稱），后者需要對容器鏡像改造，并且有悖于單任務容器的設計原則。
　　由此看來，直接照搬虛擬機管理的基礎設施到容器化服務的集群上是不適合的。那么如何構建一套對容器運維友好的基礎設施呢？
　　我們且從盡可能不要重復造輪子的角度考慮，看看原有方案的問題出在哪里。首先否定在容器實例里增加額外管理服務的思路，這種做法且不說成倍的增加帶寬和內存開銷，未來升級這些鏡像里的各種管理客戶端也將非常麻煩。反觀基于主機層面的管理思路，欠缺的其實是服務于所屬容器的對應關聯，而這些信息通常是能夠使用容器服務（例如Docker）的API查詢出來的。特別是對于Docker容器，在命令行工具『docker stats』或『docker inspect』的輸出中就能獲取到很多有用的信息。因此，一種比較有效的方法是對運行在主機上的客戶端工具進行適當改造，彌補缺失的這部分數據內容。這個改造工作不算太麻煩，但十分瑣碎，所幸的是，目前有許多開源的或者企業及的運維工具已經集成了容器信息的預處理，用戶需要的只是做好運維工具的正確選型。
　　下面針對開源工具的方面，介紹幾種容器友好的監控和日志管理方案。
　　容器性能監控：開源的全新時代
　　在虛擬機運維的時代，Nagios和Zabbix等都是十分經典的性能監控軟件。但在容器時代，這些曾經耳熟能詳的軟件以及其他過去用于虛擬機的監控工具大多不能提供方便的容器化服務的監控體驗，社區對開發這類插件和數據收集客戶端也并不積極。相反的許多新生的開源監控項目則將對容器的支持放到了關鍵特性的位置，可以說容器的應用界定了一個全新的監控軟件時代，一代新人換舊人。
　　在這些新生的監控工具中，值得一提的是2015年的Docker歐洲技術大會（Docker EU 2015）上，Swisscom AG的云方案架構師Brian Christner推薦的基于InfluxDB或Prometheus的方案。Christner在闡述完容器監控的基本方法原則后，演示了三種比較流行且成熟的具體方案，分別是『cAdvisor』、『cAdvisor + InfluxDB + Grafana』和『Prometheus』。其中基于InfluxDB的方案是一個多種開源組件的組合方案，而基于Prometheus的方案在現場演示時，是為一種整體解決方案出現的。事實上Prometheus雖然是整體化的開源監控軟件，但它本身對容器信息的收集能力以及圖表展示能力相比其他專用開源組件較弱，通常在實際實施的時候依然會將它組合為『cAdvisor + Prometheus』或『cAdvisor + Prometheus + Grafana』的方式使用。
　　這幾組方案中的Influxdb和Prometheus都是當下已被廣泛認可的性能、狀態及其他時間序列數據的存儲和檢索工具。時間序列數據指的是一類對時間關系比較敏感的數據序列，這類數據是在不同時間點上采用相同方法收集的，通過這些數據可以反映出某種特征的趨勢變化，而其中出現的異常數據點往往與某些值得關注的事件直接相關。另外，由于這些數據主要是用于故障告警、趨勢分析和事故后的現場回溯，因此對于越接近現在的數據需要的精度越高，有時可以采用對一段時間之前的數據數據間隔抽樣丟棄的方法，以降低精度為代價減少存儲空間消耗。比如說，一周內的數據進行全量的保存，一周前的數據就把精度丟掉一半，一個月前的數據把精度再丟掉一半，類似這樣的處理若是用通用型數據庫要做起來就要復雜得多。
　　cAdvisor對經常使用容器的讀者來說應該不陌生，它是谷歌專為監控容器性能狀態設計的一個開源工具。cAdvisor只有一個二進制文件，使用起來非常簡單，只需直接啟動然后在主機的8080端口就會看到一個簡潔而內容豐富的監控界面。cAdvisor本身不會持久化存儲數據，默認只將保存2分鐘的記錄在內存，更早的數據會被直接丟棄。為此，若是要對數據做進一步處理，就得定期把數據從cAdvisor采集到持久化存儲服務里去。cAdvisor提供有Push和Pull兩種獲取性能數據的接口。Push接口指的是由cAdvisor主動將數據周期性的推送到遠端的存儲服務中，Influxdb與cAdvisor的對接就是通過這個接口完成的。而Pull接口則允許外部訪問服務隨時主動從cAdvisor獲取到當時時刻的性能數據，然后自行處理，Prometheus與cAdvisor的對接用的是這種方法。此外，作為一個專用的容器監控工具，cAdvisor不僅支持多種輸出方式，在輸入方面也頗為靈活，能支持Docker、Systemd-nspawn和Rkt等多個標準的容器監控，具有很好的業界通用性。
　　Grafana是針對時間序列數據設計的一款開源數據展示面板。對于cAdvisor采集上來的數據，Grafana可以提供主機名稱和容器名稱兩級維度的篩選，例如在一個圖表中展示所有『名稱包含nginx的容器』的內存變化曲線，或是所有『名稱是api-gateway且運行在名字含有middleware的主機上的容器』的網絡吞吐量趨勢。這樣查找特定服務并對其進行監控就會變得十分容易，也能縮短在出現問題之后從性能圖表定位具體故障的時間。
　　容器日志管理：Fluentd一枝獨秀
　　傳統的日志匯總收集方案主要有商業軟件Splunk、開源軟件棧ELK和Facebook開源的Scribe等，其中以ELK最為廣泛使用。ELK是ElasticSearch、Logstash和Kibana三個工具的簡稱，經典的ELK架構如圖1所示。在每一個節點部署一個Logstash服務，稱為Shipper，然后收集的日志經過一個Redis緩存，在Redis后面再用另一個Logstash服務去做索引，稱為Indexer，之所以有這樣一個架構一方面是因為Logstash在做數據索引時會消耗較多內存和CPU，不適合在每個節點分別運算，另一方面則是集中運算方便對運算規則進行修改，而在兩級數據之間若不加緩存則可能會由于Indexer處理不及時而丟失部分日志數據。
　　
　　圖1 典型的ELK部署結構
　　然而即使在各個節點上的Logstash Shipper僅僅完成日志采集的工作，依然會帶來不可忽略的額外性能消耗，這主要是由于Logstash基于JRuby語言開發，因此在運行效率上和內存使用上存在一定瓶頸。之后Logstash所屬的公司Elastic推出了基于Go語言的數據采集服務Beats，其中用于做日志文件收集的Filebeat將替代Logstash Shipper的主要功能，為以示區別，這套開源方案被稱為EFK。
　　除了Filebeat，還有許多來自社區的Logstash替代方案，使用比較廣泛的是Apache基金會旗下的Flume和2011年底才剛剛誕生的Fluentd，它們可以同時取代Shipper和Indexer的兩級日志匯聚，這兩種方案同樣需要配合ElasticSearch和Kibana作為日志數據的存儲和展示工具，因此都被稱作是社區方案中的EFK。其中Fluentd在誕生后不久就由于其易用性、擴展性和高效的數據處理能力受到許多企業的青睞，亞馬遜將它稱為是最好的集群日志收集工具。
　　Fluentd并非是專用于日志文件收集的，而是一個通用的信息收集、整理、轉發的流式數據處理工具，日志收集只是它十分典型的一個運用場景。重要的是，Fluentd的日志收集功能對容器支持十分完備，遠遠勝于Logstash等傳統日志收集工具。一方面得益于Fluentd社區開發了幾種專用于Docker日志文件的收集插件，這些插件能夠在Fluentd收集完Docker日志以后自動為它加上容器相關的信息，比較推薦其中的fluent-plugin-docker-metadata-filter這一款插件，它提供的信息頗為齊全。Logstash對于這方面依然比較空缺，GitHub上唯一能夠找到的一款社區插件也已經在一年前就停止開發。另一方面，當前Docker官方支持的日志驅動除了默認的使用本地目錄，還可以直接發送到遠程的日志存儲或日志采集服務，而其中日志采集服務目前僅僅支持Splunk和Fluentd，同樣沒有Logstash等老一輩開源日志工具的蹤影。
　　通過采集本地文件日志和使用Docker的日志驅動的方式各有優劣。默認情況下Docker會將所有容器輸出到系統控制臺的內容重定向到以容器ID命名的一個本地目錄中，只需要定期采集所有這些目錄的內容就能一字不漏的將容器的輸出捕獲出來，這種方式的侵入性很小，但由于是周期性的收集，日志在匯聚端（例如Kibana）的展示會有一定的延時，延時長度與日志收集的周期相關。相反的，如果使用Docker的日志驅動（啟動docker后臺服務時指定參數–log-driver=fluentd）將獲得實時性很好的匯聚端日志展示，但由于日志直接發送到了遠端的Fluentd服務，會使得在本地主機上的docker logs命令失效。兩種方式的共性在于：不論通過哪一種方式，收集到的日志都能夠以容器名稱、鏡像、標簽等對容器使用十分友好的維度進行檢索。
　　總結
　　新技術的大規模流行往往會帶來兩面性的變革，云技術如此、大數據如此、容器技術也屬此列。作為一項正在被越來越多企業所接受的軟件打包、分發和部署標準，容器式服務的運維正在成為傳統運維團隊面對的新挑戰。
　　容器作為DevOps的催化劑，正在為這場欣欣向榮的運動推波助瀾。大浪淘沙，Influxdb、Prometheus、Fluentd…這些誕生不過幾年的新生事物，借著容器化的百丈浪花，撼動著曾經扎根深厚的運維設施基石。技術的更迭方式可以是潛移默化的和平演變，亦或是轟轟烈烈的武裝革命，容器技術應該歸屬于后者?？梢灶A見在更高效和輕量化的運維實踐之后，容器還將為整個IT領域注入更多新鮮和活力，讓我們拭目以待。
?