CN105191211B - 服务器集群下的日志提取方法和服务器集群 - Google Patents

Abstract

本发明公开了一种服务器集群下的日志提取方法和服务器集群。本发明实施例提供的一种服务器集群下的日志提取方法包括：第一日志组件在将第一应用服务的日志记录至对应的第一日志库时，根据配置数据获取与日志关联的用户和/或业务的信息，并将该信息记录在为日志设置的上下文字段中；第一日志组件根据第一应用服务接收到的请求端的日志调用请求，获知该日志调用请求中的输出表达式，该输出表达式用于指示与请求调用的日志关联的用户和/或业务的信息满足的条件；第一日志组件将输出表达式与第一日志库中保存的日志的上下文字段进行匹配；将匹配成功的日志输出至日志调用请求所指定的输出端口。

Description

服务器集群下的日志提取方法和服务器集群

技术领域

本发明涉及计算机网络技术领域，特别涉及一种服务器集群下的日志提取方法和服务器集群。

背景技术

在服务器系统的开发与维护中，分析日志是一种主要的排错手段，在不同的领域下也出现了很多成熟的日志系统，允许将日志写入本地的文本文件或中心数据库文件。

然而，现有的日志系统已无法满足大规模服务器集群的运维需要，例如，现有日志系统将不同用户或不同业务的日志混杂在一起输出及处理，导致在集群的几百台服务器中通过日志排查单个用户或业务的错误时难度过高。

发明内容

鉴于上述问题，本发明实施例提供了一种服务器集群下的日志提取方法和服务器集群，以解决现有方案在集群中通过日志排查单个用户或业务的错误时难度过高的问题等。

为了达到上述目的，本发明实施例采用的技术方案如下：

一方面，本发明实施例提供了一种服务器集群下的日志提取方法，包括：

第一日志组件在将第一应用服务的日志记录至对应的第一日志库时，根据配置数据获取与日志关联的用户和/或业务的信息，并将信息记录在为日志设置的上下文字段中；第一日志组件根据第一应用服务接收到的请求端的日志调用请求，获知日志调用请求中的输出表达式，该输出表达式用于指示与请求调用的日志关联的用户和/或业务的信息满足的条件；第一日志组件将输出表达式与第一日志库中保存的日志的上下文字段进行匹配；第一日志组件将匹配成功的日志输出至日志调用请求所指定的输出端口。

另一方面，本发明实施例提供了一种服务器集群，包括多个应用服务器。该应用服务器中包括第一应用服务器，第一应用服务器包括第一应用服务、第一日志组件和第一日志库。

第一应用服务，用于承载业务，接收来自请求端的业务请求并处理；第一日志库，用于存储第一应用服务的日志；第一日志组件，用于在将第一应用服务的日志记录至对应的第一日志库时，根据配置数据获取与日志关联的用户和/或业务的信息，并将信息记录在为日志设置的上下文字段中；根据第一应用服务接收到的请求端的日志调用请求，获知日志调用请求中的输出表达式，该输出表达式用于指示与请求调用的日志关联的用户和/或业务的信息满足的条件；将输出表达式与第一日志库中保存的日志的上下文字段进行匹配；将匹配成功的日志输出至日志调用请求所指定的输出端口。

由上所述，本发明实施例通过将与日志关联的用户和/或业务的信息记录在为日志设置的上下文字段中，以及将输出表达式与保存的日志的上下文字段进行匹配、输出匹配成功的日志至指定端口的技术手段，能够利用用户和/或业务的信息从集群中筛选出需要的日志，如某一特定用户的日志或某一特定业务的日志，并能够将单个用户或特定业务的日志输出至指定的服务器，从而极大便利了在集群中通过日志追踪和排查单个用户或业务错误的操作，提高了整个系统排错的效率，满足了大规模服务器集群的运维需要。

附图说明

图1示出了根据本发明一个实施例的一种服务器集群的结构示意图；

图2示出了根据本发明又一个实施例的更新日志组件的配置数据的流程示意图；

图3示出了根据本发明又一个实施例的针对单个业务调用的日志追踪流程；

图4示出了根据本发明又一个实施例的基于整个集群环境下的面向单个业务的日志抽取方法；

