CN116149932A - 软件系统状态的检测方法、装置及电子设备 - Google Patents

Abstract

本申请公开了一种软件系统状态的检测方法、装置及电子设备。其中，该方法包括：获取目标软件系统中每个子系统的系统日志，其中，目标软件系统由多个子系统构成，多个子系统之间具有业务关联关系，每个子系统用于处理对应的业务数据；根据系统日志确定每个子系统在运行过程中生成的目标运行数据；检测每个子系统对应的目标运行数据是否满足对应子系统的预设条件，得到每个子系统对应的目标检测结果；根据每个子系统对应的目标检测结果确定目标软件系统的系统状态，其中，系统状态表征目标软件系统是否正常运行。本申请解决了现有技术中对由多个子系统组成的软件系统的系统状态检测效率低的问题的技术问题。

Description

软件系统状态的检测方法、装置及电子设备

技术领域

本申请涉及软件技术领域，具体而言，涉及一种软件系统状态的检测方法、装置及电子设备。

背景技术

在金融行业，通常会将具有业务关联关系的多个软件系统组成一个大型的业务软件系统。其中，多个软件系统中每个软件系统可以理解为是业务软件系统的一个子系统。

容易注意到的是，当多个软件系统中有任意一个系统出现异常时，都会影响业务软件系统的整体业务执行能力。因此，为了及时检测业务软件系统的系统状态，现有技术通常采用人工的方式，由运维人员定期对组成业务软件系统的每个软件系统进行逐一排查，结合每个子系统对应的排查结果确定目标软件系统的系统状态。由于这种方式需要消耗大量的人力物力，并且容易出现排查不及时的问题，因此会导致对业务软件系统的系统状态检测效率低的问题。

针对上述的问题，目前尚未提出有效的解决方案。

发明内容

本申请实施例提供了一种软件系统状态的检测方法、装置及电子设备，以至少解决现有技术中对由多个子系统组成的软件系统的系统状态检测效率低的问题的技术问题。

根据本申请实施例的一个方面，提供了一种软件系统状态的检测方法，包括：获取目标软件系统中每个子系统的系统日志，其中，目标软件系统由多个子系统构成，多个子系统之间具有业务关联关系，每个子系统用于处理对应的业务数据；根据系统日志确定每个子系统在运行过程中生成的目标运行数据；检测每个子系统对应的目标运行数据是否满足对应子系统的预设条件，得到每个子系统对应的目标检测结果；根据每个子系统对应的目标检测结果确定目标软件系统的系统状态，其中，系统状态表征目标软件系统是否正常运行。

进一步地，软件系统状态的检测方法还包括：获取每个子系统的启动日志和心跳日志，其中，启动日志中至少包括每个子系统在服务器上的启动信息，心跳日志中至少包括每个子系统每次向数据库发送心跳信息时的时间，系统日志包括启动日志和心跳日志。

进一步地，软件系统状态的检测方法还包括：根据启动日志确定每个子系统的第一启动数据，其中，第一启动数据中至少包含在当前时刻运行每个子系统的运行服务器的服务器标识，服务器标识用于表征运行服务器是否为预设的备用服务器；根据心跳日志确定每个子系统的响应状态数据，其中，响应状态数据中至少包含每个子系统在向数据库发送相邻的两个心跳信息时的间隔时长，目标运行数据至少包括第一启动数据和响应状态数据。

进一步地，软件系统状态的检测方法还包括：检测第一启动数据中所包含的服务器标识是否为目标服务器标识，得到每个子系统对应的第一检测结果，其中，目标服务器标识为每个子系统在正常运行状态下所对应的运行服务器的服务器标识；检测响应状态数据中所包含的间隔时长是否小于或等于预设间隔时长，得到每个子系统对应的第二检测结果；根据第一检测结果和第二检测结果确定目标检测结果。

进一步地，软件系统状态的检测方法还包括：在第一启动数据中所包含的服务器标识为目标服务器标识，并且响应状态数据中所包含的间隔时长小于或等于预设间隔时长的情况下，确定目标运行数据满足对应子系统的预设条件；在第一启动数据中所包含的服务器标识与目标服务器标识不同，或响应状态数据中所包含的间隔时长大于预设间隔时长的情况下，确定目标运行数据不满足对应子系统的预设条件。

进一步地，软件系统状态的检测方法还包括：在每个子系统对应的目标运行数据满足每个子系统对应的预设条件的情况下，确定目标软件系统处于正常状态；在多个子系统中存在至少一个异常子系统的情况下，确定目标软件系统处于异常状态，其中，异常子系统对应的目标运行数据未满足异常子系统所对应的预设条件。

进一步地，软件系统状态的检测方法还包括：根据启动日志确定每个子系统的第二启动数据，其中，第二启动数据用于表征每个子系统是否成功启动；根据第二启动数据，检测多个子系统中是否存在至少一个第一异常子系统，其中，第一异常子系统为启动失败的子系统；在多个子系统中存在至少一个第一异常子系统的情况下，确定目标软件系统处于异常状态。

根据本申请实施例的另一方面，还提供了一种软件系统状态的检测装置，包括：获取模块，用于获取目标软件系统中每个子系统的系统日志，其中，目标软件系统由多个子系统构成，多个子系统之间具有业务关联关系，每个子系统用于处理对应的业务数据；第一确定模块，用于根据系统日志确定每个子系统在运行过程中生成的目标运行数据；检测模块，用于检测每个子系统对应的目标运行数据是否满足对应子系统的预设条件，得到每个子系统对应的目标检测结果；第二确定模块，用于根据每个子系统对应的目标检测结果确定目标软件系统的系统状态，其中，系统状态表征目标软件系统是否正常运行。

根据本申请实施例的另一方面，还提供了一种计算机可读存储介质，该计算机可读存储介质中存储有计算机程序，其中，计算机程序被设置为运行时执行上述的软件系统状态的检测方法。

根据本申请实施例的另一方面，还提供了一种电子设备，电子设备包括一个或多个处理器和存储器，存储器用于存储一个或多个程序，其中，当一个或多个程序被一个或多个处理器执行时，使得一个或多个处理器实现上述的软件系统状态的检测方法。

在本申请中，采用通过基于每个子系统的系统日志自动确定每个子系统的目标运行数据的方式，首先获取目标软件系统中每个子系统的系统日志，然后根据系统日志确定每个子系统在运行过程中生成的目标运行数据，并检测每个子系统对应的目标运行数据是否满足对应子系统的预设条件，得到每个子系统对应的目标检测结果，最后根据每个子系统对应的目标检测结果确定目标软件系统的系统状态，其中，目标软件系统由多个子系统构成，多个子系统之间具有业务关联关系，每个子系统用于处理对应的业务数据，系统状态表征目标软件系统是否正常运行。

需要注意到的是，由于每个子系统用于处理各自对应的业务数据，因此每个子系统在正常运行时的运行数据也会存在差别，在此基础上，本申请通过基于每个子系统的系统日志自动确定每个子系统的目标运行数据，并结合每个子系统对应的预设条件，实现了自动检测每个子系统是否处于正常运行状态的目的，进行实现了自动确定目标软件系统的系统状态的效果。由于本申请的方案无需人工排查日志、分析日志以及核对每个子系统的运行数据是否符合正常运行时的要求，因此本申请的技术方案可以节约大量的人力物力，从而实现了提高对目标软件系统的系统状态的检测效率。

由此可见，本申请的技术方案达到了根据系统日志自动检测目标软件系统的系统状态的目的，从而避免了现有技术中使用人工方式排查软件系统的系统状态导致的人工成本高的问题，进而解决了现有技术中对由多个子系统组成的软件系统的系统状态检测效率低的问题的技术问题。

附图说明

此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：

图1是根据本申请实施例的一种可选的软件系统状态的检测方法的流程图；

图2是根据本申请实施例的一种可选的目标软件系统的构成示意图；

图3是根据本申请实施例的一种可选的子系统运行状态检测示意图；

图4是根据本申请实施例的一种可选的软件系统状态的检测装置的示意图。

具体实施方式

为了使本技术领域的人员更好地理解本申请方案，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分的实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都应当属于本申请保护的范围。

需要说明的是，本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本申请的实施例能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

实施例1

根据本申请实施例，提供了一种软件系统状态的检测方法的实施例，需要说明的是，在附图的流程图示出的步骤可以在诸如一组计算机可执行指令的计算机系统中执行，并且，虽然在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤。

图1是根据本申请实施例的一种可选的软件系统状态的检测方法的流程图，如图1所示，该方法包括如下步骤：

步骤S101，获取目标软件系统中每个子系统的系统日志。

在步骤S101中，目标软件系统由多个子系统构成，多个子系统之间具有业务关联关系，每个子系统用于处理对应的业务数据。

在一种可选的实施例中，图2示出了根据本申请实施例的一种可选的目标软件系统的构成示意图，如图2所示，在图2中的目标软件系统由APP服务子系统、异常数据识别服务子系统、金融数据处理服务子系统、短信服务子系统以及记账服务子系统共5个子系统组成，其中，每个子系统都可以独立处理对应的业务数据，并且5个子系统之间具有业务关联关系。举例而言，APP服务子系统用于支持用户提交转账请求，异常数据识别服务子系统用于核查转账请求中是否存在敏感信息等异常数据，金融数据处理服务子系统用于根据转账请求执行银行账户之间的转账，短信服务子系统用于在转账成功或失败之后为用户发送短信，记账服务子系统用于记录该笔转账记录。

需要注意到的是，图2中的各个子系统只是一种示例，在金融行业中，上述的子系统包括但不限于业务系统、渠道系统以及平台系统，其中，业务系统包括但不限于用于开展记账业务的系统、用于开展贷款授信业务的系统、用于开展账户开户业务的系统、用于开展转账业务的系统。渠道系统包括但不限于用于提交监管信息的渠道系统。平台系统包括但不限于短信平台系统、用户管理平台系统。

步骤S102，根据系统日志确定每个子系统在运行过程中生成的目标运行数据。

在步骤S102中，每个子系统在运行过程中都会生成对应的系统日志，其中，系统日志中至少包括目标运行数据，目标运行数据用于描述每个子系统的运行状况，例如，子系统的启动时间、关闭时间、运行子系统的服务器的相关信息、以及子系统向数据库发送心跳信息时的时间等等。

步骤S103，检测每个子系统对应的目标运行数据是否满足对应子系统的预设条件，得到每个子系统对应的目标检测结果。

在步骤S103中，由于每个子系统所处理的业务数据不同，因此，每个子系统的使用要求也不完全相同，在此基础上，每个子系统在正常运行时的运行数据也会存在差别，因此，本申请基于每个子系统分别设置了每个子系统所对应的预设条件，例如，对于图2中的5个子系统，每个子系统都有自己对应的预设条件，一共有5个预设条件。

为了更好的说明上述内容，以下结合一个示例进行说明，举例而言，子系统A为一个用于提供短信服务的子系统、子系统B为一个用于向监管机构提交监管信息的渠道系统，其中，由于子系统A不涉及监管信息等敏感信息，因此，在子系统A对应的预设条件中，子系统A既可以在指定的主服务器上运行，也可以在备用服务器上运行。而对于子系统B而言，由于涉及监管信息，因此子系统B对应的预设条件规定必须在指定的主服务器上运行，如果子系统B在备用服务器上运行，则说明子系统B不符合对应的预设条件，子系统B出现了异常。另外，预设条件除了规定运行子系统的服务器的类型之外，还可以规定子系统在向数据库发送心跳信息时的最大延迟时长。

步骤S104，根据每个子系统对应的目标检测结果确定目标软件系统的系统状态。

在步骤S104中，系统状态表征目标软件系统是否正常运行。

可选的，仍以图2中的目标软件系统进行说明，如果图2中的5个子系统全部满足对应的预设条件，则说明每个子系统都处于正常运行状态，进而说明目标软件系统状态也处于正常状态。如果图2中的5个子系统中有至少一个子系统未满足对应的预设条件，则说明5个子系统中有至少一个子系统处于了异常运行状态，从而说明目标软件系统状态也处于了异常状态。

基于上述步骤S101至步骤S104的内容可知，在本申请中，采用通过基于每个子系统的系统日志自动确定每个子系统的目标运行数据的方式，首先获取目标软件系统中每个子系统的系统日志，然后根据系统日志确定每个子系统在运行过程中生成的目标运行数据，并检测每个子系统对应的目标运行数据是否满足对应子系统的预设条件，得到每个子系统对应的目标检测结果，最后根据每个子系统对应的目标检测结果确定目标软件系统的系统状态，其中，目标软件系统由多个子系统构成，多个子系统之间具有业务关联关系，每个子系统用于处理对应的业务数据，系统状态表征目标软件系统是否正常运行。

需要注意到的是，由于每个子系统用于处理各自对应的业务数据，因此每个子系统在正常运行时的运行数据也会存在差别，在此基础上，本申请通过基于每个子系统的系统日志自动确定每个子系统的目标运行数据，并结合每个子系统对应的预设条件，实现了自动检测每个子系统是否处于正常运行状态的目的，进行实现了自动确定目标软件系统的系统状态的效果。由于本申请的方案无需人工排查日志、分析日志以及核对每个子系统的运行数据是否符合正常运行时的要求，因此本申请的技术方案可以节约大量的人力物力，从而实现了提高对目标软件系统的系统状态的检测效率。

由此可见，本申请的技术方案达到了根据系统日志自动检测目标软件系统的系统状态的目的，从而避免了现有技术中使用人工方式排查软件系统的系统状态导致的人工成本高的问题，进而解决了现有技术中对由多个子系统组成的软件系统的系统状态检测效率低的问题的技术问题。

在一种可选的实施例中，一种软件系统状态的检测装置可作为本申请实施例中的软件系统状态的检测方法的执行主体，其中，软件系统状态的检测装置可以是一种程序脚本。

在一种可选的实施例中，检测装置获取每个子系统的启动日志和心跳日志，其中，启动日志中至少包括每个子系统在服务器上的启动信息，心跳日志中至少包括每个子系统每次向数据库发送心跳信息时的时间，系统日志包括启动日志和心跳日志。

具体的，一个子系统的启动日志中用于记录该日志的各种启动信息，例如，该子系统的系统名称、系统版本、启动组件、启动时间、启动成功标识、启动失败标识以及启动位置信息。其中，启动位置信息用于描述该子系统在那一台服务器上启动并运行。

另外，一个子系统的心跳日志用于记录该子系统每次向数据库发送的心跳信息的相关信息，例如，心跳信息的发送时间以及心跳信息的内容。其中，为了确定子系统的存活状态，通常需要在子系统中部署心跳程序，通过该心跳程序，子系统每间隔预设时长便会向数据库发送一次心跳信息，例如，每隔5秒向数据库中注册一下时间。

在一种可选的实施例中，检测装置还根据启动日志确定每个子系统的第一启动数据，其中，第一启动数据中至少包含在当前时刻运行每个子系统的运行服务器的服务器标识，服务器标识用于表征运行服务器是否为预设的备用服务器。同时，检测装置还根据心跳日志确定每个子系统的响应状态数据，其中，响应状态数据中至少包含每个子系统在向数据库发送相邻的两个心跳信息时的间隔时长，目标运行数据至少包括第一启动数据和响应状态数据。

具体的，在金融系统的数据中心中，一般存在两个数据中心：生产中心和灾备中心，两个中心部署的应用系统是相同的，正常情况下，每个子系统都存活在生产中心，即每个子系统都在生产中心中的主服务器上运行。当生产中心的一个主服务器出现异常后，该主服务器上所运行的子系统会转移到灾备中心的备用服务器上运行，即灾备中心中的备用服务器接管了该子系统的业务，此时该子系统的存活位置为灾备中心。

一个子系统对应的第一启动数据中至少包含有在当前时刻运行该子系统的运行服务器的服务器标识，并且该服务器标识用于表征该运行服务器是否为预设的备用服务器。举例而言，子系统A对应的第一启动数据中包含的服务器标识为“主服务器”，则说明子系统A此时在生产中心中的主服务器上运行，子系统B对应的第一启动数据中包含的服务器标识为“备用服务器”，则说明子系统B此时在灾备中心中的备用服务器上运行。

此外，检测装置还根据心跳日志确定每个子系统的响应状态数据，其中国，响应状态数据中至少包含每个子系统在向数据库发送相邻的两个心跳信息时的间隔时长。例如，已知每个子系统中部署的心跳程序在设计时规定的都是每间隔5秒钟向数据库发送一次心跳信息。为了验证每个子系统的存活状态以及消息处理的时效性，检测装置中会部署有一个监控线程，用于监控每个子系统是否按照每间隔5秒的频率向数据库发送心跳信息。如果在实际发送过程中，一个子系统在向数据库发送相邻的两个心跳信息时的间隔时长超过预设间隔时长(例如10秒)，则认为该子系统出现了异常，该子系统在消息处理过程中存在超时严重的问题。需要注意到是，由于每个子系统对于消息处理的时效性不同，因此，每个子系统对应的预设间隔时长也可以不同，例如，异常数据识别服务子系统对于消息处理的时效性要求较高，因此其对应的预设间隔时长可以设置为6秒，记账服务子系统对于消息处理的时效性要求较低，因此记账服务子系统对应的预设间隔时长可以设置为10秒。

在一种可选的实施例中，检测装置会检测第一启动数据中所包含的服务器标识是否为目标服务器标识，得到每个子系统对应的第一检测结果，其中，目标服务器标识为每个子系统在正常运行状态下所对应的运行服务器的服务器标识。同时，检测装置还会检测响应状态数据中所包含的间隔时长是否小于或等于预设间隔时长，得到每个子系统对应的第二检测结果，其中，预设间隔时长与每个子系统相对应。最后，检测装置根据第一检测结果和第二检测结果确定目标检测结果。

举例而言，子系统A为一个用于提供短信服务的子系统、子系统B为一个用于向监管机构提交监管信息的渠道系统，其中，由于子系统A不涉及监管信息等敏感信息，因此，在子系统A对应的预设条件中，子系统A既可以在生产中心的主服务器上运行，也可以在灾备中心的备用服务器上运行。而对于子系统B而言，由于涉及监管信息，因此子系统B对应的预设条件规定子系统B需要在生产中心的主服务器上运行，如果子系统B在灾备中心的备用服务器上运行，则子系统B不符合对应的预设条件，子系统B出现了异常。

在此基础上，如果子系统A对应的第一启动数据中包含的服务器标识为“主服务器”，则说明子系统A此时在生产中心中的主服务器上运行，子系统B对应的第一启动数据中包含的服务器标识为“备用服务器”，则说明子系统B此时在灾备中心中的备用服务器上运行。结合上述子系统A对应的预设条件和子系统B对应的预设条件，检测装置确定子系统A的第一启动数据中所包含的服务器标识为目标服务器标识，子系统B的第一启动数据中所包含的服务器标识不是目标服务器标识。

另外，由于子系统A用于提供短信服务，该服务对于消息处理的时效性要求较高，因此在子系统A对应的预设条件中规定子系统A对应的预设间隔时长为6秒。由于子系统B用于提供上传监管信息的服务，该服务对于消息处理的时效性要求较低，因此在子系统B对应的预设条件中规定子系统B对应的预设间隔时长为10秒。在此基础上，检测装置会检测子系统A在实际运行过程中，向数据库发送相邻的两个心跳信息时的间隔时长是否小于或等于6秒，得到子系统A对应第二检测结果。同时，检测装置还会检测子系统B在实际运行过程中，向数据库发送相邻的两个心跳信息时的间隔时长是否小于或等于10秒，得到子系统B对应第二检测结果。

在一种可选的实施例中，在第一启动数据中所包含的服务器标识为目标服务器标识，并且响应状态数据中所包含的间隔时长小于或等于预设间隔时长的情况下，检测装置确定目标运行数据满足对应子系统的预设条件；在第一启动数据中所包含的服务器标识与目标服务器标识不同，或响应状态数据中所包含的间隔时长大于预设间隔时长的情况下，检测装置确定目标运行数据不满足对应子系统的预设条件。

可选的，以上述的子系统A为例，子系统A需要同时满足两个预设子条件，才能确定子系统A满足子系统A对应的预设条件A。其中，第一个预设子条件为子系统A对应的第一启动数据中包含的服务器标识应该为预设条件A中规定的目标服务器标识，第二个预设子条件为子系统A在实际运行过程中，向数据库发送相邻的两个心跳信息时的间隔时长小于或等于预设条件A中规定的预设间隔时长6秒。

假设子系统A对应的第一启动数据中包含的服务器标识为“主服务器”，与子系统A的预设条件中规定的目标服务器标识相同，并且子系统A在实际运行过程中，向数据库发送相邻的两个心跳信息时的间隔时长为5秒，小于子系统A的预设条件中规定的预设间隔时长6秒，则检测装置确定子系统A满足子系统A对应的预设条件A。

如果子系统A不满足上述两个预设子条件中的任意一个预设子条件，则检测装置确定子系统A不满足子系统A对应的预设条件A。

