今天我们来说说Docker容器日志。

一、容器日志输出的旧疾及能力演进

Docker容器在默认情况下会将打印到stdout、stderr的 日志数据存储在本地磁盘上，默认位置为/var/lib/docker/containers/{ContainerId} /{ContainerId}-json.log。在老版本Docker中，这种日志记录方式经常被诟病，诸如：日志大小无限制、无法 Rotate（轮转）、无日志基本管理能力以及性能糟糕等。针对这些旧疾，Docker一直试图在演进中完善和解决。

记忆中好像是在Docker 1.8版本中，Docker增加了对json-file型（默认）log driver的rotate功能，我们可通过max-size和max-file两个–log-opt来配置。比如：我们启动一个nginx容器，采用 json-file日志引擎，每个log文件限制最大为1k，轮转的日志个数为5个：

$docker run -d --log-driver=json-file --log-opt max-size=1k --log-opt max-file=5 --name webserver -p 9988:80 nginx
50f100e7ea4d5b4931f144f9eac12b6a05e56579583d7a0322b250004b68ae72
$ sudo ls -l /var/lib/docker/containers/50f100e7ea4d5b4931f144f9eac12b6a05e56579583d7a0322b250004b68ae72
总用量 44
-rw-r--r-- 1 root root  226  3月 24 14:39 50f100e7ea4d5b4931f144f9eac12b6a05e56579583d7a0322b250004b68ae72-json.log
-rw-r--r-- 1 root root 1129  3月 24 14:39 50f100e7ea4d5b4931f144f9eac12b6a05e56579583d7a0322b250004b68ae72-json.log.1
-rw-r--r-- 1 root root 1130  3月 24 14:39 50f100e7ea4d5b4931f144f9eac12b6a05e56579583d7a0322b250004b68ae72-json.log.2
-rw-r--r-- 1 root root 1129  3月 24 14:39 50f100e7ea4d5b4931f144f9eac12b6a05e56579583d7a0322b250004b68ae72-json.log.3
-rw-r--r-- 1 root root 1129  3月 24 14:39 50f100e7ea4d5b4931f144f9eac12b6a05e56579583d7a0322b250004b68ae72-json.log.4
... ...

有了rotate，我们就不必担心某个container的日志暴涨而将同host的其他container拖死了。不过对于日志的管理目前也仅仅演进到如此，很多需求还得依靠第三方工具和方案来解决。

另外当前Docker容器日志的写入性能依旧糟糕，如果对此敏感，可以用volume机制来解决，即 关闭容器内应用的标准输出、错误（–log-driver=none），直接将日志写到某mounted volume中的某个文件中。下面是bare metal裸机原生写日志文件、volume方式写日志文件以及docker默认写json文件的性能简单对比：

我们用dd这个小工具，以go1.6.linux-amd64.tar.gz这个 85MB的文件作为输入，结果如下：（环境ubuntu 12.04 docker 1.9.1）

1、bare metal
dd if=~/.bin/go1.6.linux-amd64.tar.gz of=./go.bin
记录了165623+1 的读入
记录了165623+1 的写出
84799480字节(85 MB)已复制，0.426716 秒，199 MB/秒

2、通过挂在本地volume
$ docker run --rm -it -v /home1/tonybai/testdd/volume:/testdd ubuntu:14.04 dd if=/testdd/go1.6.linux-amd64.tar.gz of=/testdd/go.bin
165623+1 records in
165623+1 records out
84799480 bytes (85 MB) copied, 0.3753 s, 226 MB/s

3、docker default
$docker run  -v /home1/tonybai/testdd/volume:/testdd ubuntu:14.04 dd if=/testdd/go1.6.linux-amd64.tar.gz 2>&1 1>/dev/null

165623+1 records in
165623+1 records out
84799480 bytes (85 MB) copied, 5.97732 s, 14.2 MB/s

$ sudo ls -lh /var/lib/docker/containers/d4b5e6aae3968f68e5081414ad95c6308fa91808b44b415a03040403af5a4713/                                              d4b5e6aae3968f68e5081414ad95c6308fa91808b44b415a03040403af5a4713-json.log
-rw------- 1 root root 331M  3月 24 18:05 /var/lib/docker/containers/d4b5e6aae3968f68e5081414ad95c6308fa91808b44b415a03040403af5a4713/                                          d4b5e6aae3968f68e5081414ad95c6308fa91808b44b415a03040403af5a4713-json.log