图5示出了根据本发明又一个实施例的一种服务器集群下的日志提取方法流程图。

具体实施方式

为使本发明的目的、技术方案和优点更加清楚，下面将结合附图对本发明实施方式作进一步地详细描述。

本发明一个实施例提供的一种服务器集群，包括多个应用服务器。该集群中还可以设置有配置中心服务器和日志分析及测试服务器。参见图1，示出了本实施例提供的一个服务器集群的结构示意图。该服务器集群中包括应用服务器100、配置中心服务器200和日志分析及测试服务器300。应用服务器100中包括应用服务110、日志组件111和日志库112。下面分别对这些器件进行说明。

应用服务110用于承载业务，接收来自请求端的业务请求并处理。应用服务的日志会通过日志组件111进行记录。记录时，应用服务110会将当前的用户或业务的相关信息、日志等级、线程及会话相关的信息传给日志组件111。当前的用户或业务的相关信息，可以为诸如用户ID、业务ID、用户状态或业务状态以及其它对用户或业务的描述信息等，日志组件111将这些相关信息记录在日志的上下文字段中，以利用这些相关信息来匹配日志调用请求中的输出表达式。

日志组件111为可复用的代码库，向上提供记录应用服务日志的接口，向下将日志存储至日志库112。日志组件111可以根据日志等级、线程信息、会话信息、用户信息和/或业务信息判断该日志是否应当进行记录。

本实施例提供的日志组件111具有为日志设置上下文(Context)字段的功能，用于将用户和/或业务的信息设置在日志的上下文字段中，以及将日志调用请求中的输出表达式与上下文字段进行匹配。例如，通过该功能，日志组件111在将应用服务110的日志记录至对应的日志库112时，日志组件111根据自身已获取的配置数据获取与日志关联的用户和/或业务的信息，并将该信息记录在为日志设置的上下文字段中；以及，根据应用服务110接收到的请求端的日志调用请求，获知该日志调用请求中的输出表达式，该输出表达式用于指示与请求调用的日志关联的用户和/或业务的信息满足的条件，则将输出表达式与日志库112中保存的日志的上下文字段进行匹配；将匹配成功的日志输出至日志调用请求所指定的输出端口，如输出至文本文件、数据库及RPC(Remote Procedure Call Protocol，远程过程调用协议)接口中。

日志库112存储应用服务的日志数据。一个应用服务对应一个日志组件和日志库。

配置中心服务器200在整个服务器集群中同步所有应用服务器中日志组件的配置数据。配置中心服务器200保存并更新集群中所有应用服务的日志组件的配置数据，例如，对服务器集群中的第一应用服务器中的第一日志组件，配置中心服务器200定时轮询第一日志组件的订阅信息中包括的版本号(即第一日志组件的配置数据中的版本号)与配置中心服务器保存的对应的配置数据中的版本号是否一致，当版本号不一致时，向第一日志组件发送版本更新提示信息，以及，根据该版本更新提示信息将新的配置数据发送至第一日志组件。相应的，第一日志组件会向配置中心服务器发送订阅信息，该订阅信息包括配置数据中的版本号；当该订阅信息中包括的版本号与配置中心服务器中保存的对应的配置数据中的版本号不一致时，接收配置中心服务器发送的版本更新提示信息；根据版本更新提示信息从配置中心服务器获取新的配置数据并启用该新的配置数据。

其中，在本实施例所描述的集群环境下，配置中心服务器200所使用的日志的配置数据主要包含以下内容：

1：级别(Level)信息：从低到高分别为：调用跟踪(TRACE)日志、调试(DEBUG)日志、业务(INFO)日志、警告(WARN)日志、错误(ERROR)日志。

当待输出的日志的级别大于或等于当前配置的允许输出的日志级别时，输出该日志。日志可以按照应用标记的名字区分不同的级别。

2：输出器(Appender)：将日志信息输出到持久化设备或RPC接口的输出器。输出方式包含文本输出、数据库输出和RPC输出。

3：过滤器(Filter)：用于对日志进行过滤，以判断该日志是否需要输出。在日志是否输出的判断上，先判断过滤器，如果所有过滤器都中立，则根据级别进行判断，其中过滤器可以级联。本实施例的过滤器可以根据线程信息、上下文字段及当前用户信息进行判断。过滤器可以返回以下结果之一：

