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会崩溃。
2/2 首页 上一页 1 2
