项目由来

　　（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，如需转载请自行联系原作者