docker容器日志收集方案汇总评价总结

docker日志收集方案有太多，下面截图罗列docker官方给的日志收集方案（详细请转docker官方文档）。很多方案都不适合我们下面的系列文章没有说。

经过以下5篇博客的叙述简单说下docker容器日志采集方案

docker容器日志收集方案（方案一 filebeat+本地日志收集）

docker容器日志收集方案（方案二 filebeat+syslog本地日志收集）

docker容器日志收集方案（方案三 filebeat+journald本地日志收集）

docker容器日志收集方案（方案四，目前使用的方案）

docker容器日志收集方案（方案N，其他中间件传输方案）

docker日志收集方案基本归为两类：

1、本地存储

2、远程输出

由于docker的特殊性大部分采用的都是远程即时输出方案，比如阿里云，亚马逊云，都有自己的插件

各有优劣势，不过总体趋势肯定是远程即时传输方式，如果网络有压力，进行日志压缩传输。

---

本地存储然后在扫描传输实际上是把积压问题放在了虚拟机上面。这种方案是基于虚拟机时代虚拟化技术的方案

如果在容器内部放置日志扫描程序，首先会导致容器运行两个进程，这是docker官方不推荐的（https://docs.docker-cn.com/engine/admin/multi-service_container/），

会造成不必要的麻烦引起问题不便追查（黑盒），增加了使用难度。

---

其实我们还可以通过容器卷来吧日志输出到指定目录但是使用集群之后，

容器卷是建立在操作系统文件系统之上的，就需要针对卷做可移植操作，

同样是使用成本增加，因为如果使用的是docker集群要保证每台宿主机能访问相同的卷，

我们要做集中存储（集中存储我们数据库才有这个待遇啊！！！）

---

对于docker容器虚拟化技术有几个特点

1、容器在集群宿主之间会漂移，每漂移一次容器ID会变更，所以跟着容器相关都会换掉，当然给容器起的名字不会换掉，不过那只是在集群中标记（更直白的说这个名字是存储在第三方键值对进行对应的是docker引擎维护的）。

2、容器是黑盒封闭性的，把日志先输出到容器内部不符合新一代容器技术的理念，处理不好会造成大量垃圾文件。