“通过”：直接输出此日志。

“不通过”：直接忽略此日志。

“中立”：过滤器不做表态，交给下一个过滤器，或按照日志级别进行处理。

需要说明的是，本实施例中的过滤器包括用于上下文字段与输出表达式匹配的过滤器(简称为上下文过滤器)，将该上下文过滤器和相关的上下文字段的列表设置在配置中心服务器的全局配置当中。

可选的，该上下文过滤器返回两种结果“通过”和“中立”。将日志输入至上下文过滤器进行过滤，当日志中的输出表达式与上下文过滤器对应的上下文字段匹配时，上下文过滤器返回的结果是“通过”；当日志中的输出表达式与上下文过滤器对应的上下文字段不匹配时，上下文过滤器返回的结果是“中立”。

当上下文过滤器返回的结果是“中立”，即该日志与该对上下文过滤器中没有匹配成功的日志，日志组件将该日志发送至下一过滤器，如果所有上下文过滤器返回的结果都是中立，对该日志的级别进行判断，即用于级别判断的过滤器判断该日志的级别是否大于或等于当前配置的允许输出的日志级别时，若是，日志组件将该日志输出至日志调用请求所指定的输出端口，若否，日志组件不输出该日志。

日志分析及测试服务器300用于控制配置中心服务器中配置数据的更新，以及根据接收的日志调用请求，从应用服务器获取到对应的日志，将该日志展示在交互界面以进行错误排查。具体的，日志分析及测试服务器300主要面向运维人员，可以通过运维人员的日志配置设置指令，增加针对用户、针对会话的日志配置条件，并且将日志信息实时的反映在查询界面上，另外可以由开发或运维人员日志分析及测试服务器300发起日志调用请求(如测试请求)，并将测试请求的日志完整输出到日志分析及测试服务器300的交互界面上以便于问题的排查。

本发明又一个实施例主要对应用服务器中日志组件的配置数据的更新流程进行说明，关于本发明服务器集群的其他内容参见其他实施例的描述。参见图2，示出了本实施例提供的更新日志组件的配置数据的流程示意图，包括如下步骤：

S200：日志组件向配置中心服务获取配置数据。

日志组件对应的应用服务会首先和配置中心服务建立一条长连接并保持，通过该长连接向配置中心服务发送读取配置请求。如图2所示，配置中心服务器侧可以具体包括配置中心服务、配置库和配置分析服务。配置库中保存配置数据，配置数据包括配置中心服务器侧的配置信息和版本号，配置分析服务负责配置信息的更新操作。

日志组件向配置中心服务发送读取配置请求，配置中心服务将该配置请求传递至配置库，配置库通过配置中心服务将所请求的配置数据返回至日志组件，然后，进入步骤S201。

S201：日志组件向配置中心服务订阅配置数据。

日志组件向配置中心服务器发送订阅配置请求，通过该订阅配置请求将日志组件的订阅信息发送至配置中心服务器，订阅信息包括日志组件的配置数据中信息的版本号。订阅信息中还可以包括日志组件对应的应用服务的名称、日志组件所在的应用服务器以及本次订阅的时间。

配置中心服务将各日志组件的订阅信息保存至配置库。当需要执行对配置数据的更新时，进入步骤S202。

S202：配置分析服务更新配置数据。

配置分析服务执行更新时，将配置库中需要更新的配置信息及其版本号修改为新的配置信息和新的版本号。

S203：配置中心服务轮询配置库中存储的日志组件的订阅信息与配置库中存储的配置数据，并判断订阅信息中的版本号与配置库中对应配置数据中的版本号是否一致，如果否，执行S204。

具体的，配置中心服务定时轮询配置库中所有日志组件的订阅信息与配置库中的配置数据，并判断订阅信息中包括的配置数据中的版本号与配置库的配置数据中对应的版本号是否一致，如果不一致，说明配置信息的版本需要更新，则执行S204。

S204：配置中心服务器向日志组件发送版本更新提示信息。

当订阅信息中的版本号与配置数据中的版本号不一致时，配置中心服务器查找与订阅此数据的应用服务建立的长连接，通过此长连接，向日志组件发送版本更新提示信息，进入步骤S205。

