一种日志服务系统及日志处理方法

技术领域

本说明书涉及日志服务技术领域，尤其涉及一种日志服务系统及日志处理方法。

背景技术

在路由器、交换机等网络设备中，系统日志记录系统中任何时间发生的大小事件，管理者可以通过查看系统记录，随时掌握系统状况。

相关技术中，网络设备可以将日志信息以用户数据协议方式传送到远端服务器。然而在高可用架构中，日志量会随着业务增长而增加，当业务达到一定规模，架构变得复杂，日志也会更加混乱，查看指定日志将会变得低效。因此，需要一种能够高效处理大量日志的日志服务系统和日志管理方法。

发明内容

有鉴于此，本申请提供一种日志服务系统及日志处理方法，以解决相关技术中存在的缺陷，本申请技术方案如下：

根据本申请第一方面的实施例，提供一种日志服务系统，包括：

收集模块，用于通过所述收集模块中包含的分布式收集组件接收网络设备发送的日志；

处理模块，用于获取收集模块收集的日志，将获取的日志提供至所述处理模块中包含的自定义组件，由所述自定义组件根据用户设置的个性化过滤规则对获取的日志进行过滤，生成结果日志集；

存储模块，用于获取所述结果日志集，通过所述存储模块中包含的分布式存储组件对所述结果日志集进行存储。

可选的，所述处理模块，还用于：

由所述自定义组件根据用户设置的个性化解析规则对所述收集模块收集的日志或者对所述结果日志集中包含的日志进行解析，得到用户指定格式的日志。

可选的，所述收集模块，还用于：通过所述收集模块中包含的分布式消息队列，将收集到的日志发送至所述处理模块。

可选的，所述收集模块，还用于：将收集到的日志存储至磁盘进行备份；

所述处理模块，还用于：在所述系统发生异常的情况下，从磁盘读取所述收集模块收集到的日志。

可选的，所述日志服务系统还包括：

搜索模块，响应于搜索客户端发出的请求，根据请求中携带的搜索条件，在所述存储模块储存的日志中确定符合所述搜索条件的日志并返回至所述搜索客户端。

可选的，所述存储模块，还用于：

基于预设分词规则，对结果日志集中的每条日志进行分词；

基于预设权重规则，对结果日志集中的每条日志计算权重值；

将每条日志及其对应的分词结果和权重值一并进行储存；

所述搜索模块，还用于：根据每条日志对应的分词结果和权重值，对符合用户搜索条件的日志进行排序。

可选的，所述日志服务系统还包括：

组织模块，用于获取符合用户搜索条件的日志，根据所述搜索客户端发出的请求中携带的展示方式，对获取的日志进行组织，并将组织后的日志返回至所述搜索客户端，以使所述搜索客户端按照所述展示方式进行展示。

可选的，所述分布式收集组件通过多个管道接收网络设备发送的日志，所述多个管道分别运行在独立的线程中。

可选的，所述分布式收集组件包括：Logstash、Flume，Filebeat；

所述分布式存储组件包括：Elasticsearch、Mysql、Oracle；

所述分布式消息队列包括：Kafka、ActiveMQ、RabbitMQ、RockerMQ。

根据本申请第二方面的实施例，提供一种日志处理方法，应用于日志服务系统，所述日志服务系统中包含分布式收集组件、自定义组件和分布式存储组件，所述方法包括：

通过所述分布式收集组件接收网络设备发送的日志；

由所述自定义组件根据用户自定义的个性化过滤规则对收集的日志进行过滤，生成结果日志集；

通过所述分布式存储组件对所述结果日志集进行存储。

在本申请提供的技术方案中，日志服务系统通过收集模块中的分布式收集组件，可以对网络架构中的多个不同的网络设备的日志进行收集，使处理模块中的自定义组件可以对收集起来的不同数据源的日志进行统一的过滤处理。由于自定义组件中应用的过滤规则是由用户根据需求进行设置的个性化过滤规则，经过处理可以过滤掉对于用户而言的无用日志，精简了日志信息，进一步使得存储模块中的分布式存储组件只存储符合用户所需要的日志，节省了存储所需的资源，也提高了用户在后续工作中对日志的查询效率，提升了用户体验。同时，分布式收集组件和分布式存储组件可以随着架构规模的增加进行水平扩展，能够支持大量日志的收集和存储工作，保证了日志服务系统的性能。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本说明书实施例。

