CN109783330A - 日志处理方法、显示方法和相关装置、系统 - Google Patents

Abstract

本申请实施例公开一种日志处理方法，包括：获得日志数据和解析规则；按照解析规则，对日志数据进行处理；发送处理后的日志数据；其中，至少利用解析规则中的解析表达式对日志数据进行格式化处理，经格式化处理后的日志数据及所述日志数据的关联内容能够进行关联显示。还公开了一种日志显示方法和相关装置、系统。

Description

日志处理方法、显示方法和相关装置、系统

技术领域

本申请涉及日志数据处理技术，具体涉及一种日志处理方法、显示方法和相关装置、系统。

背景技术

日志数据的海量性已被业内公知，针对海量日志数据的查询，目前仅能通过以下方式：在具有查询功能的系统上输入要查询的日志内容，查询系统从存储的数据库中搜索输入的内容，如果数据库中存在该内容则查询成功，显示用户输入的要查询的日志内容。而往往用户输入的要查询的日志内容仅为其要查询的全部信息中的部分信息，这种部分信息的查询在一定程度上无法满足用户的需求。

发明内容

为解决现有存在的技术问题，本发明实施例提供一种日志处理方法、显示方法和相关装置、系统，至少能够避免仅对待查询内容进行的单一显示。

本发明实施例的技术方案是这样实现的：

本发明实施例提供了一种日志处理方法，所述方法包括：

获得日志数据和解析规则；

按照解析规则，对日志数据进行处理；

发送处理后的日志数据；

其中，至少利用解析规则中的解析表达式对日志数据进行格式化处理，经格式化处理后的日志数据及所述日志数据的关联内容能够进行关联显示。

上述方案中，所述至少按照解析规则中的解析表达式对日志数据进行格式化处理，包括：

按行读取日志数据，并利用所述解析表达式解析日志数据的以下至少一种内容：日志标识、日志的时间戳信息、日志的线程标识、日志等级、日志内容；

将所解析的内容进行存储。

上述方案中，所述方法还包括：将从同一日志数据中解析出的内容存储到相同的接口函数中。

上述方案中，所述获得解析规则，包括：

接收解析规则；

所述解析规则包括至少两种解析表达式；

在利用解析规则中的其中一种解析表达式对日志数据进行格式化处理未成功时，使用所述至少两种解析表达式中的剩余至少一种解析表达式进行解析。

本发明实施例还提供了一种日志显示方法，所述方法包括：

接收查询操作；

响应查询操作，至少显示待查询日志数据的线程标识；所述日志数据至少为按照解析规则进行格式化处理后的数据；

基于线程标识，对待查询日志数据及待查询日志数据的关联内容进行关联显示。

上述方案中，所述将对待查询日志数据及待查询日志数据的关联内容进行显示，至少包括：按照日志数据的时间戳，将对待查询日志数据及待查询日志数据的关联内容进行关联显示。

上述方案中，所述将对待查询日志数据及待查询日志数据的关联内容进行显示，至少包括：按照日志数据的时间戳和累加标识，将对待查询日志数据及待查询日志数据的关联内容进行关联显示；其中，所述累加标识至少用于对具有相同时间戳的日志数据进行的顺序标识。

本发明实施例还提供了一种日志处理装置，所述装置包括：

获取单元，用于获得日志数据和解析规则；

处理单元，用于按照解析规则，对日志数据进行处理；

传输单元，用于发送处理后的日志数据。

本发明实施例还提供了一种日志显示装置，所述装置包括：

传输单元，用于接收查询操作；

响应单元，用于响应查询操作，至少显示待查询日志数据的线程标识；所述日志数据至少为按照解析规则进行格式化处理后的数据；

显示单元，用于基于线程标识，对待查询日志数据及待查询日志数据的关联内容进行关联显示。

本发明实施例还提供了一种日志系统，至少包括本发明实施例所述的日志处理装置和本发明实施例所述的日志显示装置。

本申请实施例中，基于解析规则中的解析表达式对日志数据进行格式化处理，经格式化处理后的日志数据及该日志数据的关联内容能够进行关联显示，至少能够避免仅对待查询内容进行的单一显示。

附图说明

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

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

图2为本申请提供一种日志显示方法的实施例的流程示意图；

图3为本申请提供的一种日志处理系统的框架示意图；

图4a和图4b为本申请提供的查询操作页面展示示意图；

图5为本申请提供的日志处理装置的实施例的组成结构示意图；

