基于ELK自動化收集Docker容器日志的分析系統(tǒng)

周德永，王瑞剛，梁小江

（1.西安郵電大學 陜西 西安710061；2.陜西省信息化工程研究院 陜西 西安710061）

基于ELK自動化收集Docker容器日志的分析系統(tǒng)

周德永1，王瑞剛1，梁小江2

（1.西安郵電大學 陜西 西安710061；2.陜西省信息化工程研究院 陜西 西安710061）

針對Docker容器集群中日志的收集和集中處理的問題。本文采用Docker Swarm和Etcd實現(xiàn)容器的管理、服務發(fā)現(xiàn)以及調度，并為分布式系統(tǒng)提供支撐。使用主流的開源日志收集系統(tǒng)ELK，并結合分布式消息隊列redis部署實時消息自動化系統(tǒng)，能夠快速、實時地收集應用日志，提高運維人員的工作效率。詳細介紹了Docker、ELK、Docker Swarm和Etcd的功能及原理，最后通過使用容器編排工具docker-compose，一鍵式構建基于Docker容器的ELK日志收集系統(tǒng)的實驗環(huán)境，證明了本系統(tǒng)收集Docker容器日志的實時性、穩(wěn)定性和高可用性。

Docker集群；Docker Swarm；Etcd；ELK；自動化；分布式

Abstract:According to the log Docker container cluster in the collection and centralized processing problems.In this paper， Swarm Docker and Etcd are used to realize the management of containers，service discovery and scheduling，and to provide support for distributed systems.Using the mainstream open source log collection system ELK，combined with distributed message queue redis deployment of real-time message automation system，can quickly and real-time collection of application log，improve the efficiency of operation and maintenance personnel.This paper introduces the function and principle of Docker， ELK， Docker， Swarm and Etcd， finally，by useing the container layout tool docker-compose，one button in the experimental environment of Docker container based on ELK log collection system，it is proved that the system collects the Docker container log in real-time，stable and high availability.

Key words:Docker cluster；Docker Swarm；Etcd；ELK；automated；distributed

Docker是一款基于LXC的容器引擎，自2013年開源以來，因為其易用性、可移植性在開源社區(qū)非?；馃帷ocker是把軟件與其依賴環(huán)境打包成鏡像，并以鏡像的方式交付，讓應用運行在“標準環(huán)境”中，這非常符合云計算的要求。各大IT巨頭紛紛跟進，基于Docker容器技術創(chuàng)業(yè)公司也如雨后春筍，Docker創(chuàng)造了一個嶄新的容器云行業(yè)。Docker技術應用廣泛[1]。如利用其隔離特性，為開發(fā)、測試提供一個輕量的、獨立的環(huán)境，加速本地開發(fā)和構建的流程，使其更加高效、輕量化。開發(fā)人員可以構建、運行并分享容器，輕松提交到測試環(huán)境中，最終進入生產環(huán)境。

在生產環(huán)境中運行的容器集群，日志系統(tǒng)是保障系統(tǒng)穩(wěn)定運行不可或缺的一部分，Docker容器產生的日志不同于以往將所有日志放在主機系統(tǒng)的統(tǒng)一位置的日志類型，而是日志分散在很多不同容器的相互隔離的環(huán)境中[2]，這就迫使人們尋求另一種方式來存儲日志。ELK能夠靈活地按照時間窗對特定字段做數(shù)值統(tǒng)計，它支持按照關鍵詞搜索和瀏覽，并運用實時數(shù)據(jù)處理技術對這些數(shù)據(jù)建立索引和統(tǒng)計，幫助運維人員快速定位問題的根源，及時發(fā)現(xiàn)數(shù)據(jù)價值，提高工作效率，而且它提供了一種集中式的日志服務器的Web管理界面[3]。

1 Docker容器技術

Docker是以容器為資源分割和調度的基本單位，封裝整個軟件運行時的環(huán)境，為開發(fā)者和系統(tǒng)管理員設計的，用于構建、發(fā)布和運行分布式應用平臺。它提供了簡單易用的跨平臺、可移植的容器解決方案[4]。

Docker基于松耦合的架構，架構中各個功能模塊支撐著容器的生命周期，例如容器的構建、運行和應用。架構中的主要模塊包括Docker Client、Docker Daemon、Docker Register、graph、Drive、libcontainer 和Docker Container[5]。Docker的整體架構如圖1所示。

圖1 docker架構

