这篇文档完成于2015年7月12日,原先要作为开源的东西最终还是闭源了, 这其中当然发生了太多的故事…

0x00 前言

“大数据”,一个被时下环境炒到不能再热的词。那么,什么才是大数据?百度百科是这样解释的“大数据(big data),是指无法在可承受的时间范围内用常规软件工具进行捕捉、管理和处理的数据集合。”那么,究竟多大才算大?至少,这里没有一个准确的分界线。但至少,如果每天增量在100G左右,你的数据量也不小了。
我们不去纠结过多口水,当我们拥有了“大数据”我们应该怎么使用呢?它能给我们带来什么价值?还是把它删掉,存放起来确实占不少成本。 “大数据的4个特点:第一,数据体量巨大。从TB级别,跃升到PB级别;第二,数据类型繁多,如:网络日志、视频、图片、地理位置信息等等。第三,处理速度快,1秒定律,可从各种类型的数据中快速获得高价值的信息,这一点也是和传统的数据挖掘技术有着本质的不同。第四,只要合理利用数据并对其进行正确、准确的分析,将会带来很高的价值回报。业界将其归纳为4个“V”——Volume(数据体量大)、Variety(数据类型繁多)、Velocity(处理速度快)、Value(价值密度低)。” (引自百度)。
那么,为什么要基于运维呢? 运维层面能给我们带来哪些优势?
首先,基于运维操作不会在现行业务层面修改代码,不影响现有业务使用,提升效率;其次,基于运维层面我们通过对日志的分析,截获对系统的攻击行为以及各种奇怪的入侵姿势;三是降低企业成本,只须运维人员统一规划配置日志存放,可供系统学习分析即可。

那么,这到底要怎么实现呢? 还有哪些技术热点需要我们使用和参考呢?

0x01 需求讨论

我们即将开展的运维日志分析,只是大数据分析的一种,除业务日志以外,大数据还分为如:社会化媒体数据分析(Good DATA)、工业数据分析(Singht Machine)、企业非同源数据分析(Looker)、传统BI分析(同类数据汇总)等等(欢迎补充)。
在安全业务层面,我们可能有这样或那样的问题有待解决,如访问、扫描,攻击、异常、系统等等,这些方式都会产生一条又一条的日志,造成的结果就是日志里越来越大,可是我们拿着这么大坨的日志到底要做什么呢?

主要功能

1.数据鸟瞰

首先,我们要在系统中清楚的显示出系统正在发生着什么,系统在做什么?能看到某个进程的资源情况,以及它正在干什么。

2.分析问题

假设系统故障,我们可以用存储的数据引导解决问题,促进故障修复和改进。追溯某个故障发生的位置,出错的具体代码位置或操作命令。

3.故障预警

初步的预警系统,简单实用,保障系统的健康运行。如异常登陆操作,譬如某预警规则“邮件帐号密码同ip错误登陆次数超过设定值”。

要实现的

1.全文检索

不仅能返回关键字内容,还要能搜索在文本中的内容。

2.水平扩展

高效的系统API架构可方便的二次开发,实现功能扩展。

3.高效读写

考虑到海量内容入库,快速搜索到关键信息,系统的读写大多数情况下可能会考虑在内存中操作。

4.容错能力

节点错误肯定会发生,有容错机制来ByPass

5.Agent-Free

本系统在实际应用部署中是一个自由角色,不干涉当前企业的业务环境。

6.GUI

友好的操作GUI,可能是Web,也可以是系统应用程序。

7.形态可控

可单机、群集、公有云、私有云,自动部署

应用场景

1.低部署成本

使用本项目的一键安装脚本可无人值守安装部署本项目。

2.快速检索问题

大数据分析能力以秒级别反馈数据。

3.可视化

该项目中的可视化可直观的显示检索出的统计结果等信息。

4.预警

及时的提醒运维人员攻击预警,反馈系统正在遭受的攻击。

可行性

1.Hadoop & Spark & Storm

三种技术各有优势,其中的技术对比在baidu一搜一箩筐,在项目初期可能只需要考虑Hadoop,原因有以下两点:

1.延续性

根据hadoop的特点,海量数据离线分析、大规模web信息检索,数据密集型并行计算,在项目后期也不会放弃hadoop。

2.部署成本

hadoop的hdfs是基于磁盘的,所以部署成本相对Spark和Storm较为低廉,易被企业所接受。在项目的后期,可能考虑hadoop+Storm更多一些,Storm的优点是全内存计算,它的业务处理速度是相当快的,Storm对于实时计算的意义类似于Hadoop对于批处理的意义。

2.Docker

它属于开源的应用容器,产品的最终形态可能是基于Docker的可移植的容器去发布,从而充实项目的自由度及降低部署成本.

3.ElasticSearh & Elastic HQ

它是基于lucene的搜索服务器,提供了一个分布式多用户能力的全文索索引擎,它提供一系列基于java和http的api,用于索引、检索、修改大多数配置。Elastic HQ则是为ElasticSerch提供的UI系统。

架构图

架构示意
架构示意
动静分离,充分自由
动静分离,充分自由

日志收集的实现方式我们通过运维的配置,将日志统一挂载到指定位置,譬如下图:

原始目录形态
原始目录形态

应用形态

服务器安全分析
服务器安全分析
服务器威胁报告
服务器威胁报告
邮件安全(日志钻取)
邮件安全(日志钻取)
邮件安全
邮件安全

参考

两个可参考的商业产品
Splunk, http://zh-hans.splunk.com/
Sumologic, http://www.sumologic.com/

0x02 小结

在目前看来,实现该项目,工作分为3个部分,前端开发,后端app开发,后端系统开发(基于ElasticSearh的二次开发).最终由运维人员打包整理发布。
基于目前的开源项目和业务应用场景,预设项目应支持AIO(All In One)方式部署,在业务量不大的应用场景中,存储方式可以酌情考虑.
群集场景中,我们还需要考虑 Hadoop和Storm的协调性,譬如:3日内的业务日志在Storm中存储,大于3日的业务日志在Hadoop中存储的智能存储方式,以降低企业成本。
这些问题,还有待讨论。

0x03 后话

该项目已经成功落地并且实施.当然,这只是早先的雏形与构想. 发出来的原因,只是希望你能更深层次的了解MoonStack到底是干什么用的.
当然,这篇文档不会长时间放在线上,我似乎已经发现什么了.哈哈~