可以看出，默认情况下，Docker写入json的速度是挂载volume方式的十分之一还低。主要原因是Docker容器的标准输出、 标准错误都会被Docker Daemon接管，并由Daemon写入json log文件，因此Daemon就成为了日志写入的瓶颈。

二、容器日志的集中管理

日志的管理需求由来已久，无论是传统遗留系统，还是互联网应用或服务，日志在运维和运营中的作用不可小觑。尤其是现在被普遍采用的集中日志管理实践，对Docker的日志管理提出了新的要求。上面提到随着Docker的演进，Docker的logging已有所改善，增加了多种log driver的支持（比如syslog、fluentd等），为容器日志的集中管理方案提供了多样性。

目前国内很多企业采用ELK方案（当然ELK方案不仅仅局限于Docker了），即ElasticSearch + Logstash + Kibana，Logstash负责从各个节点收集、过滤、分析和处理日志，ElasticSearch负责存储、索引和查找日志；Kibana负责以图形化界面展示日志处理结果。但Docker Container如何做本地日志管理、如何将本地最新的日志输送给Logstash没有标准方案，你可以用fluentd agent也可以使用logspout。ELK方案中也有自己的用于客户端节点日志输送的工具，以前称为logstash-forwarder：

node1 (logstash-forwarder) ------>

node2 (logstash-forwarder) ------>   logstash server --> ElasticSearch

node3 (logstash-forwarder) ------>

现在Elastic.co使用beats系列产品替代logstash-forwarder，针对日志输送这块，对应的beats产品是filebeat，使用filebeat后，前面的集中日志方案结构就变成了：

node1 (filebeat) ------>

node2 (filebeat) ------>   [logstash server] --> ElasticSearch

node3 (filebeat) ------>

我们看到logstash server是一个可选的中间环节，使用filebeat后，你可以将client node上的最新日志直接发送给ElasticSearch，而无需经过logstash这一环节。当然如果你对源日志有过滤、清洗、分析等需求时，logstash依旧是你的得力助手。这里我们暂不用logstash，而是直接将日志发给ElasticSearch做存储和索引。

三、使用Filebeat输出容器日志的步骤

测试环境示意图如下：（ubuntu 14.04 + docker 1.9.1)

node1 (10.10.126.101 nginx container +  filebeat) ------>   server 10.10.105.71 (ElasticSearch + kibana)

这里的所有程序均以容器形式安装和运行。

1、安装elasticsearch和kibana

elasticsearch和kibana都有官方Docker image。

安装elasticsearch：

$ docker pull elasticsearch
Using default tag: latest
latest: Pulling from library/elasticsearch
...

执行env，查看版本：

$ docker exec  elasticsearch env

... ...
ELASTICSEARCH_MAJOR=2.2
ELASTICSEARCH_VERSION=2.2.1
ELASTICSEARCH_REPO_BASE=http://packages.elasticsearch.org/elasticsearch/2.x/debian
... ...

安装kibana：

$ docker pull kibana
Using default tag: latest
latest: Pulling from library/kibana
... ...

我们查看一下当前images列表：

REPOSITORY                             TAG                 IMAGE ID            CREATED             VIRTUAL SIZE
elasticsearch                          latest              c6b6bed19c45        8 days ago          347.1 MB
kibana                                 latest              d2c9c3cfc682        12 days ago         295.4 MB
... ...

2、启动es和kibana，验证服务启动ok

启动ES:

$ sudo mkdir -p /data/elasticsearch
$  docker run -d --name elasticsearch -p 9200:9200 -v /data/elasticsearch:/usr/share/elasticsearch/data elasticsearch
4288b4db18af8575961faf940a1dc634fe30857bb184fb45611136b7bd3ffb7d

查看服务启动情况：

$ docker ps
CONTAINER ID        IMAGE               COMMAND                  CREATED             STATUS              PORTS                              NAMES
4288b4db18af        elasticsearch       "/docker-entrypoint.s"   21 seconds ago      Up 10 seconds       0.0.0.0:9200->9200/tcp, 9300/tcp   elasticsearch

启动日志如下：