Docker daemon是Docker架構中的主要用戶接口。首先，它提供了APIserver用于接收來自Docker client的請求，其后根據(jù)不同的請求發(fā)給Docker daemon的不同模塊執(zhí)行相應的工作。Docker是通過driver模塊來實現(xiàn)對Docker容器運行環(huán)境的構建。鏡像的存儲是由鏡像管理驅動graphdriver來完成；Docker容器的網(wǎng)絡環(huán)境是由網(wǎng)絡驅動networkdriver來完成；Docker容器運行資源或執(zhí)行用戶指令等操作時，則通過execdriver來完成。libcontainer是一個獨立的容器管理包，networkdriver和execdriver都通過libcontainer來實現(xiàn)對容器的具體操作，包括利用UTS、PID、Network、Mount等 namespace實現(xiàn)容器之間的資源隔離和利用cgroup實現(xiàn)對容器的資源隔離。

Docker之所這么受歡迎，主要是因為它具有以下的優(yōu)勢[6]：

1）高資源利用率和隔離：Docker容器與底層共享操作系統(tǒng)，性能更加優(yōu)良，在同等條件下可以運行更多的應用實例，充分地利用系統(tǒng)資源。而且，Docker擁有很好的資源隔離與限制能力，可以精確地將CPU、內存等資源分配到應用，保證了應用間不會相互影響。

2）易用性：Docker能獲取如此巨大的成功，主要是因為他的易用性。Docker創(chuàng)造了一種統(tǒng)一的方式，通過簡便的命令行及HTTP API工具來打包、運行和維護容器。這種簡化降低了將應用程序及其運行環(huán)境打包成一個自包含鏡像的入門門檻，使之變得可行，而不需要類似Chef、Puppet及Capistrano之類的配置管理和發(fā)布系統(tǒng)。

3）容器跨平臺性與鏡像：Docker在原有Linux容器的基礎上進行大膽創(chuàng)新，并為容器設定了一整套標準化的配制方法，將應用及其依賴的運行環(huán)境打包成為鏡像，實現(xiàn)了“構建一次，到處運行”的理念，大大提高了容器的跨平臺特性。

2 Docker容器與虛擬機的比較

Docker可以被稱為輕量級虛擬化技術。與傳統(tǒng)的VM相比，它更輕量，啟動速度更快，單臺硬件上可以同時跑成百上千個容器，所以非常適合在業(yè)務高峰期通過啟動過大量容器進行橫向擴展?；谌萜骷夹g的Docker不需要額外的虛擬化管理程序（hypervisor）支持，利用Linux內核特性命名空間（namespaces）及控制組（cgroups）提供隔離的運行環(huán)境，幫助用戶在容器內部快速自動化部署應用。由于Docker的資源隔離在操作系統(tǒng)層通過虛擬化技術實現(xiàn)，使得Docker容器的運行和宿主機共享同一個操作系統(tǒng)，因此不會產生額外的系統(tǒng)開銷，在提高了資源利用率的同時也提升了I/O等方面的性能。Docker輕量級容器技術與傳統(tǒng)虛擬技術的對比如圖2所示。

圖2 虛擬機與Docker的實現(xiàn)框架

從圖中可以總結，容器和虛機都是屬于虛擬化技術的一種實現(xiàn)。兩種架構在底層上相同，需要物理硬件和操作系統(tǒng)的支持。不同的是虛擬機場景中，虛擬機管理程序（如KVM）作為操作系統(tǒng)到虛擬機的中間層，而容器場景中Docker Engine（以Docker為例）作為操作系統(tǒng)到容器的中間層。虛機封裝操作系統(tǒng)和應用，而容器則直接封裝應用，這也是為什么容器要比虛機輕量、相對于虛擬機比較輕量、靈活、資源利用率高的原因。在生成環(huán)境中，這些資源節(jié)約很容易轉化為成本節(jié)約。

3 容器日志收集

在生產環(huán)境中，容器需要支持服務是與非容器環(huán)境一樣的[7]。包括如何從容器實例中捕獲日志，并將它們傳輸?shù)郊惺饺罩竟芾硐到y(tǒng)中。容器的臨時狀態(tài)是容器的日志領域中需要突出顯示的一個關鍵特性。當生產環(huán)境做發(fā)布時，舊的容器會被新的容器替換。這對于傳統(tǒng)概念中假設有狀態(tài)和長時間運行的計算單元是一種破壞。滾動容器特性對于處理傳統(tǒng)日志的理念帶來了新的問題[8]。與讓計算實例運行長達數(shù)天甚至數(shù)月不同的是，容器可能在以小時為單位的時間內就發(fā)生變化。在生產環(huán)境中，一個良好的容器日志收集方案，通過分析日志可以快速分析定位錯誤，減少運維人員的難度，提高運維效率。

