CN107660283B

CN107660283B - 用于在日志分析系统中实现日志解析器的方法和系统

Info

Publication number: CN107660283B
Application number: CN201680029404.0A
Authority: CN
Inventors: G·M·法拉尔
Original assignee: Oracle International Corp
Current assignee: Oracle International Corp
Priority date: 2015-04-03
Filing date: 2016-04-01
Publication date: 2021-12-28
Anticipated expiration: 2036-04-01
Also published as: US10592521B2; CN114153701A; US10891297B2; US9767171B2; US20180004824A1; US20160292166A1; US20170004185A1; US10366096B2; EP3278243A1; US20190243827A1; US20160378577A1; US11194828B2; US9940373B2; US10585908B2; US20200097466A1; US20160292263A1; CN114153702A; CN114168418A; CN107660283A; US20160294649A1

Abstract

公开了用于实现日志分析方法和系统的系统、方法和计算机程序产品，该日志分析方法和系统可以以高效的方式来配置、收集和分析日志记录。已经描述了通过分析日志的行内容来自动生成日志解析器的改进方法。此外，已经描述了从日志内容中提取键‑值内容的高效方法。

Description

用于在日志分析系统中实现日志解析器的方法和系统

背景技术

许多类型的计算系统和应用生成与该计算系统或应用的操作相关或由该计算系统或应用的操作引起的大量数据。这些大量数据被存储到诸如日志文件/记录之类的收集的位置中，如果需要分析系统或应用的行为或操作，则这些收集的位置可以在稍后的时间段被审查。

服务器管理员和应用管理员可以通过学习和分析系统日志记录的内容来获益。但是，收集和分析这些记录会是非常有挑战性的任务。这些挑战有很多原因。

一个显著的问题涉及以下事实：许多现代组织拥有非常大量的计算系统，每个计算系统具有在这些计算系统上运行的大量应用。考虑到在这些计算设备上运行的大量相异的(disparate)系统和应用，在大型系统中配置、收集和分析日志记录会非常困难。此外，这些应用中的一些应用可以实际上在多个计算系统上运行以及跨多个计算系统运行，从而使得协调日志配置和收集的任务更加成问题。

常规的日志分析工具提供收集和分析日志记录的基本能力。但是，当面临大型系统包括具有在这些系统上运行的大量应用的大量计算系统的问题时，常规系统不能高效地缩放。这是因为常规系统常常以每台主机为基础进行工作，其中每当在系统中添加或新配置新的主机时，都需要执行设置和配置活动，或者甚至需要针对现有的主机执行新的日志收集/配置活动。考虑到现代系统中存在大量的主机，这种方法非常低效。此外，常规方法(特别是本地(on-premise)解决方案) 也不能充分地允许共享资源和分析部件。这造成大量且过量的冗余处理和资源使用。

常规的日志分析工具在涉及由日志分析工具使用的日志解析器的构建时也是非常低效的。日志解析器是理解如何解析日志内的条目的工具。常规地，日志解析器必须由必须既熟知待分析的日志文件的确切格式又熟练掌握将用来实现解析器的具体编程基础设施的人来手动构建。

手动构建日志解析器的常规方法的一个问题是这个过程需要来自熟练技术人员的大量时间和资源以构建解析器。此外，这种方法还需要过多的手动资源以在日志文件的格式发生改变的情况下维护解析器。此外，这种手动方法必然需要对日志文件格式的先验知识。

因此，需要改进的方法来实现日志分析系统。还需要提供更高效的方式来实现用于日志分析系统的日志解析器。

发明内容

本发明的一些实施例通过提供自动构建日志解析器的方法来解决上述问题。作为需要人来手动创建日志解析器的内容的替代，日志内容本身被用来构建解析器。

根据一些实施例，提供了方法、系统或计算机可读介质，该方法、系统或计算机可读介质通过以下操作来构建日志解析器：识别要分析的日志，创建将日志的内容映射到用于日志内的一个或多个数据部分的识别出的元素类型的映射结构，从日志中选择数据部分，相对于映射结构分析该数据部分以识别可变部分和不可变部分，对于可变部分中的至少一个可变部分将该至少一个可变部分指派给涵盖在该至少一个可变部分中检测到的值的可变性的限制最少的数据类型，以及自动生成用于日志解析器的正则表达式。正则表达式在一些实施例中可以包括不可变部分以及用于可变部分的占位符，以实现日志解析器，其中至少两个不同的占位符与不同的数据类型相关联。

在一些实施例中，用于识别可变部分和不可变部分的发明性方法可以通过以下操作来执行：从日志中识别行以对照映射结构进行比较，从该行的开头开始并且向前移动直到识别出不匹配为止，找到下一个公共字符，将中间范围标记为可变的，并且循环直到达到行的末尾。

在映射结构内，元素类型可以包括字符串类型、整数类型、字母字符类型或字段规则类型中的至少一个，其中字段规则类型与由规则定义的元素序列对应。

多个行被分组在一起，作为用于针对映射结构进行分析的单个条目。在可替代方案中，多个行的内容可以被操纵成单个行。

可以通过以下操作来识别用于日志内的分析范围的定界符：识别日志的两个行内的公共元素，对公共元素进行评分，对公共元素进行评分通过考虑公共元素的位置结合一个或多个加权因子来进行，以及基于评分结果来选择一个公共元素作为定界符。在一些情况下，加权因子可以包括与多个元素的组合对应的规则。此外，可以为公共元素的位置计算总和或平均值。

可以通过以下操作来从日志中提取键字段和值字段：由识别第一键值分隔符以及迭代地识别行内的键值对分隔符来识别用于评估一个或多个键值对的范围，并且迭代地遍历该行以从键值分隔符的实例的左侧提取键字段并且从键值分隔符的实例的右侧提取值字段。可以对日志应用预处理，以对日志的字段和值部分进行分类。除了预处理之外或作为预处理的代替，可以应用后处理，以校正内容向键字段或值字段的有问题的指派。

根据一些实施例，日志解析器在被实施为基于云的体系架构和/ 或基于SaaS(软件即服务)的体系架构的日志分析系统中被采用。由日志分析系统处理的原始日志数据可以源自任何日志产生源，诸如数据库管理系统(DBMS)、数据库应用(DB App)、中间件、操作系统、硬件部件或任何其它日志产生应用、部件或系统。日志监视可以使用配置机制来配置，该配置机制包括用户可操作的UI控件以便为日志收集配置选择和配置日志收集配置和目标表示。日志收集配置包括信息集合(例如，日志规则、日志源信息和日志类型信息)，该信息集合识别要收集什么数据(例如，哪些日志文件)、要收集的数据的位置(例如，目录位置)、如何访问数据(例如，日志的格式和/或日志内要获取的具体字段)、和/或何时收集数据(例如，定期)。目标表示识别“目标”，“目标”是包含日志和/或产生日志的单独的部件。这些目标与客户环境中的具体部件/主机相关联。当前实施例通过将目标与日志规则和/或日志源相关联来配置日志收集/ 监视的能力为本发明提供了独特的优点。这是因为配置日志监视的用户不需要具体地确切了解用于给定应用的日志如何跨环境内的不同主机和部件而定位或分布。代替地，用户仅需要选择要对其进行监视的具体目标(例如，应用)，以及然后配置要在其下执行日志收集过程的具体参数。

在具体实施方式、附图和权利要求中描述本发明的其它附加目的、特征和优点。

附图说明

下面参考附图描述各种实施例。应当指出，附图不是按比例绘制的，并且贯穿整个附图，具有相似结构或功能的元件由相似的附图标记表示。还应当指出，附图仅旨在便于对实施例的描述。它们不旨在作为对本发明的详尽描述或作为对本发明的范围的限制。

图1A示出了在本发明的一些实施例中可以被采用的示例系统。

图1B示出了在本发明的一些实施例中可以被采用的方法的流程图。

图2示出了报告UI。

图3A-图3C提供了日志分析系统的内部结构以及客户环境内的与日志分析系统交互的部件的较详细图示。

图4A-图4C示出了实现日志收集配置的方法。

图5示出了通过将日志规则与目标相关联来实现日志收集配置的方法的流程图。

图6示出了通过将日志源与目标相关联来实现日志收集配置的方法的流程图。

图7示出了实现用于日志监视的基于目标的配置的方法的流程图。

图8示出了根据本发明的一些实施例的、实现用于日志监视的基于目标的配置的方法的较详细的流程图。

图9示出了根据本发明的一些实施例的示例XML配置内容。

图10示出了将被包括在配置文件中以促进日志解析的服务器侧信息。

图11示出了实现本发明的一些实施例的这个方面的一种可能方法的流程图。

图12示出了用于实现将日志分析规则与可变位置相关联的发明性方法的一些实施例的体系架构。

图13示出了跨所有日志条目不一致的附加数据的提取。

图14示出了一些示例字段定义。

图15示出了根据本发明的一些实施例的、实现日志解析器的方法的高级流程图。

图16示出了根据一些实施例的、实现日志解析器的方法的较详细的流程图。

图17-1至图17-21提供了构建日志解析器的过程的图示。

图18示出了解决非标准行格式的实施例的过程流程。

图19示出了对行内容的操纵或分类。

图20示出了根据本发明的一些实施例的、用于高效识别日志内容集合内的正确定界符元素的方法的流程图。

图21-1至图21-5示出了定界符识别过程。

图22示出了在本发明的一些应用中可以应用于公共元素的一些示例权重。

图23示出了执行键值提取的示例方法的流程图。

图24-1至图24-12示出了键值提取过程。

图25-1至图25-2和图26-1至图26-2示出了示例行配置。

图27示出了本发明可以利用其被实现的示例计算系统的体系架构。

具体实施方式

如上面所指出的，许多类型的计算系统和应用生成与该计算系统或应用的操作相关或由该计算系统或应用的操作引起的大量数据。然后这些大量数据被存储到诸如日志文件/记录之类的收集的位置中，如果需要分析系统或应用的行为或操作，则这些收集的位置可以在稍后的时间段被审查。

本发明的一些实施例提供了一种自动构建日志解析器的方法。作为需要人来手动创建日志解析器的内容的替代，日志内容本身被用来构建解析器。在具体实施方式、附图和权利要求中描述本发明的其它附加目的、特征和优点。

虽然下面的描述可以关于“日志”数据通过说明的方式来描述本发明，但是本发明的范围不限于对日志数据的分析，并且实际上本发明可以应用到范围广泛的数据类型。因此，本发明的应用不限于日志数据，除非是如此具体要求保护的。此外，以下描述还可以可互换地将被处理的数据称为“记录”或“消息”，而不旨在将本发明的范围限制到数据的任何特定格式。

日志分析系统

本公开的这部分提供了对用于实现大量日志收集和分析的方法和系统的描述，该方法和系统可以与如下文描述而被构建的日志解析器结合使用。

图1A示出了根据本发明的一些实施例的用于配置、收集和分析日志数据的示例系统100。系统100包括日志分析系统101，日志分析系统101在一些实施例中被实施为基于云的体系架构和/或基于 SaaS(软件即服务)体系架构。这意味着日志分析系统101能够作为被托管平台上的服务来提供日志分析功能，以使得需要该服务的每个客户不需要在客户自己的网络上单独安装和配置服务部件。日志分析系统101能够将日志分析服务提供给多个单独的客户，并且可以被缩放以便为任何数量的客户服务。

每个客户网络104可以包括任何数量的主机109。主机109是客户网络104内的生成作为一个或多个日志文件的日志数据的计算平台。在主机109内产生的原始日志数据可以源自任何产生日志的源。例如，原始日志数据可以源自数据库管理系统(DBMS)、数据库应用 (DB App)、中间件、操作系统、硬件部件或任何其它日志生成应用、部件或系统。在每个客户网络中提供一个或多个网关108，以与日志分析系统101通信。

系统100可以包括位于一个或多个用户站103的一个或多个用户，该一个或多个用户使用系统100来操作日志分析系统101并与日志分析系统101进行交互。用户站包括可被用于操作系统100中的日志分析系统101或与日志分析系统101对接的任何类型的计算站。这种用户站的示例包括例如工作站、个人计算机、移动设备或远程计算终端。用户站包括用于向位于用户站的用户显示用户界面的显示设备，诸如显示器监视器。用户站还包括让用户提供对系统100的活动的操作控制的一个或多个输入设备，诸如，用于操纵图形用户界面中的定点对象以生成用户输入的鼠标或键盘。在一些实施例中，用户站103可以(但不需要)位于客户网络104内。

日志分析系统101包括用户站101处的用户可访问的功能，例如，其中日志分析系统101被实现为引擎、机制和/或模块(无论是硬件、软件还是硬件和软件的混合)的集合，以执行日志数据的配置、收集和分析。用户界面(UI)机制生成UI，以显示分类和分析结果，并且以允许用户与日志分析系统交互。

图1B示出了使用系统100来配置、收集和分析日志数据的方法的流程图。图1B的这种讨论将参考针对图1A中的系统100所示的部件。

在120处，在系统内配置日志监视。这可以例如由用户/客户进行，以配置用户/客户期望的日志监视/数据搜集的类型。在系统101 内，包括UI控件的配置机制129可由用户操作，以选择和配置用于日志收集配置的日志收集配置111和目标表示113。

如下面更详细地讨论的，日志收集配置111包括信息集合(例如，日志规则、日志源信息和日志类型信息)，该信息集合识别要收集什么数据(例如，哪些日志文件)、要收集的数据的位置(例如，目录位置)、如何访问数据(例如，日志的格式和/或日志内要获取的具体字段)、和/或何时收集数据(例如，定期)。日志收集配置111 可以包括由服务提供商包括的开箱即用规则。日志收集配置111还可以包括客户定义的/客户定制的规则。

目标表示113识别“目标”，“目标”是客户环境内的包含日志和/或产生日志的单独的部件。这些目标与客户环境中的具体部件/主机相关联。示例目标可以是具体的数据库应用，该具体的数据库应用与一个或多个日志一个或多个主机相关联。

当前实施例通过将目标与日志规则和/或日志源相关联来配置日志收集/监视的能力为本发明提供了独特的优点。这是因为配置日志监视的用户不需要具体地确切了解用于给定应用的日志如何跨环境内的不同主机和部件定位或分布。代替地，用户仅需要选择要对其进行监视的具体目标(例如，应用)，以及然后配置要在其下执行日志收集过程的具体参数。

