CN105808414A - 一种日志处理方法及日志处理电子设备 - Google Patents

Abstract

本申请公开一种日志处理方法和日志处理电子设备，所述方法包括在符合预设类型的日志处理条件时，从统一存储的各个服务的日志信息中获取至少一个目标服务对应的目标日志信息；对所述目标日志信息进行所述预设类型的日志处理。可见，本申请通过对多服务日志信息进行统一存储，来克服现有技术因对各个服务的日志信息分块独立存储而导致的问题，当某一API在不同的微服务间穿透访问时，可从统一存储的多服务日志信息中统一获取穿透访问所涉及的不同服务的日志信息，从而后续可进行日志信息的统一分析与快速、准确的出错定位，有效提高了查错效率，为微服务环境下的日志处理提供了便利。

Description

一种日志处理方法及日志处理电子设备

技术领域

本发明属于日志处理技术领域，尤其涉及一种日志处理方法及日志处理电子设备。

背景技术

目前，在微服务环境下，各个微服务采用独立管理的方式各自存储并管理自己的日志信息，即各个微服务的日志信息分块存储且独立管理。

此种方式会为微服务环境下的日志信息处理带来诸多不便，例如，当某一API(ApplicationProgrammingInterface，应用程序编程接口)在不同的微服务间穿透访问时，不能很好地对该API的访问行为进行跟踪，在访问出错时不能快速准确地一次性定位出错误信息(例如定位出发生错误的微服务及错误原因等)，只能针对各个服务，从其独立存储的日志信息中逐个调出相应日志，并逐个对调出的每个服务的日志信息进行错误分析，从而导致查错效率较低。

发明内容

有鉴于此，本发明的目的在于提供一种日志处理方法及日志处理电子设备，旨在通过对多服务日志信息进行统一存储、统一管理，实现为微服务环境下的日志信息处理提供便利。

为此，本发明公开如下技术方案：

一种日志处理方法，包括：

在符合预设类型的日志处理条件时，从统一存储的各个服务的日志信息中获取至少一个目标服务对应的目标日志信息；

对所述目标日志信息进行所述预设类型的日志处理。

上述方法，优选的，所述统一存储的各个服务的日志信息包括：针对服务间的穿透访问，统一记录的所述穿透访问所涉及的各个服务的日志信息，其中，所述穿透访问所涉及的各个服务的日志信息包括所述穿透访问的访问身份标识号，不同的穿透访问对应的访问身份标识号不同。

上述方法，优选的，当所述目标服务为目标穿透访问所涉及的多个服务时，所述从统一存储的各个服务的日志信息中获取至少一个目标服务对应的目标日志信息包括：

依据所述目标穿透访问的访问身份标识号，从统一存储的日志信息中获取所述目标穿透访问所涉及的各个服务的日志信息。

上述方法，优选的，所述预设类型的日志处理条件为：

到达针对至少一个目标服务的预设类型的日志分析时间；或，

接收到针对至少一个目标服务的预设类型的日志分析请求；或，

到达预设的针对至少一个目标服务的日志推送时间；或，

接收到针对至少一个目标服务的日志查看请求。

上述方法，优选的，当所述预设类型的日志处理条件为：到达针对至少一个目标服务的预设类型的日志分析时间或接收到针对至少一个目标服务的预设类型的日志分析请求时，所述对所述目标日志信息进行所述预设类型的日志处理包括：

对所述至少一个目标服务对应的目标日志信息进行所述预设类型的日志分析，得到日志分析结果；

推送所述日志分析结果。

上述方法，优选的，所述预设类型的日志分析为：分析应用程序编程接口访问服务错误时对应的错误信息、分析目标服务所在的服务系统的性能、健康程度或分析用户行为中的任意一种。

上述方法，优选的，当所述预设类型的日志处理条件为：到达预设的针对至少一个目标服务的日志推送时间或接收到针对至少一个目标服务的日志查看请求时，所述对所述目标日志信息进行所述预设类型的日志处理包括：

推送所述至少一个目标服务对应的目标日志信息。

一种日志处理电子设备，包括：

第一处理器，用于在符合预设类型的日志处理条件时，从统一存储的各个服务的日志信息中获取至少一个目标服务对应的目标日志信息；

第二处理器，用于对所述目标日志信息进行所述预设类型的日志处理。

