随着互联网的发展，网络流量和会话规模呈现爆炸式增长，在这种情况下，如何实现对大规模流量的实时、复杂的处理，已成为网络流量监测分析面临的重要挑战。近年来大数据技术的发展，为网络监测分析提供了新思路。
上图主要采用Filebeat和ELK stack技术架构。通过对非结构化原始数据包Packets进行采集和处理，生成结构化的Netflow文件，并在采集服务器上部署轻量级的数据收集工具Filebeat来监视和实时发送到传输层。该架构提供了实现结构化网络流量Netflow流数据和非结构化的Packets包数据的收集、传输、存储和分析以及可视化展示的全套解决方案，可以比较好的解决大规模流量的存储、快速检索问题。当然，中间处理需要根据业务对平台进行优化和定制。举个例子，为有效避免单点故障问题，可在传输层设置Logstash以多节点协作的方式进行数据接收，并对数据存储配置多个目的主机。此外，根据业务需求，在传输过程中还可以直接对数据进行各类处理，包括过滤处理、数据分割处理、数据类型转换、IP地理信息等额外信息添加处理等，以更好的适配接入的大量Netflow数据。
我们使用4台普通服务器（单核、32G内存、500G硬盘）对当前系统进行了性能测试，当系统中存储有312699条Netflow流时，对IP、端口、包数等简单查询，平均耗时为0.007s；多个条件的符合查询，平均耗时为0.14s。基本可以满足网络安全监测中海量Netflow流实时查询分析需求。
日志分析
通过全面的日志分析获取设备故障、用户异常行为、网络运行状况等信息，能够弥补现有各类技术产品在威胁分析方面的不足，有利于及时处置网络安全事件和软硬件故障，保证服务的稳定性和安全性。日志是由众多用户与不同服务器产生，它具有着数据源多样性、海量性、传输不确定性等特点，而完整的日志是分析工作的保证。因此从日志的收集到日志分析是一项非常复杂的工作，它不仅要求系统具有较高的可靠性，还需要时效性。面对着每秒数MB/GB的网络请求，每天新增的海量日志，基于单机处理技术的传统日志分析系统，在存储和计算性能方面遇到了困难。同时基于Hadoop的海量离线分析系统，在日志分析的时效性方面也存在着极大的瓶颈。
上图是我们设计的日志分析大数据处理架构，相对于流量分析系统，主要变化有两个：增加了Kafka集群、实时分析上增加了Spark Streaming计算组件。通过从Kafka中实时抽取消息，进行消费，并基于滑动时间窗口进行实时计算。Spark Streaming提供两种Kafka消费数据方式直接去读取Kafka的数据，并做数据偏移量的检查，避免重复读取，同时保证数据的一致性。此外，在实时日志流上有每个应用处理函数，统计每一个请求日志类型的出现次数，并将前TOP20输出到应用层进行实时展示。
在类似的配置下，我们分析在特定的时间内请求日志数据，通过分析其响应时间来对系统的检索能力进行评价。可以看出，日志分析系统对141.5G的数据查询返回时间在800ms左右，能很好的满足系统的性能。
在这个大数据处理平台的具体实践过程中，有以下三个方面的经验可以分享：
（1）为了保证系统的稳定性与可靠性，保障Logstash、Kafka、ElasticSearch及Kibana的长期稳定运行，需用守护进程进行实时监控。利用daemontools工具对各个后台服务的运行情况进行监测，如果发现服务意外停止，daemontools工具可以将服务自启动，保证各进程的正常运行，从而实现服务的可靠性。
（2）Spark Streaming性能调优涉及很多方面，具体实践中主要做了以下两方面：1)设置作业为明确持续的RDD，这可以显著地减少Spark在RDD上的内存使用，同时也可以改善GC行为；2) 设置spark.streaming.concurrentJobs，修改默认值，这样可以提高Spark Streaming的吞吐量。
（3）对于长期运行的ElasticSearch集群，由于网络或者意外宕机等原因，可能会导致集群产生多个master，即“脑裂”的现象。目前社区还没有彻底解决的方法，实践中通过设置discovery.zen.minimum_master_nodes参数为(N/2)+1（其中N为master节点资格的数量），可以减缓“脑裂”现象的发生。
后记
诚惶诚恐的写完这个技术不技术，科普不科普的文章，写的战战兢兢的，就当是漫谈闲聊吧。如果能给少部分人带来点对大数据的更多的认识，也算是一件幸事。
感谢下面文献对这篇漫谈大数据的贡献。由于时间关系，没法一一求证，还有部分内容未列在参考文献里，在此笔者统一表示感谢。另外这个系列是整理和加了部分自己的观点，整理的内容权利原作者保留，个人的观点仅代表个人观点，[笑脸]。
联系客服