对于判断子系统B是否满足子系统B对应的预设条件B，其判断过程与子系统A的判断过程相同，本申请在此不作过多赘述。

在一种可选的实施例中，在每个子系统对应的目标运行数据满足每个子系统对应的预设条件的情况下，检测装置确定目标软件系统处于正常状态；在多个子系统中存在至少一个异常子系统的情况下，检测装置确定目标软件系统处于异常状态，其中，异常子系统对应的目标运行数据未满足异常子系统所对应的预设条件。

可选的，图3示出了根据本申请实施例的一种可选的子系统运行状态检测示意图，如图3所示，目标软件系统由APP服务子系统、异常数据识别服务子系统、金融数据处理服务子系统、短信服务子系统以及记账服务子系统共5个子系统组成，其中APP服务子系统和异常数据识别服务子系统的存活位置位于灾备中心中的备用服务器上，另外三个子系统的存储位置位于生产中心中的主服务器上。

另外，在图3中，记账服务子系统的第一启动数据中的间隔时长为5.5秒，其余四个子系统的第一启动数据中的间隔时长均为5秒。

基于每个子系统的预设条件对每个子系统的运行状态进行判断，假设每个子系统的预设条件都规定对应的子系统的正常运行服务器应该为生产中心的主服务器，间隔时长不超过预设间隔时长(5秒)，则图3中的APP服务子系统(存活位置位于灾备中心中的备用服务器)、异常数据识别服务子系统(存活位置位于灾备中心中的备用服务器)以及记账服务子系统(间隔时长超过了预设间隔时长)都是异常子系统。检测装置可针对此三个异常子系统生成报警信息。

在一种可选的实施例中，检测装置还根据启动日志确定每个子系统的第二启动数据，其中，第二启动数据用于表征每个子系统是否成功启动。然后检测装置根据第二启动数据，检测多个子系统中是否存在至少一个第一异常子系统，其中，第一异常子系统为启动失败的子系统。最后，在多个子系统中存在至少一个第一异常子系统的情况下，检测装置确定目标软件系统处于异常状态。

可选的，只有一个子系统中的第二启动数据中包含有该子系统的系统名称、系统版本、启动组件、启动时间以及启动成功标识，检测装置才会确定该子系统启动成功，否则检测装置均会确定该子系统启动失败。容易理解的是，当目标软件系统中有任意一个子系统启动失败时，该目标软件系统均无法完成业务的执行过程，也就是说此时该目标软件系统已经处于了异常状态。

由上述内容可知，本申请通过基于每个子系统的系统日志自动确定每个子系统的目标运行数据，并结合每个子系统对应的预设条件，实现了自动检测每个子系统是否处于正常运行状态的目的，进行实现了自动确定目标软件系统的系统状态的效果。由于本申请的方案无需人工排查日志、分析日志以及核对每个子系统的运行数据是否符合正常运行时的要求，因此本申请的技术方案可以节约大量的人力物力，从而实现了提高对目标软件系统的系统状态的检测效率。

实施例2

根据本申请实施例，还提供了一种软件系统状态的检测装置的实施例，如图4所示，该装置包括：获取模块401，用于获取目标软件系统中每个子系统的系统日志，其中，目标软件系统由多个子系统构成，多个子系统之间具有业务关联关系，每个子系统用于处理对应的业务数据；第一确定模块402，用于根据系统日志确定每个子系统在运行过程中生成的目标运行数据；检测模块403，用于检测每个子系统对应的目标运行数据是否满足对应子系统的预设条件，得到每个子系统对应的目标检测结果；第二确定模块404，用于根据每个子系统对应的目标检测结果确定目标软件系统的系统状态，其中，系统状态表征目标软件系统是否正常运行。

可选的，获取模块还包括：第一获取单元，用于获取每个子系统的启动日志和心跳日志，其中，启动日志中至少包括每个子系统在服务器上的启动信息，心跳日志中至少包括每个子系统每次向数据库发送心跳信息时的时间，系统日志包括启动日志和心跳日志。

可选的，第一确定模块还包括：第一确定单元和第二确定单元。其中，第一确定单元，用于根据启动日志确定每个子系统的第一启动数据，其中，第一启动数据中至少包含在当前时刻运行每个子系统的运行服务器的服务器标识，服务器标识用于表征运行服务器是否为预设的备用服务器；第二确定单元，用于根据心跳日志确定每个子系统的响应状态数据，其中，响应状态数据中至少包含每个子系统在向数据库发送相邻的两个心跳信息时的间隔时长，目标运行数据至少包括第一启动数据和响应状态数据。