附图说明

为了更清楚地说明本说明书实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本说明书实施例中记载的一些实施例，对于本领域普通技术人员来讲，还可以根据这些附图获得其他的附图。

图1是本说明书一示例性实施例示出的一种日志服务系统模块示意图；

图2是本说明书一示例性实施例示出的一种日志服务系统的日志处理流程图；

图3是本说明书一示例性实施例示出的一种日志处理方法的流程图；

图4是本说明书一示例性实施例示出的一种日志处理装置的示意图；

图5是本说明书一示例性实施例示出的一种电子设备的示意图。

具体实施方式

这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本说明书相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本说明书的一些方面相一致的装置和方法的例子。

在本说明书使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本说明书。在本说明书和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。

应当理解，尽管在本说明书可能采用术语第一、第二、第三等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本说明书范围的情况下，第一信息也可以被称为第二信息，类似地，第二信息也可以被称为第一信息。取决于语境，如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。

系统日志是记录系统中硬件、软件和系统问题的信息，例如网络设备、系统及服务程序等，在运作时都会产生一个叫log的事件记录，其中包括多行日志，每一行日志都记载着日期、时间、使用者及动作等相关操作的描述，可以监视系统中发生的事件。用户可以通过系统日志来查看系统记录，随时掌握系统状况，例如检查错误发生的原因，或者寻找受到攻击时攻击者留下的痕迹。

目前，Syslog即是一种可以用来记录网络设备的日志的工业标准的协议，它几乎被所有的网络设备支持，并且能够记录多种事件类型的日志消息。支持Syslog的设备常见的有路由器、交换机、打印机等等，甚至UNIX系统服务器也可以支持产生Syslog消息，用以记录用户的登录、防火墙事件、Apache或者Nginx Access日志等。

当今网络设备普遍支持Syslog协议，即系统日志协议，几乎所有的网络设备都可以通过系统日志协议，将日志信息以用户数据协议方式传送到远端服务器。同时，目前也存在一些系统日志服务器，如Syslogd、Rsyslogd、Syslog-ng、Kiwisyslog等服务器，能够对网络设备中的系统日志进行简单的收集。

然而在高可用架构中，单点模式往往是系统高可用最大的风险，应该尽量在系统设计的过程中避免单点模式。因此，为了保证系统高可用，架构设计应该遵从冗余的准测，但是这也同时导致高可用架构中的日志通常分散在架构中的多节点上，日志量会随着业务的增长而增加，当业务达到一定规模，架构变得复杂，日志也会更加混乱，日志数量十分庞大。在这种情况下，普通的系统日志服务器无法承担负载，导致性能下降甚至崩溃，同时在收集到的海量的日志信息中，查看指定日志的效率会大幅降低。

为了解决上述问题，本申请提出一种日志服务系统，系统中的收集模块中包含分布式收集组件、存储模块中包含分布式存储组件，可以收集、储存网络架构中产生的大量日志，并能够随着架构规模的增加进行水平扩展，保证了日志服务系统的性能；同时采用自定义组件对收集的日志进行个性化过滤处理，只保留并储存用户所需的日志，节省了存储所需的资源，也提高了用户在后续工作中对日志的查询效率，提升了用户体验。接下来对本申请实施例进行详细说明。

图1是本申请根据一示例性实施例示出的一种日志服务系统的示意图，可以包括：

收集模块11，用于通过所述收集模块中包含的分布式收集组件接收网络设备发送的日志；

处理模块12，用于获取收集模块收集的日志，将获取的日志提供至所述处理模块中包含的自定义组件，由所述自定义组件根据用户设置的个性化过滤规则对获取的日志进行过滤，生成结果日志集；

存储模块13，用于获取所述结果日志集，通过所述存储模块中包含的分布式存储组件对所述结果日志集进行存储。

为了对本申请日志服务系统进行详细说明，接下来将配合图2，介绍一种示例性的日志处理流程。

在一示例性实施例中，日志服务系统布置于一个或多个服务器上，在服务器的指定端口上，通过收集模块11中包含的分布式收集组件接收来自不同网络设备中传输过来的系统日志。在收集方式的选择上，架构中的各网络设备可以将日志主动推送到日志服务系统，也可以由收集模块11对日志进行统一采集。本申请中的网络设备是连接到网络中的物理实体，其种类繁多，例如可以是路由器、交换机、打印机等，也可以是其他服务器，如电商平台、数据监控服务器等，本申请并不对此进行限制。

