一种多服务器网站的日志存储管理系统转让专利

申请号 : CN202111435572.9

文献号 : CN113849846B

文献日 :

基本信息:

PDF:

法律信息:

相似专利:

发明人 : 王涛朱春华王清植孙涛张英

申请人 : 山东捷瑞数字科技股份有限公司

摘要 :

本发明涉及电数字数据处理技术领域,特别是涉及一种多服务器网站的日志存储管理系统,包括多个子系统和一个主系统,子系统分别部署于已部署WEB应用的子服务器上、负责收集各自WEB应用日志及定时将日志消息传输给主系统,主系统部署于一台日志存储服务器上、负责存储和管理各子服务器的日志消息,子系统与子系统之间的数据相互隔绝,每个子系统与主系统之间的数据双向传输。与现有技术相比,本发明适用于调用频繁的日志业务,依托于内存数据库进行大量数据的短时间存储,可以保证日志的完整性并规避硬件储存导致的服务器压力。

权利要求 :

1.一种多服务器网站的日志存储管理系统,其特征在于:包括多个子系统和一个主系统,子系统分别部署于已部署WEB应用的子服务器上、负责收集各自WEB应用日志及定时将日志消息传输给主系统,主系统部署于一台日志存储服务器上、负责存储和管理各子服务器的日志消息,子系统与子系统之间的数据相互隔绝,每个子系统与主系统之间的数据双向传输;

各子系统通过解析端口访问各自子服务器的apche或其他服务器请求分发器日志模块,并将各子服务器的WEB应用的日志数据存储在各自的Redis数据库中,各子系统定时对各自的Redis数据库中的日志数据进行识别、分类、加密、打包形成各自的日志消息数据包缓存在各自子服务器的Redis数据库中,并将各日志消息数据包通过文件传输端口传输给主系统;当各子系统通过接收端口收到主系统返回的传输成功的消息后,清除各自子服务器中的日志消息数据包及Redis数据库中的数据;当各子系统通过接收端口收到主系统返回的传输失败的消息或无响应时,将缓存的各自的日志消息数据包保存在各自子服务器的磁盘空间中,并尝试再次续传;

主系统包括日志收集模块、日志处理模块和日志存储模块;

日志收集模块:通过文件传输端口获取各子系统的日志消息数据包,记录各子系统的IP、传输时间、包的大小,获取完成后对各子系统返回相同或不同的状态码;

日志处理模块:对获取的日志消息数据包进行解压、解密,解密完成的数据暂存于Redis数据库中;

日志存储模块:对暂存于Redis数据库中的数据进行序列化,得到java日志对象集合,对java日志对象集合根据其访问日期,访问IP,访问来自的地理区域进行处理,再将对象逐条转储进Mysql数据库进行持久化储存。

2.根据权利要求1所述的一种多服务器网站的日志存储管理系统,其特征在于:每个子系统与主系统之间的数据传输通过TPC/IP协议在局域网内通讯。

3.根据权利要求2所述的一种多服务器网站的日志存储管理系统,其特征在于:加密使用Base64编码方式。

说明书 :

一种多服务器网站的日志存储管理系统

技术领域

[0001] 本发明涉及日志数据处理技术领域,特别是涉及一种多服务器网站的日志存储管理系统。

背景技术

[0002] 随着互联网行业的日渐发展,网站业务变得日渐兴盛,为了给网站进行合理的服务端资源分配,需要将网站日常的运行和访问的日志作为基准。
[0003] 网站日志一般通过先期开发已经设定好的规则进行生成,生成完成的日志经过开发人员的分析,及时发现项目的问题并优化。网站的日志由于要记录网站的每位访客的操
作,必然会产生海量的数据,这些数据一般存储于服务器的硬件存储设备中,庞大的日志量
会使服务器性能受到影响,进而导致项目运行不稳定,甚至会导致服务器宕机等严重问题。
其次是频繁的日志业务调用带来了服务器内存负载压力及磁盘的写入压力。
[0004] 总体而言,现有的日志管理系统普遍存在的缺陷有:1.频繁的日志业务调用,导致服务器压力过高。2.过多的日志写入磁盘空间,势必对服务器性能造成影响。3. 日志文件
在服务器上以纯文本文件的形式存在,不方便后期查阅和分析。