S205：日志组件根据所述版本更新提示信息向配置中心服务器获取新的配置数据。

日志组件接收到版本更新提示信息后，通过配置中心服务获取配置数据，此时会获得到新的配置信息及新的版本号。

日志组件向配置中心服务器发送读取配置请求，配置中心服务器将该配置请求传递至配置库，配置库通过配置中心服务器将新的配置信息及版本号返回至日志组件。

S206：日志组件执行配置刷新操作，如果刷新成功，执行S207。

日志组件通过配置刷新操作，如果配置刷新成功，让新获取的配置数据生效，从而可以启用该新的配置数据，进入步骤S207。

本步骤中，如果刷新操作失败，则无法完成对日志组件中的配置信息的更新，无法继续执行订阅操作，所以当配置中心服务再次执行轮询操作时还会触发配置数据的更新操作，直到刷新成功为止。

S207：日志组件继续执行订阅操作，向配置中心服务器订阅配置数据。

当刷新操作成功后，日志组件继续执行订阅操作，此操作将新获取到的版本号传给配置中心，配置中心更新订阅信息中的，已获取配置版本字段。此时日志组件的配置数据已经更新为最新版本，且轮询操作不会重新触发配置数据的更新操作。

本发明又一个实施例主要对在集群中针对单个用户或单个业务的日志追踪并提取的流程进行说明，关于本发明服务器集群的其他内容参见其他实施例的描述。

本实施例提供的一种针对单个用户的日志追踪并提取流程包括如下步骤：

步骤1：请求端通过交互界面输入需要追踪的用户ID。

例如，运维人员可以通过日志分析及测试服务器的交互界面输入需要追踪的用户的用户ID，向应用服务发送日志调用请求。该日志调用请求中的输出表达式用于指示请求调用的日志满足的条件为：请求调用的日志的用户ID＝日志调用请求中的用户ID。日志调用请求中还包括输出日志的指定端口。

应用服务收到日志调用请求后，判断是否存在输出表达式，如果存在，则将输出表达式保存到当前线程的上下文当中，以通过该线程执行对单个用户日志的追踪。

步骤2：应用服务启动日志组件的上下文过滤器并添加输出器和输出地址。

在全局配置中增加一个上下文过滤器，日志组件的配置数据中具有该上下文过滤器。本场景中该上下文过滤器的过滤条件为日志上下文字段中的用户ID与日志调用请求中的用户ID相等，则返回的结果为“通过”，输出该日志，否则“中立”。而上述添加的输出地址为日志调用请求中指定的输出端口。

需要说明的是，日志组件在对用户的日志进行记录时，会根据配置数据获取与日志关联的用户的信息，例如，配置数据指示需要获取的与日志关联的用户信息包括用户ID，则日志组件在记录日志时将用户ID记录在为该日志设置的上下文字段中。

步骤3：当上下文过滤器返回的结果是通过时，日志组件通过输出器将匹配成功的日志输出所述输出地址。

日志组件将日志调用请求中的输出表达式与日志库中保存的日志的上下文字段进行匹配，匹配成功的日志为用户ID符合的日志，通过输出器将该日志输出至指定的输出端口。

集群中所有应用服务器的日志组件都可以根据上述步骤1至3中的操作将用户ID符合的日志截取出来，输出至指定的输出端口，实现单个用户的日志的追踪。

步骤4：由日志分析及测试服务器实时轮询所有应用服务器上的日志输出，收集输出结果并展示在日志分析及测试服务器的界面上，供运维人员查询。

参见图3，示出了本实施例提供的针对单个业务调用的日志追踪流程，包括如下步骤：

S300：请求端向应用服务发送业务调用请求，进入步骤S301。

请求端将日志输出的端口地址及输出表达式，放到业务调用请求的扩展字段中，发起业务调用。即可以将日志调用请求中的内容设置在业务调用请求的扩展字段中。

S301：应用服务从业务调用请求中提取出输出表达式。

应用服务收到业务调用请求后，判断是否存在输出表达式，如果存在，将该输出表达式提取出来，进入步骤S302。

S302：应用服务添加基于RPC的日志输出器，然后，进入步骤S303。

对业务的调用通常是基于RPC方式的，本实施例在日志组件中添加了一个基于RPC的日志输出器，增加了基于RPC的日志输出方案，包括如下：

添加RPC的日志输出器，该输出器的输出地址为日志调用请求中指定的输出端口，例如该输出地址为RPC日志接收端服务器的地址tcp://192.168.1.100:7078。当需要输出日志时，先将需要输出的日志信息放到队列中。由于业务产生的日志数量较多，另外启动一个定时任务，定期从队列中将日志信息批量读取出来发送到上述地址。如果发送失败，且重试次数超过N次(N的取值根据系统设置)，则自动移除此基于RPC的输出器，以避免性能消耗。

S303：应用服务设置日志组件的上下文过滤器。

应用服务将输出表达式保存到当前线程的上下文当中。通过当前线程运行上下文过滤器进行对业务调用日志的追踪，所以该线程需要通过线程上下文获知输出表达式。应用服务设置日志组件的上下文过滤器为开启状态，继续执行步骤S304。

S304：应用服务执行业务代码。

当应用服务执行业务代码实现业务的调用时，会生成日志，日志组件将这些日志写入日志库中。日志组件在写日志时，会根据日志组件的配置数据获取与业务相关的信息，将这些信息记录在为业务的日志设置的上下文字段中。在执行步骤S304的同时或执行步骤S304之后，进入步骤S305。

S305：日志组件利用上下文过滤器将日志的上下文字段与业务调用请求中的输出表达式匹配，对日志进行过滤。

当日志组件执行日志输出时，上下文过滤器为开启状态，则判断本线程的上下文中是否存在输出表达式，若输出表达式存在，则日志组件会将本线程的上下文过滤器过滤出的日志输出到之前添加的指定输出端口上。对于其他的业务请求，因为这些请求并不在当前线程执行，也不存在线程上下文，所以由这些业务请求产生的日志不会被输出至指定端口上。日志过滤操作结束后，进入步骤S306。

S306：当此业务代码执行结束后，应用服务通知请求端业务调用完成，进入步骤S307。

S307：关闭在本次业务调用中开启的上下文过滤器，仅此次业务调用的全部日志被输出到指定地址。

在服务器集群环境下，业务调用通常不仅仅局限在一台应用服务器上，很可能存在并发等场景，针对多台应用服务器执行一次业务调用的并发场景，本发明又一实施例提供了一种基于整个集群环境下的面向单个业务的日志抽取方法，能够将特定业务在不同服务器间的调用的日志全部输出至特定服务器。参见图4，具体包括如下步骤：

S400：日志分析及测试服务器向接入层服务发起采样申请，进入步骤S401。

对于多个应用服务器的场景，集群中会设置一个接入层服务，负责业务请求在各应用服务器之间的调度，保持负载的均衡。

可以由运维人员在日志分析及测试服务器中向涉及到的接入层服务发起采样申请。采样申请中包括采样配置，该采样配置可以包括采样次数(如N次)、采样出的日志输出的地址(如可以将输出端口设置为日志测试与分析服务器)以及采样策略。示例性的，采样策略可以包括下述的一种或多种：

随机记录应用服务对业务请求生成的日志；或者，

记录应用服务为特定用户的业务请求生成的日志；或者，

记录应用服务为特定IP地址的业务请求生成的日志。

S401：请求端发送业务请求至接入层服务，接入层服务将业务请求转发至对应的应用服务，进入步骤S402。

接入层服务根据接收到采样配置，针对请求端(如客户端)的业务请求进行判断，如果满足采样配置，则将请求端的业务请求转发给后端实际的应用服务，如第一应用服务器。在业务请求中包括用于追踪日志的输出表达式以及日志的指定的输出端口。

通过采样策略可以针对需要关注的特定用户或IP的日志(如信息发送失败的用户或IP)进行记录，并将这些日志记录至特定的服务器中，从而便利了错误的追踪和排查。

S402：当第一应用服务接收到业务请求后，判断业务请求中是否存在输出表达式，若存在，则将输出表达式保存到当前线程上下文当中，设置日志组件的上下文过滤器为开启状态并添加输出器及输出端口；第一应用服务执行业务处理，将过滤出的日志通过输出器输出至指定的输出端口(如日志分析及测试系统)。