在整体架构比较简单的情况下，如需要监测活动的网络设备较少、收集的日志数量较少，可以将收集模块11中的分布式收集组件布置在单个服务器或者服务节点上，此时一个服务器或者服务节点即可支撑整个架构的日志收集工作，可以节省服务器成本。而在整体架构比较复杂的情况下，如需要监测活动的网络设备较多，或者架构中业务数量增加、业务复杂度上升，使得收集的日志数量大幅上升，可以将收集模块11中的分布式收集组件扩展到多个服务器或者多个服务节点中进行工作，即水平扩展集群，分散了现有服务的压力，能够支持大量日志的收集工作，同时在扩展时也不会对现有服务器或者服务节点中的分布式收集组件的工作造成影响，进一步提高了日志收集效率。此处，可以选用Logstash、Flume，Filebeat作为分布式收集组件，也可选用其他支持分布式的收集组件，本申请不对此进行限制。

在一示例性实施例中，收集模块11中还包括分布式消息队列，将收集到的日志发送到处理模块12。一方面，分布式消息队列能够接收分布式收集组件收集的大量日志，由于其具有分布式的特性，可以进行水平扩展，使得系统能够应对更高的负载和更大的数据量，同时在集群中某些节点出现故障时，其他节点也能够继续支持工作，不会影响到整个系统，拥有更好的容错性。另一方面，分布式消息队列可以作为缓冲区，由于其采用基于异步通信的消息传递机制，能够在不同的程序之间异步通信，使得发送者和接收者之间不必在同一时刻进行日志数据传输，从而降低了组件之间的耦合性，提高了组件弹性，在收集的日志量忽然激增的情况下，分布式消息队列可以起到很好的缓冲作用。需要说明的是，图2所示流程中包含的分布式消息队列是一可选组件。此处，可以选用Kafka、ActiveMQ、RabbitMQ、RockerMQ作为分布式消息队列，也可选用其他消息队列框架，或是用简单的队列结构进行消息处理，本申请不对此进行限制。

在一示例性实施例中，处理模块12获取收集模块11收集到的日志，提供给处理模块12内的自定义组件。自定义组件中包含根据用户要求设置的个性化过滤规则，通过该规则对收集到的日志进行过滤，将过滤后得到的日志作为结果日志，生成结果日志集。此处的用户是指日志服务系统的使用者，即需要对网络设备发送的日志进行查看、搜索或分析等一系列操作的人，此处的自定义组件为针对用户需求定制化开发的组件。在开发该自定义组件时，可以遵循分布式组件标准，以便在后续使用中根据实际需要进行水平扩展，应用至多个服务器或者服务节点。个性化过滤规则可以在自定义组件开发时一并确定，直接写入自定义组件的逻辑代码当中，也可以不写入逻辑代码，而是在自定义组件中预留接口，通过接口对过滤规则进行设置和更改。以此方式，能够更加灵活地更改个性化过滤规则，在用户的过滤需求改变时也能够简便地进行调整。

在一示例性实施例中，过滤条件可以包括日志各个维度的信息，例如日志的时间、来源、关键字、格式等等。例如，在一架构中包括A、B、C、D四个网络设备，每个网络设备运行自己的业务并产生相应的日志，如子系统初始化记录、请求执行记录等，收集模块11中包含的分布式收集组件会收集四个设备中产生的所有日志。假如用户在该架构中只需要关注网络设备A和C中关于警告、报错的日志信息，那么可以将过滤条件设置为：时间[不限]；来源[A、C]，关键字[Warning、Error]，格式[不限]。自定义组件以此过滤规则对收集到的日志进行过滤，将得到所有时间内，来自网络设备A和C的、有关警告和报错的所有日志。因为网络设备A、D的所有日志及网络设备A、C中的其他日志对于用户而言都是无用日志，用户不需要关注这些日志信息，也不需要进行存储。将过滤后得到的日志作为结果日志，生成结果日志集将过滤后保留下的日志作为结果日志，生成结果日志集，结果日志集中的所有日志即是用户所需要的所有日志。