图6为本申请提供的日志显示装置的实施例的组成结构示意图。

具体实施方式

为使本申请的目的、技术方案和优点更加清楚明白，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互任意组合。在附图的流程图示出的步骤可以在诸如一组计算机可执行指令的计算机系统中执行。并且，虽然在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤。

对于前述内容：往往用户输入的要查询的日志内容仅为其要查询的全部信息中的部分信息，这种部分信息的查询在一定程度上无法满足用户的需求，可以结合以下应用场景来理解：

在应用层面上，针对用户A对某一商家的投诉请求，在技术层面上，该投诉请求为一超文本传输协议(HTTP)请求，客户端会产生针对该HTTP请求产生对应的日志数据。在查询该投诉请求时，查询人员输入待查询数据即可显示出该投诉请求。相关技术中，仅能显示针对投诉请求而产生的日志数据，对于与该投诉请求相关联的其它日志数据如该投诉请求是否被处理，采用哪种方式解决的均无法显示。如果这些关联日志数据将一并显示，则会大大提升用户的使用体验。

本方案就在于解决相关技术中仅能对待查询内容进行显示，显示较为单一的问题。利用本申请实施例的以下技术方案至少能够实现待查询日志及该待查询日志的关联数据的关联显示。

本领域技术人员应该而知，待查询的日志数据的关联内容是与待查询的日志数据存在一定关联关系的数据，待查询的日志数据及其关联内容可表示为关于同一事件的日志内容，如前述的关于投诉请求这一事件的发展情况。将待查询的日志数据及其关联内容进行关联显示，可以理解为，将待查询的日志数据及其关联内容进行一并显示；或者，为待查询的日志数据及其关联内容提供一个查询入口，通过该查询入口进入到展示所述待查询的日志数据及其关联内容的显示界面。

考虑到在实际应用中，不同客户端产生的日志格式不尽相同，同一客户端上的不同的应用产生的日志格式也不尽相同，本方案要想实现对待查询日志数据及其关联数据的关联显示，需先对日志数据进行格式化处理，使得格式统一，以方便后续的查询操作。

本申请提供一种日志数据方法的实施例，如图1所示，所述方法包括：

步骤101：获得日志数据和解析规则；

步骤102：按照解析规则，对日志数据进行处理；其中，至少利用解析规则中的解析表达式对日志数据进行格式化处理；经格式化处理后的日志数据及所述日志数据的关联内容能够进行关联显示；

步骤103：发送处理后的日志数据；

步骤101～步骤103的执行主体可以为客户端或收集端。在步骤101中，执行主体采集客户端产生的不同格式的日志数据，接收控制中心下发的解析规则；在步骤102中，执行主体按照解析规则中的解析表达式对不同格式的日志数据进行格式化处理，该经格式化处理后的日志数据及该日志数据的关联内容能够进行关联显示。在步骤103中，执行主体发送经格式化的日志数据。

在步骤103中，如果执行主体为客户端，则执行主体发送经格式化的日志数据至收集端。如果执行主体为收集端，则执行主体发送经格式化的日志数据至队列。

由上述方案可知，本申请实施例基于解析规则中的解析表达式对日志数据进行格式化处理，经格式化处理后的日志数据及该日志数据的关联内容能够进行关联显示，为进行关联显示提供了一定的基础。基于解析表达式进行格式化处理的方式，应用面广，可适用于不同类型的日志格式，这种格式化处理在实际应用工中易于实现，易于移植，可实施性佳。

在一个可选的方案中，所述至少按照解析规则中的解析表达式对日志数据进行格式化处理，包括：

按行读取日志数据，并利用所述解析表达式解析日志数据的以下至少一种内容：日志标识、日志的时间戳信息、日志的线程标识、日志等级、日志内容；

将所解析的内容进行存储。

上述可选方案中，执行主体按行读取日志数据，即采用解析表达式进行逐行日志数据的逐行解析，解析出日志数据的以上至少一种内容并按照一定的格式进行排序，这种格式化方式可实施性佳。

在一个可选的方案中，所述方法还包括：

将从同一日志数据中解析出的内容存储到相同的接口函数中。

上述可选方案中，执行主体将从同一日志数据解析出的内容存储到海量日志数据系统(flume)的同一event接口函数中、更进一步的是同一event接口函数中的头文件(header)中，相当于将从同一日志数据中解析出的内容存储到本地磁盘里，与将日志数据存储到本地内存的方式相比，保存时间被延长，可方便查询。

本方案中，日志数据最终不是存储在flume中，是存储在数据库中如分布式全文索引(elastic search)中。步骤101～步骤103的执行主体可以利用flume具有顺时间状态的特性进行日志数据的存储；更进一步的，利用flume中的event特性：event具有保存单一日志的功能，利用event保存解析出的日志数据并将解析出的日志数据发送出去。

在一个可选的方案中，所述获得解析规则，包括：

接收解析规则；

所述解析规则包括至少两种解析表达式；

在利用解析规则中的其中一种解析表达式对日志数据进行格式化处理未成功时，使用所述至少两种解析表达式中的剩余至少一种解析表达式进行解析。

在上述方案中，执行主体接收到的控制中心下发的解析表达式的数量为两个及以上，在利用其中一种解析表达式解析日志数据不成功时，使用其它的解析表达式进行解析。这种格式化处理方法可最大程度的使得日志数据解析为统一的日志格式。

考虑到在实际应用中，在对日志数据进行格式化之后，用户可通过控制中心进行查询，针对用户的查询操作，控制中心可将待查询日志数据及待查询日志数据的关联内容进行关联显示。

本申请提供一种日志显示方法的实施例，如图2所示，所述方法包括：

步骤201：接收查询操作；

步骤202：响应查询操作，至少显示待查询日志数据的线程标识，所述日志数据至少为按照解析规则进行格式化处理后的数据；

步骤203：基于线程标识，对待查询日志数据及待查询日志数据的关联内容进行关联显示。

步骤201～203的执行主体为控制中心。在接收到用户的查询操作时，控制中心会向elastic search发送查询请求，在浏览器中显示待查询日志数据的线程标识，基于线程标识，对待查询日志数据及待查询日志数据的关联内容进行关联显示。可见，本方案基于线程标识实现了待查询日志数据及待查询日志数据的关联内容的关联显示，解决了仅能显示待查询内容的技术问题，使得显示的内容更为丰富，可大大提升用户的使用体验。

可以理解，在本方案中，控制中心不负责存储日志，负责查询日志，日志需要存储在数据库如elastic search中。

在一个可选的方案中，所述将对待查询日志数据及待查询日志数据的关联内容进行显示，至少包括：

按照日志数据的时间戳，将对待查询日志数据及待查询日志数据的关联内容进行关联显示。

在上述可选的方案中，按照日志数据的产生时间对待查询日志数据及待查询日志数据的关联内容进行关联显示。这样的显示方式更方便用户从时间上区分日志数据，使得使用体验大大提升。

在一个可选的方案中，所述将对待查询日志数据及待查询日志数据的关联内容进行显示，至少包括：

按照日志数据的时间戳和累加标识，将对待查询日志数据及待查询日志数据的关联内容进行关联显示；其中，所述累加标识至少用于对具有相同时间戳的日志数据进行的顺序标识。

在上述可选的方案中，按照日志数据的产生时间和日志数据的累加标识，对待查询日志数据及待查询日志数据的关联内容进行关联显示。这样的显示方式更方便用户从时间上区分日志数据，使得使用体验大大提升。

图3为本发明提供的一种日志处理系统的框架示意图；下面结合图3所示的框架对本方案做进一步说明。

在图3所示的框架中，包括以下几大模块部分：控制中心、客户端、收集端、队列、分发器和数据库。其中，控制中心用于对以上几种模块进行控制，具体的控制方式如下文所述。

本领域技术人员应该而知，日志数据主要包括以下几个部分：日志标识(logger)、日志的时间戳信息(日志的产生时间)、日志的线程标识、日志等级及日志的净荷数据-日志内容(msg)。本文中按照如下方式对这些部分格式化为统一的格式，以方便存储与管理。其中，线程的定义是：针对用户在客户端上产生的请求如前述的投诉请求，其为HTTP请求，由客户端中的线程对该请求进行处理从而产生日志数据。如果能定位到负责某个请求的线程，那么通过该线程即可查询到该线程对应的日志数据。本方案的将待查询的日志数据及其关联数据进行关联显示的方案就按照如上思想来进行。

本方案中以执行格式化的主体为客户端为例，针对自身产生的不同格式的日志数据进行格式化过程：

控制中心为各个客户端配置解析规则并下发解析规则到对应的客户端。客户端之间使用的解析规则可以相同也可以不同，视客户端使用的数据系统及其应用而定。通常，控制中心下发至各个客户端的解析规则中包括至少两种解析表达式，以防止仅利用一种解析表达式无法格式化成功的情况的发生。在具体实现上，可以认为，解析表达式为用于对日志数据中的几大组成部分进行解析的正则表达式，该正则表达式由控制中心记录到解析规则清单中并通过清单的下发到达相应的客户端中。

