fluent.conf的配置文件由于保密关系就不贴了，收集后的一条数据如下：
{ "_fileName":"/data/work/logs/xxx_2019-05-22-0.log", "_sortedId":"660c2ce8-aacc-42c4-80d1-d3f6d4c071ea", "_collectTime":"2019-05-22 17:23:58", "_log":"[33m2019-05-22 17:23:58[0;39m |[34mINFO [0;39m |[34mmain[0;39m |[34mSpringApplication.java:679[0;39m |[32mcom.hqyg.epaas.EpaasPortalApplication[0;39m | The following profiles are active: dev", "_domain":"namespace", "_ip":"10.128.93.31", "_podName":"xxxx-5679849765-gncbf", "_hostName":"dev4.gcloud.set" } 四、总结总的来说，daemonset方式比较简单，而且适合更加适合微服务化，当然，不是完美的，比如业务方想把业务日志打到控制台上，但是同时也想知道jvm的日志，这种情况下或许sidecar模式更好。但是sidecar也有不完美的地方，每个pod里都要存在一个日志收集的agent实在是太消耗资源了，而且很多问题也难以解决，比如：主容器挂了，agent还没收集完，就把它给kill掉，这个时候日志怎么处理，业务会不会受到要杀掉才能启动新的这一短暂过程的影响等。所以，我们实际使用中首选daemonset方式，但是提供了sidecar模式让用户选择。
参考：
1.Kubernetes日志官方文档
2.Kubernetes日志采集Sidecar模式介绍
3.Docker日志收集最佳实践