需要说明的是，在实际使用过程中，被过滤掉的日志可以根据需要进行处理，例如，可以直接删除以节省存储空间，或者存储至普通磁盘保留一定时长，在超出保留期限后再进行删除，以便用户在根据日志排查问题时查看近期的其他日志的相关信息。本申请不限制对过滤掉的日志的具体处理方式。

在一示例性实施例中，处理模块12中的自定义组件还可以对日志进行解析。类似于上述个性化过滤规则，自定义组件中的个性化解析规则根据用户的要求进行设置。用户可以选择日志解析方法，如聚类、频繁项挖掘等，通过用户选择的解析方法，将日志解析为用户指定的格式，以便于提高后续工作的处理效率。此处，图2所示流程中包含的通过自定义组件进行日志解析是一可选步骤，进行解析的日志可以是由收集模块11收集到的日志，也可以是经过处理模块12处理后生成的结果日志集中的日志，并且可以是所述日志中的部分日志。例如，收集模块11收集到的日志中包含Debug、Info、Warning、Fatal等多种类型的日志，经过处理模块12的自定义组件过滤后，保留了Info、Warning、Fatal这三种类型的日志，其中，用户对Info类型的日志关注度较低且不常使用，只重点关注Fatal类型的日志并在需要后续工作中频繁查看、搜索，那么自定义组件即可对Fatal类型的这部分日志进行解析。假设用户选用了聚类的方法对日志进行解析，则可以通过计算日志文本间的相似度，将相似度高的Fatal日志聚合成一类，并提取它们的共同模式。具体来讲，可以先基于自然语言处理对日志进行特征提取，而后利用日志文本的相似度对日志聚类，挖掘日志模板，进而对不同网络设备中的Fatal类型日志进行格式上的统一。在聚类解析过程中，用户可以根据需求决定聚类的次数，聚类次数越多，模式的浓缩程度越高，例如原有5条来自不同网络设备的Fatal日志，首次聚类后得到2条日志格式，再次聚类后得到1条日志格式，即可作为最后的日志格式。同时，在每次进行下一次的聚类之前，用户也可以自行决定选择哪一条的日志格式来进行后期的分析，例如5条Fatal日志在首次聚类后得到2条日志格式，用户可以手动选择其中一条格式，使下次聚类时以该格式为准，以得到最后符合用户要求的格式的日志结果。通过日志解析，能够将原始日志统一至相同的格式，提高了后续搜索时的效率，也使得用户查看相关日志信息更加方便，利于用户开展后续的工作，提高了用户体验。

需要说明的是，此处个性化解析规则的设置方式也与上述个性化过滤规则相同，可以在自定义组件开发时一并确定，直接写入自定义组件的逻辑代码当中，也可以在自定义组件中预留接口，通过接口对解析规则进行设置和更改。以此方式，能够更加灵活地更改个性化解析规则，在用户的解析需求改变时也能够简便地进行调整。

在一示例性实施例中，存储模块13获取处理模块12生成的结果日志集，通过存储模块13内包含的分布式存储组件对结果日志集进行存储。类似于前述分布式收集组件，在整体架构比较简单的情况下，可以将存储模块13中的分布式存储组件布置在单个服务器或者服务节点上，以节省服务器成本；而在整体架构比较复杂的情况下，可以将存储模块13中的分布式存储组件扩展到多个服务器或者多个服务节点中进行工作，即水平扩展集群，分散了现有服务的压力，能够支持大量日志的存储工作，同时在扩展时也不会对现有服务器或者服务节点中的分布式存储组件的工作造成影响。

在实际使用中，分布式存储组件可以采用主副分片的方式对日志进行存储。此处可以选用Elasticsearch数据分析引擎作为分布式存储组件，也可选用其他支持分布式存储的组件，例如Mysql、Oracle或者文件方式存储等。例如，在使用Elasticsearch进行存储时，每个索引可以分为多个主分片，每个主分片都有若干个副本，即副分片。主分片负责数据的读写操作，副分片用于数据冗余和提高搜索性能。当某个主分片因各种原因失效时，分布式存储组件会自动从对应的副本分片中选取一个作为新的主分片，并且向其他节点广播这个信息。由于每个分片都是独立存储的，因此可以将分片分布到不同的节点，实现数据的水平扩展，当集群中部分服务器出现问题或者某个分片出现故障时，可以从其他分片读取数据，保证了日志数据的可用性，提高了日志服务系统的可靠性。