在客户端侧，日志数据是以文件的形式记录的，本方案中的客户端如客户端1逐行读取日志文件，并利用控制中心下发的解析规则清单中记录的正则表达式进行格式化。

对于日志文件中的某一行，利用如下表1和程序代码中所示的正则表达式，如果能够解析出日志的logger、日志的时间戳信息、日志的线程标识和日志等级等这些信息，则认为是日志数据的一个完整行，对一完整行进行格式化后，客户端即可将其发送至由控制中心指定的收集端。如果在该行没有前述全部信息，则说明该行仅是该日志数据的一部分，缓存该行的日志数据，读取下一行，对下一行数据进行如上信息的解析，如果能够从这两行中能够解析到如上全部信息，则认为这两行中的第二行内容是第一行内容的换行内容，这两行可作为完整的日志数据，可将这两行日志数据发送至由控制中心指定的收集端。否则，读取下下行，并按照以上方法继续解析。这种解析方式考虑到了在日志文件中日志数据换行存储的情况，并通过正则表达式的解决了由于日志数据换行存储而导致的无法解析出来的问题。

如果客户端使用的数据系统为Java系统，则可以利用如表1所示的正则表达式进行逐行的解析，以得到格式化后的日志数据。

表1

表1所示的正则表达式仅为一个具体举例而已，并不限定于本申请实施例中的所有正则表达式。以表1所示的正则表达式为例，其包括5个()，第1个()里的内容表示为对日期进行解析，为日期所处的位置，日期的格式可以统一格式化为“yy-MM-dd.HH:mm:ss.SSS(年-月-日-时-秒-毫秒)”的形式；第2个()里的内容表示为对线程标识进行解析，为线程标识所处的位置；第3个()里的内容表示为对日志等级进行解析，为日志等级所处的位置；第4个()里的内容表示为对日志标识进行解析，为日志标识所处的位置；第5个()里的内容表示为对日志内容进行解析，为日志内容所处的位置。也就是说，客户端按照正则表达式进行日志数据的逐行解析，并将解析出来的内容存放到flume系统中的event接口函数中。

如果客户端使用的数据系统为高并发分布式(nginx)系统，则可以利用如下程序代码所示的正则表达式进行日志数据的格式化。

上述内容中，cells为自定义的字段，正则表达式regex中具有多个()，其中，第5个()里的内容表示对日志日期(log_date)进行解析；第4个()里的内容表示对客户端(agent)标识进行解析，第9个()里的内容表示对请求的返回数据的字节(bytes)进行解析；第3个()里的内容表示对客户端的IP(clientip)进行解析，第2个()里的内容表示对主机的http(http_host)进行解析。客户端按照前述的regex进行日志数据的逐行解析，并将解析出来的内容存放到flume系统中的event接口函数中。可以理解，本方案是将属于同一日志数据的解析内容存放到同一event接口函数中。存储到event接口函数中相当于将从同一日志数据中解析出的内容存储到本地磁盘里，与将日志数据存储到本地内存的方式相比，保存时间被延长，可方便查询。

上述的正则表达式regex仅为一个具体举例而已，并不限定本申请实施例的所有情况。

前述方案中，因为event接口函数包括头文件(header)和主文件(body)，本方案中将解析出来的内容存储到header文件中。在实际应用中，存在有这样一种情况：属于同一日志数据的多行解析内容的时间戳相同，对于这种情况，利用累加器counter对时间戳相同的日志数据进行顺序标识，进一步的利用counter产生的累加标识对时间戳相同的日志数据进行标识。如此，方便在后续的对时间戳相同的日志数据的查询。

前述方案中，客户端按照控制中心发送的解析规则清单中记录的其中正则表达式进行解析，如果利用该正则表达式对日志数据无法成功解析，则利用清单中的其它任一正则表达式进行解析，如果利用清单中的所有正则表达式均无法成功解析，客户端告知控制中心，控制中心更新正则表达式，并通过下发新的清单重新下发正则表达式至该客户端。

客户端通过如上方案进行的解析，相当于将逻辑上的一条日志收集完成，并在解析完成后将解析出来的内容发送到控制中心指定的收集端中。