上述电子设备，优选的，所述统一存储的各个服务的日志信息包括：针对服务间的穿透访问，统一记录的所述穿透访问所涉及的各个服务的日志信息，其中，所述穿透访问所涉及的各个服务的日志信息包括所述穿透访问的访问身份标识号，不同的穿透访问对应的访问身份标识号不同；则当所述目标服务为目标穿透访问所涉及的多个服务时，所述第一处理器具体用于：

依据所述目标穿透访问的访问身份标识号，从统一存储的日志信息中获取所述目标穿透访问所涉及的各个服务的日志信息。

上述电子设备，优选的，当所述预设类型的日志处理条件为：到达针对至少一个目标服务的预设类型的日志分析时间或接收到针对至少一个目标服务的预设类型的日志分析请求时，所述第二处理器具体用于：

对所述至少一个目标服务对应的目标日志信息进行所述预设类型的日志分析，得到日志分析结果；推送所述日志分析结果。

上述电子设备，优选的，当所述预设类型的日志处理条件为：到达预设的针对至少一个目标服务的日志推送时间或接收到针对至少一个目标服务的日志查看请求时，所述第二处理器具体用于：

推送所述至少一个目标服务对应的目标日志信息。

由以上方案可知，本申请公开的日志处理方法，包括在符合预设类型的日志处理条件时，从统一存储的各个服务的日志信息中获取至少一个目标服务对应的目标日志信息；对所述目标日志信息进行所述预设类型的日志处理。可见，本申请通过对多服务日志信息进行统一存储，来克服现有技术因对各个服务的日志信息分块独立存储而导致的问题，当某一API在不同的微服务间穿透访问时，可从统一存储的多服务日志信息中统一获取穿透访问所涉及的不同服务的日志信息，从而后续可进行日志信息的统一分析与快速、准确的出错定位，有效提高了查错效率，为微服务环境下的日志处理提供了便利。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据提供的附图获得其他的附图。

图1是本申请提供的一种日志处理方法实施例一的流程图；

图2是本申请实施例一提供的日志信息统一存储示意图；

图3是本申请实施例二提供的API穿透访问时的日志记录示意图；

图4是本申请提供的一种日志处理方法实施例二的流程图；

图5是本申请提供的一种日志处理方法实施例三的流程图；

图6是本申请提供的一种日志处理方法实施例四的流程图；

图7是本申请实施例四提供的日志订阅推送交互示意图；

图8是本申请提供的一种日志处理电子设备实施例五的结构示意图。

具体实施方式

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

实施例一

参考图1，图1为本申请提供的一种日志处理方法实施例一的流程图，所述方法适用于但不限于微服务环境下的日志处理，如图1所示，所述日志处理方法可以包括以下步骤：

S101：在符合预设类型的日志处理条件时，从统一存储的各个服务的日志信息中获取至少一个目标服务对应的目标日志信息。

其中，所述预设类型的日志处理条件可以为：

到达针对至少一个目标服务的预设类型的日志分析时间；或，

接收到针对至少一个目标服务的预设类型的日志分析请求；或，

到达预设的针对至少一个目标服务的日志推送时间；或，

接收到针对至少一个目标服务的日志查看请求。

所述预设类型的日志分析可以是分析某一API访问服务出错时对应的错误信息、分析目标服务所在的服务系统的性能、健康程度或分析用户行为、用户喜好、用户购买力等等。

区别于现有技术对不同服务的日志信息进行独立存储、独立管理的特点，本申请对不同服务的日志信息进行统一、集中存储和管理，具体地，本实施例采用Cassandra数据库对不同服务的日志信息进行统一记录，并以时间线方式(即按照日志发生时间的先后次序)将不同服务的日志信息写入数据库进行统一、集中存储和管理，从而可方便后续从统一存储的Cassandra数据库中调取出一个或多个所需服务的日志信息、并对调取的日志信息进行所需的分析、处理等，克服了现有技术从不同服务独立存储的日志信息中，逐个调取各服务日志信息时具有的操作繁琐、效率低等问题。

具体地，参考图2示出的日志信息存储示意图，图2显示了本申请中服务/微服务与日志存储间的关系，本申请具体采用一日志服务将传统的日志记录从各个服务，如Web服务中剥离开，并对各个服务的日志信息进行统一记录和存储，日志服务的底层由Cassandra数据库支撑，从而可方便日志信息的快速存储和检索查询，为后续的日志分析提供了便利，同时进一步方便了日志信息的归档、备份。

其中，日志的存储规则具体可参考Apache日志格式，该格式提供了统一的日志存储接口，可以方便地将各种服务的日志信息进行统一存储和管理。

基于此，本步骤中，当符合所述预设类型的日志处理条件时，例如当到达预先设定的某一服务系统的健康程度分析时间时，具体可从所述Cassandra数据库中统一调取所述服务系统所涉及的各个微服务的日志信息。

S102：对所述目标日志信息进行所述预设类型的日志处理。

在从统一存储的多服务日志信息如从所述Cassandra数据库中，获取所需的至少一个目标服务的日志信息后，可基于实际的处理需求，对获取的一个或多个服务的日志信息进行相应处理，如综合分析各个服务的日志信息，进行服务查错，或对各个服务的日志信息进行推送等等。

由以上方案可知，本申请公开的日志处理方法，包括在符合预设类型的日志处理条件时，从统一存储的各个服务的日志信息中获取至少一个目标服务对应的目标日志信息；对所述目标日志信息进行所述预设类型的日志处理。可见，本申请通过对多服务日志信息进行统一存储，来克服现有技术因对各个服务的日志信息分块独立存储而导致的问题，当某一API在不同的微服务间穿透访问时，可从统一存储的多服务日志信息中统一获取穿透访问所涉及的不同服务的日志信息，从而后续可进行日志信息的统一分析与快速、准确的出错定位，有效提高了查错效率，为微服务环境下的日志处理提供了便利。

实施例二

本实施例提供穿透访问场景下，穿透访问所涉及的多服务日志信息的记录存储及访问方案。

具体地，参考图3示出的多服务间穿透访问时的日志记录示意图，当一次API调用在多个服务间进行穿透访问时，以时间线方式对穿透访问各个服务时的日志信息进行记录。其中，具体在API穿透访问的请求信息中添加本次穿透访问的访问ID(身份标识号，Identity)，如具体可在访问请求信息的头部添加所述访问ID；在此基础上，在API穿透访问多服务的过程中，将所述访问ID添加至API穿透访问各个服务时所产生的日志信息中，从而，针对API的一次穿透访问，最终写入数据库的日志信息为：利用本次穿透访问的访问ID统一标识的多服务日志信息，从而数据库可基于所述穿透访问的访问ID统一记录并存储穿透访问所涉及的多个服务及其日志信息。

其中，不同的穿透访问被分配有唯一不同的访问ID。

基于此，参考图4，图4为本申请提供的一种日志处理方法实施例二的流程图，本实施例中，当所述目标服务为目标穿透访问所涉及的多个服务时，所述步骤S101具体可通过以下步骤实现：

S401：依据所述目标穿透访问的访问ID，从统一存储的日志信息中获取所述目标穿透访问所涉及的各个服务的日志信息。

具体地，基于本实施例的穿透访问日志记录和存储方案，当需对某次穿透访问的日志信息进行相应处理时，例如当API的某次穿透访问出错，需对该穿透访问进行出错分析时，则可依据该穿透访问的访问ID，从数据库中统一调取出所述穿透访问所涉及的所有服务的日志信息，进而可依据统一调取的多服务日志信息快速分析并定位出具体错误信息，如定位出出错的服务以及错误原因、错误类型等。

应用本实施例的方案，可实现对API穿透访问时的访问行为跟踪提供便利，为访问出错后快速进行出错定位及出错原因分析提供便利。

实施例三

参考图5，图5为本申请提供的一种日志处理方法实施例三的流程图，本实施例中，当所述预设类型的日志处理条件为：到达针对至少一个目标服务的预设类型的日志分析时间或接收到针对至少一个目标服务的预设类型的日志分析请求时，所述步骤S102可以通过以下步骤实现：

S501：对所述至少一个目标服务对应的目标日志信息进行所述预设类型的日志分析，得到日志分析结果；

S502：推送所述日志分析结果。

在从多服务日志信息的统一存储数据中获取至少一个目标服务的日志信息后，可基于实际的日志处理需求，对获取的至少一个目标服务的日志信息进行相应处理。

具体地，可基于从数据库中调取的日志信息，分析微服务环境下的服务系统(可包括多个微服务)性能参数，如分析系统性能瓶颈、系统健康状况、或分析各个服务的访问量、访问压力信息等。