需要说明的是，分布式存储组件除了上述通过主副分片方式进行存储外，也可以包含其他功能，例如主节点(Master)选举、数据恢复，技术人员可以根据实际需要设置分布式存储组件的工作方式，本申请不限制分布式存储组件中具体的功能。

本申请实施例的日志服务系统，通过收集模块中包含分布式收集组件、存储模块中包含分布式存储组件，可以收集、储存网络架构中产生的大量日志，并能够随着架构规模的增加进行水平扩展，保证了负载需求和服务性能；同时采用自定义组件对收集的日志进行个性化处理，只保留并储存用户所需的日志，节省了存储所需的资源，也提高了用户在后续工作中对日志的查询效率，提升了用户体验。

在一示例性实施例中，收集模块11可以将收集到的日志存储至磁盘作为备份，在日志服务系统发生异常的情况下，处理模块12可以从磁盘中读取收集到的日志。在另一示例性实施例中，收集模块11可以等待系统恢复正常后，从磁盘读取收集到的日志，并正常发送至处理模块12。收集模块11将收集到的日志持久化到磁盘，并且在系统故障之后进行数据恢复的过程中保证日志数据的有序性。例如，日志服务系统在A时刻发生故障，于B时刻恢复，在系统的处理模块重新开始工作时，仍然优先处理A时刻之前收集到的日志。采用该方式，能够在提高日志服务系统的可靠性，同时能够在一定程度上保证日志数据被及时处理，避免对日志服务系统的后续工作造成影响。

在一示例性实施例中，收集模块11中的分布式收集组件通过管道对日志进行收集，多个管道独立运行在独立的线程中。在本申请的管道模式下，日志在收集过程中被并行处理，相比于单线程而言，多线程管道可以充分利用多核CPU(Central Processing Unit，中央处理器)的计算能力，提高处理速度。在需要对大量日志进行收集的情况下，使用管道并行收集日志可以显著减少收集时间。

在一示例性实施例中，本申请的日志服务系统还包括搜索模块14，能够响应于搜索客户端发出的请求，根据请求中携带的搜索条件，在所述存储模块储存的日志中确定符合所述搜索条件的日志并返回至所述搜索客户端。搜索客户端是用户使用的客户端，可以是具有图形化界面的平台，也可以是只有命令行形式服务器，本申请不限制搜索客户端的具体形式，能够支持用户发送搜索请求即可。用户可以通过搜索客户端向日志服务系统发送搜索请求，搜索请求中需要携带搜索条件，用于指示用户所期望的日志。搜索条件可以包括日志各个维度的信息，例如日志的时间、来源、包含的信息、关键字等，可以限制单一条件进行搜索，也可以通过组合条件进行搜索。例如，用户发送的搜索请求中的搜索条件为{date:2023-01-01}，那么搜索模块14将会在存储模块13存储的日志中查找日期为2023年1月1日的全部日志并返回；如果用户发送的搜索请求中的搜索条件为{date:2023-01-01；type:Error}，那么搜索模块14将会查找日期为2023年1月1日，且类型为Error的全部日志，并返回至搜索客户端。需要说明的是，图2所示流程中包含的搜索模块是一可选模块，技术人员可以根据需求决定是否使用。在本申请实施例的日志服务系统中，搜索模块14使得用户能够更加方便地使用日志服务系统，精确地得到用户所需要日志，并且搜索模块14配合存储模块13一同使用，进一步发挥了分布式存储组件的分布式特性，能够更加高效地查找日志，提升了用户体验。

在一示例性实施例中，存储模块13在日志存储之前，可以对日志进行分词，并计算权重值，将每条日志及其对应的分词结果和权重值一并进行储存，在搜索模块14根据搜索条件对日志进行搜索时，将根据每条日志对应的分词结果和权重值，对符合用户搜索条件的日志进行排序。分词时，将日志的文本数据拆分成一个个的单独的词项，并将词项标准化。分词规则可以根据用户的需要进行个性化设置，例如可以简单地按空格、逗号等字符进行分割，也可以基于正则表达式进行定制化分词。此外，在分词的同时可以对词项进行一些扩展，例如同义词扩展、大小写转换、停用词过滤等等，在存储时可以将原词项与原词项的扩展词项共同作为分词结果进行存储，以此可以更加精确地对日志文本进行搜索和分析。权重计算则主要考虑词项的重要性，用户可以根据实际使用时的需要，对词项的权重值进行设置，以重点突出其关注的词项，使得在搜索排序时能够将具有该词项、或者具有同义词项的日志信息排在更前面，方便用户更快地找到需要的日志，提高工作效率。