在实际应用中，收集端的数量小于客户端的数量，由控制中心指示每个收集端负责收集由哪些客户端发送的经格式化处理后的日志数据。

收集端将客户端发送来的经格式化处理后的日志数据发送至对应的队列端；队列端按照队列的形式将接收到的日志数据进行存放。队列端再将日志数据发送至分发器；分发器根据控制中心的指示将日志数据存储到对应的数据库。以将解析后的日志数据存储到elastic search为例，在elastic search中，elastic search将解析后的日志数据进行格式转换，转换成elastic search能够识别的数据格式。

当存在查询需求时，用户可通过控制中心展示的查询页面如图4a所示，进行待查询内容的输入。控制中心接收该输入操作，如接收用户输入的应用程序“sgm-console”以及日志等级“Error”等信息，控制中心在elastic search中进行输入信息的查找，并展示查找结果。如图4a所示中的第一条查找结果为例，控制中心至少显示应用程序名如sgm-console、该程序的客户端所在主机的IP地址、时间、日志等级如Error等信息。同时，还可以显示线程标识如thread等信息，该线程标识thread是本方案提供的一个查询入口，当用户点击thread时，控制中心进入如图4b所示的页面，该页面展示的是应用名为sgm-console、日志等级为Error的日志数据及其关联内容。假定图4b所示的第2个框中所示的日志数据为期望查询的日志数据，该日志数据显示为其出现错误。图4b所示的第1个框中所示的日志数据为与期望查询的日志数据关联的内容，其表示为第2个框中所示的日志数据出现错误的原因是由于执行权限不足而导致的错误。也就是说，作为关联内容，第1个框中所示的日志数据给出了第2个框中所示的日志数据出现错误的原因。可见，本方案基于线程标识实现了待查询日志数据及待查询日志数据的关联内容的关联显示，解决了仅能显示待查询内容的技术问题，不仅能显示待查询内容，还能够显示与待查询内容关联的数据，使得显示的内容更为丰富，可大大提升用户的使用体验。

可以看出，图4b中，诸如[00:04:33:604]和[00:04:33:609]等信息为日志数据的时间戳，本方案中控制中心可按照时间戳对查找到的日志数据进行排序。其中，第1个框和第2个框中所示的日志数据的时间戳均为00:04:33:609，为相同的时间戳，在本方案中日志数据具有相同时间戳的情况下，依据counter产生的累加标识进行来区分日志数据的产生和显示顺序。这种利用累加标识至少能够实现对日志数据的区分。

本方案中的控制中心具体可采用zookeeper来实现。zookeeper是开源的分布式应用程序协调服务，至少可提供配置维护、域名服务、分布式同步和组服务等功能，更易于对正则表达式的修改与重新下发。

利用本申请实施例的技术方案，在海量日志中，能够基于线程标识快速实现期望日志及其关联数据的定位，能够通过减少日志查询定位原因来实现对线上问题的尽快解决。

本申请实施例的基于控制中心下发的正则表达式进行日志格式的格式化的方案，可适配多种日志格式，能够对日志打印做更为规范化的管理。此外，格式化后的日志数据可存储到elastic search中，可通过某些追踪ID(比如线程标识)作为追踪点来对日志进行查询，在工程上易于实现，可加快对期望数据及其关联信息的查询。

基于前述的日志处理方法，本申请实施例提供一种日志处理装置，如图5所示，所述装置包括：

获取单元501，用于获得日志数据和解析规则；

处理单元502，用于按照解析规则，对日志数据进行处理；

传输单元503，用于发送处理后的日志数据；

其中，处理单元502还用于至少利用解析规则中的解析表达式对日志数据进行格式化处理，经格式化处理后的日志数据及所述日志数据的关联内容能够进行关联显示。

在一个可选的方案中，所述处理单元502，还用于按行读取日志数据，并利用所述解析表达式解析日志数据的以下至少一种内容：日志标识、日志的时间戳信息、日志的线程标识、日志等级、日志内容；

将所解析的内容进行存储。

在一个可选的方案中，所述处理单元502，还用于将从同一日志数据中解析出的内容存储到相同的接口函数中。

在一个可选的方案中，所述获取单元501，还用于接收解析规则；

所述解析规则包括至少两种解析表达式；

在利用解析规则中的其中一种解析表达式对日志数据进行格式化处理未成功时，使用所述至少两种解析表达式中的剩余至少一种解析表达式进行解析。

基于前述的日志显示方法，本申请实施例提供一种日志显示装置，如图6所示，所述装置包括：