不同于以往將所有日志放在主機系統(tǒng)的統(tǒng)一位置，Docker日志分散在相互隔離的容器環(huán)境中。每個運行在容器內的應用的日志輸出統(tǒng)一保存在宿主機的/var/lib/dockr/containers/$CONTAINER_ID目錄下。因為Docker容器資源是相互隔離的，所以Docker環(huán)境下的日志收集很不方便[9]。目前主要有以下幾種收集Docker容器日志的方法。

1）默認情況下，Docker采用的是 json-file，它會將應用的日志以json格式存儲到容器根文件的日志路徑下。擁有root權限的用戶可以使用命令docker logs＜container-id＞來查看容器從啟動開始所有的日志。當前Docker僅將應用的stdout和stderr兩個日志輸出，執(zhí)行命令docker logs＜container-id＞不一定顯示文件的輸出內容。如果應用日志的輸出量很大，日志沒有自動切分功能，docker logs命令返回的日志記錄過于冗長。此外，Docker以json消息記錄每一行日志，這將會導致文件增長過快，從而超過主機磁盤限額。

2）連接到Docker容器：Docker在1.3版本推出docker exec子命令，它允許用戶在正在運行的docker容器里執(zhí)行任何命令。一旦進入到容器，用戶便可以看到一些可能不被記錄的stdout或stderr的額外的日志文件。然而，這并不是一個適用于生產系統(tǒng)的可擴展方案。生產系統(tǒng)一般需要一個集中式的日志平臺來查看匯總的日志流。

3）將日志導出到宿主機：用戶可以在Dockerfile鏡像里使用VOLUME指令或使用docker run-v參數(shù)將容器里的一個文件路徑掛載到宿主機文件系統(tǒng)的一個位置上。默認情況下，Dockerfile里的VOLUME指令使用的是容器里的路徑，其對應的一般是一個跟文件系統(tǒng)的位置，如果用戶的根文件系統(tǒng)已經(jīng)滿了，這就會導致用戶的宿主機出現(xiàn)一些大問題，而且它很難被清理干凈。

4）發(fā)送日志到集中式的日志平臺：如果要將日志發(fā)送到一個集中式的日志系統(tǒng)里，除了將它導出宿主機似乎別無他法。以標準的syslog為例。運行的容器里應用會把日志傳送到/logs/apps/里，然后安裝和配置一個syslog守護進程，從該目錄下位置下讀取任何存在的日志信息。隨后，它被配置成可以將日志發(fā)送到一個集中式的日志服務器里。這一模式確實很有價值，然而卻存在一些明顯的短板，若在一個容器里運行多個進程，這可能會導致在進程利用方面變得更加笨重，并使得應用隔離的便利性蕩然無存。

5）在其他容器一側收集日志：從容器里獲取日志的方案在業(yè)界逐漸變得流行起來。它使用共享數(shù)據(jù)卷將系統(tǒng)的其他容器聯(lián)系起來，并且讓其他容器使用--volumes-from選項來繼承這個卷，用戶便可以在其他正在運行的容器里提取自己所需要的日志數(shù)據(jù)。在一個系統(tǒng)上有多個容器的場景下采用這一方案可以節(jié)省一些不必要的處理時間。用戶可以把各個容器里的所有日志放到一個單獨的容器里面，然后將其集中起來發(fā)送到一個集中式的日志系統(tǒng)。由于將所有的事物都整合到一個統(tǒng)一的日志采集服務，因此用戶便可以節(jié)省一大筆的資源。

本文采用在容器一側收集日志這一方案，在一個多容器的系統(tǒng)場景下采用本方案可以節(jié)省一些不必要的處理時間，比如方法1和2查找所需要日志花費時間多。采用開源的日志收集系統(tǒng)ELK，結合高性能的key-value數(shù)據(jù)庫Redis實現(xiàn)docker容器日志的收集分析功能。

ELK stack是以分布式搜素引擎Elasticsearch、日志采集解析工具Logstash、分析可視化界面Kibana 3個開元軟件為主的數(shù)據(jù)處理工具鏈，在實時數(shù)據(jù)檢索和分析場合，三者通常是配合使用，為快速應對大數(shù)據(jù)時代的數(shù)據(jù)收集、檢索、可視化，提供一站式解決方案。

