快捷搜索:  网络  渗透  后门  CVE  扫描  木马  黑客  as

借鉴开源框架自研日记网络体系

项目违景

公司项目需要将分布在多台机器中的日记统一网络治理。笔者前后使用logstash,flume等开源项目。并终极自研一套基于Java说话的日记网络体系 Bloodhound。下列从项目关注的角度对开源体系与自研进行阐发。

1 开源日记网络体系特征

Logstash 以及 Flume 都是很成熟的日记网络平台,结构清晰,插件丰富,文档简明易懂,示例代码无比多。其中Logstash 侧重对字段的预处理,Flume 侧重不同的收集拓扑中日记的传递,通过Agent打通各个收集结点。

2 关于日记网络体系的考量

 开发说话的选择

公司的开发团队首要集中在 Java,Python。而 Logstash 的插件使用 Ruby,从团队角度,不太具备扩大性。在使用 logstash 增添一个插件比较痛楚,同时几个月使用下来,感觉性能偏低,启动时较慢。 

性能的考虑

Flume性能相对于比较低,首要有下列几点:

① 单线程。

Flume 每一个 Agent 分为 source,channel,sink 等插件。每一个插件都只启用单线程处理。要是义务是写数据库等 IO 操作,性能必然会被拖累。

②source的Timer机制

Source 线程在检测有新的更新,会始终读取推向 Channel,当所有的更新处理完毕,线程会退出。启动一个 Timer 线程。定期3秒重新启动,云云反复。在这个过程中,没有充分行使 Java 的多线程通知机制,每一次启动都有一些调度,排队,检测及义务初始化过程。影响性能。

③Flume事件机制

Flume 本身已对事各进行了优化,允许批量提交事故。但本质上照样需要检测Sink的处理效果,再进行 Co妹妹it 或 Roolback。

治理的考虑

要是将一个 agent 的义务处理串,source->channel->sink 理解为一个义务(这个义务是个抽象的概念,Flume 里并没有这个概念),那么 Flume 从营业脚度上看,就是单义务网络体系。要是需要同时处理两个义务,必须开启两个 Flume Agent 进程。随着网络义务的增添,必然会大大增添治理成本。

图片1.png

(flume处理:多进程处理多义务)

图片2.png

(Bloodhound处理:单进程处理多义务)

此外,我们还有监控需求,统计需求,义务治理等。这些义务需要以及我们的 grafana 平台打通。综合考虑下,我们选择自研日记网络体系。

BloodHound体系

项目名称来源

From wikipedia:

The Bloodhound is a large scent hound, originally bred for hunting deer, wild boar, and since the Middle Ages for tracking people. Believed to be descended from hounds once kept at the Abbey of Saint-Hubert, Belgium, it is known to French speakers as the Chien de Saint-Hubert.

This breed is famed for its ability to discern human scent over great distances, even days later. Its extraordinarily keen sense of smell is combined with a strong and tenacious tracking instinct, producing the ideal scent hound, and it is used by police and law enforcement all over the world to track escaped prisoners, missing people, lost children and lost pets.

“嗅觉最灵敏的猎犬,寓意是能从包括流量在内的种种粗糙的原始数据中提炼中初步有价值的信息。”

项目需求

多义务治理体系

强扩大性

义务监控

高性能

项目架构

图片3.png

体系分层

核心框架层

为了充分行使Flume的功能特性,我们也将Bloodhound拆分层source->channel->sink三个层次。这个设计是为了充分行使Flume中的丰富插件资源,请参照下列设置文件。

图片4.png

时序图

图片5.png

source 层

source为数据输入,一般是文件,新闻体系等。示例中的Source为Redis,Source为单独运行的线程,从Redis中指定的行列步队中获取输入,读取实现后则推向 Channel。当 Channel 中行列步队已满时,则 source 线程则进入守候。

 Channel 层

Channel 作为枢钮,连接 Source 以及 Channel,首要功能以下:

珍爱一个行列步队,接受 source 的 put,向 Sink 发送处理。

治理一个线程池,调度 Sink 义务。由于 Sink 通常较慢,因此全部核心模块中,只有 Sink 为多线程处理,其余均为单线程执行。

控制QPS,可以使用令牌或漏斗,首要目的是维护高并发写入的环境下,Sink 对应的数据库或 Redis。不至于压力过大,影响正常营业要求。

发送 Metrics,提供实时监控数据来源。

Channel 层首要的要领有:popEvents, addEvents, notifyEvents, sendMetrics等。

Sink 层

Sink 层为一个 Runnable,接受 Events,被 Channel 调度,执行终极的落地逻辑。

以上三层中,Channel 层有 MemoryChannel 以及 FileChannel,要是义务比较重要,应该选择 FileChannel,可以保障进程中止后,Event 不会被丢失。MemoryChannel 治理一个 Queue,性能相对于比较高。Source 以及 Sink 可以大批复用Flume中的插件代码。

义务治理器

义务治理器,故名思义是治理全部日记网络体系的治理模块。

1 义务治理

义务注册接口:可通过义务注册接口向全部进程提交一个义务,如设置所示,义务注册接口是通过一个 http post 要领提供注册并启动一个新的义务。

数据提交接口:默认情形下,Source 是 pull 模式,从文件中,行列步队中拉取日记。同时也支持 http 方式提交。数据提交接口需要传递两个参数,jobName 以及 events 。

2 义务监控

查看义务执行情形:在grafana中查看各个义务执行情形,这个数据由核心框架层提供。

查看义务运行情形:提供列表,工控黑客 ,查看义务状态,启动,休止义务。

体系运维层

进程治理:使用supervisor治理进程。

 调度器:根据各个营业情形,使用调度义务对义务进行治理。调用义务治理中的义务启动,休止等。这一块以及日记网络核心不太相干,就再也不赘述。

结语

笔者从事过量个项目需要使用日记网络,同时也使用了 logstash, flume 等开源体系,团体感觉开源体系比较成熟,有大批插件,事件治理。但以及自已营业体系结合不够慎密。自研框架工作量较大,也会有很多坑,优势是较好的以及营业接轨。

*

您可能还会对下面的文章感兴趣: