一种基于综合巡检的容错处理方法和装置与流程

1.本发明涉及计算机软件容错处理、服务巡检分析技术领域，特别是涉及一种基于综合巡检的容错处理方法和装置。


背景技术：

2.jenkins部署云平台从单服务到整个平台以及相关第三方中间件，在安装、部署、运行等不同阶段会出现各种问题，同时由于服务本身复杂度不同，在不同运行阶段，问题种类、出现频率和处理方式也天差地别。于不同角色而言，处理庞杂的问题都存在巨大挑战。对于大部分内部系统，维护人员也无法满足实时监控，一旦出现问题，及时恢复也变得相当困难，系统快速恢复变得遥不可及。尤其在研发过程中，对于编译和部署是研发的核心步骤，大型软件编译打包由于耗时较长，一般都是在晚间进行，一旦失败且未及时处理，对第二天的测试等安排会带来延期，对整个项目进度存在较大风险和挑战。
3.鉴于此，克服该现有技术所存在的缺陷是本技术领域亟待解决的问题。


技术实现要素：

4.本发明要解决的技术问题是现有技术类似边车、prometheus一类的监控服务，主要为master和slave提供节点监控数据，侧重点主要在于监控已启动服务，解决问题主要以重启服务居多，处理手段简单、粗暴，方案单一，无法涵盖复杂场景，监控、运维割裂，对于jenkins编译、部署等阶段出现的各种问题也无法及时处理。
5.本发明采用如下技术方案：
6.第一方面，本发明提供了一种基于综合巡检的容错处理方法，综合巡检包括服务巡检和日志巡检，其中，服务巡检面向有固定端口或服务名的服务；日志巡检根据日志路径进行关键字的筛选和查询进行相应日志巡检，具体的：
7.对服务巡检和日志巡检设置统一分析处理定义下的多个问题分类名称；在相应分类之下包含有多个问题编号；
8.通过历史分析过程，建立所述服务巡检和日志巡检与各个问题编号的对应分析关系；
9.其中，各个问题编号与相应问题分类的处理步骤相关联。
10.优选的，所述服务巡检的分析对象包含第三方组件和/或web服务；
11.所述第三方组件包括redis、mysql、es和jenkins中的一种或者多种；
12.web服务包括nacos、sentinel、自定义平台或自定义系统中一种或者多种。
13.优选的，服务巡检中通过系统自带端口检测命令定时轮训查询通信情况；日志巡检中按照预设时长对日志文件进行切割获取。
14.优选的，问题分类包括networkerror、systemerror、ioerror、scripterror、nullexception、databaseerror和builderror中的一类或者多类；
15.其中，所述networkerror表明下载依赖失败、传包失败或连接节点失败；所述
systemerror表明服务器宕机或权限问题；所述ioerror表明磁盘空间不足；所述scripterror表明编译脚本问题；所述nullexception表明传参问题或者java服务空指针异常；所述databaseerror表明数据库部署问题；所述builderror表明编译错误。
16.优选的，在问题分类为networkerror时，相应的处理步骤包括：
17.调用连通性接口再次确认是否正常连接；
18.若没有处于正常连接，则调用脚本重启节点服务；
19.再次检查是否正常连接；
20.若还没有处于正常连接，则重启本次编译任务，进行传参对失败任务进行重启。
21.优选的，在问题分类为builderror时，相应的处理步骤包括：
22.检索报错的日志行并解析该行的包名、文件名或类名，结合正则表达式，相关路径配置变量对字符串进行分割查找完成拆解；
23.通过代码工具对文件出处进行排查，并记录从上次编译成功到本次编译失败之间所有提交的对应人员，将报错日志进行邮件发送。
24.优选的，在问题分类为networkerror时，相应的处理步骤包括：
25.解析依赖包名，哈希值等重要信息；删除缓存中的脏数据；
26.重新下载包；重新启动任务。
27.优选的，针对跟问题类型下所包含的多个问题编号建立关系-概率树，所述关系-概率树以历史统计的发生概率高低作为树中节点划分层级依据，相应的问题编号之间的关联关系则作为相应建立节点之间建立连线的依据，具体的：
28.在发生故障时，根据相关故障码确定所属的问题类型；
29.在相应的问题类型的关系-概率树中，从统计发生概率最高的位于根节点的问题编号开始向关系-概率树叶节点遍历，依次通过所述问题编号所关联的服务巡检和/或日志巡检确认当前故障与之适配度；
30.找到适配度达到预设阈值的问题编号，执行与相应处理步骤。
31.优选的，在出现服务巡检和日志巡检同时与一个问题编号存在分析关系时，确认所述服务巡检和日志巡检各自所消耗的时间，所述方法还包括：
32.分析所述问题编号所处的问题类型下，其他问题编号同样依赖与相应服务巡检和日志巡检的情况；
33.以相应服务巡检和日志巡检各自所消耗的时间作为第一乘积因子，以两者所关联的各问题编号出现的概率为第二乘积因子，将各个问题编号的第二乘积因子与所述第一乘积因子进行乘积运算后的结果求和得到其均值；
34.根据所述均值的大小，确定在出现服务巡检和日志巡检同时与一个问题编号存在分析关系时，是选择服务巡检或者是选择日志巡检。
35.第二方面，本发明还提供了一种基于综合巡检的容错处理装置，用于实现第一方面所述的基于综合巡检的容错处理方法，所述装置包括：
36.至少一个处理器；以及，与所述至少一个处理器通信连接的存储器；其中，所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述处理器执行，用于执行第一方面所述的基于综合巡检的容错处理方法。
37.第三方面，本发明还提供了一种非易失性计算机存储介质，所述计算机存储介质
存储有计算机可执行指令，该计算机可执行指令被一个或多个处理器执行，用于完成第一方面所述的基于综合巡检的容错处理方法。
38.本发明通过实时采集指定服务日志，对采集到的日志进行提取、分析，将分析结果与预设的处理流程进行匹配，达到自动化分析和处理问题的效果。
39.本发明中通过预定义问题处理方法，结合端口、服务及日志情况、实时巡检信息，对错误进行靶向处理，使问题处理更加可靠、高效。同时本发明将问题处理范围进一步扩大，把服务、系统与问题处理分离，对问题处理更加动态化、灵活化、多方案化。
附图说明
40.为了更清楚地说明本发明实施例的技术方案，下面将对本发明实施例中所需要使用的附图作简单地介绍。显而易见地，下面所描述的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
41.图1是本发明实施例提供的一种基于综合巡检的容错处理方法架构示意图；
42.图2是本发明实施例提供的一种基于综合巡检的容错处理方法流程示意图；
43.图3是本发明实施例提供的一种基于综合巡检的容错处理方法流程示意图；
44.图4是本发明实施例提供的一种基于综合巡检的容错处理方法流程示意图；
45.图5是本发明实施例提供的一种基于综合巡检的容错处理方法流程示意图；
46.图6是本发明实施例提供的一种基于综合巡检的容错处理方法中问题编号场景示意图；
47.图7是本发明实施例提供的一种基于综合巡检的容错处理方法中问题编号场景示意图；
48.图8是本发明实施例提供的一种基于综合巡检的容错处理方法流程示意图；
49.图9是本发明实施例提供的一种基于综合巡检的容错处理方法中问题库、步骤库和执行库关系示意图；
50.图10是本发明实施例提供的一种基于综合巡检的容错处理装置结构示意图。
具体实施方式
51.为了使本发明的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本发明进行进一步详细说明。应当理解，此处所描述的具体实施例仅仅用以解释本发明，并不用于限定本发明。
52.在本发明的描述中，术语“内”、“外”、“纵向”、“横向”、“上”、“下”、“顶”、“底”等指示的方位或位置关系为基于附图所示的方位或位置关系，仅是为了便于描述本发明而不是要求本发明必须以特定的方位构造和操作，因此不应当理解为对本发明的限制。
53.本发明中术语“第一”、“第二”等仅用于描述目的，而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”等的特征可以明示或者隐含地包括一个或者更多个该特征。在本技术的描述中，除非另有说明，“多个”的含义是两个或两个以上。
54.在本技术中，除非另有明确的规定和限定，术语“连接”应做广义理解，例如，“连
接”可以是固定连接，也可以是可拆卸连接，或成一体；可以是直接相连，也可以通过中间媒介间接相连。此外，术语“耦接”可以是实现信号传输的电性连接的方式。
55.现有技术类似边车、prometheus一类的监控服务，主要为master和slave提供节点监控数据，侧重点主要在于监控已启动服务，解决问题主要以重启服务居多，处理手段简单、粗暴，方案单一，无法涵盖复杂场景，监控、运维割裂，对于jenkins编译、部署等阶段出现的各种问题也无法及时处理，且仍然无法解决以下问题：
56.需要人为干预，对各环节处理问题人员能力要求较高，处理问题流程比较繁琐、人工成本等损耗巨大；由于问题种类场景多，人工处理问题主观性较高，准确性存在偏差；从出现问题到发现问题再到处理问题，无法it化，各流程存在割裂，问题响应速度和效率不高；现有处理问题机制比较单一，面向场景单一，只适用于某些特殊场景，不具有通用性；问题处理粒度太大，欠缺对问题全面分析，问题解决不彻底。系统运行过程中的错误日志无法及时反馈运维人员，问题无法及时解决。
57.此外，下面所描述的本发明各个实施方式中所涉及到的技术特征只要彼此之间未构成冲突就可以相互组合。
58.实施例1:
59.本发明实施例1提供了一种基于综合巡检的容错处理方法，综合巡检包括服务巡检和日志巡检，其中，服务巡检面向有固定端口或服务名的服务；日志巡检根据日志路径进行关键字的筛选和查询进行相应日志巡检，如图1所示，具体的：
60.对服务巡检和日志巡检设置统一分析处理定义下的多个问题分类名称；在相应分类之下包含有多个问题编号。
61.所述服务巡检的分析对象包含第三方组件和/或web服务；
62.所述第三方组件包括redis、mysql、es和jenkins中的一种或者多种；
63.web服务包括nacos、sentinel、自定义平台或自定义系统中一种或者多种。
64.通过历史分析过程，建立所述服务巡检和日志巡检与各个问题编号的对应分析关系。其中，各个问题编号与相应问题分类的处理步骤相关联。
65.通常服务巡检中通过系统自带端口检测命令定时轮训查询通信情况；日志巡检中按照预设时长对日志文件进行切割获取。
66.本发明实施例通过实时采集指定服务日志，对采集到的日志进行提取、分析，将分析结果与预设的处理流程进行匹配，达到自动化分析和处理问题的效果。
67.本发明实施例中通过预定义问题处理方法，结合端口、服务及日志情况、实时巡检信息，对错误进行靶向处理，使问题处理更加可靠、高效。同时本发明将问题处理范围进一步扩大，把服务、系统与问题处理分离，对问题处理更加动态化、灵活化、多方案化。
68.在本发明实施例中，除了主体方案中所阐述的设计问题类、问题编号、服务巡检、日志巡检，以及处理步骤之间的逻辑联系外，作为可选的实现方案，为了形成更为完善的问题库，对出现的问题进行统一定义处理过程中，还可以包含严重程度，执行次数，执行系统等关联要素。
69.在本发明实施例中，对于日志巡检而言，由于其相较服务巡检而言文件信息量更大，因此，其处理过程中也会多有些关联性设计，例如包括：
70.日志路径设置：明确日志分析的范围，当有多个服务可设置多个采集路径。
71.关键条件设置：比如哪些情况需要匹配，例如日志中出现error、exception等。
72.日志采集时间范围：日志量较大问题较多时可做过滤，减少索引和处理时间。
73.日志采集设置：有两种选型可选择，包括大型系统日志量特别巨大可以借助elasticsearch+filebeat对日志进行实时采集，并根据已设置的关键条件进行查询，具体的es查询方法不在此详细描述，并根据文件路径对错误的上下x(0《x《100)行进行保存，方便后续通知；小型系统日志量较小的系统，也可以通过脚本形式采集，可按照小时对日志文件进行切割。例如通过python脚本进行粒度更小的搜索查询，python脚本具体内容不做具体介绍。
74.在本发明实施例中，巡检服务会将匹配到的关键词、端口或服务信息，以及日志按照规定格式存储起来，方便后续调用。
75.本发明实施例在以整个编译过程为例进行展示中，以下三种问题常见且不容易自动化处理。
76.第一类为节点问题，由于网络波动等问题，节点会断开导致编译失败，问题发生只能手动启动或更换节点。
77.第二类为代码问题，开发人员漏提或错提导致编译失败，需要定位问题人员，并且精准发邮件到个人。
78.第三类依赖下载问题，由于下载第三方依赖失败，导致编译失败，需要重新下载依赖。
79.因此，作为本发明实施例较为推荐的问题分类划分方式，问题分类至少被划分为包括networkerror、systemerror、ioerror、scripterror、nullexception、databaseerror和builderror中的一类或者多类；
80.其中，所述networkerror表明下载依赖失败、传包失败或连接节点失败；所述systemerror表明服务器宕机或权限问题；所述ioerror表明磁盘空间不足；所述scripterror表明编译脚本问题；所述nullexception表明传参问题或者java服务空指针异常；所述databaseerror表明数据库部署问题；所述builderror表明编译错误。
81.依托上面所划分的问题分类，以下将通过摘选其中的典型几个问题类型，阐述配套的处理步骤。
82.第一示例，在问题分类为networkerror时，如图2所示，相应的处理步骤包括：
83.在步骤201中，调用连通性接口再次确认是否正常连接。
84.其中，可以使用jenkins自带的agent或者ansible，也可以使用tracroute等端口检测命令进行检查。
85.在步骤202中，若没有处于正常连接，则调用脚本重启节点服务。
86.可以通过jenkinspipeline远程服务器并进行节点重启，也可以通过sshcommand远程执行命令重启，还可以通过编写脚本的形式重启。
87.在步骤203中，再次检查是否正常连接。
88.在步骤204中，若还没有处于正常连接，则重启本次编译任务，进行传参对失败任务进行重启。
89.例如通过调用jenkinsapi并进行传参对失败任务进行重启。
90.第二示例，在问题分类为builderror时，如图3所示，相应的处理步骤包括：
91.在步骤301中，检索报错的日志行并解析该行的包名、文件名或类名，结合正则表达式，相关路径配置变量对字符串进行分割查找完成拆解。
92.在步骤302中，通过代码工具对文件出处进行排查，并记录从上次编译成功到本次编译失败之间所有提交的对应人员，将报错日志进行邮件发送。
93.例如，上次编译成功到本次编译失败之间所有提交的对应人员的数据可以通过自有系统及其相关jenkins接口获取。
94.第三示例，在问题分类为networkerror时，如图4所示，相应的处理步骤包括：
95.在步骤401中，解析依赖包名，哈希值等重要信息；删除缓存中的脏数据；
96.在步骤402中，重新下载包；重新启动任务。
97.在本发明实施例中，为了能够更高效的管理各个问题类，以及相应问题类中所包含的问题编号，针对跟问题类型下所包含的多个问题编号建立关系-概率树，所述关系-概率树以历史统计的发生概率高低作为树中节点划分层级依据，相应的问题编号之间的关联关系(包括信令层面的上下游关系，逻辑上的包含关系等等)则作为相应建立节点之间建立连线的依据，如图5和图6所示，具体的：
98.在步骤501中，在发生故障时，根据相关故障码确定所属的问题类型。
99.在步骤502中，在相应的问题类型的关系-概率树中，从统计发生概率最高的位于根节点的问题编号开始向关系-概率树叶节点遍历，依次通过所述问题编号所关联的服务巡检和/或日志巡检确认当前故障与之适配度。
100.以图6为例，问题编号6作为其关系-概率树的根节点，即认定为近段时间统计下来，发生故障概率最高的问题编号。这里需要补充说明的是，问题编号并不具有问题发生顺序等属性概念，其仅仅是用来区别不同问题的标识号，其一旦与具体问题内容关联后，没有特殊需求的情况下就不会随意修改；而在实际操作中，会周期性的刷新不同问题编号之间的发生概率，从而更新所述关系-概率树，例如图7就可以理解是相应图6所示的关系-概率树中，在进行了新一轮发生概率统计之后更新完成的关系-概率树。而结合具体应用场景而言，相应的触发刷新不同问题编号之间的发生概率的时机，除了上述描述的依周期来执行外，还存在可并行结合的条件，例如：系统更新、硬件更新、网络架构更新等等，都可以以逻辑或的方式和上述周期同步作为触发刷新不同问题编号之间的发生概率的判断条件。
101.在步骤503中，找到适配度达到预设阈值的问题编号，执行与相应处理步骤。
102.在上述步骤501-步骤503所提出的改进场景之中，还存在一种可能的情形，在出现服务巡检和日志巡检同时与一个问题编号存在分析关系时，确认所述服务巡检和日志巡检各自所消耗的时间，如图6所示，对于问题编号6同时存在服务巡检(服务1)和日志巡检(日志1)可作为分析确认相应问题编号6发生的途径，如图8所示，所述方法还包括：
103.在步骤601中，分析所述问题编号所处的问题类型下，其他问题编号同样依赖与相应服务巡检和日志巡检的情况。
104.在图6中，在同一问题类型下，即图6所示的关系-概率树中(需要补充说明的是，同一问题类型下可能存在多棵关系-概率树，而不应该将其局限的理解为一个问题类型下只有一颗树。原因也很直观，前面步骤501-步骤503中已经介绍，关系-概率树的节点之间的联系建立是依赖于问题编号所代表的问题之间的关联关系)，问题编号6所关联的服务1和日志1中，服务1同时被问题编号2、问题编号7和问题编号8依赖；日志1同时被问题编号1、问题
编号3和问题编号5所依赖。此处举例即针对上述其他问题编号同样依赖与相应服务巡检和日志巡检的情况的解释。
105.在步骤602中，以相应服务巡检和日志巡检各自所消耗的时间作为第一乘积因子，以两者所关联的各问题编号出现的概率为第二乘积因子，将各个问题编号的第二乘积因子与所述第一乘积因子进行乘积运算后的结果求和后得到其均值。
106.以日志1为例，相应的求和后得到其均值过程为，此处为了避免关联符号
“‑”
与加号“+”的混淆，将相应的“耗时”后面跟随的标志号改为下标呈现方式：
107.(概率6*耗时
6-2
+概率1*耗时
1-1
+概率3*耗时
3-1
+概率5*耗时
5-1
)/4；(1)
108.以服务1为例，相应的求和后得到其均值过程为，此处为了避免关联符号
“‑”
与加号“+”的混淆，将相应的“耗时”后面跟随的标志号改为下标呈现方式：
109.(概率6*耗时
6-1
+概率2*耗时
2-1
+概率7*耗时
7-1
+概率8*耗时
8-1
)/4；(2)
110.在步骤603中，根据所述均值的大小，确定在出现服务巡检和日志巡检同时与一个问题编号存在分析关系时，是选择服务巡检或者是选择日志巡检。
111.以上面所展示示例，即分析式(1)和式(2)的结果大小，其中结果值越大表明相应的日志或者服务的巡检等效价值越高。
112.在具体实现过程中，真实情况会比示意图图6和图7展现的复杂度，一个问题编号的分析可能是要依赖多个服务或者日志才能完成，相应本发明实施例所示意的图仅仅是为了阐述本发明基本原理用，因此是最为简化的展示效果。
113.本发明实施例通过预定义问题处理方法，结合端口、服务及日志情况、实时巡检信息，对错误进行靶向处理，使问题处理更加可靠、高效。同时该发明将问题处理范围进一步扩大，把服务、系统与问题处理分离，对问题处理更加动态化、灵活化、多方案化，该方案主要有以下优点：
114.屏蔽系统、服务之间的差异，让问题处理模板化、通用化；问题及时发现，及时处理，提升处理效率，不需要人为干预，解放人力资源；通过日志分析得到问题具体信息，处理粒度更小，准确性更高；该方案可拓展性高，与其他系统服务对接比较容易，在整个系统构建中改造较小；对错误处理各项数据进行监控以及展示，有助于量化分析本次错误结果，为问题分析处理提供数据支撑。
115.本发明实施例从问题产生到处理结束以流水线方式进行，将问题处理步骤工厂化，大量缩短了人为处理的不确定性以及时间损耗成本，避免了不同角色人为主观处理带来的影响，提高问题处理质量；
116.本发明实施例将问题处理步骤模板化，将问题进行归类，通过问题库方式对问题进行存储，可复用，解决不同系统之间，相同问题重复处理的弊端，提升了问题解决效率。
117.本发明实施例可通过自定义规则，采用自动化规则配置策略，完善问题处理机制，显著提升问题处理灵活性；本发明实施例独立与系统和服务，高度解耦，可单独运行，具有极强的可拓展性和定制型；本发明实施例将问题处理过程记录，对问题进行记录，方便问题回溯，为从根源解决问题提供数据支持；本发明实施例通过日志分析，对于不同的问题，匹配具体的处理过程，处理更加准确。
118.实施例2:
119.本发明实施例延续实施例1所提出的方案思想，以jenkins平台常出现的问题为
例，从问题统一定义、问题处理步骤以及问题结果处理逐步展开在本发明实施例所提出场景下，上述实施例1方法的实现过程补全。
120.设置该部分主要用于建立问题库、步骤库和执行库。通过该形式实现对jenkins常见问题的分类汇总，处理的模板化、通用化，设计核心思想为对问题类型和问题步骤进行分类，同时根据用户设置对问题和处理步骤进行组合，以达到同一问题可根据具体需求实现不同处理方式。
121.该模块主要分为三个大步骤，问题统一定义、问题处理步骤以及问题结果处理。
122.第一大步骤，问题统一定义包括：
123.根据jenkins常出现的问题对问题进行统一分析处理定义、分类，以达到问题处理的精准性，以下以编译问题为例。
124.1)问题类型(ptype)
125.用于问题分类处理，做问题标识，包含但不限于:
126.networkerror:下载依赖失败、传包失败、连接节点失败等；
127.systemerror:服务器宕机、权限问题等；
128.ioerror:磁盘空间不足；
129.scripterror:编译脚本问题等；
130.nullexception:传参问题，java服务空指针异常；
131.databaseerror:数据库部署问题；
132.builderror:编译错误；
133.对于本发明实施例所阐述的重心的编译问题可设置大类为builderror。
134.2)问题编号(pnumber)
135.该字段为唯一主键，用于后续与巡检服务问题处理步骤做关联，问题编号与问题处理步骤为1-m的关系。
136.buildeerror里面可能存在多种原因，可能是服务器节点问题，也可能是代码问题，还可能是依赖下载问题，我们对上述问题进行分类编号。
137.3)问题名称(pname)
138.由于一个问题在不同的操作系统、不同的服务之间可能存在多种处理步骤，通过问题名称做区分。
139.4)严重程度(severity)
140.可分为四类:极其严重(系统服务宕机等)、严重(核心服务不正常)、普通(非核心功能不正常，不影响使用)、低(优化建议、组件安全性漏洞)，根据不同的严重程度，执行的优先级和处理速度也会有相应的区分。
141.对于服务器节点问题为严重问题，代码问题为极其严重问题，依赖下载问题也为极其严重问题。
142.5)执行步骤(executestep)
143.该部分的最小单元为命令或脚本，通过配置相关环境变量，支持python、bat以及shell等命令脚本实现支持各种操作系统及开发语言，最大化提高问题处理能力，如果需要执行复杂的处理过程，也可以上传脚本供调用，通过该种方式对装置处理问题的能力得到进一步提升。问题执行步骤，大致可分为以下四类：
144.1、执行命令：通过不同的操作系统，执行简单的系统命令，比如systemctl、reboot、python等；
145.2、执行脚本：通过上传具体脚本，自动根据后缀识别脚本，并支持传递参数执行；
146.3、清理环境：清理固定的目录，比如jenkins节点的编译构建数据、var目录的缓存数据等；
147.4、通知类型：可以定义通知的类型(短信、邮件)，通知的模板、附件内容等。
148.服务巡检设置中主要面向有固定端口或服务名的服务，包含服务所需要的第三方组件，包含但不限于redis、mysql、es、jenkins等，也可以用于web服务，比如nacos、sentinel、自定义平台、自定义系统等。
149.1.端口号设置：设置需要巡检的端口号，后台巡检服务定时检测端口通信情况；
150.2.服务名设置：设置服务名，后台监控服务运行情况；
151.3.巡检时间设置：设置轮循时间；
152.4.执行的操作系统；
153.日志巡检设置中主要根据日志路径进行关键字的筛选和查询。为进行更加准确的判断和处理，需要对日志格式进行标准格式设置，包含时间戳、log leve、log message等，格式如下：
[0154][0155]
对日志进行分类分文件分时打印，文件命名如下:
[0156]
service-request-info-2023-06-05t11-03-01.940.log等，如果超过一天则对日志进行压缩service-request-info-20230605110301940.gz。同时也需要对不同功能的日志进行分类，比如可分为编译日志、jenkins运行日志、部署日志、监控日志等，设置主要如下：
[0157]
1.日志路径设置：明确日志分析的范围，当有多个服务，可设置多个采集路径，通过上文的文件模糊匹配某一路径下所有日志进行检索；
[0158]
2.关键条件设置：比如哪些情况需要匹配，例如日志中出现error、exception等；
[0159]
3.日志采集时间范围：日志量较大，问题较多时，可做过滤，减少索引和处理时间；
[0160]
4.日志采集设置：对目标日志进行采集，可以通过第三方系统(elk)进行采集，也可以通过编写exporter形式进行采集，本发明只提供相关思想，具体方式可根据实际情况进行自由选择。
[0161]
第二大步骤，问题处理步骤
[0162]
巡检服务为exporter，主要功能是对服务巡检和日志巡检设置的条件以主动方式进行定时查询筛选，当匹配到与预设问题相符时，将该条记录包含问题与处理步骤置于问题处理队列中。exporter策略实现思想如下：
[0163]
服务巡检中：端口巡检、服务巡检：通过不同系统自带端口检测命令定时轮训查询通信情况，例如linux系统可使用lsof等底层命令，也可以通过python等语言进行开发，屏
蔽底层操作系统差异，当查询不到数据时，可判定服务异常，启动问题处理步骤。
[0164]
日志巡检中包括以下两种情形：
[0165]
日志文件超量：通过第三方日志采集软件对日志进行实时采集，根据已设置的关键条件进行查询，并根据文件路径对错误的上下x(0《x《100)行进行保存，方便后续通知和进一步的排查。
[0166]
日志文件正常：可通过系统自带命令进行关键字查询，也可通过脚本进行粒度更小的搜索查询。
[0167]
设置问题与执行步骤的对应关系，设置问题处理次数，设置如果有步骤出现问题是否继续执行等，数据模型可根据实际情况进行设置，示例如下：
[0168]
[0169][0170]
第三大步骤，问题结果反馈
[0171]
主要用于记录相关日志，包含但不限于处理过程以及分析日志、执行脚本日志等，对处理结果进行日志压缩，通过邮件发送、短信等方式进行通知。
[0172]
当问题队列中存在问题时，会首先根据预设值的问题与该问题再一次匹配，如果匹配到则执行问题处理步骤，即上述步骤设置处理脚本，否则直接做问题记录。
[0173]
将问题处理结束与问题处理过程日志进行整理汇总，并压缩，后续以邮件形式通知，也可以使用监控平台或者查询平台进行数展示。将本次处理生成记录存储，方便后续为其他系统提供数据。
[0174]
参考图9中，a1表示a类问题的第一种问题，sa表示第一种执行方法，执行库中的a1 sa sb表示队列第一位需要处理a类第一种问题的步骤为先执行sa，再执行sb。
[0175]
实施例3：
[0176]
如图10所示，是本发明实施例的基于综合巡检的容错处理装置的架构示意图。本实施例的基于综合巡检的容错处理装置包括一个或多个处理器21以及存储器22。其中，图10中以一个处理器21为例。
[0177]
处理器21和存储器22可以通过总线或者其他方式连接，图10中以通过总线连接为例。
[0178]
存储器22作为一种非易失性计算机可读存储介质，可用于存储非易失性软件程序和非易失性计算机可执行程序，如实施例1中的基于综合巡检的容错处理方法。处理器21通过运行存储在存储器22中的非易失性软件程序和指令，从而执行基于综合巡检的容错处理
方法。
[0179]
存储器22可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件、闪存器件、或其他非易失性固态存储器件。在一些实施例中，存储器22可选包括相对于处理器21远程设置的存储器，这些远程存储器可以通过网络连接至处理器21。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。
[0180]
所述程序指令/模块存储在所述存储器22中，当被所述一个或者多个处理器21执行时，执行上述实施例1中的基于综合巡检的容错处理方法，例如，执行以上描述的图2-图5，以及图8所示的各个步骤。
[0181]
值得说明的是，上述装置和系统内的模块、单元之间的信息交互、执行过程等内容，由于与本发明的处理方法实施例基于同一构思，具体内容可参见本发明方法实施例中的叙述，此处不再赘述。
[0182]
本领域普通技术人员可以理解实施例的各种方法中的全部或部分步骤是可以通过程序来指令相关的硬件来完成，该程序可以存储于一计算机可读存储介质中，存储介质可以包括：只读存储器(rom，read only memory)、随机存取存储器(ram，random access memory)、磁盘或光盘等。
[0183]
以上所述仅为本发明的较佳实施例而已，并不用以限制本发明，凡在本发明的精神和原则之内所作的任何修改、等同替换和改进等，均应包含在本发明的保护范围之内。