Logstash是一種基于Ruby的集合應用程序日志、事件的傳輸、處理、管理和搜索的平臺。利用JVM的線程功能進行數(shù)據(jù)的并行處理，并支持多種插件。Elasticsearch是一個基于Apache Lucene（TM）的開源搜索引擎，使用Lucene作為實現(xiàn)所有索引和搜索的功能，它通過簡單的RESTful API來隱藏Lucene的復雜性，從而讓全文搜索變得簡單。Kibana是一款具有分析和可視化功能的web界面?？梢允褂肒ibana搜索，查看，并與存儲在Elasticsearch指數(shù)的數(shù)據(jù)進行交互?？梢愿鶕?jù)圖表和表格執(zhí)行數(shù)據(jù)分析和可視化。

基于Docker部署ELK日志收集系統(tǒng)非常方便，使用Docker編排工具docker-compose，一鍵式部署所需要的各種容器[10-11]。本文對Docker、ELK、redis深度整合，組成分布式日志收集自動化系統(tǒng)。架構如圖3所示。

圖3 日志系統(tǒng)框架

本系統(tǒng)首先構建 Redis、Logstash、ElasticSearch、Kibana的Docker鏡像，鏡像文件基于Ubuntu:14.04，然后使用docker-compose工具一鍵式構建了所需要的容器。從圖中可以看出，多個Logspout部署在不同的node節(jié)點上，各個應用容器的日志通過volumefrom的方法被Logspout收集，Logspout來向Logstash Shipper轉發(fā)送容器的日志，Logstash Shipper作為遠程syslog來收集來自容器的日志，然后發(fā)送給Redis消息隊列；Redis是接收容器日志的消息隊列，臨時存儲日志發(fā)揮緩沖的作用，防止大量日志上傳后，拖垮 Logstash Indexer；Logstash Indexer做日志解析，統(tǒng)一成JSON輸出給 Elasticsearch；ElasticSearch來索引收集的日志數(shù)據(jù)并使它更易于查詢；Kibana與收集來的數(shù)據(jù)進行交互的一個實用的web前端。使用open Vswitch虛擬交換機，實現(xiàn)各個物理機上的docker容器之間跨主機通信。圖4是UI動態(tài)監(jiān)控各個docker容器示例產生的各種日志。

從實驗結果總結，本系統(tǒng)實現(xiàn)了docker容器日志自動化、實時性的收集，而且ELK應用于Docker容器中，可以能夠達到實時搜索、穩(wěn)定、可靠、快速、安裝使用方便。

圖4 Kibana dashboard

在分布式集群系統(tǒng)中，容器的管理、服務發(fā)現(xiàn)與調度功能至關重要[12-13]。在集群環(huán)境中部署容器，Kubernetes和Docker Swarm是最常用的兩種工具[14]。它們都是創(chuàng)建容器的輔助工具，可以用來管理一個容器集群，并將所有服務器作為獨立的單元來處理。kubernetes是Google根據(jù)其在Linux上容器管理經(jīng)驗，改造到docker管理上的。而docker swarm是Docker原生的集群工具。Kubernetes安裝復雜，不同的操作系統(tǒng)安裝都不相同；Docker Swarm安裝簡單明了并且靈活。并且Docker Swarm支持多種docker自帶的命令工具。本文采用的是docker swarm，并結合高可用的鍵值存儲倉庫etcd實現(xiàn)容器的管理、服務發(fā)現(xiàn)與調度[15]，部署了開源的docker容器圖形化管理平臺shipyard。

基于etcd和swarm的容器管理、服務發(fā)現(xiàn)與調度架構圖如圖5所示，Docker Swarm發(fā)現(xiàn)Docker集群中的各個節(jié)點，收集節(jié)點狀態(tài)、角色信息，并監(jiān)聽各個節(jié)點狀態(tài)的變化，發(fā)現(xiàn)（etcd discovery）是Swarm中用于維護Docker集群狀態(tài)的機制。Docker swarm通過發(fā)現(xiàn)機制發(fā)現(xiàn)所有注冊的Docker Node，并收集到所有Docker Node的狀態(tài)以及具體信息。此后，Docker Swarm一旦接收到具體的Docker管理請求，Swarm會對請求進行處理，并通過所有Docker Node的狀態(tài)以及具體信息，來篩選決策哪些Docker Node滿足要求，并通過一定的策略將請求轉發(fā)至具體的一個Docker Node；Docker Swarm創(chuàng)建并初始化API監(jiān)聽服務模塊。注冊、發(fā)現(xiàn)以及調度模塊在容器中獨立運行，負責監(jiān)聽端口或者連接到其他主機的端口，不需要編寫容器植入性代碼。可以實現(xiàn)服務、注冊、調度集群，以及分布式的終端部署集成。

