基于ELK网络安全监控系统设计与实现--系统需求分析(二)

第3章 系统需求分析

3.1 可行性分析

3.1.1技术可行性

该系统使用IDEA开发工具,Elasticsearch 数据库,可视化看板kibana,ELK框架联合开发并实现。对于以上描述的技术或开发工具,在当代都是较为成熟的技术和平台,虽然它们都有自已的体系,但在程序员的眼里,它们的配合度是很高的,网上的相关博客中每个创建项目的帖子,它们都会出现,数据库负责管理数据,开发工具负责管理项目,技术负责代码的框架,既相互独立,又相互依赖[6]。以上描述的工具、技术都已转化为自身的技能,所以从技术角色考虑是可行的,工作人员对于技术的关注度并不高,只要程序可用即可。

3.1.2经济可行性

经济可行性,可分为两种,支出和收入,该系统属于研究型毕业设计,所以收入部分暂不考虑。支出可分为,设备、场地、开发环境、人力、时间等一切需考虑的因素,所有信息都是影响形成系统的一部分。设备:只需一台笔记本电脑,配套的输入设备;开发环境:良好;人力:自身、指导老师、同学;时间:从选题到毕业为止,大约8个月。从以上描述可知,大部分条件已经满足,所以该系统不会存在经济方面的问题,所以是可行的。

3.1.3社会可行性

社会可行性,广义而讲可涉及到道德方面、法律方面、社会方面,每个方面都会影响系统的形成。本系统的是独立且没有任何传播性质的信息,更涉及不到道德层面,法律层面;本系统也没有触发法律,没有赌博、黄色等类型信息,同时也是遵从国家法律,不会显示任何触发法律层面的信息;社会方面,该系统是为人们带来快速并有效查询的功能,也是具有贡献意义的。总体而言,该系统也是具有社会可行性的。

3.1.4法律可行性分析

网络安全监控系统使用的是免费开源框架,功能是自己独立设计的,该系统是本人开发出来做毕业设计之用,并不会侵犯他人、集体和国家的利益。该系统使用正版软件开发,所有参考资料都是正规网站查询分析得出,开发的技术完全是开源免费的工具,百分百遵守国家法律法规。不会出现任何违反国家的政策和法律的。

3.1.5 操作可行性分析

系统的登录界面和业务逻辑简洁明了,采用一般的界面窗口来登录界面,首页顶端有导航栏,通过导航栏我们可以很快找到我们要去的页面,导航栏左侧有搜索框,我们可以通过搜索框搜索信息,导航栏下方有轮播图,轮播图会每天更新热点信息,使得整个系统更加人性化,用户操作更加简洁方便。本系统具有易操作、易管理、交互性好的特点,在操作上是非常简单的。因此,本系统可以进行设计开发。通过电脑进行访问操作,用户一定能够很快就会对系统熟悉,尤其对老年群体,稍微简单了解下本系统,就能很快上手[10]

3.2 需求分析

功能性需求分析主要是针对系统所需的各项功能进行分析,其主要目标是注重所设计的系统或平台是否具备了所需功能和特性,是否达到了用户预期的需求目标。基于国内外研究现状的总结和详细的分析,对于安全的志分析系统侧重于

四个方面的问题:

第一 如何安装配置elasticsearch,确保所采集的日志数据不会丢失。

第二 如何安装配置kibana,确保连通elasticsearch;

第三 如何安装配置filebeat,采集需要的日志数据到elasticsearch,并连通kibana;

第四 如何安装配置auditbeat,采集需要的日志数据到elasticsearch,并连通kibana。在设计该集中式日志分析系统时,本文对互联网的架构需求有非常充分的分析,并且结合业务需求来挑选了合适的工具,在面对技术架构选型的问题时,有如下四个问题是非常关键的:

1、实时性。日志信息数据在传送过程,如果数据发生变化了,那么分析系统什么时候可以看到这个变化的情况?这个时差理论上是越小越好,由于受设备和技术方面的制约,不同级别的网络设备和技术对应的不同级别的系统,按常规可分为:毫秒级秒级、分钟级和离线级。一般来说计算机性能越好,延迟时间会越小,处理速度越快;如果计算数据要求精确度很高,则延迟时间会增加。所以,延迟时间的长短也影响实时性,而计算查询延迟是根据查询请求发出后,所需要等待的时间长短,再结合服务器把计算结果返回。作为日志分析系统首先要确保有较高的实时性,才能保证系统能在第一时间把系统的实际情况反映给用户。

2、海量性。对海量数据的处理,是衡量日志分析系统的性能的一个重要标志。随着各种数据大小的提升,网络中的日志文件数量也从GB慢慢增长到TB,将来甚至到PB,所以能快速对海量日志文件数据进行处理,不仅是日志分析系统性能优越的表现,也是日志存储如何架构所需要考虑的重要问题。

3、防御和维护性。在实现实时性和海量性的基础上,以最有效的方式选择架构技术,注重防御强度和维护的简便性。如果使用组件数量越多,成本就会越高,构建的架构就越复杂。众多组件的配合度低则使用的成本就少,众多组件的配合度高则使用的成本就多。面对日志分析系统各种的业务需求,往往需要增加不同类型的服务器和安全设备,或者扩展系统服务器和安全设备,保证对各种类型的日志文件收集、分析和存储。同时互联网中的入侵方式也越来越多,为了确保服务器主机的性能和稳定性,入侵防范检测就对技术人员提出了很高要求

4、简便性的检索和可视化。在收集各种日志信息数据时,不同岗位的工作人员对曰志信息有不同的需求,比如维护技术人员要服务器系统的关键指标并能够及时地可视化展示其状态,测试人员和开发人员对各种应用程序日志的实时检索和查询等,需要满足各工作人员的检索和监控需求。对于日志信息简便性的检索和可视化,应该按实际要求进行制定,可以根据指定的检索条件进行分类统计,也可以按照时间的形式进行。系统需求示意图如图3-1所示。

图3-1 系统需求示意图

系统核心需求如图3-2所示。

图3-2 系统核心需求图

模块设置auditbeat.yml

auditbeat.modules:

- module: file_integrity

  paths:

  - /bin

  - /usr/bin

  - /sbin

  - /usr/sbin

  - /etc

file_integrity配置为在指定路径之一中的文件在磁盘上发生更改时生成事件的模块设置输出elasticsearch.index索引。

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论
基于Spring Cloud的空气污染物数据分析系统设计实现,可以基于微服务架构来构建。下面是一个简要的300字设计实现方案: 首先,我们可以使用Spring Cloud的注册中心来进行服务的注册与发现,例如使用Eureka。 接下来,我们可以将数据收集与处理拆分为多个微服务,每个微服务负责不同的任务。例如,我们可以有一个数据收集微服务负责从不同的空气污染监测站点收集数据,并将其存储在数据库中。另一个微服务可以负责数据预处理和清洗,处理离群值和缺失值等。还有一个微服务可以负责数据分析和建模,使用机器学习算法预测空气污染物的变化趋势。 为了实现这些微服务,我们可以使用Spring Cloud的其他组件。例如,使用Spring Cloud Zuul作为API网关,对外提供统一的接口;使用Spring Cloud Config来管理不同微服务的配置;使用Spring Cloud Feign来进行微服务之间的通信;使用Spring Cloud Stream来处理高吞吐量的数据流。 此外,考虑到系统的可靠性和容错性,我们还可以使用Spring Cloud的断路器模式和服务降级技术,例如使用Hystrix。这样可以确保即使一个或多个微服务出现故障,系统仍能保持正常运行。 最后,我们可以使用Spring Cloud的监控和日志组件来对系统进行监控和调优,例如使用Spring Boot Actuator和ELK堆栈。 总之,基于Spring Cloud的空气污染物数据分析系统设计实现,可以采用微服务架构,利用Spring Cloud的各个组件来提供可靠的服务和高性能的数据分析能力。这样的系统设计可以满足数据收集、处理、分析和预测的需求,并且具备良好的可扩展性和可维护性。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

Abelon

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值