发明内容

[0005] 为弥补现有日志存储管理系统的不足,本发明提供一种多服务器网站的日志存储管理系统,所采取的技术方案是:
[0006] 一种多服务器网站的日志存储管理系统,包括多个子系统和一个主系统,子系统分别部署于已部署WEB应用的子服务器上、负责收集各自WEB应用日志及定时将日志消息传
输给主系统,主系统部署于一台日志存储服务器上、负责存储和管理各子服务器的日志消
息,子系统与子系统之间的数据相互隔绝,每个子系统与主系统之间的数据双向传输。
[0007] 进一步地,各子系统通过解析端口访问各自子服务器的apche或其他服务器请求分发器日志模块,并将各子服务器的WEB应用的日志数据存储在各自的Redis数据库中,各
子系统定时对各自的Redis数据库中的日志数据进行识别、分类、加密、打包形成各自的日
志消息数据包缓存在各自子服务器的Redis数据库中,并将各日志消息数据包通过文件传
输端口传输给主系统;当各子系统通过接收端口收到主系统返回的传输成功的消息后,清
除各自子服务器中的日志消息数据包及Redis数据库中的数据;当各子系统通过接收端口
收到主系统返回的传输失败的消息或无响应时,将缓存的各自的日志消息数据包保存在各
自子服务器的磁盘空间中,并尝试再次续传。
[0008] 进一步地,主系统包括日志收集模块、日志处理模块、日志存储模块和日志展示模块;
[0009] 日志收集模块:通过文件传输端口获取各子系统的日志消息数据包,记录各子系统的IP、传输时间、包的大小,获取完成后对各子系统返回相同或不同的状态码;
[0010] 日志处理模块:对获取的日志消息数据包进行解压、解密,解密完成的数据暂存于Redis数据库中;
[0011] 日志存储模块:对暂存于Redis数据库中的数据进行序列化,得到java日志对象集合,对java日志对象集合根据其访问日期,访问IP,访问来自的地理区域进行处理,再将对
象逐条转储进Mysql数据库进行持久化储存。
[0012] 进一步地,每个子系统与主系统之间的数据传输通过TPC/IP协议在局域网内通讯。
[0013] 进一步地,加密使用Base64编码方式。
[0014] 与现有技术相比,本发明具有如下有益的技术效果:Redis数据库为一种内存数据库,此种数据库的特点为存取速度快,适用于调用频繁的日志业务,依托于内存数据库进行
大量数据的短时间存储可以保证日志的完整性并规避硬件储存导致的服务器压力。
[0015] 通过Redis分库操作将日志文件进行应用级的划分,改善后期海量日志分析导致的工作成本。分库操作通过子系统自身功能实现。
[0016] 日志包进行Base64加密后进行传输,防止被拦截解包后用于黑客分析攻击的凭据。

具体实施方式