需要说明的是，除了在日志存储前进行分词、计算权重之外，在搜索模块14接收到搜索请求并确定了符合条件的日志时，也可以根据搜索条件来计算权重，对搜索结果进行排序，该方式与前述计算权重的方式并不矛盾。例如，某个架构因业务原因，需要重点关注与删除操作相关的日志信息，那么分布式存储组件在进行存储前会对日志进行分词，并为包含“remove”词项的日志设置一个较高的权重值，将分词结果与权重值和日志一并储存。假如搜索模块14接收到的搜索请求中的搜索条件为{content:“server A”}，指用户想要查看日志内容与服务A相关的日志，那么搜索模块14在对搜索结果进行排序时，会将“serverA”的权重值与“remove”的权重值综合计算，具体的评分函数可以根据需要进行配置，并根据最后的权重计算结果对日志排序。

需要说明的是，分词规则和权重规则预先设置在存储模块13中，在用户有特殊需求的情况下，可以根据用户要求对具体规则进行调整，本申请不限制具体的分词规则和权重计算规则。

在一示例性实施例中，本申请的日志服务系统还包括组织模块15，用于获取符合用户搜索条件的日志，根据所述搜索客户端发出的请求中携带的展示方式，对获取的日志进行组织，并将组织后的日志返回至所述搜索客户端，以使所述搜索客户端按照所述展示方式进行展示。搜索客户端的搜索请求中可以包含对于日志展示方式的描述，例如，可以选择信息列的展示项，也可以限制信息列的排布顺序，或者是用户所需要的其他展示方式等，组织模块15会根据搜索请求中的展示方式对搜索的结果日志进行组织，并将组织后的日志返回至搜索客户端，用户即可看到符合展示要求的日志搜索结果。需要说明的是，图2所示流程中包含的组织模块是一可选模块，技术人员可以根据需求决定是否使用。在本申请实施例的日志服务系统中，通过对日志的展示方式进行限制，用户可以更加快速地得到有效日志信息，提高了用户体验。

基于本申请提供的日志服务系统，本申请还提供了一种日志处理方法，应用于日志服务系统，所述日志服务系统中包含分布式收集组件、自定义组件和分布式存储组件。图3是本说明书一示例性实施例示出的一种日志处理方法的流程图，可以包括如下步骤：

S301：通过所述分布式收集组件接收网络设备发送的日志；

S302：由所述自定义组件根据用户自定义的个性化过滤规则对收集的日志进行过滤，生成结果日志集；

S303：通过所述分布式存储组件对所述结果日志集进行存储。

如前所述，日志处理方法还包括：

由所述自定义组件根据用户设置的个性化解析规则对收集的日志或者对所述结果日志集中包含的日志进行解析，得到用户指定格式的日志。

如前所述，所述日志服务系统中还包括分布式消息队列，日志处理方法还包括：通过所述分布式消息队列，将收集到的日志发送至所述自定义组件。

如前所述，日志处理方法还包括：

将收集到的日志存储至磁盘进行备份；

在所述系统发生异常的情况下，从磁盘读取收集到的日志。

如前所述，日志处理方法还包括：

响应于搜索客户端发出的请求，根据请求中携带的搜索条件，在所述分布式存储组件储存的日志中确定符合所述搜索条件的日志并返回至所述搜索客户端。

如前所述，日志处理方法还包括：

基于预设分词规则，对结果日志集中的每条日志进行分词；

基于预设权重规则，对结果日志集中的每条日志计算权重值；

将每条日志及其对应的分词结果和权重值一并进行储存；

在用户发出搜索请求的情况下，根据每条日志对应的分词结果和权重值，对符合用户搜索条件的日志进行排序。

如前所述，日志处理方法还包括：

获取符合用户搜索条件的日志，根据所述搜索客户端发出的请求中携带的展示方式，对获取的日志进行组织，并将组织后的日志返回至所述搜索客户端，以使所述搜索客户端按照所述展示方式进行展示。

