微服务（SOP）日志管理

问题：

---

　　大型企业应用规模大，调试 / 解决问题因为在生产环境中不会有开发环境的调试工具，若是须要模拟还原当时的环境，

目前的解决办法是进行日志记录

　　日志记录的经常使用方式：

• 使用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命令是看不到的。对用户而言，能够根据实际的应用产品，对这两种方式进行选择。