浅谈下，如标题这个问题：
随着大数据被不停的挖掘，每天有态度的人利用用户数据信息，产生巨大的商业价值，以及风险告警，在筹建大数据分析系统时，大家都很热衷新的东西，在做公司架构体系时，动不动就直接上新的技术，导致项目夭折，最后走人换公司的局面，后来不断的有人去填坑。
随着Splunk 的声势浩大，导致目前公司采用起来的成本太高，所以选择方案的时候需要均衡发展，达到良性可伸缩的系统框架。
采用ELK框架进行日志分析系统构建：
ELK是Elasticsearch、Logstash、Kibana的简称，这三者是核心套件
- Elasticsearch是实时全文搜索和分析引擎，提供搜集、分析、存储数据三大功能；是一套开放REST和JAVA API等结构提供高效搜索功能，可扩展的分布式系统。它构建于Apache Lucene搜索引擎库之上。
- Logstash是一个用来搜集、分析、过滤日志的工具。它支持几乎任何类型的日志，包括系统日志、错误日志和自定义应用程序日志。它可以从许多来源接收日志，这些来源包括 syslog、消息传递（例如 RabbitMQ）和JMX，它能够以多种方式输出数据，包括电子邮件、websockets和Elasticsearch。
- Kibana是一个基于Web的图形界面，用于搜索、分析和可视化存储在 Elasticsearch指标中的日志数据。它利用Elasticsearch的REST接口来检索数据，不仅允许用户创建他们自己的数据的定制仪表板视图，还允许他们以特殊的方式查询和过滤数据。
这种架构、验证依赖、缺点是Logstash耗资源较大，运行占用CPU和内存高，严重依赖RabbitMQ消息队列缓存，存在丢失数据隐患，小型公司比较适合。
第二种架构、基于kafka 或者redis
Logstash中心节点和Elasticsearch节点都需要采用集群节点，做相应的负载均衡，缓解服务器压力，此方案适用于大型架构、虽然引用了消息队列机制，Logstash占用系统资源过度，需要庞大的集群做支撑，建议对不同应用类型的数据进行分类展示，避免大面积分析系统不可用。
为了很好的缓解logstash占用系统过多的问题，将Logstash-forwarder替换为Beats
Beats 平台是 Elastic.co 从 packetbeat 发展出来的数据收集器系统。beat 收集器可以直接写入 Elasticsearch，也可以传输给 Logstash。其中抽象出来的 libbeat，提供了统一的数据发送方法，输入配置解析，日志记录框架等功能。
目前这种方案很多公司都在此基础上做二次开发。
在海量日志系统的运维中，以下几个方面是必不可少的：
- 分布式日志数据集中式查询和管理
- 系统监控，包含系统硬件和应用各个组件的监控
- 故障排查
- 安全信息和事件管理
- 报表功能
怎么基于数据提升自我价值，为公司提供实时可靠的数据分析，让市场部掌控着市场，让营销部定点的做业务推广，从而实现技术价值，也实现这种方案的价值，发挥到极致。
根据庞大的应用日志可以分析出用户分布的位置、行为、动态、习惯等等。