这解决了需要以每个主机为基础来配置日志监视的常规系统的显著问题，其中，每当在系统中添加或新配置新的主机时，都需要执行设置和配置活动，或者甚至需要针对现有的主机执行新的日志收集/ 配置活动。与常规方法不同的是，日志分析用户可以与和用于给定目标的日志相关的确切主机/部件的细节隔离。这种信息可以封装在由系统管理员维护的底层元数据中，系统管理员了解系统中的应用、主机和部件之间的对应关系。

122处的下一个动作是根据用户配置来捕获日志数据。日志规则 111和目标表示之间的关联被发送到客户网络104以进行处理。日志分析系统的代理存在于主机109中的每个主机上，以从主机109上的适当日志收集数据。

在一些实施例中，可以对捕获的数据执行数据遮蔽(masking)。遮蔽是在收集时执行的，它在客户数据离开客户网络之前保护客户数据。例如，收集到的日志数据中的各种类型的信息(诸如用户名和其它个人信息)可能足够敏感以至于在这些信息被发送到服务器之前要被遮蔽。为这种数据识别模式，在为服务器收集这种数据之前，可以将其移除和/或改为代理数据。这允许数据仍然用于分析目的，同时隐藏敏感数据。一些实施例永久地移除敏感数据(例如，将所有此类数据都改为“***”符号)，或者改为被映射为使得可以恢复原始数据的数据。

在124处，将收集到的日志数据从客户网络104递送到日志分析系统101。客户网络104中的多个主机109将收集到的数据提供给一个或多个网关108中的较少数量的网关，然后这些较少数量的网关将日志数据发送到日志分析系统101处的边缘服务106。边缘服务106 接收从一个或多个客户网络收集的数据，并将数据放到入站 (inbound)数据存储库中，以供日志处理流水线107进一步处理。

在126处，日志处理流水线107对所收集的日志数据执行一系列数据处理和分析操作，这将在下面更详细地描述。在128处，经处理的数据然后被存储到数据存储设备110中。计算机可读存储设备110 包括允许迅速(ready)访问位于计算机可读存储设备110处的数据的硬件和软件的任意组合。例如，计算机可读存储设备110可以被实现为由操作系统可操作地管理的计算机存储器。计算机可读存储设备 110中的数据还可以被实现为数据库对象、云对象和/或文件系统中的文件。在一些实施例中，经处理的数据被存储在文本/加索引的数据存储库110a(例如，作为SOLR集群)和原始/历史数据存储库110b (例如，作为HDFS集群)两者内。

在130处，可以使用报告机制/UI 115对经处理的数据执行报告。如图2中所示，报告UI 200可以包括日志搜索设施202、一个或多个控制面板204、和/或用于分析/查看经处理的日志数据的任何合适的应用206。下面将更详细地描述这种报告部件的示例。

在132处，可以对经处理的数据执行事件管理。可以在日志分析系统内配置一个或多个警报条件，使得在检测到警报条件时，事件管理机制117向指定的用户集合提供事件/警报的通知。

在134处，校正动作引擎119可以执行在客户网络104内要采取的任何必要的动作。例如，可以接收到数据库系统停机的日志条目。当识别出这种日志条目时，可能的自动化校正动作是尝试使数据库系统恢复工作。客户可以创建校正动作脚本，以解决这种情况。触发器可以被执行，以运行脚本来执行校正动作(例如，触发器使得指令被发送到客户网络上的代理，以运行脚本)。在可替代实施例中，针对该情况的适当脚本从服务器被下推到客户网络以被执行。此外，在 136处，可以至少基于经处理的数据来适当地采取任何其它附加功能和/或动作。

图3A提供了在主机环境340处的日志分析系统的内部结构以及与日志分析系统交互的客户环境342内的部件的较详细的图示。这种体系架构300被配置为提供能够处理大量日志数据摘要(digest)的用于日志监视的流程。

在单个客户主机/服务器344内的客户环境342中，LA(日志分析)代理333取得日志监视配置数据332(例如，嗅探器配置或目标侧配置资料)，并且调用日志文件336嗅探器(在本文中也被称为 “日志收集器”)以从一个或多个日志文件338搜集日志数据。守护进程管理器334可以被用来与日志文件嗅探器336对接。日志文件嗅探器336从主机机器344上的一个或多个日志文件338读取。守护进程管理器334取得日志内容并将该日志内容打包，以便它可以被交还给LA代理333。要注意的是，系统可以包括任何数量的不同类型的嗅探器，并且日志嗅探器336仅仅是可以在系统中被使用的单个类型的嗅探器的示例。因此，可以在本发明的各种实施例内采用其它类型的嗅探器，例如用于监视注册表、数据库、窗口事件日志等的嗅探器。此外，在一些实施例中，日志嗅探器被配置为处理集合文件/压缩文件，例如Zip文件。

LA代理333将搜集的日志数据发送到网关代理330。网关代理 330将从多个客户主机/服务器收集的日志数据打包，从而本质上充当聚合来自多个主机的日志内容的聚合器。然后打包的内容从网关代理 330被发送到边缘服务306。边缘服务306从来自任何数量的不同客户环境342的多个网关代理330接收大量数据。

考虑到可以在边缘服务306处接收的潜在大量数据，数据被立即存储到入站数据存储设备304(“平台入站存储库”)中。这充当日志处理流水线308的队列。提供数据结构以管理要在入站数据存储库内处理的项。在一些实施例中，(例如，使用Kafka产品实现的)消息传送平台302可以被用来跟踪队列内的待处理项。在日志处理流水线308内，队列消费者310识别队列内要处理的下一个项，然后该下一个项从平台入站存储库中被检索。队列消费者310包括能够处理系统内离开队列的工作的任何实体，诸如进程、线程、节点或任务。

检索出的日志数据经历“解析”阶段312，在“解析”阶段312 中日志条目被解析并且被分解成具体的字段。如下面更详细地讨论的，为日志配置的“日志类型”指定如何将日志条目分解成期望的字段。

在“规格化”阶段314中，识别出的字段被规格化。例如，“时间”字段在不同日志中可以以任何数量的不同方式表示。该时间字段可以被规格化为单个可识别的格式(例如，UTC格式)。作为另一个示例，在不同的系统中，“error”这个词可以以不同的方式表示 (例如，全部大写“ERROR”、全部小写“error”、首字母大写 “Error”或缩写“err”)。这种情况可能需要将不同的单词形式/ 类型规格化为单一格式(例如，全部小写的非缩写术语“error”)。

“变换”阶段316可以被用来从日志数据中合成新的内容。作为示例，并且将在下面更详细地讨论，“标签”可以被添加到日志数据，以提供关于日志条目的附加信息。作为另一个示例，可以执行字段提取，以从现有日志条目字段中提取附加字段。

“条件评估”阶段318被用来针对指定条件对日志数据进行评估。可以执行这个阶段，以识别日志数据内的模式，以及在日志内创建/ 识别警报条件。在这个阶段可以执行任何类型的通知，包括例如发送给管理员/客户的电子邮件/文本消息/呼叫或者发送给另一个系统或机制的警告。

日志写入器320然后将经处理的日志数据写入一个或多个数据存储库324。在一些实施例中，经处理的数据被存储在文本/加索引的数据存储库(例如，作为SOLR集群)以及原始和/或历史数据存储库 (例如，作为HDFS集群)二者内。日志写入器还可以将日志数据发送到另一个处理阶段322和/或下游处理引擎。

如图3B中所示，一些实施例提供侧加载机制350，以在不通过客户端侧的代理333继续的情况下收集日志数据。在这种方法中，用户登录到服务器中，以选择本地系统上的一个或多个文件。系统将在服务器处加载该文件，并且(例如，通过让用户提供日志类型、尝试可能的日志类型、滚动通过(roll through)不同的日志类型，或者通过对日志类型进行受教育的“猜测”)对该文件进行嗅探。嗅探结果然后被传递到边缘服务和如前所述的过程。在图3C的实施例中，仅侧加载机制350存在，以收集日志文件–其中代理/嗅探器实体在客户端服务器344上未被安装和/或不需要。

图4A-图4B示出了实现日志收集配置的方法。这种方法允许对如何监视具有一个或多个日志条目的日志文件进行非常大规模的配置。在一些实施例中，日志条目与来自日志文件的单个逻辑行对应。在实际的日志文件中，由于回车是日志条目内容的一部分，因此单个条目可以占用多个行。这整个内容被认为是单个“条目”。每个条目以 “####<date”开头，并且可以在文件中占用单个物理行或者由回车分隔的多个行。

在这个模型中，“日志类型”406定义系统如何读取日志文件，以及如何将日志文件分解成其部分。在一些实施例中，日志文件包含若干基本字段。对于不同类型的日志，存在的基本字段可以有所不同。可以使用“基本解析器”将日志条目分解成指定的字段。基本解析器还可以执行变换。例如，可以将日期字段转换成规格化的格式以及将时间调整为UTC，以便来自多个位置的数据可以被混合在一起。

“日志源”404定义日志文件位于何处以及如何读取它们。在一些实施例中，日志源是命名的定义，该命名的定义包含使用模式描述的日志文件的列表以及解析该文件所需的解析器。例如，一个源可以是“SSH日志文件”。这个源可以分别列出与SSH相关的每个日志文件，或者可以使用通配符(例如，“/var/log/ssh*”)来描述日志文件。对于每个模式，可以(例如，由用户)选择基本解析器来从文件中解析基本字段。这种方法可以被用来确保对于单个模式，所有文件都符合相同的基本解析结构。对于一个源，可以从多种日志类型中进行选择，并且对那些可能的类型给予优先权。例如，可以识别出类型A、B和C，其中分析遍历(work through)这些类型中的每一个类型，以便确定源是否与这些识别出的类型之一相匹配。因此，对于每个模式，用户可以选择多个基本解析器。在一些实施例中，相同的源可以针对多种类型进行匹配和可以使用多种类型而被分析。

“日志规则”402定义源的集合连同在持续监视期间要被触发的条件和动作。“目标”408识别IT环境中包含日志的单独的部件。在一些实施例中，将规则关联到目标开始监视过程。

在图4A的实施例中，一个或多个日志规则与一个或多个目标相关联。在图4B的可替代实施例中，一个或多个日志源可以与一个或多个目标相关联，以创建目标的实例。在图4C的实施例中，甚至不提供日志规则来作为创建关联的方法–其中仅提供日志源到目标的关联，以创建目标实例。下面将更详细地描述这些方法中的每一个方法。

图5示出了通过将日志规则与目标相关联来实现日志收集配置的方法的流程图。在502处，创建一个或多个日志规则。规则由日志处理系统内的规则引擎处理，以实现对给定目标的基于规则的处理。因此，规则将包括用于处理它所关联的给定目标的具体逻辑。

在一些实施例中，规则可以被用于指定目标类型，该目标类型识别该规则旨在应对的目标的类型。规则可以针对单个目标类型或多个目标类型来指定。例如，当监视用于数据库实例的日志文件时，可以将目标类型设置为“数据库实例”，以便日志中的活动的报告针对适当的目标类型进行；在一些实施例中，即使规则可以针对作为日志类型的“文件”而被配置，目标类型也仍然可以是任何受管理的目标类型，诸如数据库。

规则可以指定源类型，源类型识别规则旨在应对的日志文件的类型。例如，规则可以指定日志文件类型将是：(i)文件：OS级日志文件；(ii)数据库表：数据库中的存储日志内容的表；(iii) Windows事件日志：从Windows事件中读取事件作为日志内容。

可以在规则中指定目标属性过滤器，以过滤目标，以便指定规则适用的条件，诸如像特定的操作系统(OS)、目标版本和/或目标平台。例如，用户可以创建仅针对给定平台上的给定OS的规则(例如，仅针对X86_64硬件上的Linux OEL5)。

在一些实施例中当创建规则时，规则还可以包括：(a)规则的名称；(b)严重性级别，该严重性级别指示如果这个规则导致事件被生成，那么这个规则的结果有多么重要；(c)规则的描述；和/或 (d)为什么要进行这种监视的文本理由。

在一些实施例中，可以建立对于其规则将“触发”的一个或多个条件。可以指定多个条件，其中每个条件可以使用布尔运算符与其它条件组合。例如，与其它条件OR(或)的条件集合意味着，如果这些条件中的任何条件与正在被评估的日志文件中的条目匹配，那么该条目触发这个规则。当条件AND(和)在一起时，为了使该条件触发日志文件中的条目，条件的所有子句必须都被满足。然后，将采取指定的动作以作为对匹配的该条目的响应。以下是包括正则表达式的示例条件子句：“MESSAGE contains(消息包含)“START：telnet pid＝[0-9]*from＝[.]*””，其中，如果消息与正则表达式匹配，那么这个条件触发规则。

条件中的“运算符”是如何执行比较。以下是在本发明的一些实施例中可以采用的一些示例运算符：(a)<、>、>＝、<＝：比较值大于或小于(或等于)某个设定值；(b)Contains(包含)：具有包括正则表达式子句的能力的模式匹配，其中可以在开始和结束处放置隐式通配符，除非用户使用^和$正则表达式符号来指定串的开始或串的结束；(c)In(在……中)：可能值的列表；(d)Is(是)：确切的串匹配(没有正则表达式能力)；(e)Is Not(不是)；(f) Does Not Contain(不包含)；(g)Not In(不在……中)：不匹配的值的列表。

可以指定动作，以识别当对于给定条件在所选择的源上找到匹配时要做什么。例如，一个可能的动作是当匹配规则的条件时捕获完整的日志条目以作为观察。这种方法让系统/用户在监视来自任何源的日志时以及在看到与这个规则的条件匹配的单个条目时保存该完整的条目并且将它作为观察存储在储存库中。

观察被存储，以供以后通过日志观察UI或其它报告特征来查看。另一个可能的动作是为每个匹配的条件创建事件条目。当日志条目被认为匹配指定的条件时，这种方法引发事件。在一些实施例中，事件将直接在代理处被创建。源定义将定义捕获事件可能需要的任何特殊字段(如果有的话)。对于这个动作的附加选项是在代理处捆绑重复的日志条目，并且仅在用户指定的时间范围内将事件报告最多仅一次。匹配条件可以被用来帮助识别重复条目的存在。另一个示例动作是为规则创建度量，以捕获匹配条件的每次出现。在这种方法中，使用度量子系统来为这个规则创建新的度量。此后，当存在匹配规则的条件的日志条目时，某一数量的字段作为度量数据被捕获，并且作为这个度量的一部分被上载。这些字段可以被选择，以包括例如诸如“关键” 字段(比如目标、时间、源等)之类的信息。