在以用户为主导的微服务环境下，用户日志变得越来越重要，用户行为、用户喜好，用户购买力等都可通过微服务日志分析得到相关结果数据，因此本实施例还可利用从数据库中调出的一个或多个微服务的日志信息，来分析用户行为、用户喜好，用户购买力等等。

在对调出的日志信息进行分析，得出相关结果数据后，可将所述结果数据推送至相应的目标接收者，例如，将分析出的系统性能瓶颈数据、系统健康状况数据推送至相关管理人员，将分析得出的用户行为，用户喜好，用户购买力数据推送至具有相应权限的某些用户等。

实施例四

参考图6，图6为本申请提供的一种日志处理方法实施例四的流程图，本实施例中，当所述预设类型的日志处理条件为：到达预设的针对至少一个目标服务的日志推送时间或接收到针对至少一个目标服务的日志查看请求时，所述步骤S102可以通过以下步骤实现：

S601：推送所述至少一个目标服务对应的目标日志信息。

目前，基于微服务相关信息的订阅推送日渐兴起，在云平台环境下，基于微服务的用户资源实时管理信息，资源的健康状态信息等都需要及时反馈给用户，从而，为了解决和用户间的交互，供用户实时查看和掌握其服务系统的相关信息，本实施例具体提供一种面向用户的服务日志订阅推送方案。

参考图7示出的日志订阅推送交互示意图，当到达用户订阅的服务系统(可包括多个服务)的日志推送时间，或接收到用户发出的系统日志推送请求后，可从统一存储的日志数据库中调取出相关的日志信息，并推送给用户，供用户查看，从而满足了用户的日志查看请求。

实施例五

参考图8，图8为本申请提供的一种日志处理电子设备实施例五的结构示意图，所述电子设备适用于但不限于微服务环境下的日志处理，如图8所示，所述电子设备可以包括：

第一处理器100，用于在符合预设类型的日志处理条件时，从统一存储的各个服务的日志信息中获取至少一个目标服务对应的目标日志信息。

其中，所述预设类型的日志处理条件可以为：

到达针对至少一个目标服务的预设类型的日志分析时间；或，

接收到针对至少一个目标服务的预设类型的日志分析请求；或，

到达预设的针对至少一个目标服务的日志推送时间；或，

接收到针对至少一个目标服务的日志查看请求。

所述预设类型的日志分析可以是分析某一API访问服务出错时对应的错误信息、分析目标服务所在的服务系统的性能、健康程度或分析用户行为、用户喜好、用户购买力等等。

区别于现有技术对不同服务的日志信息进行独立存储、独立管理的特点，本申请对不同服务的日志信息进行统一、集中存储和管理，具体地，本实施例采用Cassandra数据库对不同服务的日志信息进行统一记录，并以时间线方式(即按照日志发生时间的先后次序)将不同服务的日志信息写入数据库进行统一、集中存储和管理，从而可方便后续从统一存储的Cassandra数据库中统一调取出一个或多个所需服务的日志信息、并对调取的多个服务的日志信息进行所需的分析、处理等，克服了现有技术从不同服务独立存储的日志信息中，逐个调取各服务日志信息时具有的操作繁琐、效率低等问题。

具体地，参考图2示出的日志信息存储示意图，图2显示了本申请中服务/微服务与日志存储间的关系，本申请具体采用一日志服务将传统的日志记录从各个服务，如Web服务中剥离开，并对各个服务的日志信息进行统一记录和存储，日志服务的底层由Cassandra数据库支撑，从而可方便日志信息的快速存储和检索查询，为后续的日志分析提供了便利，同时进一步方便了日志信息的归档、备份。

其中，日志的存储规则具体可参考Apache日志格式，该格式提供了统一的日志存储接口，可以方便地将各种服务的日志信息进行统一存储和管理。

基于此，当符合所述预设类型的日志处理条件时，例如当到达预先设定的某一服务系统的健康程度分析时间时，具体可从所述Cassandra数据库中统一调取所述服务系统所涉及的各个微服务的日志信息。

第二处理器200，用于对所述目标日志信息进行所述预设类型的日志处理。

在从统一存储的多服务日志信息如从所述Cassandra数据库中，获取所需的至少一个目标服务的日志信息后，可基于实际的处理需求，对获取的一个或多个服务的日志信息进行相应处理，如综合分析各个服务的日志信息，进行服务查错，或对各个服务的日志信息进行推送等等。

