根据使用数据的结构化日志模式的服务度量分析专利检索-许可空中管制专利检索查询-专利查询网

根据使用数据的结构化日志模式的服务度量分析

阅读：969发布：2024-01-12

专利汇可以提供根据使用数据的结构化日志模式的服务度量分析专利检索，专利查询，专利分析的服务。并且技术通常被描述为提供应用日志模式以追踪使用数据以便对服务的性能和可靠性进行分析的被动监测系统。该日志模式可以被配置为当在协同服务的独立的子系统中接收和处理每个请求时，对用户请求进行追踪。可以在服务的数据存储处创建日志条目，其中，日志条目包括子系统名称、由子系统执行的用于满足请求的操作、操作的开始时间和结束时间。日志模式还可以检测满足请求的错误，并且将所检测到的错误分类到桶中，其中每个桶指示一个失败场景。可以基于对桶的分析来计算错误率从而计算服务的可靠性。可以生成报告以启用对系统的性能和可靠性的持续监测。，下面是根据使用数据的结构化日志模式的服务度量分析专利的具体信息内容。

权利要求

1.一种方法，其至少部分地在计算设备中执行以提供应用日志模式以在服务处追踪请求的被动监测系统，所述方法包括：
检测由所述服务接收的请求；
在与所述服务相关联的数据存储处创建针对所述请求的日志条目；
确定所述请求是否被所述服务满足；
响应于确定所述请求被满足，将所述请求分类为成功桶中的成功；
响应于确定所述请求没有被满足，将所述请求分类为错误桶中的所检测到的错误，其中，所述错误桶表示所定义的失败场景；以及
基于成功桶和错误桶的百分比来确定所述服务的可靠性。
2.根据权利要求1所述的方法，还包括：
标识接收所述请求的子系统；
标识由所述子系统执行来满足所述请求的操作；以及
标识被执行来满足所述请求的操作的开始时间和结束时间。
3.根据权利要求2所述的方法，还包括：
在所述数据存储处将所述子系统、所述操作、被执行来满足所述请求的所述操作的所述开始时间和所述结束时间包括在所述日志条目中。
4.根据权利要求1所述的方法，还包括：
在所述数据存储处利用针对所述请求的所述日志条目来记录所述所检测到的错误的错误描述。
5.根据权利要求1所述的方法，还包括：
生成报告，所述报告包括以下中的一项或多项的所确定的可靠性：所述服务、所述服务的一个或多个特征、以及所述服务的一个或多个子系统。
6.根据权利要求5所述的方法，其中，所述报告包括对所述服务的性能的分析。
7.根据权利要求5所述的方法，其中，所述报告包括与所述服务相关联的所检测到的一个或多个错误的原始数据。
8.根据权利要求1所述的方法，还包括：
如果所检测到的错误不属于预先存在的错误桶，则创建针对所述所检测到的错误的新的错误桶。
9.根据权利要求1所述的方法，还包括：
如果所检测到的错误的数量超过预先定义的阈值，则生成警报。
10.一种计算设备，其用于提供应用日志模式以在服务处追踪请求的被动监测系统，所述计算设备包括：
被配置为存储一个或多个指令的存储器；以及
耦合至所述存储器的处理器，其中，所述处理器被配置为：
检测由所述服务接收的请求；
在与所述服务相关联的数据存储处创建针对所述请求的日志条目；
确定所述请求是否被所述服务满足；
响应于确定所述请求被满足，将所述请求分类为成功桶中的成功；
响应于确定所述请求没有被满足，将所述请求分类为错误桶中的所检测到的错误，其中，所述错误桶表示所定义的失败场景；以及
基于成功桶和错误桶的百分比来确定所述服务的可靠性。
11.根据权利要求10所述的计算机设备，其中，所述服务器是促成以下中的一个或多个的协同服务：通信交换、文档共享、企业管理、文档管理、文件管理、协同、社交网络联系人管理、日历管理、数据共享、以及应用共享。
12.根据权利要求10所述的计算设备，其中，所述请求是以下中的一个或多个：发起应用、打开文档、发起会话、与文档或应用交互、以及取回与应用相关联的数据。
13.根据权利要求10所述的计算设备，其中，所述处理器还被配置为：
在所述数据存储处利用所述日志条目来记录所述所检测到的错误的错误描述，其中，所述错误描述包括内部错误代码以及错误类型。
14.根据权利要求10所述的计算设备，其中，所述处理器还被配置为：
基于所确定的所述服务的可靠性和性能而生成报告；并且
对真实用户请求与合成的请求进行区分，并且从所生成的报告中移除合成的请求。
15.一种计算机可读存储设备，其具有存储在其上的用于提供应用日志模式以在服务处追踪请求的被动监测系统的指令，所述指令包括：
检测由所述服务接收的请求；
在与所述服务相关联的数据存储处创建针对所述请求的日志条目；
确定所述请求是否被所述服务满足；
响应于确定所述请求被满足，将所述请求分类为成功桶中的成功；
响应于确定所述请求没有被满足，将所述请求分类为错误桶中的所检测到的错误，其中，所述错误桶表示所定义的失败场景；以及
基于成功桶和错误桶的百分比来确定所述服务的可靠性。

