容器内应用日志收集方案

容器化应用日志收集挑战

应用日志的收集、分析和监控是平常运维工做重要的部分，妥善地处理应用日志收集每每是应用容器化重要的一个课题。

Docker处理日志的方法是经过docker engine捕捉每个容器进程的STDOUT和STDERR，经过为contrainer制定不一样log driver 来实现容器日志的收集，缺省json-file log driver是将容器的STDOUT/STDERR 输出保存在磁盘上，而后用户就能使用docker logs <container>来进行查询。

在部署一个传统的应用的时候，应用程序记录日志的方式一般记录到文件里， 通常（但不必定）会记录到/var/log目录下。应用容器化后，不一样于以往将全部日志放在主机系统的统一位置，日志分散在不少不一样容器的相互隔离的环境中。

如何收集应用写在容器内日志记录，有如下挑战：

1) 资源消耗

若是在每一个容器运行一个日志收集进程， 好比logstatsh/fluentd 这类的日志工具，在主机容器密度高的时候，logstatsh/fluentd这类日志采集工具会消耗大量的系统资源。上面这种方法是最简单直观的，也是最消耗资源的。

2) 应用侵入

一些传统应用，特别是legacy 系统，写日志机制每每是无法配置和更改的，包括应用日志的格式，存放地址等等。日志采集机制，要尽可能避免要求修改应用。

3) 日志来源识别

采用统一应用日志收集方案，日志分散在不少不一样容器的相互隔离的环境中，须要解决日志的来源识别问题。

日志来源识别的功能借助了rancher平台为container_name的命名的规则特性，能够作到即便一个容器在运行过程当中被调度到另一台主机，也能够识别日志来源。

容器化应用日志收集方案

下面是咱们设计的一个低资源资源消耗、无应用侵入、能够清楚识别日志来源的统一日志收集方案，该方案已经在睿云智合的客户有成功实施案例。

在该方案中，会在每一个host 部署一个wise2c-logger，wise2C会listen docker engine的event，当有新容器建立和销毁时，会去判断是否有和日志相关的local volume 被建立或者销毁了，根据lables，wise2c-logger 会动态配置logstatsh的input、filter 和output，实现应用日志的收集和分发。

1） 应用如何配置

应用容器化时候，须要在为应用容器挂载一个专门写有日志的volume，为了区别该volume 和容器其它数据volume，咱们把该volume 定义在容器中，经过volume_from 指令share 给应用容器，下面是一个例子：demo应用的docker-compose file

web-data 容器使用一个local volume，mount到/var/log目录(也能够是其它目录)，在web-data中定义了几个标签， io.wise2c.logtype说明这个容器中包含了日志目录，标签里面的值elasticsearch、kafka能够用于指明log的output或者过滤条件等。

那么咱们如今来看下wiselogger大体的工做流程：

监听新的日志容器->获取日志容器的type和本地目录->生成新的logstash配置：

1）wise2c-looger 侦听docker events 事件， 检查是否有一个日志容器建立或者被销毁；

2）当日志容器被建立后（经过container label 判断）, inspect 容器的volume 在主机的path；

3）从新配置wise2c-logger 内置的logstatsh 的配置文件，设置新的input, filter 和output 规则。

这里是把wise2c-logger在rancher平台上作成catalog须要的docker-compose.yml的截图，你们能够配合上面的流程描述一块儿看一下。

优化

目前咱们还在对Wise2C-logger 做进一步的优化：

1）收集容器的STDOUT/STDERR日志

特别是对default 使用json-file driver的容器，经过扫描容器主机的json-file 目录，实现容器STDIN/STDERR日志的收集。

2）更多的内置日志收集方案

目前内置缺省使用logstatsh 做日志的收集，和过滤和一些简单的转码逻辑。将来wise2C-logger 能够支持一些更轻量级的日志收集方案，好比fluentd、filebeat等。

Q & A

Q：有没有作过性能测试？我这边模块的日志吞吐量比较大。好比在多少许级的日志输出量基础上，主要为logger模块预留多少系统资源，保证其正常稳定工做？

A：没有作过很强的压力，可是咱们如今正常使用倒没碰上过性能上的瓶颈。咱们如今没有对logger作资源限制，可是能占用300～400M内存，由于有logstash的缘由。

Q：「生成日志容器」是指每一个应用容器要对应一个日志容器？这样资源消耗不会更大吗？k8s那种日志采集性能消耗会比这样每一个应用容器对应一个日志容器高么？

A：是指每一个应用容器对应一个日志容器。虽然每一个应用有一个日志容器，可是，日志容器是start once的，不会占用运行时资源。

Q：你说的start once是什么意思？我说占资源是大量日志来的时候，那么多日志容器要消耗大量io的吧，CPU使用率会上升，不会影响应用容器使用CPU么？

A：不会，日志容器只生成一下，不会持续运行。

Q：怎么去监听local volume？

A：能够监听文件目录，也能够定时请求docker daemon。

Q：直接用syslog driver，能作到对应用无侵入么？

A：启动容器的时候 注明使用Syslog driver的参数便可，这样几乎没有额外资源占用。

Q：这种方案是否是要保证应用容器日志要输出到/var/log下啊？

A：不是，能够随意定义，logstah能够抓syslog。

Q：syslog driver能收集容器内的日志文件么？容器内不一样流向的日志能区分么？

A：容器内应用的本地日志syslog能够收集，分流一样能够完成，可是容器内的本地日志这个我我的以为跟容器环境下的应用无本地化、无状态化相悖吧。

Q：最后你说到，从新配置logstash中配置文件，看上去感受你又是经过wiselog这个容器去采集全部日志的？只不过是动态配置logstash里面参数。

A：是的，如今收集工做是logstash来完成的，单纯的文件收集，可选的方案还挺多的，也没有必要再造轮子了。

Q：那这个方案其实有个疑问，为何不学k8s那种，直接固定那目录，经过正则表达式去采集日志文件，而要动态这么作？有什么好处吗？目前我感受这两套方案几乎同样。

A：为了减小对应用的侵入。由于不少用户的现有系统不能再修改了，这样作也是为了减小用户现有程序的修改，为了最重要的“兼容现有”。

Q：除了kibana还有没别的可视化方案？

A：针对es来讲，尚未别的更好的方案。

Q：若是是挂载log目录，logstash就能够去宿主机收集了，还须要别的插件作什么？

A：经过容器能够识别出来这个应用的业务上的逻辑，能够拿到service名称。

Q：有的应用输出的log名都是同样的，不会有冲突吗，好比我启动2个容器在一个宿主机上，都往xx.log里写入会有问题。

A：不会，给每个应用容器配一个日志卷容器就能够解决这个问题。这个问题也是咱们出方案时一个棘手的问题。因此这个方案的一个好处就是，每个应用的均可以随意设置日志目录，不用考虑和别的应用冲突，也不会和同宿主机同一应用冲突。

Q：上次听别人说所有把日志扔到标准输出里，不知道靠谱不？

A：有人报过这种处理方式，日志量大时，docker daemon会崩溃。