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

就目前而言，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 差异如下：

模式

被动模式 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

The post 日志安全分析方案梳理一二 appeared first on nood1es.