如前所述，所述分布式收集组件通过多个管道接收网络设备发送的日志，所述多个管道分别运行在独立的线程中。

如前所述，所述分布式收集组件包括：Logstash、Flume，Filebeat；

所述分布式存储组件包括：Elasticsearch、Mysql、Oracle；

所述分布式消息队列包括：Kafka、ActiveMQ、RabbitMQ、RockerMQ。

对于日志处理方法实施例而言，图3所示的方法实施例的内在逻辑已在图1所对应的系统实施例中进行了介绍，其具体的实施方法可以参考前述实施例，此处不再赘述。

本申请还提供了一种日志处理装置，参见图4，包括：

收集单元41，被配置为通过分布式收集组件接收网络设备发送的日志；

处理单元42，被配置为由自定义组件根据用户自定义的个性化过滤规则对收集的日志进行过滤，生成结果日志集；

存储单元43，被配置为通过分布式存储组件对所述结果日志集进行存储。

可选的，所述日志处理装置还包括：

由所述自定义组件根据用户设置的个性化解析规则对收集的日志或者对所述结果日志集中包含的日志进行解析，得到用户指定格式的日志。

可选的，所述日志处理装置还包括：通过所述分布式消息队列，将收集到的日志发送至所述自定义组件。

可选的，所述日志处理装置还包括：

所述收集单元41，还被配置为：将收集到的日志存储至磁盘进行备份；

所述处理单元42，还被配置为：在所述系统发生异常的情况下，从磁盘读取收集到的日志。

可选的，所述日志处理装置还包括：

搜索单元44，被配置为响应于搜索客户端发出的请求，根据请求中携带的搜索条件，在所述分布式存储组件储存的日志中确定符合所述搜索条件的日志并返回至所述搜索客户端。

可选的，所述日志处理装置还包括：

所述存储单元43，还被配置为：

基于预设分词规则，对结果日志集中的每条日志进行分词；

基于预设权重规则，对结果日志集中的每条日志计算权重值；

将每条日志及其对应的分词结果和权重值一并进行储存；

所述搜索单元44，还被配置为：根据每条日志对应的分词结果和权重值，对符合用户搜索条件的日志进行排序。

可选的，所述日志处理装置还包括：

组织单元45，被配置为获取符合用户搜索条件的日志，根据所述搜索客户端发出的请求中携带的展示方式，对获取的日志进行组织，并将组织后的日志返回至所述搜索客户端，以使所述搜索客户端按照所述展示方式进行展示。

可选的，所述分布式收集组件通过多个管道接收网络设备发送的日志，所述多个管道分别运行在独立的线程中。

可选的，所述分布式收集组件包括：Logstash、Flume，Filebeat；

所述分布式存储组件包括：Elasticsearch、Mysql、Oracle；

所述分布式消息队列包括：Kafka、ActiveMQ、RabbitMQ、RockerMQ。

上述装置中各个单元的功能和作用的实现过程具体详见上述方法中对应步骤的实现过程，在此不再赘述。

对于装置实施例而言，由于其基本对应于方法实施例，所以相关之处参见方法实施例的部分说明即可。以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本申请方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

相应的，本申请还提供一种电子设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，处理器执行计算机程序时实现如上任一实施例所述的日志处理方法。

参考图5，在硬件层面，该电子设备包括处理器502、内部总线504、网络接口506、内存508以及非易失性存储器510，当然还可能包括其他业务所需要的硬件。处理器502从非易失性存储器510中读取对应的计算机程序到内存408中然后运行，在逻辑层面上形成上述日志处理方法的装置。当然，除了软件实现方式之外，本申请并不排除其他实现方式，比如逻辑器件抑或软硬件结合的方式等等，也就是说以下处理流程的执行主体并不限定于各个逻辑单元，也可以是硬件或逻辑器件。

相应的，本申请还提供一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现如上任一实施例所述的控制方法。

上述实施例阐明的系统、装置、模块或单元，具体可以由计算机芯片或实体实现，或者由具有某种功能的产品来实现。一种典型的实现设备为计算机，计算机的具体形式可以是个人计算机、膝上型计算机、蜂窝电话、相机电话、智能电话、个人数字助理、媒体播放器、导航设备、电子邮件收发设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的任意几种设备的组合。

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