日志处理方法、装置、电子设备及存储介质与流程

1.本发明实施例涉及数据处理技术领域，尤其涉及一种日志处理方法、装置、电子设备及存储介质。


背景技术：

2.当产品开发完成并正式上线后，除了需要对系统的进程、内存等物理指标进行监控外，为了主动发现产品的问题，通常还需要对系统的线上业务日志进行观察。
3.现有技术中，工作人员可以利用特定的工具对系统的错误信息进行收集，再基于收集的错误信息对产品进行优化。然而，一方面，这种基于各个错误信息逐一解决问题的方式无法让工作人员对产品出现的问题进行宏观把控，进而无法明确产品的改进方向，不利于提升产品的稳定性；另一方面，人为地对这些错误信息进行汇总分析又需要消耗较多的人力成本和时间成本，系统的优化效率较低。


技术实现要素：

4.本发明提供一种日志处理方法、装置、电子设备及存储介质，能够自动高效地对系统出现的问题进行多维度的分析汇总，降低了人力成本和时间成本，便于工作人员对系统进行针对性修复。
5.第一方面，本发明实施例提供了一种日志处理方法，该方法包括：
6.当接收到日志处理请求时，获取采集的各已监控平台所对应的目标文件集；其中，所述目标文件集中包括各已监控平台运行过程中的待分析信息；
7.基于至少三个评估维度对所述待分析信息进行处理，得到与各评估维度相对应的评估属性信息；其中，所述至少三个评估维度包括事件类型维度、基于资源定位符确定的业务域类型维度、以及基于待分析信息所确定的关键字类型维度；
8.基于各评估维度的评估属性信息，确定各已监控平台所对应的质量分析报告。
9.第二方面，本发明实施例还提供了一种日志处理装置，该装置包括：
10.目标文件集获取模块，用于当接收到日志处理请求时，获取采集的各已监控平台所对应的目标文件集；其中，所述目标文件集中包括各已监控平台运行过程中的待分析信息；
11.评估属性信息确定模块，用于基于至少三个评估维度对所述待分析信息进行处理，得到与各评估维度相对应的评估属性信息；其中，所述至少三个评估维度包括事件类型维度、基于资源定位符确定的业务域类型维度、以及基于待分析信息所确定的关键字类型维度；
12.质量分析报告确定模块，用于基于各评估维度的评估属性信息，确定各已监控平台所对应的质量分析报告。
13.第三方面，本发明实施例还提供了一种电子设备，所述电子设备包括：
14.一个或多个处理器；
15.存储装置，用于存储一个或多个程序，
16.当所述一个或多个程序被所述一个或多个处理器执行，使得所述一个或多个处理器实现如本发明实施例任一所述的日志处理方法。
17.第四方面，本发明实施例还提供了一种包含计算机可执行指令的存储介质，所述计算机可执行指令在由计算机处理器执行时用于执行如本发明实施例任一所述的日志处理方法。
18.本发明实施例的技术方案，当接收到日志处理请求时，获取采集的各已监控平台所对应的目标文件集，从而确定多条错误信息；基于至少三个评估维度对待分析信息进行处理，得到与各评估维度相对应的评估属性信息，进而基于各评估维度的评估属性信息，确定各已监控平台所对应的质量分析报告，能够自动高效地对系统出现的问题进行多维度的分析汇总，在降低了人力成本和时间成本的同时，便于工作人员对系统的问题进行宏观把控，进而对系统进行针对性修复以提升产品的稳定性。
附图说明
19.为了更加清楚地说明本发明示例性实施例的技术方案，下面对描述实施例中所需要用到的附图做一简单介绍。显然，所介绍的附图只是本发明所要描述的一部分实施例的附图，而不是全部的附图，对于本领域普通技术人员，在不付出创造性劳动的前提下，还可以根据这些附图得到其他的附图。
20.图1为本发明实施例一所提供的一种日志处理方法的流程示意图；
21.图2为本发明实施例二所提供的一种日志处理方法的流程示意图；
22.图3为本发明实施例三所提供的一种日志处理方法的流程示意图；
23.图4为本发明实施例四所提供的一种日志处理方法的流程图；
24.图5为本发明实施例五所提供的一种日志处理装置的结构框图；
25.图6为本发明实施例六所提供的一种电子设备的结构示意图。
具体实施方式
26.下面结合附图和实施例对本发明作进一步的详细说明。可以理解的是，此处所描述的具体实施例仅仅用于解释本发明，而非对本发明的限定。另外还需要说明的是，为了便于描述，附图中仅示出了与本发明相关的部分而非全部结构。
27.实施例一
28.图1为本发明实施例一所提供的一种日志处理方法的流程示意图，本实施例可适用于对错误监控系统生成的日志进行处理的情况，该方法可以由日志处理装置来执行，该装置可以通过软件和/或硬件的形式实现，该硬件可以是电子设备，如移动终端、pc端或服务器等。
29.如图1所示，该方法具体包括如下步骤：
30.s110、当接收到日志处理请求时，获取采集的各已监控平台所对应的目标文件集。
31.在业务系统运行的过程中，错误监控系统可以对与业务系统相关联的多个平台进行监控，并得到与业务系统对应的日志文件，本领域技术人员应当理解，这些处于监控状态下的平台即是已监控平台。示例性的，在医疗业务系统运行的过程中，利用sentry错误监控
系统可以同时对作为已监控平台的服务端和客户端进行监控，进一步的，sentry会对业务系统服务端和客户端中出现的故障进行采集记录，并将这些错误信息以日志的形式进行存储。
32.具体来说，错误监控系统将业务系统的错误信息进行记录后，可以生成多个与各错误信息相对应的日志文件。可以理解，在每个日志文件中都包含有具体的错误信息，如，发生故障的平台标识、与该故障对应的关键字段、故障发生的时间、故障解决以及其他冗余数据等。在实际应用过程中，为了高效地对业务系统出现的问题进行宏观把控和分析，就需要对每个日志文件对应的错误信息中的数据进行针对性提取。因此，在错误信息对应的数据中，可以将对确定业务系统问题具有指导意义的数据作为待分析信息。
33.基于此，本领域技术人员应当理解，日志处理请求是指工作人员基于前端页面的特定控件向系统发送的请求，至少用于对业务系统的待分析信息进行获取。例如，可以在业务系统中开发一个“收集错误信息”的控件，工作人员通过点击该控件即可实现对待分析信息的获取。需要说明的是，业务系统还可以采用定时轮询的方式获取待分析信息，例如，基于预先设置的时间间隔定期获取各已监控平台的待分析信息，本领域技术人员应当理解，具体的获取待分析信息的方式可以根据实际情况进行选择，本公开实施例在此不做具体的限定。
34.进一步的，系统可以对日志处理请求进行响应，进而对各个已监控平台的待分析信息进行获取和汇总，并以文件的形式进行存储，进而得到与各已监控平台对应的目标文件集，可以理解，在目标文件集中至少包括各已监控平台运行过程中的待分析信息。
35.s120、基于至少三个评估维度对待分析信息进行处理，得到与各评估维度相对应的评估属性信息。
36.在本实施例中，对日志处理请求进行响应，并获取到各已监控平台的待分析信息后，为了实现对业务系统错误信息的汇总分析，可以基于至少三个评估维度对待分析信息进行处理。其中，评估维度可以是待分析信息中的某一具体参数或项目，本领域技术人员应当理解，该参数或项目至少可以用于对当前业务系统在某个方面所存在的问题进行分析，至少三个评估维度包括事件类型维度、基于资源定位符确定的业务域类型维度、以及基于待分析信息所确定的关键字类型维度，下面对上述三个评估维度分别进行说明。
37.在本实施例中，基于事件类型评估维度对业务系统进行分析，可以理解为基于待分析信息中的事件类型参数对业务系统进行分析，在实际应用过程中，可以通过不同的事件标识(事件id)反映相应的事件类型。示例性的，在各已监控平台中，服务端发生的某个故障可以以id128893来表示，客户端发生的某个故障可以以id186779来表示。
38.基于资源定位符确定的业务域类型维度对业务系统进行分析，可以理解为基于待分析信息中的路由信息对业务系统进行分析，在实际应用过程中，可以将各待分析信息中的统一资源定位符(uniform resource locator，url)作为路由信息。可以理解，对于错误监控系统记录的各错误信息来说，基于与各错误信息对应的url，不仅可以确定平台发生故障时采用的传输协议以及相关的域名，还可以确定该平台在业务系统中的端口号和路径信息等。同时，由于各已监控平台与特定的业务域相对应，通过对待分析信息中的路由信息进行分析，还可以确定该故障与业务系统中哪一项业务相对应。
39.基于待分析信息所确定的关键字类型维度对业务系统进行分析，可以理解为基于
待分析信息中的错误类型对业务系统进行分析，在实际应用过程中，可以利用能够反映特定故障的字段来表示错误类型。示例性的，在各已监控平台中，当错误监控系统记录的故障与数据格式相关时，对应的故障字段可以是json data。
40.本领域技术人员应当理解，对于各已监控平台来说，当相同的故障不断发生时，在与每个故障相对应的待分析信息中，各评估维度的具体信息可以相同，例如，表示相同故障的多个待分析信息的事件标识、路由信息以及错误类型相同，而其他信息(如故障发生时间以及故障解决时间等)则可以不同。
41.在本实施例中，确定出至少三个维度后，可以基于各个维度分别对待分析信息进行分类汇总，进而生成与各评估维度相对应的评估属性信息，其中，评估属性信息可以是业务系统各错误信息在对应评估维度下的统计和排序结果。示例性的，当评估维度为基于资源定位符确定的业务域类型维度时，基于与各待分析信息对应的路由信息，可以统计出业务系统相关联的不同端口出现的次数，进而帮助工作人员确定哪种业务对应的平台发生故障的次数最多。
42.s130、基于各评估维度的评估属性信息，确定各已监控平台所对应的质量分析报告。
43.在本实施例中，基于至少三个评估维度得到对应的评估属性信息后，为了确定业务系统整体的故障发生情况，还需要将多个评估属性信息进行汇总，进而生成包括各已监控平台错误信息的质量分析报告。其中，质量分析报告即是对与各已监管平台对应的待分析信息进行分析后所形成的论点、论据以及结论的集中表现，是一种运用统计资料和统计方法对数字和文字的结合。可以理解，质量分析报告以各评估属性信息及待分析信息中的具体数据为主体，以特有的表达方式以及结构来反映业务系统当前较为重要的问题，也即是说，质量分析报告是一份将各已监控平台的待分析信息进行融合、有助于工作人员从中发现更多问题和系统优化方向的文件。可以理解，该文件中的内容与各个已监控平台相对应，例如，对于医疗相关业务系统来说，生成的文件中既包括医生端对应平台出现的问题，也包括患者端对应平台出现的问题。
44.需要说明的是，在本实施例中，可以基于特定的编程语言编写相应的程序，在程序运行过程中还可以调用多种开源组件，以此将多个评估属性信息进行整合。本领域技术人员应当理解，具体的调用方式和规则应根据实际情况进行选择，本公开实施例在此不作具体的限定。
45.进一步的，在基于各评估维度的评估属性信息确定出质量分析报告后，还可以将报告在特定的页面进行显示，从而实现业务系统错误信息的可视化。
46.本实施例的技术方案，当接收到日志处理请求时，获取采集的各已监控平台所对应的目标文件集，从而确定多条错误信息；基于至少三个评估维度对待分析信息进行处理，得到与各评估维度相对应的评估属性信息，进而基于各评估维度的评估属性信息，确定各已监控平台所对应的质量分析报告，能够自动高效地对系统出现的问题进行多维度的分析汇总，在降低了人力成本和时间成本的同时，便于工作人员对系统的问题进行宏观把控，进而对系统进行针对性修复以提升产品的稳定性。
47.实施例二
48.图2为本发明实施例二所提供的一种日志处理方法的流程示意图，在前述实施例
的基础上，基于所接收请求携带的时间参数确定目标文件集，从而实现对业务系统特定时间段内的错误信息进行分类汇总；通过将不同评估维度对应的统计结果进行分类汇总和排序筛选，有助于工作人员直观地发现业务系统在特定时间段内出现的重点故障(出现次数/频率较高的故障)，确定出后续工作任务的优先级，从而对对业务系统影响较大的故障进行针对性处理。其具体的实施方式可以参见本实施例技术方案。其中，与上述实施例相同或者相应的技术术语在此不再赘述。
49.如图2所示，该方法具体包括如下步骤：
50.s210、当接收到日志处理请求时，基于日志处理请求携带的时间参数，从各已监控平台存储空间的数据中确定目标数据；根据目标数据确定各已监控平台运行过程中的待分析信息，并基于待分析信息构建集合，得到目标文件集。
51.其中，时间参数可以是包括起止时间的某个时间段，可以由工作人员手动进行选择，可以由系统按照预设规则生成。对于错误监控系统来说，该时间段表示一个错误信息分析区间，可以理解，最终所生成质量分析报告中包含的错误信息仅仅是处于该分析区间内的错误信息。
52.在本实施例中，时间参数可以以多种形式携带于日志处理请求中，例如，相对于系统时间来说，可以是“本周”、“上周”等特定的字符串，还可以是年月日等具体的日期。当接收到日志处理请求时，对该请求进行解析即可提取到请求携带的时间参数。进一步的，由于错误监控系统在对各个平台进行监控时，可以记录各种故障发生的时间以及解决该故障的时间，对应的，这些时间信息又与存储于特定存储空间的错误信息相关联，因此，当请求携带的时间段与错误监控系统记录的错误信息相匹配时，即可确定出该时间段内错误监控系统记录并存储于存储空间内的特定错误信息，可以理解，所确定的特定错误信息即是目标数据。
53.需要说明的是，基于特定时间参数确定错误信息的分析区间，不仅可以对特定时段内业务系统出现的故障进行分析，还可以将该分析区间的错误信息进一步划分，进而在后续过程中实现不同时段故障信息之间的比对。
54.在本实施例中，确定出作为目标数据的错误信息后，进一步的，可以按照预先设置的配置项在错误信息中确定出对确定业务系统问题具有指导意义的数据，并将这些数据作为待分析信息。示例性的，对于错误监控系统记录的一条错误信息来说，所确定的待分析信息包括“故障名称：医生工作站，家庭医生签约及公卫列表页面白屏”、“故障原因：发布时操作失误”、“项目：工作站”、“缺陷等级：c级”、“故障状态：已修复”、“问题来源：运行产品”、“提出时间：2019-11-07-10：33”、“解决时间：2019-11-07-10：34”、“责任人：a”、“责任团队：b区业务组”等。确定出待分析信息后，基于这些信息构建集合即可得到用户生成业务系统质量分析报告的目标文件集。
55.s220、基于至少三个评估维度对待分析信息进行处理，得到与各评估维度相对应的评估属性信息。
56.在本实施例中，评估维度至少包括三种，下面则对基于三种维度生成对应评估属性信息的过程进行说明。
57.可选的，当评估维度为事件类型维度时，基于事件标识统计各事件类型出现的次数和/或频率，得到与事件类型维度相对应的评估属性信息。具体来说，当确定出各待分析
信息后，可以基于预先设置的配置项将每个待分析信息中的事件id进行提取，并将不同事件id出现的次数和/或频率进行统计，所得到的统计结果即是即是与该维度对应的评估属性信息，例如，事件id128893对应的评估属性信息中的具体数值为26，表明业务系统中该事件id对应的故障在特定时间段内出现了26次。
58.可选的，当评估维度为基于资源定位符确定的业务域类型维度时，基于各资源定位符统计各个业务域出现的次数和/或频率，得到与基于资源定位符确定的业务域类型维度相对应的统计结果。具体来说，在确定出各待分析信息后，可以基于预先设置的配置项将每个待分析信息中的url进行提取，进一步的，以手动或自动的方式将各url中的域名进行剔除，仅保留端口号信息以及路径信息等，可以理解为，仅保留能够确定出现故障的业务域的路由信息。本领域技术人员应当理解，自动剔除url中的域名可以通过调用预先编写的脚本来实现，本公开实施例在此不做具体的限定。最后，对各路由信息出现的次数和/或频率进行统计，所得到统计结果即是与该维度对应的评估属性信息，例如，路由信息为ls/2828671对应的评估属性信息中的具体数值为19，代表与该业务对应的业务域在特定时间段内出现了19次故障。
59.可选的，当评估维度为基于待分析信息所确定的关键字类型维度时，基于各关键字类型统计不同关键字出现的次数和/或频率，得到与基于待分析信息所确定的关键字类型维度相对应的统计结果。具体来说，在确定出各待分析信息后，可以基于预先设置的配置项将每个待分析信息中的具体故障字段进行提取，进一步的，针对各具体故障字段，基于关键字匹配技术确定出相对应的关键字，从而对各关键字出现的次数和/或频率进行统计，所得到的统计结果即是与该维度对应的评估属性信息。在实际应用过程中，与各具体故障字段相匹配的关键字包括空指针异常、图片不显示、接口超时、内存溢出，可以理解，所匹配的关键字即是不同故障的表现，基于这些表现信息同样可以确定出相对应的故障。
60.s230、根据各个统计结果中的次数或频率对待分析信息进行分类；根据预设的筛选规则对各个统计结果中不同类别的待分析信息进行筛选，得到与各个维度信息相对应的筛选结果，将所得到的筛选结果进行汇总以生成各已监控平台所对应的质量分析报告。
61.在本实施例中，确定出与至少三个维度相对应的评估属性信息后，还需要将这些信息进行分类汇总，具体来说，可以是将各个事件id、路由信息以及与各具体故障字段相匹配的关键字进行分类汇总。进一步的，将分类汇总的结果(不同评估维度下各种故障出现的次数或频率)基于由大到小的顺序进行排序，并按照预设规则对结果中的部分内容进行剔除。示例性的，对于评估属性信息中与各具体故障字段相匹配的关键字来说，可以在统计不同关键字出现的次数之后，取出现次数处于前五的五个关键字进行排序，并将其他出现次数较低的关键字剔除。
62.在本实施例中，将与各评估维度相对应的统计结果进行分类汇总以及筛选排序后，再将最终结果整合成文档，即可得到包含各已监控平台错误信息的质量分析报告。可以理解，质量分析报告可以从多个维度体现业务系统在特定时间段内出现的故障，示例性的，当时间参数决定的分析区间为上一周时间段时，报告中不仅包括不同评估维度下出现次数为前五的故障的具体信息，还可以包括业务系统上一周发生的故障的数量、已修复故障的数量、已修复故障的总修复时长、已修复故障的平均修复时长、未修复故障数量等。
63.本实施例的技术方案，基于所接收请求携带的时间参数确定目标文件集，从而实
现对业务系统特定时间段内的错误信息进行分类汇总；通过将不同评估维度对应的统计结果进行分类汇总和排序筛选，有助于工作人员直观地发现业务系统在特定时间段内出现的重点故障(出现次数/频率较高的故障)，确定出后续工作任务的优先级，从而对对业务系统影响较大的故障进行针对性处理。
64.实施例三
65.图3为本发明实施例三所提供的一种日志处理方法的流程示意图，在前述实施例的基础上，确定各评估维度间的共性信息，便于工作人员对业务系统的故障进行追踪，并对业务系统的运行逻辑进行调整，进而从整体上优化相关业务的架构。进一步的，将不同时段的质量分析报告进行比对评估得到评估结果，可以基于评估结果判断对各已监控平台的系统运行逻辑调整是否有效，实现了对优化点落地情况的调查和验证，从而保证业务相关产品的稳定性。其具体的实施方式可以参见本实施例技术方案。其中，与上述实施例相同或者相应的技术术语在此不再赘述。
66.如图3所示，该方法具体包括如下步骤：
67.s310、当接收到日志处理请求时，获取采集的各已监控平台所对应的目标文件集。
68.s320、基于至少三个评估维度对待分析信息进行处理，得到与各评估维度相对应的评估属性信息。
69.s330、基于各评估维度的评估属性信息，确定各已监控平台所对应的质量分析报告。
70.s340、将各评估属性信息对应的数据来源信息进行匹配，得到各评估维度间的共性信息，根据共性信息对各已监控平台的系统运行逻辑进行调整，以在接收到日志处理请求时，基于调整后的各已监控平台生成对应的质量分析报告。
71.在本实施例中，在确定与各评估维度相对应的评估属性信息后，还需要将与各评估属性信息对应的数据来源信息进行匹配，其中，各评估属性信息对应的数据来源信息可以是错误监控系统在记录故障时生成的各日志文件，当多个日志文件相匹配时，表明不同评估维度下的评估属性信息都是基于错误监控系统记录的同一故障信息生成的。示例性的，将各评估属性信息进行分类汇总以及筛选排序后，出现次数最多的路由信息对应的数据来源信息，与出现次数最多的故障字段关键字对应的数据来源信息相同，表明某一业务域经常出现某种错误类型的故障。
72.进一步的，当不同评估属性信息对应的数据来源信息匹配成功时，即得到各评估维度之间的共性信息，可以理解，共性信息即是匹配得到的与不同评估维度相关联的待分析信息。基于得到的共性信息，工作人员可以对业务系统的运行逻辑进行调整，进而从整体上优化相关业务的架构。当业务架构优化完毕后，基于后续的日志处理请求即可生成经过调整后业务系统各已监控平台的质量分析报告。
73.s350、基于当前时段的质量分析报告以及上一时段的质量分析报告对各已监控平台进行评估，得到评估结果，以基于评估结果判断对各已监控平台的系统运行逻辑调整是否有效。
74.在本实施例中，由于日志处理请求中携带的时间参数可以包含多个时间段(即多个分析区间)，因此，基于各评估维度的共性信息对业务架构进行优化后，可以得到当前时段的质量分析报告以及上一时段的质量分析报告。进一步的，还可以对优化调整之前和优
化调整之后的业务系统对应的两个质量分析报告进行比对评估，得到对应的评估结果。本领域技术人员应当理解，比对评估过程中采用的算法或函数可以根据实际需求进行编写，本公开实施例对此并未做具体的限定。
75.示例性的，对业务系统的优化调整发生在上周与本周两个时间段之间，在对上周各已监控平台的故障信息以及本周各已监控平台的故障信息进行分析后，基于两个质量分析报告即可得到对应的评估结果，评估结果中可以包括业务系统调整前后的基本比对信息，如，两周故障数量、故障修复时间的差异，进一步的，还可以包括各评估维度对应故障出现的趋势，如，上周a类型故障的修复时长与本周a类型故障修复时长的变化趋势(上升、持平或下降)，还可以包括搭建维护业务系统相关团队的工作量，如，一号业务组在上周和本周修复的故障数量，修复故障对应的工作时长，以及二号业务组在上周和本周修复的故障数量，修复故障对应的工作时长等。在实际应用过程中，评估结果还可以包括业务系统调整优化的结论，如，“本周较上周相比，故障质量有变好的趋势”，“故障总量较上周下降14％”，本领域技术人员应当理解，所得到的结论可以是预先编写的字符串与各待分析信息匹配整合得到的结果。
76.本实施例的技术方案，确定各评估维度间的共性信息，便于工作人员对业务系统的故障进行追踪，并对业务系统的运行逻辑进行调整，进而从整体上优化相关业务的架构。进一步的，将不同时段的质量分析报告进行比对评估得到评估结果，可以基于评估结果判断对各已监控平台的系统运行逻辑调整是否有效，实现了对优化点落地情况的调查和验证，从而保证业务相关产品的稳定性。
77.实施例四
78.作为上述实施例的一可选实施例，图4为本发明实施例四所提供的一种日志处理方法的流程图。为了清楚的介绍本实施例技术方案，可以以应用场景是将sentry错误监控系统记录的错误信息进行分类汇总处理，以对业务系统进行优化调整的情形为例来介绍，但是不局限于上述场景，可以适用于各种需要对错误信息相关日志进行处理的场景中。
79.参见图4，当业务系统的各平台与sentry错误监控系统进行关联后，该监控系统即可实时采集各已监控平台产生的错误信息，并将这些错误信息以日志文件的形式存储在特定的存储区域。当接收到日志处理请求时，基于请求携带的时间参数即可在特定存储区域内确定出对应的日志文件，可以理解，文件中包含的待分析信息即表征特定时间段内各平台出现的故障。
80.继续参见图4，当获取到各已监控平台的待分析信息后，可以基于至少三个评估维度对待分析信息进行分析汇总，至少三个评估维度包括事件类型维度、路由信息维度以及错误类型维度。以与三维评估维度相对应的方式对待分析信息进行处理后，即可得到包含各已监控平台待分析信息的质量分析报告。
81.继续参见图4，在得到质量分析报告后，为了从整体上优化相关业务的架构，可以确定出不同评估维度的共性信息并对其进行分析。当确定各评估维度存在共性信息时，可以由工作人员对业务系统的架构进行优化调整，并基于优化调整后的质量分析报告以及优化调整前的质量分析报告得到评估结果，从而判断对各已监控平台的系统运行逻辑调整是否有效；当确定各评估维度不存在共性信息时，可以统计出业务系统内出现频次较高的一些故障，进而由工作人员对这些故障进行针对性修复。
82.上述技术方案的有益效果为：能够自动高效地对系统出现的问题进行多维度的分析汇总，在降低了人力成本和时间成本的同时，便于工作人员对系统的问题进行宏观把控，进而对系统进行针对性修复以提升产品的稳定性。
83.实施例五
84.图5为本发明实施例五所提供的一种日志处理装置的结构框图，可执行本发明任意实施例所提供的日志处理方法，具备执行方法相应的功能模块和有益效果。如图5所示，该装置具体包括：目标文件集获取模块410、评估属性信息确定模块420、以及质量分析报告确定模块430。
85.目标文件集获取模块410，用于当接收到日志处理请求时，获取采集的各已监控平台所对应的目标文件集；其中，所述目标文件集中包括各已监控平台运行过程中的待分析信息。
86.评估属性信息确定模块420，用于基于至少三个评估维度对所述待分析信息进行处理，得到与各评估维度相对应的评估属性信息；其中，所述至少三个评估维度包括事件类型维度、基于资源定位符确定的业务域类型维度、以及基于待分析信息所确定的关键字类型维度。
87.质量分析报告确定模块430，用于基于各评估维度的评估属性信息，确定各已监控平台所对应的质量分析报告。
88.在上述各技术方案的基础上，目标文件集获取模块410包括目标数据确定单元以及目标文件集确定单元。
89.目标数据确定单元，用于当接收到日志处理请求时，基于所述日志处理请求携带的时间参数，从各已监控平台存储空间的数据中确定目标数据。
90.目标文件集确定单元，用于根据所述目标数据确定各已监控平台运行过程中的待分析信息，并基于所述待分析信息构建集合，得到所述目标文件集。
91.可选的，评估属性信息确定模块420，还用于当评估维度为事件类型维度时，基于事件标识统计各事件类型出现的次数和/或频率，得到与事件类型维度相对应的评估属性信息；当评估维度为基于资源定位符确定的业务域类型维度时，基于各资源定位符统计各个业务域出现的次数和/或频率，得到与基于资源定位符确定的业务域类型维度相对应的统计结果；当评估维度为基于待分析信息所确定的关键字类型维度时，基于各关键字类型统计不同关键字出现的次数和/或频率，得到与基于待分析信息所确定的关键字类型维度相对应的统计结果。
92.在上述各技术方案的基础上，质量分析报告确定模块430包括分类单元以及汇总单元。
93.分类单元，用于根据各个统计结果中的次数或频率对所述待分析信息进行分类。
94.汇总单元，用于根据预设的筛选规则对各个统计结果中不同类别的待分析信息进行筛选，得到与各个维度信息相对应的筛选结果，将所得到的筛选结果进行汇总以生成各已监控平台所对应的质量分析报告。
95.在上述各技术方案的基础上，日志处理装置还包括共性信息确定模块以及评估模块。
96.共性信息确定模块，用于将各评估属性信息对应的数据来源信息进行匹配，得到
各评估维度间的共性信息，根据所述共性信息对各已监控平台的系统运行逻辑进行调整，以在接收到日志处理请求时，基于调整后的各已监控平台生成对应的质量分析报告。
97.评估模块，用于基于当前时段的质量分析报告以及上一时段的质量分析报告对各已监控平台进行评估，得到评估结果，以基于所述评估结果判断对各已监控平台的系统运行逻辑调整是否有效。
98.本实施例所提供的技术方案，当接收到日志处理请求时，获取采集的各已监控平台所对应的目标文件集，从而确定多条错误信息；基于至少三个评估维度对待分析信息进行处理，得到与各评估维度相对应的评估属性信息，进而基于各评估维度的评估属性信息，确定各已监控平台所对应的质量分析报告，能够自动高效地对系统出现的问题进行多维度的分析汇总，在降低了人力成本和时间成本的同时，便于工作人员对系统的问题进行宏观把控，进而对系统进行针对性修复以提升产品的稳定性。
99.本发明实施例所提供的日志处理装置可执行本发明任意实施例所提供的日志处理方法，具备执行方法相应的功能模块和有益效果。
100.值得注意的是，上述装置所包括的各个单元和模块只是按照功能逻辑进行划分的，但并不局限于上述的划分，只要能够实现相应的功能即可；另外，各功能单元的具体名称也只是为了便于相互区分，并不用于限制本发明实施例的保护范围。
101.实施例六
102.图6为本发明实施例六所提供的一种电子设备的结构示意图。图6示出了适于用来实现本发明实施例实施方式的示例性电子设备50的框图。图6显示的电子设备50仅仅是一个示例，不应对本发明实施例的功能和使用范围带来任何限制。
103.如图6所示，电子设备50以通用计算设备的形式表现。电子设备50的组件可以包括但不限于：一个或者多个处理器或者处理单元501，系统存储器502，连接不同系统组件(包括系统存储器502和处理单元501)的总线503。
104.总线503表示几类总线结构中的一种或多种，包括存储器总线或者存储器控制器，外围总线，图形加速端口，处理器或者使用多种总线结构中的任意总线结构的局域总线。举例来说，这些体系结构包括但不限于工业标准体系结构(isa)总线，微通道体系结构(mac)总线，增强型isa总线、视频电子标准协会(vesa)局域总线以及外围组件互连(pci)总线。
105.电子设备50典型地包括多种计算机系统可读介质。这些介质可以是任何能够被电子设备50访问的可用介质，包括易失性和非易失性介质，可移动的和不可移动的介质。
106.系统存储器502可以包括易失性存储器形式的计算机系统可读介质，例如随机存取存储器(ram)504和/或高速缓存存储器505。电子设备50可以进一步包括其它可移动/不可移动的、易失性/非易失性计算机系统存储介质。仅作为举例，存储系统506可以用于读写不可移动的、非易失性磁介质(图6未显示，通常称为“硬盘驱动器”)。尽管图6中未示出，可以提供用于对可移动非易失性磁盘(例如“软盘”)读写的磁盘驱动器，以及对可移动非易失性光盘(例如cd-rom,dvd-rom或者其它光介质)读写的光盘驱动器。在这些情况下，每个驱动器可以通过一个或者多个数据介质接口与总线503相连。存储器502可以包括至少一个程序产品，该程序产品具有一组(例如至少一个)程序模块，这些程序模块被配置以执行本发明各实施例的功能。
107.具有一组(至少一个)程序模块507的程序/实用工具508，可以存储在例如存储器
502中，这样的程序模块507包括但不限于操作系统、一个或者多个应用程序、其它程序模块以及程序数据，这些示例中的每一个或某种组合中可能包括网络环境的实现。程序模块507通常执行本发明所描述的实施例中的功能和/或方法。
108.电子设备50也可以与一个或多个外部设备509(例如键盘、指向设备、显示器510等)通信，还可与一个或者多个使得用户能与该电子设备50交互的设备通信，和/或与使得该电子设备50能与一个或多个其它计算设备进行通信的任何设备(例如网卡，调制解调器等等)通信。这种通信可以通过输入/输出(i/o)接口511进行。并且，电子设备50还可以通过网络适配器512与一个或者多个网络(例如局域网(lan)，广域网(wan)和/或公共网络，例如因特网)通信。如图所示，网络适配器512通过总线503与电子设备50的其它模块通信。应当明白，尽管图6中未示出，可以结合电子设备50使用其它硬件和/或软件模块，包括但不限于：微代码、设备驱动器、冗余处理单元、外部磁盘驱动阵列、raid系统、磁带驱动器以及数据备份存储系统等。
109.处理单元501通过运行存储在系统存储器502中的程序，从而执行各种功能应用以及数据处理，例如实现本发明实施例所提供的日志处理方法。
110.实施例七
111.本发明实施例七还提供一种包含计算机可执行指令的存储介质，所述计算机可执行指令在由计算机处理器执行时用于执行日志处理方法。
112.该方法包括：
113.当接收到日志处理请求时，获取采集的各已监控平台所对应的目标文件集；其中，所述目标文件集中包括各已监控平台运行过程中的待分析信息；
114.基于至少三个评估维度对所述待分析信息进行处理，得到与各评估维度相对应的评估属性信息；其中，所述至少三个评估维度包括事件类型维度、基于资源定位符确定的业务域类型维度、以及基于待分析信息所确定的关键字类型维度；
115.基于各评估维度的评估属性信息，确定各已监控平台所对应的质量分析报告。
116.本发明实施例的计算机存储介质，可以采用一个或多个计算机可读的介质的任意组合。计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质。计算机可读存储介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。计算机可读存储介质的更具体的例子(非穷举的列表)包括：具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机存取存储器(ram)、只读存储器(rom)、可擦式可编程只读存储器(eprom或闪存)、光纤、便携式紧凑磁盘只读存储器(cd-rom)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本文件中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。
117.计算机可读的信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了计算机可读的项目代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读的信号介质还可以是计算机可读存储介质以外的任何计算机可读介质，该计算机可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。
118.计算机可读介质上包含的项目代码可以用任何适当的介质传输，包括——但不限
于无线、电线、光缆、rf等等，或者上述的任意合适的组合。
119.可以以一种或多种程序设计语言或其组合来编写用于执行本发明实施例操作的计算机项目代码，所述程序设计语言包括面向对象的程序设计语言—诸如java、smalltalk、c ，还包括常规的过程式程序设计语言——诸如“c”语言或类似的程序设计语言。项目代码可以完全地在用户计算机上执行、部分地在用户计算机上执行、作为一个独立的软件包执行、部分在用户计算机上部分在远程计算机上执行、或者完全在远程计算机或服务器上执行。在涉及远程计算机的情形中，远程计算机可以通过任意种类的网络——包括局域网(lan)或广域网(wan)—连接到用户计算机，或者，可以连接到外部计算机(例如利用因特网服务提供商来通过因特网连接)。
120.注意，上述仅为本发明的较佳实施例及所运用技术原理。本领域技术人员会理解，本发明不限于这里所述的特定实施例，对本领域技术人员来说能够进行各种明显的变化、重新调整和替代而不会脱离本发明的保护范围。因此，虽然通过以上实施例对本发明进行了较为详细的说明，但是本发明不仅仅限于以上实施例，在不脱离本发明构思的情况下，还可以包括更多其他等效实施例，而本发明的范围由所附的权利要求范围决定。