项目由来
（1）开发人员不能登录线上服务器查看详细日志，经过运维周转费时费力
（2）日志数据分散在多个系统，难以查找与整合
（3）日志数据量巨大，查询速度太慢，无法满足需求
（4）无法全局掌控项目运行状况
（5）日志数据查询不够实时
（6）数据分析人员不会写代码，无法分析统计数据
（7）.........
框架里包含的组件
Logstash+Elasticsearch+Kibana（ELK）
Logstash：监控，过滤，收集日志。
Elasticsearch：存储日志,提供搜索功能。
kibana：提供web界面，支持查询，统计，和图表展现。
filebeat：轻量级的日志收集工具。
很多公司都采用该架构构建分布式日志系统，包括新浪微博，freewheel，畅捷通等
注意：在应用端收集日志时，建议用filebeat。
效果图
架构设计
（1）使用filebeat
架构设计1：filebeat(1.3)-->logstash(parse)-->es集群-->kibana--ngix
缺点：如果logstash出问题会导致filebeat收集的数据丢失
架构设计2：filebeat(1.3)-->logstash(parse)[loadbalance]-->es集群-->kibana--ngix
filebeat和>logstash耦合性太高
架构设计3：filebeat(1.3)（3台）-->redis-->logstash(parse)-->es集群-->kibana--ngix（可选） （我这里，目前为了学习，走这条线路）
里面redis是一个单线程的实例，redis单线程每秒处理能力一般是10W次左右。
架构设计4：filebeat(5.0)-->redis/kafka-->logstash(parse)-->es-->kibana--ngix
filebeat(1.3)不支持输出到kafka，5.x版本中支持输出到kafka
（2）不使用filebeat
logstash-->kafka-->logstash(parse)-->es-->kibana--ngix
里面kafka支持水平扩展，可以使用多分区，支持多线程并行执行。
在应用端收集日志的话，logstash比较重量级，性能消耗比filebeat大
（3）Filebeat用于日志收集和传输，相比Logstash更加轻量级和易部署，对系统资源开销更小。
后续贴图。
本文转自大数据躺过的坑博客园博客，原文链接：http://www.cnblogs.com/zlslch/p/6621794.html，如需转载请自行联系原作者