技术特征：
1.一种基于综合巡检的容错处理方法，其特征在于，综合巡检包括服务巡检和日志巡检，其中，服务巡检面向有固定端口或服务名的服务；日志巡检根据日志路径进行关键字的筛选和查询进行相应日志巡检，具体的：对服务巡检和日志巡检设置统一分析处理定义下的多个问题分类名称；在相应分类之下包含有多个问题编号；通过历史分析过程，建立所述服务巡检和日志巡检与各个问题编号的对应分析关系；其中，各个问题编号与相应问题分类的处理步骤相关联。2.根据权利要求1所述的基于综合巡检的容错处理方法，其特征在于，所述服务巡检的分析对象包含第三方组件和/或web服务；所述第三方组件包括redis、mysql、es和jenkins中的一种或者多种；web服务包括nacos、sentinel、自定义平台或系统中一种或者多种。3.根据权利要求1所述的基于综合巡检的容错处理方法，其特征在于，服务巡检中通过系统自带端口检测命令定时轮训查询通信情况；日志巡检中按照预设时长对日志文件进行切割获取。4.根据权利要求1所述的基于综合巡检的容错处理方法，其特征在于，问题分类包括networkerror、systemerror、ioerror、scripterror、nullexception、databaseerror和builderror中的一类或者多类；其中，所述networkerror表明下载依赖失败、传包失败或连接节点失败；所述systemerror表明服务器宕机或权限问题；所述ioerror表明磁盘空间不足；所述scripterror表明编译脚本问题；所述nullexception表明传参问题或者java服务空指针异常；所述databaseerror表明数据库部署问题；所述builderror表明编译错误。5.根据权利要求4所述的基于综合巡检的容错处理方法，其特征在于，在问题分类为networkerror时，相应的处理步骤包括：调用连通性接口再次确认是否正常连接；若没有处于正常连接，则调用脚本重启节点服务；再次检查是否正常连接；若还没有处于正常连接，则重启本次编译任务，进行传参对失败任务进行重启。6.根据权利要求4所述的基于综合巡检的容错处理方法，其特征在于，在问题分类为builderror时，相应的处理步骤包括：检索报错的日志行并解析该行的包名、文件名或类名，结合正则表达式，相关路径配置变量对字符串进行分割查找完成拆解；通过代码工具对文件出处进行排查，并记录从上次编译成功到本次编译失败之间所有提交的对应人员，将报错日志进行邮件发送。7.根据权利要求4所述的基于综合巡检的容错处理方法，其特征在于，在问题分类为networkerror时，相应的处理步骤包括：解析依赖包名，哈希值等重要信息；删除缓存中的脏数据；重新下载包；重新启动任务。8.根据权利要求1-7任一所述的基于综合巡检的容错处理方法，其特征在于，针对跟问题类型下所包含的多个问题编号建立关系-概率树，所述关系-概率树以历史统计的发生概
率高低作为树中节点划分层级依据，相应的问题编号之间的关联关系则作为相应建立节点之间建立连线的依据，具体的：在发生故障时，根据相关故障码确定所属的问题类型；在相应的问题类型的关系-概率树中，从统计发生概率最高的位于根节点的问题编号开始向关系-概率树叶节点遍历，依次通过所述问题编号所关联的服务巡检和/或日志巡检确认当前故障与之适配度；找到适配度达到预设阈值的问题编号，执行与相应处理步骤。9.根据权利要求8所述的基于综合巡检的容错处理方法，其特征在于，在出现服务巡检和日志巡检同时与一个问题编号存在分析关系时，确认所述服务巡检和日志巡检各自所消耗的时间，所述方法还包括：分析所述问题编号所处的问题类型下，其他问题编号同样依赖与相应服务巡检和日志巡检的情况；以相应服务巡检和日志巡检各自所消耗的时间作为第一乘积因子，以两者所关联的各问题编号出现的概率为第二乘积因子，将各个问题编号的第二乘积因子与所述第一乘积因子进行乘积运算后的结果求和得到其均值；根据所述均值的大小，确定在出现服务巡检和日志巡检同时与一个问题编号存在分析关系时，是选择服务巡检或者是选择日志巡检。10.一种基于综合巡检的容错处理装置，其特征在于，所述装置包括：至少一个处理器；以及，与所述至少一个处理器通信连接的存储器；其中，所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述处理器执行，用于执行权利要求1-9任一所述的基于综合巡检的容错处理方法。

技术总结
本发明涉及计算机软件容错处理、服务巡检分析技术领域，提供了一种基于综合巡检的容错处理方法和装置。其中综合巡检包括服务巡检和日志巡检，其中，服务巡检面向有固定端口或服务名的服务；日志巡检根据日志路径进行关键字的筛选和查询进行相应日志巡检，具体的：对服务巡检和日志巡检设置统一分析处理定义下的多个问题分类名称；在相应分类之下包含有多个问题编号；通过历史分析过程，建立所述服务巡检和日志巡检与各个问题编号的对应分析关系；其中，各个问题编号与相应问题分类的处理步骤相关联。本发明通过实时采集指定服务日志，对采集到的日志进行提取、分析，将分析结果与预设的处理流程进行匹配，达到自动化分析和处理问题的效果。问题的效果。问题的效果。


技术研发人员：盖玉成 童庆武 姜萌 陈子义 徐瑞晚 程航远 王柯
受保护的技术使用者：烽火通信科技股份有限公司
技术研发日：2023.07.21
技术公布日：2023/10/7