说明书全文

根据使用数据的结构化日志模式的服务度量分析

背景技术

[0001] 在协同的环境中，用户可以通过网络与协同服务进行交互。协同服务可以是通过网络同时向许多用户提供众多应用和功能的服务。协同服务可以监测来自多个用户的业务模式和数据请求，以便持续地监测服务的性能和可靠性。追踪在协同服务上所接收到并由服务的多个子系统所处理的大量数据请求可能产生一组复杂的数据，并且对这些数据进行聚合与分类来提取关于服务的有价值的度量以用于持续评估系统的性能和可靠性是困难的。发明内容

[0002] 提供了该发明内容以用简化的形式介绍在下文的具体实施方式部分中所进一步描述的概念的选择。该发明内容不旨在排他地标识所要求保护的主题的关键特征或本质特征，也不旨在作为帮助用来确定所要求保护的主题的范围。

[0003] 实施例涉及应用日志模式以在协同服务处追踪使用数据的监测系统。日志模式可以被配置为当在协同服务的独立的子系统中接收和处理请求时，对用户请求进行追踪。可以在服务的数据存储处创建日志条目，其中，所述日志条目可以包括对请求进行处理的子系统、由子系统执行的以满足请求的操作、操作开始时间和结束的时间、请求的场所信息、以及在满足请求时所检测到的错误。日志模式可以在服务的子系统处启用错误检测以提供对服务的性能和可靠性的持续监测。

[0004] 通过阅读以下的详细描述并回顾相关联的附图，这些和其他特征和优点将变得明显。应当理解的是，前述的一般描述以及下文的详细描述两者都是解释性的而不限制所要求保护的方面。

附图说明

[0005] 图1示出了在其中用户可以通过网络与协同服务进行交互的基于云的示例环境；

[0006] 图2示出了包括其中可以实现用于追踪使用数据的日志模式的多个子系统的服务的示例架构；

[0007] 图3示出了在服务处记录使用数据并生成错误报告的概念图；

[0008] 图4是其中可以实现根据实施例的系统的网络化环境；

[0009] 图5是其中可以实现实施例的示例计算操作环境的框图；并且

[0010] 图6示出了根据实施例的提供被动监测系统的过程的逻辑流程图，所述被动监测系统应用日志模式来追踪使用数据以便分析服务的性能和可靠性。

具体实施方式

[0011] 如在上文中所简要描述的，监测系统被描述为记录使用数据并且提供对服务(例如，协同服务)的性能和可靠性的分析。该监测系统可以将日志模式应用至由一个或多个协同服务的子系统所接收和处理的请求以满足请求。可以在服务的数据存储处创建日志条目，其中，日志条目可以包括关于每个单独的请求的信息。每个日志条目可以包括对请求进行处理的子系统名称、由子系统执行的用于满足请求的操作、操作的开始时间和结束时间、用户场所信息、以及在处理请求时所检测到的错误。日志模式还可以启用对满足请求的错误的持续检测。可以将所检测到的错误分类到错误桶中，其中每个桶指示一个失败场景。可以基于对桶的分析来计算错误率从而计算服务的可靠性。可以生成报告以启用对系统的性能和可靠性的持续监测。

[0012] 在以下的具体实施方式中，对形成了其一部分并且在其中作为说明而示出了具体的实施例或示例的附图进行了参考。可以组合这些方面、可以利用其它方面、并且可以做出结构改变而不脱离本公开的精神或范围。因此，以下的具体实施方式将不被看作是限制性意义，并且本发明的范围是由所附权利要求及其等同物所限定的。

