本发明涉及互联网应用技术领域，特别是涉及一种信息生成方法、一种信息生成装置、一种服务器。
背景技术：
随着互联网应用的快速发展，服务器能够通过执行各种服务的业务逻辑来为客户端提供各种服务。具体的，在客户端需要向服务器请求服务时，向服务器发送针对其所请求服务的服务请求，服务器接收到客户端发送的服务请求后，执行客户端所请求服务的业务逻辑，从而为客户端提供客户端需要的服务。
然而，发明人在实现本发明的过程中发现，现有技术至少存在如下问题：
客户端在向服务器请求服务时，可能存在因网络连接失败、响应超时等原因导致请求服务失败的情况。为了了解请求服务失败的原因，服务器一般会调用开发人员事先编写的分析工具，对请求服务失败的情况进行分析。然而，由于服务的种类较多，且每一种服务均具有不同的特点，开发人员一般会针对每一服务编写一个分析工具，导致开发人员工作量大。
技术实现要素：
本发明实施例的目的在于提供了一种信息生成方法、装置及服务器，以避免因需要编写大量分析工具而造成开发人员的工作量较大。具体技术方案如下：
第一方面，本发明实施例提供了一种信息生成方法，应用于服务器，所述方法包括：
获取第一服务请求对应的第一日志，其中，所述第一服务请求为：请求服务失败的服务请求；
确定所述第一服务请求所请求的服务，作为目标服务；
确定所述目标服务的业务逻辑，作为第一业务逻辑；
在所述第一日志包含的日志数据中，查找与所述第一业务逻辑的业务配置项不匹配的日志数据，作为目标日志数据；
根据所述目标日志数据，生成所述第一服务请求请求服务失败的原因。
可选的，所述获取第一服务请求对应的第一日志，包括：
获取第一客户端生成的目标日志，作为第一日志，其中，所述第一客户端为：向所述服务器发送所述第一服务请求的客户端，所述目标日志为：所述第一客户端在请求所述目标服务过程中生成的日志；
和/或，
获取第一服务端在响应所述第一服务请求过程中生成的日志，作为第一日志，所述第一服务端为：响应所述第一服务请求的服务端。
可选的，所述方法还包括：
获取第二服务请求对应的第二日志，其中，所述第二服务请求为：请求服务成功的服务请求；
根据所述第一日志和所述第二日志，生成响应所述第一服务请求和第二服务请求的服务端的状态数据，其中，一个服务端的状态数据包括：该服务端的运行状态数据、该服务端所提供服务的服务状态数据。
可选的，一个服务端的运行状态数据包括以下数据中的至少一种：
预设时长内接收到服务请求的数量、所述预设时长内响应服务请求的成功概率、所述预设时长内响应服务请求的失败概率、响应服务请求的时间占比和每秒响应的服务请求的次数、依赖方的数量、依赖方的成功率和失败率。
可选的，在根据所述第一日志和所述第二日志，生成响应所述第一服务请求和第二服务请求的服务端的状态数据之后，所述方法还包括：
展示所生成的服务端的状态数据；
和/或，
向预设电子设备发送所生成的服务端的状态数据和/或提示信息，其中，所述提示信息为：根据所生成的服务端的状态数据生成的、用于对服务端的状态进行提示的信息。
可选的，按照以下方式生成所述提示信息：
从所生成的服务端的状态数据中，选择符合各个状态数据对应的预设异常条件的状态数据；
根据所选择的状态数据生成所述提示信息。
第二方面，本发明实施例还提供了一种信息生成装置，应用于服务器，所述装置包括：
第一日志获取模块，用于获取第一服务请求对应的第一日志，其中，所述第一服务请求为：请求服务失败的服务请求；
目标服务确定模块，用于确定所述第一服务请求所请求的服务，作为目标服务；
业务逻辑确定模块，用于确定所述目标服务的业务逻辑，作为第一业务逻辑；
目标日志数据查找模块，用于在所述第一日志包含的日志数据中，查找与所述第一业务逻辑的业务配置项不匹配的日志数据，作为目标日志数据；信息生成模块，用于根据所述目标日志数据，生成所述第一服务请求请求服务失败的原因。
可选的，所述第一日志获取模块，具体用于：
获取第一客户端生成的目标日志，作为第一日志，其中，所述第一客户端为：向所述服务器发送所述第一服务请求的客户端，所述目标日志为：所述第一客户端在请求所述目标服务过程中生成的日志；
和/或，
获取第一服务端在响应所述第一服务请求过程中生成的日志，作为第一日志，所述第一服务端为：响应所述第一服务请求的服务端。
可选的，所述装置还包括：
第二日志获取模块，用于获取第二服务请求对应的第二日志，其中，所述第二服务请求为：请求服务成功的服务请求；
状态数据生成模块，用于根据所述第一日志和所述第二日志，生成响应所述第一服务请求和第二服务请求的服务端的状态数据，其中，一个服务端的状态数据包括：该服务端的运行状态数据、该服务端所提供服务的服务状态数据。
可选的，一个服务端的运行状态数据包括以下数据中的至少一种：
预设时长内接收到服务请求的数量、所述预设时长内响应服务请求的成功概率、所述预设时长内响应服务请求的失败概率、响应服务请求的时间占比和每秒响应的服务请求的次数、依赖方的数量、依赖方的成功率和失败率。
可选的，所述装置还包括：
状态数据展示模块，用于在根据所述第一日志和所述第二日志，生成响应所述第一服务请求和第二服务请求的服务端的状态数据之后，展示所生成的服务端的状态数据；
和/或，
信息发送模块，用于在根据所述第一日志和所述第二日志，生成响应所述第一服务请求和第二服务请求的服务端的状态数据之后，向预设电子设备发送所生成的服务端的状态数据和/或提示信息，其中，所述提示信息为：根据所生成的服务端的状态数据生成的、用于对服务端的状态进行提示的信息。
可选的，按照以下方式生成所述提示信息：
从所生成的服务端的状态数据中，选择符合各个状态数据对应的预设异常条件的状态数据；
根据所选择的状态数据生成所述提示信息。
第三方面，本发明实施例还提供了一种电子设备，包括处理器、通信接口、存储器和通信总线，其中，处理器，通信接口，存储器通过通信总线完成相互间的通信；
存储器，用于存放计算机程序；
处理器，用于执行存储器上所存放的程序时，实现上述第一方面所述的任一信息生成方法。
在本发明实施的又一方面，还提供了一种计算机可读存储介质，所述计算机可读存储介质中存储有指令，当其在计算机上运行时，使得计算机执行上述第一方面所述的任一信息生成方法。
在本发明实施的又一方面，本发明实施例还提供了一种包含指令的计算机程序产品，当其在计算机上运行时，使得计算机执行执行上述第一方面所述的任一信息生成方法。
与现有技术相比，本发明实施例提供的技术方案，服务器在分析请求服务失败的原因时，首先获取第一服务请求对应的第一日志，其中，第一服务请求为：请求服务失败的服务请求；然后确定第一服务请求所请求的目标服务，并确定目标服务的业务逻辑，作为第一业务逻辑；最后在第一日志包含的日志数据中，查找与第一业务逻辑的业务配置项不匹配的日志数据，作为目标日志数据；并根据目标日志数据，生成第一服务请求请求服务失败的原因。
可见，通过本发明实施例提供的技术方案，服务器在分析请求服务失败的原因时，获得请求服务失败的服务请求所对应的日志，并确定请求服务失败的服务请求所请求的目标服务的业务逻辑，在所获得的日志里查找与目标服务的业务逻辑不匹配的目标日志数据，根据目标日志数据即可生成请求服务失败的原因。而不像现有技术那样，服务器在分析请求服务失败的原因时，服务器需要调用所请求的服务对应的分析工具来对请求服务失败的原因进行分析。因此，通过本发明实施例提供的技术方案，可以避免因需要编写大量分析工具而造成开发人员的工作量较大，即可以降低开发人员的工作量。
附图说明
为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍。
图1为本发明实施例所提供的一种信息获取方法的流程图；
图2为本发明实施例所提供的另一种信息获取方法的流程图；
图3为本发明实施例所提供的另一种信息获取方法的流程图；
图4为本发明实施例所提供的一种信息获取装置的结构示意图；
图5为本发明实施例所提供的一种信息获取装置的另一结构示意图；
图6为本发明实施例所提供的一种服务器的结构示意图。
具体实施方式
下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行描述。
为了解决现有技术问题，本发明实施例提供了一种信息生成方法、装置及服务器，以避免因需要编写大量分析工具而造成开发人员的工作量较大。
第一方面，将对本发明实施例所提供的一种信息生成方法进行介绍。
如图1所示，本发明实施例所提供的一种信息生成方法，包括如下步骤：
s110，获取第一服务请求对应的第一日志，其中，第一服务请求为：请求服务失败的服务请求；
s120，确定第一服务请求所请求的服务，作为目标服务；
s130，确定目标服务的业务逻辑，作为第一业务逻辑；
s140，在第一日志包含的日志数据中，查找与第一业务逻辑的业务配置项不匹配的日志数据，作为目标日志数据；
s150，根据目标日志数据，生成第一服务请求请求服务失败的原因。
可见，在本发明实施例提供的技术方案中，服务器在分析请求服务失败的原因时，获得请求服务失败的服务请求所对应的日志，并确定请求服务失败的服务请求所请求的目标服务的业务逻辑，在所获得的日志里查找与目标服务的业务逻辑不匹配的目标日志数据，根据目标日志数据即可生成请求服务失败的原因。而不像现有技术那样，服务器在分析请求服务失败的原因时，服务器需要调用所请求的服务对应的分析工具来对请求服务失败的原因进行分析。因此，通过本发明实施例提供的技术方案，可以避免因需要编写大量分析工具而造成开发人员的工作量较大，即可以降低开发人员的工作量。
下面将对如图1所示的实施例提供的信息生成方法进行详细描述。
s110，获取第一服务请求对应的第一日志，其中，第一服务请求为：请求服务失败的服务请求；
服务器在分析请求服务失败的原因时，首先获取请求服务失败的服务请求对应的日志，即获取第一服务请求对应的第一日志。
其中，上述第一日志可以是向服务器发送第一服务请求的客户端在请求服务的过程中生成的日志；还可以是响应第一服务请求的服务端在响应第一服务请求过程中生成的日志。
当第一日志是向服务器发送第一服务请求的客户端在请求服务的过程中生成的日志时，服务器获取第一日志有两种方式，第一种方式为：发送第一服务请求的客户端将第一日志发送至服务器；第二种方式是：服务器向发送第一服务请求的客户端发送用于获取第一日志的请求，发送第一服务请求的客户端接收到该请求后，将第一日志发送至服务器。
当第一日志是响应第一服务请求的服务端在响应第一服务请求过程中生成的日志时，服务器获取第一日志的方式可以为：在日志系统中查找服务端在响应第一服务请求的过程中产生的第一日志。
可以理解的是，响应第一服务请求的服务端可以是执行主体服务器本身，还可以是其他能够响应第一服务请求的服务器，这都是合理的。
s120，确定第一服务请求所请求的服务，作为目标服务；
通常情况下，不同的服务请求所请求的服务不同，而服务器为客户端提供不同的服务时所执行的业务逻辑不同，因此，为了在后续步骤中能够得知第一服务请求所请求服务的业务逻辑，服务器需要先确定第一服务请求所请求的服务，即需要确定目标服务。
s130，确定目标服务的业务逻辑，作为第一业务逻辑；
通常情况下，不同的服务所对应的业务逻辑是不同的，因此，在确定了目标服务之后，需要确定目标服务的业务逻辑，即确定第一业务逻辑。
s140，在第一日志包含的日志数据中，查找与第一业务逻辑的业务配置项不匹配的日志数据，作为目标日志数据；
第一业务逻辑的业务配置项是服务端为客户端成功提供服务时，执行第一业务逻辑所需要满足的参数。第一日志为请求服务失败的服务请求对应的日志，因此，第一日志包括的日志数据中存在与第一业务逻辑的业务配置项不匹配的日志数据。为了在后续步骤中能够分析出请求服务失败的原因，需要在第一日志包含的日志数据中，查找与第一业务逻辑的业务配置项不匹配的日志数据，作为目标日志数据。
举例而言，第一日志包含的响应时间为20秒，服务端为客户端成功提供服务时，执行第一业务逻辑最大响应时间为：10秒，即第一业务逻辑的业务配置项中的最大响应时间为为：10秒，则目标日志数据为：响应时间为20秒。s150，根据目标日志数据，生成第一服务请求请求服务失败的原因。
由于第一日志是向服务器发送第一服务请求的客户端在请求服务的过程中生成的日志；或者响应第一服务请求的服务端在响应第一服务请求过程中生成的日志。因此，在第一日志包含的日志数据中，查找到与第一业务逻辑的业务配置项不匹配的目标日志数据后，服务器即可以生成第一服务请求请求失败的原因，并生成第一服务请求请求失败的原因。
举例而言，第一日志包含的响应时间为20秒，第一业务逻辑的业务配置项中的最大响应时间为：10秒，目标日志数据为：响应时间为20秒，则根据目标日志数据，生成的第一服务请求请求服务失败的原因可以为：响应超时。
与现有技术相比，本发明实施例提供的技术方案，服务器在分析请求服务失败的原因时，首先获取第一服务请求对应的第一日志，其中，第一服务请求为：请求服务失败的服务请求；然后确定第一服务请求所请求的目标服务，并确定目标服务的业务逻辑，作为第一业务逻辑；最后在第一日志包含的日志数据中，查找与第一业务逻辑的业务配置项不匹配的日志数据，作为目标日志数据；并根据目标日志数据，生成第一服务请求请求服务失败的原因。
可见，通过本发明实施例提供的技术方案，服务器在分析请求服务失败的原因时，获得请求服务失败的服务请求所对应的日志，并确定请求服务失败的服务请求所请求的目标服务的业务逻辑，在所获得的日志里查找与目标服务的业务逻辑不匹配的目标日志数据，根据目标日志数据即可生成请求服务失败的原因。而不像现有技术那样，服务器在分析请求服务失败的原因时，服务器需要调用所请求的服务对应的分析工具来对请求服务失败的原因进行分析。因此，通过本发明实施例提供的技术方案，可以避免因需要编写大量分析工具而造成开发人员的工作量较大，即可以降低开发人员的工作量。
下面对本发明实施例所提供的另一种信息生成方法进行介绍。
如图2所示，本发明实施例所提供的一种信息生成方方法，可以包括如下步骤：
s210，获取第一服务请求对应的第一日志，其中，第一服务请求为：请求服务失败的服务请求；
s220，确定第一服务请求所请求的服务，作为目标服务；
s230，确定目标服务的业务逻辑，作为第一业务逻辑；
s240，在第一日志包含的日志数据中，查找与第一业务逻辑的业务配置项不匹配的日志数据，作为目标日志数据；
s250，根据目标日志数据，生成第一服务请求请求服务失败的原因；
s260，获取第二服务请求对应的第二日志，其中，第二服务请求为：请求服务成功的服务请求；
s270，根据第一日志和第二日志，生成响应第一服务请求和第二服务请求的服务端的状态数据，其中，一个服务端的状态数据包括：该服务端的运行状态数据、该服务端所提供服务的服务状态数据。
在该实施例中，步骤s210至s250与步骤s110至s150的内容相同，由于在如图1所述的实施例中，已经对步骤s110至s150进行了详细的描述，在该实施例中不再赘述。
下面将对步骤s260和s270进行详细的阐述。
s260，获取第二服务请求对应的第二日志，其中，第二服务请求为：请求服务成功的服务请求；
在步骤s210至s250中，服务器获取了请求服务失败的服务请求，并分析了请求服务失败的原因。为了进一步地分析响应服务请求的各个服务端的状态数据，还需要获取请求服务成功的服务请求对应的日志，即需要获取第二日志。
其中，上述第二日志可以是向服务器发送第二服务请求的客户端在请求服务的过程中生成的日志；还可以是响应第二服务请求的服务端在响应第二服务请求过程中生成的日志。
当第二日志是向服务器发送第二服务请求的客户端在请求服务的过程中生成的日志时，服务器获取第二日志有两种方式，第一种方式为：发送第二服务请求的客户端将第二日志发送至服务器；第二种方式是：服务器向发送第二服务请求的客户端发送用于获取第二日志的请求，发送第二服务请求的客户端接收到该请求后，将第二日志发送至服务器。
当第二日志是响应第二服务请求的服务端在响应第二服务请求过程中生成的日志时，服务器获取第二日志的方式可以为：在日志系统中查找服务端在响应第二服务请求的过程中产生的第二日志。
可以理解的是，响应第二服务请求的服务端可以是执行主体服务器本身，还可以是其他能够响应第二服务请求的服务器，这都是合理的。
s270，根据第一日志和第二日志，生成响应第一服务请求和第二服务请求的服务端的状态数据，其中，一个服务端的状态数据包括：该服务端的运行状态数据、该服务端所提供服务的服务状态数据。
服务器在获取到第一日志和第二日志之后，分析第一日志和第二日志，即可得到响应第一服务请求和第二服务请求的服务端的状态数据。
需要说明的是，上述服务端的状态数据，可以包括：服务端的运行状态数据以及服务端所提供服务的服务状态数据。
其中，服务端的运行状态数据可以包括以下数据：
1、服务器在预设时长内接收到服务请求的数量。
具体地，该服务请求的数量可以为服务端在预设时长内接收到的第一服务请求和第二服务请求的总数量，该预设时长可以是1秒、10秒、1分钟、1小时等等，本发明实施例对预设时长的大小不做具体限定。
2、服务器在预设时长内响应服务请求的成功概率。
具体地，由于第二服务请求是请求服务成功的服务请求，因此，预设时长内响应服务请求的成功概率可以通过如下方式来计算：服务端在预设时长内接收到的第二服务请求的数量除以服务端在预设时长内接收到服务请求的数量，即可计算出服务器在预设时长内响应服务请求的成功概率。可以理解的是，预设时长可大可小，本发明实施例对预设时长的大小并不做具体限定。
3、服务器在预设时长内响应服务请求的失败概率。
具体地，由于第一服务请求是请求服务失败的服务请求，因此，预设时长内响应服务请求的失败概率可以通过如下方式来计算：服务端在预设时长内接收到的第一服务请求的数量除以服务端在预设时长内接收到服务请求的数量，即可计算出服务器在预设时长内响应服务请求的成功概率。可以理解的是，预设时长可大可小，本发明实施例对预设时长的大小并不做具体限定。
可以理解的是，在计算出服务器在预设时长内响应服务请求的成功概率之后，利用1减去服务器在预设时长内响应服务请求的成功概率，即可得到服务器在预设时长内响应服务请求的失败概率。
4、服务端响应服务请求的时间占比；
服务器获取到第一服务请求对应的第一日志和第二服务请求对应的第二日志之后，即可得知服务端响应每个服务请求所消耗的时间，进而可以计算出服务端响应服务请求的时间占比。
举例而言，有10个服务请求，服务器响应这10个服务请求所消耗的时间依次为：1秒、2秒、3秒、3秒、4秒、4秒、5秒、7秒、8秒、9秒，服务器计算出服务端响应服务请求所消耗的时间占比可以是：小于3秒所占得比例为20％，3秒到5秒所占得比例为50％。6秒到10秒所占得比例为：30％。
5、服务端每秒响应的服务请求的次数。
具体的，服务器获取到第一服务请求对应的第一日志和第二服务请求对应的第二日志之后，可以从第一日志中获取到响应第一服务请求对应的时刻，以及可以从第二日志中获取到响应第二服务请求对应的时刻，从而服务器可以计算出响应第一服务请求和第二服务请求的服务端每秒响应的服务请求的次数。
6、依赖方的数量；
依赖方的数量即为依赖服务的总数量。举例而言，服务端在提供服务a，会调用服务b和服务c，那么服务b和服务c为依赖服务。
7、依赖方的成功率和失败率。
依赖方的成功率为：调用依赖服务成功的概率。举例而言，依赖服务的总数量为10，调用依赖服务成功的次数为8，那么，依赖方的成功率为80％；
相应地，依赖方的成功率为：调用依赖服务失败的概率。举例而言，依赖服务的总数量为10，调用依赖服务失败的次数为2，那么，依赖方的失败率为20％。
需要说明的是，服务端所提供服务的服务状态数据可以为服务器所提供的服务成功的数量、失败的数量、成功的概率、失败的概率等等。
与现有技术相比，服务器在分析请求服务失败的原因时，获得请求服务失败的服务请求所对应的日志，并确定请求服务失败的服务请求所请求的目标服务的业务逻辑，在所获得的日志里查找与目标服务的业务逻辑不匹配的目标日志数据，根据目标日志数据即可生成请求服务失败的原因；并且获取了请求服务成功的服务请求所对应的第二日志，根据第一日志和第二日志，生成响应第一服务请求和第二服务请求的服务端的状态数据。因此，通过本发明实施例提供的技术方案，可以避免因需要编写大量分析工具而造成开发人员的工作量较大，即可以降低开发人员的工作量，并且能够根据第一日志和第二日志自动生成响应服务请求的服务端的状态数据。
下面对本发明实施例所提供的另一种信息生成方法进行介绍。
如图3所示，本发明实施例所提供的一种信息生成方方法，可以包括如下步骤：
s310，获取第一服务请求对应的第一日志，其中，第一服务请求为：请求服务失败的服务请求；
s320，确定第一服务请求所请求的服务，作为目标服务；
s330，确定目标服务的业务逻辑，作为第一业务逻辑；
s340，在第一日志包含的日志数据中，查找与第一业务逻辑的业务配置项不匹配的日志数据，作为目标日志数据；
s350，根据目标日志数据，生成第一服务请求请求服务失败的原因；
s360，获取第二服务请求对应的第二日志，其中，第二服务请求为：请求服务成功的服务请求；
s370，根据第一日志和第二日志，生成响应第一服务请求和第二服务请求的服务端的状态数据，其中，一个服务端的状态数据包括：该服务端的运行状态数据、该服务端所提供服务的服务状态数据；
s380，展示所生成的服务端的状态数据；
和/或，
向预设电子设备发送所生成的服务端的状态数据和/或提示信息，其中，所述提示信息为：根据所生成的服务端的状态数据生成的、用于对服务端的状态进行提示的信息。
在该实施例中，步骤s310至s350与步骤s110至s150的内容相同，由于在如图1所述的实施例中，已经对步骤s110至s150进行了详细的描述，在该实施例中不再赘述；步骤s360至s370与步骤s260至s270的内容相同，由于在如图2所述的实施例中，已经对步骤s2600至s270进行了详细的描述，在该实施例中不再赘述。
下面将对步骤s380进行详细描述。
s380，展示所生成的服务端的状态数据；
和/或，
向预设电子设备发送所生成的服务端的状态数据和/或提示信息，其中，所述提示信息为：根据所生成的服务端的状态数据生成的、用于对服务端的状态进行提示的信息。
服务器在生成服务端的状态数据之后，为了使得用户能够了解响应第一服务请求和第二服务请求的各个服务端的状态，将所生成的响应第一服务请求和第二服务请求的各个服务端的状态数据展示出来。其中，为了使得用户能够快速地了解各个服务端的状态。可以利用echarts等图形化工具将所生成的服务端的状态数据制作成图表的形式，图表的形式可以是报表、折线图、柱状图、区域图、条状图、散点图、气泡图、k线图、饼图、圆环图等。
需要说明的是，服务器可以实时地将所生成的服务端的状态数据展示出来，从而方便用户随时了解各个服务端的状态；用户也可以根据自身需要预设时间间隔，按照预设时间间隔，将所生成的服务端的状态数据展示出来，例如预设时间间隔可以为一天、一周、一个月等。可以理解的是，为了节省内存，服务器会自动删除已经展示的状态数据，只保存没有展示的性能数据。
另外，为了使得用户能够及时地得知服务端的状态数据，服务器生成服务端的状态数据之后，可以将所生成的服务端的状态数据发送至预定电子设备，这样用户不必要每次都需要查看服务器才能了解服务端的状态数据；或者，服务器生成服务端的状态数据之后，可以向预设电子设备提示信息，该提示信息为：根据所生成的服务端的状态数据生成的、用于对服务端的状态进行提示的信息。举例而言，在服务端响应服务请求的失败率较高的时候，该提示信息可以为：报警信息。当然，服务器可以将所生成的服务端的状态数据和提示信息同时发送至预设电子设备，这都是合理的。
在一种实现方式中，可以按照以下方式生成所述提示信息：
从所生成的服务端的状态数据中，选择符合各个状态数据对应的预设异常条件的状态数据；根据所选择的状态数据生成提示信息。
举例而言，预设的预设时长内响应服务请求的失败概率为：2％，即预设时长内响应服务请求的失败概率对应的预设异常条件为：大于2％，那么，在预设时长内响应服务请求的失败概率为3％时，服务器生成的提示信息可以为：响应服务请求的失败概率异常、响应服务请求的失败概率较高等。
需要说明的是，向预设电子设备发送所生成的服务端的状态数据和/或提示信息的方式有多种。例如，可以是向预设电子设备发送短信、邮件、qq消息或微信消息等；提示信息的具体内容可以是只提示发生异常，也可以是发生异常的状态数据的详细信息。本发明对发送提示信息的方式、提示信息的形式及提示信息的具体内容不做具体限定。
与现有技术相比，服务器在生成响应第一服务请求和第二服务请求的服务端的状态数据之后，可以将所生成的状态数据展示出来，或者向预设电子设备发送所生成的服务端的状态数据和/或提示信息，从而用户能够及时地了解各个服务端的状态，并在服务端的状态数据发送异常时，用户能够及时发现并处理。
第二方面，本发明实施例还提供了一种信息生成装置，应用于服务器，如图4所示，所述装置包括：
第一日志获取模块410，用于获取第一服务请求对应的第一日志，其中，所述第一服务请求为：请求服务失败的服务请求；
目标服务确定模块420，用于确定所述第一服务请求所请求的服务，作为目标服务；
业务逻辑确定模块430，用于确定所述目标服务的业务逻辑，作为第一业务逻辑；
目标日志数据查找模块440，用于在所述第一日志包含的日志数据中，查找与所述第一业务逻辑的业务配置项不匹配的日志数据，作为目标日志数据；
信息生成模块450，用于根据所述目标日志数据，生成所述第一服务请求请求服务失败的原因。
可选的，所述第一日志获取模块，具体用于：
获取第一客户端生成的目标日志，作为第一日志，其中，所述第一客户端为：向所述服务器发送所述第一服务请求的客户端，所述目标日志为：所述第一客户端在请求所述目标服务过程中生成的日志；
和/或，
获取第一服务端在响应所述第一服务请求过程中生成的日志，作为第一日志，所述第一服务端为：响应所述第一服务请求的服务端。
与现有技术相比，本发明实施例提供的技术方案，服务器在分析请求服务失败的原因时，首先获取第一服务请求对应的第一日志，其中，第一服务请求为：请求服务失败的服务请求；然后确定第一服务请求所请求的目标服务，并确定目标服务的业务逻辑，作为第一业务逻辑；最后在第一日志包含的日志数据中，查找与第一业务逻辑的业务配置项不匹配的日志数据，作为目标日志数据；并根据目标日志数据，生成第一服务请求请求服务失败的原因。
可见，通过本发明实施例提供的技术方案，服务器在分析请求服务失败的原因时，获得请求服务失败的服务请求所对应的日志，并确定请求服务失败的服务请求所请求的目标服务的业务逻辑，在所获得的日志里查找与目标服务的业务逻辑不匹配的目标日志数据，根据目标日志数据即可生成请求服务失败的原因。而不像现有技术那样，服务器在分析请求服务失败的原因时，服务器需要调用所请求的服务对应的分析工具来对请求服务失败的原因进行分析。因此，通过本发明实施例提供的技术方案，可以避免因需要编写大量分析工具而造成开发人员的工作量较大，即可以降低开发人员的工作量。
本发明实施例还提供了一种信息生成装置，应用于服务器，如图5所示，所述装置包括：
第一日志获取模块510，用于获取第一服务请求对应的第一日志，其中，所述第一服务请求为：请求服务失败的服务请求；
目标服务确定模块520，用于确定所述第一服务请求所请求的服务，作为目标服务；
业务逻辑确定模块530，用于确定所述目标服务的业务逻辑，作为第一业务逻辑；
目标日志数据查找模块540，用于在所述第一日志包含的日志数据中，查找与所述第一业务逻辑的业务配置项不匹配的日志数据，作为目标日志数据；
信息生成模块550，用于根据所述目标日志数据，生成所述第一服务请求请求服务失败的原因；
第二日志获取模块560，用于获取第二服务请求对应的第二日志，其中，所述第二服务请求为：请求服务成功的服务请求；
状态数据生成模块570，用于根据所述第一日志和所述第二日志，生成响应所述第一服务请求和第二服务请求的服务端的状态数据，其中，一个服务端的状态数据包括：该服务端的运行状态数据、该服务端所提供服务的服务状态数据。
可选的，一个服务端的运行状态数据包括以下数据中的至少一种：
预设时长内接收到服务请求的数量、所述预设时长内响应服务请求的成功概率、所述预设时长内响应服务请求的失败概率、响应服务请求的时间占比和每秒响应的服务请求的次数、依赖方的数量、依赖方的成功率和失败率。
与现有技术相比，服务器在分析请求服务失败的原因时，获得请求服务失败的服务请求所对应的日志，并确定请求服务失败的服务请求所请求的目标服务的业务逻辑，在所获得的日志里查找与目标服务的业务逻辑不匹配的目标日志数据，根据目标日志数据即可生成请求服务失败的原因；并且获取了请求服务成功的服务请求所对应的第二日志，根据第一日志和第二日志，生成响应第一服务请求和第二服务请求的服务端的状态数据。因此，通过本发明实施例提供的技术方案，可以避免因需要编写大量分析工具而造成开发人员的工作量较大，即可以降低开发人员的工作量，并且能够根据第一日志和第二日志自动生成响应服务请求的服务端的状态数据。
可选的，在图5所示实施例的基础上，所述信息获取装置还可以包括：
状态数据展示模块，用于在根据所述第一日志和所述第二日志，生成响应所述第一服务请求和第二服务请求的服务端的状态数据之后，展示所生成的服务端的状态数据；
和/或，
信息发送模块，用于在根据所述第一日志和所述第二日志，生成响应所述第一服务请求和第二服务请求的服务端的状态数据之后，向预设电子设备发送所生成的服务端的状态数据和/或提示信息，其中，所述提示信息为：根据所生成的服务端的状态数据生成的、用于对服务端的状态进行提示的信息。
在一种实施方式中，可以按照以下方式生成所述提示信息：
从所生成的服务端的状态数据中，选择符合各个状态数据对应的预设异常条件的状态数据；
根据所选择的状态数据生成所述提示信息。
与现有技术相比，服务器在生成响应第一服务请求和第二服务请求的服务端的状态数据之后，可以将所生成的状态数据展示出来，或者向预设电子设备发送所生成的服务端的状态数据和/或提示信息，从而用户能够及时地了解各个服务端的状态，并在服务端的状态数据发送异常时，用户能够及时发现并处理。
本发明实施例还提供了一种服务器，如图6所示，包括处理器601、通信接口602、存储器603和通信总线604，其中，处理器601，通信接口602，存储器603通过通信总线604完成相互间的通信，
存储器603，用于存放计算机程序；
处理器601，用于执行存储器603上所存放的程序时，实现第一方面方法实施例所述的任一信息生成方法。
上述电子设备提到的通信总线可以是外设部件互连标准(peripheralpomponentinterconnect，简称pci)总线或扩展工业标准结构(extendedindustrystandardarchitecture，简称eisa)总线等。该通信总线可以分为地址总线、数据总线、控制总线等。为便于表示，图中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。
通信接口用于上述电子设备与其他设备之间的通信。
存储器可以包括随机存取存储器(randomaccessmemory，简称ram)，也可以包括非易失性存储器(non-volatilememory)，例如至少一个磁盘存储器。可选的，存储器还可以是至少一个位于远离前述处理器的存储装置。
上述的处理器可以是通用处理器，包括中央处理器(centralprocessingunit，简称cpu)、网络处理器(networkprocessor，简称np)等；还可以是数字信号处理器(digitalsignalprocessing，简称dsp)、专用集成电路(applicationspecificintegratedcircuit，简称asic)、现场可编程门阵列(field－programmablegatearray，简称fpga)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。
与现有技术相比，本发明实施例提供的技术方案，服务器在分析请求服务失败的原因时，首先获取第一服务请求对应的第一日志，其中，第一服务请求为：请求服务失败的服务请求；然后确定第一服务请求所请求的目标服务，并确定目标服务的业务逻辑，作为第一业务逻辑；最后在第一日志包含的日志数据中，查找与第一业务逻辑的业务配置项不匹配的日志数据，作为目标日志数据；并根据目标日志数据，生成第一服务请求请求服务失败的原因。
可见，通过本发明实施例提供的技术方案，服务器在分析请求服务失败的原因时，获得请求服务失败的服务请求所对应的日志，并确定请求服务失败的服务请求所请求的目标服务的业务逻辑，在所获得的日志里查找与目标服务的业务逻辑不匹配的目标日志数据，根据目标日志数据即可生成请求服务失败的原因。而不像现有技术那样，服务器在分析请求服务失败的原因时，服务器需要调用所请求的服务对应的分析工具来对请求服务失败的原因进行分析。因此，通过本发明实施例提供的技术方案，可以避免因需要编写大量分析工具而造成开发人员的工作量较大，即可以降低开发人员的工作量。
在本发明提供的又一实施例中，还提供了一种计算机可读存储介质，该计算机可读存储介质中存储有指令，当其在计算机上运行时，使得计算机执行上述实施例中任一所述的信息生成方法。
与现有技术相比，本发明实施例提供的技术方案，服务器在分析请求服务失败的原因时，首先获取第一服务请求对应的第一日志，其中，第一服务请求为：请求服务失败的服务请求；然后确定第一服务请求所请求的目标服务，并确定目标服务的业务逻辑，作为第一业务逻辑；最后在第一日志包含的日志数据中，查找与第一业务逻辑的业务配置项不匹配的日志数据，作为目标日志数据；并根据目标日志数据，生成第一服务请求请求服务失败的原因。
可见，通过本发明实施例提供的技术方案，服务器在分析请求服务失败的原因时，获得请求服务失败的服务请求所对应的日志，并确定请求服务失败的服务请求所请求的目标服务的业务逻辑，在所获得的日志里查找与目标服务的业务逻辑不匹配的目标日志数据，根据目标日志数据即可生成请求服务失败的原因。而不像现有技术那样，服务器在分析请求服务失败的原因时，服务器需要调用所请求的服务对应的分析工具来对请求服务失败的原因进行分析。因此，通过本发明实施例提供的技术方案，可以避免因需要编写大量分析工具而造成开发人员的工作量较大，即可以降低开发人员的工作量。
在本发明提供的又一实施例中，还提供了一种包含指令的计算机程序产品，当其在计算机上运行时，使得计算机执行上述实施例中任一所述的信息生成方法。
与现有技术相比，本发明实施例提供的技术方案，服务器在分析请求服务失败的原因时，首先获取第一服务请求对应的第一日志，其中，第一服务请求为：请求服务失败的服务请求；然后确定第一服务请求所请求的目标服务，并确定目标服务的业务逻辑，作为第一业务逻辑；最后在第一日志包含的日志数据中，查找与第一业务逻辑的业务配置项不匹配的日志数据，作为目标日志数据；并根据目标日志数据，生成第一服务请求请求服务失败的原因。
可见，通过本发明实施例提供的技术方案，服务器在分析请求服务失败的原因时，获得请求服务失败的服务请求所对应的日志，并确定请求服务失败的服务请求所请求的目标服务的业务逻辑，在所获得的日志里查找与目标服务的业务逻辑不匹配的目标日志数据，根据目标日志数据即可生成请求服务失败的原因。而不像现有技术那样，服务器在分析请求服务失败的原因时，服务器需要调用所请求的服务对应的分析工具来对请求服务失败的原因进行分析。因此，通过本发明实施例提供的技术方案，可以避免因需要编写大量分析工具而造成开发人员的工作量较大，即可以降低开发人员的工作量。
在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。所述计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行所述计算机程序指令时，全部或部分地产生按照本发明实施例所述的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输，例如，所述计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线(dsl))或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。所述计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。所述可用介质可以是磁性介质，(例如，软盘、硬盘、磁带)、光介质(例如，dvd)、或者半导体介质(例如固态硬盘solidstatedisk(ssd))等。
需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。
本说明书中的各个实施例均采用相关的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于装置、服务器等实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。
以上所述仅为本发明的较佳实施例而已，并非用于限定本发明的保护范围。凡在本发明的精神和原则之内所作的任何修改、等同替换、改进等，均包含在本发明的保护范围内。