在504处，在系统中识别一个或多个目标。目标是客户环境内包含日志的单独的部件。这些目标与客户环境中的具体部件/主机相关联。示例目标包括与一个或多个日志一个或多个主机相关联的主机、数据库应用、中间件应用程序和/或其它软件应用。下文描述关于指定目标的方法的更多细节。

在506处，在目标和规则之间进行关联。可以在系统中维护元数据，以跟踪给定目标和给定规则之间的关联。可以提供如下用户界面，该用户界面允许用户查看所选择的规则与什么目标相关联和/或添加更多关联，其中关联是通过将规则与真实目标相关联而使规则成为活动的的方式。

之后，在508处，至少部分地基于规则与目标之间的关联来执行日志收集和处理。如下文更详细地讨论的，基于目标的配置可以涉及在服务器侧和目标侧二者处创建的各种类型的配置数据，以实现日志收集以及日志处理。

当前实施例通过将目标与日志规则相关联来配置日志收集/监视的能力提供了独特的优点。这是因为配置日志监视的用户不需要具体地确切了解用于给定应用的日志如何跨环境内的不同主机和部件定位或分布。相反，用户仅需要选择要对其执行监视的具体目标(例如，应用)，以及然后配置要依据其来执行日志收集过程的规则。

这解决了需要以每个主机为基础来配置日志监视的常规系统的显著问题，其中每当在系统中添加或新配置新的主机时，都需要执行设置和配置活动，或者甚至需要针对现有的主机执行新的日志收集/配置活动。与常规方法不同的是，日志分析用户可以与和用于给定目标的日志相关的确切主机/部件的细节隔离。这种信息可以被封装在由系统管理员维护的底层元数据中，系统管理员了解系统中的应用、主机和部件之间的对应关系。

作为规则的代替或除了规则之外，还可以通过将日志源关联到目标来配置日志处理。图6示出了通过将日志源与目标相关联来实现日志收集配置的方法的流程图。在602处，创建一个或多个日志源。日志源定义了日志文件位于何处以及如何读取它们。日志源可以定义指示源内容如何被收集的源类型。以下是示例源类型：(a)文件–识别可以使用常规OS级文件操作来访问的来自OS级的可读文件； (b)数据库表–存储日志条目的表(例如：数据库审计表)；(c) Windows事件系统–提供对事件记录的访问的API。可以为日志源定义一个或多个源名称。此外，日志源可以与源的描述相关联。要注意的是，日志源还可以在创建日志监视规则时被使用(如上文所描述的)。

日志源还可以与文件模式和/或路径名表达式相关联。例如， “/var/log/messages*”是文件模式的示例(其实际上可能与多个文件相关)。关于文件模式，在目前的日志分析系统中使用它们的一个原因是因为有可能要监视的日志的确切位置发生变化。有些时候，系统将预期日志位于特定的地方，例如在特定目录中。当系统处理大量的流传输日志时，系统可能不清楚日志预期位于哪个目录中。这阻止依赖于静态日志文件位置的系统正确运行。因此，文件模式对于解决这些可能变化的日志位置是有用的。

在一些实施例中，通过指定用于日志源的源名称和描述来创建日志源。日志源的定义可以包括被包括的文件名模式和被排除的文件名模式。文件名模式是与对于日志源要包括的文件(或目录)对应的模式。被排除的文件名模式与从日志源中明确排除的文件(或目录)的模式对应，例如，这在被包括的文件名模式识别具有许多文件的目录并且这些文件中的一些文件(诸如伪文件或非日志文件)使用被排除的文件名模式被排除的情况下是有用的。对于每个模式，系统捕获将用来解析文件的模式串、描述和基本解析器(日志类型)。基本解析器可以定义文件的基本结构，例如，如何解析来自文件的数据、主机名和消息。

日志源的定义还可以指定源是否包含安全日志内容。这是可用的，以便源创建者可以指定如下特殊角色，用户必须具有该特殊角色以便查看可能被捕获的任何日志数据。该日志数据可以包括不是任何目标所有者都可以查看的安全相关内容。

如上面所指出的，日志规则可以引用日志源，反之亦然。在一些实施例中，系统元数据跟踪这些关联，以便维护当前正在使用源的规则的计数。这有助于了解如果源和/或规则被改变或删除所造成的影响。

在604处，识别一个或多个目标。如上面所指出的，目标是环境内的包含、对应于和/或创建要处理的日志或其它数据的部件，其中目标与客户环境中的具体部件/主机相关联。示例目标包括与一个或多个日志一个或多个主机相关联的主机、数据库应用、中间件应用和 /或其它软件应用。

在606处，在目标和源之间进行关联。可以在系统中维护元数据，以跟踪给定目标和给定源之间的关联。可以提供用户界面，该用户界面允许用户查看所选择的源与什么目标相关联和/或添加更多关联。

在608处，目标到源的关联创建日志源的具体实例。例如，考虑通常指定给定文件位于给定目录位置(例如， c:/log_directory/log_file)的日志源。情况可能是客户环境内的任何数量的服务器(服务器A、服务器B、服务器C、服务器D)都可以具有该目录(c:/log directory)中的该文件(log_file)的副本。但是，通过将具体目标(例如，服务器A)关联到日志源，这创建日志源的实例，以便新实例具体关于具体目标上指定目录中的日志文件(例如，开始监视具体地在服务器A上的c:/log_directory/log_file)。

此后，在610处，至少部分地基于规则和日志源之间的关联来执行日志收集和处理。如下面更详细地讨论的，基于目标的配置可以涉及在服务器侧和目标侧二者处创建的各种类型的配置数据，以实现日志收集和处理活动。

当使用这种类型的模型用于配置日志收集时，有许多好处。一个好处是日志类型、源、规则可以根据需要容易地被重用。此外，这种方法通过实现在多个级别上进行共享而避免了必须进行大量的重复配置。此外，用户可以创建使用由其他人定义的或者与产品一起提供的源和日志类型的自定义规则。这种方法还容易在共享知识之上建立。

将规则/源关联到目标提供了识别在哪里经由代理物理地实现日志收集的知识。这意味着用户不需要知道关于目标所在的位置的任何信息。此外，可以促进规则/源到目标的大量关联。在一些实施例中，规则/源可以基于配置被自动地关联到所有目标。如上面所指出的，服务提供商可以提供开箱即用配置。此外，用户可以创建他们自己的配置，包括扩展所提供的开箱即用配置。这允许用户在不构建他们自己的内容的情况下进行定制。

图7示出了实现用于日志监视的基于目标的配置的方法的流程图。这个过程生成用于日志监视的配置资料的创建、部署和/或更新。在一些实施例中，配置资料被实现为由日志监视系统用来管理和实现日志监视过程的配置文件。

在700处，发起基于目标的处理。用于发起基于目标的处理的示例方法包括例如将日志分析代理安装到具体的日志收集位置上。基于目标的处理涉及在一个或多个目标与一个或多个日志源和/或规则之间进行的关联。

在702处，为基于目标的处理生成配置资料。在一些实施例中，基于目标的配置文件被实现为配置XML文件，但是还可以使用其它格式来实现配置资料。可以在主站点处创建基于目标的配置文件(例如，以创建主版本704)，然后将具体版本传递到服务器侧和目标侧。

目标侧资料708可以包括配置细节的与日志收集工作有关的那些部分。这包括例如关于日志源细节和目标细节的信息。服务器侧资料 706可以包括配置细节的与服务器侧日志处理有关的部分。这包括例如关于解析器细节的信息。

在一些实施例中，服务器处的数据库维护配置资料的主版本和目标版本。如上面所指出的，目标版本包括与日志收集工作有关的配置细节，并且被传递到客户环境，以供客户环境中的代理用来从客户环境中收集适当的日志数据。主版本包括在服务器处所需要的全套配置细节，并且当在服务器处被选择并且被用于处理时成为“服务器侧” 资料。这可以例如在目标处收集的日志数据被传递到服务器时发生，其中日志数据的发送包括唯一地识别用来收集日志数据的目标侧资料的标识符(例如，图9的示例目标侧资料中示出的配置版本或“CV” 号903)。当在服务器处接收到这个数据时，标识符被用来确定具有相同标识符号码的资料的对应主版本(例如，如图10的示例服务器侧资料中的字段1003中所示)。然后，该主版本被用作服务器侧资料以处理接收到的日志数据。因此，在这个实施例中，主版本704和服务器侧资料706是相同的，但是具有取决于资料当前是否正被用于处理日志数据的不同标签。在可替代实施例中，例如，资料在具有不同配置细节的多个服务器上被使用的情况下，主版本可以不同于服务器版本。

在710处，配置资料然后被分发到日志处理系统内的适当位置。在一些实施例中，目标侧资料708作为图3A中所示的嗅探器配置文件332被分发给客户系统。关于服务器侧资料706，资料作为图1A 中所示的日志配置文件111被“分发”，其中该分发实际上并不需要将资料跨网络分发，而仅仅指示资料是从服务器内的另一个部件(例如，根据需要)获得的。

之后，在712处，使用目标侧配置资料在目标处执行日志收集处理。此外，在714处，使用服务器侧配置资料来执行服务器侧日志处理。

图8示出了根据本发明的一些实施例的、实现用于日志监视的基于目标的配置的方法的较详细的流程图。在802处，在系统中创建用于处理目标关联的一个或多个工作项。例如，可以在将日志分析代理安装到目标上时创建这种类型的工作，其中对这种安装的识别使得为基于目标的配置资料创建工作项。具有(例如，来自关联的数据库的) 至少一个自动关联规则的目标类型的列表被识别。生成需要与自动启用的规则相关联的目标的列表。这些步骤相当于由生产者实体/进程将关联任务放到队列(例如，数据库表)中，关联任务然后由一个或多个消费者实体/进程进行处理。

一个或多个消费者/工作者实体可以周期性地醒来，以处理工作项。例如，工作者实体(例如，线程或进程)(例如，每10秒)醒来，以检查是否存在任何未决的关联任务。一个或多个工作者的集合将遍历(iterate through)任务以处理队列中的工作。

在804处，工作者中的一个工作者识别要处理的关联任务。在 806处，通过访问为规则、源、解析器、字段和/或目标收集的信息来处理关联请求。这个动作识别正在被寻址的目标，找到该目标并且然后查找已经与该目标相关联的日志源和/或日志规则的详细信息。

在808处，工作者然后为它正在处理的具体关联任务生成配置内容。在一些实施例中，配置内容被实现为XML内容。这个动作为配置资料创建目标侧详细信息和服务器侧详细信息两者。对于服务器侧，这个动作将为服务器创建配置数据以处理收集到的日志数据。例如，为服务器侧资料创建XML格式的解析器详细信息，以用于预期要接收的日志数据。对于目标侧来说，这个动作将为来自目标的日志收集创建配置数据。例如，如下面所讨论的，可以为给定的日志源指定 (例如，具有变量而不是绝对路径名的)可变的路径名，以识别包含要监视的日志文件的目录。在步骤808处，这些变化的路径名可以用实际的路径名替换并且被插入到目标侧资料中。

在810处确定是否存在任何附加的关联任务要处理。如果队列上存在附加任务，那么该过程返回到804以选择要处理的另一个任务。如果没有，那么在812处，配置资料被最终确定。

要注意的是，可以使用相同的配置/XML文件来寻址多个关联。例如，如果多个目标位于同一个主机上，那么可以为主机上的所有目标生成单个配置文件。在这种情况下，上文描述的步骤808通过处理循环将XML内容附加到同一个XML文件，以进行多次迭代。

更新可以以类似的方式发生。当发生需要更新资料的改变时，一个或多个新的关联任务可以被放到队列上并且如上文所描述的被寻址。此外，例如在日志分析代理被卸载的情况下，还可以发生解除关联。在这种情况下，配置文件可以被删除。当目标被删除时，消息可以被广播，以通过目标模型服务来向所有的监听者通知这个事件，该消息可以被利用(consume)，以删除对应的关联以及更新XML内容。

图9示出了根据本发明的一些实施例的示例XML配置内容900。这是可以放在保持目标的主机上的目标侧内容的示例。这个XML配置内容900定义在主机XYZ.us.oracle.com上收集具有文件模式 “/var/log/messages*”的Linux系统消息日志的规则。部分902识别用于正在被寻址的关联的基本解析器。部分903提供内容900的版本号(“配置版本”或“CV”)的标识符，该标识符被用来与具有相同版本号的对应服务器侧资料进行匹配。部分904识别日志规则的 ID。部分906识别具体目标。部分908识别目标类型。部分910识别源类型。部分912识别用于源的解析器ID。日志将基于某种定义的解析器被解析。这些配置文件驻留在嗅探器上，并且日志收集过程基于定义的日志源来收集日志。

在服务器侧的日志处理器中，附加信息可以被包括在配置文件中，以促进日志分析，例如，如图10的服务器侧内容部分1000中所示。 FieldDef部分1001指示服务的数据类型。Log Source(日志源)部分1002指示日志具有“os_file”类型。BaseParse部分1004定义基于部分1006中定义的正则表达式来解析日志条目的方式。部分1003 提供内容1000的版本号的标识符，该标识符被用来与具有相同版本号的对应目标侧资料进行匹配。

除了上文描述的自动关联之外，还可以执行目标-源手动关联。例如，可以提供用户界面来执行手动关联。这也导致上述动作被执行，但是由手动动作触发。

可以执行目标-源关联的再同步。为了解释，考虑在安装日志分析代理时，通过代理连接的被监视目标可以与某些预定义的日志源相关联。类似地，当代理被卸载时，可以从适当的数据库表中删除这些关联。此外，当目标被添加以便由代理监视时，目标可以与用于该目标类型的某些预定义的日志源相关联，并且当从代理删除目标时，可以从数据库表中删除这种关联。

随着时间的推移，由于各种原因，这些关联可能变得不同步。例如，当安装日志分析代理时，由于导致在其传送过程中丢失配置资料的某种网络问题，可能发生自动关联。此外，当添加或删除目标时，事件可能无法被正确处理，因此在更新时的配置XML文件不能适当地发生。

为了处理这些情况以及维持目标与它们对应的日志源之间的关联一致性，在一些实施例中提供了web服务，以周期性地同步关联。在至少一个实施例中，仅自动关联被同步，而由用户手动定制的手动关联不被同步。