[0013] 尽管将在结合在个人计算机的操作系统上运行的应用程序而执行的程序模块的一般性的上下文中描述一些实施例，但是本领域技术人员将理解的是，也可以结合其它程序模块来实现这些方面。

[0014] 通常而言，程序模块包括例程、程序、组件、数据结构、以及执行特定的任务或实现特定的抽象数据类型的其他类型的结构。此外，本领域技术人员将理解的是，可以利用包括手持设备、多处理器系统、基于微处理器的或可编程的消费性电子产品、微型计算机、大型计算机、以及类似的计算设备在内的其它计算机系统配置来实践实施例。还可以在其中任务是由通过通信网络链接的远程处理设备来执行的分布式计算环境中实现实施例。在分布式计算环境中，程序模块既可以位于本地的存储器存储设备中，也可以位于远程的存储器存储设备中。

[0015] 可以将实施例实现为计算机实现的过程(方法)、计算系统、或者诸如计算机程序产品或计算机可读介质之类的制品。计算机程序产品可以是可以由计算机系统读取的计算机存储介质，并且对包括指令的计算机程序进行编码以使得计算机或计算系统执行示例过程。计算机可读存储介质是计算机可读存储器设备。计算机可读存储介质可以例如经由易失性计算机存储器、非易失性存储器、硬盘驱动器、闪存驱动器、软盘、或者光盘、以及类似的介质中的一个或多个而被实现。

[0016] 在该说明书通篇中，术语“平台”可以是用于对系统进行监测以记录使用数据并且提供对服务的性能和可靠性的分析的软件组件和硬件组件的组合。平台的示例包括但不限于：在多个服务器上执行的托管服务、在单个计算设备上执行的应用、以及类似的系统。术语“服务器”通常是指通常在网络化环境中执行一个或多个软件程序的计算设备。然而，服务器还可以被实现为在被视为是网络上的服务器的一个或多个计算设备上执行的虚拟服务器(软件程序)。在下文中提供了关于这些技术和示例操作的更多的细节。

[0017] 图1示出了根据一些示例实施例的在其中用户可以通过网络与协同服务进行交互的基于云的示例环境。

[0018] 如在图100中所示，用户(102、104和106)可以通过基于云的网络110来访问诸如协同服务112之类的服务或应用。协同服务112可以在远程服务器处托管，并且可以通过基于云的网络110而通过用户的客户端设备来访问。协同服务112的本地版本也可以本地地托管在用户客户端设备处，并且可以通过基于云的网络110来取回与本地协同服务112相关联的数据。一些示例客户端设备可以包括膝上型计算机136、台式计算机132、智能电话134、车载电话、移动电话、平板计算机、和/或家庭自动化设备。尽管将网络描述为基于云的网络，但实施例不限于基于云的网络，并且可以以各种本地的和托管的网络来实现。

[0019] 示例协同服务112可以是使得多个用户能够通过网络(例如，基于云的网络110)来访问与服务相关联的多个应用的服务。与服务相关联的应用可以提供多个工具和功能，例如，文档和文件管理、协同、社交网络、外联网、网站、企业管理、文档共享、电子邮件、文本消息传输、互联网协议语音(VOIP)、会议技术、即时通讯、电话通话、联系人管理、日历管理、以及其他类似的功能等。协同服务112还可以提供系统集成、过程集成、以及工作流程自动化功能。可以从协同服务112中接收与协同服务112相关联的不同类型的数据，例如软件数据、应用数据、通讯数据(例如电子邮件消息、文本消息、即时消息、语音信箱消息)以及其他类似数据，并且在用户客户端设备处进行交互。

[0020] 可以将与协同服务112相关联的数据托管在与协同服务112相关联的数据存储器116处。数据存储器116可以按照与协同服务112相关联的应用所请求的来取回并存储数据，所述应用包括跨网络(例如，基于云的网络110)而在个人客户端设备上本地执行的应用。在示例实施例中，当用户从用户客户端设备通过网络与协同服务112进行交互时，可以将请求发送至协同服务112以取回数据以便响应并满足该请求。示例请求可以包括开始应用、打开文档、发起会话、与文档或应用交互、取回与应用相关联的数据、以及其他类似的请求。协同服务112可以通过网络从访问协同服务112的多个用户处持续地接收多个请求。追踪多个数据请求可以启用对协同服务112的性能的详细监测，并且可以启用对协同服务112的各种服务度量和关键性能指标(例如，用户业务、可靠性、和错误率)的计算。根据实施例的系统可以提供被动监测系统，以当协同服务112的子系统接收并处理请求时根据日志模式来记录使用数据。基于所记录的使用数据，可以生成性能和可靠性报告以启用待持续监测、分析、和提升的协同服务。

