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