由以上方案可知，本申请公开的日志处理电子设备，通过对多服务日志信息进行统一存储，来克服现有技术因对各个服务的日志信息分块独立存储而导致的问题，当某一API在不同的微服务间穿透访问时，可从统一存储的多服务日志信息中统一获取穿透访问所涉及的不同服务的日志信息，从而后续可进行日志信息的统一分析与快速、准确的出错定位，有效提高了查错效率，为微服务环境下的日志处理提供了便利。

实施例六

本实施例中，当所述目标服务为目标穿透访问所涉及的多个服务时，所述第一处理器100具体用于：依据所述目标穿透访问的访问ID，从统一存储的日志信息中获取所述目标穿透访问所涉及的各个服务的日志信息。

本实施例提供穿透访问场景下，穿透访问所涉及的多服务日志信息的记录存储及访问方案。

具体地，参考图3示出的多服务间穿透访问时的日志记录示意图，当一次API调用在多个服务间进行穿透访问时，以时间线方式对穿透访问各个服务时的日志信息进行记录。其中，具体在API穿透访问的请求信息中添加本次穿透访问的访问ID(身份标识号，Identity)，如具体可在访问请求信息的头部添加所述访问ID；在此基础上，在API穿透访问多服务的过程中，将所述访问ID添加至API穿透访问各个服务时所产生的日志信息中，从而，针对API的一次穿透访问，最终写入数据库的日志信息为：利用本次穿透访问的访问ID统一标识的多服务日志信息，从而数据库可基于所述穿透访问的访问ID统一记录并存储穿透访问所涉及的多个服务及其日志信息。

其中，不同的穿透访问被分配有唯一不同的访问ID。

基于此，当需对某次穿透访问的日志信息进行相应处理时，例如当API的某次穿透访问调用出错，需对该穿透访问进行出错分析时，则可依据该穿透访问的访问ID，从数据库中统一调取出所述穿透访问所涉及的所有服务的日志信息，进而可依据统一调取的多服务日志信息快速分析并定位出具体错误信息，如定位出出错的服务以及错误原因、错误类型等。

应用本实施例的方案，可实现对API穿透访问时的访问行为跟踪提供便利，为访问出错后快速进行出错定位及出错原因分析提供便利。

实施例七

本实施例中，当所述预设类型的日志处理条件为：到达针对至少一个目标服务的预设类型的日志分析时间或接收到针对至少一个目标服务的预设类型的日志分析请求时，所述第二处理器200具体用于：对所述至少一个目标服务对应的目标日志信息进行所述预设类型的日志分析，得到日志分析结果；推送所述日志分析结果。

在从多服务日志信息的统一存储数据中获取至少一个目标服务的日志信息后，可基于实际的日志处理需求，对获取的至少一个目标服务的日志信息进行相应处理。

具体地，可基于从数据库中调取的日志信息，分析微服务环境下的服务系统(可包括多个微服务)性能参数，如分析系统性能瓶颈分析、系统健康状况、或分析各个服务的访问量、访问压力信息等。

对于在以用户为主导的微服务环境下，用户日志变得越来越重要，用户行为、用户喜好，用户购买力等都可通过微服务日志进行分析得到相关结果数据，因此本实施例还可利用从数据库中调出的一个或多个微服务的日志信息，来分析用户行为、用户喜好，用户购买力等等。

在对调出的日志信息进行分析，得出相关结果数据后，可将所述结果数据推送至相应的目标接收者，例如，将分析出的系统性能瓶颈数据、系统健康状况数据推送至相关管理人员，将分析得出的用户行为，用户喜好，用户购买力数据推送至具有相应权限的某些用户等。

实施例八

本实施例中，当所述预设类型的日志处理条件为：到达预设的针对至少一个目标服务的日志推送时间或接收到针对至少一个目标服务的日志查看请求时，所述第二处理器200具体用于：推送所述至少一个目标服务对应的目标日志信息。

目前，基于微服务相关信息的订阅推送日渐兴起，在云平台环境下，基于微服务的用户资源实时管理信息，资源的健康状态信息等都需要及时反馈给用户，从而，为了解决和用户间的交互，供用户实时查看和掌握其服务系统的相关信息，本实施例具体提供一种面向用户的服务日志订阅推送方案。

参考图7示出的日志订阅推送示意图，当到达用户订阅的服务系统(可包括多个服务)的日志推送时间，或接收到用户发出的系统日志推送请求后，可从统一存储的日志数据库中调取出相关的日志信息，并推送给用户，供用户查看，从而满足了用户的日志查看请求。