[0021] 图2示出了根据一些实施例的包括其中可以实现用于追踪使用数据的日志模式的多个子系统的服务的示例架构。

[0022] 如在图200中所示，协同服务210可以包括被配置为通过网络从客户端设备202接收请求218并且执行操作来处理请求218的多个子系统或层。示例子系统可以包括前端204、中间层、以及后端数据存储222，其中前端204可以最初通过网络从客户端设备202接收请求，，中间层可以包括被配置为满足特定的数据请求218的多个子系统(例如，206、212)，并且后端数据存储222可以存储与协同服务210的每个子系统相关联的数据。不同的子系统可以在与协同服务210相关联的不同的虚拟机上执行，或者在同一个虚拟机上执行。额外地，协同服务210还可以执行一组操作来满足请求，其中这一组操作可以不局限于特定的子系统。

[0023] 根据实施例，被动监测系统可以被配置为在处理请求并且将响应返回至用户之前，当请求218跨协同服务的不同的子系统以及虚拟机而顺序或并行传递时，追踪请求218。被动监测系统还可以被配置为在后端数据存储器222处应用日志模式来记录所追踪的使用数据。日志模式可以被配置当在每个请求在协同服务210的每个单独子系统上被接收并处理时，实时地追踪使用数据以便追踪请求的处理路径。日志模式可以在子系统级追踪使用数据，并且还可以追踪并记录每个子系统内的用于处理请求的子操作的使用数据。在示例场景中，每个请求都可以在其进入和退出协同服务210的每个子系统(例如，206、212)时被追踪，并且日志模式可以基于后端数据存储222中的条目而针对由协同服务210接收并处理的每个请求来提供子系统和操作。后端数据存储222处的每个条目可以包括子系统和操作的名称、从每个子系统进入和退出的时间、由子系统执行以满足请求的操作的开始时间和结束时间、初始请求的用户场所信息、以及与每个子系统处的对请求的处理相关联的错误信息。后端处的数据存储可以包括被配置为从作为分布式系统的一部分的多个不同的服务接收使用信息的数据存储接口。与协同服务210相关联的数据存储还可以是作为210的一部分的、与协同服务分离地托管的外部数据存储。外部数据存储可以从作为分布式系统的一部分的多个不同的服务中接收数据。

[0024] 在示例场景中，当接收到请求时，日志模式可以对在其中接收到请求并且在其中发起操作的子系统进行标识和命名。子系统的名称可以是对请求进行处理的协同服务210的组件。额外地，日志模式可以定义由子系统执行以处理请求的特定的操作。还可以记录在子系统处的操作的开始时间和结束时间。可以将结束时间与开始时间一起使用以确定子系统对请求提供响应的响应时间或处理时间。保存用户请求的记录可以使得协同服务210能够持续地监测服务性能、业务，并且追踪错误以确定服务可靠性。基于看到最少和最多使用的用户业务子系统以及关于与服务的用户交互的性质(例如，在各种场景下由用户所执行的操作的模式)的观察，用户请求的记录还可以使得能够观察服务的热门特征。

[0025] 在根据实施例的系统中，被动监测系统还可以在子系统处理请求218时启用错误检测和错误追踪以启用对服务可靠性的确定。当在子系统中的一个子系统处检测到处理请求的错误时，日志模式可以利用在后端数据存储222处的日志条目来记录错误。日志条目可以包括错误描述，所述错误描述可以包括对所发生的处理错误类型的详细描述以及其中发生错误的子系统的名称。错误描述可以包括内部错误代码，所述内部错误代码可以是可以由协同服务210所识别的针对错误的本地代码标识符。可以将内部错误代码映射至错误描述以提供协同服务210的用户能够识别和理解的对用户友好的错误描述。可以将面向用户的错误信息本地化，以使得对于同一个内部错误，可以生成基于用户定位的不同的错误信息。针对错误的日志条目还可以包括错误类型，所述错误类型可以包括用于对针对在子系统处的请求和相关联的操作所检测到的错误类型进行分类的与场所无关的字符串。