[0017] 下面通过具体实施例对本发明作进一步说明。
[0018] 一种多服务器网站的日志存储管理系统,包括多个子系统和一个主系统,子系统分别部署于已部署WEB应用的子服务器上、负责收集各自WEB应用日志及定时将日志消息传
输给主系统,主系统部署于一台日志存储服务器上、负责存储和管理各子服务器的日志消
息,子系统与子系统之间的数据相互隔绝,每个子系统与主系统之间的数据双向传输。
[0019] 访问者通过终端设备访问子服务器上部署的WEB应用时,会产生日志文件,各子系统通过解析端口访问各自子服务器的apche或其他服务器请求分发器日志模块,并将各子
服务器的WEB应用的日志数据存储在各自的Redis数据库中,各子系统定时对各自的Redis
数据库中的日志数据进行识别、分类、加密、打包形成各自的日志消息数据包缓存在各自子
服务器的Redis数据库中,并将各日志消息数据包通过文件传输端口传输给主系统;当各子
系统通过接收端口收到主系统返回的传输成功的消息后,清除各自子服务器中的日志消息
数据包及Redis数据库中的数据;日志包成功发送后,子服务器磁盘上的日志包文件和存储
于Redis数据库中的数据都是无效数据,因此全部予以清除,来降低服务器的内存压力;当
各子系统通过接收端口收到主系统返回的传输失败的消息或无响应时,将缓存的各自的日
志消息数据包保存在各自子服务器的磁盘空间中,并尝试再次续传。
[0020] 子服务器启动Apache后,Apache会自动生成两个日志文件,这两个日志文件分别是访问日志access_log(在Windows上是access.log)和错误日志error_log(在Windows上
是error.log),access_log与error_log中的日志消息皆可以下方法读取:
[0021] File file = new File(“日志文件的全路径”);//首先通过文件全路径实例化一个File对象;
[0022] BufferedReader reader = null;
[0023] StringBuffer sbf = new StringBuffer();
[0024] reader = new BufferedReader(new FileReader(file));//将文件对象转化为BufferedReader缓冲流,来读取文件中的文本信息;
[0025]     String tempStr;
[0026]     while ((tempStr = reader.readLine()) != null) {
[0027]     sbf.append(tempStr);//循环读取缓冲流中的文本信息,并定义一个字符串缓冲类;
[0028]         }
[0029]     reader.close();
[0030]     return sbf.toString();//将字符串缓冲类转化为字符串,接下来使用正则匹配日志信息。
[0031] 获取完成后的日志信息的几部分组成,P ‑ ‑ [带时区的日期] “请求类型 /资源路径/ 请求协议” 请求状态码发送信息的字节数 “‑” “客户的浏览终端信息(手机/PC 操
作系统)”。
[0032] 日志信息的格式统一,可以通过正则匹配的方式从中获取到的信息有此日志的产生时间,访问者的IP,访问的方法或者页面地址,受访问的WEB应用信息,请求状态码。以键
值对的形式存入子系统服务器中的Redis数据库中。
[0033] 存储过程中,使用Java提供的jedis对象将日志对象以WEB应用为依据分类分别存于不同的Redis库中,例如某官网的网址为www.***.com,对应Redis中名为www.***.com的
库。
[0034] 此处我们应对Redis日志存储策略进行设置,子系统的Redis数据库配置应统一设定为增量存储模式,具体操作为在Redis配置文件redis.conf中设定appendonly配置项为
yes,并设置appendfsync项的值为everysec 。
[0035] appendonly yes/no ,appendonly配置,指出是否在每次更新操作后进行日志记录,如果不开启,无法使用Redis的AOF备份方式备份数据。
[0036] appendfsync no/always/everysec ,appendfsync配置,no表示等操作系统进行数据缓存同步到磁盘,always表示每次更新操作后手动调用fsync()将数据写到磁盘,
everysec表示每秒同步一次。此处根据业务逻辑需求,选择对服务器压力较小的everysec
逐秒进行fsync将数据存入磁盘。
[0037] 根据返回的请求状态码不同将请求分为三个等级:如返回的状态码为500、404、502、503或504,将此日志归入ERROR日志;如返回的状态码为200,归入INFO日志;其他状态
码归入WAN日志。
[0038] 上述过程完成后,获得和子服务器上部署的WEB应用一一对应的多个Redis库。例如WEB应用为某官网,网址为www.***.com,则对应Redis中名为www.***.com的库。使用
Redis提供的AOF备份技术对Redis数据库中的信息进行备份,获取到AOF备份文件(*.aof),
AOF备份文件名由Redis数据库配置文件redis.conf指定。使用Base64字符集进行加密。
[0039] 相关加密解密规则使用JDK自带的的sun.misc包下的方法进行加密。将加密完成的备份进行打包,进入待传输状态。通过设定服务器定时脚本的方式,使服务器上的项目日
志定时进行打包操作,打包完成的文件以*.zip的格式缓存于子系统的硬盘上。
[0040] Base64就是一种基于64个可打印字符来表示二进制数据的方法。可用于进行文本数据的加密。
[0041] 对于标准的Base64:
[0042] 加密为字符串使用Base64.getEncoder().encodeToString();
[0043] 加密为字节数组使用Base64.getEncoder().encode();
[0044] 解密使用Base64.getDecoder().decode();
[0045] 通过上述过程可以获得的待传输的日志包文件(*.zip)。使用主系统提供的文件传输端口将子系统上的日志包文件文件(*.zip)传输至主系统。
[0046] 将文件传输完成后返回状态码通知子系统对磁盘上的日志文件进行处理。如返回传输失败的状态码或者出现传输超时的情况。保存当日的日志包文件。并进行再次续传。如
返回传输成功状态码时,清除服务器上的日志文件,传统日志保存在本机服务器的情况下,
百万级别访问量的网站一天大概产生3G左右的日志数据,这些数据如未被及时清除,长期
会导致磁盘空间不足,最终影响服务器上的项目运行。
[0047] 本发明的子系统,将日志转储入Redis数据库,并将数据库备份文件打包为加密数据包转移到统一的日志存储服务器。避免了日志文件堆积导致的子服务器磁盘空间浪费。
在日志处理过程中使用了定时脚本及缓存数据库Redis减轻子服务器日志业务的负担,定
时对服务器日志进行数据处理打包而不是随时执行打包业务,避免子系统方法的重复调
用。Redis数据库强大的存取能力,为子系统业务的健壮性提供保障。
[0048] 主系统包括日志收集模块、日志处理模块和日志存储模块。
[0049] 日志收集模块:主系统通过的文件传输接口进行文件的获取。取得完整的日志包文件(*.zip),记录来源的子系统的IP,传输时间,包的大小等日志信息。完成传输后返回状
态码,通知子系统对日志文件进行后续处理。如返回传输失败的状态码或者出现传输超时
的情况,子系统保存当日的日志包文件,并进行再次续传。如返回传输成功状态码时,子系
统清除服务器上的日志文件及打包完成的日志包,节省子系统硬件存储空间。
[0050] 子系统及主系统间的数据传输通过局域网实现,禁止外网使用主系统的文件传输端口,保障端口的安全性。
[0051] 日志处理模块:日志收集完成后,对传输来的日志包文件(*.zip)进行解压,获取到加密后的通过主服务器上的Redis数据库对传输来的AOF备份文件(*.aof)进行还原,复
现子服务器上的Redis数据库状态(Base64加密后的数据)。此时数据仍被Base64加密,在存
入持久化数据库前,先通过主系统程序进行Base64解密。
[0052] 解密完成的数据暂存于Redis数据库中。
[0053] 日志存储模块:日志处理完成后对Redis数据库中的数据进行序列化。
[0054] Redis数据库数据序列化为Java对象,在主系统程序中定义一个日志对象的实体类,此类应拥有IP,状态码,项目名等与存于Redis库中的数据匹配的字段,Java可以通过此
实体类将Redis数据库中的日志转化为Java对象。方便之后进行的持久化存储操作。
[0055] 上述操作完成后,得到java日志对象,对java日志对象进行数据处理,根据对象的访问日期,访问IP,访问来自的地理区域,对数据进行处理,再将java日志对象逐条转储进
Mysql数据库。
[0056] Redis数据库是一种非关系型的内存数据库,其数据存储于服务器内存中,服务器内存是服务器暂时存储程序以及数据的地方,内存中的数据在服务器关闭时将会被清除。
为了避免服务器宕机或其他意外情况导致内存中的数据丢失,因此对Redis数据库中的数
据进行持久化处理。本实施例采用将Redis数据库中的数据转储进Mysql数据库的方式完成
数据的持久化,Mysql是一种将数据存储于服务器硬盘上的数据库,此操作实际上达到了将
内存中临时数据转化成硬盘上永久数据的作用。
[0057] 完成上述操作后,数据会存储于Mysql数据库中,通过主系统可以将这些数据表中的数据读取为java日志对象,主系统通过对java日志对象的操作完成展示日志和查询日志
的业务逻辑。
[0058] 通过以上步骤,主系统可达到将日志数据进行保存安置的目的。并通过主系统的程序调用,使原本在Redis数据库中以文本数据存在的日志数据转化为易读、可操作的java
日志对象。
[0059] 以上实施例仅为本发明的技术方案而非对其限制,应当指出,对于本技术领域的技术人员来说,在不脱离本发明技术原理的前提下,还可以对本发明的具体实施方式进行
修改或等同替换,而未脱离本发明精神和范围的任何修改或等同替换,其均应涵盖在本发
明的权利要求范围当中。