可选的，检测模块还包括：第一检测单元、第二检测单元以及第三确定单元。其中，第一检测单元，用于检测第一启动数据中所包含的服务器标识是否为目标服务器标识，得到每个子系统对应的第一检测结果，其中，目标服务器标识为每个子系统在正常运行状态下所对应的运行服务器的服务器标识；第二检测单元，用于检测响应状态数据中所包含的间隔时长是否小于或等于预设间隔时长，得到每个子系统对应的第二检测结果，其中，预设间隔时长与每个子系统相对应；第三确定单元，用于根据第一检测结果和第二检测结果确定目标检测结果。

可选的，第三确定单元还包括：第一确定子单元和第二确定子单元。其中，第一确定子单元，用于在第一启动数据中所包含的服务器标识为目标服务器标识，并且响应状态数据中所包含的间隔时长小于或等于预设间隔时长的情况下，确定目标运行数据满足对应子系统的预设条件；第二确定子单元，用于在第一启动数据中所包含的服务器标识与目标服务器标识不同，或响应状态数据中所包含的间隔时长大于预设间隔时长的情况下，确定目标运行数据不满足对应子系统的预设条件。

可选的，第二确定模块还包括：第四确定单元和第五确定单元。其中，第四确定单元，用于在每个子系统对应的目标运行数据满足每个子系统对应的预设条件的情况下，确定目标软件系统处于正常状态；第五确定单元，用于在多个子系统中存在至少一个异常子系统的情况下，确定目标软件系统处于异常状态，其中，异常子系统对应的目标运行数据未满足异常子系统所对应的预设条件。

可选的，软件系统状态的检测装置还包括：第三确定模块、第一检测模块以及第四确定模块。其中，第三确定模块，用于根据启动日志确定每个子系统的第二启动数据，其中，第二启动数据用于表征每个子系统是否成功启动；第一检测模块，用于根据第二启动数据，检测多个子系统中是否存在至少一个第一异常子系统，其中，第一异常子系统为启动失败的子系统；第四确定模块，用于在多个子系统中存在至少一个第一异常子系统的情况下，确定目标软件系统处于异常状态。

实施例3

根据本申请实施例，还提供了一种计算机可读存储介质，计算机可读存储介质中存储有计算机程序，其中，计算机程序被设置为运行时执行实施例1中的软件系统状态的检测方法。

实施例4

根据本申请实施例，还提供了一种电子设备，电子设备包括一个或多个处理器和存储器，存储器用于存储一个或多个程序，其中，当一个或多个程序被一个或多个处理器执行时，使得一个或多个处理器实现实施例1中的软件系统状态的检测方法。

上述本申请实施例序号仅仅为了描述，不代表实施例的优劣。

在本申请的上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其他实施例的相关描述。

在本申请所提供的几个实施例中，应该理解到，所揭露的技术内容，可通过其它的方式实现。其中，以上所描述的装置实施例仅仅是示意性的，例如所述单元的划分，可以为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，单元或模块的间接耦合或通信连接，可以是电性或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可为个人计算机、服务器或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、移动硬盘、磁碟或者光盘等各种可以存储程序代码的介质。

以上所述仅是本申请的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本申请原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本申请的保护范围。

Claims (10)

1.一种软件系统状态的检测方法，其特征在于，包括：

获取目标软件系统中每个子系统的系统日志，其中，所述目标软件系统由多个子系统构成，所述多个子系统之间具有业务关联关系，所述每个子系统用于处理对应的业务数据；

根据所述系统日志确定所述每个子系统在运行过程中生成的目标运行数据；

检测所述每个子系统对应的目标运行数据是否满足对应子系统的预设条件，得到所述每个子系统对应的目标检测结果；

根据所述每个子系统对应的目标检测结果确定所述目标软件系统的系统状态，其中，所述系统状态表征所述目标软件系统是否正常运行。

2.根据权利要求1所述的方法，其特征在于，获取目标软件系统中每个子系统的系统日志，包括：

