CN102356390A - 诸如用于Web服务器的灵活的日志记录 - Google Patents

Abstract

本文中描述了一种灵活的日志记录系统，该系统与web服务器一起操作以用可定制成包括多个数据字段的方式来提供活动日志，可将客户机和服务器日志信息捕捉到单个位置，并可直接向分析引擎提供数据以提供近乎实时的报告。该系统在web服务器内捕捉刚发生的事件，并可在进行最后的响应之前提供报告。在web服务器中的请求处理过程中，无论事件在何时发生，服务器扩展模块引发日志事件。该系统将所接收到的数据与日志定义相匹配并将该数据写入任何与之匹配的日志中。因此，该灵活的日志记录系统为内容提供者和管理员提供丰富、灵活、快速的平台以获得对其web服务器的请求的状态的实时视图。

Description

诸如用于Web服务器的灵活的日志记录

背景

Web服务器一般产生活动日志，这些日志提供该web服务器所接收到的请求以及所发出的响应的记录。W3C主张用于web服务器日志文件的标准格式(参见，如“http://www.w3.org/TR/WD-logfile”)，不过还存在其他的专有格式。大多数的分析工具支持标准日志文件格式，不过有关每个服务器事务的信息是固定的(fixed)。服务器一般将更新的条目添加在日志文件的尾端，且服务器可周期性地开始新的日志文件(如，在当前日志达到特定大小时或经过一段时期后)。服务器一般添加有关请求的信息，包括客户机IP地址、请求日期/时间、所请求的页面、HTTP响应代码、所提供的字节、用户代理和推荐者(referrer)。该服务器可将这些字段组合到单个文件中，或者将它们拆分到不同的日志中，诸如访问日志、错误日志或推荐者日志。这些文件一般不能由普通的因特网用户访问，而仅能由网站管理员或其他管理员访问。以下是典型的wen服务器日志的示例。

#Version：1.0

#Date：12-Jan-1996 00:00:00

#Fields：time cs-method cs-uri

00:34:23 GET/foo/bar.html

12:21:16 GET/foo/bar.html

12:45:52 GET/foo/bar.html

12:57:34 GET/foo/bar.html

网站管理员可使用对web服务器日志的统计分析按照一天内的时间、一周内的天、推荐者或用户代理来检验通信量模式。对Web服务器日志的分析可有助于有效的网站管理、充足的主存资源和销售努力的微调。Web分析是出于理解和优化网站用途目的的对因特网数据的测量、收集、分析和报告。站点上的web分析法测量访问者(一旦)在网站上的旅程。这包括驱动(driver)和会话；例如，登陆页鼓励人们做出购买，以及在商业环境中的网站的性能。此数据通常与组织性能指示符作比较，并用来改善网站或营销活动的观众响应。

很多不同的供应商提供站点上的web分析法软件与服务。有两种用来收集数据的主要技术方法。第一种方法即日志文件分析，读取其中web服务器记录其所有事务的日志文件。第二种方法即页面标签，在每个页面上使用JavaScript来通知第三方服务器何时web浏览器呈现了页面。两种方法均收集可被处理以产生web通信量报告的数据。

Web日志分析软件(也称为web日志分析器)是简单种类的web分析法软件，该软件解析来自web服务器的日志文件，并基于包含在该日志文件中的值，得到关于谁、何时以及如何访问web服务器的指示符。一般报告立即从日志文件产生，不过替代地，可将日志文件解析到数据库中并按要求产生报告。在1990年代早期，网站统计数据主要由向web服务器做出的客户机请求(或点击(hit))的计数组成。一开始这是合理的方法，因为那时每个网站经常由单个HTML文件组成。然而，随着HTML中图像的引入以及跨多个HTML文件的网站的引入，此计数变得不那么有用。

Web高速缓存的广泛使用也提出了关于日志文件分析的问题。如果有人重新访问页面，则经常从浏览器高速缓存中取回第二个请求，所以web服务器将接收不到请求。这意味着这个人通过该站点的路径丢失了。可通过配置该web服务器来战胜高速缓存，不过这对访问者而言可导致网站的性能下降。Web分析法供应商通过添加使客户机向日志服务器报告使用信息的客户机侧逻辑来战胜这个现象，从而促使更多的日志分析。

Web日志分析还展现出多个不希望有的问题。首先，在日志的处理中存在固有延迟。存在从接收到请求的时间到请求被写入日志的时间之间的延迟(如，由于操作系统或硬件转储清除的延迟磁盘高速缓存)、将日志放到将作分析之处的延迟以及在处理日志并以适于分析的格式(诸如经由数据库中的行)提供数据的延迟。这些延迟中的每一个意味着内容提供者不能发现有关正在使用的提供者站点的最新信息。对于一些类型的内容而言，诸如现场媒体事件，这可能意味着直到事件结束还没有关于事件成功的有意义分析。诸如负载平衡的某些决定可用有关站点使用的更即时信息来改善，这些更即时信息一般可通过仅提供过程级别数据(如，没有访问者或请求信息)的其他方式得到(诸如通过监测性能计数器)。

在很多情况下，记录比标准日志格式所支持的更多的信息是有用的。对个人数据发出敏感的站点可能希望省略特定数据的记录。因此，第二个问题是网站日志文件可能实际上不包含与内容提供者最相关的数据，且该web服务器可能不支持提供任何超出少数数据预定义字段之外的数据。对于其他类型的信息，内容提供者可能不得不为web服务器编写自定义扩展或就是不能获得该数据。有时内容提供者可在客户机处获得附加数据，不过接着日志分析软件执行尝试相关客户机与服务器日志以提供关于单个客户机发生了什么的完整画面的额外步骤。该数据相关也增加了web通信量分析的延迟。

发明内容

本文中描述了一种灵活的日志系统，该系统与web服务器一起操作以用可定制成包括多个数据字段的方式来提供活动日志，可将客户机及服务器日志信息捕捉到单个位置，并可直接向分析引擎提供数据以提供近乎实时的报告。该灵活的日志系统在web服务器内捕捉刚发生的请求及其他事件，并可在进行最后响应之前提供报告。该系统从web管理员或其他用户处获得定义管理员想要记录的数据字段以及要存储这些字段的一个或多个目的地的日志定义。该系统可接收用于不同用途的多个日志定义，以使一些日志包含不同的数据并存储于不同的目的地。在web服务器中处理请求的过程中，无论事件何时发生服务器扩展模块都引发日志记录事件，针对该事件服务器具有管理员可能想要记录的数据。该系统将所接收到的数据与日志定义相匹配并将该数据写入任何相匹配的日志中。日志目的地除了传统的日志文件之外还可包括数据库，从而访问该数据库的报告软件可执行实时报告。因此，该灵活的日志记录系统为内容提供者和管理员提供丰富、灵活、快速的平台以获得对其web服务器的请求的状态的实时视图。

提供本发明内容以便以简化形式介绍将在以下具体实施方式中进一步描述的一些概念。本发明内容并不旨在标识所要求保护主题的关键特征或必要特征，也不旨在用于限制所要求保护主题的范围。

附图说明

图1是示出一个实施例中的灵活日志记录系统的各组件的框图。

图2是示出一个实施例中的灵活日志记录系统的操作环境的框图。

图3是示出一个实施例中的该系统接收日志数据的处理的流程图。

图4是示出一个实施例中的该系统报告所接收到的日志数据的处理的流程图。

具体实施方式

本文中描述了一种灵活的日志记录系统，该系统与web服务器一起操作以用可定制成包括多个数据字段的方式来提供活动日志，可将客户机和服务器日志信息捕捉到单个位置，并可直接向分析引擎提供数据以提供近乎实时的报告。该系统还是可扩展的，从而第三方研发者可添加新数据以进行日志记录。研发者还可通过编写自定义处理应用来扩展该系统，这些自定义处理应用接收绑定到日志的相同数据。自定义应用可直接地向数据库或控制板应用写入数据。在典型的web日志中，当请求结束时web服务器作出日志条目。对于对大媒体文件的请求(如，一小时长的流传送呈现)，这可意味着甚至很长时间内没有日志信息写入，比可用于分析的少得多。该灵活的日志系统在web服务器内捕捉刚发生的请求及其他事件，并可在进行最后响应之前提供报告。该系统从web管理员或其他用户处获得定义管理员想要记录的数据字段以及要存储这些字段的一个或多个目的地的日志定义。该系统可接收用于不同用途的多个日志定义，从而一些日志包含不同的数据且存储于不同的目的地。在web服务器中处理请求的过程中，无论事件何时发生服务器扩展模块都引发日志记录事件，针对该事件服务器具有管理员想要记录的数据。该系统将所接收到的数据与日志定义相匹配并将该数据写入任何相匹配的日志中。日志目的地除了传统的日志文件之外还可包括数据库，从而访问该数据库的报告软件可执行实时报告。因此，该灵活的日志记录系统为内容提供者和管理员提供丰富、灵活、快速的平台以获得对其web服务器的请求的状态的实时视图。

图1是示出一个实施例中的灵活的日志记录系统的各组件的框图。灵活的日志记录系统100包括日志定义组件110、服务器数据捕捉组件120、客户机数据捕捉组件130、报告组件140和用户接口组件150。此处详细地描述了这些组件中的每一个。

日志定义组件110接收描述一个或多个日志的日志定义。日志定义包括要包含在日志中的字段列表。管理员或内容提供者通过直接或经由用户接口编辑日志定义来创作日志定义。例如，可将日志定义存储在文件中，诸如可用文本编辑器或其他编辑器编辑的可扩展标记语言(XML)文件。替代地或附加地，日志定义组件110可调用用户界面组件150来显示例如用户可从中选取字段来包括在日志中的可用日志字段列表。日志字段可包括字段首部、响应首部、服务器变量和扩展web服务器的功能的模块的模块变量。

服务器数据捕捉组件120捕捉由web服务器或扩展web服务器的模块所引发的事件。系统100定义与web浏览器相关联的任何代码可引发的事件类型以提供日志数据。日志数据可包括模块标识符、字段名称和具体的日志信息。日志定义可提供模块标识符和/或字段名称以标识日志定义作者想要记录的特定字段。对于非模块的日志记录(如，请求首部、响应首部和服务器变量)，该事件可提供众所周知的标识符替代模块标识符来辨别这些类型。服务器数据捕捉组件120收集全部所引发的事件日志数据并基于日志定义将数据引导至一个或多个日志目的地。一个日志目的地可包括标准W3C日志文件，以使web服务器在更多先进的日志记录目的地并排地持续产生传统的web服务器日志。

服务器数据捕捉组件120可将特定请求过程中引发的每个事件聚合和关联，从而系统100随后可相关来自不同模块和web服务器自身内的事件，以提供关于请求处理的完整记录。例如，服务器日志和客户机日志均可包含全局唯一标识符(GUID)，该GUID为日志中与同一事件(如，请求、媒体流等)相关的字段。在一些情况下，请求可跨多个服务器。例如，在使用自适应流传送时，客户机可从服务器场(farm)请求媒体文件的部分，并从不同服务器得到媒体文件的一些部分。客户机可指定客户机标识符，该客户机标识符允许系统100检测每个客户机请求而不考虑提供该请求的服务器，然后在日志数据中相关这些请求。

日志目的地可为特定应用、站点或在数据存储器的其自有目录中的虚拟目录聚合日志数据，从而不需要解析默认服务器日志文件就可在与应用特定的位置处获得相关的日志信息。数据存储器的目录还可具有特定的许可，从而例如在共享web主机上运行应用的每个应用作者仅可访问与该作者自己的应用相关的日志信息。

客户机数据捕捉组件130捕捉客户机上的事件并将这些事件发送到web服务器。由于服务器将所请求的网页提供给客户机，因此该服务器对客户机运行的东西具有一些影响。传统分析法平台在请求透明图像的网页中嵌入JavaScript，此处对图像的请求包含URL中针对服务器的数据。此方法在一些情况下是有用的，不过受限于URL长度和数据类型限制。客户机侧数据捕捉组件130可使用此技术来操作，然而，组件130也可使用其他技术，诸如发送应用以供客户机运行并在所请求的网页中嵌入对应用的引用，此处应用通过可比基于URL的技术包含多得多的数据的HTTP POST(张贴)请求提供日志数据。

可通过web服务器提供的客户机应用的一个示例是Microsoft Silverlight应用。Microsoft Silverlight接收网页中对包含在称为XAP文件的容器中的应用的引用。Microsoft Silverlight提取XAP文件并且调用该应用。MicrosoftSilverlight提供具有沙箱化(sandboxed)安全环境的应用，在应用中该环境运行使得用户的计算机系统受到保护而免受恶意或错误应用代码损害。MicrosoftSilverlight提供应用可调用的API以将用户的计算机系统和硬件与潜在有害的应用动作相屏蔽的方式来回放媒体并将数据发送到服务器。因此，MicrosoftSilverlight和其他浏览器插件可提供预期运行客户机数据捕捉组件130的环境的所有功能。

在一些实施例中，客户机数据捕捉组件130可包括将所接收到的客户机日志数据作为就像本文中描述的服务器上所引发的其他日志事件的日志事件引发的服务器上组件。这允许服务器侧的报告逻辑和日志定义将客户机侧日志数据作为要包括在日志目的地中的字段的一个或多个源来处理。

报告组件140接收所捕捉的服务器和客户机数据并将这些数据提供给一个或多个报告目的地。例如，报告组件140可基于所捕捉的事件产生标准的W3C日志文件。当记录日志到文件时，报告组件140可在将日志条目写入磁盘之前，在一段可配置的时间段内保持这些条目，从而只有特定窗口内的最新日志张贴才会被写入磁盘—这使得为客户机而写入磁盘的重复临时数据或可随着累积数据被持续记录的请求最小化。报告组件140可将来自多个源的数据(如，客户机、一个或多个服务器模块、操作系统数据等)聚合成一个或多个日志条目以供报告。例如，与单个客户机请求相关的数据可以被记录在一起。报告组件140可与其他系统通信以提供实时的日志数据。报告组件140可直接将数据写入包括一个或多个字段的数据库，从而不使用解析来读取数据。可对照这一数据库直接运行很多分析工具。

用户界面组件150提供用户与系统100的组件之间的界面。例如，用户界面组件150可从用户处接收日志定义，并提供用于编辑日志定义的控件。另外，用户界面组件150可接收管理日志命令，诸如开始或停止日志记录、旋转日志文件等的命令。用户界面组件150还向用户显示信息，诸如日志定义的细节以及潜在的实时报告数据。

在其上实现了系统的计算设备可包括中央处理单元、存储器、输入设备(例如，键盘和指示设备)、输出设备(例如，显示设备)，以及存储设备(例如，磁盘驱动器或其他非易失性存储介质)。存储器和存储设备是可以编码有实现或启用系统的计算机可执行指令(例如，软件)的计算机可读存储介质。此外，数据结构和消息结构可以被存储或通过诸如通信链路上的信号之类的数据传输介质传输。可以使用各种通信链路，诸如因特网、局域网、广域网、点对点拨号连接、蜂窝电话网络等。

系统的各实施例可以在各种操作环境中实现，操作环境包括个人计算机、服务器计算机、手持式或膝上型设备、多处理器系统、基于微处理器的系统、可编程消费电子产品、数码相机、网络PC、小型计算机、大型计算机、包括上述系统或设备中的任一个的分布式计算机环境等。计算机系统可以是蜂窝电话、个人数字助理、智能电话、个人计算机、可编程的消费电子产品、数码相机等。

可以在由一台或多台计算机或其他设备执行的诸如程序模块之类的计算机可执行的指令的一般上下文中来描述本系统。一般而言，程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等等。通常，程序模块的功能可以按需在各个实施例中进行组合或分布。

图2是示出一个实施例中的灵活的日志记录系统的操作环境的框图。该环境包括客户机210和通过网络边界920与之相连的服务器250。客户机210包括提供日志数据的一个或多个数据源220，诸如Microsoft Silverlight、浏览器应用及媒体播放器。客户机数据源220跨越网络边界290诸如通过使用HTTPPOST请求230向服务器252提供数据。服务器250执行一个或多个web服务器进程260。每个进程包括在潜在感兴趣的事件发生时引发事件270的各种日志源265。日志模块280捕捉事件并将它们报告给一个或多个日志目的地285，诸如日志文件或合作数据库。第三方还可提供捕捉所引发的日志事件并处理所接收到的日志数据的模块，诸如自定义模块275。

图3是示出一个实施例中的该系统接收日志数据的处理的流程图。从系统接收日志定义的框310开始。用户可通过用户界面创建日志定义，从而系统可在接收到日志事件时访问日志定义。日志定义描述一个或多个日志，以及每个日志中用户感兴趣的字段和要向其提供日志数据的一个或多个目的地。继续到框320，系统接收日志事件。系统可从服务器或客户机处同时接收日志事件。服务器事件可涉及对服务器接收到的请求的处理，而客户机事件可涉及在客户机上检测到的用户动作(如，收看视频)。继续到框330，系统判定所接收到的日志事件是否与任何日志定义相匹配。例如，事件可包含与日志定义中的源标识符匹配的源标识符，或者可包含在日志定义中指定的一个或多个字段。注意，系统为每一个匹配的日志定义执行接下来的步骤，且相同的日志事件潜在地贡献给多于一个日志。

继续到判定框340，如果该日志事件与日志定义相匹配，则系统在框360继续，否则系统跳转至框350。继续到框350，系统忽略该日志事件，然后继续到框370。系统可能引发很多用户不感兴趣的日志事件，且因此不被包含在任何日志定义中。可使用web服务器来主存很多类型的网站，且每一类网站可具有变化的日志记录规范。继续到框360，该系统存储日志事件以供报告。例如，系统可将日志事件存储于日志事件的存储器内列表中。继续到判定框370，如果系统检测到一组相关日志事件是完整的，则系统继续到框380，否则系统循环到框320以接收附加的日志事件。例如，系统可检测与单个请求相关的所有日志事件并将它们归组在一起以供统一报告。

继续到框380，该系统将相关的日志事件聚合在一起以供统一报告。例如，日志定义可基于特定请求、应用和虚拟目录等指定特定日志记录，且该聚合在日志定义的基础上关联日志事件。继续到框390，系统报告所存储的日志事件，如进一步参考图4所述。在框390之后，这些步骤结束。

图4是示出一个实施例中该系统报告所接收到的日志数据的处理的流程图。从框410开始，系统接收指定要存储日志数据的一个或多个目的地的日志定义。例如，系统可访问存储于在每个web服务器上的XML文件中的日志定义，且该XML文件可具有对每个目的地的分层定义。继续到框420，系统接收一个或多个所捕捉的日志事件。例如，系统可按图3的过程接收事件。继续到框430，系统从日志定义选择第一个(或下一个)报告目的地。例如，系统可枚举报告目的地并遍历它们迭代。

继续到框440，系统将日志定义中的任何字段映射到所接收到的日志事件中的字段。字段可包括许多类型的数据，包括请求首部、响应首部、服务器变量和自定义模块数据。日志事件可包括与特定事件相对应的服务器和客户机侧数据。继续到框450，系统向报告目的地发送日志数据的经映射字段。例如，如果报告目的地是文件，则系统将日志数据的经映射字段存储到该文件中。如果报告目的地是数据库，则系统将经映射字段存储为数据库表格中的列。继续到判定框460，如果在日志定义中有更多的报告目的地，则系统循环到框430以选择下一个报告目的地，否则这些步骤完成。尽管示出为串行，该系统可并行地处理多个报告目的地以减少报告等待时间并有效地利用服务器资源。

在一些实施例中，灵活的日志记录系统提供实时的或近乎实时的(如，在五分钟内)的日志记录。例如，在系统从各个服务器和/或客户机组件接收日志数据时，系统可向分析服务器报告该数据，诸如与报告引擎相关联的数据库。在数据到达时，管理员或其他用户可查看基于该数据的报告，以使用户具有与对该服务器的请求有关的最新信息。此信息传递比传统的日志记录到文件、然后周期性地后处理该文件的模式快得多地进行。另外，该系统可基于特定数据特性分离数据，诸如将对于同一个站点、用户、服务器或虚拟目录的请求日志记录于同一位置。该数据还可由服务器流水线中的其他(如，报告)模块消费，且一个或多个模块可将该数据推送至数据库或web服务以供实时报告并监测。首先向发起请求的服务器报告日志数据克服了由一些浏览器对向第三方站点发送信息施加的限制。在这种情况下，数据首先去往第一方站点，其然后将数据转发给第三方站点。

在一些实施例中，灵活的日志记录系统允许任何HTTP客户机使用标准的HTTP POST/GET请求向服务器发送回日志信息。服务器关注提取、验证该日志信息并将其记录到合并的日志中或者使其可用于实时报告。例如，在媒体情况下，客户机可邮送回有关回放对话的消费相关信息，该信息可被用于分析、QOS监测或开账单。这可由标准认证/授权政策来提供安全的日志记录。由客户机发送的日志信息是实现相关的，且服务器实现是灵活的以容纳自定义字段。

服务器可向客户机上的应用(如，基于浏览器应用的Microsoft Silverlight)提供可扩展标记语言(XML)或其他格式清单，这些清单指定请求发送给服务器的客户机日志记录。以下是一示例客户机清单。

在本示例中，清单包含：“字段”(Fields)元素，该元素标识要包括在日志中的客户机侧字段的名称；以及“目的地”(Destination)元素，该元素标识请求客户机向其发送日志的URL(如，经由HTTP POST)。还要注意，该示例清单包括两个不同的日志定义，这两个不同日志定义由客户机提供给不同的目的地URL并且含有不同的信息。日志定义的作者可将日志数据引导到合适的位置并在到达时分离出有用的信息，而不是执行无用的后处理。灵活的日志记录系统还可与将高速缓存的日志数据提交给永久存储器异步和同步地操作。这对于存储器内高速缓存增长过快且系统存档进程无法跟上传入请求的情形、以及需要即时写通过行为的情况，是有用的。

在一些实施例中，灵活的日志记录系统允许管理员或内容提供者指定日志定义中的自定义字段。这个特征允许自定义字段包括(但不限于)HTTP请求首部、HTTP响应首部、Web服务器变量和Windows性能计数器。另外，任何web服务器模块可记录任何字段。这些自定义字段然后对于写入日志文件或其他报告目的地可用。该系统还考虑多个设置，诸如专用/共享主存，由此能够共享同一服务器的多个站点的信息可被划分并提供给站点的相应拥有者。

在一些实施例中，灵活的日志记录系统存储哪些字段针对特定日志文件记录以及服务器配置信息。该配置还可包括策略，诸如日志翻转、日志文件名称、客户机侧日志记录是否启用等等。该特征允许创建多个日志定义并因此允许日志记录对该日志有用的信息。场景的示例会是想要日志记录服务质量(QoS)和分析法信息的内容传递网络。在内部使用QoS时，分析法信息是之后与其用户共享的信息。在这种情况下，CDN不必执行后处理，且仅可创建两个日志定义并仅将相关的字段添加到每一个日志定义。

在一些实施例中，灵活的日志记录系统通过日志定义组件接收过滤规则，这些过滤规则根据特定的日志定义限制所记录的数据。例如，特定的内容提供者可能仅仅对网页的日志记录请求(如，包括*.htm的请求)而不是图像请求感兴趣。内容提供者可提供指定要应用于特定日志的过滤器的过滤规则。这样，内容提供者可减少日志的大小并确保日志仅包含提供者感兴趣的数据。过滤准则的其他示例包括多用途因特网邮件扩展(MIME)类型和所需要的字段。过滤允许系统捕捉较少的数据来进行更快的处理，不管是现场处理还是后处理。

在一些实施例中，灵活的日志记录系统允许安装用于处理客户机日志记录的自定义模块。如此处所述，服务器可在模块中接收客户机日志数据，该模块引发与其它由服务器侧日志记录所引发的类似的日志事件。第三方可选择用自定义模块中的自定义行为替代这个模块，自定义模块执行特定站点或网络应用特定的处理。自定义模块允许第三方包括对所接收到的客户机日志数据的不同处理而不是默认的模块行为。

在一些实施例中，灵活的日志记录系统允许安装用于处理所捕捉日志数据的报告的自定义模块。尽管日志定义提供了关于所记录信息的目的地和类型的灵活性，一些第三方仍可选择提供对所捕捉日志数据的附加自定义处理，且可通过自定义报告模块这样做。例如，第三方可实现与第三方数据库连接的模块，并根据特定的方案将所捕捉的日志数据输入到数据库行。多个自定义报告模块可同时操作以出于不同目的用不同方法提供所捕捉的日志数据。

当前，一般的web服务器仅允许站点级别的日志记录。在一些实施例中，灵活的日志记录系统允许日志记录和为不同级别的配置级别隔离日志，包括站点、应用、虚拟目录等。例如，所分享的主存服务可选择向共享的web主机的每个虚拟目录提供一个日志，以使每个虚拟目录拥有者可检索有关拥有者站点的信息。如今类似的功能涉及将一个站点日志拆分为多个文件作为后处理步骤。

灵活的日志记录系统提供在当前日志记录系统中不可用的日志信息的一个场景用于渐进下载，诸如针对现场事件。渐进下载可包括长时间事件(如，两小时)的视听数据。传统的日志记录系统在整个事件完成之后提供有关请求的信息。反之，灵活的日志记录系统可在接收到请求时并在整个事件进行中提供日志数据。管理员设定指定管理员想要检测的事件类型和所监测数据的目的地的日志定义。这可向内容提供者提供关于有多少个观看者正在收看事件、正在发生的任何差错、事件过程中的服务器负载等的较早信息。

在一些实施例中，灵活的日志记录系统提供用于向客户开账单的信息。例如，特定客户可基于内容项目被下载的次数或基于用户在时间段内使用的带宽而向内容提供者支付。内容提供者可设置带有开账单专用的使用信息的日志定义，以使内容提供者可正确地向用户收费。

事件数据结构

以下是一个实施例中由引发日志事件的服务器侧模块所引发的事件数据结构的一个示例。

符合HTTP_TRACE_EVENT结构的是以下结构中的一个或多个。

从前面的描述中可以看出，可以理解，此处描述的灵活的日志记录系统的特定实施例只是为了说明，但是，在不偏离本发明的精神和范围的情况下，可以进行各种修改。例如，尽管此处描述了web服务器，其他记录信息的服务器类型可使用此处描述的技术来提供丰富、灵活、实时的日志记录。因此，本发明仅受所附权利要求书限制。

Claims (15)

1.一种用于向一个或多个目的地报告日志数据的计算机实现的方法，所述方法包括：

接收(410)指定要存储日志数据的一个或多个报告目的地的日志定义；

接收(420)一个或多个所捕捉的日志事件；

从所述日志定义中所指定的所述一个或多个报告目的地中选择(430)一报告目的地；

将所述日志定义中的字段映射(440)到所接收的日志事件的字段中；

将所述日志事件的经映射字段发送(450)到所选报告目的地；以及

判定(460)所述日志定义是否指定了附加的报告目的地，且如果为是，则对每个附加报告目的地重复选择、映射和发送的步骤，

其中上述步骤由至少一个处理器来执行。

2.如权利要求1所述的方法，其特征在于，接收所捕捉的日志事件包括接收至少一个服务器侧事件和至少一个客户机侧事件。

3.如权利要求1所述的方法，其特征在于，所述日志定义中的字段选自由以下项目组成的组：一个或多个请求首部、一个或多个响应首部、一个或多个服务器变量、一个或多个性能计数器，以及一个或多个自定义模块字段。

4.如权利要求1所述的方法，其特征在于，至少一个报告目的地是文件，其中向所述报告目的地发送经映射字段包括将所述日志事件的经映射字段存储到所述文件。

5.如权利要求1所述的方法，其特征在于，所述至少一个报告目的地是数据库，其中向所述报告目的地发送经映射字段包括将所述日志事件的经映射字段存储为数据库表格中的列。

6.如权利要求1所述的方法，其特征在于，对每一个附加报告目的地重复步骤包括将字段并行地发送到至少两个报告目的地。

7.如权利要求1所述的方法，其特征在于，向所选报告目的地发送所述日志事件的经映射字段包括将所述日志事件发送到用于基于所述日志事件向客户开账单的数据库中。

8.如权利要求1所述的方法，其特征在于，接收一个或多个所捕捉的日志事件包括在所述请求完整之前，接收有关渐进下载请求的信息，其中向报告目的地发送经映射字段包括近乎实时地提供所接收到的信息。

9.如权利要求1所述的方法，其特征在于，所述日志定义是可由管理员定制的，以包括由所述管理员选择的字段。

10.一种用于提供灵活的web服务器日志记录的计算机系统，所述系统包括：

处理器和存储器，所述处理器和存储器被配置成执行软件指令；

日志定义组件(110)，被配置成接收描述一个或多个日志的日志定义，其中日志由要包含在所述日志中的数据字段列表以及要存储所述日志的目的地定义；

服务器数据捕捉组件(120)，被配置成捕捉由web服务器或扩展web服务器的模块所引发的事件；

客户机数据捕捉组件(130)，被配置成捕捉web服务器的客户机上的事件并将所述事件发送到所述web服务器；以及

报告组件(140)，被配置成接收所捕捉的服务器和客户机数据并将所述数据提供给一个或多个报告目的地。

11.如权利要求10所述的系统，其特征在于，与日志相关联的字段列表可根据安装在web服务器上的扩展基于所安装的扩展提供的日志数据来扩展。

12.如权利要求10所述的系统，其特征在于，所述服务器数据捕捉组件进一步被配置成收集任何所引发的事件日志数据并基于所述日志定义将所述数据引导到一个或多个日志目的地。

13.如权利要求10所述的系统，其特征在于，所述服务器数据捕捉组件进一步被配置成将在特定请求的过程中引发的每个事件聚合并关联，以使系统随后可相关来自不同模块以及web服务器自身内的事件，以提供处理请求的完整记录。

14.如权利要求10所述的系统，其特征在于，所述客户机数据捕捉组件进一步被配置成将日志数据提供给可定制的服务器模块，所述服务器模块可由第三方替代以执行自定义客户机数据处理。

15.如权利要求10所述的系统，其特征在于，所述报告组件进一步被配置成基于存储在所述服务器数据和所述客户机数据中的匹配请求标识符来相关涉及同一个请求的所捕捉的服务器和客户机数据。

Images