微服务(SOP)日志管理

问题:


  大型企业应用规模大,调试 / 解决问题由于在生产环境中不会有开发环境的调试工具,如果需要模拟还原当时的环境,

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

  日志记录的常用方式:

解决:


  ELK Stack 是 Elasticsearch、Logstash、Kibana 三个开源软件的组合。

  和传统的日志处理方案相比,ELK Stack 具有如下几个优点:

  •   处理方式灵活。Elasticsearch 是实时全文索引,不需要像 storm 那样预先编程才能使用;
  •   配置简易上手。Elasticsearch 全部采用 JSON 接口,Logstash 是 Ruby DSL 设计,都是目前业界最通用的配置语法设计;
  •   检索性能高效。虽然每次查询都是实时计算,但是优秀的设计和实现基本可以达到全天数据查询的秒级响应;
  •   集群线性扩展。不管是 Elasticsearch 集群还是 Logstash 集群都是可以线性扩展的;

  传统的日志收集方案有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命令是看不到的。对用户而言,可以根据实际的应用产品,对这两种方式进行选择。

上一篇:ORB-SLAM(六)回环检测


下一篇:『学了就忘』Linux日志管理 — 91、日志服务rsyslogd说明