需要说明的是，本说明书中的各个实施例均采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似的部分互相参见即可。

通过以上的实施方式的描述可知，本领域的技术人员可以清楚地了解到本申请可借助软件加必需的通用硬件平台的方式来实现。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在存储介质中，如ROM/RAM、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例或者实施例的某些部分所述的方法。

最后，还需要说明的是，在本文中，诸如第一、第二、第三和第四等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

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

Claims (11)

1.一种日志处理方法，其特征在于，包括：

在符合预设类型的日志处理条件时，从统一存储的各个服务的日志信息中获取至少一个目标服务对应的目标日志信息；

对所述目标日志信息进行所述预设类型的日志处理。

2.根据权利要求1所述的方法，其特征在于，所述统一存储的各个服务的日志信息包括：针对服务间的穿透访问，统一记录的所述穿透访问所涉及的各个服务的日志信息，其中，所述穿透访问所涉及的各个服务的日志信息包括所述穿透访问的访问身份标识号，不同的穿透访问对应的访问身份标识号不同。

3.根据权利要求2所述的方法，其特征在于，当所述目标服务为目标穿透访问所涉及的多个服务时，所述从统一存储的各个服务的日志信息中获取至少一个目标服务对应的目标日志信息包括：

依据所述目标穿透访问的访问身份标识号，从统一存储的日志信息中获取所述目标穿透访问所涉及的各个服务的日志信息。

4.根据权利要求1所述的方法，其特征在于，所述预设类型的日志处理条件为：

到达针对至少一个目标服务的预设类型的日志分析时间；或，

接收到针对至少一个目标服务的预设类型的日志分析请求；或，

到达预设的针对至少一个目标服务的日志推送时间；或，

接收到针对至少一个目标服务的日志查看请求。

5.根据权利要求4所述的方法，其特征在于，当所述预设类型的日志处理条件为：到达针对至少一个目标服务的预设类型的日志分析时间或接收到针对至少一个目标服务的预设类型的日志分析请求时，所述对所述目标日志信息进行所述预设类型的日志处理包括：

对所述至少一个目标服务对应的目标日志信息进行所述预设类型的日志分析，得到日志分析结果；

推送所述日志分析结果。

6.根据权利要求4或5所述的方法，其特征在于，所述预设类型的日志分析为：分析应用程序编程接口访问服务错误时对应的错误信息、分析目标服务所在的服务系统的性能、健康程度或分析用户行为中的任意一种。

7.根据权利要求4所述的方法，其特征在于，当所述预设类型的日志处理条件为：到达预设的针对至少一个目标服务的日志推送时间或接收到针对至少一个目标服务的日志查看请求时，所述对所述目标日志信息进行所述预设类型的日志处理包括：

推送所述至少一个目标服务对应的目标日志信息。

8.一种日志处理电子设备，其特征在于，包括：

第一处理器，用于在符合预设类型的日志处理条件时，从统一存储的各个服务的日志信息中获取至少一个目标服务对应的目标日志信息；

第二处理器，用于对所述目标日志信息进行所述预设类型的日志处理。

9.根据权利要求8所述的电子设备，其特征在于，所述统一存储的各个服务的日志信息包括：针对服务间的穿透访问，统一记录的所述穿透访问所涉及的各个服务的日志信息，其中，所述穿透访问所涉及的各个服务的日志信息包括所述穿透访问的访问身份标识号，不同的穿透访问对应的访问身份标识号不同；则当所述目标服务为目标穿透访问所涉及的多个服务时，所述第一处理器具体用于：

依据所述目标穿透访问的访问身份标识号，从统一存储的日志信息中获取所述目标穿透访问所涉及的各个服务的日志信息。

10.根据权利要求8所述的电子设备，其特征在于，当所述预设类型的日志处理条件为：到达针对至少一个目标服务的预设类型的日志分析时间或接收到针对至少一个目标服务的预设类型的日志分析请求时，所述第二处理器具体用于：

对所述至少一个目标服务对应的目标日志信息进行所述预设类型的日志分析，得到日志分析结果；推送所述日志分析结果。

11.根据权利要求8所述的电子设备，其特征在于，当所述预设类型的日志处理条件为：到达预设的针对至少一个目标服务的日志推送时间或接收到针对至少一个目标服务的日志查看请求时，所述第二处理器具体用于：

推送所述至少一个目标服务对应的目标日志信息。