1. 为什么要分析日志
传统的Web开发中，日志可能并不被重视，只有应用出现问题后，才会适时性的去看一眼。而且日志的储存方式也很简单，直接写入一个文本文件或者扔到数据库中就了事了。这样对于单机应用来说没有什么不可以的，可是当系统架构分布式后，官网、论坛、社交、交易等各个大大小小的子系统越来越多，再加上操作系统、应用服务、业务逻辑等等，日志的管理与查看就越发的麻烦，面对大量的日志数据而且又是分布在各个不同的机器甚至不同的机房，如果我们还是按照传统的方式登录到某一台机器上去查看日志，然后再汇总起来，再做个跨机房的排序，那这样感觉就太糟糕了。所以一套集中式的实时日志分析平台就显得非常重要了，而一套日志分析平台至少要包括一下几个特点：
- 收集, 可以收集不同来源的日志，包括Web日志，请求日志，本地机器，跨机房机器等
- 存储，稳定的存储日志信息并索引起来
- 分析，支持各种层面的分析，而且可以以UI展示出来
- 警告，根据日志内容进行不同错误级别的报警
2. ELK协议栈
其实市面上的日志分析产品很多，简单的Rsyslog，商业化的Splunk，开源的Scribe，Apache的Flume，Cloudera 的ELK。这里采用的是ELK这个体系架构，ELK(Elasticsearch, Logstash, Kibana)经过这么多年的发展，一直到现在的6.0.0版本。能够发展这么快，其中肯定有他的原因所在。简单介绍一下这三个软件的特点：
- Elasticsearch 高可用性，实时索引，拓展简单，接口友好
- Logstash 是一个具有实时的数据收集引擎，几乎可以收集所有的数据
- Kibana 提供分析和可视化的
Web平台，用来查询分析以及生成各种报表
通过架构图可以看到，整体日志平台的原理其实并不难，日志的生产者作为Shipper产生各种各样的日志，然后传输到Kafka中，这里传输也是从生产者中读取然后传输通过 Logstash 到 Kafka， 再者Logstash通过读取Kafka中的日志数据，储存到ElasticSearch。只在中间再增加了Kafka做为缓冲层，因为Logstash会同步把日志传输到Elasticsearch，一旦ElasticSearch挂掉数据就有可能会丢失。于是，我们考虑利用Kafka作为缓冲区。
这里选择
Kafka的原因是因为与大多数消息系统比较，Kafka有更好的吞吐量，内置分区，副本和故障转移，这有利于处理大规模的消息，因为互联网应用日志基本上都是海量的。
3.基于Docker
Docker算是云计算时代拥有划时代意义的项目了，关于Docker的介绍与资料非常多。特别是docker-compose相当于给Docker插上了翅膀。Docker相对于传统的虚拟化技术，Docker应用运行于宿主内核，无需启动完整的操作系统，可以做到秒级、甚至毫秒级的启动时间，大大的节约了开发、测试、部署的时间。并且确保了运行环境的一致，「这段代码在我机器上没问题啊」这一些的问题再也不会出现。