S402中的具体内容可以参见上述步骤S301至S305中的详细描述，然后进入步骤S403。

S403：第一应用服务通过应用服务间的调用组件调用第二应用服务，进入步骤S404。

上述调用组件可以为基于RPC的调用组件。当第一应用服务通过RPC调用组件调用第二应用服务的时候，由RPC调用组件判断第一应用服务的当前线程上下文是否存在输出表达式，如果存在，将此输出表达式及指定的输出地址传递到向第二应用服务发送的业务调用请求中后，通过该业务调用请求调用第二应用服务。

S404：第二应用服务接收来自第一应用服务的基于RPC的业务调用请求；第二应用服务判断该业务调用请求中是否存在输出表达式，若存在，则将输出表达式保存到第二应用服务的当前线程上下文当中，设置第二日志组件的上下文过滤器为开启状态并添加输出器及输出端口。第二应用服务执行业务处理，将过滤出的日志输出至指定端口(如日志分析及测试系统)。

S404中的具体内容可以参见上述步骤S301至S305的详细描述。应用间的调用结束后，进入步骤S405。

S405：第二应用服务结束调用，返回调用结束消息给第一应用服务，同时第二应用服务移除自己的线程上下文标记，防止继续输出日志。

S406：第一应用服务接收到来自第二应用服务的调用结束消息后，继续进行业务处理。

S406中的具体操作与步骤S402中的相同，然后进入步骤S407。

S407：第一应用服务业务调用完成后，通过接入层服务向请求端返回业务处理完毕的应答，同时移除自己的线程上下文标记，防止继续输出日志。

S408：接入层服务将应答转发给请求端后，如果已经完成了本次采样任务，则结束采样。

由上，本实施例弥补了现有日志系统缺少针对大规模服务器集群设计的不足，为大型服务器集群下的实时日志抓取提供了解决方案，另外本实施例提供了针对单次业务的日志追踪，在大规模的业务系统中，大幅度提高了整体排错的效率。

本发明又一个实施例提供了一种服务器集群下的日志提取方法，参见图5，该方法包括如下步骤：

S500：第一日志组件将第一应用服务的日志记录至对应的第一日志库时，根据配置数据获取与日志关联的用户和/或业务的信息，并将该信息记录在为日志设置的上下文字段中。

服务器集群中包括多个应用服务器，第一应用服务器为其中的任一应用服务器，每个应用服务器中都包括一个应用服务、一个日志组件和一个日志库。第一应用服务器中的应用服务、日志组件和日志库，可被称之为第一应用服务、第一日志组件和第一日志库。上述第一日志组件使用的配置数据中包括但不局限于日志的级别、输出器和过滤器。在此，第一日志组件主要根据上下文过滤器中的内容获知与日志关联的用户和/或业务的信息。

本实施例还可以针对特定用户和/或业务的日志进行记录并将日志记录至特定的服务器，则上述将第一应用服务的日志记录至对应的第一日志库还包括：将第一应用服务为满足采样策略的业务请求生成的日志记录至对应的第一日志库，其中，该采样策略至少包括下述的一种：随机记录应用服务对业务请求生成的日志；或者，记录应用服务为特定用户的业务请求生成的日志；或者，记录应用服务为特定IP地址的业务请求生成的日志。

S501：第一日志组件根据第一应用服务接收到的请求端的日志调用请求，获知该日志调用请求中的输出表达式，该输出表达式用于指示与请求调用的日志关联的用户和/或业务的信息满足的条件。

例如，输出表达式用于指示请求调用日志为用户ID为ID1的用户的日志，或者输出表达式用于指示请求调用日志为用户年龄不大于18岁的用户的日志等等。

S502：第一日志组件将输出表达式与第一日志库中保存的日志的上下文字段进行匹配。

第一日志组件可以通过上下文过滤器实现该匹配操作。

S503：第一日志组件将匹配成功的日志输出至日志调用请求所指定的输出端口。

该指定的输出端口可以是某一特定的服务器。例如，将匹配成功的日志输出至日志调用请求指定的日志分析及测试服务器的输出端口，以将该日志展示在日志分析及测试服务器的交互界面，进行错误排查。