可以针对具体的日志分析代理执行关联。可以在数据模型数据存储库中的目标与日志分析数据存储库中的目标之间执行增量分析，以实现这个动作。在以下情况中处理可以发生：(a)对于在数据模型数据存储库中但不在日志分析数据存储库中的目标，为这些目标添加关联；(b)对于不在数据模型数据存储库中但在日志分析数据存储库中的目标，删除用于这些目标的关联；(c)对于在数据模型数据存储库和日志分析数据存储库中的目标，在用户定制的情况下，为这些目标保留相同的关联。添加关联的一个潜在问题与如下情况有关：用户可能已经删除用于特定目标的所有关联，因此在日志分析数据存储库中没有条目，但是在数据模型数据存储库中存在条目。问题在于，当应用上面的方法时，在同步操作之后，不想要的自动关联可能再次被引入。为了避免这种情况，系统可以记录用户动作，以识别潜在的问题。

此外，可以针对指定的租户同步关联。当执行这个动作时，可以在用于数据模型数据存储库的代理与用于日志分析数据存储库的代理之间执行增量分析。处理可以通过以下各项发生：(a)对于在数据模型数据存储库中但不在日志分析数据存储库中的代理，为这些代理添加关联；(b)对于不在数据模型数据存储库中但在日志分析数据存储库中的代理，删除用于这些代理的关联；(c)对于在数据模型数据存储库和日志分析数据存储库中的代理，如上文所描述的执行相同的增量分析和同步。

可以针对所有租户的关联执行同步。当执行这个动作时，应当执行对于每个租户所描述的代理级同步。

将本文档的注意力转向文件模式，在日志分析系统中使用文件模式的一个原因是因为有可能要监视的日志的确切位置变化。在大多数时间，系统将预期日志在特定的位置中、在具体的目录中。当系统处理大量的流传输日志时，它可能不清楚这些日志预期位于哪个目录中。这阻止依赖于静态日志文件位置的系统正确操作。

在一些实施例中，本发明性方法可以将日志分析规则关联到可变位置。一种方法是使用元数据，该元数据替换与日志文件的位置对应的可变部分。路径表达式被用来表示日志文件的路径名，其中该路径表达式包括固定部分和可变部分，并且对于可变部分实现不同的值。位置的占位符最终被替换为目录路径中的实际位置。

一些实施例提供“参数”，这些“参数”是用户可以在包括文件名模式或者排除文件名模式时使用的灵活字段(例如，文本字段)。可以通过将参数名称包含在大括号{和}中来实现参数。在这个源中提供用户定义的缺省值。然后，用户可以在将使用这个源的日志监视规则关联到目标时以每个目标为基础来提供参数覆写。例如，对于从开箱即用的内容的改变，覆写尤其适用(例如，以在不实际改变 OOTB内容的情况下覆写规则、定义等)。这是例如通过实现包括用户覆写和指示对OOTB内容的覆写的映射/注释表来实现的。

这非常有帮助的原因是因为，在日志源中，可以为要监视的日志文件定义路径。在一些情况下，路径是固定的，诸如在Linux syslog 文件中，路径是“/var/log/messages*”。但是，在其它情况下，可能想要监视数据库警报日志，其中每个数据库目标将被安装在完全不同的路径中，并且查找警报日志的路径可能不同。例如，用于一个数据库的警报日志位于该位置： “/xxx/db/yyyy/oracle/diag/rdbms/set2/set2/alert/log*.xml”。带下划线的部分对于每个数据库目标可以不同。但是，每个目标都有目标属性的概念。包括在这些属性中的是可以被用来填充路径中的可变部分的元数据。在当前的实施例中，可以将这个路径替代地表示为：

“{DIAGNOSTIC_DEST}/diag/rdbms/{SID}/{SID}/alert/log*.xml”

当这个源在规则中被使用并且这个规则被关联到目标时，系统用对于该目标已知的参数来替换参数“DIAGNOSTIC_DEST”和 “SID”。这允许系统将单个规则和源一下关联到数千个目标。

