一、传统日志解决方案
在以前我们的应用日志一般由log4j输入到不同的文件中，比如info.log warn.log error.log。
然后当我们需要查看日志的时候，就需要登录服务器使用命令tail -fn 500 error.log进行查看。
二、微服务日志解决方案
近年来微服务越来越火爆，微服务虽然带来一些好处，但是也引入了日志收集的问题。一般来说，我们可能将服务部署在容器中，然后使用k8s进行编排。这样的话服务被部署到那个node我们是不知道的，我们也不可能登陆所有的服务器一一去查看日志。所以我们需要将日志收集并进行统一的存储和查看。k8s推荐使用EFK，对日志进行收集，存储，查看，现在我们就3种常见的日志解决方案进行讲解。
在Node部署logstash（Fluentd）
在容器中输出到控制台的日志，都会被以*-sjson.log的命名方式保存到宿主机的/var/lib/docker/containers/目录下，这就为我们这个日志采集提供了基础。
k8s推荐使用Fluentd Elasticsearch Kibana。
我们可以在每个node上面部署一个Fluentd，然后将日志收集转发到远端的ElasticSearch里保存起来供将来进行检索
好处： 1）一个宿主机只需要部署一个日志收集器可以是Fluentd也可以是logstash 2）不会对应用和pod有任何入侵性。
这个方案在社区里是最常用的一种
缺点： 1）应用日志必须输出到控制台，不然收集不到 2）一个log agent收集多个pod的日志，不好进行分类存储 3）容器停了，日志就清空了（需要验证一下）
当然我们也可以使用在将文件写在容器的某个目录，然后将该目录挂载到node中，然后使用ELk等去收集 缺点是：：日志文件占用磁盘空间
在pod新增日志收集容器sidecar，将应用日志重定向输出stdout和stderr
当我们的应用将日志输出到文件中的时候，我们只要登录容器中查看日志才能看到到的，使用kubect这种命令是看不到的，所以我们想办法将文件里面的日志，重定向到控制台输出。
我们可以在pod部署两个容器，一个是应用本身，一个是sidecar，应用将日志写入文件中，比如error.log， sidecar则负责将文件的日志转到控制台输出。这样的话我们就可以继续用上一个方案，统一收集，存储。
缺点： 1）由于pod里面的容器是共用Volume，所以这个方案性能损耗并不高，就是多占了点cpu，内存 2）磁盘浪费，保存了两份日志文件，一：容器中应用输出的日志文件，二：重定向输出到控制台，宿主机保存的日志
不到万不得已，一般不使用这个方案
在pod新增日志收集容器sidecar，将日志文件发送到远程存储
这个方案我们还是可以将应用的日志输出到文件中，然后在每个pod部署一个log-agent来收集日志，然后直接将日志文件发送到远程直接存储，不用输出到控制台。
这个log-agent可以是logstash，也可以是Fluentd，只是输出的源不再是控制台了，而是容器中的日志文件
优点： 1）部署简单，并且对宿主机非常友好 2）每一个pod都有一个单独的收集器，容易分类 缺点： 1）每一个pod都有一个单独的收集器，占用资源 2）日志没有输出到stdout上，所以你通过kubectl logs 是看不到日志
综上：：：建议使用方案一（官方推荐），方案二最好不要用。
