CN114064676A - 一种数据处理方法及第一处理单元 - Google Patents
一种数据处理方法及第一处理单元 Download PDFInfo
- Publication number
- CN114064676A CN114064676A CN202111416263.7A CN202111416263A CN114064676A CN 114064676 A CN114064676 A CN 114064676A CN 202111416263 A CN202111416263 A CN 202111416263A CN 114064676 A CN114064676 A CN 114064676A
- Authority
- CN
- China
- Prior art keywords
- processing unit
- target
- data
- log
- log file
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/23—Updating
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/10—File systems; File servers
- G06F16/18—File system types
- G06F16/1805—Append-only file systems, e.g. using logs or journals to store data
- G06F16/1815—Journaling file systems
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/22—Indexing; Data structures therefor; Storage structures
- G06F16/2228—Indexing structures
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Data Mining & Analysis (AREA)
- Databases & Information Systems (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Software Systems (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
- Debugging And Monitoring (AREA)
Abstract
本发明公开了一种数据处理方法及第一处理单元,第一处理单元在目标容器节点中,通过多线程采集方式分别从多个日志文件中采集日志更新数据,将采集到的日志更新数据发送至第二处理单元,以使得第二处理单元对日志更新数据进行数据处理及存储。第一处理单元可以通过单进程而多线程的采集方式,适应目标容器节点中高并发的实时日志采集场景,即可以同时对目标容器节点中多个日志文件进行日志更新数据的实时采集,有效保障对日志更新数据的采集效率。且,第一处理单元负责对日志更新数据的采集,采集好日志更新数据后发送至第二处理单元进行后续处理及存储,有效实现日志更新数据的采集与后续处理的解耦,实现微服务化,可扩展性较高。
Description
技术领域
本发明涉及数据处理技术领域,尤其涉及一种数据处理方法及第一处理单元。
背景技术
随着科学技术的发展,容器集群控制技术不断提高。
其中,容器集群可以集计算、存储和网络资源为一体,为容器化的应用程序提供部署、资源调度和弹性伸缩等一系列功能。容器集群中可以包括有多个容器节点。容器节点可以是容器集群中最小的硬件单位,比如,容器节点可以为一台真实的物理机器;再比如,容器节点也可以为一个虚拟机。在容器集群中,应用程序运行时的位置、数量和时间都可以是动态变化的。现有技术可以通过专用于容器集群的日志采集工具来对容器集群进行日志数据的采集。
但是,现有技术在日志数据高并发的应用场景下,无法对日志数据进行实时采集。
发明内容
鉴于上述问题,本发明提供一种克服上述问题或者至少部分地解决上述问题的数据处理方法及第一处理单元,技术方案如下:
一种数据处理方法,应用于第一处理单元,包括:
所述第一处理单元在目标容器节点中,通过多线程采集方式,分别从多个日志文件中采集日志更新数据,所述目标容器节点为容器集群中的设置有所述第一处理单元的一个容器节点;
所述第一处理单元将采集到的所述日志更新数据发送至第二处理单元,以使得所述第二处理单元对所述日志更新数据进行数据处理及存储;其中,所述第一处理单元与所述第二处理单元不同。
可选的,所述第一处理单元从目标日志文件中采集日志更新数据,包括:
所述第一处理单元基于所述目标日志文件的文件结束符,和已保存的对所述目标日志文件的当前消费位移,确定所述目标日志文件是否存在目标更新数据,如果是,则创建与所述目标日志文件对应的一个抓取器;
所述第一处理单元调用所述抓取器,在所述目标日志文件中采集所述目标更新数据;
所述第一处理单元将采集到的所述目标更新数据存储至数据聚合单元中。
可选的,在所述第一处理单元调用所述抓取器,在所述目标日志文件中采集所述目标更新数据之后,所述方法还包括:
如果所述目标日志文件在第一预定义时长内未出现新的更新数据,则所述第一处理单元关闭所述抓取器。
可选的,在所述第一处理单元调用所述抓取器,在所述目标日志文件中采集所述目标更新数据之后,所述方法还包括:
如果所述目标日志文件的删除时长不小于第二预定义时长,则所述第一处理单元关闭所述抓取器。
可选的,在所述第一处理单元调用所述抓取器,在所述目标日志文件中采集所述目标更新数据之后,所述方法还包括:
如果所述目标日志文件出现重命名,则所述第一处理单元关闭所述抓取器。
可选的,所述第二处理单元对所述日志更新数据进行数据处理及存储,包括:
所述第二处理单元按照预定义的数据处理方式,在所述日志更新数据中添加目标字段,获得处理后数据;
所述第二处理单元确定与所述日志更新数据相匹配的索引标识;
所述第二处理单元将所述处理后数据存储至所述索引标识对应的索引中。
第一处理单元,包括:第一采集单元和第一发送单元,其中:
所述第一采集单元,用于在目标容器节点中,通过多线程采集方式,分别从多个日志文件中采集日志更新数据,所述目标容器节点为容器集群中的设置有所述第一处理单元的一个容器节点;
所述第一发送单元,用于将采集到的所述日志更新数据发送至第二处理单元,以使得所述第二处理单元对所述日志更新数据进行数据处理及存储;其中,所述第一处理单元与所述第二处理单元不同。
可选的,所述第一采集单元从目标日志文件中采集日志更新数据,设置为:
所述第一采集单元基于所述目标日志文件的文件结束符,和已保存的对所述目标日志文件的当前消费位移,确定所述目标日志文件是否存在目标更新数据,如果是,则创建与所述目标日志文件对应的一个抓取器,调用所述抓取器,在所述目标日志文件中采集所述目标更新数据,将采集到的所述目标更新数据存储至数据聚合单元中。
可选的,所述第一处理单元还包括:第一关闭单元;
所述第一关闭单元,用于在所述调用所述抓取器,在所述目标日志文件中采集所述目标更新数据之后,如果所述目标日志文件在第一预定义时长内未出现新的更新数据,则关闭所述抓取器。
可选的,所述第一处理单元还包括:第二关闭单元;
所述第二关闭单元,用于在所述调用所述抓取器,在所述目标日志文件中采集所述目标更新数据之后,如果所述目标日志文件的删除时长不小于第二预定义时长,则关闭所述抓取器。
可选的,所述第一处理单元还包括:第三关闭单元;
所述第三关闭单元,用于在所述第一处理单元调用所述抓取器,在所述目标日志文件中采集所述目标更新数据之后,如果所述目标日志文件出现重命名,则关闭所述抓取器。
可选的,所述第二处理单元对所述日志更新数据进行数据处理及存储,设置为:
所述第二处理单元按照预定义的数据处理方式,在所述日志更新数据中添加目标字段,获得处理后数据;
所述第二处理单元确定与所述日志更新数据相匹配的索引标识;
所述第二处理单元将所述处理后数据存储至所述索引标识对应的索引中。
本实施例提出的数据处理方法及第一处理单元,可以第一处理单元在目标容器节点中,通过多线程采集方式,分别从多个日志文件中采集日志更新数据,目标容器节点为容器集群中的设置有第一处理单元的一个容器节点,第一处理单元将采集到的日志更新数据发送至第二处理单元,以使得第二处理单元对日志更新数据进行数据处理及存储;其中,第一处理单元与第二处理单元不同。第一处理单元可以通过单进程而多线程的采集方式,适应目标容器节点中高并发的实时日志采集场景,即可以同时对目标容器节点中多个日志文件进行日志更新数据的实时采集,保障和提高对日志更新数据的采集效率。且,第一处理单元负责对日志更新数据的采集,采集好日志更新数据后发送至第二处理单元进行后续处理及存储,即可以实现日志更新数据的采集与后续处理的分离,有效实现了采集与后续处理的解耦,实现微服务化,可扩展性较高。
上述说明仅是本发明技术方案的概述,为了能够更清楚地了解本发明的技术手段,可依照说明书的内容予以实施,并且为了让本发明的上述和其它目的、特征和优点能够更明显易懂,以下特举本发明的具体实施方式。
附图说明
为了更清楚地说明本申请实施例或现有技术中的技术方案,下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图仅仅是本申请的实施例,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据提供的附图获得其他的附图。
图1示出了本发明实施例提供的第一种数据处理方法的流程图;
图2示出了本发明实施例提供的第一种第一处理单元的结构示意图。
具体实施方式
下面将参照附图更详细地描述本发明的示例性实施例。虽然附图中显示了本发明的示例性实施例,然而应当理解,可以以各种形式实现本发明而不应被这里阐述的实施例所限制。相反,提供这些实施例是为了能够更透彻地理解本发明,并且能够将本发明的范围完整的传达给本领域的技术人员。
如图1所示,本实施例提出了第一种数据处理方法,可以应用于第一处理单元。该方法可以包括以下步骤:
S101、第一处理单元在目标容器节点中,通过多线程采集方式,分别从多个日志文件中采集日志更新数据,目标容器节点为容器集群中的设置有第一处理单元的一个容器节点;
其中,第一处理单元可以是用于从目标容器节点中采集日志数据的多线程应用程序或者实体单元。本发明对于第一处理单元的具体类型不作限定,比如,第一处理单元可以为Filebeat。
其中,目标容器节点可以为容器集群中安装有第一处理单元的一个容器节点。
其中,多线程采集方式可以为第一处理单元在一个进程中并发多个线程,使用多个线程同时进行数据采集的方式。
需要说明的是,容器节点中可以支撑多个应用程序运行,因此容器节点中可以设置有多个用于记录应用程序在运行过程中发生变化的配置数据和运行数据等数据的日志文件。
其中,日志更新数据可以为日志文件的更新数据。
具体的,第一处理单元可以在目标容器节点中,采用多线程采集方式对多个日志文件的日志更新数据进行采集。其中,线程与日志文件可以为是一一对应的,比如,第一处理单元可以执行第一线程对第一日志文件的日志更新数据进行采集,执行第二线程对第二日志文件的日志更新数据进行采集。
S102、第一处理单元将采集到的日志更新数据发送至第二处理单元,以使得第二处理单元对日志更新数据进行数据处理及存储;其中,第一处理单元与第二处理单元不同。
其中,第一处理单元采集到的日志更新数据可以为一个或多个日志文件的日志更新数据。
其中,第二处理单元可以为与第一处理单元不同的数据处理单元。第二处理单元可以对日志更新数据进行预处理,使得处理后的日志更新数据可以满足存储至相应的数据存储空间中的格式要求、索引要求和溯源要求等预定义要求。
具体的,第一处理单元可以将采集到的日志更新数据全部发送至第二处理单元,由第二处理单元对日志更新数据进行预处理。
可选的,在本实施例提出的其它数据处理方法中,步骤S102可以包括:
第二处理单元按照预定义的数据处理方式,在日志更新数据中添加目标字段,获得处理后数据;
第二处理单元确定与日志更新数据相匹配的索引标识;
第二处理单元将处理后数据存储至索引标识对应的索引中。
其中,目标字段可以包括应用程序的区分字段、数据溯源字段和/或产生时间字段等字段。
其中,处理后数据可以为添加目标字段后的日志更新数据。
具体的,第二处理单元可以确定日志更新数据对应的索引标识,之后将日志更新数据对应的处理后数据,存储至该索引标识对应的索引中。
为更好的说明第二处理单元对日志更新数据进行的数据处理过程,本实施例提出并结合具体应用场景对其进行介绍。
具体的,在容器节点中采用Filebeat作为第一处理单元来进行日志更新数据采集的应用场景中,第二处理单元可以包括Log-adapter和Ingest node。Log-adapter可以接收Filebeat发送的日志更新数据,根据service字段确定当前日志更新数据所属的应用程序,根据projectId字段确定当前日志更新数据所属的项目,根据tenantId字段确定当前日志更新数据所属的用户,然后根据这三个字段信息确认对应的索引名。Log-adapter可以周期性(如每5分钟)调用一次Elasticsearch的rollover API,判断索引是否需要滚动,如果索引大小超过max_size则可以创建出一个新的索引。如果不需要创建新的索引,则Log-adapter可以直接通过Ingest node节点,将处理后的日志更新数据存入相应的索引中。
其中,在该应用场景中,第二处理单元可以在将日志更新数据保存至索引之前,可以按照预定义的日志预处理规则,对日志更新数据进行字段处理和逻辑判断。具体的,第二处理单元可以对每一条日志更新数据增加服务标签字段service以区分服务;可以针对打印出来的堆栈异常日志根据正则匹配表达式合并为一行,并在合并过程中对处理异常日志超时的情况进行超时处理;对每一条日志更新数据增加容器字段podname和主机名字段hostname以溯源日志数据;对每一条日志更新数据提取日志级别level字段,对日志更新数据进行级别标签化存储;对日志更新数据进行格式化检查,检查日志更新数据中的message字段,是否以日期、时间开头的日志格式,如果message不是以此为格式,则添加本地时间戳为日志产生时间。
需要说明的是,第二处理单元在将日志更新数据插入索引之前,可以通过预定义好的处理管道对日志更新数据进行预处理。每个预处理过程可以包括一个或多个处理管道。其中,本发明可以通过几种Ingest API来实现该处理管道,比如PUT、GET和DELETE等。
其中,在上述应用场景中,第二处理单元可以将处理后的日志更新数据存储至Elasticsearch对应的索引中。此时,本发明还可以使用Log-service对Elasticsearch中的数据进行查询,并转发给前端进行展示,在log-service中通过curator实定期清理大小超过阈值的索引的功能。Log-service可以从Elasticsearch集群中获取各个索引,作为待执行列表,通过用户定义的过滤器,从待执行列表中删除对应的索引。
可选的,容器集群中的各容器节点均可以设置有一个第一处理单元,各第一处理单元均可以对相应的容器节点上的日志文件进行日志更新数据的采集。而各第一处理单元均可以将日志更新数据发送至一个第二处理单元中,由该第二处理单元对日志更新数据进行处理,存储至相应的数据存储空间中。
需要说明的是,在现有技术中,可以采用Fluentd在容器节点中进行日志更新数据的采集。但是,Fluentd是单线程应用,无法适应高并发的实时日志采集场景。在容器化部署模式下,各应用程序的日志以不同文件的形式分布在容器节点上,在同一时间点,Fluentd需要对接源端多个不同的日志文件。虽然Fluentd支持记录每个日志文件的位移,但是Fluentd只有一个线程进行处理,当日志文件的日志更新数据产生的过多时,Fluentd存在处理不及时的情况,当某个日志文件的日志更新数据过大时会阻塞Fluentd对其他日志文件的读取,导致消费速度跟不上数据的生产速度。且,Fluentd将日志更新数据的采集与后续处理耦合在一起进行处理,当日志更新数据产生的过快和过多时,Fluentd的性能损耗极其严重,大量耗费CPU资源,CPU占用率高,无法实时的对日志更新数据进行采集和后续处理。且,Fluentd在采集完日志更新数据后对日志更新数据进行预处理时,如果某个日志文件的日志更新数据产生的过快,则可能导致Fluentd一直在处理这个日志文件的日志更新数据,导致其他日志文件采集夯住,其占用的文件句柄也不释放。
而本发明中,第一处理单元可以通过单进程而多线程的采集方式,适应目标容器节点中高并发的实时日志采集场景,即可以同时对目标容器节点中多个日志文件进行日志更新数据的实时采集,保障和提高对日志更新数据的采集效率。而第一处理单元负责对日志更新数据的采集,采集好日志更新数据后发送至第二处理单元进行后续处理及存储,即可以实现日志更新数据的采集与后续处理的分离,有效实现了采集与后续处理的解耦,实现微服务化,可扩展性较高。
本实施例提出的数据处理方法,可以第一处理单元在目标容器节点中,通过多线程采集方式,分别从多个日志文件中采集日志更新数据,目标容器节点为容器集群中的设置有第一处理单元的一个容器节点,第一处理单元将采集到的日志更新数据发送至第二处理单元,以使得第二处理单元对日志更新数据进行数据处理及存储;其中,第一处理单元与第二处理单元不同。第一处理单元可以通过单进程而多线程的采集方式,适应目标容器节点中高并发的实时日志采集场景,即可以同时对目标容器节点中多个日志文件进行日志更新数据的实时采集,保障和提高对日志更新数据的采集效率。且,第一处理单元负责对日志更新数据的采集,采集好日志更新数据后发送至第二处理单元进行后续处理及存储,即可以实现日志更新数据的采集与后续处理的分离,有效实现了采集与后续处理的解耦,实现微服务化,可扩展性较高。
基于图1所示方法,本实施例提出第二种数据处理方法。在该方法中,第一处理单元从目标日志文件中采集日志更新数据,可以包括步骤S201、S202和S203。其中:
S201、第一处理单元基于目标日志文件的文件结束符,和已保存的对目标日志文件的当前消费位移,确定目标日志文件是否存在目标更新数据,如果是,则执行步骤S202;
需要说明的是,第一处理单元可以对日志文件中的日志数据进行监测,在监测到日志数据发生更新时,再对日志文件中的日志更新数据进行采集,而日志文件中的日志数据未发生更新时,即可以无需执行数据采集工作,避免无谓资源的浪费。
其中,目标日志文件可以为目标容器节点中的某个日志文件。
其中,目标更新数据可以为目标日志文件的日志更新数据。
具体的,第一处理单元可以存储目标日志文件的唯一文件标识和消费位移,该消费位移可以是第一处理单元上一次对目标日志文件读取的偏移量。可以理解的是,该偏移量的位置可以与目标日志文件的文件结束符(End Of File,EOF)相对应,当目标日志文件中的日志数据出现更新时,该偏移量与EOF不再对应,此时第一处理单元可以确定目标日志文件出现日志数据的更新。
具体的,第一处理单元在确定目标日志文件的日志数据出现更新时,可以执行对目标更新数据的采集工作。
S202、创建与目标日志文件对应的一个抓取器;
具体的,第一处理单元可以在确定目标日志文件的日志数据出现更新时,创建与目标日志文件对应的一个抓取器harvester。
S203、第一处理单元调用抓取器,在目标日志文件中采集目标更新数据;
具体的,第一处理单元可以调用创建的抓取器,在目标日志文件中对目标更新数据进行采集。
S204、第一处理单元将采集到的目标更新数据存储至数据聚合单元中。
具体的,第一处理单元在调用抓取器采集到目标更新数据之后,可以将目标更新数据发送至数据聚合单元中进行暂时的存储。
需要说明的是,每个容器节点中的第一处理单元,均可以在采集到容器节点中的目标更新数据之后,将目标更新数据发送至数据聚合单元进行聚合,之后数据聚合单元可以将聚合的目标更新数据发送至第二处理单元进行后续处理。
可选的,在本实施例提出的第三种数据处理方法中,在步骤S203之后,该方法还可以包括:
如果目标日志文件在第一预定义时长内未出现新的更新数据,则第一处理单元关闭抓取器。
需要说明的是,第一处理单元可以对应目标容器节点中的每个日志文件,启动一个新的抓取器,而如果某个日志文件在抓取过程中被删除或被重命名呢,则第一处理单元可能会继续读取该日志文件而不会释放该文件句柄,导致磁盘空间一直被占用,引起僵尸文件的存在。
为解决多文件并发采集场景下僵尸文件占用的问题,本发明可以在日志文件某次出现数据更新时,对日志文件的后续状态进行持续监测,当日志文件的后续状态满足预定义规则时,可以关闭抓取器,释放占用的文件句柄和相应的磁盘空间,降低第一处理器自身的负载。
具体的,第一处理器可以在确定目标日志文件在第一预定义时长内未再出现新的更新数据时,关闭目标日志文件对应的抓取器。
其中,第一预定义时长可以由技术人员根据实际情况进行制定,本发明对此不作限定,比如,第一预定义时长可以为10分钟。
可选的,在本实施例提出的第三种数据处理方法中,在步骤S203之后,该方法还可以包括:
如果目标日志文件的删除时长不小于第二预定义时长,则第一处理单元关闭抓取器。
具体的,第一处理器可以在确定目标日志文件被删除的时长已不小于第二预定义时长时,关闭目标日志文件对应的抓取器。
可选的,在本实施例提出的第三种数据处理方法中,在步骤S203之后,该方法还可以包括:
如果目标日志文件出现重命名,则第一处理单元关闭抓取器。
具体的,第一处理器可以在目标日志文件因滚存策略而重命名时,可以关闭目标日志文件对应的抓取器。
本实施例提出的数据处理方法,可以在日志文件某次出现数据更新时,对日志文件的后续状态进行持续监测,当日志文件的后续状态满足预定义规则时,可以关闭抓取器,减少对无效文件句柄的占用,减少过多僵尸文件进程的存在,从而释放占用的文件句柄和相应的磁盘空间,也可以降低第一处理器自身的负载。
与图1所示步骤相对应,如图2所示,本实施例提出第一种第一处理单元。该第一处理单元可以包括:第一采集单元101和第一发送单元102,其中:
第一采集单元101,用于在目标容器节点中,通过多线程采集方式,分别从多个日志文件中采集日志更新数据,目标容器节点为容器集群中的设置有第一处理单元的一个容器节点;
其中,第一处理单元可以是用于从目标容器节点中采集日志数据的多线程应用程序或者实体单元。本发明对于第一处理单元的具体类型不作限定,比如,第一处理单元可以为Filebeat。
其中,目标容器节点可以为容器集群中安装有第一处理单元的一个容器节点。
其中,多线程采集方式可以为第一处理单元在一个进程中并发多个线程,使用多个线程同时进行数据采集的方式。
需要说明的是,容器节点中可以支撑多个应用程序运行,因此容器节点中可以设置有多个用于记录应用程序在运行过程中发生变化的配置数据和运行数据等数据的日志文件。
其中,日志更新数据可以为日志文件的更新数据。
具体的,第一采集单元101可以在目标容器节点中,采用多线程采集方式对多个日志文件的日志更新数据进行采集。其中,线程与日志文件可以为是一一对应的,比如,第一采集单元101可以执行第一线程对第一日志文件的日志更新数据进行采集,执行第二线程对第二日志文件的日志更新数据进行采集。
第一发送单元102,用于将采集到的日志更新数据发送至第二处理单元,以使得第二处理单元对日志更新数据进行数据处理及存储;其中,第一处理单元与第二处理单元不同。
其中,第一采集单元101采集到的日志更新数据可以为一个或多个日志文件的日志更新数据。
其中,第二处理单元可以为与第一处理单元不同的数据处理单元。第二处理单元可以对日志更新数据进行预处理,使得处理后的日志更新数据可以满足存储至相应的数据存储空间中的格式要求、索引要求和溯源要求等预定义要求。
具体的,第一处理单元可以将采集到的日志更新数据全部发送至第二处理单元,由第二处理单元对日志更新数据进行预处理。
可选的,在本实施例提出的其它第一处理单元中,第二处理单元对日志更新数据进行数据处理及存储,设置为:
第二处理单元按照预定义的数据处理方式,在日志更新数据中添加目标字段,获得处理后数据;
第二处理单元确定与日志更新数据相匹配的索引标识;
第二处理单元将处理后数据存储至索引标识对应的索引中。
其中,目标字段可以包括应用程序的区分字段、数据溯源字段和/或产生时间字段等字段。
其中,处理后数据可以为添加目标字段后的日志更新数据。
具体的,第二处理单元可以确定日志更新数据对应的索引标识,之后将日志更新数据对应的处理后数据,存储至该索引标识对应的索引中。
需要说明的是,第一处理单元可以通过单进程而多线程的采集方式,适应目标容器节点中高并发的实时日志采集场景,即可以同时对目标容器节点中多个日志文件进行日志更新数据的实时采集,保障和提高对日志更新数据的采集效率。而第一处理单元负责对日志更新数据的采集,采集好日志更新数据后发送至第二处理单元进行后续处理及存储,即可以实现日志更新数据的采集与后续处理的分离,有效实现了采集与后续处理的解耦,实现微服务化,可扩展性较高。
本实施例提出的第一处理单元,可以通过单进程而多线程的采集方式,适应目标容器节点中高并发的实时日志采集场景,即可以同时对目标容器节点中多个日志文件进行日志更新数据的实时采集,保障和提高对日志更新数据的采集效率。且,第一处理单元负责对日志更新数据的采集,采集好日志更新数据后发送至第二处理单元进行后续处理及存储,即可以实现日志更新数据的采集与后续处理的分离,有效实现了采集与后续处理的解耦,实现微服务化,可扩展性较高。
基于图2,本实施例提出第二种第一处理单元。在该第一处理单元中,第一采集单元101从目标日志文件中采集日志更新数据,设置为:
第一采集单元101基于目标日志文件的文件结束符,和已保存的对目标日志文件的当前消费位移,确定目标日志文件是否存在目标更新数据,如果是,则创建与目标日志文件对应的一个抓取器,调用抓取器,在目标日志文件中采集目标更新数据,将采集到的目标更新数据存储至数据聚合单元中。
需要说明的是,第一采集单元101可以对日志文件中的日志数据进行监测,在监测到日志数据发生更新时,再对日志文件中的日志更新数据进行采集,而日志文件中的日志数据未发生更新时,即可以无需执行数据采集工作,避免无谓资源的浪费。
其中,目标日志文件可以为目标容器节点中的某个日志文件。
其中,目标更新数据可以为目标日志文件的日志更新数据。
具体的,第一采集单元101可以存储目标日志文件的唯一文件标识和消费位移,该消费位移可以是第一采集单元101上一次对目标日志文件读取的偏移量。可以理解的是,该偏移量的位置可以与目标日志文件的文件结束符(End Of File,EOF)相对应,当目标日志文件中的日志数据出现更新时,该偏移量与EOF不再对应,此时第一采集单元101可以确定目标日志文件出现日志数据的更新。
具体的,第一采集单元101在确定目标日志文件的日志数据出现更新时,可以执行对目标更新数据的采集工作。
具体的,第一采集单元101可以在确定目标日志文件的日志数据出现更新时,创建与目标日志文件对应的一个抓取器harvester。
具体的,第一采集单元101可以调用创建的抓取器,在目标日志文件中对目标更新数据进行采集。
具体的,第一采集单元101在调用抓取器采集到目标更新数据之后,可以将目标更新数据发送至数据聚合单元中进行暂时的存储。
需要说明的是,每个容器节点中的第一采集单元101,均可以在采集到容器节点中的目标更新数据之后,将目标更新数据发送至数据聚合单元进行聚合,之后数据聚合单元可以将聚合的目标更新数据发送至第二处理单元进行后续处理。
可选的,在本实施例提出的第三种第一处理单元中,第一处理单元还包括:第一关闭单元;
第一关闭单元,用于在调用抓取器,在目标日志文件中采集目标更新数据之后,如果目标日志文件在第一预定义时长内未出现新的更新数据,则关闭抓取器。
需要说明的是,第一采集单元101可以对应目标容器节点中的每个日志文件,启动一个新的抓取器,而如果某个日志文件在抓取过程中被删除或被重命名呢,则第一采集单元101可能会继续读取该日志文件而不会释放该文件句柄,导致磁盘空间一直被占用,引起僵尸文件的存在。
为解决多文件并发采集场景下僵尸文件占用的问题,本发明可以在日志文件某次出现数据更新时,对日志文件的后续状态进行持续监测,当日志文件的后续状态满足预定义规则时,可以关闭抓取器,释放占用的文件句柄和相应的磁盘空间,降低第一处理器自身的负载。
具体的,第一关闭单元可以在确定目标日志文件在第一预定义时长内未再出现新的更新数据时,关闭目标日志文件对应的抓取器。
其中,第一预定义时长可以由技术人员根据实际情况进行制定,本发明对此不作限定,比如,第一预定义时长可以为10分钟。
可选的,在本实施例提出的第三种第一处理单元中,第一处理单元还包括:第二关闭单元;
第二关闭单元,用于在调用抓取器,在目标日志文件中采集目标更新数据之后,如果目标日志文件的删除时长不小于第二预定义时长,则关闭抓取器。
其中,第二关闭单元与第一关闭单元可以是同一单元,也可以是不同单元,本发明对此不作限定。
具体的,第二关闭单元可以在确定目标日志文件被删除的时长已不小于第二预定义时长时,关闭目标日志文件对应的抓取器。
可选的,在本实施例提出的第三种第一处理单元中,第一处理单元还包括:第三关闭单元;
第三关闭单元,用于在第一处理单元调用抓取器,在目标日志文件中采集目标更新数据之后,如果目标日志文件出现重命名,则关闭抓取器。
具体的,第三关闭单元可以在目标日志文件因滚存策略而重命名时,可以关闭目标日志文件对应的抓取器。
需要说明的是,第一关闭单元、第二关闭单元和第三关闭单元可以是同一单元,也可以为不同单元。
本实施例提出的第一处理单元,可以在日志文件某次出现数据更新时,对日志文件的后续状态进行持续监测,当日志文件的后续状态满足预定义规则时,可以关闭抓取器,减少对无效文件句柄的占用,减少过多僵尸文件进程的存在,从而释放占用的文件句柄和相应的磁盘空间,也可以降低第一处理器自身的负载。
还需要说明的是,术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含,从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素,而且还包括没有明确列出的其他要素,或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下,由语句“包括一个……”限定的要素,并不排除在包括要素的过程、方法、商品或者设备中还存在另外的相同要素。
以上仅为本申请的实施例而已,并不用于限制本申请。对于本领域技术人员来说,本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等,均应包含在本申请的权利要求范围之内。
Claims (10)
1.一种数据处理方法,其特征在于,应用于第一处理单元,包括:
所述第一处理单元在目标容器节点中,通过多线程采集方式,分别从多个日志文件中采集日志更新数据,所述目标容器节点为容器集群中的设置有所述第一处理单元的一个容器节点;
所述第一处理单元将采集到的所述日志更新数据发送至第二处理单元,以使得所述第二处理单元对所述日志更新数据进行数据处理及存储;其中,所述第一处理单元与所述第二处理单元不同。
2.根据权利要求1所述的数据处理方法,其特征在于,所述第一处理单元从目标日志文件中采集日志更新数据,包括:
所述第一处理单元基于所述目标日志文件的文件结束符,和已保存的对所述目标日志文件的当前消费位移,确定所述目标日志文件是否存在目标更新数据,如果是,则创建与所述目标日志文件对应的一个抓取器;
所述第一处理单元调用所述抓取器,在所述目标日志文件中采集所述目标更新数据;
所述第一处理单元将采集到的所述目标更新数据存储至数据聚合单元中。
3.根据权利要求2所述的数据处理方法,其特征在于,在所述第一处理单元调用所述抓取器,在所述目标日志文件中采集所述目标更新数据之后,所述方法还包括:
如果所述目标日志文件在第一预定义时长内未出现新的更新数据,则所述第一处理单元关闭所述抓取器。
4.根据权利要求2所述的数据处理方法,其特征在于,在所述第一处理单元调用所述抓取器,在所述目标日志文件中采集所述目标更新数据之后,所述方法还包括:
如果所述目标日志文件的删除时长不小于第二预定义时长,则所述第一处理单元关闭所述抓取器。
5.根据权利要求2所述的数据处理方法,其特征在于,在所述第一处理单元调用所述抓取器,在所述目标日志文件中采集所述目标更新数据之后,所述方法还包括:
如果所述目标日志文件出现重命名,则所述第一处理单元关闭所述抓取器。
6.根据权利要求1所述的数据处理方法,其特征在于,所述第二处理单元对所述日志更新数据进行数据处理及存储,包括:
所述第二处理单元按照预定义的数据处理方式,在所述日志更新数据中添加目标字段,获得处理后数据;
所述第二处理单元确定与所述日志更新数据相匹配的索引标识;
所述第二处理单元将所述处理后数据存储至所述索引标识对应的索引中。
7.第一处理单元,其特征在于,包括:第一采集单元和第一发送单元,其中:
所述第一采集单元,用于在目标容器节点中,通过多线程采集方式,分别从多个日志文件中采集日志更新数据,所述目标容器节点为容器集群中的设置有所述第一处理单元的一个容器节点;
所述第一发送单元,用于将采集到的所述日志更新数据发送至第二处理单元,以使得所述第二处理单元对所述日志更新数据进行数据处理及存储;其中,所述第一处理单元与所述第二处理单元不同。
8.根据权利要求7所述的第一处理单元,其特征在于,所述第一采集单元从目标日志文件中采集日志更新数据,设置为:
所述第一采集单元基于所述目标日志文件的文件结束符,和已保存的对所述目标日志文件的当前消费位移,确定所述目标日志文件是否存在目标更新数据,如果是,则创建与所述目标日志文件对应的一个抓取器,调用所述抓取器,在所述目标日志文件中采集所述目标更新数据,将采集到的所述目标更新数据存储至数据聚合单元中。
9.根据权利要求8所述的第一处理单元,其特征在于,在所述调用所述抓取器,在所述目标日志文件中采集所述目标更新数据之后,所述第一采集单元还用于:
如果所述目标日志文件在第一预定义时长内未出现新的更新数据,则所述第一处理单元关闭所述抓取器。
10.根据权利要求8所述的第一处理单元,其特征在于,在所述第一处理单元调用所述抓取器,在所述目标日志文件中采集所述目标更新数据之后,所述第一采集单元还用于:
如果所述目标日志文件的删除时长不小于第二预定义时长,则所述第一处理单元关闭所述抓取器。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202111416263.7A CN114064676A (zh) | 2021-11-25 | 2021-11-25 | 一种数据处理方法及第一处理单元 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202111416263.7A CN114064676A (zh) | 2021-11-25 | 2021-11-25 | 一种数据处理方法及第一处理单元 |
Publications (1)
Publication Number | Publication Date |
---|---|
CN114064676A true CN114064676A (zh) | 2022-02-18 |
Family
ID=80276219
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202111416263.7A Pending CN114064676A (zh) | 2021-11-25 | 2021-11-25 | 一种数据处理方法及第一处理单元 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN114064676A (zh) |
-
2021
- 2021-11-25 CN CN202111416263.7A patent/CN114064676A/zh active Pending
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US20200133750A1 (en) | Methods, apparatus and computer programs for managing persistence | |
US9467460B1 (en) | Modularized database architecture using vertical partitioning for a state machine | |
US8954971B2 (en) | Data collecting method, data collecting apparatus and network management device | |
CN106802826B (zh) | 一种基于线程池的业务处理方法及装置 | |
US12008027B2 (en) | Optimization for real-time, parallel execution of models for extracting high-value information from data streams | |
US20070180102A1 (en) | Method and apparatus for analyzing idle states in a data processing system | |
CN113238913A (zh) | 服务器故障智能推送方法、装置、设备及存储介质 | |
CN102467412B (zh) | 一种处理操作请求的方法、装置及业务系统 | |
CN107515784B (zh) | 一种在分布式系统中计算资源的方法与设备 | |
WO2013165450A1 (en) | Process scheduling using scheduling graph to minimize managed elements | |
CN107783881B (zh) | 基于内存队列的网站动态性能监控方法及系统 | |
CN103645904A (zh) | 一种接口调用的缓存实现方法 | |
CN105069029B (zh) | 一种实时etl系统及方法 | |
JP2000155719A (ja) | デ―タのバックアップ・復旧システムおよび非同期デ―タ管理方法 | |
US20060143150A1 (en) | Messaging system and method of operation thereof | |
EP3011456B1 (en) | Sorted event monitoring by context partition | |
JP2013171542A (ja) | 性能分析装置、性能分析方法及び性能分析プログラム | |
CN112948096A (zh) | 一种批量调度方法、装置和设备 | |
CN114064676A (zh) | 一种数据处理方法及第一处理单元 | |
CN111597056A (zh) | 一种分布式调度方法、系统、存储介质和设备 | |
US7984189B2 (en) | Recording medium storing slip data processing program, method of processing slip data, and slip data processing device | |
CN112817687A (zh) | 一种数据同步方法和装置 | |
CN110765081A (zh) | 一种数据删除方法和装置 | |
CN111913996B (zh) | 数据处理方法、装置、设备及存储介质 | |
CN113342836A (zh) | 同步数据处理方法、装置、计算机设备及存储介质 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication | ||
SE01 | Entry into force of request for substantive examination | ||
SE01 | Entry into force of request for substantive examination |