对没有匹配成功的日志，第一日志组件会继续根据级别对该日志进行过滤，例如第一日志组件判断该日志的级别是否大于或等于当前配置的允许输出的日志级别时，若是，将该日志输出至日志调用请求所指定的输出端口，若否，不输出该日志。

本实施例还提供了一种对第一日志组件中的配置数据更新的处理方法，包括：向集群中的配置中心服务器发送订阅信息，该订阅信息包括配置数据中的版本号；当订阅信息中包括的版本号与配置中心服务器中的对应的配置数据中的版本号与不一致时，接收配置中心服务器发送的版本更新提示信息；根据版本更新提示信息从配置中心服务器获取新的配置数据并启用该新的配置数据。上述更新方法的详细描述可以参见上述步骤S200至S207中的内容。

本实施例还提供了一种将特定业务在不同服务器间的调用的日志全部输出至特定服务器的方法，包括：当第一应用服务调用第二应用服务时，应用服务间的调用组件(如RPC调用组件)将日志调用请求指定的输出端口和对应的输出表达式包含在应用服务调用请求中发送至第二应用服务；第二日志组件将输出表达式与第二应用服务对应的第二日志库中保存的日志的上下文字段进行匹配；第二日志组件将第二日志库中匹配成功的日志输出至日志调用请求所指定的输出端口。具体内容还可以参见上述步骤S400至S408中的描述。

由上所述，本发明实施例通过将与日志关联的用户和/或业务的信息记录在为日志设置的上下文字段中，以及将输出表达式与保存的日志的上下文字段进行匹配、输出匹配成功的日志至指定端口的技术手段，能够利用用户和/或业务的信息从集群中筛选出需要的日志，如某一特定用户的日志或某一特定业务的日志，并能够将单个用户或特定业务的日志输出至指定的服务器，从而极大便利了在集群中通过日志追踪和排查单个用户或业务错误的操作，提高了整个系统排错的效率，满足了大规模服务器集群的运维需要。

为了便于清楚描述本发明实施例的技术方案，在发明的实施例中，采用了“第一”、“第二”等字样对功能和作用基本相同的相同项或相似项进行区分，本领域技术人员可以理解“第一”、“第二”等字样并不对数量和执行次序进行限定。

以上所述仅为本发明的较佳实施例而已，并非用于限定本发明的保护范围。凡在本发明的精神和原则之内所作的任何修改、等同替换、改进等，均包含在本发明的保护范围内。

Claims (12)

1.一种服务器集群下的日志提取方法，包括：

第一日志组件在将第一应用服务的日志记录至对应的第一日志库时，根据配置数据获取与所述日志关联的用户和/或业务的信息，并将所述信息记录在为所述日志设置的上下文字段中；

所述第一日志组件根据第一应用服务接收到的请求端的日志调用请求，获知所述日志调用请求中的输出表达式，所述输出表达式用于指示与请求调用的日志关联的用户和/或业务的信息满足的条件；

所述第一日志组件将所述输出表达式与所述第一日志库中保存的日志的上下文字段进行匹配；

所述第一日志组件将匹配成功的日志输出至所述日志调用请求所指定的输出端口。

2.根据权利要求1所述的方法，其中，所述方法还包括：

所述第一日志组件向配置中心服务器发送订阅信息，所述订阅信息包括第一日志组件的配置数据中的版本号；

当所述订阅信息中的版本号与配置中心服务器中对应的配置数据中的版本号不一致时，所述第一日志组件接收配置中心服务器发送的版本更新提示信息；

所述第一日志组件根据所述版本更新提示信息从配置中心服务器获取新的配置数据并启用该新的配置数据。

3.根据权利要求1所述的方法，其中，所述方法还包括：

当第一应用服务调用第二应用服务时，应用服务间的调用组件将所述日志调用请求指定的输出端口和对应的输出表达式包含在应用服务调用请求中发送至第二应用服务；

第二日志组件将所述输出表达式与第二应用服务对应的第二日志库中保存的日志的上下文字段进行匹配；

所述第二日志组件将第二日志库中匹配成功的日志输出至所述日志调用请求所指定的输出端口。

4.根据权利要求1至3任一项所述的方法，其中，所述方法还包括：

