问题：
大型企业应用规模大，调试 / 解决问题由于在生产环境中不会有开发环境的调试工具，如果需要模拟还原当时的环境，
目前的解决办法是进行日志记录
日志记录的常用方式：
- 使用SpringAop进行切入，有针对性的对关键操作进行记录【http://www.cnblogs.com/hackxiyu/p/8072314.html】
- 使用ELK工具进行集中式日志管理
解决：
参考文章：基于微服务的日志系统【http://www.fx361.com/page/2017/0315/1185754.shtml】
ELK Stack 是 Elasticsearch、Logstash、Kibana 三个开源软件的组合。
和传统的日志处理方案相比，ELK Stack 具有如下几个优点：
- 处理方式灵活。Elasticsearch 是实时全文索引，不需要像 storm 那样预先编程才能使用；
- 配置简易上手。Elasticsearch 全部采用 JSON 接口，Logstash 是 Ruby DSL 设计，都是目前业界最通用的配置语法设计；
- 检索性能高效。虽然每次查询都是实时计算，但是优秀的设计和实现基本可以达到全天数据查询的秒级响应；
- 集群线性扩展。不管是 Elasticsearch 集群还是 Logstash 集群都是可以线性扩展的；
参考文章：微服务的性能监控与日志收集【https://baijia.baidu.com/s?old_id=478661】
传统的日志收集方案有Splunk、Logstash、Flume、Fluentd等，其中Splunk和Fluentd被列入了Docker官方文档里。Fluentd是一个出来时间不长，但是对传统收集工具 Logstash挑战比较大的收集方案，同时它也在去年被亚马逊评为最好的日志收集工具。Splunk则是一套基于商业的解决方案，一般只有大型企业才会使用，这种方案是目前最好的，但也是最昂贵的。
在其他方案中，传统的解决方案最常见的是Logstash，它的配合工具一般是Elasticsearch和Kibana。图2是一张经典的ELK架构图，首先在每一个节点上部署一个Logstash数据端，称为shipper，然后搭一个redis的缓存，在redis缓存后面再用另一个Logstash去做索引，称为indexer。之所以有这样一个架构是因为Logstash本身运行效率率比较低，用的是JRuby语言，它使得索引不能在每一个客户端去做，因为会占用很大的的内存。
Fluentd的方案与Logstash差不多，但是它可以省掉Indexer这层，而且它的核心代码是C++写的，从效率上说会比Logstash高很多。除此之外，Fluentd是除了Splunk以外唯一一个在Docker官方日志驱动里面的工具。一般来说,日志收集是通过收集文件的方式进行的，因为Docker会默认将容器的日志放到一个指定的目录里。Logstash会去搜集目录里面的日志，但是存在一个问题，就是Logstash在搜集的时候是每隔一定的时间在目录里面做一次查询，这样很可能因为监测的服务出故障造成日志丢失。Fluentd则不仅支持Logstash那种文件的方式去搜集日志，还可以通过Docker的Fluentd driver直接定向搜集，但是搜集的日志Docker log命令是看不到的。对用户而言，可以根据实际的应用产品，对这两种方式进行选择。