作为另一个示例，用户可能想要监视模式：“/xxx/oracle/log/*”。在这种情况下，“/xxx/oracle”是取决于主机的可变路径。可以代替地将该模式写为：“{INSTALL_DIR}/log/*”。对于这个源，用户可以向INSTALL_DIR参数提供缺省值(/xxx/oracle)。稍后，当规则关联到目标时，用户可以为这个目标上的这个参数提供目标覆写值 “/xxx/oracle”，而无需创建新的源或规则。

对于系统定义的固定参数，可能存在用户希望引用内置参数(例如，ORACLE_HOME)的情况。这时，系统将用对于所选择的目标已知的ORACLE_HOME来替换那个变量。模式可以被写为： “{ORACLE_HOME}/log/*”。这个路径将被代理自动理解，其中 ORACLE_HOME是不需要用户设置缺省值的特殊的内置参数。系统可以被提供有集成商/用户可以选择使用的固定参数的列表。

图11示出了实现本发明的一些实施例的该方面的一种可能方法的流程图。在1102处，识别对于其期望实现可变位置处理的位置内容。例如，当系统正在处理来自可能大量和/或不确定的目录位置的大量流传输日志时，这种情况可能存在。日志数据可以位于使用对于不同数据库目标而言变化的路径名来寻址的目标位置处。

在1104处，为目标位置指定具有固定部分和可变部分的路径。可变部分可以用一个或多个参数表示。在日志处理期间，在1106处，用与一个或多个目标日志文件对应的值来替代该一个或多个参数，其中用于实现日志监视的单个规则与要被监视的多个不同目标相关联。

这种方法相对于如下方法而言是相当有利的：在这些方法中每个日志处于不能提前知道的不同目录中并且将必须为每条路径设置单独的转发器机制。相反，本方法可以被用来设置用于非常大量的路径的一个规则。

在一些实施例中，来自日志分析系统的配置信息可以耦合到这种方法，以配置和设置用于识别日志文件指派的规则。可以被使用的配置信息的一些示例包括例如数据库如何连接、部件如何连接、使用哪个数据中心，等等。

一些实施例指定如何基于源和目标的关系来将源映射到目标。例如，定义的源Source1可以被指派给属于某个系统的所有相关目标。在这个实施例中可以使用任何关联类型和/或规则，例如，其中关联类型的公共集合被用来提供对于确定用于日志位置的规则有用的配置信息。这样的关联类型可以包括例如“contains”、 “application_contains”、“app_composite_contains”、 “authenticated_by”、“composite_contains(abstract)”、 “cluster_contains”、“connects_through”、 “contains(abstract)”、“depends_on(abstract)”、 “deployed_on”、“exposes”、“hosted_by”、“installed_at”、“managed_by”、“monitored_by”、“provided_by”、 “runs_on(abstract)”、“stores_on”、“stores_on_db”和 “uses(abstract)”。

要注意的是，目标关系信息/模型还可以以其它方式被使用。例如，目标模型还可以用来帮助关联日志条目查找结果，以帮助进行根本原因分析。作为另一个示例，主机模型可以被用于比较一个系统中的所有主机。例如，如果第一系统中存在多个数据库，那么这个特征可以被用来一起查看跨这些系统的日志，并且与用于第二系统的数据库隔离。

图12示出了用于实现将日志分析规则关联到可变位置的发明性方法的一些实施例的体系架构。在这里，日志分析引擎1202通过访问日志收集配置文件1211来操作。日志收集配置文件1211被实现以表示路径，在该路径中目标位置可以具有固定部分和可变部分两者。可变部分可以用一个或多个位置参数表示。在这个示例中，对于日志 1202a、1201b和1201c可以存在不同的位置。通过替换可变部分，感兴趣的日志的具体位置可以由日志分析引擎1202选择，并且被处理以生成分析结果1213。

在这里，可以访问参考资料1210，以识别用于目标位置的路径的可变部分的正确替代。可以实现任何合适类型的参考资料。如上面所提到的，定义的源Source1可以被指派给属于某个系统的所有相关目标，和/或关联类型和/或规则也可以被使用。此外，可以采用目标关系信息/模型以及参考资料。

因此，本发明的实施例提供了执行基于目标的日志监视的改进的功能。这个功能的两个可能的用例包括日志监视和自组织日志浏览。

日志监视涉及例如存在对日志的持续监视和捕获的情况。日志监视的一些实施例涉及以下各项中的一些或全部：(a)监视用于任何目标的任何日志并从日志中捕获重要的条目；(b)基于一些日志条目来创建事件；(c)识别可以影响合规性得分的日志条目的存在性；(d) 执行用户定义的监视以及集成商定义的监视；(e)捕获不是事件的日志条目以在所有日志的子集上启用分析；(f)诸如入侵检测、潜在安全风险检测、问题检测之类的用例；(g)实现日志内容的长期持久存储；(h)搜索日志内容；(i)可定制的基于搜索的视图；(j)日志异常检测和评分。

自组织日志浏览涉及例如不存在对日志的持续监视的情况。在这种方法中，用户可以浏览主机上的实况日志，而不必收集日志并将它们向上发送到SaaS服务器。用于配置要监视的事物的模型与前面所描述的模型类似。区别在于以下事实：用户可以从UI选择规则、源和一些过滤器，并且然后搜索被向下发送到代理，以获得匹配的日志文件并且将它们带回，从而将它们存储在服务器中的临时存储装置中。用户可以继续在该结果集上缩小搜索范围。如果用户添加另一个目标、规则或扩展时间范围，那么系统返回到代理，以仅获得增量内容，而不是再次获得整个内容。因此，用户可以获得日志分析的相同益处，而无需配置持续的日志监视。这个特征可以延迟非常低，因为当搜索被扩展时，系统仅需要返回以从代理获得更多的数据。缩小当前结果集的所有搜索都与从代理的先前获取而被高速缓存的数据进行比较。

本发明的实施例可以被用来将日志数据存储到原始/历史数据存储库中的长期集中位置。例如，公司IT部门中的目标所有者可以监视所有负责目标的传入问题。这可以包括由公司的SaaS日志分析系统管理的数千个目标(主机、数据库、中间件和应用)。每天可以生成许多日志条目(例如，数百GB的条目)。出于合规性原因，这些日志可能需要被永久存储，并且基于这些日志，数据中心管理者可能希望长期获得它们的一些总体情况(bigpicture)，并且IT管理员可能希望搜索它们来找出特定问题的某些可能原因。在这种场景中，可以将非常大量的日志存储在集中式存储装置中，在集中式存储装置之上用户可以以可接受的性能来搜索日志和查看日志趋势。在一些实施例中，日志数据可以被存储在离线储存库中。这可以例如在数据被保持在线一段时间并且然后被离线传送时被使用。当对于不同类型的存储装置存在不同的定价等级(例如，离线存储装置的价格较低)，并且用户可以选择存储数据的位置时，这尤其适用。在这种方法中，数据可以被保持在离线存储装置中，可以在稍后的时间点处恢复在线。

日志可以被搜索，以分析问题的可能原因。例如，当特定问题对于目标发生时，目标所有者可以分析来自各种源的日志，以查明问题的原因。特别地，来自同一应用的不同部件或来自不同但相关的应用的时间相关的日志可以以时间交错的格式在整合的视图中被报告，以帮助目标所有者找出问题的可能原因。目标所有者可以执行一些自组织搜索，以查找随时间推移相同或相似的日志条目，并且跳转到感兴趣的日志条目，以及然后下钻(drill down)到详细消息并且浏览在感兴趣的点之前/之后生成的其它日志。

在一些实施例中，可以应用限制，以使得用户只能访问向这些用户提供了访问许可的日志。不同等级的用户可以与访问不同的日志集合相关联。各种角色可以与访问某些日志的许可相关联。

可以采用一些实施例来查看长期的日志分布、趋势和相关性。由于许多日志由许多不同的目标和日志源经长时间产生，数据中心管理者可能希望查看长期的日志分布和模式。

可以采用一些实施例来搜索日志，以识别应用中断的原因。考虑这样一种情况：Web应用的目标所有者或IT管理员接收到使用该应用的一些客户报告他们无法完成其在线交易并且在点击提交按钮之后无法显示确认页面的某种通知。利用本发明的实施例，IT管理员可以以用户名作为关键字并且在问题报告时间范围内搜索由应用生成的日志。在日志中可能会找到指示当应用尝试提交事务时发生了某种数据库错误的某种应用异常。通过经由目标关联关系和它们的可用性相关的日志源来添加数据库及其对应的托管服务器以用于搜索，IT管理员可以浏览应用异常时间周围的日志，以查找一些数据库错误，这些数据库错误例如与某种托管服务器部分盘故障和大量提交事务相关。

可以采用一些实施例来通过标签查看长期日志分布、趋势和相关性。数据中心管理者可以为数据中心中收集的日志定义一些标签，诸如用于生产数据库的安全日志、用于开发服务器的安全日志、用于测试服务器的日志、噪声日志，等等。数据管理者可能对例如了解以下情况感兴趣：过去半年中按这些标签的日志分布、上个月期间它们的每日传入速率、以及在给定时间段期间用于生产数据库的安全日志条目与它们的合规性得分的变化之间是否存在任何相关性。

一些实施例允许将日志数据存储为度量。在某些实施例中，系统将存储若干日志字段作为关键字段。关键字段将包括(但可以不限于)：Time(时间)、Target(目标)、Rule(规则)、Source(源) 和Log File(日志文件)。系统还可以创建散列或GUID，以区分具有相同时间和所有其它关键字段的可能日志条目。当使用用于日志条目的该度量动作的规则与第一目标相关联时，创建并部署度量扩展。这个度量扩展将与规则类似地被命名，以方便用户引用它。

在一些实施例中，日志监视规则具有用于在日志条目与规则的条件匹配时创建事件的可能动作。此外，用户将能够指示这个事件还应当触发合规性违反，合规性违反将对针对合规性标准和框架的合规性评分造成影响。

如上面所指出的，一种可能的用例是，例如，在浏览被用来浏览主机上的实况日志，而不收集日志以及将它们发送到SaaS服务器的情况下，提供日志浏览器。用户可以从UI选择规则、源和某些过滤器，然后搜索被向下发送到代理，以获得匹配的日志文件以及将它们带回，从而将它们存储在服务器中的临时存储装置中。这个特征的一个用例是为了允许用户跨系统中的多个目标浏览日志文件的短时间段，以尝试发现问题的源，尤其是在客户环境存在丰富拓扑映射和依赖关系映射的情况下。这种内容可以被用来帮助查找相关元素以及一起示出日志。这允许用户查看例如与给定系统相关的所有目标的日志，并且以时间顺序查看跨所有目标发生了什么。在许多情况下，当存在目标故障时，它可能是正在经历问题的依赖目标，而不是正在发生故障的目标。

用户可以选择在系统/组/单独的目标的上下文中开始新的日志浏览会话。如果从目标主页进入，那么目标主页上下文将被保留。这意味着该页的外壳仍然属于目标主页，并且仅内容面板将包含浏览UI 功能。这意味着浏览UI可以被实现为模块化的，以便动态地插入到其它页面中。在一些实施例中，可以为每个条目提供多行内容，以示出每行的附加细节。这是一次一行，或者用户可以决定对所有行执行这个操作。可以提供对经解析的字段的排序，但是此外，排序可以被用来查看每行的附加细节(包括原始日志条目)。

可以提供搜索过滤器。例如，可以提供以日期范围形式的搜索过滤器，例如，其中选项是Most Recent(最近的)和Specific Date Range(具体日期范围)。利用Most Recent选项，用户可以输入某个时间和Minutes(分钟)或Hours(小时)的尺度。利用SpecificDate Range选项，用户将输入开始和结束时间。利用日期范围选项，可以指定Targets(目标)、Sources(源)和Filters(过滤器)。这些允许用户选择在这个日志浏览会话中他们想要看的内容。在用户选择目标、源以及应用任何过滤器之后，他们可以开始浏览会话，以发起对来自各个目标的日志的检索，并且最终将这些日志显示在界面上。

搜索查询可以以任何合适的方式来实现。在一些实施例中，执行自然语言搜索处理，以实现搜索查询。可以使用搜索处理跨依赖关系图来执行搜索。可以在数据中查询各种关系，诸如“runs on (在……上运行)”、“use by(由……使用)”、“uses(使用)” 和“member of(是……的成员)”等。

在一些实施例中，搜索查询是文本表达式(例如，基于Lucene 查询语言)。用户可以在搜索框中输入搜索查询，以搜索日志。以下是搜索查询中可以包括的内容的示例：(a)项；(b)字段；(c) 项修饰符；(d)通配符搜索；(e)模糊搜索；(d)接近性搜索； (f)范围搜索；(g)推进(boost)项；(h)布尔运算符；(i)分组；(j)字段分组；(k)转义特殊字符。

可以提供搜索查找结果的表格视图。一些查询细化可以经由表格单元格执行，以允许用户经由UI动作在搜索框中包含的查询文本中添加/移除一些基于字段的条件。例如，当用户鼠标右键单击字段时，弹出窗口提供让他/她在搜索期间添加或移除过滤日志的条件的一些选项。这对于用户修改查询文本是方便的，并且，利用这种方法，用户不需要知道内部字段名称就能够在字段级别细化查询。

存在可以被提供的许多方式以在搜索查找结果表中列出字段以供用户为了显示目的而选择/取消选择它们。一个示例方法基于静态元数据，并且另一个可能的方式基于动态搜索结果。

对于基于静态元数据的列表字段，使用基本字段穿梭(shuttle) 来列出所有定义的字段。可以由日志条目元数据定义的一些示例字段包括：(a)日志文件；(b)条目内容；(c)规则名称；(d)源名称；(e)解析器名称；(f)源类型；(g)目标类型；(h)目标名称。这些字段的值可以从代理获得，而日志条目(尽管源、解析器、规则、目标都是GUID/ID)将需要在显示时被查找。

对于基于动态搜索查找结果的列表字段，将示出前n(例如，10) 个字段，这些字段将被建议为对该搜索最为重要。“更多字段”链接将引发让用户选择其它字段的弹出窗口。用户在弹出窗口上比从 View(查看)菜单可以看到那些字段的更多的信息。当列出字段时，系统可以使用任何合适的算法，例如，来为受到搜索结果中多少行有非空值或者跨对于该字段的所有搜索结果存在多少不同值等影响的每个字段指派数字。

考虑到有如此多动态字段可用于让用户选择/取消选择，期望用户能够保存字段选择(字段名称和尺寸)。系统可以存储最后选择的字段，因此，当用户回到页面时，他/她仍然得到上次挑选的字段。

可能存在由搜索产生的非常大量的(例如，数千个)日志条目，并且用户可能无法浏览所有日志条目以找到感兴趣的日志。对于特定的搜索，用户应当能够利用几次点击来下钻到搜索查找结果 (findings)的细节。在一些实施例中，特征包括可点击的条形图和表格分页。利用这些导航特征，加上可自定义的时间范围，用户应当能够快速跳转到某个感兴趣的点。相应地，一些实施例提供从细节上钻到较高级别，因此用户可以经由条形图容易地导航到期望的日志条目。示例用例是：在用户下钻几个级别之后，他们可能想要上钻回到先前的级别，以从另一个条下去。在用户经由一些搜索识别出感兴趣的日志条目之后，他们可能想要探索来自感兴趣的日志条目周围的特定日志源的日志，或者以时间交织模式探索来自感兴趣的日志条目周围的多个日志源的日志。一些实施例提供让用户逐页向前/向后浏览指定的日志条目周围的日志的选项。可以提供搜索查找结果的图形视图。这允许用户挑选字段来以图形方式渲染结果。

一些实施例涉及解决日志分布、趋势和相关性的改进技术。对于从特定搜索得到的搜索查找结果，分布可以基于日志计数，以给予用户关于日志的某种高级别信息。对于每种分布类型，前n(例如，5 或10)个项以及所发现日志的数量被列出(其中“更多...”链接将导致列出所有其它项的弹出窗口)。当用户选择特定的项时，仅与该项对应的日志将显示在右边的表格中，因此该动作等价于用该项来过滤搜索查找结果。这种信息可以通过以下方式来呈现：(a)按目标类型；(b)按目标，诸如目标所有者和/或生命周期状态；(c)按日志源；(d)按标签。除了在结果表中示出搜索查找结果之外，系统还可以为用户提供在表视图与对应的分布图视图之间进行切换的选项。

在一些实施例中，可以通过选择分布项来过滤结果。用户可以通过选择一个或多个分布项来过滤结果表。缺省地，所有分布项都被选择并且所有日志条目都在结果表中列出。在选择一个或多个分布项之后，用户可以经由分页来导览(navigate)日志条目。在一个或多个分布项被选择的情况下，当用户点击搜索按钮进行新搜索时，分布项的选择将被复位成对于所有分布项都被选择。

一些实施例提供了示出搜索查找结果趋势的特征。一些实施例提供了示出搜索查找结果相关性的特征。关于这个特征，一些实施例提供启动链接，这些启动链接用于让用户在他们执行事件、度量和基础设施改变之间的相关性分析时进行导航以搜索/查看详细日志。可以提供启动链接，例如用于让用户在他们希望看到与这里的日志相关的一些较总体的情况时导航到IT分析产品，以分析/查看详细的事件/ 度量。

一些实施例中的另一个特征涉及处理时间扩展的字段定义。即使使用相同的基线日志类型，各个日志条目也有可能包含从一个日志到下一个日志的不一致信息。在一些实施例中，这可以通过定义日志类型公共的基本字段而被处理，然后允许用于日志条目中的附加数据的扩展字段定义。

为了解释，考虑源定义定义了要监视的日志文件。日志文件基于日志类型定义被解析成它们的基本字段。可以提取跨所有日志条目不一致的附加数据，例如，如图13的1300中所示。在这个图中，从日志条目解析的基本字段是Month(月)、Day(日)、Hour(小时)、Minute(分)、Second(秒)、Host(主机)、Service(服务)、Port(端口)(可选的)和Message(消息)。目的是从第二个日志条目中提取出IP地址和端口。例如，由于不是每个日志条目都具有这种结构，因此这个目的在作为日志类型的一部分的某些实现中可能是不能获得的。在这里，用于第二个条目的Message字段具有以下内容：

Accepted publickey for scmadm from xxx.xxx.1.1port xyz ssh2 在一些实施例中，使用诸如以下格式之类的格式对Message字段上的扩展字段定义进行定义：

Accepted publickey for.*from{IP Address}port{Port}ssh2 对于该日志条目，两个新的字段IP Address(IP地址)和Port(端口)将被解析出来，并且将可用于报告、搜索等。当数据在收集时被处理时，这种提取发生。

根据一些实施例，用于实现处理时间扩展的字段定义的处理包括：识别要监视的一个或多个日志文件，其中该一个或多个日志文件中的条目中的一些条目可以包括不存在于其它条目中或与其它条目中的条目不一致的附加数据，诸如一个条目中的没有出现在另一个条目中的附加IP地址字段；识别用于要监视的一个或多个日志文件的源定义；使用源定义将一个或多个日志文件解析成多个基本字段；为一个或多个日志文件定义一个或多个扩展字段；以及从一个或多个日志文件中提取该一个或多个扩展字段。

因此，一些实施例允许用户添加扩展的字段定义。这些是在字段内看到的被定义的模式。用户可以对源执行类似创建的动作(create- like)，然后源和所有扩展将变成新的用户创建的源。扩展字段定义定义要基于给定文件字段中的内容来创建的新字段。在一些实施例中，扩展的字段定义(和标签)可以被追溯地应用。这允许用后定义的字段定义和标签来处理过去的日志数据。

图14示出了一些示例字段定义1302。对于表中的第一种情况，用户指定查看来自日志条目并且由文件解析器解析的“Message”文件字段。这个Message字段将在其中具有文本，但是用户已经识别出他们想要捕获消息的SIGNALNAME部分以作为这个具体消息的新字段。这个新字段(SIGNALNAME)现在变得可以在捕获的日志条目中可查看、在日志浏览器中可查看、并且还可以作为度量的一部分被存储，如果创建规则来这么做的话。在这个示例中扩展字段定义使用Message的全部内容。用户可以用通配符模式来绑定他们的表达式的任一侧。例如，定义可以仅是“发送{SIGNALNAME}”。所示的文本是已知对于这个日志消息永远不会改变的静态文本。在表达式中使用[0-9]*意味着任意数量的数字字符都可以位于这里，但是它们将只会被忽略(因为不存在相关联的字段名称来命名这个字段)。串“发送”之后的文本将被指派给变量SIGNALNAME。

最后一个条目是另一个示例，其中用户定义了两个新字段，并且在第一个字段中，他们还定义了使用正则表达式来获得这个内容的方式。在这里，在句号“.”之前存在包含a-z、A-Z、0-9或连字符的一些字符。与该表达式匹配的所有内容都应当被添加到名为HOSTNAME的新的扩展字段。第一个句号之后的任何内容都将被放入名为DOMAINNAME的新的扩展字段中。来自文件解析器的 HOST字段仍然具有所有的内容，但是这个扩展的字段定义告诉我们的特征除了HOST字段之外还添加了两个新字段(HOSTNAME和 DOMAINNAME)。

其中使用{}定界符来定义新字段的所有扩展字段定义使用解析表达式。但是在这个示例中，除了最后一个示例中的HOSTNAME字段之外，没有示出任何解析表达式。这是因为在一些实施例中，存在缺省已知的(.)*的正则表达式模式，该正则表达式模式意味着任何数量的字符。如果用户不提供正则表达式，那么隐式地使用这个表达式。如果存在静态文本，那么系统将获取两段静态文本之间的任何字符。如果在字段表达式之后没有静态文本或字符，那么假设到文件字段末尾之前的每个字符都是新的扩展字段的值的一部分(比如最后一个示例中的DOMAINNAME和第三个示例中的 CONTENT_LENGTH_LIMIT)。如果这个日志条目存在有时具有附加文本的变体，那么这可能导致一些问题。解决这个问题的方式是还为每个字段定义解析正则表达式，而不依赖于缺省的隐式正则表达式(.)*。

一些实施例提供定义正则表达式并且将它们带名称保存的能力。例如，上面使用的用于主机名的正则表达式是[a-zA-Z0-9\-]+。

保存的正则表达式的一个示例可以是：

IP_Address正则表达式＝>\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3} 当在扩展字段定义中引用这个保存的正则表达式时，表中的最后一个条目可以代替地看起来像这样：

{HOSTNAME:@IP_Address}.{DOMAINNAME}

将被创建的新字段是HOSTNAME和DOMAINNAME。所创建和保存的被引用的正则表达式被称为IP_Address。当系统在代理上执行处理时，它将用以下正则表达式字符串来替代引用的正则表达式 “@IP_address”：

“\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}”

通过利用对来自用户的输入字符串的微小改变，扩展表达式定义可以在代理处(例如，使用Perl解析引擎)直接被评估。

在一些实施例中，可以提供字段引用定义。这提供了一个特征：用户可以提供SQL查询的查找表，以将可能具有不易读的值的字段变换为人类可读性更强的内容。三个示例用例突出了这种需求：(a) 在日志条目中，可能存在仅仅具有数字的错误代码字段(核心字段或者扩展字段)，在这种情况下用户可以提供查找引用，使得系统添加另一个新的字段来存储对这个错误代码的含义的文本描述；(b)在日志条目中，可能存在具有目标的GUID的字段(核心文件字段或者扩展字段)，并且系统可以使用SQL查询提供对目标表的查找，该查找将创建存储目标的显示名称的另一个新字段；(c)作为常见的用例还可以执行IP到主机名的查找，在日志中，可以存在用于客户端的IP地址，其中这些IP地址被用来查找主机名。

如上面所指出的，还可以定义日志类型(在本文档中的一些情况下，在本文中还被称为包括“解析器”)以解析日志数据。一个示例日志类型涉及“日志解析器”，它是可以被用来解析源的核心字段的解析器。另一个示例日志类型涉及“保存的正则表达式”，它可以在定义扩展字段定义时被使用。例如，主机名可以经由正则表达式被定义为“[a-zA-Z0-9\-]+”。这个正则表达式可以带名称保存，并且然后在创建扩展字段定义的稍后时间被使用。

日志解析器是如何读取日志文件并且将内容提取到字段中的元数据定义。每个日志文件可以由单个解析器描述，以将每个日志条目分解成它的基本字段。日志类型可以对应于解析表达式字段，诸如像用于解析文件的Perl正则表达式。当定义日志解析器时，作者识别日志文件中将始终存在的字段。在这种情况下，以下是上面的日志文件的每个条目中存在的字段：

一些字段可以非常复杂，这意味着该字段实际上将包含用于一些日志条目但不用于其它日志条目的附加结构化内容。在一些实施例中，这些可能不能由日志文件解析器处理，因为它在每一行中都不一致。相反，当定义源时，可以定义扩展字段，以将这个字段分解成更多字段来处理这些情况。

可以为系统中的各种构造(诸如解析器、规则和源)实现简档。简档捕获数据项和用户产品的不同用途和/或版本之间的差异。例如，可以创建考虑被监视的用户产品的不同版本的源简档，例如，其中源简档在被监视的数据库的版本1和版本2之间改变源定义。规则简档可以被用来考虑要应用的规则的差异。作为另一个示例，可以提供解析器简档，以调整解析功能，例如，由于来自不同地理位置的日志之间的日期格式的差异。可以为不同的解析器简档提供不同的正则表达式。

关于日志条目定界符，日志文件可以具有已知总是为每个条目一行的内容(syslog)，或者可以具有可以跨多个行的内容(Java Log4j格式)。日志条目定界符输入让用户指定始终将这个日志文件解析为每个条目一行，或者提供告诉我们如何找到每个新条目的报头解析表达式。条目起始表达式将通常与解析表达式的前几个区段相同。系统使用这个表达式来检测何时看到新条目而不是看到前一条目的后续部分。

对于这个示例，条目起始表达式可以是：

([A-Z]{1}[a-z]{2})\s([0-9]{1，2})\s([0-9]{1，2})：([0-9]{2})：([0-9]{2})

这个表达式查找严格的月、日、小时、分、秒结构。如果看到该确切的字符序列，那么这“行”被视为新条目的开始。

在一些实施例中，维护与经解析的字段对应的表，并且由于解析表达式为空，因此该表开始为空(没有行)。随着用户创建解析表达式，被定义的字段被添加到这个表。这可以通过监视在这个字段中输入的文本来实现，并且当添加“)”时，调用函数来确定已经定义了多少个字段。系统可以忽略“(”和“)”的一些情况，例如，当它们被转义或者当它们被与控制字符一起被使用时。

例如，考虑以下解析语言：

([a-z]{2})\s([a-z0-9]+)

在这个示例中，存在两对“()”，这意味着定义了两个字段。里面的内容是如何从日志条目中找到字段–为此创建解析器页面的 UI不关心括号内的内容。这仅在代理上被评估和使用。“(”和 “)”之外的内容仅是帮助解析行的静态文本(这个UI也不关心这个内容)。为了在表中创建正确数量的字段，该方法对解析表达式中 “()”对的数量进行计数。对于由解析表达式解析出的每个字段，用户基于现有的公共字段之一来提供字段名称。

日志解析器构建

如上面所指出的，日志解析器通常由必须既熟知待分析的日志文件的确切格式又熟练掌握将用来实现解析器的具体编程基础设施的人在手动过程中构建。这种方法存在许多问题。例如，这种高度手动的过程需要来自熟练的技术人员的大量时间和资源，既在前期用来创建解析器，也要持续地维护解析器，以面对日志文件格式的可能变化。此外，这种手动方法必须要求对日志文件格式的先验知识，这在日志文件开始流传输到日志分析系统中之前可能并不总是可用的。最后，缺少合适的解析器可能潜在地使日志分析流水线暂停分析受影响的日志数据。

本发明的一些实施例通过提供自动构建日志解析器的方法来解决这些问题。作为需要人来手动创建日志解析器的内容的替代，日志内容本身被用来构建解析器。

图15示出了实现本发明的这个实施例的方法的高级流程图。在 1502处，接收日志文件的一个行或多个行以供处理。在一些实施例中，当以流传输方式接收日志文件的每一行时，日志解析器被构建。这种方法允许当日志文件的内容被接收时，解析器被实时构建。在可替代实施例中，来自日志文件的若干行可以在处理这些行之前被一起收集。这种方法对于对日志文件行执行批处理会是有用的，例如以实现某些类型的处理，诸如在处理之前可能需要最少数量的日志文件行的收集的集合的集群或分组分析。

在1504处，分析来自日志文件的行。分析被执行，以识别日志文件行内的特定内容和有差异的区段。当附加的行被处理并且获得关于行的更多信息时，可以获得对日志文件行的基本结构的更高级别的确定性。要注意的是，为了生成准确的解析器而需要被审查的行的数量取决于日志文件行的复杂性和内容。但是，通过使用本文描述的技术，许多日志文件可以仅需要10-20行(或者甚至更少的行)被分析以构建可接受地准确的日志解析器。这种基于查看相对少量的行来生成日志解析器的能力允许以非常时间高效的方式来执行日志解析器生成过程，并且因此改进计算系统本身的运转，因为它允许在日志文件数据被流传输到日志分析系统中时实时地执行日志解析器生成过程。

在1506处，然后基于对来自日志文件的行的分析来构建解析器。这例如通过扫描日志的一个或多个集合的内容来构建用于解析日志的正则表达式而执行。本实施例通过以下各项来操作：遍历所选择的行集合以识别行之间的公共性，以及然后构建可以被用来一般地解析包含日志条目的类似行的日志文件的正则表达式。

图16示出了根据一些实施例的、实现这个过程的方法的较详细的流程图。在1602处，从正在被分析的日志的第一行创建主列表。该主列表包括将日志文件行的内容映射到行内的识别出的元素类型的映射结构。这些元素类型的示例包括例如数字/整数类型、字符类型和字符串类型。

一旦第一行已被处理，则在1604处选择来自日志的另一行进行分析。在1606处，通过移动通过被分析的行以对照主列表进行比较来执行分析。这个动作被执行，以识别正在被分析的(一个或多个) 行的可变部分和不可变部分。这可以通过从行的开头开始并且向前移动直到存在不匹配为止来执行。在这时，过程找到下一个(或接下来的多个)公共字符。识别出的公共字符中的一个被认为是“定界符”，因此中间范围被标记为可变的。要注意的是，中间范围的尺寸在两个行之间可以是可变的，因此算法应当足够健壮，以处理这个问题。下面更详细地描述用于识别应当被认为是定界符的公共部分的示例算法。该过程循环，直至到达行的末尾为止。

在1608处，主行然后可以被更新，以反映公共部分和可变部分。此外，如果期望，那么可以存储可变部分的值。

在1610处，确定是否存在任何附加的行要分析。在一些实施例中，不需要分析日志中的每一行以执行对日志的分析。相反，仅需要分析行的子集(例如，10个行)来构建解析器。如果需要分析附加的行(例如，用于分析的10个行中仅2个行已经被处理)，那么该过程返回到1604至1608，以从日志中选择和分析另一个行。

如果不需要分析附加的行，那么在1612处，更新后的主行准备好被处理。如下面更详细地描述的，处理的一个示例类型是，对于可变部分中的至少一个可变部分，将该至少一个可变部分指派给涵盖在该至少一个可变部分中检测到的值的可变性的限制最少的数据类型。此外，公共性可以在行之间被识别，以便然后从公共性构建正则表达式。可以为具有占位符的不可变部分生成正则表达式，以实现日志解析器，其中至少两个不同的占位符与不同的数据类型相关联。

图17-1至图17-21提供了这个过程的图示。图17-1示出了日志文件1702的示例。在图中示出了日志文件1702内的两个行。第一行包括内容“N＝Bob.”，第二行包括内容“N＝Sue.”。

第一个动作是从日志文件1702中选择行1，以构建主列表1704。如图17-2中所示，与“N＝Bob.”对应的行1被选择以进行处理。

为了构建主列表1704，检查行1内的内容的每个部分/单元，以识别与该行的该部分相关联的单元类型(在本文中也被称为“解析单元”)。根据一个实施例，行的每个部分是依据以下解析单元之一来识别的：(a)字符串–这是与可能存在于字符串内的任何类型的元素对应的缺省解析单元类型；(b)alpha–这个解析单元类型与任何数量的连续的字母元素对应；(c)整数–这个解析单元类型与任何数量的连续整数元素对应；和/或(d)字段规则类型–这个解析单元类型与基于规则定义来识别的类型对应，并且可以关联到任意数量的字符、整数或符号的复杂组合。类型的限制性越大，为行内的 (一个或多个)元素选择那种类型就越有利。

图17-3至图17-8示出了构建用于日志文件1702的行1的主列表1704的过程。如图17-3中所示，第一个字符“N”被检索并且被放入主列表中的第一个位置中。还为这个字符识别出解析单元类型。在这种情况下，“字符串”的初始解析单元类型被指派给这个字符，因为该过程还没有足够的信息来知道多个行内这个元素的可变性是否应当使这个元素被指派给不同的解析单元类型。因此，由于主列表涉及日志文件的第一行，因此这个元素(以及该行内的其它元素中的每一个)都将被指派给缺省的“字符串”解析单元类型，因为这个分析单元类型涵盖在行中可能存在的每种可能的元素类型。如图17-4中所示，来自行1的下一个字符“＝”也被放入主列表1704中，并且被指派给解析单元类型“字符串”。如图17-5中所示，来自行1的下一个字符“B”也被放入主列表1704中，并且被指派给解析单元类型“字符串”。图17-6示出了来自行1的下一个字符“o”被放入主列表1704中并且被指派给解析单元类型“字符串”。图17-7类似地示出来自行1的下一个字符“b”被放入主列表1704中并且被指派给解析单元类型“字符串”。最后，如图17-8中所示，来自行1的最后一个字符“.”被放入主列表1704中并且被指派给解析单元类型 “字符串”。

接下来，如图17-9中所示，与“N＝Sue.”对应的行2从日志文件1702中被检索出并且对照主列表1704进行比较。可以相对于主列表1704以逐个元素为基础来分析行2的内容。为了说明这种类型的分析，图17-10示出了以逐个元素为基础组织的第2行的内容。

图17-11至图17-15示出了行2与主列表1704之间的这种比较分析。图17-11示出了行2内的第一个元素位置对照主列表1704中的第一个元素位置的分析。在这里，主列表1704在第一位置中包括 “N”，其与行2内的同一位置中的元素“N”匹配。因此，这示出主列表1704正确地指示行的第一个元素具有“N”作为其内容。类似地，图17-12示出了第二元素位置的分析，其中主列表1704在第二位置中包括“＝”，它与行2内的相同位置中的元素“＝”匹配。这指示主列表1704正确地示出行的第二个元素具有“＝”作为其内容。

但是，如图17-13中所示，第三元素位置的比较指示主列表 1704的内容与行2的内容之间的差异。特别地，主列表1704在第三元素位置中具有“B”，而行2在第三元素位置中包括“S”。这指示第三元素位置是(一个或多个)行的可变部分。

然后过程继续识别应当被认为是公共部分与可变部分之间的定界符的下一个(或接下来的多个)公共元素。在当前示例中，第六元素位置中的“.”元素是下一个公共元素。下面结合图20更详细地描述可以用来识别应当被视为定界符的下一个公共元素的方法。要注意的是，这种“向前跳过”以找到下一个公共部分的方法允许比较多个行中每一行内的任何变化数量的字符，因为跳过每个行的多少个字符以识别下一个公共字符没有关系。

如图17-14中所示，公共部分是第一元素位置(“N”)、第二元素位置(“＝”)和第六元素位置(“.”)。可变部分包括第三元素位置(主列表中的“B”和行2中的“S”)、第四元素位置(主列表中的“o”和行2中的“u”)以及第五元素位置(主列表中的 “b”和行2中的“e”)。

可变部分形成分析范围，在分析范围中它的内容可以作为元素的集体组被分析。此外，在可变部分内，公共解析单元类型可以折叠在一起，例如，对于主列表和行2二者的可变部分，这与主列表的 “Bob”和来自行2的“Sue”对应。与这些值相关的最严格的解析单元类型是alpha解析单元。因此，如图17-15中所示，用于主列表的可变部分的各个字符串值被替换为alpha解析单元。

当考虑来自主列表和行2两者的内容时，主列表1704内的解析单元定义还可以被用来跟踪来自已经被分析的行中的每个行的具体内容。在这里，对于该元素位置的来自行1和行2的“Bob”和“Sue” 值可以被包括在用于主列表内的alpha解析单元的解析单元定义内。这产生图17-16中所示的主列表1704。跟踪这些值的一个原因是识别可以稍后用来构建正则表达式的内容值。另一个原因是允许从主列表中重构任何底层的行，例如，其中主列表实质上提供用来构建列表的每个行的压缩集合视图。

在日志文件的一行内，可以存在可以被解释为具有与其相关联的有意义的标签/类型的内容的区段。例如，由“.”值分隔的一系列数字(诸如“123.45.67.89”)可以被识别为IP地址。因此，作为一般将这种序列表示为整数、alpha或字符串解析单元的代替，可以构建 “字段规则”类型，“字段规则”类型将有意义的标签关联到这些类型的序列。字段规则类型可以包括与给定感兴趣序列所关联的字符、整数和/或符号的组合相关的规则定义。

图17-17至图17-19示出了识别用于主列表的字段规则解析单元的这个过程。如图17-17中所示，可以存在已经为日志分析系统定义的任何数量的字段规则1710。这些字段规则中的每个字段规则与不同类型的序列对应，对于该不同类型的序列有兴趣为该序列识别有意义的类型。字段规则类型的示例包括用于IP地址、时间戳、标识符等的字段规则。

图17-18示出了可应用于主列表的可变部分的示例字段规则 1712。字段1712与“Name”类型(或名字/标签)对应，例如，其中字段规则可适用于识别人的姓名。字段规则1712可以与正则表达式1714相关联，以识别主列表的与字段规则相关的部分。在这里，正则表达式1714是“[A-Z][a-z]+”。这个正则表达式与第一个字符是大写字母(从A-Z)、随后是任何数量的后续非大写字母(从a-z) 的任何字符序列对应。在这里，用于主列表的alpha解析单元的所记录的数据集合(例如，“Bob”和“Sue”)与这个“Name”字段规则的正则表达式匹配。如图17-19中所示，此后可以更新主列表 1704，以用字段规则解析单元来替代(一个或多个)alpha解析单元类型。

要注意的是，可以在构建主列表之后(在分析来自日志文件的多个行之后)的后处理动作中执行对主列表的处理，以识别字段规则。可替代地，可以将字段规则识别为以流传输方式被单独分析的行。在另一个实施例中，在行的处理期间以及之后在后处理步骤中都可以识别字段规则。

在一些实施例中，字段规则处理仅针对行的被识别为可变的区段而执行。可替代地，字段规则可以与行的恒定部分和可变部分两者都相关。

一旦处理了来自日志文件的足够数量的行，就可以从主列表构建正则表达式。例如，如图17-20中所示，可以构建正则表达式 “N＝([A-Z][a-z]+)\.”，该正则表达式与主列表1704中维持的值相关。特别地，主列表的恒定部分可以直接插入到正则表达式内。正则表达式的与字段规则对应的部分可以从字段规则本身的正则表达式定义中拉取。

最后，如图17-21中所示，可以为日志文件构建日志解析器 1722。日志解析器1722可以包括从主列表构建的正则表达式，其中该正则表达式与用于日志文件的行定义相关，其中日志文件的行定义可以被用来从文件中读取和解析每一行。数据/元数据的其它项可以与日志解析器1722一起被包括。例如，日志解析器1722可以与解析器标识号/名称相关联，和/或与文件类型标识符相关联。

这种方法的一个关键优点是可以高效地检测各不相同的子模式，该方法分别匹配高级模式，然后使用子模式检测来尝试表征不是高级模式的固定部分的可变部分。一个示例子模式是键-值对。

这种方法还可以被用来定义骨架部分，以构建正则表达式以及构建能够将表达式的部分指派给变量的解析器。这种方法还可以通过指派可变部分以使同一日志中的项保持一致(如果可能的话)来处理低于相似性阈值的模式。在一些实施例中，生成解析器以供将来处理，而不仅仅用于分类。

通过使用这种方法，可以处理具有任何级别的复杂度的日志，以构建日志解析器。考虑以下日志条目，它们是稍微更复杂的示例：

[11.22.33.44]Name＝Bob Age＝27

[10.20.30.40]Name＝Sue Age＝30

本实施例通过遍历所选择的行集合来识别行之间的公共性，然后构建可以被用来一般地解析包含日志条目的类似行的日志文件的正则表达式来操作。主列表可以从第一行构建，其中第一行与第二行进行比较。分析识别被分析的(一个或多个)行的可变部分和不可变部分。

假设第一行(具有name＝Bob)被用来初始构建主列表。然后分析下一行(具有name＝Sue)，以识别两个行之间的可变部分和不可变部分。在这里，行的第一部分具有相同的公共字符“[”。从这个字符开始移动，可以看到存在不同值的中间范围，直到到达右中括号 “]”为止。中间范围可以可选地被视为包括用于“.”字符的公共值。行的其余部分类似地可以被分析，以使得“Name＝”部分和“Age＝” 部分被发现是公共部分，而在这些公共部分之后的字符的范围被发现是可变部分。主行可以被更新，以反映公共部分和可变部分。此外，如果期望的话，那么还可以存储可变的值。

然后可以处理更新后的主行，以从公共性构建正则表达式。对于上面的示例行，以下识别公共部分、可变部分以及可变部分的值。

[{可变区段1}]Name＝{可变区段2}Age＝{可变区段3}

可变区段1：{11.22.33.44，10.20.30.40}

可变区段2：{Bob，Sue}

可变区段3：{27，30}

然后这可以被用来构建适当的正则表达式，以解析来自日志的行。例如，IP地址的行的第一部分可以与以下正则表达式对应： “\[[0-9]*\.[0-9]*\.[0-9]*\.[0-9]*\.\]”。要注意的是，还可以使用(被定义为包括这个正则表达式的)字段规则来将行的该部分与IP地址相关联。

根据一些实施例，行预处理可以提前执行，以准备用于进行处理的日志数据。为了解释，考虑图19中所示的示例日志文件1902。这个日志文件1902包括四个行，其中第一行包括“N＝”，第二行包括 “Bob.”，第三行包括“N＝”，第四行包括“Sue.”。这与图17-1 的文件1702中的两个行中存在的内容完全相同，但在文件1902中分散在四个行中。但是，问题在于预期每一行作为单一单元被分开处理的日志解析器生成器在面对图19的日志文件1902中所示的日志文件结构时将失败，因为每个日志条目事实上一次涵盖两个行(例如，前两行作为第一日志条目，而第三行和第四行作为第二日志条目)。

图18示出了解决这种类型和其它类型的非标准行格式情况的实施例的过程流程。在1802处，从日志文件中识别出一个行或多个行以进行预处理。

在1804处，为了分组的目的而分析行。为了将行分组到一起而可以采取的一种可能的方法是检查行的时间戳。例如，在一些系统中，有可能彼此相关的多个行仅包含用于第一行的时间戳。在这种情况下，行被分组在一起，直到识别出另一个时间戳。即使每行包括自己的时间戳，时间戳值的公共性也允许将多个行识别为单一整体的部分。作为另一种替代方案，可以执行集群，以将假定彼此链接的行的分组集群在一起。另一种可能性是对行执行预分类，以识别行结构，以便识别应当被分组在一起的行。

一旦分组已经被识别出，就可以出于日志分析目的将被分组的行一起考虑。根据1806a，一种可能的方法是操纵行，以使被分组的内容出现在单个行内。在1806b处，另一种方法是为了分析的目的而将多个相关的行分类成单个日志条目。

图19的部分1904a示出了操纵被分组的内容以使得内容出现在单个行内的方法。在这里，原始文件1902包括四个行，其中第一行包括“N＝”，第二行包括“Bob.”，第三行包括“N＝”，并且第四行包括“Sue.”。意图是为了将第一行和第二行彼此分组在一起，而第三行和第四行形成另一个分组。如部分1904a中所示，第一行和第二行的内容被组合以形成具有内容“N＝Bob.”的单个行。类似地，第三行和第四行的内容被组合在一起以形成另一个单个行 “N＝Sue.”。然后处理这些新形成的单个行中的每个行，以用于生成日志解析器。

在部分1904b中所示的替代方法中，不创建新行以将多个相关的行组合在一起。相反，为了分析的目的，多个行只是逻辑上分组在一起以作为单个日志条目。如部分1904b中所示，第一逻辑日志条目 1906s由前两行形成，第二逻辑日志条目1906b由第三行和第四行形成。将通过遍历涉及公共逻辑日志条目的两个行的元素来构建上面描述的主列表。在这种情况下，分隔单个日志条目内的行的“换行”字符可以被认为仅仅是在针对给定条目的主列表内要被识别和处理的另一个字符。

如前面所指出的，当构建日志解析器时，日志行的连续区段可以被视为单元。行内的定界符可以被识别，以确定要识别的连续区段。每行都可以针对它的公共部分和可变部分而被考虑，其中公共部分可以与将可变部分内的一个或多个元素分隔开以作为用于分析的元素序列的定界符对应。例如，在图17-1中所示的日志文件1702的第一行中，可变部分“Bob”在左侧由公共部分“N＝”界定并且在右侧由 “.”界定。类似地对于行2，可变部分“Sue”在左侧由公共部分 “N＝”界定并且在右侧由“.”界定。因此，公共元素“.”可以被识别为定界符，该定界符将它前面的可变部分(例如，“Bob”或 “Sue”)与行的其它部分分开以供分析。

但是，如果公共部分中的一个或多个公共部分实际上应当被认为是应当作为单元被分析的内容区段的一部分，那么仅将公共部分识别为定界符的简单解决方案会失败。为了说明这个问题，考虑图21-1 中所示的日志文件2102。在这里，行1和行2在第四元素位置处具有公共部分(在行的该位置处两行中都有字母“o”)并且在第六元素位置处具有公共部分(在该位置处两行中都有“.”)。作为人类观察者，确定“.”应当是定界符(而不是“o”字符)相当容易，因为字母“o”形成用于“Bob”和“Tod”字母序列两者的名字的一部分。但是，当执行对行的自动化处理时，尤其是当面对这些行而不具有行内容的先验知识时，识别正确的定界符是困难得多的问题。因为自动化处理系统可能不具有作为行结构的一部分的“名字”类型的预先知识，所以尤其如此。实际上，即使在没有行结构的预先知识的情况下，本文描述的过程也将被用来发现日志行结构内的这样的类型。

根据一些实施例，提供了发明性方法，以识别行内的一个或多个公共元素中的哪一个应当被视为定界符。该方法通过遍历行以识别公共元素来操作，其中考虑元素位置和元素权重的组合来确定每个公共元素的得分。然后可以将具有最高得分(或最低得分，这取决于如何计算得分)的元素识别为定界符。

图20示出了根据本发明的一些实施例的、用于高效地识别日志内容集合内的正确定界符元素的方法的流程图。在2002处，用于至少两个行的(一个或多个)行内容被(例如，在行内从左到右)遍历，以识别界定该行的可变部分的公共元素。

在2004处，该过程然后遍历行的其余部分，以识别行内的附加的(一个或多个)公共元素。可能存在任何数量的一个或多个附加的公共元素。

在2008处，为识别出的公共元素中的每个公共元素计算评分。首先为评分确定公共元素在行内的位置。总体思路是，在其它所有条件相同的情况下，较早找到(例如，当在行内从左到右遍历时更靠近左侧)的可能的定界符应当是要考虑的第一个定界符。例如，考虑以下行：“Names:Bob Joe Sam”。在这个示例行中，“Bob”和“Joe” 之间存在第一空格，“Joe”和“Sam”之间存在第二空格。在这种情况下，两个空格都可以是定界符，但是应当首先识别第一空格 (“Bob”和“Joe”之间的左侧空格)。仅仅在之后，当再次运行定界符识别过程时，(“Joe”和“Sam”之间的)第二空格才将被识别为下一个定界符。因此，当在第一空格与第二空格之间进行选择时，第一空格的位置应当收到比第二空格更显著(prominent)的得分。这在2010处通过提供由元素在行内的位置确定的得分因子来完成。例如，元素的位置的总和或者平均值可以被识别并与元素相关联。

此外，找到的元素的类型还应当被考虑到用于元素的定界符得分中。这在2012处通过对行内的识别出的(一个或多个)公共元素应用加权因子来完成。图22示出了具有在本发明的一些应用中可以被应用于识别出的公共元素的一些示例权重的图表2202。特别地，这个图基于这样的假设：即得分越低，就越可能发现元素为定界符。因此，图22中所示的每种类型的元素与加权因子相关联，其中更有可能是定界符的元素类型具有较小的加权因子，并且不太可能是定界符的元素类型与较大的加权因子相关联。在这个示例中，空格很可能被认为是定界符；因此，如行2206中所示，这个元素类型与非常小的加权因子相关联。另一方面，字母数字字符被认为是最不可能作为定界符的元素类型之一；因此，如行2210中所示，这个元素类型与非常高的加权因子相关联。

加权因子还可以与考虑元素的组合的更复杂的规则相关联。例如，由于典型的IP地址具有点缀有“.”元素的数字序列，因此这意味着两个整数序列之间设置的“.”不太可能是定界符，而更有可能是IP 地址字段的一部分。此外，非整数(例如，浮点数)可以包括在两个数字之间的小数点(例如，对于“2.3”中在两个数字元素之间的“.” 元素)，这也使得在这种情况下“.”元素不太可能是定界符，而更有可能是数值的一部分。因此，如行2208中所示，元素的这种组合可以与识别两个整数之间的“.”元素的规则相关联，其中这个规则与加权因子相关联，以便在这种类型的元素组合中使“.”偏离作为定界符。

作为另一个示例规则，考虑当给定的字符已经被发现是一行中的定界符的情况。在这种情况下，位于同一行后面的那个相同的字符很有可能也是定界符，例如，在一行中之前被发现是用于键-值对的定界符的“＝”元素很有可能也是同一行中稍后用于其它键-值对的定界符。因此，如行2204中所示，针对这种情况的规则可以与加权因子相关联，以严重偏向于支持先前被识别为定界符的元素被再次视为定界符。

一旦计算出得分，在2014处，就可以通过比较不同的可能定界符的得分来识别定界符。例如，如果评分被配置为使得较低得分与作为定界符的较大可能性对应，那么(一个或多个)行中的具有计算出的最低得分的元素将被识别为定界符。然后可以重复该过程，以识别该行内的任何数量的附加定界符(如果它们存在的话)。

要注意的是，虽然这个示例计算其中最低得分最有可能是定界符的定界符得分，但是本文公开的原理的应用还可以操作以计算其中最高得分与最有可能的定界符对应的得分。在这种替代方法中，加权因子将被配置为使得最有可能是定界符的元素类型将与较高的加权因子相关联，并且不太可能被认为是定界符的元素类型将与较低的加权因子相关联。

图21-1至图21-5示出了定界符识别过程。图21-1示出了日志文件2102，其中行1与“N＝Bob.”对应并且行2与“N＝Tod.”对应。如图21-2中所示，在这两个行中都找到左侧的公共元素“＝”。然后该过程遍历其余的行，以识别更多公共元素。如图21-3中所示，可以看出“o”是第一个公共元素，并且“.”是第二个公共元素。

然后将为这两个公共元素中的每一个计算定界符得分。图21-4 示出了为这些元素中的每一个元素计算得分的过程。首先，为每个行计算元素在行内的相对位置。对于元素“o”，这个元素对于每个行都存在于位置1处。因此，这些位置值的总和是2。对于元素“.”，这个元素对于每个行都存在于位置3处。因此，位置值的总和是6。

接下来，为每个元素识别加权因子。图22示出了在当前评分计算中可以被使用的示例加权因子。对于元素“o”，这是字母数字字符，它与图22的图表中的加权因子100相关联。对于元素“.”，这与图22的图表中的加权因子1相关联。

在这个示例中，通过将加权因子乘以用于元素的位置地点的总和来计算得分。对于“o”元素，得分因此将是位置总和(2)*加权因子(100)＝定界符得分200。对于“.”元素，得分是位置总和(6) *加权因子(1)＝分界符得分6。

然后比较得分，以识别最低得分，其中具有最低得分的元素被认为是分界符。在这里，“.”元素的得分低于“o”元素(6<200)。因此，“.”元素被识别为定界符。

如图21-5中所示，现在可以识别在“＝”元素与定界符“.”之间的分析区段“Bob”和“Tod”。在这种情况下，将“.”(而不是 “o”)识别为定界符产生正确的结果，因为可以看出，尽管“o”字符是两个行之间的公共元素，但是“o”字符实际上是分析段的一部分，而不是定界符。

在一些实施例中可以应用的另一种技术是自动执行来自日志数据的键值提取。这种方法例如对于实现上面描述的扩展字段定义尤其有用。当前实施例通过识别行中的第一个和最后一个键值对分隔符，以及然后利用分割功能处理其间的内容以提取键值数据来实现。

图23示出了执行键值提取的示例方法的流程图。该过程在2302 处通过分析行并识别它看到的第一个键-值分隔符开始。键-值分隔符可以是例如“＝”字符。如果在行中没有找到适当的键值分隔符，那么该过程退出。

接下来，在2304处，尝试找到键-值(KV)对分隔符(如果找到KV分隔符，那么中断)。这种对分隔符可以是例如不同键-值对之间的空格。该过程循环该步骤，以寻找附加的对分隔符。因此这识别出在行内存在的键-值对的范围以供处理。

然后过程返回到识别出的范围的开始，以提取键-值内容。在 2306处，识别在第一个键值分隔符左侧的键。在2308处，识别最后一个KV分隔符右侧的值。在2310处，行的识别出的部分然后被解析，以识别键值。例如，来自Java或Perl的“split”函数可以被用来执行这个动作。对于当前行，这个动作因此识别行中每个键值对的键值。因此，这种方法可以被用来自动执行键值提取。该过程遍历识别出的范围中的其余键值对，以提取用于所有键值对的键值数据。

图24-1至图24-12迭代这个过程。图24-1示出来自日志文件的具有以下内容的示例行2402：“11/12/2017Name＝Bob ID＝5 Age＝21”。如图24-2中所示，该过程开始于分析行2402并且识别被看到的第一个键-值分隔符。该键值分隔符可以是例如“＝”字符。在这里，搜索第一个键-值(KV)分隔符会找到“Name＝Bob”内的 “＝”字符。

接下来，如图24-3中所示，尝试找到键-值对分隔符。这个分隔符可以是例如不同键-值对之间的空格。在行2402中，这识别出键值 -对(KVP)“Name＝Bob”和下一个KVP“ID＝5”之间的空格。该过程循环该步骤，以找出附加的对分隔符。例如，如图24-4中所示，在KVP“ID＝5”和下一个KVP“Age＝21”之间找到另一个对分隔符。如图24-5中所示，在行2402中KVP“Age＝21”的右侧没有其它键值对是标识符。

在这个时候，已经为键-值内容提取过程识别出了分析的范围。如图24-6中所示，分析范围从KVP“Name＝Bob”到KVP “Age＝21”。

现在处理将发生，以提取用于每个键值对的“键”和“值”。如图24-7中所示，识别第一个KV分隔符左侧的键。在示例行中，第一个KV分隔符位于“Name”和“Bob”之间。这个分隔符左侧的键是“Name”。接下来，如图24-8中所示，识别KV分隔符右侧的值。在示例行中，分隔符右侧的值是“Bob”。这些值可以被记录到诸如数据库表或键-值数据结构之类的任何合适的结构中。

然后处理前进到下一个键值对。如图24-9中所示，识别下一个 KV分隔符左侧的键。在示例行中，KV分隔符位于“ID”和“5” 之间。因此，这个分隔符左侧的键是“ID”。接下来，如图24-10中所示，识别KV分隔符右侧的值。在示例行中，分隔符右侧的值是 “5”。这些值被记录到适当的存储结构中。

然后处理前进到最后一个键值对。如图24-11中所示，识别最后一个KV分隔符左侧的键。在这里，最后一个KV分隔符“＝”位于 “Age”和“21”之间。这个分隔符左侧的键是“Age”。接下来，如图24-12中所示，识别该KV分隔符右侧的值。在这里，分隔符右侧的值是“21”。这些值被记录到适当的存储结构中。在这个时候，所有键值对都已经被识别，并且被提取到键-值存储结构中。

可以执行附加的优化，以高效地从日志文件中提取键-值内容。为了解释，再次考虑图24-6中所示的日志文件行2402。已经为这个行2502识别出的分析区段相当容易处理，因为它仅包含要进行处理的键-值对。因此，迭代应用上文描述的方法以检查KV分隔符“＝” 的任一侧的键和值将得到用于每个键值对的正确的键/值数据。

但是，如图25-1的行2504内所示，存在非键-值内容可能存在于分析范围的边界内的可能性。在这种情况下，日期内容 “11/12/2017”出现在分析范围内。因此，仅检查KV分隔符“＝” 的左/右侧的值的过程的简单应用可能以这个内容向前一KV对的值内容的不正确指派(例如，其中键是“Name”并且这个键的值被错误地识别为“Bob 11/12/2017”)结束或者以该内容向后续键内容的不正确指派(例如，键被错误地识别为“11/12/2017 ID”并且这个键的值被识别为“5”)结束。

这个问题不能仅仅通过考虑空格字符作为用于识别键和值的定界符来校正。这是因为某些键和/或值可能意图包括空格作为键/值内容的一部分。为了解释，考虑图26-1中所示的行2506。在这个行中，第一个KV对具有“Name”作为键。这个键的值假定是“BobSmith”，在“Bob”和“Smith”之间有空格。因此，总是将空格视为定界符的任何方法都将错误地仅将“Bob”部分指派为值，而不能不正确地将“Smith”识别为值内容的一部分。

解决这个问题的一种可能方法是执行预处理来对行的部分进行分类，以使得行的键-值部分可以被识别以用于键-值提取。利用这种方法，图25-1中的行2504的非KV部分可以被正确地识别(例如，识别为日期字段)，并且上文描述的键-值提取过程因此将忽略行的这部分。如图25-2中所示，这将导致KV提取下的多个分析范围。这种方法可以类似地被用来解决图26-1中所示的行2506，在行2506 中第一个KV对具有“Name”作为键，并且这个键的值被假定为 “Bob Smith”，并且在“Bob”和“Smith”之间有空格。将空格视为定界符的任何方法都将错误地仅将“Bob”部分指派为值，而不能不正确地将“Smith”识别为值内容的一部分。但是，可以使用预处理来识别用于这个键值对的值字段内可以存在空格的事实，并且如图 26-2中所示，将针对各个键值对来识别行的正确部分，其中“Bob” 和“Smith”之间的空格元素被认为是值字段的一部分而不是定界符。在于2014年9月26日提交的美国临时申请No.62/056073和2015年 9月24日提交的美国申请No.14/863994中描述的一个或多个方法可以被用来识别模式签名，以实现这种方法，并且这两个申请的全部内容通过引用并入本文。模式签名可以与KV签名对应(例如，识别出的KV分隔符(诸如“＝”)将可识别的键和值部分分开)，KV签名用来识别行的KV分析部分(并且忽略行的非KV部分)。

另一种方法是执行后处理，以校正内容到键或值字段的任何有问题的指派。这种方法可以被用来例如检查键值字段内的值的(一个或多个)不正确类型。为了解释，考虑图25-1中所示的行2506，并且考虑仅检查KV分隔符“＝”的左/右侧的值的过程的简单应用可能以日期内容向前一KV对的值内容的错误指派而结束，例如，其中键是 “Name”，并且这个键的值被错误地识别为“Bob 11/12/2017”。可以为日志分析系统配置规则，该规则将类型元素的范围限制在可识别为“Name”字段的字段内，这将“/”字符排除在有效名字之外。在这种情况下，后处理将能够基于“Bob 11/12/2017”字段内的“/”字符来识别值字段的不正确部分。然后分析系统可以选择排除整个提取出的键/值内容，或者可以选择校正错误的内容。可以通过在行内容内向前和/或向后扫描以识别要指派给键和/或值字段的正确内容集合来实现校正。在这种情况下，“Bob 11/12/2017”字段将被校正为仅将“Bob”与键“Name”的值字段相关联。

因此，已经描述的是用于实现日志分析方法和系统的改进的系统、方法和计算机程序产品，该日志分析方法和系统可以以高效的方式配置、收集和分析日志记录。特别地，已经描述了通过分析日志的行内容来自动生成日志解析器的改进方法。此外，已经描述了从日志内容中提取键-值内容的高效方法。

系统体系架构概述

图27是适于实现本发明的实施例的说明性计算系统1400的框图。计算机系统1400包括用于传送信息的总线1406或其它通信机制，总线1406或其它通信机制互连子系统和设备，诸如处理器1407、系统存储器1408(例如，RAM)、静态存储设备1409(例如，ROM)、盘驱动器1410(例如，磁性的或光学的)、通信接口1414(例如，调制解调器或以太网卡)、显示器1411(例如，CRT或LCD)、输入设备1412(例如，键盘)和光标控制器。

根据本发明的一个实施例，计算机系统1400通过处理器1407执行系统存储器1408中包含的一条或多条指令的一个或多个序列来执行具体操作。这种指令可以从另一个计算机可读/可用介质(诸如静态存储设备1409或盘驱动器1410)被读取到系统存储器1408中。在替代实施例中，可以使用硬连线的电路系统来代替软件指令或与软件指令组合，以实现本发明。因此，本发明的实施例不限于硬件电路系统和/或软件的任何特定组合。在一个实施例中，术语“逻辑”是指用于实现本发明的全部或部分的软件或硬件的任何组合。

如本文所使用的，术语“计算机可读介质”或“计算机可用介质” 是指参与向处理器1407提供指令以供执行的任何介质。这种介质可以采取许多形式，包括但不限于非易失性介质和易失性介质。非易失性介质包括例如光盘或磁盘，诸如盘驱动器1410。易失性介质包括动态存储器，诸如系统存储器1408。

计算机可读介质的常见形式包括例如软盘、柔性盘、硬盘、磁带、任何其它磁性介质、CD-ROM、任何其它光学介质、打孔卡、纸带、具有孔的图案的任何其它物理介质、RAM、PROM、EPROM、 FLASH-EPROM、任何其它存储器芯片或盒式存储器、基于云的存储装置或计算机可以从其读取的任何其它介质。

在本发明的实施例中，用于实践本发明的指令序列的执行是由单个计算机系统1400执行的。根据本发明的其它实施例，通过通信链路1415(例如，LAN、PTSN或无线网络)耦合的两个或更多个计算机系统1400可以彼此协调地执行实践本发明所需的指令序列。

计算机系统1400可以通过通信链路1415和通信接口1414来发送和接收消息、数据和指令，包括程序，即，应用代码。接收到的程序代码可以在它被接收时由处理器1407执行，和/或被存储在盘驱动器1410或其它非易失性存储装置中以供稍后执行。可以从在存储设备1431中维护的数据库1432访问数据，存储设备1431是使用数据接口1433来访问的。

在前面的说明书中，已经参照本发明的具体实施例描述了本发明。但是，将明显的是，在不背离本发明的更广泛的精神和范围的情况下，可以对本发明进行各种修改和改变。例如，上文描述的处理流程是参考处理动作的特定次序来描述的。但是，所描述的处理动作中的许多处理动作的次序可以改变，而不影响本发明的范围或操作。相应地，说明书和附图应当被认为是说明性的而不是限制性的。此外，所示实施例不需要具有所示出的所有方面或优点。结合特定实施例描述的方面或优点不一定限于该实施例，并且可以在任何其它实施例中被实践，即使没有如此示出。而且，贯穿本说明书，对“一些实施例”或“其它实施例”的引用意味着结合实施例描述的特定特征、结构、材料或特点被包括在至少一个实施例中。因此，短语“在一些实施例中”或 “在其它实施例中”贯穿本说明书的各个地方的出现不一定是指相同的一个或多个实施例。

Claims

1.一种用于实现日志解析器的方法，包括：

生成将日志中的第一条目的第一多个元素映射到对应的元素类型的映射结构；

相对于所述映射结构，分析所述日志中的第二条目的第二多个元素，以识别至少以下内容：

在所述第一多个元素和所述第二多个元素中相同的公共元素；以及

在所述第一多个元素和所述第二多个元素之间不同的第一可变元素；

生成包括至少以下内容的正则表达式：

所述公共元素；以及

第一匹配模式，所述第一匹配模式(a)将所述第一可变元素限制为多个可能的数据类型中的第一数据类型，并(b)在所述第一多个元素和所述第二多个元素这两者中匹配所述第一可变元素；

生成被配置为基于所述正则表达式解析日志的日志解析器；

其中所述方法由包括处理器的至少一个设备执行。

2.如权利要求1所述的方法，其中相对于所述映射结构，分析所述第二多个元素包括：

遍历所述第二多个元素；

在遍历所述第二多个元素的同时：

确定在所述第二多个元素和所述映射结构之间相同的第一公共字符；

确定在所述第二多个元素和所述映射结构之间相同的第二公共字符；

确定所述第一公共字符和所述第二公共字符之间的一个或多个中间字符在所述第二多个元素和所述映射结构之间不匹配；以及

将包含所述一个或多个中间字符的字符范围标记为所述第一可变元素。

3.如权利要求1或2所述的方法，其中所述多个可能的数据类型包括字符串类型、整数类型、字母字符类型或字段规则类型中的一个或多个，其中所述字段规则类型与由规则定义的元素序列对应。

4.如权利要求1或2所述的方法，还包括：

将所述日志的多个行的内容分组在一起，作为用于相对于所述映射结构进行分析的第二条目。

5.如权利要求4所述的方法，其中将多个行的内容分组在一起包括形成包括所述内容的单个行。

6.如权利要求1或2所述的方法，还包括：

至少通过以下操作，识别所述公共元素是所述日志内的定界符：

识别所述第一条目和所述第二条目中的多个公共元素；

至少部分基于所述多个公共元素的各自位置以及一个或多个加权因子，对所述多个公共元素进行评分；以及

至少部分基于评分来选择所述公共元素作为所述定界符。

7.如权利要求6所述的方法，其中所述一个或多个加权因子中的至少一个加权因子包括与多个元素的组合对应的基于规则的加权因子。

8.如权利要求6所述的方法，其中为所述公共元素的位置计算总和或平均值。

9.如权利要求1或2所述的方法，其中通过以下操作从所述日志中提取键字段和值字段：

由识别第一键值分隔符以及迭代地识别行内的键值对分隔符来识别用于评估一个或多个键值对的范围；以及

迭代地遍历所述行，以从键值分隔符的实例的左侧提取所述键字段并且从键值分隔符的实例的右侧提取所述值字段。

10.如权利要求9所述的方法，还包括对所述日志进行预处理，以对所述日志的字段和值部分进行分类。

11.如权利要求9所述的方法，其中后处理被应用以校正内容向所述键字段或所述值字段的有问题的指派。

12.如权利要求1或2所述的方法，其中在基于云的日志分析系统中的日志处理流水线内采用所述日志解析器。

13.如权利要求1或2所述的方法，还包括：

识别在所述第一多个元素和所述第二多个元素之间不同的第二可变元素；

其中所述正则表达式还包括第二匹配模式，所述第二匹配模式(a)将所述第二可变元素限制为所述多个可能的数据类型中的第二数据类型，并(b)在所述第一多个元素和所述第二多个元素这两者中匹配所述第二可变元素；

其中所述第一数据类型和所述第二数据类型是不同的。

14.一种其上存储有指令序列的计算机可读介质，所述指令序列当由处理器执行时，使所述处理器执行如权利要求1至13中任一项所述的方法。

15.一种用于实现日志解析器的系统，包括：

处理器；

其上存储有指令序列的存储器，所述指令序列当由处理器执行时，使所述处理器执行如权利要求1至13中任一项所述的方法。