[0026] 图3示出了根据一些实施例的在服务处记录使用数据并生成错误报告的概念图。

[0027] 如前所述，被动监测系统可以应用日志模式来在协同服务310的子系统处追踪使用数据，以便提供关于协同服务310的性能和可靠性的详细信息。如在图300中所示，可以在协同服务310处接收一个或多个请求304，并且可以在协同服务310的一个或多个子系统(例如302、308)处处理一个或多个请求304。可以在协同服务310的数据存储器处记录特定于操作和子系统的使用数据320，以创建与协同服务相关联的使用数据的详细记录。例如，每次在子系统处接收并处理请求时，可以记录对请求进行处理的子系统，并且还可以报告所执行以处理请求的操作。可以在数据存储处记录包括与请求相关联的具体的子系统和操作的日志条目。所述日志条目可以包括与请求相关的额外的数据，所述数据包括请求开始和结束的时间、以及用户场所信息。用户场所信息和其他用户可识别的信息可以是匿名的，以保护个人用户隐私。被动监测系统还可以使得服务的特定的子系统和/或操作能够被监测，以便确定协同服务的特定的子系统的性能和可靠性以及协同服务整体的性能和可靠性。

[0028] 为了提供对协同服务的性能和可靠性的分析，可以实现错误检测和错误追踪。当在协同服务310的子系统(例如302、308)处接收到请求304时，被动监测系统可以检测该请求是否被满足。如果该请求被满足，则将该请求记录为成功。如果该请求没有被满足，则将该请求记录为所检测到的错误。可以利用所记录的错误来生成针对协同服务310的性能和可靠性的报告314。

[0029] 在根据实施例的系统中，为了生成错误检测记录以启用服务可靠性分析，系统可以监测在协同服务310的一个或多个子系统(302、308)处所接收到的每个请求，并且在对请求进行处理中检测到错误之后，可以记录该错误。可以将所检测到的每个错误分类到关于错误类型的桶322、或种类中，其中，每个桶322都指示不同的失败场景和成功场景。例如，桶可以指示特定的错误类型或者可以指示特定的场景，例如需要进一步的用户操作以便完成操作的场景。额外地，也可以将其他请求类型分类到与特定的请求类型相关联的桶中。在示例场景中，当首次检测到错误时，可以将错误分类到初始的未分类的桶322中，直到确定了错误类型为止。在确定了错误类型之后，可以根据所述错误类型将错误分类到有标签的桶322中。随后，可以基于错误类型将所检测到的错误分类到预先存在的桶中。如果新检测到的错误不属于预先存在的错误桶，则可以创建新的桶。可以基于新检测到的错误场景而持续增加新的桶322。可以创建额外的错误桶以在错误是由于操作不被协同服务支持的事实而产生的情况下，对所检测到的错误进行分类。成功桶可以存储被记录为成功的请求。可以基于对桶322的分析来计算错误率从而计算协同服务310的可靠性。可以针对每个桶来计算绝对数和百分比，并且可以将整体的服务可靠性测量为“成功”桶和“错误”桶的百分比的总和。

[0030] 在根据实施例的系统中，可以基于所记录的错误数据来生成报告314。可以针对任何时段而生成报告314，例如，每日、每周、每月、每年、或其他可定制的时段。额外地，可以基于默认参数来提供报告314，也可以基于管理员或用户定制的参数来生成报告314。在一些实施例中，所生成的报告314可以被配置为提供显示与服务的子系统和操作相关联的所检测到的错误的统计的原始数据。在其他实施例中，报告314可以基于预先定义的设置和可定制的设置而提供对数据的分析。例如，报告314可以提供对特定的操作类型或子系统的性能分析、或其他指定的参数。可以通过解释可以影响请求是否有类似的预期的性能的因素(例如，请求的成功/失败、预期的待由请求来处理的数据的总量、以及其他类似的参数)来确定性能分析。此外，所生成的报告314可以提供服务性能的可审核性。例如，报告可以提供关于错误率和服务可靠性的实时的真实用户数据，并且协同服务310可以向客户端提供报告以展示实际错误率并保证可靠性。被动监测系统还可以被配置为对真实用户数据和合成的数据(例如，机器人数据)进行区分，并且基于真实用户数据而提供报告，从而提供基于真实用户数据的对协同服务的性能及可靠性的准确分析。也可以基于所记录的数据和报告来评估特定的子系统、特征、或一系列操作的可靠性。额外地，可以对报告进行过滤以启用对协同服务310的特定的子系统和操作的分析。

