日志数据处理方法及***
【技术领域】
本申请涉及互联网技术领域,尤其涉及一种日志数据处理方法及***。
【背景技术】
海量日志数据的处理本质上属于大数据计算,业界有着众多成熟的解决方案,例如以Hadoop为代表的后计算流和以Storm为代表的预计算流。与Hadoop相比,Storm是个实时的、分布式以及具备高容错的计算***,Storm在保证高可靠性的前提下还可以让处理进行的更加实时。
Storm计算流的过程为:在产生日志的宿主机上部署客户端(agent);每当宿主机有新的日志数据输出到日志(log)文件时,客户端将新的日志数据直接传输到Storm计算集群,Storm计算集群负责完成日志数据的计算和存储。
在实际应用中,有时需要对一定时间段内的日志数据一起进行处理,例如在对周期型日志数据进行实时处理的应用场景中,日志数据的处理是以周期为单位的,这就需要Storm计算集群能够确定同一周期内的日志数据全部到齐,然后再进行处理。目前,Storm计算集群可以根据当前时间判断同一周期的日志数据是否全部到齐,例如若当前时间为14:03:30秒,则认为14:02分这一周期内的日志数据全部到齐;或者,Storm计算集群可以根据当前接收的数据来判断同一周期内的日志数据是否全部到齐,例如若接收到14:03分这一周期内的日志数据,则认为14:02分这一周期内的日志数据全部到齐。
现有判断同一周期内的日志数据是否全部到齐的两种方式都比较绝对,均未考虑从客户端到Storm计算集群的传输路径造成日志数据的丢失或超时等情况。也就是说,现有两种方式实际上并不能严格保证同一周期内的日志数据全部到齐,这就导致采用Storm计算集群对周期型日志数据进行实时处理的结果的可靠性较低。
【发明内容】
本申请的多个方面提供一种日志数据处理方法及***,用以在对日志数据进行实时处理的同时,提高处理结果的可靠性。
本申请的一方面,提供一种日志数据处理方法,适用于日志数据处理***,所述日志数据处理***包括映射节点和执行节点,所述方法包括:
执行当前日志数据处理任务中的关联预处理子任务的映射节点向所述映射节点对应的目标客户端代理装置发送查询请求,并接收所述目标客户端代理装置根据所述查询请求返回的当前日志数据处理任务所需的目标日志数据;
其中,所述目标客户端代理装置是部署于产生所述目标日志数据的日志宿主机上的客户端代理装置,所述查询请求包括:日志文件标识和时间段标识,所述目标日志数据是所述日志文件标识所标识的日志文件中在所述时间段标识所标识的时间段内产生的日志数据;
若所述映射节点接收到所述映射节点对应的所有所述目标客户端代理装置返回的所述目标日志数据,对所有接收到的所述目标日志数据进行关联预处理,并将关联预处理结果发送给执行当前日志数据处理任务中的关联处理子任务的归纳节点;
若所述归纳节点接收到所有执行关联预处理子任务的所述映射节点发送的所述关联预处理结果,对所有接收到的所述关联预处理结果进行关联处理,并输出关联处理结果。
本申请的另一方面,提供一种日志数据处理***,包括:映射节点和归纳节点,所述归纳节点与所述映射节点连接;
所述映射节点,用于在执行日志数据处理任务中的关联预处理子任务时,向所述映射节点对应的目标客户端代理装置发送查询请求,接收所述目标客户端代理装置根据所述查询请求返回的当前日志数据处理任务所需的目标日志数据,并在接收到所述映射节点对应的所有所述目标客户端代理装置返回的所述目标日志数据时,对所有接收到的所述目标日志数据进行关联预处理,并将关联预处理结果发送给所述归纳节点;
其中,所述目标客户端代理装置是部署于产生所述目标日志数据的日志宿主机上的客户端代理装置,所述查询请求包括:日志文件标识和时间段标识,所述目标日志数据是所述日志文件标识所标识的日志文件中在所述时间段标识所标识的时间段内产生的日志数据;
所述归纳节点,用于在执行当前日志数据处理任务中的关联处理子任务时,接收所述映射节点发送的所述关联预处理结果,并在接收到所有执行关联预处理子任务的当前日志数据处理任务的所述映射节点发送的所述关联预处理结果,对所有接收到的所述关联预处理结果进行关联处理,并输出关联处理结果。
在本申请中,执行当前日志数据处理任务的映射节点和部署于产生当前日志数据处理任务所需的目标日志数据的日志宿主机上的客户端代理装置相配合,可以准确获取指定时间段内产生的日志数据,使得日志数据处理***可以及时对日志数据进行处理,实现对日志数据的实时处理;另外,客户端代理装置允许映射节点获取指定时间段内产生的日志数据,为保证日志数据处理任务所需的日志数据全部到齐日志数据处理***打下了基础,进一步在日志数据处理***内部,映射节点通过判断,只有在来自映射节点对应的所有客户端代理装置的日志数据全部到齐时,才执行关联预处理并将关联预处理结果发送给归纳节点,归纳节点通过判断,只有在来自所有执行日志数据处理任务的映射节点的关联预处理结果全部到齐后,才对所有关联预处理结果进行关联处理,并最终输出关联处理结果,由于每一步处理都能够保证在所需数据全部到齐的情况下执行,因此可以提高处理结果的可靠性。
【附图说明】
为了更清楚地说明本申请实施例中的技术方案,下面将对实施例或现有技术描述中所需要使用的附图作一简单地介绍,显而易见地,下面描述中的附图是本申请的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动性的前提下,还可以根据这些附图获得其他的附图。
图1为本申请一实施例提供的日志数据处理方法的流程示意图;
图2为本申请一实施例提供的日志数据处理***的简化结构示意图;
图3为本申请一实施例提供的日志数据处理***的结构示意图。
【具体实施方式】
为使本申请实施例的目的、技术方案和优点更加清楚,下面将结合本申请实施例中的附图,对本申请实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例是本申请一部分实施例,而不是全部的实施例。基于本申请中的实施例,本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例,都属于本申请保护的范围。
图1为本申请一实施例提供的日志数据处理方法的流程示意图。如图1所示,该方法包括:
101、日志数据处理***中执行当前日志数据处理任务中的关联预处理子任务的映射节点向该映射节点对应的目标客户端代理装置发送查询请求,并接收该目标客户端代理装置根据查询请求返回的当前日志数据处理任务所需的目标日志数据;其中,目标客户端代理装置是部署于产生目标日志数据的日志宿主机上的客户端代理装置,查询请求包括:日志文件标识和时间段标识,目标日志数据是该日志文件标识所标识的日志文件中在该时间段标识所标识的时间段内产生的日志数据。
102、若上述映射节点接收到映射节点对应的所有目标客户端代理装置返回的目标日志数据,对所有接收到的目标日志数据进行关联预处理,并将关联预处理结果发送给日志数据处理***中执行当前日志数据处理任务中的关联处理子任务的归纳节点。
103、若归纳节点接收到所有执行关联预处理子任务的映射节点发送的关联预处理结果,对所有接收到的关联预处理结果进行关联处理,并输出关联处理结果。
本实施例提供的方法可由日志数据处理***来执行,日志数据处理***是指负责对日志数据进行处理的***,可以包括映射节点(Mapper)和归纳节点(Reducer),映射节点和归纳节点相互配合完成日志数据处理任务。例如,该日志数据处理***可以是但不限于:优化和改进后的spark***,或者优化和改进后的Hadoop***。
其中,日志宿主机是指产生日志数据的各种设备,例如可以是计算机、生产***的服务器等。在本实施例中,一次日志数据处理任务可由关联预处理子任何和关联处理子任务构成。
具体的,在执行当前日志数据处理任务过程中,映射节点主要负责关联预处理子任务,该关联预处理子任务主要包括日志数据采集、日志数据解析、对日志数据的关联预处理以及将关联预处理结果发送给归纳节点;这里的关联预处理主要是指对日志数据进行合并处理,以获得归纳节点中第一层逻辑节点所需的处理结果的过程。而归纳节点主要负责关联处理子任务,关联处理子任务主要包括:接收映射节点发送的关联预处理结果,并对关联预处理结果进行关联处理,输出关联处理结果。归纳节点内部的关联处理主要是指归纳节点内部包括的多层逻辑处理节点进行处理的过程。
由于在现有技术中,无论是以Hadoop为代表的后计算流还是以Storm为代表的预计算流,均无法保证需要处理的日志数据全部到齐,从而导致处理结果不准确。该问题可以简称为“日志数据齐全度问题”,本实施例具体采用以下几点解决现有技术存在的日志数据齐全度问题:
第一点:利用客户端代理装置保证采集日志数据时的齐全度。
日志数据产生后会存储在日志宿主机上的日志文件中。通常,日志数据在日志宿主机上并不是永久保留,一般是按天滚动,保留固定天数之后会被删除,但是一般情况下日志数据在日志宿主机上的保留时间已经足够满足以实时分析为主要目标的监控计算等场景。
日志宿主机本身可以提供日志的查询服务。但是,日志宿主机一般是直接向最终用户提供服务的,不能因为日志分析而消耗过多性能。为了尽量不影响日志宿主机的性能,本实施例在日志宿主机上部署客户端代理装置,由客户端代理装置提供日志查询功能,并且尽量将日志查询功能带来的性能消耗局限在必需的网络带宽上,不产生其他性能消耗。也就是说,本实施例中部署于日志宿主机上的客户端代理装置能够准确提供指定时间段内产生的日志数据的查询功能,这样就可以保证当前日志数据处理任务所需的目标日志数据从日志宿主机进入日志数据处理***时就是齐全的。
为了实现能够准确提供指定时间段内产生的日志数据的查询功能,客户端代理装置需要为日志宿主机在不同时间产生的日志数据创建用于指示该日志数据在日志文件中的位置的位置索引。这样,客户端代理装置就可以根据位置索引快速找到待查询的日志数据,降低对日志宿主机的性能消耗。
例如,以对周期型日志数据进行实时处理的应用场景为例,在该应用场景中,日志数据处理任务都是周期性的,这里的周期性是指每次日中数据处理任务都要处理相同时间段内产生的日志数据,例如每个任务周期均需处理一分钟内产生的日志数据以产出这一周期的日志分析结果,这种任务需要查询的是某分钟,例如2014-11-1111:11这一分钟内产生的日志数据。基于此,本实施例设定单位周期,以单位周期内产生的日志数据为最小数据单位进行存储和查询。其中,单位周期可以是1秒、1分钟、2分钟、3分钟、1小时等,具体可以根据用户需求而定。基于此,上述查询请求包括的时间段标识所标识的时间段包括至少一个单位周期。意味着,映射节点一次查询请求可以查询至少一个单位周期内产生的日志数据。
基于上述,客户端代理装置应该为日志宿主机在每个单位周期内产生的日志数据创建位置索引。
值得说明的是,位置索引可以用日志数据在日志文件中的起始字节位置和日志数据的字节长度来表示;或者,位置索引也可以用日志数据在日志文件中的起始字节位置和结束字节位置来表示。
具体的,对于每个单位周期,客户端代理装置对该单位周期的上一个单位周期的尾部数据进行解析,确定该单位周期内产生的日志数据的起始位置,并对该单位周期的尾部数据进行解析,确定该单位周期内产生的日志数据的长度,作为该单位周期内产生的日志数据的位置索引。其中,该单位周期的尾部数据是指在该单位周期即将结束时产生的日志数据。
简单来说,上述实施方式主要是利用了日志打印的特点,即时间增序打印(意思是不可能出现较晚产生的日志数据打印在较早产生的日志数据之前),在相邻单位周期交替的时刻,客户端代理装置从单位周期内产生的日志数据的末尾读取少量字节进行解析,确定当前单位周期内产生的日志数据的结束点以及下一单位周期内产生的日志数据的起始点。
例如,对于单位周期T和单位周期T+1,如果对单位周期T内产生的日志数据的末尾进行分析,确定该末尾数据的下一字节是单位周期T+1内产生的日志数据,那说明在这个位置单位周期T内产生的日志数据已经全部结束,而单位周期T+1内产生的日志数据刚刚开始,这个末尾数据就是两个相邻单位周期的交替点。找到交替点之后,客户端代理装置就可以得到单位周期T内产生的日志数据的结束点位置(其中,根据起始点位置和结束点位置可以计算出日志数据的字节长度),以及单位周期T+1产生的日志数据的起始点位置;如此循环反复,就能得到每个单位周期内产生的日志数据的起始点位置和字节长度,即位置索引。
基于上述,当有日志数据处理任务时,负责执行该日志数据处理任务中的关联预处理子任务的映射节点可以通过向客户端代理装置发送查询请求,并在查询请求中携带日志文件标识和时间段标识,从客户端代理装置获取到该日志数据处理任务所需的日志数据。为便于描述,以当前日志数据处理任务为例,并将当前日志数据处理任务涉及的客户端代理装置称为目标客户端代理装置,将当前日志数据处理任务所需的日志数据称为目标日志数据,若当前日志数据处理任务所需的日志数据来自多台日志宿主机,则来自每台日志宿主机的日志数据可分别称为目标日志数据。当前日志数据处理任务所需的目标日志数据也就是该日志文件标识所标识的日志文件中在该时间段标识所标识的时间段内产生的日志数据。
对目标客户端代理装置来说,接收映射节点发送的查询请求后,可以根据其中的日志文件标识,确定存储该目标日志数据的日志文件,进而根据时间段标识找到在该时间段标识所标识的时间段内产生的日志数据,并将找到的日志数据作为目标日志数据返回给映射节点。
例如,基于上述位置索引,当映射节点用周期14:02分作为参数来查询目标客户端代理装置时,目标客户端代理装置可以根据日志数据的位置索引返回不多不少的日志数据。这就解决了映射节点采集日志数据时的齐全度问题。
值得说明的是,由于客户端代理装置具有保证采集日志数据时的齐全度的能力,所以映射节点可以在任意时刻启动采集日志数据的操作,不用担心启动采集日志数据的操作的时机不合适导致日志数据采集不齐全的问题。
例如,仍以对周期型日志数据进行实时处理的应用场景为例,映射节点其实可以在14:03:00秒就启动“采集14:02分这一周期产生的日志数据”的任务,因为当映射节点发起查询请求到目标客户端代理装置时,目标客户端代理装置可以根据当前位置索引的构建状况酌情处理:若14:02分这一周期产生的日志数据的位置索引已经产出,那就可以直接检索到相应的日志数据并返回;若还未产出,那就返回查询失败,映射节点的采集任务做失败处理。
第二点:通过映射节点的处理逻辑保证日志数据预处理阶段数据的齐全度。
映射节点与目标客户端代理装置相配合,可以保证来自目标客户端代理装置的目标日志数据都是指定时间段内产生的日志数据。但是考虑到一次日志数据处理任务可能同时涉及至少两台日志宿主机产生的日志数据,也就是说映射节点可能需要负责从至少两个客户端代理装置采集日志数据,这对映射节点来说,需要解决至少两个客户端代理装置返回的目标日志数据到达时的齐全度问题。
在本实施例中,映射节点在向目标客户端代理装置发送查询请求后,接收目标客户端代理装置返回的目标日志数据,之后判断是否接收到当前日志数据处理任务涉及的所有目标客户端代理装置返回的目标日志数据,只有在接收到当前日志数据处理任务涉及的所有目标客户端代理装置返回的目标日志数据的情况下,才对所有接收到的目标日志数据进行解析,并对解析后的目标日志数据进行关联预处理,进而将关联预处理结果发送给归纳节点。
在一可选实施方式中,日志数据处理***还包括任务管理节点,负责进行任务编排。任务管理节点会定时驱动任务编排,并将编排好的任务发送到映射节点和归纳节点。这里的任务编排主要涉及日志数据处理任务涉及到多少个目标日志数据(对应于目标客户端代理装置的个数)、多少个关联预处理子任务(对应于映射节点的个数)以及目标日志数据与关联预处理子任务之间的映射关系(也就是目标客户端代理装置与映射节点之间的对应关系,简单来说就是一个映射节点负责几个目标客户端代理装置以及哪几个目标客户端代理装置等)等等。
对于映射节点来说,可以预先配置该映射节点对应的目标客户端代理装置的标识信息。目标客户端代理装置的标识信息可以是其IP地址,名称等。一种确定映射节点与目标客户端代理装置之间的对应关系的实施方式包括:任务管理节点确定当前日志数据处理任务涉及的日志宿主机的个数和执行当前日志数据处理任务的映射节点的个数;根据日志宿主机的个数和执行当前日志数据处理任务的映射节点的个数,确定每个映射节点分别对应的目标客户端代理装置,并将每个映射节点对应的目标客户端代理装置的标识信息提供给每个映射节点。
假设当前日志数据处理任务涉及的日志宿主机有N台,即涉及的目标客户端代理装置有N个,日志数据处理***中负责日志数据关联预处理子任务的映射节点有M个,可以采用预设的分配算法确定每个映射节点对应的目标客户端代理装置。分配算法可以是对目标客户端代理装置进行排序,例如可以根据目标客户端代理装置的IP地址,将IP地址转换为一个长整(long)型数值,将long型数值按递增排序,得到目标客户端代理装置的排序;采用同样的方式对映射节点进行排序;根据预先设定的算法公式,例如m=n/(N/M)得到每个映射节点对应的目标客户端代理装置,在该算法公式中,n表示目标客户端代理装置的序号,m表示映射节点需要对应的目标客户端代理装置的序号,比如有100个目标客户端代理装置,20个映射节点,那第3个目标客户端代理装置应该由第0个映射节点对应,即(3/(100/20)=0),第6个目标客户端代理装置应该由第1个映射节点对应,即(6/(100/20)=1),以此类推,获得每个映射节点对应的目标客户端代理装置。值得说明的是,对于上述算法公式除不尽等情况可以做些微调。
通过上述方式确定出每个映射节点对应的目标客户端代理装置,这样就可以为每个映射节点配置对应的目标客户端代理装置的标识信息。基于此,当映射节点接收到目标日志数据时,记录返回该目标日志数据的目标客户端代理装置的标识信息,并将记录的返回目标日志数据的目标客户端代理装置的标识信息与预先配置的客户端代理装置的标识信息进行比较;若所记录的返回目标日志数据的目标客户端代理装置的标识信息与预先配置的客户端代理装置的标识信息完全相同,确定接收到该映射节点对应的所有目标客户端代理装置返回的目标日志数据。
在此说明,在上述实施方式中,目标客户端代理装置可以一次性将目标日志数据发送给所对应的映射节点。或者,目标客户端代理装置也可以采用串行方式多次分批将目标日志数据传输给所对应的映射节点。例如可以采用远程过程调用协议(RemoteProcedure Call Protocol,RPC)传输方式。实际上来说,无论是一次性传输还是多次分批传输,目标客户端代理装置要保证目标日志数据是以“任务驱动”的,保证目标日志数据具有事务属性,要么全部传输成功,要么全部传输失败。基于此,映射节点可以根据每个目标日志数据的结束标识来判断目标日志数据是否传输结束,并在确定目标日志数据传输结束时,才会记录传输该目标日志数据的目标客户端代理装置的标识信息。目标日志数据的结束标识可以是目标日志数据自身携带的时间戳,或者可以是目标客户端代理装置在目标日志数据中添加的专用标识。
值得注意的是,即使目标客户端代理装置没有获取到任何目标日志数据,即返回为空,也需要正常向映射节点返回“空输出”,以便于映射节点能够记录该目标客户端代理装置的标识信息。
第三点:通过归纳节点的处理逻辑保证关联处理阶段数据的齐全度。
归纳节点接收映射节点发送的预处理结果,有可能当前日志数据处理任务涉及至少两个映射节点,于是归纳节点判断是否接收到当前日志数据处理任务涉及的所有映射节点发送的预处理结果,只有在接收到当前日志数据处理任务涉及的所有映射节点发送的预处理结果的情况下,才对所有接收到的预处理结果进行关联处理,并产生关联处理结果。
在一可选实施方式中,对于归纳节点来说,可以预先配置当前日志数据处理任务涉及的映射节点的标识信息。映射节点的标识信息可以是其IP地址,名称等。基于此,当归纳节点接收到关联预处理结果时,记录返回该关联预处理结果的映射节点的标识信息,并将记录的返回关联预处理结果的映射节点的标识信息与预先配置的映射节点的标识信息进行比较;若所记录的返回关联预处理结果的映射节点的标识信息与预先配置的映射节点的标识信息完全相同,确定接收到所有执行当前日志数据处理任务的映射节点返回的关联预处理结果。
在本实施例中,归纳节点可以包括多层逻辑处理节点,其中,所有第一层逻辑处理节点的合并处理结果,作为第二层逻辑处理节点的输入,所有第二层逻辑节点的合并处理结果,作为第三层逻辑处理节点的输入,……,直到所有逻辑处理节点的处理均结束并输出最终的关联处理结果。
由上述可见,在本实施例中,执行当前日志数据处理任务的映射节点和部署于产生当前日志数据处理任务所需的目标日志数据的日志宿主机上的客户端代理装置相配合,可以准确获取指定时间段内产生的日志数据,使得日志数据处理***可以及时对日志数据进行处理,实现对日志数据的实时处理;另外,客户端代理装置允许映射节点获取指定时间段内产生的日志数据,为保证日志数据处理任务所需的日志数据全部到齐日志数据处理***打下了基础,进一步在日志数据处理***内部,映射节点通过判断,只有在来自映射节点对应的所有客户端代理装置的日志数据全部到齐时,才执行关联预处理并将关联预处理结果发送给归纳节点,归纳节点通过判断,只有在来自所有执行日志数据处理任务的映射节点的关联预处理结果全部到齐后,才对所有关联预处理结果进行关联处理,并最终输出关联处理结果,由于每一步处理都能够保证在所需数据全部到齐的情况下执行,因此可以提高处理结果的可靠性。
在一可选实施方式中,为了进一步提高处理日志数据的实时性,采用简化的日志数据处理***结构,如图2所示,从物理结构角度来看,该日志数据处理***是两层结构,即包括一层映射节点21(是物理节点)和一层归纳节点22(是物理节点),映射节点21可以是至少一个,而归纳节点22为一个。
关于映射节点21和归纳节点22的工作原理不再赘述。本实施例提供的日志数据处理***与Spark类似,但区别在于,按关键字汇聚(groupByKey)的过程被放入了一个归纳节点22的内部,并且映射节点21会为归纳节点22做预处理。即当映射节点21获取到各个目标客户端代理装置返回的目标日志数据并进行解析后,并不是直接将解析结果传递到归纳节点22,而是先在内存中执行关联预处理,产出归纳节点内部第一逻辑层的数据,值得说明的是这里的关联预处理结果不一定是完整的数据,例如可能映射节点21输出的关联预处理结果只是由第一目标客户端代理装置和第二目标客户端代理装置的目标日志数据合并产生的数据,不包含第三目标客户端代理装置、第四目标客户端代理装置和第五目标客户端代理装置返回的目标日志数据。映射节点21的关联预处理结果汇聚到同一个归纳节点22,归纳节点22将所有映射节点21的关联预处理结果导入其内部的谱系图计算流。
在归纳节点22内部包括多层逻辑处理节点,计算过程十分类似树状结构的广度遍历算法(广度优先遍历是以层为顺序,将某一层上的所有节点都搜索到了之后才向下一层搜索)。
进一步说明,由于本实施例将分布式的物理节点变成单机内存中的逻辑处理节点,可以进一步解决“日志数据齐全度”的问题,具体分析如下:
假如树状结构的广度遍历计算过程是单线程串行的,那触发计算流往下继续的条件就是此单线程的执行进度而已,各逻辑处理节点不需要具备自主检测齐全度的能力来驱动下游计算。即使做成多线程,所有的数据子集状态都在本地内存而非分布式的散落在各台机器上,也能很轻松的辅助“数据子集元数据”的推导;在实际场景中其实根本没必要做成多线程,一台服务器可能有4个CPU,而它可能同时负责100个日志宿主机的归纳节点,每个归纳节点22单线程执行也能充分利用CPU,不会浪费性能,反而极大的简化了***设计。这种做法首先继续保障了计算关联的能力和性能优势,其次它可以非常轻松的实现“日志数据齐全度”。
进一步,考虑到在实际应用中日志宿主机、目标客户端代理装置、映射节点或归纳节点都有可能会发生故障,本实施例还提供一种用于解决故障的方法。
对于日志宿主机或目标客户度代理装置发生故障的情况:由于目标客户端代理装置是无状态的,即其内存中没有缓存任何状态信息,日志数据的位置索引是持久化存储的,日志数据也是持久化存储的,所以对于目标客户端代理装置发生故障的情况,只需在故障重启之后继续启动索引增量构建、继续提供日志查询服务即可。
对于映射节点来说,具体可以创建执行日志数据采集任务的线程,并将该线程放入线程池,以在线程被执行时向目标客户端代理装置发送查询请求并接收目标客户端代理装置返回的目标日志数据。基于此,在目标客户端代理装置发生故障时,例如映射节点在指定时间内未接收到目标客户端代理装置返回的目标日志数据,或者接收到目标客户端代理装置返回的日志数据获取失败消息,可以按照预设的延迟参数,将上述线程重新放入线程池,直到该线程接收到目标客户端代理装置返回的目标日志数据为止。其中,延迟参数用于决定将上述线程重新放入线程池的时间,实际上是指距离该线程上次被执行时的时间间隔,如果过早将上述线程重新放入线程池,有可能该线程再次被执行时仍无法获取到目标日志数据;如果过晚才将上述线程重新放入线程池,就会降低获取目标日志数据的时效性。为了尽量避免关联预处理子任务失败带来的损耗,可以将延迟参数设置为动态可调的值,一般情况下可以将延迟参数设置为5s。
对于映射节点和归纳节点发生故障的情况:由于映射节点和归纳节点是有状态的,即其内存会存储有日志数据处理过程涉及的状态信息,故障重启之后这些状态信息就会丢失。由于本申请实施例中映射节点和归纳节点出现故障的概率较低,所以没有必要对日志数据处理流程做冗余备份,本实施例下面提供一种解决故障的技术方案,用以尽量降低故障解决所消耗的成本。
本实施例采用分布式任务管控的思路,日志数据处理***提供一个任务管理节点,该任务管理节点位于独立的设备上,可以负责对映射节点和归纳节点进行故障处理。
具体的,当前日志数据处理任务被分配到映射节点时,映射节点预先向任务管理节点注册关联预处理子任务和该关联预处理子任务涉及的元数据。基于此,任务管理节点可以根据关联预处理子任务涉及的元数据确定映射节点是否成功执行该关联预处理子任务,并在确定映射节点未成功执行关联预处理子任务时,根据该关联预处理子任务涉及的元数据,向映射节点发送第一重试指示,以指示映射节点重新执行关联预处理子任务。关联预处理子任务涉及的元数据包括但不限于:关联预处理子任务涉及的日志宿主机或客户端代理装置的信息(例如标识信息、位置信息、能力信息等),注册该关联预处理子任务的映射节点的信息(例如标识信息、位置信息、能力信息等),以及关联预处理子任务的执行时间、执行时长等。
例如,映射节点执行关联预处理子任务后可以向任务管理节点上报执行结果,这样任务管理节点可以获知映射节点是否成功执行关联预处理子任务。另外,任务管理节点上还可以设置一时长门限,当某个映射节点在超过该时长门限后仍未返回任务执行结果信息,任务管理节点认为该映射节点未成功执行关联预处理子任务。
具体的,当前日志数据处理任务被分配到归纳节点时,归纳节点预先向任务管理节点注册关联处理子任务和该关联处理子任务涉及的元数据。基于此,任务管理节点可以根据关联处理子任务确定归纳节点是否成功执行该关联处理子任务,并在确定归纳节点未成功执行关联处理子任务时,根据该关联处理子任务涉及的元数据,向映射节点和归纳节点分别发送第二重试指示,以指示映射节点和归纳节点分别重新执行关联预处理子任务和关联处理子任务。关联处理子任务涉及的元数据包括但不限于:关联处理子任务涉及的映射节点的信息(例如标识信息、位置信息、能力信息等),注册该关联处理子任务的归纳节点的信息(例如标识信息、位置信息、能力信息等),以及关联处理子任务的执行时间、执行时长等。
综上所述,本申请实施例提供的方法使得日志数据齐全度问题得以妥善解决,一致性能够得到有效保障,并且也没有因此丢失实时性或增加额外的成本。
需要说明的是,对于前述的各方法实施例,为了简单描述,故将其都表述为一系列的动作组合,但是本领域技术人员应该知悉,本申请并不受所描述的动作顺序的限制,因为依据本申请,某些步骤可以采用其他顺序或者同时进行。其次,本领域技术人员也应该知悉,说明书中所描述的实施例均属于优选实施例,所涉及的动作和模块并不一定是本申请所必须的。
在上述实施例中,对各个实施例的描述都各有侧重,某个实施例中没有详述的部分,可以参见其他实施例的相关描述。
图3为本申请一实施例提供的日志数据处理***的结构示意图。如图3所示,该***包括:映射节点31和归纳节点32,归纳节点32与映射节点31连接。
映射节点31,用于在执行日志数据处理任务中的关联预处理子任务时,向映射节点31对应的目标客户端代理装置发送查询请求,接收目标客户端代理装置根据查询请求返回的目标日志数据,并在接收到映射节点31对应的所有目标客户端代理装置返回的目标日志数据时,对所有接收到的目标日志数据进行关联预处理,并将关联预处理结果发送给归纳节点32。
其中,目标客户端代理装置是部署于产生当前日志数据处理任务所需的目标日志数据的日志宿主机上的客户端代理装置,查询请求包括:日志文件标识和时间段标识,目标日志数据是日志文件标识所标识的日志文件中在时间段标识所标识的时间段内产生的日志数据;
归纳节点32,用于在执行当前日志数据处理任务中的关联处理子任务时,接收映射节点31发送的关联预处理结果,并在接收到所有执行关联预处理子任务的映射节点31发送的关联预处理结果,对所有接收到的关联预处理结果进行关联处理,并输出关联处理结果。
在一可选实施方式中,映射节点31还用于:
记录返回目标日志数据的目标客户端代理装置的标识信息,并将记录的返回目标日志数据的目标客户端代理装置的标识信息与预先配置的客户端代理装置的标识信息进行比较;
若记录的返回目标日志数据的目标客户端代理装置的标识信息与预先配置的客户端代理装置的标识信息完全相同,确定接收到映射节点31对应的所有目标客户端代理装置返回的目标日志数据。
相应的,归纳节点32还用于:
记录发送关联预处理结果的映射节点31的标识信息,并将记录的发送关联预处理结果的映射节点31的标识信息与预先配置的映射节点31的标识信息进行比较;
若记录的发送关联预处理结果的映射节点31的标识信息与预先配置的映射节点31的标识信息完全相同,确定接收到所有执行当前日志数据处理任务的映射节点31发送的关联预处理结果。
在一可选实施方式中,映射节点31具体用于:创建执行日志数据采集任务的线程,并将线程放入线程池,以在线程被执行时向目标客户端代理装置发送查询请求并接收目标客户端代理装置返回的目标日志数据。
基于上述,映射节点31还用于:在指定时间内未接收到目标客户端代理装置返回的目标日志数据,或者接收到目标客户端代理装置返回的日志数据获取失败消息,按照预设的延迟参数,将线程重新放入线程池,直到线程接收到目标客户端代理装置返回的目标日志数据为止。
在一可选实施方式中,映射节点31为至少一个,归纳节点32为一个,此时日志数据处理***的结构示意图如图2所示。
在一可选实施方式中,如图3所示,日志数据处理***还包括:任务管理节点33。
映射节点31还用于:向任务管理节点33注册关联预处理子任务和关联预处理子任务涉及的元数据;
任务管理节点33,用于根据关联预处理子任务涉及的元数据确定映射节点是否成功执行关联预处理子任务,并在确定映射节点31未成功执行关联预处理子任务时,根据关联预处理子任务涉及的元数据,向映射节点31发送第一重试指示,以指示映射节点31重新执行关联预处理子任务。
进一步,归纳节点32还用于:向任务管理节点33注册关联处理子任务和关联处理子任务涉及的元数据;
任务管理节点33还用于:根据关联处理子任务涉及的元数据确定归纳节点是否成功执行关联处理子任务,并在确定归纳节点32未成功执行关联处理子任务时,根据关联处理子任务涉及的元数据,向映射节点31和归纳节点32分别发送第二重试指示,以指示映射节点31和归纳节点32分别重新执行关联预处理子任务和关联处理子任务。
进一步,任务管理节点33还可用于,进行任务编排和分配。具体的,任务管理节点33还可用于:
确定日志宿主机的个数和执行关联预处理子任务的映射节点的个数;
根据日志宿主机的个数和执行关联预处理子任务的映射节点的个数,确定每个映射节点对应的目标客户端代理装置,并将每个映射节点对应的目标客户端代理装置的标识信息提供给每个映射节点。
本实施例提供的日志数据处理***,其中执行当前日志数据处理任务的映射节点和部署于产生当前日志数据处理任务所需的目标日志数据的日志宿主机上的客户端代理装置相配合,可以准确获取指定时间段内产生的日志数据,使得日志数据处理***可以及时对日志数据进行处理,实现对日志数据的实时处理;另外,客户端代理装置允许映射节点获取指定时间段内产生的日志数据,为保证日志数据处理任务所需的日志数据全部到齐日志数据处理***打下了基础,进一步在日志数据处理***内部,映射节点通过判断,只有在来自映射节点对应的所有客户端代理装置的日志数据全部到齐时,才执行关联预处理并将关联预处理结果发送给归纳节点,归纳节点通过判断,只有在来自所有执行日志数据处理任务的映射节点的关联预处理结果全部到齐后,才对所有关联预处理结果进行关联处理,并最终输出关联处理结果,由于每一步处理都能够保证在所需数据全部到齐的情况下执行,因此可以提高处理结果的可靠性。
所属领域的技术人员可以清楚地了解到,为描述的方便和简洁,上述描述的***,装置和单元的具体工作过程,可以参考前述方法实施例中的对应过程,在此不再赘述。
在本申请所提供的几个实施例中,应该理解到,所揭露的***,装置和方法,可以通过其它的方式实现。例如,以上所描述的装置实施例仅仅是示意性的,例如,所述单元的划分,仅仅为一种逻辑功能划分,实际实现时可以有另外的划分方式,例如多个单元或组件可以结合或者可以集成到另一个***,或一些特征可以忽略,或不执行。另一点,所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口,装置或单元的间接耦合或通信连接,可以是电性,机械或其它的形式。
所述作为分离部件说明的单元可以是或者也可以不是物理上分开的,作为单元显示的部件可以是或者也可以不是物理单元,即可以位于一个地方,或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
另外,在本申请各个实施例中的各功能单元可以集成在一个处理单元中,也可以是各个单元单独物理存在,也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现,也可以采用硬件加软件功能单元的形式实现。
上述以软件功能单元的形式实现的集成的单元,可以存储在一个计算机可读取存储介质中。上述软件功能单元存储在一个存储介质中,包括若干指令用以使得一个计算机设备(可以是个人计算机,服务器,或者网络设备等)或处理器(processor)执行本申请各个实施例所述方法的部分步骤。而前述的存储介质包括:U盘、移动硬盘、只读存储器(Read-Only Memory,ROM)、随机存取存储器(Random Access Memory,RAM)、磁碟或者光盘等各种可以存储程序代码的介质。
最后应说明的是:以上实施例仅用以说明本申请的技术方案,而非对其限制;尽管参照前述实施例对本申请进行了详细的说明,本领域的普通技术人员应当理解:其依然可以对前述各实施例所记载的技术方案进行修改,或者对其中部分技术特征进行等同替换;而这些修改或者替换,并不使相应技术方案的本质脱离本申请各实施例技术方案的精神和范围。