Shipyard管理界面如圖6所示，實現(xiàn)了容器，主機，鏡像等資源的管理。

圖5 基于etcd和swarm的容器管理、服務發(fā)現(xiàn)與調度

圖6 Shipyard管理界面

4 結 論

隨著Docker容器技術的發(fā)展，越來越多的容器被創(chuàng)建，在大規(guī)模的容器集群中日志處理平臺是保障集群穩(wěn)定運行的關鍵?；贓LK Docker容器集群日志收集的云存儲應用，用戶可以進行多主機、多區(qū)域對象服務請求，可以實現(xiàn)對應用容器的日志數(shù)據(jù)的存儲、管理、整合。通過Docker Swarm和Etcd等工具的使用，實現(xiàn)了負載均衡減輕服務器壓力，有效提升服務請求的吞吐能力。自動化的收集容器日志，實現(xiàn)服務器的高可靠性和穩(wěn)定性。

通過實驗模擬，當并行服務請求急劇增長的情況下，本系統(tǒng)能夠有效地、實時地收集來自應用容器的日志，能夠實現(xiàn)Docker容器集群日志收集的實時性、高可用性。

[1]Turnbull，j.第一本Docker書[M].李兆海，劉斌，巨震，譯.北京：人民郵電出版社，2015.

[2]Joe Johnston，Antoni Batchelli.Docker生產環(huán)境實踐指南[M].吳家興，梁曉勇，譯.北京：人民郵電出版社，2016.

[3]饒琛琳.ELK stack權威指南[M].北京：機械工業(yè)出版社，2015.

[4]浙江大學SEL實驗室.Dcoekr容器與容器云[M].北京：人民郵電出版社，2015.

[5]孫洪亮.Docker源碼分析[EB/OL].[2014-09]http://open.daocloud.io/tag/yuan-ma-fen-xi/.

[6]趙樂樂，黃剛，馬越.基于Docker的Hadoop平臺架構研究 [EB/OL].（2016-08）.http://www.cnki.net/kcms/detail/61.1450.TP.20160801.0909.072.html.

[7]Spujadas.Elasticsearch， Logstash， Kibana （ELK）Docker image documentation[EB/OL].[2016-04-22].http://elk-docker.readthedocs.io/#elasticsearchlogstash-kibana-elk-docker-image-documentation.

[8]Deni Bertovic.Docker and Logstash:Smarter Log Management For Your Containers[EB/OL].[2014-02-03].https://denibertovic.com/post/docker-andlogstash-smarter-log-management-for-yourcontainers/.

[9]Nathan leclaire.Automating Docker Logging:Elastic Search， Logstash， Kibana， and Logspout[EB/OL].[2015-04-27].https://nathanleclaire.com/blog/2015/04/27/automating-docker-logging-elasticsearchlogstash-kibana-and-logspout/.

[10]姜繼忠.容器服務中使用ELK[EB/OL].[2016-09-06].https://yq.aliyun.com/articles/60059spm=5176.100240.searchblog.7.QaNI0p.

[11]Jimmycmh.容器內日志收集方案示例[EB/OL].[2015-12-24].https://yq.aliyun.com/articles/303.

[12]孫宏亮.深入淺出Swarm[EB/OL].[2015-01-25].http://blog.daocloud.io/swarm_analysis_part1/.

[13]Yi wang.你是否真的了解 Docker Swarm[EB/OL].[2016-05-07].http://blog.daocloud.io/docker-swarm-1/.

[14]Viktor Farcic.Docker Clustering Tools Compared:Kubernetes vs Docker Swarm.[EB/OL].[2015-11-04].https://technologyconversations.com/2015/11/04/docker-clustering-tools-compared-kubernetesvs-docker-swarm/.

[15]孫健波.etcd：從應用場景到實現(xiàn)原理的全方位解讀.[EB/OL].[2015-02-03].http://linux.cn/article-4810-1.html.

Analysis system based on ELK automated collection of Docker container log

ZHOU De-yong1， WANG Rui-gang1， LIANG Xiao-jiang2
（1.Xi'an University of Posts and Telecommunications， Xi'an710061，China；2.Shanxi Information Engineering Research Institute， Xi'an710061，China）

TN919.6

A

1674－6236（2017）19-0050-06

2016-09-26稿件編號201609238

周德永（1989—），男，安徽阜陽人，碩士研究生。研究方向：云計算與大數(shù)據(jù)處理。