对没有匹配成功的日志，第一日志组件判断所述日志的级别是否大于或等于当前配置的允许输出的日志级别，若是，第一日志组件将所述日志输出至所述日志调用请求所指定的输出端口，若否，第一日志组件不输出所述日志。

5.根据权利要求1所述的方法，其中，所述将第一应用服务的日志记录至对应的第一日志库包括：

将第一应用服务为满足采样策略的业务请求生成的日志记录至对应的第一日志库，其中，所述采样策略至少包括下述的一种：

随机记录应用服务对业务请求生成的日志；或者，

记录应用服务为特定用户的业务请求生成的日志；或者，

记录应用服务为特定IP地址的业务请求生成的日志。

6.根据权利要求1所述的方法，其中，所述将匹配成功的日志输出至所述日志调用请求所指定的输出端口包括：

将匹配成功的日志输出至所述日志调用请求指定的日志分析及测试服务器的输出端口，以将所述日志展示在日志分析及测试服务器的交互界面进行错误排查。

7.一种服务器集群，包括多个应用服务器，所述应用服务器中包括第一应用服务器，所述第一应用服务器包括第一应用服务、第一日志组件和第一日志库；

所述第一应用服务，用于承载业务，接收来自请求端的业务请求并处理；

所述第一日志库，用于存储第一应用服务的日志；

所述第一日志组件，用于在将第一应用服务的日志记录至对应的第一日志库时，根据配置数据获取与所述日志关联的用户和/或业务的信息，并将所述信息记录在为所述日志设置的上下文字段中；根据第一应用服务接收到的请求端的日志调用请求，获知所述日志调用请求中的输出表达式，所述输出表达式用于指示与请求调用的日志关联的用户和/或业务的信息满足的条件；将所述输出表达式与所述第一日志库中保存的日志的上下文字段进行匹配；将匹配成功的日志输出至所述日志调用请求所指定的输出端口。

8.根据权利要求7所述的服务器集群，其中，还包括配置中心服务器，用于保存并更新集群中所有应用服务的日志组件的配置数据，定时轮询并判断第一日志组件的订阅信息中的版本号与配置中心服务器中对应的配置数据的版本号是否一致，当不一致时，向第一日志组件发送版本更新提示信息，以及，根据所述版本更新提示信息将新的配置数据发送至第一日志组件；

所述第一日志组件，还用于向配置中心服务器发送订阅信息，所述订阅信息包括所述第一日志组件的配置数据中的版本号；当所述订阅信息中的版本号与配置中心服务器中对应的配置数据的版本号不一致时，接收配置中心服务器发送的版本更新提示信息；根据所述版本更新提示信息从配置中心服务器获取新的配置数据并启用该新的配置数据。

9.根据权利要求7所述的服务器集群，其中，还包括第二应用服务器以及应用服务间的调用组件，所述第二应用服务器包括第二应用服务、第二日志组件和第二日志库；

所述应用服务间的调用组件，用于当第一应用服务调用第二应用服务时，将所述日志调用请求指定的输出端口和对应的输出表达式包含在应用服务调用请求中发送至第二应用服务；

所述第二日志组件，用于将所述输出表达式与第二应用服务对应的第二日志库中保存的日志的上下文字段进行匹配；并将第二日志库中匹配成功的日志输出至所述日志调用请求所指定的输出端口。

10.根据权利要求7至9任一项所述的服务器集群，其中，所述第一日志组件和第二日志组件，还分别用于对没有匹配成功的日志，判断所述日志的级别是否大于或等于当前配置的允许输出的日志级别，若是，将所述日志输出至所述日志调用请求所指定的输出端口，若否，不输出所述日志。

11.根据权利要求7所述的服务器集群，其中，所述第一日志组件，还用于将第一应用服务为满足采样策略的业务请求生成的日志记录至对应的第一日志库，其中，所述采样策略至少包括下述的一种：

随机记录应用服务对业务请求生成的日志；或者，

记录应用服务为特定用户的业务请求生成的日志；或者，

记录应用服务为特定IP地址的业务请求生成的日志。

12.根据权利要求8所述的服务器集群，其中，还包括日志分析及测试服务器，用于控制所述配置中心服务器中配置数据的更新，以及根据接收的日志调用请求，从应用服务器获取到对应的日志，将所述日志展示在交互界面以进行错误排查。