$ docker logs elasticsearch
[2016-03-24 11:00:29,289][INFO ][node                     ] [Katherine Reynolds] version[2.2.1], pid[1], build[d045fc2/2016-03-09T09:38:54Z]
[2016-03-24 11:00:29,291][INFO ][node                     ] [Katherine Reynolds] initializing ...
[2016-03-24 11:00:29,863][INFO ][plugins                  ] [Katherine Reynolds] modules [lang-expression, lang-groovy], plugins [], sites []
[2016-03-24 11:00:29,894][INFO ][env                      ] [Katherine Reynolds] using [1] data paths, mounts [[/usr/share/elasticsearch/data (/dev/disk/by-uuid/f577c0bc-665b-431b-96e0-e3536dc11469)]], net usable_space [114.5gb], net total_space [130.4gb], spins? [possibly], types [ext4]
[2016-03-24 11:00:29,894][INFO ][env                      ] [Katherine Reynolds] heap size [990.7mb], compressed ordinary object pointers [true]
[2016-03-24 11:00:31,881][INFO ][node                     ] [Katherine Reynolds] initialized
[2016-03-24 11:00:31,881][INFO ][node                     ] [Katherine Reynolds] starting ...
[2016-03-24 11:00:31,993][INFO ][transport                ] [Katherine Reynolds] publish_address {172.17.0.1:9300}, bound_addresses {[::]:9300}
[2016-03-24 11:00:32,004][INFO ][discovery                ] [Katherine Reynolds] elasticsearch/D7hV_RcHQa275Xc7if1Kkg
[2016-03-24 11:00:35,058][INFO ][cluster.service          ] [Katherine Reynolds] new_master {Katherine Reynolds}{D7hV_RcHQa275Xc7if1Kkg}{172.17.0.1}{172.17.0.1:9300}, reason: zen-disco-join(elected_as_master, [0] joins received)
[2016-03-24 11:00:35,075][INFO ][http                     ] [Katherine Reynolds] publish_address {172.17.0.1:9200}, bound_addresses {[::]:9200}
[2016-03-24 11:00:35,076][INFO ][node                     ] [Katherine Reynolds] started
[2016-03-24 11:00:35,144][INFO ][gateway                  ] [Katherine Reynolds] recovered [0] indices into cluster_state

启动kibana：

启动kibana容器需要提供一个环境变量参数，即ES的服务地址和端口：

$docker run -d --name kibana -e ELASTICSEARCH_URL="http://10.10.105.72:9200"  -p 5601:5601 kibana

要验证kibana是否启动ok，可以通过浏览器打开：http://10.10.105.72:5601，如果web页面正常显示，并且http://10.10.105.72:5601/status页面中有”Status: Green”字样，说明Kibana启动ok了。

3、安装和配置filebeat

在安装filebeat前，我们先启动一个测试用webserver，部署在10.10.126.101上，用于产生日志数据：

$ docker run -d --log-driver=json-file --log-opt max-size=1k --log-opt max-file=5 --name webserver -p 9988:80 nginx
50f100e7ea4d5b4931f144f9eac12b6a05e56579583d7a0322b250004b68ae72

Filebeat没有官方image版本，docker hub上star数量最多的是prima/filebeat这个库中的image，我们就打算使用这个了，pull过程这里就不赘述了：

$docker run --rm prima/filebeat env
... ...
FILEBEAT_VERSION=1.1.2
... ...

可以看到这个库中的filebeat image使用的filebeat版本是最新的。

我们接下来来看run：

$ docker run --rm prima/filebeat
Loading config file error: Failed to read /filebeat.yml: open /filebeat.yml: no such file or directory. Exiting.

看来Filebeat需要做一些配置，我们得来查看一下Filebeat的官方manual。

Filebeat需要一个filebeat.yml配置文件，用于配置log来源以及log输送的目的地，我们参考manual给出一个适合我们的配置：

filebeat:
  # List of prospectors to fetch data.
  prospectors:
    # Each - is a prospector. Below are the prospector specific configurations
    -
      # Paths that should be crawled and fetched. Glob based paths.
      # For each file found under this path, a harvester is started.
      paths:
          - "/var/lib/docker/containers/*/*.log"
        #- c:\programdata\elasticsearch\logs\*

      # Type of the files. Based on this the way the file is read is decided.
      # The different types cannot be mixed in one prospector
      #
      # Possible options are:
      # * log: Reads every line of the log file (default)
      # * stdin: Reads the standard in
      input_type: log