[0031] 在额外的实施例中，被动监测系统可以被配置为基于所记录的使用和错误数据来生成警报。如之前所讨论的，被动监测系统可以是可定制的，以使得管理员可以对来自待监测的服务的具体的子系统的操作进行标定。在进一步的实施例中，可以针对失败的操作和服务故障来监测经标定的操作和子系统中的每一个，以启用对服务性能、可用性、和可靠性的持续监测。被动监测系统可以被配置为如果错误率(或用户请求失败)超过预先定义的阈值或期望，则提供自动警报。错误率阈值可以是可配置的值。被动监测系统可以被配置为识别重复的错误并且针对新的或之前从未见过的错误而发出警报，使得不会针对同一错误而多次提供同一警报。在另一个实施例中，当检测到特定的错误时，可以自动地提供故障诊断信息以帮助用户和管理员解决特定的错误。也可以提供自动愈合脚本以解决在协同服务310处所检测到的错误，而不导致将由协同服务310的用户所感受到的性能的降低。

[0032] 在额外的实施例中，可以利用经记录的所检测到的错误来追踪并修复服务故障。可以通过检查未分类错误桶来识别所检测到的常见错误以及错误模式从而识别潜在的故障。服务的故障追踪组件可以被配置为针对故障而持续地检查错误桶，并且自动修复所检测到的故障。故障追踪组件还可以被配置为标记未被修复或无法被修复的故障。例如，在一些情况下，系统可以出于多种不同的原因而选择不修复故障，或者在其它场景中，故障可以无法被修复。故障追踪组件可以对无法被修复的错误和系统选择不进行修复的错误进行区分和指示。故障追踪组件还可以指示做出不进行修复的决策在可靠性和/或期望的增益的损失方面在协同服务310未来的可靠性和/或性能中的影响。故障追踪组件可以进一步被配置为提供警报来指示故障的存在。可以创建针对所检测到的故障的单独的桶，该桶可以使能够创建针对故障的可靠性报告。该可靠性报告可以指示百分之多少的故障已被修复并作为下次服务更新的一部分来部署、以及百分之多少的故障被标记为“无法被修复”。可以在可扩展服务部署场景中利用对故障的检测以在最终部署之前对服务进行改进。例如，可以将服务部署至第一组用户，并且可以针对错误和故障来对服务进行监测。随后，可以将服务部署至更大的组，并且针对错误和故障来进行监测，直至最终部署至指定的组或公共部署为止。在部署的每一层上，可以监测并收集包括错误数据和故障数据的使用数据，以创建对服务的性能和可靠性的综合分析，并且改进最终部署的性能和可靠性。

[0033] 在进一步实施例中，可以根据用户场所来对使用数据进行本地化，并且使用数据可以包括可以基于用户场所而被本地化成不同的语言的数据字符串。可以独立于用户场所来对错误数据进行分类，以便一起分类所有使用数据，而无须由日志模式进行专业化、本地化的处理来对错误数据进行分类。也可以将具体的用户信息匿名化来保护用户隐私。

[0034] 被动监测系统可以根据服务需要是可扩展和可定制的。协同服务310的用户和管理员可以能够访问在数据存储处所记录的数据以便对协同服务310的性能进行分析。可以定义并追踪在协同服务的每个子系统处的额外的数据类型，以使得日志模式能够根据协同服务310的需要是可扩展和可定制的。管理员还可以能够根据服务需要来定义从哪些子系统收集数据以及数据收集的频率。

[0035] 在图1-3中所描述的示例应用、设备和模块仅仅是出于说明的目的而提供的。实施例不限于在示例图中所示出的配置和内容，并且可以使用应用了在本文中所描述的原理的其它引擎、客户端应用、服务提供商、和模块来实现。

[0036] 图4是其中可以实现实施例的示例网络化环境。除了本地安装的应用，还可以提供被动监测系统来追踪子系统间的使用数据，并且确定服务的性能和可靠性。还可以结合可以经由在一个或多个服务器406或者独立的服务器414上执行的软件而实现的托管的应用和服务来应用被动监测系统。托管的服务或应用可以通过网络410与独立的计算设备(例如，手持式计算机、台式计算机401、膝上型计算机402、智能电话403、平板计算机(或平板电脑)(“客户端设备”))上的客户端应用进行通信，并且控制呈现给用户的用户界面。

