专利名称：：动态应用程序使用信息的分布式采集和汇集的制作方法
技术领域：
：本发明一般涉及软件监控、跟踪以及投资回报率(ROI)分析。相关技术的描述强大的趋势正在改造软件工业运作的方式和软件开发的方式。最大的趋势可论证地是信息技术(IT)作为商业运转的趋势。美国商业部估计全部资本支出的50%花费在IT和软件上。根据所公布的研究，由于关于生产率和ROI的度量的缺乏，以及因为在软件开发过程期间开发者缺乏从用户和消费者处容易地收集反馈的能力，此开支的相当一部分被浪费。没有这样的反馈，开发者和产品管理人员就不能确定应用程序的哪个特征是最受欢迎的、在软件被使用时哪个特征造成最多的问题，等等。因此，没有告知关于在哪里最佳地分配和有效利用(leverage)开发资源的决定。当软件开发和测试行为在全世界变成分布式的时，该问题恶化。在过去，开发者和IT管理人员试图通过包括推测-估计、用户调查和焦点小组(focusgroup)的各种技术来确定和评价应用程序使用信息，但这样的技术一般只代表消费者库的小规模取样，且它们通常包含不准确和不适时的数据。在现有技术中，在计算机网络中提供用于中心协调、收集并储存错误、迹线(trace)、审计和其它信息的方法和系统是公知的。代表性的例子M给Niemi等人的美国专利号为No.6,470,388的专利。在此专利中，在网络一个或更多"调试"对象。每个实体还包括与应用程序或进程通信的至少一个记录服务层，并包括通信资源以及一个或更多状态机引擎。响应于收集错误、迹线、审计或其它信息，每个调试对象将数据传递到相应的记录服务层，记录服务层决定是否将数据发送到设置在网络中的集中式记录设备。所收集的信息的发送取决于调试对象的状态。在集中式记录设备上，信息被加以时间戳，并连同应用程序的名称和应用程序正在其上运行的主机或实体的名称一起附加到日志文件。另一代表性的例子是发给Hall等人的美国专利号为No.6,591,228的专利。在此专利中，记录服务从在计算环境中执行的应用程序记录至集中式记录诊断消息，在该计算环境中多台大型机连接到数据储存区。每个大型机具有执行应用程序的一个或更多子系统。记录服务API将诊断消息写到数据存储器，并根据问题的类型与告警设备联系。虽然上述应用程序记录技术通常是有用的，它们使用相对适当数量的跟踪系统在整个均勻的计算机环境中工作，以及它们收集相对受限的信息组。在本领域中仍然存在提供跟踪应用程序使用信息的方法和系统的需要，而与所使用的应用程序实例的平台、位置和数量无关，特别是在软件开发过程的环境中。本发明解决了本领域中的需要。
发明内容本发明是用于技术最优化的提供商业值分析的软件平台，特别是在软件开发过程期间。通常根据本发明，跟踪平台作为主机(或管理)服务设备(hostedservice)运行，以监控、收集和汇集(aggregate)应用程序4吏用信息。可以假定，经受测试的应用程序在一组分布式机器例如终端用户客户机上执行。应用程序用工具装备以收集使用信息，使用信息在一个实施例中接着被可靠地传送到中央位置，在中央位置它被汇集并输出，用于查看。通过收集并估量关于应用程序的详细使用信息，服务设备帮助软件开发者更有效地建立高质量的软件应用程序。系统优选地输出网页界面，以使用户(例如，IT管理人员、应用程序开发者等)能够使用传统技术(具有网页浏览器和网络连接性的计算机)和使用标准通信技术(HTTP、安全HTTP、基于SOAP的网络服务，等等)在互联网上与系统进行相互作用。可选地，系统在私用网络上等实现为外联网(extranet)。优选地，实体在订购(subscription)的基础上访问主机解决方案，虽然给定的实体也可选择在基于处理事务(transaction)的基础上访问服务设备。根据本发明的更具体的方面，经受测试的应用程序是应用程序软件、网络应用程序或富互联网应用程序(RIA)之一。在开发过程期间，使用监控API集成到应用程序中，且应用程序被使用。当用户与应用程序互相作用时，日志文件一般以两种方式之一产生。如果应用程序能写到本地文件系统中(在用户的机器中)，则使用信息在对所使用的应用程序为本地的日志文件中收集，并接着发送到上载服务器用于以批量方式处理。如果应用程序不能写到用户机器的本地文件系统中(因为例如，它是网络应用程序或RIA),则使用信息优选地在即时(just-in-time)的基础上发送到远程记录服务器，接着日志文件在记录服务器上产生。在任一情况下，被跟踪的使用信息优选地包括应用程序的"特征(feature)","故障(fault)"和"失效(failure)",而与所使用的应用程序实例的平台、位置和数量无关。如同在这里使用的，"特征"数据通常指信息的收集，例如哪些特征被使用、什么时候、以什么顺序、被谁、在什么平台上以及以什么终端用户环境。"故障"数据通常指哪些特征造成计划性的错误(例如，例外)。"失效"数据识别哪些特征不能成功地完成，例如，如果数据以不正确的格式输入到字段中。根据本发明的进一步的特征，使用信息，或更一般地，日志文件以高度紧凑的方式(优选地使用传统HTTP传输)在互联网上传输，以考虑具有轻量(lightweight)的处理要求的高性能分布式系统。前述内容概述了本发明的一些更相关的特征。这些特征应被解释成仅仅是例证性的。如同将要描述的，通过以不同的方式应用所公开的发明或通过修改本发明可获得很多其它有益的结果。图1是根据本发明用于实现品牌整合(brandintegration)技术平台的服务供应商基础设施的结构图2示出本发明的基本记录服务，其中应用程序实例用工具装备，以提供接着被传送到远程记录服务器的使用数据集；图3示出在软件开发过程期间主机服务设备如何能用于向开发者提供反馈；图4提供主机服务设备的更详细的实现；图5是简化的过程流程图，其示出远程节点如何与记录服务器互相作用；图6示出根据本发明的代表性记录服务器配置；图7示出当用户执行所跟踪的特征时出现的代表性处理流程；图8示出用于文件传输的HTML形式的代表性HTML代码片断；图9是在创建日志文件中使用的代表性记录代码；以及图IO是示出二进制文件格式的代表性日志文件。具体实施例方式图1示出代表性的服务供应商或系统体系结构，其在优选实施例中在一个或更多数据中心内或贯穿一个或更多数据中心实现。数据中心一般具有到互联网的连接性。在一个实施例中，系统提供基于网络的主机解决方案，应用程序开发者(或其它人例如IT人员)通过此方案以在线方式创建、管理并监控应用程序使用分析。参与者优选地与作为主机服务设备的平台互相作用。在可选的实施例中，系统可在私用网络上实现，或作为产品(与主机或管理服务设备相比)实现。服务的用户具有可访问互联网的机器，例如工作站或笔记本电脑。一般，用户通过将机器上的网页浏览器打开到与服务供应商域(domain)或子域(sub-domain)关联的URL来访问服务供应商体系结构。用户然后以通常的方式例如通过输入用户名和密码来对管理服务设备进行验证。在机器和服务供应商基础设施之间的连接可例如通过SSL等被加密或保护。虽然通过公用路由的互联网的连冲妻性是典型的，但用户可在任何局域网、广域网、无线网、有线网、私用网或其它专用网上连接到服务供应商J^出设施。如在图1中看到的，服务供应商体系结构100包括IP交换机102、一个或更多网络服务器104的组、一个或更多应用程序服务器106的组、数据库管理系统108以及一个或更多管理服务器110的组。代表性网络服务器104包括(例如，基于因特尔(Intel)的)商用硬件、才喿作系统如Linux和网络服务器如Apache2.x。代表性应用程序服务器106包括商用硬件、Linux和应用程序服务器。数据库管理系统108可作为Oracle数据库管理程序包实现。在大量的使用环境中，可能有几个网络服务器、几个应用程序服务器和多个管理服务器。虽然没有详细示出，基础设施可包括名称服务设备、其它负载平衡设备、其它交换机、连接网络的存储器等。系统一般还包括到外部数据源，如第三方数据库的连接性。系统中的每个机器一般包括充足的磁盘和存储器以及输入和输出设备。通常，网络服务器104处理进入的商业实体供应请求，以及它们输出下面更详细描述和示出的显示界面。应用程序服务器106管理数据并促进平台的功能。管理员服务器110处理所有的后台(back-end)记账和报告功能。这里仅仅为了例证性目的而详细描述的流行的硬件和软件实现意图不意味着限制本发明的范围。图2示出记录服务设备的基本操作。在本例中，应用程序实例200a和200b根据本发明装备有使用监控API。使用监控API有时称为远程节点。因此，应用程序实例200a具有与其关联的远程节点202a,以及应用程序实例200b具有与其关联的远程节点202b。当然，两个实例的使用只是例证性的，因为本发明设计成提供高度可升级的分布式记录服务设备，其中所使用的应用程序的大量实例用工具装备并被跟踪。在操作中，远程节点202a产生〗吏用数据组204a，以及远程节点202b产生〗吏用数据组204b。此使用数据以高度有效的方式(如下面将要描述的)传输到中央服务器(或一组服务器)，其中数据组在分析和报告引擎208内汇集(参考数字206)并净皮处理。本发明在测试和软件开发的环境中是有用的，虽然本领域中的一个普通技术人员应认识到本发明不限于这样的使用。图3示出代表性商业情况。在本例中，网络应用程序开发者300将使用监控API添加到在开发中的网络应用程序或富互联网应用程序中。接着使这样用设备装备的应用程序可/人网站或其它发布服务器(publishingserver)302得到。终端用户304导航到站点，并下载应用程序和与应用程序互相配合来产生使用数据。该数据被发送到记录服务器306,记录服务器306接着将这样的数据上载到主机服务设备数据库308。管理人员310(或开发者300)可然后登录到主机月l务设备网站312中并访问所记录的数据。图4比较详细地示出主机服务设备的操作。在本例中，大量的终端用户400a-400n使用应用程序并产生将要提供给记录服务器402的使用数据组。记录服务器402可包括一个或更多服务器。记录服务器402通过防火墙410定期上载数据组到应用程序服务器404，应用程序服务器404将所处理的数据存储在数据库406中。主机服务设备的用户405通过服务器412登录到服务设备中，并通过服务器414查看使用报告，服务器414通过防火墙410访问使用数据。优选地，经受测试的应用程序是应用程序软件(例如用Java、.Net、C++、C弁等编写的程序)、支持脚本的网络应用程序(例如包括Java描述语言(Javascript)、ActionScript等的网页)或富互联网应用程序(RIA)(例如支持Flash、AJAX等)之一。在开发过程期间，使用监控API被集成到应用程序中，且应用程序净皮使用。当用户与应用程序互相配合时，日志文件一般以两种方式之一产生。如果应用程序能写到本地文件系统(在用户的机器中)，则使用信息在对所使用的应用程序为本地的日志文件中被收集，并接着发送到上载服务器，用于以批量方式处理。如果应用程序不能写到用户机器的本地文件系统(因为例如，它是网络应用程序或RIA),则使用信息优选地在即时的1^出上发送到远程记录服务器，接着日志文件在记录服务器上产生。这是用于基于网页浏览器记录的技术。优选地，这样的记录通过借助于httpURL参数将数据传输到记录服务器来完成，记录服务器接着将数据转换成日志文件。在任一情况下，被跟踪的使用信息优选地包括应用程序的"特征"、"故障"和"失效"，而与所使用的应用程序实例的平台、位置和数量无关。如上所述，"特征"数据通常指信息的收集，例如哪些特征#1使用、什么时候、以什么顺序、被谁、在什么平台上以及以什么终端用户环境。一般，特征被公开给终端用户。"故障，，数据通常指哪些特征造成计划性的错误(例如，例外)。"失效"数据识别哪些特征不能成功地完成，例如，如果数据以不正确的格式输入到字段中。因此，根据本发明的一个例证性使用，主机服务设备的用户使得开发中的应用程序装备有跟踪模块，以更好地理解其测试第二版(beta)消费者以及他们的测试第二版测试的进展。如上所述，优选地，"跟踪模块"嵌入要被跟踪的软件应用程序中(或另外与其相关联)。使用数据以轻量私有(proprietary)方式发送回汇集和报告服务器。下列描述提供实施方式的额外细节，其中应用程序具有将日志文件写到终端用户机器本地文件系统的能力。在本实施方式中，主机服务设备平台通过现在描述的很多组件从终端用户收集数据。第一个组件是远程节点，其负责收集特征跟踪和配置信息。第二个组件是服务器，其获得远程节点的结果并将它与从其它远程节点收集的数据合并。这两个组件使本发明的用户从^f艮多同时存在的节点收集特征跟踪和配置信息成为可能。还有远程节点应该有的三个重要目标。第一个是它必须易于集成。第二个是它必须运行快速。第三个是信息的传输必须快速且看起来是伴随应用程序的正常执4亍而附带发生的。通过优选地每个特征只需添加一行代码来简单地进行集成。第二个目标通过应用程序快速运行来达到，因为这一行代码以及其最后产生的调用对于每个特征调用的应用程序只引入几毫秒的系统开销。第三个目标被达到，因为日志文件格式确保文件即使在最坏的条件下也总是很小的，导致非常快的传输时间和在那些时间的低CPU利用，因而确保当传输在进行中时用户的应用程序没有被低质量地执行。下面描述了远程节点及其所有的部分，并接着转到相关的服务器组件。远程节点为给定应用程序的一个实例收集特征跟踪和配置信息。在某个用户规定的点，远程节点试图连接到服务器组件并发送一系列日志文件。远程组件依赖于收集和传输该信息的几个子组件。这些组件中的一些需要用户执行确定的实现任务。下面的表1描述了每个组件,组件通信软(Messenger)件事件(event)消息处理器(MessageHandler)日志发送器(logdispatcher)日志文件(logfile)日志记录器(LogWriter)服务器(Server)文件上栽形式(fileuploadform)输入(Import)描述源入遞存欢斧4餘存#扭^戎/力。该i伴戎斤夢斧W—些^理，濕厉谅,惑老理器Ofewflgei/a"af/erJ4确定潘,惑乂《座被记^以及乂否g适合f发'这曰^X伴。逸舍^f运/,^^^疾#^炎在^惑并趟/^惑###。岸,龙;t^逾斧，^确尤,惑乂《应被錄^、/!7^发'送##夢伴餘存岸"及摔它发'迷/麵/^。兑译远资，乂脊仏悉义伴发送iV應务器^逸斧。夢辆斜岸。摔夢伴^",錄存到^悉X斧种邀伴。炎供#义伴丄4'多4'#^"/《^任砉//77^應#器。众众^^摔"，乂传餘到麽多器W脊豕^4'弄^欲^逸斧，该纽斧老^^迷入^仏悉义伴并摔"^X伴^炎兹合^到i婆^^￡估#^炎拔岸#。表l下面将描述这些组件。首先，下面的内容描述了在fc表性的实施方式中数据在远程节点和服务器之间的流动。然后，描述了将这些组件集成到应用程序中以便用户可收集特征跟踪信息的过程。优选地，数据在单一方向上从远程节点流动到服务器，且服务器不与远程节点通信。图5示出代表性的处理流程。用于传输数据的过程是简单明了的。远程节点等待发送事件500,该事件使远程节点连接到用户规定的URL。在步骤502，远程节点试图连接到记录服务器。在步骤504中的测试确定是否远程节点可连接到服务器。如果是，远程节点接着优选地通过将日志文件提交到由URL指定的HTML页面上的HTML形式来传送所有的日志文件。优选地，远程节点接着删除成功发送的日志文件。而且，优选地，如果没有产生到服务器的连接，远程节点储存日志文件达一段用户确定的天数的时间。远程节点也优选地在失败的发送事件之后检验每个日志文件的日期。远程节点然后删除比最大天数旧的文件。在本实施例中，服务器侧仅仅为文件传输提供HTML形式，以如图8所示代码片断中示出的一样来工作。远程节点解析HTML页面并找到上载形式，设定文件字段，接着提交信息。找到形式的步骤确保系统没有试图在不能接受进入的文件的形式上任意执行文件上载。一旦收到，服务器将进入的日志文件写到输入目录。服务器的日志输入组件优选地以有规律的间隔扫描该目录。输入组件打开新的日志文件并将数据添加到数据库。优选地，有两种基本配置以使记录服务器可利用文件上载形式。图6示出对这些配置的处理流程。第一种配置(类型A)显示在附图的顶部中。在该配置中，服务器使形式可利用并等待远程节点连接。这是步骤600。在步骤602，测试被运行来确定远程节点是否试图连接。一旦收到连接，服务器就在步骤604接受日志文件，并在步骤606将日志文件写到输入目录。在步骤608,新的日志文件输入到服务器数据库中。数据库在步骤610被更新，其后日志文件在步骤612被删除。服务器接着返回到等待另一上载的状态。第二种配置(类型B)—般用位于企业网站的DMZ中的记录服务器实现。在本实现中，任意HTTP服务器613提供文件传输形式并在步骤614等待远程节点连接。当远程节点连接时，服务器613在步骤616处理上载形式请求，将日志文件写到本地驱动器618,以及在步骤620复制文件以记录与主机服务设备关联的记录服务器615的输入目录。记录服务器615同时地运行。特别是，记录服务器615在步骤622扫描输入目录。如在步骤624由测试所示的，如果新的日志文件出现，则日志文件在步骤626被输入，数据库在步骤628被更新，以及日志文件在步骤630被删除。配置B更安全和可靠(与配置A相比)，因为HTTP服务器可为现有的公司HTTP服务器，例如用于提供公司网页的服务器。在没有重要的日志数据可从外界访问的意义上，配置B更安全。进一步地，第二配置更可靠，因为公司网络服务器被实现来处理大量的同时存在的用户，并且它被不断地监控，以便它可在失效的事件中快速恢复。在本实施例中，软件开发者一般执行一系列步骤来便于特征和配置信息的收集。特别是，下列步骤描述开发者用工具装备应用程序以产生日志数据(在下文中假定对Java熟悉)1.实现MessageHandler类的导出。2.将一系列Messenger.store(...)方法添力o到应用程序的现有代码。每次添加应在表示给定特征的输入点的代码中的点处。3.更新应用程序安装工具，以^使它收集HTTP代理信息并产生配置文件，该配置文件可被开发者的应用程序读取并可将该信息发送到MessageHandler。现在更详细地描述上面步骤中的每一个。歩骤1MessageHandler是Java抽象类。因此，根据本发明，合成者导出他或她的应用程序特有的该类的具体实现。此消息处理器执行现在描述的一系列任务。在代表性实施例中，MessageHandler类负责过滤和发送日志文件。类的实例一般以初始化代码开始，该初始化代码设置创建和发送日志文件所必需的一系列变量。创建日志文件一般需要合成者的域名的名称如mycompany.com、由服务供应商的服务器提供的唯一的32个字符标识符、以及工程(project)和构建(construct)名称。32个字符的唯一的标识符可由服务器提供给通过用户界面或通过任何其它方便的装置工作的用户。当用户为特定的工程创建新的构建时，标识符净皮创建并显示。用户接着将所述32个字符的唯一的标识符复制到其MessageHandler类实现中。所述32个字符的标识符用于使日志文件数据与特定的工程匹配，并在服务供应商的服务器上建立。读取的来自日志文件的数据接着放入到服务器的数据目录中。工程和构建名称优选地也用于使^:据与工程匹配，并在32个字符的标识符失效的事件中建立，例如由于在开发者方面的印刷错误。MessageHandler的发送才几制优选地也需要目标URL,并可包括其它可选项例如登录名、密码、代理服务器配置和编写将日志文件传输回输入服务器的过程的其它代码。MessageHandler可在应用程序开始、停止的时刻、在配置数据收集期间或在执行特征之后，发送日志文件。开发者的这些方法的实现仅仅返回"真(true)"响应，且MessageHandler然后自动发送系统中所有的日志文件(或其一些子集)。当获得"真"响应时，如果存在或必要，发送者一般使用代理信息，以通过第一干扰防火墙传递并进行与在URL参数中指定的服务器的连接。URL可能需要特殊的登录信息或显示额外的脚本。在此时，发送者执行额外的登录信息和代码以获得文件上载形式。发送者接着通过该形式发送日志文件。<image>imageseeoriginaldocumentpage</image>表2一般，Constructor方法提供关于应用程序的初始化的相当数量的信息。图10中的代码块是MessageHandler抽象类。各种getXXX和setXXX方法允许用户设置重要的配置信息。所示框架允许用户定义很多单元以进一步增强应用程序传送数据的能力。表3在下面描述各种方法和它们执行什么操作(其中带星号的方法是可选的)。<table>tableseeoriginaldocumentpage15</column></row><table>getProjectNamegetProxyServerHostgetProxyServerPort"孕#声谬《^^^在^^挣;C工在^^游。凝4'^丄唯D/s/;"fcAer源^与适/尹远程斧,.表y^^r/^^^4V《^W键#處谬/七'理厲#器^^#。^省^ZogZWs/wifcAer谬^该才法^在^这/f远症^^^^^在淨的询V《^7的嫂#處存代理厲务器的端口。getProxyUserNamegetProxyUserPasswordgetUrlgetWorkDirectorysetBuildNamesetLogDispatcher*setLoginName*setLoginPassword*setLoginUrl*setMaximumFileAge*凝4'^￡<^/>&/Wte^/源^7H法》4与适疔远在,《^^y^程^W械V《^7^試尹處谬^户^"#/七理嚴多器《/尹發证。凝^'^丄化Z)/s/mfc/^r源y5^该才法4j^适/;f远^,乂^^^在#W械咖^7W嫂^處谬y^户^麥竭"^V七'理嚴务器遽疔發证。由凝^'^丄唯Z),Vi/7a/c/^/"j麽^器J:获谬S含Jt斧J:威W#//m:f/^Ww丄。4发'送之;C送欧ilfesw"ge/"^專",悉义伴^设f。说定沟建的^称。^;t#i/^iVfMsagefffl"</ter的^始化欢河设定。谈定定#何■Log/Wopfl^r/ter。^定#納她柳g^awd7erW初始必^/^说《。设定f》;C/时Z^gZ)/apflteAer炎^W奮4f名。^定教时Messflge^aw必er^^》始必欢河设定。说定被定^#iogi)/(i/mfc/^/"炎^W逢、秀麥,4。4定浙时Me柳geHfl/irf/er的初始化期河设定。设《^"定賴^丄og/Wa;wifc/^r炎^^4V夷W^。4《浙WMessflge^a"必er^^始必參7设定。说定煤^潜定W"志X斧W處义天数。^定教时Me咖g^wirf/er射初始必身々7说;t。<table>tableseeoriginaldocumentpage17</column></row><table>表3Messenger和LogDispatcher读取这些方法来使日志文件继续存在并传送日志文件。步骤2Messenger.storefeature(...)方法跟踪特征凄t据。它采用两个参凄t。第一个是定制的消息处理器的实例。第二个是包含特征的名称的字符串。最后产生的关于特征执行的数量的信息指示该特征的值。当然，高度使用的特征通常比很少或从不使用的特征更有价值。在代表性实施方式中，Messenger.storefeature(...)方法添力口到应用程序内的每个特征输入点。歩骤3远程运行的应用程序可支持透明(transparent)的或验证的代理服务器。用户的应用程序安装组件应将此找出，且如果必要，收集代理服务器的地址、端口、用户名和密码，接着将此信息写到定制的MessageHandler实例可读取的配置文件。MessageHandler应接着以配置的信息调用setProxyServerHostO、setProxyServerPort(..)、setProxyUserName(..)、setProxyUserPassword方法。这些集成步骤使用户的应用程序现在收集并传送特征跟踪信息成为可能。图7示出当用户执行所跟踪的特征时出现的代表性处理流程。如在图7中看到的，当用户在步骤700执行特征时，例行程序开始。在步骤702,执行跟踪代码的特征。然后在步骤704运行测试以确定是否这是用于运行的应用程序的第一个特征执行。如果是，在步骤706调用MessageHandler启动方法。然后在步骤708运行测试以确定日志文件是否应该祐发送。如果不，在步骤710调用MessageHandler的处理配置消息方法。接着例行程序在步骤712调用MessageHandler的处理消息方法，当测试的结果在步骤714为正时也到达步骤712。步骤714测试发送是否是由于启动事件。在步骤712之后，特征统计在步骤716更新。接着在步骤718执行测试来确定特征是否应写到日志文件。如果是，在步骤720写日志文件。在步骤720之后，或如果在步骤718的测试结果是负的，则在步骤722执行测试来确定日志文件是否应被发送。如果是，远程节点在步骤724收集所有的曰志文件，在步骤726连接到远程服务器，以及接着在步骤728测试以确定它是否可连接到服务器。如果是，测试在步骤730进行以确定远程服务器是否具有文件上载形式。如果否，或如果在步骤728的测试结果是负的，则在步骤734执行测试来确定文件是否比用户规定的最大的天数旧。在步骤730的测试的正的结果之后，在步骤732上载文件。在步骤732之后或在步骤734的正的结果之后，文件在步骤736被删除，且控制返回到在步骤714中的测试的以完成处理。曰志文件优选地是包含一系列特别格式的事件的二进制文件。优选地，文件包括汇集的特征信息而不是每个特征执行的一个输入(如在传统曰志文件中常见的)，以确保该文件比传统曰志文件小。然而，汇集的特征信息的使用不是本发明的限制。格式可被读取并非常有效地集成到数据库中，因为每个字段被适当地定义。传统日志文件必须逐行读取，接着数据必须从文本中解析。这通常难以实现，且因此易于出错和低质量地执行。根据无符号(unsigned)字节的数量来描述格式化。下列关键字描述了如Java虚拟机(JVM)规范定义的术语。特别是，跟随以数字的U是给定长度的无符号8位字节。Ul是单个无符号字节，而U4代表4个无符号字节。跟随以[]的U表示它是字节的阵列。包围另一字段名的[]表示该字^a名指定阵列的长度。每个事件结构优选地从基本的事件格式得到，如在下面表4中描述的。<table>tableseeoriginaldocumentpage19</column></row><table>优选地，所有事件从此一种格式得到。因此，事件优选地以Event_Type和Event—Data—Length开始，Y旦可育fe不包j舌Event—Data部分(因为事件一般用其特定的实现覆盖该字段)。在代表性的实施例中，文件格式是Base—Event的集合(collection)。特征事件类型表示一系列特征调用。每个特征在日志文件中可具有一个或更多事件。通常在不同特征的日志文件中有很多特征事件。表5在下面描述了字段。字段Feature_Name一LengthFeatureNameEx6cuticms描述名称字段的长度。特征的名称。特征被执行的次数。表5用户配置事件类型由合成者产生并允许任意数量的额外配置信息的储存。表6在下面描述了字段。字段Configurationg_Entry_Name—LengthConfigurationg_Entry—NameConfigurationg_Entry—Value_LengthConfigurationg_Entry—Value描述配置输入名的长度。配置输入名。配置的值的长度。配置输入的倡L表6下面提供了关于优选技术的额外的细节，根据本发明，日志文件由该技术处理并传输。如上所述，优选地，日志文件跟踪软件应用程序的特征、故障和/或失效，且它们以高度紧凑的轨迹(footprint)传输以允许高性能、以可升级方式的轻量处理。为了此目的，根据本发明的优选的日志文件^f各式是高度有效、连续、相关和有参考内容的。通过使用优选地在二进制文件(比方说与XML或其它人类可读文本不同)中的少量消息，以及通过压缩总数以节省日志文件空间来获得效率。优选地，所有的消息以其在真实世界出现的顺序被写入。用于消息的时间戳优选地与第一个加盖时间戳的消息有关。因此例如，假定第一个消息指示事件出现在12:00,以及第二个消息出现在12:01。第一个消息在自UTC历元(epoch)日期几毫秒内储存12:00,而第二个消息以第一个事件和第二个事件之间的毫秒的数量储存。此编码技术再一次节省了日志文件空间。^艮告机制使用时间数据方式响应的详细信息。才艮告沖;l制可分割数据，以便可每小时、每天、每星期、每月或任何其它时间度量检查特征使用信息。日志文件格式优选地也是有参考内容的，如一些消息(例如，像特征执行消息)、参考标准特征消息。而且，优选地，特征消息创建特征名称的索引并使用该索引来计数特征调用的数目。在代表性的实施例中，有几个被跟踪的不同情况。在第一种情况中，代码记录第一个特征提取。在这样的情况下，特征记录代码优选地打开新的日志文件，以及记录代码优选地按工程、配置、节点类型和特征的顺序写后面的消息。在第二种情况中，代码记录跟随特征的执行。在这种情况下，记录代码优选地只添加一个消息，指示特征执行。在第三种情况下，记录代码记录特征失效。在这种情况下，记录代码优选地只添加一个消息，指示特征失效。最后，在最后一种情况下，记录代码记录特征故障。再次只有一个消息被创建，指示特征故障。具有相关联的记录语句的样本记录代码显示在图9中。优选地，每个日志文件由一系列消息组成。每个消息一般有一些公共格式编排，并接着变成特定消息类型。下面是示例性的消息类型■节点类型消息一所使用的软件的实例的类型■工程消息一工程名称，例如被跟踪的软件的所使用的实例的名称■特征名称一纟皮跟踪的特征■启动消息一应用一呈序启动的时间■特征执行消息一所执行的特征以及它何时执行■配置消息一关于环境和配置的消息，在其中使用应用程序■用户配置消息一用于API的用户期望的额外配置信息的占位符(placeholder)(例如，收集更多关于服务器的信息，应用程序安装在该服务器上)■特征失效消息一关于特征失效的信息(特征未能完成，因为例如用户输入不正确格式的数据)、它失效的时间以及关于它为什么失效的一些信息■特征故障消息一关于故障出现(排除)的信息、它出现的时间以及关于它为什么出现的一些信息■特征复位消息一内部识别占用最小数据规模的特征的机制一在大量特征的情况下复位特征计数■子节点用户消息一关于终端用户机器的配置和环境的信息(例如，使用什么网页浏览器等)■子节点用户配置一用于关于终端用户的配置的可定制信息的占位符■子节点特征执行一在终端用户配置上执行的特征，与在服务器上执行的特征相对(需要其跟踪例如在富互联网应用程序或DHTML在终端用户客户机上执行的情况下进行处理操作的客户机，与在网络应用程序服务器上相对)■子节点失效消息一在终端用户机器上遇到的失效■子节点故障消息一在终端用户机器上出现的故障，例如贯穿浏览器的Java描述语言运行时间错误■子节点重置消息一如同具有特征重置消息，但用于终端用户特征■子类型消息一增大以跟踪额外信息的空间■无效消息一为了^r测的目的来对准日志文件内的列，以4吏它们可更容易辨认优选地，在日志文件中消息的顺序如下1.工程一优选地，每个日志文件只出现一个消息2.配置一优选地，每个日志文件可只出现一个消息3.用户配置一可出现0个或更多4.节点类型一优选地，每个日志文件可只出现一个消息5.{启动辨征|子节点用户}—每个日志文件可出现1个或更多6.(特征辨征执行l特征失效辨征故障l复位l子节点用户l子节点用户配置|子节点特征执行|子节点失效|子节点故障|子节点重置}一可出现O个或更多数据以数据库记录的方式储存在日志文件中，例如下面示出的*消息格式是"名称"大小一类型1个字节一时间戳3个字节一消息类型特定的数据根据消息类型的可变长度，例如特征执行消息或子节点用户配置或其它为了采集期望的信息同时仍然维持特征跟踪系统的高性能目标，曰志文件优选地使用现在更详细描述的二进制文件格式。图10示出代表性文件格式(用表示为十六进制的字节)。下面描述了用于产生二进制文件格式以及特别是包括一个数字并将它压缩到可能的最小数量的字节的编码方法。该方法通过将緩沖器初始化为表示零，即，最小的非负整数的^出值来开始。緩沖器中每个字节的最高位(MSB)被保留，以指示该字节是数字的一部分还是数字的末端。这意味着实际上字节只有7位包含数值，而最高位是指示符。编码过程接着继续进行以贯穿緩沖器打乱(break)从8到7位的数字，将位7的位置转移到右边。数字的MSB部分在緩冲器的每个字节内编码，MSB设置为1。数字的最后位在MSB以0编码。对数字解码是检验緩冲器的MSB是否设定为1的过程。如果是，例行程序读取7位并接着将7位的值左移到目标数据类型中，例如32或64位数据类型。当MSB设定为0时，例行程序读取剩余的7位，执行相同的移位操作并终止读过程。结果是用作编码器的输入的数字。因此，根据本发明的实施方式，数据类型表示整数，该整数被压缩以适合必要的位的最小数量。该方案优选地通过贯穿一系列字节打乱数字来工作。最初的N个字节具有设定为10xxxxxx的最高位(MSB),其中x为表示实际数字的位。最后一个字节使其MSB设定为Oxxxxxxx。通过例子来最好地观察该方案如何操作。例如，根据本方案数字1被储存为00000001。正常的编码为00000000000000000000000000000001，占用4个字节；如可看到的，本方案只使用一个字节。作为另一例子，数字1,000被储存为1000011101101000。正常的编码为00000000000000000000000011101000，占用4个字节，而本方案只使用两个字节。数字100,000被储存为100001101000110100100000。正常的编码为00000000000000011000011010100000，再次占用4个字节，而本方案只使用三个字节。此技术实质上减少了日志文件大小，特别是与人类可读(例如XML)或甚至传统的二进制数字(4个字节)编码比较时。上述日志文件格式和压缩的数据类型使系统能够以高性能方式关于特征、失效和故障跟踪非常先进的软件应用程序使用数据，该方式对终端用户是透明的。大部分为数字的大多数日志数据从磁盘提供(representative)直才妻映射到内存中表示(in-memoryrepresentation)。作为结果，数据非常紧凑，并可非常有效地加载和传输。而且，优选地，数据的位置非常明确和有序，这便于减少日志文件的总的大小。因此，在示例性实施方式中，日志文件包括一系列消息。每个消息代表一些感兴趣的事件，例如特征执行或失效。消息优选地以特定的格式和字段长度格式化。可变长度字段优选地以指示后面字段的长度的字段为前缀。数值字段优选地是可变的长度，但使用上述数据类型。如上所述，编码方案使数字能够储存在二进制字段中。如前所述，在其中说明了本发明的硬件和软件系统仅仅是代表性的。本发明可在一个或更多机器上一般以软件实践。概括而言，机器通常包括商用硬件和软件、存储器(例如，磁盘、磁盘阵列等)和内存(RAM、ROM等)。在网络中使用的特定机器不是本发明的限制。给定的机器包括网络接口和软件，以将该机器以通常的方式连接到网络。如图l所示，本发明可使用所示的机器组作为管理服务设备实现(例如，在ASP模型中)，该机器组连接或可连接到一个或更多网络。更一般地，服务设备由操作人员使用一组一个或更多与计算有关的实体(系统、机器、进程、程序、库、功能等)提供，这些实体一起便于或提供上述发明性功能。在典型的实现中，服务设备包括一组一个或更多计算机。代表性机器是运行商用(例如，奔腾类)硬件的基于网络的服务器、操作系统(例如，Linux、Windows、OS-X等)、应用程序运行期间环境(例如，Java、.ASP)以及提供给定系统或子系统的功能性的一组应用程序或进程(例如，Java小应用程序(applet)或服务器小程序(servlet)、可链接的库、本地代码等，取决于平台)。如所述，服务设备可在独立的服务器中或贯穿分布式机器组实现。一般，根据期望的实现环境，服务器连接到公开可路由(publicly-routable)的互联网、企业网(corporateintranet)、私用网络或其中的任何组合。主机服务设备可在设计成有效地调整的多服务器组环境中实现。每个服务器指派有主要和次要系列的任务。优选地，一个服务器动态地设置为主服务器，该服务器确定由所有服务器执行的次要任务。所有的服务器在数据库内更新其存在，且服务器协作来确定哪个服务器将是主服务器。组中的服务器由主服务器分配任务(例如日志输入和事件处理)。描述了我们的发明后，现在我们在下面阐述权利要求。权利要求1.一种跟踪作为一组应用程序实例而被使用的应用程序的方法，每个所述应用程序实例用工具装备以促成日志文件的产生，所述方法包括提供基于网络的主机服务设备，来自所述一组应用程序实例的所述日志文件在所述主机服务设备被接收，其中给定的日志文件包括与一组应用程序特征执行、失效和故障关联的数据；汇集所述日志文件；以及使被批准的实体能够访问并查看所汇集的所述日志文件。2.如权利要求1所述的方法，其中所述应用程序是下述中之一基于服务器的应用程序、基于网络的应用程序，和富互联网应用程序。3.如权利要求1所述的方法，其中所述日志文件通过超文本传输协议传输在所述基于网络的主机服务设备被接收。4.如权利要求1所述的方法，其中在所述日志文件中的给定信息以紧凑的凄t据结构编码，以减小所述日志文件的大小。5.如权利要求1所述的方法，其中所述日志文件数据包括与所述应用程序特征执行、失效和故障关联的一组消息，其中所述一组消息以所述应用程序特征4丸行、失效和故障的连续顺序写入。6.如权利要求5所述的方法，其中所述一组消息的至少第一个消息和第二个消息每个都具有时间戳，以及其中所述第二个消息的所述时间戳是所述第一个消息中的所述时间戳的函数。7.如权利要求l所述的方法，其中所述被批准的实体是下述中之一所述应用程序的供应商，和第三方。8.如权利要求1所述的方法，其中所述应用程序实例在整个公共网络中使用，以及所述日志文件从位于整个所述公共网络的一组终端用户接收。9.如权利要求1所述的方法，其中所述日志文件在终端用户机器产生。10.如权利要求l所述的方法，其中所述日志文件在与所述基于网络的主机服务设备关联的网关服务器产生。11.一种当网络应用程序在本地终端用户网络浏览器环境中使用时，-艮踪在整个广域网上使用的所述网络应用程序的方法，包括提供基于网络的主机服务设备，在每个本地终端用户网络浏览器环境内，由所述网络应用程序的试图使用而产生的给定的特征信息在所述主机服务设备被接收；汇集所述给定的特征信息；以及使被批准的实体能够访问和查看所汇集的所述特征信息。12.如权利要求11所述的方法，其中所述网络应用程序是下述中之一具有支持浏览器的脚本的网页，和富互联网应用程序。13.如权利要求11所述的方法，其中所述给定的特征信息通过超文本传输协议传输在所述基于网络的主机服务设备被接收。14.如权利要求11所述的方法，其中所述给定的特征信息以紧凑的数据结构编码，以减'J、所述给定的特征信息的大小。15.如权利要求11所述的方法，其中所述给定的特征信息是下述中之一特征执行、特征失效和特征故障。16.如权利要求11所述的方法，其中所述被批准的实体是下述中之一所述应用程序的供应商，和第三方。17.—种计算机可读介质，其具有用于执行权利要求1的所述方法步骤的计算机可执行的指令。18.—种服务器，其包括处理器和具有用于执行权利要求1的所述方法步骤的处理器可执行的指令的计算机可读介质。全文摘要一种基于网络的主机解决方案，应用程序开发者通过该解决方案以在线方式创建、管理并监控应用程序使用分析。优选地，经受测试的应用程序是应用程序软件、支持脚本的网络应用程序或富互联网应用程序(RIA)之一。在开发过程期间，使用监控API被集成到应用程序中，且应用程序被使用。当用户与应用程序互相作用时，一般以两种方法中的一种产生日志文件。如果应用程序能够写到本地文件系统(在用户的机器中)，使用信息在对所使用的应用程序为本地的日志文件中收集，接着发送到上载服务器，用于以批量方式处理。如果应用程序不能写到用户机器的本地文件系统，则使用信息优选地在即时的基础上发送到远程记录服务器，然后日志文件在记录服务器上产生。在任一情况下，优选地，被跟踪的使用信息包括应用程序的“特征”、“故障”和“失效”，而与所使用的应用程序实例的平台、位置和数量无关。文档编号G06F15/16GK101371245SQ200680033282公开日2009年2月18日申请日期2006年7月7日优先权日2005年7月12日发明者大卫·J·安琪尔,安德鲁·S·威尔逊,布莱恩·J·施恩申请人:维兹博麦哲思公司