浅谈下,如标题这个问题:web
随着大数据被不停的挖掘,天天有态度的人利用用户数据信息,产生巨大的商业价值,以及风险告警,在筹建大数据分析系统时,你们都很热衷新的东西,在作公司架构体系时,动不动就直接上新的技术,致使项目夭折,最后走人换公司的局面,后来不断的有人去填坑。redis
随着Splunk 的声势浩大,致使目前公司采用起来的成本过高,因此选择方案的时候须要均衡发展,达到良性可伸缩的系统框架。缓存
采用ELK框架进行日志分析系统构建:安全
ELK是Elasticsearch、Logstash、Kibana的简称,这三者是核心套件服务器
Elasticsearch是实时全文搜索和分析引擎,提供搜集、分析、存储数据三大功能;是一套开放REST和JAVA API等结构提供高效搜索功能,可扩展的分布式系统。它构建于Apache Lucene搜索引擎库之上。websocket
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,提供了统一的数据发送方法,输入配置解析,日志记录框架等功能。
目前这种方案不少公司都在此基础上作二次开发。
在海量日志系统的运维中,如下几个方面是必不可少的:
分布式日志数据集中式查询和管理
系统监控,包含系统硬件和应用各个组件的监控
故障排查
安全信息和事件管理
报表功能
怎么基于数据提高自我价值,为公司提供实时可靠的数据分析,让市场部掌控着市场,让营销部定点的作业务推广,从而实现技术价值,也实现这种方案的价值,发挥到极致。
根据庞大的应用日志能够分析出用户分布的位置、行为、动态、习惯等等。