[0037] 客户端设备401-403可以用于访问由托管的服务或应用所提供的功能。服务器406或服务器414中的一个或多个可以用于提供上文中所讨论的多种服务。可以将相关的数据存储在可以由服务器406中的任何一个或者由数据库服务器408来管理的一个或多个数据存储(例如，数据存储409)中。

[0038] 网络410可以包括服务器、客户端、互联网服务提供商、以及通信介质的任何拓扑结构。根据实施例的系统可以具有静态的拓扑结构或动态的拓扑结构。网络410可以包括诸如企业网络之类的安全网络，诸如无线开放网络之类的非安全网络，或者互联网。网络410还可以协调通过诸如PSTN或蜂窝网络之类的其它网络的通信。网络410在本文中所描述的节点之间提供通信。作为示例而非限制，网络410可以包括无线介质，例如声学、RF、红外、和其它无线介质。

[0039] 可以应用计算设备、应用、数据源、以及数据分布系统的许多其它配置来实现应用日志模式来对服务或应用的子系统间的使用数据进行追踪的被动监测系统。此外，在图4中所讨论的网络化环境仅仅出于说明的目的。实施例不限于示例应用、模块、或过程。

[0040] 图5和相关联的讨论旨在提供关于其中可以实现实施例的合适的计算环境的简短、概括的描述。参考图5，示出了根据实施例的应用的示例计算操作环境(例如，计算设备500)的框图。在基本配置中，计算设备500可以是在本文中所讨论的示例设备中的任何一个，并且可以包括至少一个处理单元502和系统存储器504。计算设备500还可以包括在执行程序的过程中协作的多个处理单元。取决于计算设备的确切的配置和类型，系统存储器504可以是易失性的(例如，RAM)、非易失性的(例如，ROM、闪速存储器等)或者两者的一些组合。
系统存储器504通常包括适用于控制平台的操作的操作系统506，例如，来自Washington州Redmond市的MICROSOFT公司的操作系统、WINDOWS 操作系统、
或者WINDOWS 操作系统。系统存储器504还可以包括一个或多个软件应用，例如，使用数据记录应用522和错误追踪模块524。

[0041] 错误追踪模块524可以结合操作系统506或使用数据记录应用522来操作以当在协同服务上接收到请求并由协同服务的一个或多个子系统处理请求时对请求进行监测，并且检测在对请求进行处理的过程中的失败。结合使用数据记录应用522，错误追踪模块524可以检测在请求处理的过程中何时发生错误，并且可以创建所检测到的错误的记录。可以将所检测到的错误分类到桶中以创建服务错误的综合记录。在图5中由虚线508内的那些组件示出了该基本配置。

[0042] 计算设备500可以具有额外的特征或功能。例如，计算设备500还可以包括额外的数据存储设备(可移动的和/或不可移动的)，例如，磁盘、光盘、或磁带。在图5中由可移动存储设备509和不可移动存储设备510示出了这样额外的存储设备。计算机可读存储介质可以包括以用于存储信息(例如，计算机可读指令、数据结构、程序模块、或其它数据)的任何方法或技术实现的易失性的和非易失性的、可移动的和不可移动的介质。系统存储器504、可移动存储设备509、和不可移动存储设备510全部都是计算机可读存储介质的示例。计算机可读存储介质包括但不限于RAM、ROM、EEPROM、闪速存储器或其它存储器技术、CD-ROM、数字通用盘(DVD)、或其它光存储、盒式磁带、磁带、磁盘存储设备或其它磁存储设备、或者可以用于存储期望的信息并且可以由计算设备500访问的任何其它介质。任何这样的计算机可读存储介质都可以是计算设备500的一部分。计算设备500还可以具有输入设备512，例如，键盘、鼠标、笔、语音输入设备、触摸输入设备、用于检测手势的光学捕获设备、以及类似的输入设备。也可以包括诸如显示器、扬声器、打印机、和其它类型是输出设备之类的输出设备514。这些设备是本领域中公知的并且不需要在这里详细讨论。

