日志安全分析方案梳理一二

业界方向

随着大数据技术的发展和各类依赖性技术的提高,日志分析系统已经由原来的分散存储、事后追查发展到统一收集、实时搜索和流式处理。

就目前而言,ELK在日志收集和查阅上已经占据了优势地位,其他同类型系统如Splunk等所占份额均在萎缩。又基于高可用和性能的需求,引入了KAFKA集群作为消息队列服务。同类型系统还有Flume,此处不对其原理和实现进行分析。

在日志分析上,分布式实时流处理已经是趋势,目前业界流行的有Storm、Spark Streaming、Samza、Flink等,份额及综合实力(包括但不限于背后开发商、文档和资料、语言优势、性能)占优的是Storm和Spark Streaming。以下详细针对这两个框架进行阐述:

Storm

Apache Storm最开始是由Nathan Marz和他的团队于2010年在数据分析公司BackType开发的,后来BackType公司被Twitter收购,接着Twitter开源Storm并在2014年成为Apache顶级项目。毋庸置疑,Storm成为大规模流数据处理的先锋,并逐渐成为工业标准。Storm是原生的流处理系统,提供low-level的API。Storm使用Thrift来定义topology和支持多语言协议,使得我们可以使用大部分编程语言开发,Scala自然包括在内。

模式

原生流 Native stream process ——所有任务,从到达开始,一个接着一个进行处理。

首先以原生流处理开始,原生流处理的优势在于它的表达方式。数据一旦到达立即处理,这些系统的延迟性远比其它微批处理要好。除了延迟性外,原生流处理的状态操作也容易实现。

一般原生流处理系统为了达到低延迟和容错性会花费比较大的成本,因为它需要考虑每条记录。原生流处理的负载均衡也是个问题。比如,我们处理的数据按key分区,如果分区的某个key是资源密集型,那这个分区很容易成为作业的瓶颈。

容错

通过记录每个源数据的跟踪确认消息来容错,性能好,但是需要开发者重复处理数据,类似于三次握手。也因此,在消息传输保障上,只实现了at least once,会存在消息重复。

性能

毫秒级,容错、状态管理等均会不同程度降低性能。

总结

任务量不大,速度要求高的实时性项目适合。

Spark Streaming

Spark是非常受欢迎的批处理框架,包含Spark SQL,MLlib和Spark Streaming。Spark的运行时是建立在批处理之上,因此后续加入的Spark Streaming也依赖于批处理,实现了微批处理。接收器把输入数据流分成短小批处理,并以类似Spark作业的方式处理微批处理。Spark Streaming提供高级声明式API(支持Scala,Java和Python)。

模式

微型批处理 Mini-batch steam process ——所有任务,从到达开始,在T时间内到达的任务作为一个集合,批量进行处理。

微型批处理。将流式计算分解成一系列短小的批处理作业,也不可避免的减弱系统的表达力。像状态管理或者join等操作的实现会变的困难,因为微批处理系统必须操作整个批量数据。并且,batch interval会连接两个不易连接的事情:基础属性和业务逻辑。

相反地,微批处理系统的容错性和负载均衡实现起来非常简单,因为微批处理系统仅发送每批数据到一个worker节点上,如果一些数据出错那就使用其它副本。微批处理系统很容易建立在原生流处理系统之上。

容错

由于源数据均是以batch的形式存在,出现错误重新计算即可,同时batch本身唯一且持久,很容易解决问题。也因此,很容易在消息传递保障上实现exactly once。

性能

秒级,容错、状态管理等均会不同程度降低性能。

总结

任务量一般,速度要求不高的项目适合。适合Spark技术栈,且比较新。

初步方案

总览

采用ELK+KAFKA+Spark Streaming来实现

目前apache官方提供两个版本的Spark Streaming + KAFKA集成环境。分别是spark-streaming-kafka-0-8和 spark-streaming-kafka-0-10 差异如下:

spark-streaming-kafka-0-8 spark-streaming-kafka-0-10
Broker Version 0.8.2.1 or higher 0.10.0 or higher
Api Stability Stable Experimental
Language Support Scala, Java, Python Scala, Java
Receiver DStream(被动模式) Yes No
Direct DStream(主动模式) Yes Yes
SSL / TLS Support No Yes
Offset Commit Api No Yes
Dynamic Topic Subscription No Yes

模式

被动模式 Receiver-based Approach

是利用 Kafka 消费者高级 API 在 Spark 的工作节点上创建消费者线程,订阅 Kafka 中的消息,数据会传输到 Spark 工作节点的执行器中,但是默认配置下这种方法在 Spark Job 出错时会导致数据丢失,如果要保证数据可靠性,需要在 Spark Streaming 中开启Write Ahead Logs(WAL),也就是上文提到的 Kafka 用来保证数据可靠性和一致性的数据保存方式。可以选择让 Spark 程序把 WAL 保存在分布式文件系统(比如 HDFS)中。

主动模式 Direct Approach

不需要建立消费者线程,使用 createDirectStream 接口直接去读取 Kafka 的 WAL,将 Kafka 分区与 RDD 分区做一对一映射,相较于第一种方法,不需再维护一份 WAL 数据,提高了性能。读取数据的偏移量由 Spark Streaming 程序通过检查点机制自身处理,避免在程序出错的情况下重现第一种方法重复读取数据的情况,消除了 Spark Streaming 与 ZooKeeper/Kafka 数据不一致的风险。保证每条消息只会被 Spark Streaming 处理一次。

分析

通过阅读一些教程和报告,并根据现状,采用0-10版本比较好。该版本采用了KAFKA最新的consumer API,可以规避掉KAFKA本身的一些坑。加之我们的业务并不需要追求绝对稳定,保持技术栈的最新有利于解决一些已经暴露出来的坑。不过这个版本也存在一些问题,文档较少、官网原生暂时不支持Python、实验版本API可能修改等。

流处理框架选好了,就还有几个问题需要解决。

流程

源——日志——KAFKA——Spark Streaming——安全策略应用(脚本处理/系统处理)——数据持久化——告警与否——跟进处理

(流程图待补)

待处理问题

针对具体日志的安全策略研究

应用策略的Scala程序开发

报警消息通知

适合具体情景的集群性能指标测试

REFERENCE

[消息传输保障]: https://kafka.apache.org/documentation/#semantics
[KAFKA和Flume]: https://www.zhihu.com/question/36688175/answers/created
[流处理框架比较]: https://www.zhihu.com/question/29092950/answers/created
[流处理框架比较]: http://www.dataguru.cn/article-9532-1.html
[流处理框架比较]: http://xinhstechblog.blogspot.hk/2014/06/storm-vs-spark-streaming-side-by-side.html
[日志处理平台]: https://www.ibm.com/developerworks/cn/analytics/library/ba-1512-elkstack-logprocessing/index.html
[实时数据处理系统]: https://www.ibm.com/developerworks/cn/opensource/os-cn-spark-practice2/index.html
[ELK+SS]: https://www.ibm.com/developerworks/cn/analytics/library/ba-cn-elk-spark/index.html
[SS Guide]: http://spark.apache.org/docs/latest/streaming-programming-guide.html
[SS+KAFKA Guide]: https://spark.apache.org/docs/latest/streaming-kafka-0-8-integration.html
[SS+KAFKA+PY]: https://www.rittmanmead.com/blog/2017/01/getting-started-with-spark-streaming-with-python-and-kafka/
[SS+KAFKA+Redis]: http://shiyanjun.cn/archives/1097.html
[性能测试]: https://www.iteblog.com/archives/1561.html

日志安全分析方案梳理一二

发表评论

电子邮件地址不会被公开。

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据