传输单元601，用于接收查询操作；

响应单元602，用于响应查询操作，至少显示待查询日志数据的线程标识；所述日志数据至少为按照解析规则进行格式化处理后的数据；

显示单元603，用于基于线程标识，对待查询日志数据及待查询日志数据的关联内容进行关联显示。

在一个可选的方案中，所述显示单元603，还用于按照日志数据的时间戳，将对待查询日志数据及待查询日志数据的关联内容进行关联显示。

在一个可选的方案中，所述显示单元603，还用于按照日志数据的时间戳和累加标识，将对待查询日志数据及待查询日志数据的关联内容进行关联显示；其中，所述累加标识至少用于对具有相同时间戳的日志数据进行的顺序标识。

需要说明的是，为实现上述日志处理方法和显示方法，本发明实施例提供了一种日志处理装置和显示装置，由于该装置解决问题的日志处理原理与前述的日志处理方法相似、日志显示方法和显示装置相似，因此，装置的实施过程及实施原理均可以参见前述相关方法的实施过程及实施原理描述，重复之处不再赘述。

本申请实施例还提供一种日志系统，至少包括前述的日志处理装置和前述的日志显示装置；所述日志系统可以采用如图3所示的架构。

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

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

另外，在本发明各实施例中的各功能单元可以全部集成在一个处理单元中，也可以是各单元分别单独作为一个单元，也可以两个或两个以上单元集成在一个单元中；上述集成的单元既可以采用硬件的形式实现，也可以采用硬件加软件功能单元的形式实现。

本领域普通技术人员可以理解：实现上述方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成，前述的程序可以存储于一计算机可读取存储介质中，该程序在执行时，执行包括上述方法实施例的步骤；而前述的存储介质包括：移动存储设备、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。

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

以上所述，仅为本发明的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应以所述权利要求的保护范围为准。

Claims (10)

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

获得日志数据和解析规则；

按照解析规则，对日志数据进行处理；

发送处理后的日志数据；

其中，至少利用解析规则中的解析表达式对日志数据进行格式化处理，经格式化处理后的日志数据及所述日志数据的关联内容能够进行关联显示。

2.根据权利要求1所述的方法，其特征在于，所述至少按照解析规则中的解析表达式对日志数据进行格式化处理，包括：

按行读取日志数据，并利用所述解析表达式解析日志数据的以下至少一种内容：日志标识、日志的时间戳信息、日志的线程标识、日志等级、日志内容；

将所解析的内容进行存储。

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

将从同一日志数据中解析出的内容存储到相同的接口函数中。

4.根据权利要求1所述的方法，其特征在于，所述获得解析规则，包括：

接收解析规则；

所述解析规则包括至少两种解析表达式；

在利用解析规则中的其中一种解析表达式对日志数据进行格式化处理未成功时，使用所述至少两种解析表达式中的剩余至少一种解析表达式进行解析。

5.一种日志显示方法，其特征在于，所述方法包括：

接收查询操作；

响应查询操作，至少显示待查询日志数据的线程标识；所述日志数据至少为按照解析规则进行格式化处理后的数据；

基于线程标识，对待查询日志数据及待查询日志数据的关联内容进行关联显示。

6.根据权利要求5所述的方法，其特征在于，所述将对待查询日志数据及待查询日志数据的关联内容进行显示，至少包括：

按照日志数据的时间戳，将对待查询日志数据及待查询日志数据的关联内容进行关联显示。

7.根据权利要求5所述的方法，其特征在于，所述将对待查询日志数据及待查询日志数据的关联内容进行显示，至少包括：

按照日志数据的时间戳和累加标识，将对待查询日志数据及待查询日志数据的关联内容进行关联显示；其中，所述累加标识至少用于对具有相同时间戳的日志数据进行的顺序标识。

8.一种日志处理装置，其特征在于，所述装置包括：

获取单元，用于获得日志数据和解析规则；

处理单元，用于按照解析规则，对日志数据进行处理；

传输单元，用于发送处理后的日志数据。

9.一种日志显示装置，其特征在于，所述装置包括：

传输单元，用于接收查询操作；

响应单元，用于响应查询操作，至少显示待查询日志数据的线程标识；所述日志数据至少为按照解析规则进行格式化处理后的数据；

显示单元，用于基于线程标识，对待查询日志数据及待查询日志数据的关联内容进行关联显示。

10.一种日志系统，其特征在于，至少包括权利要求8所述的日志处理装置和权利要求9所述的日志显示装置。