[0043] 计算设备500还可以包含通信连接516，其允许设备例如通过分布式计算环境中的有线或无线网络、卫星链路、蜂窝链路、以及类似的机制来与其它设备518进行通信。其它设备518可以包括执行通信应用的计算机设备、其它目录或策略服务器、以及类似的设备。通信连接516是通信介质的一个示例。通信介质可以在其中包括计算机可读指令、数据结构、程序模块、或者经调制的数据信号(例如，载波或其它传输机制，并且包括任何信息传递介质)中的其它数据。术语“经调制的数据信号”是指这样的信号：具有使该信号的特性集中的一个或多个以如将信息编码在信号中的方式来设置或改变的信号。作为示例而非限制，通信介质包括诸如有线网络或直接有线连接之类的有线介质，以及诸如声学、RF、红外、和其它无线介质之类的无线介质。

[0044] 示例实施例还包括用于提供应用日志模式来追踪使用数据以便对服务的性能和可靠性进行分析的被动监测系统的方法。这些方法可以以包括在该文档中所描述的结构的多种方式来实现。一种这样的方式是通过在该文档中所描述的类型的设备的机器操作。

[0045] 另一种可选的方式是针对结合执行一些操作的一个或多个人类操作者而将被执行的方法的独立操作中的一个或多个。这些人类操作者不需要彼此处于同一位置，但每个操作者可以与执行程序的一部分的机器在一起。

[0046] 图6示出了根据实施例的用于提供应用日志模式来追踪使用数据以便对服务的性能和可靠性进行分析的被动监测系统的方法的过程的逻辑流程图。过程600可以被实现为应用或操作系统的一部分。

[0047] 过程600开始于操作610：“在服务处检测用户请求”，其中在协同服务处接收用于执行操作的请求。请求可以是由用户通过网络利用协同服务所接收到的、用于执行与在用户的客户端设备处所访问的应用相关联的操作的任何请求。

[0048] 操作620：“创建与所检测到的请求和操作相关联的日志条目”紧接着操作610，其中，日志条目是在与服务相关联的数据存储处创建的。日志条目可以包括处理请求的子系统名称、操作标识、以及请求的开始时间与结束时间。

[0049] 操作630：“检测满足请求的错误”紧接着操作620，其中，识别出由子系统执行以满足请求的操作，并且检测出执行操作以满足请求的错误。

[0050] 操作640：“将错误分类到错误桶中”紧接着操作630，其中，可以将所检测到的错误分类到错误桶中，其中，桶指示失败场景。可以基于错误类型将所检测到的错误分类到预先存在的桶中，或者如果所检测到的错误不属于预先存在的错误桶，则可以创建新的桶。

[0051] 操作650：“生成性能和可靠性报告”紧接着操作640，其中，可以基于对桶的分析来将计算错误率从而计算服务的性能和可靠性。可以基于所记录的错误数据来生成报告，以使得服务的管理员能够评估并改进服务。

[0052] 在过程600中所包括的操作是出于说明的目的的。可以通过具有更少或更多的步骤的类似的过程，以及使用在本文中所描述的原则的不同顺序的操作来实现根据实施例来提供应用日志模式以追踪使用数据以便对服务的性能和可靠性进行分析的被动监测系统。

[0053] 以上的说明书、示例、和数据提供了对实施例的组成部分的制造和使用的完整说明。尽管已经用特定于结构特征和/或方法行为的语言描述了主题，但应当理解的是，在所附权利要求中所定义的主题非必须限于在上文中所描述的具体的特征或行为。相反，在上文中所描述的具体的特征和行为是作为实现权利要求和实施例的示例形式而公开的。

标题	发布/更新时间	阅读量
用于模制光学组件和光学组件的模制过程和装置	2020-05-08	712
机器视觉处理系统、设备、方法及计算机可读存储介质	2020-05-08	352
一种电力系统云服务的网络安全防护系统、装置及方法	2020-05-11	343
在表面重构中使用自由形式变形	2020-05-08	30
请求响应方法、装置、设备和存储介质	2020-05-11	868
一种浮球式ROV对接与释放装置	2020-05-11	522
用于未许可频谱中的蜂窝通信的唤醒信号	2020-05-08	664
信息处理装置和其方法及存储介质	2020-05-08	104
一种轮边减速器壳密封结构	2020-05-08	910
一种消防泡沫发生器	2020-05-08	586

根据使用数据的结构化日志模式的服务度量分析

根据使用数据的结构化日志模式的服务度量分析

背景技术

附图说明

具体实施方式

该功能需要专业版企业版VIP权限，您可以：