获取所述每个子系统的启动日志和心跳日志，其中，所述启动日志中至少包括所述每个子系统在服务器上的启动信息，所述心跳日志中至少包括所述每个子系统每次向数据库发送心跳信息时的时间，所述系统日志包括所述启动日志和所述心跳日志。

3.根据权利要求2所述的方法，其特征在于，根据所述系统日志确定所述每个子系统在运行过程中生成的目标运行数据，包括：

根据所述启动日志确定所述每个子系统的第一启动数据，其中，所述第一启动数据中至少包含在当前时刻运行所述每个子系统的运行服务器的服务器标识，所述服务器标识用于表征所述运行服务器是否为预设的备用服务器；

根据所述心跳日志确定所述每个子系统的响应状态数据，其中，所述响应状态数据中至少包含所述每个子系统在向数据库发送相邻的两个心跳信息时的间隔时长，所述目标运行数据至少包括所述第一启动数据和所述响应状态数据。

4.根据权利要求3所述的方法，其特征在于，检测所述每个子系统对应的目标运行数据是否满足所述每个子系统对应的预设条件，得到所述每个子系统对应的目标检测结果，包括：

检测所述第一启动数据中所包含的服务器标识是否为目标服务器标识，得到所述每个子系统对应的第一检测结果，其中，所述目标服务器标识为所述每个子系统在正常运行状态下所对应的运行服务器的服务器标识；

检测所述响应状态数据中所包含的间隔时长是否小于或等于预设间隔时长，得到所述每个子系统对应的第二检测结果，其中，所述预设间隔时长与所述每个子系统相对应；

根据所述第一检测结果和所述第二检测结果确定所述目标检测结果。

5.根据权利要求4所述的方法，其特征在于，根据所述第一检测结果和所述第二检测结果确定所述目标检测结果，包括：

在所述第一启动数据中所包含的服务器标识为所述目标服务器标识，并且所述响应状态数据中所包含的间隔时长小于或等于所述预设间隔时长的情况下，确定所述目标运行数据满足对应子系统的预设条件；

在所述第一启动数据中所包含的服务器标识与所述目标服务器标识不同，或所述响应状态数据中所包含的间隔时长大于所述预设间隔时长的情况下，确定所述目标运行数据不满足对应子系统的预设条件。

6.根据权利要求1所述的方法，其特征在于，根据所述每个子系统对应的目标检测结果确定所述目标软件系统的系统状态，包括：

在所述每个子系统对应的目标运行数据满足所述每个子系统对应的预设条件的情况下，确定所述目标软件系统处于正常状态；

在所述多个子系统中存在至少一个异常子系统的情况下，确定所述目标软件系统处于异常状态，其中，所述异常子系统对应的目标运行数据未满足所述异常子系统所对应的预设条件。

7.根据权利要求2所述的方法，其特征在于，所述方法还包括：

根据所述启动日志确定所述每个子系统的第二启动数据，其中，所述第二启动数据用于表征所述每个子系统是否成功启动；

根据第二启动数据，检测所述多个子系统中是否存在至少一个第一异常子系统，其中，所述第一异常子系统为启动失败的子系统；

在所述多个子系统中存在至少一个第一异常子系统的情况下，确定所述目标软件系统处于异常状态。

8.一种软件系统状态的检测装置，其特征在于，包括：

获取模块，用于获取目标软件系统中每个子系统的系统日志，其中，所述目标软件系统由多个子系统构成，所述多个子系统之间具有业务关联关系，所述每个子系统用于处理对应的业务数据；

第一确定模块，用于根据所述系统日志确定所述每个子系统在运行过程中生成的目标运行数据；

检测模块，用于检测所述每个子系统对应的目标运行数据是否满足对应子系统的预设条件，得到所述每个子系统对应的目标检测结果；

第二确定模块，用于根据所述每个子系统对应的目标检测结果确定所述目标软件系统的系统状态，其中，所述系统状态表征所述目标软件系统是否正常运行。

9.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质中存储有计算机程序，其中，所述计算机程序被设置为运行时执行所述权利要求1至7任一项中所述的软件系统状态的检测方法。

10.一种电子设备，其特征在于，包括一个或多个处理器和存储器，所述存储器用于存储一个或多个程序，其中，当所述一个或多个程序被所述一个或多个处理器执行时，使得所述一个或多个处理器实现权利要求1至7中任意一项所述的软件系统状态的检测方法。

Images