# Configure what outputs to use when sending the data collected by the beat.
# Multiple outputs may be used.
output:
  ### Elasticsearch as output
  elasticsearch:
    # Array of hosts to connect to.
    hosts: ["10.10.105.72:9200"]

我们采集/var/lib/docker/containers/*/*.log，即filebeat所在节点的所有容器的日志。输出的位置是我们ElasticSearch的服务地址，这里我们直接将log输送给ES，而不通过Logstash中转。

再启动之前，我们还需要向ES提交一个filebeat index template，以便让Es知道filebeat输出的日志数据都包含哪些属性和字段。filebeat.template.json这个模板文件不用我们编写，filebeat官方提供，我们可以在github.com上找到它。

加载这个模板到ES:

$ curl -XPUT 'http://10.10.105.72:9200/_template/filebeat?pretty' -d@/home1/tonybai/filebeat.template.json
{
  "acknowledged" : true
}

如果看到curl的返回结果是true，那么说明加载ok了。

接下来，我们启动filebeat容器：

$ docker run -d --name filebeat -v /home1/tonybai/filebeat.yml:/filebeat.yml prima/filebeat
f93497ea816e5c4015e69376f98e791ca02b91a20145ee1366e4c15f6a706c10

我们到Kibana中看看是否能收到容器的日志。使用Kibana时，需要添加一个新的index pattern。按照manual中的要求，对于filebeat输送的日志，我们的index name or pattern应该填写为：”filebeat-“，不过我在kibana中添加default index ：filebeat- 一直失败，下面那个按钮一直是灰色的，并提示：“Unable to fetch mapping. Do you have indices matching the pattern”。

在filebeat的forum中找寻问题答案，有人提示：看看ElasticSearch中是否有filebeat传输来的日志。于是查看ElasticSearch日志以及通过ElasticSearch提供的API做了一番查询，发现filebeat根本没有日志传输过来。

回过头仔细想来，wow，居然没给filebeat容器挂在/var/lib/docker/containers目录，那么filebeat就没有权限访问容器日志，自然不会有日志传输到ES了，下面的输出也证实了这一点：

$ docker exec filebeat ls /var/lib/docker/containers
ls: cannot access /var/lib/docker/containers: No such file or directory

于是修改filebeat启动参数：

$docker run -d  --name filebeat -v /home1/tonybai/filebeat.yml:/filebeat.yml -v /var/lib/docker/containers:/var/lib/docker/containers prima/filebeat

一段时间后，我们就可以在Kibana上成功创建filebeat-* index pattern并看到filebeat输送过来的日志了。

这是一个Web Server的时代，apache2与nginx共舞，在追求极致性能的路上，没有最高，只有更高。但这又是一个追求个性化的时代，有些Web Server并没有去挤“Performance提升”这一独木桥，而是有着自己的定位，Caddy就是这样一个开源Web Server。

Caddy的作者Matt Holt在caddy官网以及FAQ中对caddy的目标阐释如下： 其他Web Server为Web而设计，Caddy为human设计。功能定位上，与经常充当最前端反向代理的nginx不同，caddy致力于成为一个易用的静态 文件Web Server。可以看出Caddy主打易用性，使用配置简单。并且得益于Go的跨平台特性，caddy很容易的支持了三大主流平台:Windows、 Linux、Mac。在Caddy开发者文档中，我们可以看到caddy还可以在Android(linux arm)上运行。caddy目前版本为0.7.1，还不稳定，且后续版本可能变化较大，甚至与前期版本不兼容，因此作者目前不推荐caddy在生产环境被 重度使用。

关注caddy，是因为caddy填补了go在通用web server这块的空白(也许有其他，但我还不知道)，同时Web server in go也“响应”了近期Golang去C化的趋势(Go 1.5中C is gone！)，即便caddy作者提到caddy的目标并非如nginx那样。但未来谁知道呢？一旦Go性能足够高时，一旦caddy足够稳定时，自然而 然的就会有人将其用在某些应用的生产环境中替代nginx或apache2了。一套全Go的系统，在部署、运维方面也是有优势的。

一、安装和运行caddy

和诸多go应用一样，我们可以直接从caddy的github.com releases页中找到最新发布版(目前是0.7.1)的二进制包。这里使用的是caddy_darwin_amd64.zip。

下载解压后，进入目录，直接执行./caddy即可将caddy运行起来。

$caddy
0.0.0.0:2015

在浏览器里访问localhost:2015，页面上没有预期显示的类似"caddy works!”之类的默认Welcome页面，而是“404 Not Found"。虽然这说明caddy已经work了，但没有一个default welcome page毕竟对于caddy beginer来说并不友好。这里已经向作者提了一个sugguestion issue。

二、caddy原理

Go的net/http标准库已经提供了http server的实现，大多数场合这个http server都能满足你的需要，无论是功能还是性能。Caddy实质上也是一个Go web app，它也import net/http，嵌入*http.Server，并通过handler的ServeHTTP方法为每个请求提供服务。caddy使用 http.FileServer作为处理 静态文件的基础。caddy的诱人之处在于其middleware，将诸多middleware串成一个middleware chain以提供了灵活的web服务。另外caddy中的middleware还可以独立于caddy之外使用。

caddy从当前目录的Caddyfile（默认）文件中读取配置，当然你也可以通过-conf指定配置文件路径。Caddyfile的配置格式 的确非常easy，这也符合caddy的目标。

Caddyfile总是以站点的Addr开始的。

单一站点的Caddyfile样例如下：

//Caddyfile
localhost:2015
gzip
log ./2015.log

Caddy也支持配置多个站点,类似virtualhost的 配置(80端口多路复用)：

//Caddyfile
foo.com:80 {
    log ./foo.log
    gzip
}

bar.com:80 {
    log ./bar.log
    gzip
}

为了实现风格上的统一，单一站点也最好配置为如下这种格式(代码内部称之为    Server Block)：

localhost:2015 {
    gzip
    log ./2015.log
}

这样Caddyfile的配置文件模板样式类似于下面这样：

host1:port {
    middleware1
    middleware2 {
        … …
    }
    … …
}

host2:port {
    middleware1
    middleware2 {
        … …
    }
    … …
}
… …

关于middleware，在caddy文档中有较为详细的说明和例子。对于caddy这样一个年轻的开源项目而言，其文档还算是相对较全的，虽 然现在还不能和nginx、 apache比。

caddy中的middleware就是一个实现了middleware.Handler接口的struct，例如gzip这个 middleware:

// middleware.go
type Middleware func(Handler) Handler
type Handler interface {
        ServeHTTP(http.ResponseWriter, *http.Request) (int, error)
}

// gzip/gzip.go
type Gzip struct {
    Next middleware.Handler
}

func (g Gzip) ServeHTTP(w http.ResponseWriter, r *http.Request) (int, error) {
    if !strings.Contains(r.Header.Get("Accept-Encoding"), "gzip") {
        return g.Next.ServeHTTP(w, r)
    }
    …. …
    gz := gzipResponseWriter{Writer: gzipWriter, ResponseWriter: w}

    // Any response in forward middleware will now be compressed
    status, err := g.Next.ServeHTTP(gz, r)
    … …
}

middleware.Handler的函数原型与http.Handler的不同，不能直接作为http.Server的Handler使用。caddy使用了下面这个idiomatic go pattern:

type appHandler func(http.ResponseWriter, *http.Request) (int, error)

func (fn appHandler) ServeHTTP(w http.ResponseWriter, r *http.Request) {
    if status, err := fn(w, r); err != nil {
        http.Error(w, err.Error(), status)
    }
}
当然这个pattern有很多变种，但思路大致类似。一个middleware chain大致就是handler1(handler2(handler3))的调用传递。

前面说过caddy是基于http.FileServer的静态文件Web Server，FileServer总会作为middleware chain的最后一环，如果没有配置任何middleware，那你的server就是一个静态文件server。

三、caddy典型应用

【静态文件Server】

caddy的最基础应用实际就是一个静态文件Server，底层由http.FileServer承载，当然caddy封装了http.FileServer，做了一些拦截处理，最后将w, r传递给http.ServeContent去处理文件数据。

第一次执行./caddy，实际上就启动了一个静态文件Server。但这个server不默认支持你navigate directory。如果你知道website root目录(如果没有指定root，则caddy执行的当前路径会作为website的root路径)下的文件名，比如foo.txt，你可以在浏览器 中输入：localhost:2015/foo.txt，caddy会执行正确的服务，浏览器也会显示foo.txt的全文。

对于静态文件Server，caddy支持在website的root路径下首先查找是否有如下四个文件：

//caddy/middleware/browse/browse.go
var IndexPages = []string{
    "index.html",
    "index.htm",
    "default.html",
    "default.htm",
}

如果查到有其中一个，则优先返回这个文件内容，这就是静态站点的首页。

如果要支持目录文件列表浏览，则需要为website配置browse middleware，这样对于无index file的目录，我们可以看到目录文件列表。

localhost:2015 {
    browse
}   

【反向代理】

caddy支持基本的反向代理功能。反向代理配置通过proxy middleware实现。

localhost:2015 {
    log ./2015.log

    proxy /foo localhost:9001
    proxy /bar localhost:9002
}

当你访问localhost:2015/foo时，实际上访问的是9001端口的服务程序；
当你访问localhost:2015/bar时，实际上访问的是9002端口的服务程序。

【负载均衡】

Caddy支持负载均衡配置，并支持三种负载均衡算法：random（随机）、least_conn（最少连接）以及round_robin(轮询调度)。

负载均衡同样是通过proxy middleware实现的。

localhost:2015 {
    log ./2015.log

    proxy / localhost:9001 localhost:9003 {
        policy round_robin
    }
    proxy /bar localhost:9002 localhost:9004 {
        policy least_conn
    }
}

【支持fastcgi代理】

caddy同样支持fastcgi代理，可以将请求通过fastcgi接口发送给后端的实现fastcgi的server。我们以一个"hello world"的php server为例。

mac os上自带了php-fpm，一个实现了fastcgi的php cgi进程管理器。caddy将请求转发给php-fpm监听的端口，后者会启动php-cgi解释器，解释index.php，并将结果返回给caddy。

mac os上的php-fpm默认没有随机启动。我们需要简单配置一下：

$mkdir phptest
$mkdir -p phptest/etc
$mkdir -p phptest/log
$cd phptest
$sudo cp /private/etc/php-fpm.conf.default ./etc
$cd ./etc
$sudo chown tony php-fpm.conf.default
$mv php-fpm.conf.default php-fpm.conf

编辑php-fpm.conf，保证下面两项是非注释状态的：

error_log = log/php-fpm.log
listen = 127.0.0.1:9000 

我们通过network socket进行fastcgi通信。

回到phptest目录下，执行:

php-fpm -p ~/test/go/caddy/phptest

执行后，php-fpm就会转入后台执行了。

接下来我们来配置Caddyfile：

localhost:2015 {
    fastcgi / 127.0.0.1:9000 php
    log ./2015.log
}

这里配置的含义是：将全部请求转发到9000端口，这里的php是一个preset（预配置集合），相当于：

ext   .php
split .php
index index.php

我们在phptest目录下创建一个index.php文件，内容如下：

<?php echo "Hello World\n"; ?>

好了，现在启动caddy，并使用浏览器访问localhost:2015试试。你会看到"Hello World"呈现在浏览器中。

【git push发布】

对于一些静态站点，caddy支持git directive，实现在server启动以及运行时定期git pull你的项目库，将最新更新pull到server上。

caddy文档中给出两个例子：

第一个是一个php站点，定期pull项目库，实现server更新：

git git@github.com:user/myphpsite {
    key /home/user/.ssh/id_rsa
}
fastcgi / 127.0.0.1:9000 php

第二个是一个hugo支撑的静态站点，每次pull后，执行hugo命令生成新的静态页面：

git github.com/user/site {
    path  ../
    then  hugo –destination=/home/user/hugosite/public
}

注意：git directive并非middleware，而是一个单独的goroutine实现的。

四、小结

caddy的功能不局限于上面的几个例子，上面只是几个最为常见的场景而已。caddy目前还很年轻，应用不多，但知名golang网站 gopheracademy.com（GopherCon组织方）是由Caddy support的。caddy还在积极进化，有兴趣的Gopher可持续关注。