HK1174704B - Monitoring federation for cloud based services and applications - Google Patents

Description

Monitoring federation for cloud-based services and applications

Background

Management systems, such as those used in Information Technology (IT) operations, may track various services and applications. Traditionally, these services and applications are located and operated within the physical premises of the enterprise. With the increasing deployment of cloud-based services, cloud-based applications, software as a service, service oriented architectures, and the like, the location of services and applications is crossing physical, jurisdictional, and security boundaries.

Conventional IT management systems are typically not equipped to provide visibility into or control of services and applications that reside outside the jurisdiction of the enterprise IT operations. Traditional applications and services are not suitable for the health of other cloud components, even though such information can support decisions to improve customer experience or reduce costs. Moreover, conventional IT management systems do not provide a complete view of the quality of service from within the organization and from outside the organization. This limitation exists especially if the relevant application or service is hosted in the cloud, or both internally and in the cloud.

It is with respect to these and other considerations that the present disclosure made herein is set forth.

SUMMARY

Described herein are techniques for a cloud monitoring federation, which may include a Cloud Monitoring Service (CMS) that collects monitoring information from point of presence (POP) agents. The cloud monitoring POP may be located in the cloud, on a client machine, embedded within a cloud application, or anywhere they can gain visibility into managed entities associated with the cloud. As used herein, a cloud may refer to a network environment for providing abstract access to services, applications, and data located within a network. By utilizing the techniques and concepts presented herein, a management system acting as a Cloud Monitoring Client (CMC) may interface with the CMS to obtain a complete view of the services and applications used by their enterprise, including those operating outside the enterprise premises as part of the cloud or outside network. The publishing of management information by a POP and the consumption of management information by a CMC across components within an enterprise and in a cloud outside of the enterprise may be supported by administrative roles, responsibilities, scopes, security boundaries, authenticity of information, service level agreements, and other aspects of cloud monitoring operations.

It should be appreciated that the above-described subject matter may be implemented as a computer-controlled apparatus, a computer process, a computing system, or as an article of manufacture such as a computer-readable medium. These and various other features will become apparent from a reading of the following detailed description and a review of the associated drawings.

This summary is provided to introduce a selection of concepts in a simplified form that are further described below in the detailed description. This summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended that this summary be used to limit the scope of the claimed subject matter. Furthermore, the claimed subject matter is not limited to implementations that solve any or all disadvantages noted in any part of this disclosure.

Brief Description of Drawings

FIG. 1 is a block diagram illustrating a cloud monitoring federation in accordance with one or more embodiments presented herein;

FIG. 2 is a schematic diagram illustrating more details regarding a cloud monitoring federation in accordance with one or more embodiments presented herein;

FIG. 3 is a flow diagram showing an illustrative process for a cloud monitoring service in accordance with one or more embodiments presented herein;

FIG. 4 is a flow diagram showing an illustrative process for cloud monitoring a point of presence in accordance with one or more embodiments presented herein;

FIG. 5 is a flow diagram showing an illustrative process for a cloud monitoring client in accordance with one or more embodiments presented herein; and

FIG. 6 is a computer architecture diagram showing an illustrative computer hardware architecture for a computing system capable of implementing the embodiments presented herein.

Detailed Description

The following detailed description is directed to techniques for cloud-based service and application monitoring. By utilizing the techniques and concepts presented herein, a cloud monitoring client can interface with a cloud monitoring service to obtain a complete view of services and applications used within an enterprise, including those operating outside of the enterprise premises as part of the cloud or external network. As mentioned briefly above, a cloud may refer to a network environment for providing abstract access to services, applications, and data located within a network.

An example of a cloud-based service may include a Service Oriented Architecture (SOA), where the entire service component may be owned and operated by an external organization. Other examples may include hosted cloud services, where all or part of the service may be hosted on an enterprise or third party hosted service. The hosting service may host a virtual machine or application component. Other examples may provide a platform of cloud services for use by enterprise services. For example, a passport authentication service, a credit card verification system, or a cloud database system may be used as a cloud service by other enterprise services. Other examples may include software as a service (SaaS), such as an application accessible by an enterprise end user via a network or the world wide web.

While the subject matter described herein is presented in the general context of program modules that execute in conjunction with the execution of an operating system and application programs on a computer system, those skilled in the art will recognize that other implementations may be performed in combination with other types of program modules. Generally, program modules include routines, programs, components, data structures, and other types of structures that perform particular tasks or implement particular abstract data types. Moreover, those skilled in the art will appreciate that the subject matter described herein may be practiced with other computer system configurations, including hand-held devices, multiprocessor systems, microprocessor-based or programmable consumer electronics, minicomputers, mainframe computers, and the like.

In the following detailed description, references are made to the accompanying drawings that form a part hereof, and in which are shown by way of illustrations specific embodiments or examples. Referring now to the drawings, in which like numerals represent like elements through the several figures, concepts and technologies for cloud-based service and application monitoring will be described.

Turning now to fig. 1, a block diagram illustrates a Cloud Monitoring Federation (CMF) 100 in accordance with one or more embodiments presented herein. CMF 100 is a federation formed between networking entities for supporting cloud-based service and application monitoring. CMF 100 may include a Cloud Monitoring Service (CMS) 140. The CMS140 may act as a central subscription and publication service. The CMS140 may collect information monitored by the cloud monitoring point of presence (POP) 120. The POP 120 may monitor and aggregate information published from one or more Managed Entities (MEs) 130 within the cloud 110. A Cloud Monitoring Client (CMC) 150 may subscribe to the CMS140 to consume published management information related to the ME 130.

The CMS140 is a cloud-based distributed service that acts as a centralized and dynamic repository for management information related to the ME 130. ME 130 may be a service or application distributed within cloud 110. The management information may include health metrics, performance metrics, and various other statistics associated with the ME 130.

The CMS140 may register the customer as a CMC150, a POP 120, or both. The registration may unite the CMS140, CMC150, and POP 120 to form the CMF 100. The publish and subscribe protocol may support POP 120 to publish monitored information to CMS 140. Similarly, the protocol may support the CMC 150's subscription to the CMS140 to receive monitored information. The negotiation protocol may be used to determine which POPs 120 may publish what pieces of information into the CMS140 and which CMCs 150 may access which pieces of information from the CMS 140. These protocols may also support discovery of other actors present on the network, such as the CMS140, CMC150, and POP 120. The registration process may provide security within the CMF 100 to protect against unauthorized or invalid publication of information by the POP 120 or unwanted access of information by the CMC 150.

The CMS140 may provide role and scope based update rights to the POP 120. These permissions may define the role and scope of the POP 120 in terms of which MEs 130 the POP 120 may report. The roles and scopes may also include details such as how frequently the reports should be made, by what level of detail, and where they should be published. The CMS140 may also provide role and scope based access rights to the CMC150 to define which ME 130 related information may be accessed or subscribed to.

Any type of unique identification token may be used to uniquely identify elements within the CMF 100 (such as the POP 120, ME 130, CMS140, and CMC 150) from one another. The unique identification of each element may be useful in defining roles, scopes, or other parameters associated with the elements. According to some embodiments, a representational state transfer (REST) model may be used. For example, actors within the CMF 100 may be identified by Uniform Resource Identifiers (URIs).

The POP 120 and CMS140 may each maintain models of the ME 130 that the POP 120 may utilize to report information to the CMS 140. These models may include relationships between the MEs 130 and may be classified by type of instance. For example, a particular desktop computer may be an example of the type "computer". A common model using a format understood by multiple actors in CMF 100 may support simplified delivery and aggregation of monitored information. The CMS140 may receive, aggregate, and update metrics, statistics, health, and other information associated with the ME 130 as published by the associated POP 120. The CMS140 may manage redundancy of information that may result from multiple points of view on the ME 130. For example, the CMS140 may monitor and manage the scope provided to the POP 120 to reduce redundant points of observation.

The CMS140 may respond to queries or subscription requests from the CMC150 seeking access to information monitored at the CMS 140. The CMS140 may support a query language for receiving queries from the CMC 150. For example, an extensible markup language (XML) based query language, such as Object Constraint Language (OCL), may be used. The CMS140 may manage throttling of information published from the POP 120. For example, the CMS140 may request that a certain POP 120 slow down or stop publishing. The CMS140 may also turn on (gate on) or turn off (gate off) the functionality of individual POPs 120 based on the interest level of the CMC150 making the subscription.

The CMC150 may negotiate monitoring policies with the CMS 140. The monitoring policy may include one or more of a monitoring frequency, a number of POPs 120 to monitor, a location of the POPs 120 to monitor, and a filter specification.

The ME 130 may be any service or component of a service under management. According to some embodiments, ME 130 may not be an active participant of CMF 100. Instead, the ME 130 may be an instance in the managed world that may be discovered and related to other instances or the ME 130. Metrics, statistics, health status, and other information about the ME 130 may be posted to the CMS140 or queried from the CMS 140. According to certain other embodiments, the ME 130 may participate as a POP 120 and publish information related to internal or standalone components. It should be understood that the aggregation and caching of the monitored information may occur at the POP 120, the CMS140, the CMC150, or any combination thereof.

Referring now to fig. 2, a block diagram illustrates more details regarding a Cloud Monitoring Federation (CMF) 100 in accordance with one or more embodiments presented herein. CMF 100 may include a Cloud Monitoring Service (CMS) 140 that acts as a central subscription and publication service. The CMS140 may collect information about MEs 130 within the cloud 110 monitored by POP 120A. The CMS140 may also collect information about Virtual Machines (VMs) 230 within the virtual cloud 220 monitored by POP 120B.

The CMC 150A may be associated with the management server 210 to support subscription and query activities from the management server 210 into the CMS 140. The management server 210 may also manage the internal services 250 to support simultaneous monitoring of instances within the internal services 250, within the cloud 110, and within the virtual cloud 220. According to certain embodiments, CMC 150B may be associated with a certain ME 130. This ME 130 may subscribe to the CMS140 using the CMC 150B to obtain management information about itself. This information about itself at the ME 130 may support the determination of health or status as part of a self-test. This information may also support failover or various scheduling decisions.

POPs 120, 120A, and 120B may be collectively or generically referred to as POP 120. The POP 120 may be a web service endpoint that continuously or periodically monitors the ME 130 and posts the monitored information to the CMS 140. The POP 120 may be implemented as any entity capable of collecting management information and publishing the information to the CMS 140. According to some examples, POP 120 may be an agent executing in association with one or more clients, a reviewer service executing in association with a cloud service, a component executing in the context of a managed cloud application, an agent executing on VM 230 within virtual cloud 220, any other such entity, or any combination thereof.

As part of the registration process, the POP 120 may claim identity to the CMS 140. Once claims are authenticated, the POP 120 may receive authorization based on those claims. As part of registration, the POP 120 may also announce its location, capabilities, and monitoring scope. The CMS140 may then provide the POP 120 with roles and scopes as to which specific MEs 130 the POP 120 should monitor and to what extent and with what frequency. For example, the roles and scopes may specify the frequency of monitoring, aggregation, filtering, and publication frequency of the POPs 120. The POP 120 may publish to more than one CMS140 at a time and under different roles and scopes.

The various clients discussed, such as CMC150, CMC 150A, and CMC 150B, may be collectively or generically referred to as CMC 150. As part of the registration process, the CMC150 may claim an identity to the CMS 140. Once claims are authenticated, the CMC150 may receive authorization based on those claims. As part of the registration, the CMC150 may also announce a desired monitoring scope. The CMC150 may periodically negotiate its subscription for monitoring information from the CMS 140. For example, the CMC150 may negotiate to change the monitoring frequency, the identity of the POP 120 or ME 130, the location of the POP 120, and other parameters of the monitoring information to which it subscribes.

The management server 210 may be the CMC 150A that may register with the CMS140, subscribe to manage delivery of information, negotiate quality of service (QOS) of the subscription, and also specify regular, periodic, or on-demand delivery of monitored information. The management server 210 may combine the monitored information from the CMF 100 with the monitored information from the internal services 250 to provide a complete, inside-out, and outside-in view of the services and applications of interest to the enterprise.

Examples of monitoring functions that go in from the outside can be applied to websites or web services hosted within an enterprise. A POP 120 located outside the enterprise may be tasked with monitoring the website or web service to determine the health or status of external links connected to the service. The information, once collected at the external POP 120, can be published back to the management server 210 within the enterprise. An example of an inside-out monitoring function may be applied to determine the health of services hosted outside the enterprise from a POP 120 located within the enterprise. For example, if a cloud-based service for verifying credit card transactions for a particular type of credit card is not accessible, the published health status may allow a web server located within the enterprise to remove (dispose) the particular type of credit card as a payment option for online commerce. Once the verification service is restored, the corresponding payment options may be returned to the online commerce site.

It should be understood that the management server 210 may also be the CMC150 and/or POP 120. The operations associated with the CMC150, CMS140, and POP 120 may be distributed across various and multiple entities or assembled together in any combination and diversity as may be meaningful to publish, consume, or centralize cloud monitoring activities. The functionality associated with the POP 120 or CMC150 may be provided as a library or Software Development Kit (SDK). According to these various embodiments, these libraries or SDKs may support integrating CMF 100 elements together or integrating them into other modules.

Referring now to FIG. 3, more details will be provided regarding the embodiments presented herein for cloud-based service and application monitoring. In particular, fig. 3 is a flow diagram illustrating a method 300 for the CMS140 according to embodiments presented herein. It should be appreciated that the logical operations described herein are implemented (1) as a sequence of computer implemented acts or program modules running on a computing system and/or (2) as interconnected machine logic circuits or circuit modules within the computing system. Depending on the performance and other requirements of the computing system, this implementation is a design issue. Accordingly, the logical operations described herein are referred to variously as states operations, structural devices, acts or modules. These operations, structural devices, acts and modules may be implemented in software, in firmware, in special purpose digital logic, and any combination thereof. It should be understood that more or fewer operations may be performed than shown in the figures and described herein. These operations may be performed sequentially, in parallel, or in a different order than described herein.

The method 300 begins at operation 310, where the CMS140 interfaces with the POP 120 at operation 310. The CMS140 may register the POP 120 using a claims-based security policy. From operation 310, the method 300 proceeds to operation 320.

At operation 320, the CMS140 may interface with the CMC 150. The CMS140 may register the CMC150 using a claims-based security policy. From operation 320, the method 300 proceeds to operation 330.

At operation 330, the CMS140 manages rights associated with the POP 120 to provide information about the ME 130. The CMS140 may specify which MEs 130 the POP 120 may publish monitoring information about, according to the claim-based security policy established for the POP 120 at operation 310. The CMS140 may also specify various parameters related to the publication. Such as monitoring frequency, publication frequency, aggregation, processing, filtering, level of detail, and so forth. From operation 330, the method 300 proceeds to operation 340.

At operation 340, the CMS140 receives information about the ME 130 from the POP 120. Because the POP 120 collects management information related to the ME 130, this information can be published by the POP 120 to the CMS 140. The management information associated with the ME 130 may include health status, performance metrics, operational statistics, and various other parameters. The CMS140 may manage throttling of published information from the POP 120. The CMS140 may also manage redundancy of published information from the POP 120 by monitoring and adjusting the scope of the POP 120. From operation 340, the method 300 proceeds to operation 350.

At operation 350, the CMS140 aggregates information about the ME 130. Aggregation of the monitored management information may occur at the CMS140, POP 120, CMC150, or any combination thereof. The monitored management information associated with the ME 130 may be stored in a cache, a buffer, a database, a file system, any other data storage device, mechanism, or system, or any combination thereof. From operation 350, the method 300 proceeds to operation 360.

At operation 360, the CMS140 manages the right for the CMC150 to request information about the ME 130. The CMC150 may be able to access information related to the specified ME 130, the specified rate, and the specified level of detail in accordance with the claim-based security policy established for the CMC150 at operation 320. From operation 360, the method 300 proceeds to operation 370.

At operation 370, the CMS140 receives a query from the CMC 150. The CMC150 may query or subscribe to monitored management information from the CMS 140. This information may be related to the ME 130 because the information is published from the POP 120 to the CMS 140. From operation 370, the method 300 proceeds to operation 380.

At operation 380, the CMS140 provides information about the ME 130 to the CMC150 in response to the received query of operation 370 being related to the ME 130. From operation 380, the method 300 proceeds to operation 390.

At operation 390, the CMS140 provides publish and subscribe services with the POP 120 and the CMC 150. The method 300 may terminate after operation 390 or the method 300 may repeat continuously or periodically.

Referring now to FIG. 4, more details will be provided regarding embodiments presented herein for cloud-based service and application monitoring. In particular, fig. 4 is a flow diagram illustrating a method 400 for cloud monitoring a point of presence (POP) 120, according to embodiments presented herein. The method 400 begins at operation 410, where the POP 120 interfaces with the ME 130 at operation 410. For example, a network connection may be established between the POP 120 and the ME 130. Establishing this connection may include a discovery process that identifies the ME 130 that is available to monitor within access to the POP 120.

It should be understood that the POP 120 may not have direct network connectivity with the ME 130, as the POP 120 may indirectly obtain information about the ME 120. Also, ME 130 may not actively participate in CMF 100. CMF 100 may observe only ME 130. From operation 410, the method 400 proceeds to operation 420.

At operation 420, the POP 120 registers with the CMS 140. The POP 120 may register with the CMS140 using claims-based security policies. According to such policies, a POP 120 may make claims regarding the identity, capabilities, or affiliations of the POP 120. The CMS140 may attempt to verify the claims of the POP 120. As part of the registration process, the POP 120 may establish a subscription and publication relationship with the CMS 140. From operation 420, the method 400 proceeds to operation 430.

At operation 430, the POP 120 receives the monitoring role, scope, or policy from the CMS 140. For example, the scope may indicate to the POP 120 which MEs 130 it should monitor. Similarly, the policy may specify various parameters to the POP 120, such as monitoring frequency, processing, publication frequency, aggregation, filtering, and so forth. From operation 430, the method 400 proceeds to operation 440.

At operation 440, the POP 120 aggregates the information related to the ME 130 in a local cache. From operation 440, the method 400 proceeds to operation 450.

At operation 450, the POP 120 communicates or publishes any monitored management information related to the ME 130 to the CMS 140. The method 400 may terminate after the operation 450 or the method 400 may repeat continuously or periodically.

Referring now to FIG. 5, more details will be provided regarding the embodiments presented herein for cloud-based service and application monitoring. In particular, fig. 5 is a flow diagram illustrating a method 500 for a cloud monitoring client according to embodiments presented herein. The method 500 begins at operation 510, the CMC150 registers with the CMS 140. The CMC150 may register with the CMS140 using a claims-based security policy. According to such a policy, the CMC150 may make claims regarding the identity, capabilities, or affiliations of the CMC 150. The CMS140 may attempt to verify the claims of the CMC 150. As part of the registration process, the CMC150 may establish a subscription and publication relationship with the CMS 140. From operation 510, the method 500 proceeds to operation 520.

At operation 520, the CMC150 negotiates the rights to access information from the CMS140 regarding the ME 130. The CMC150 may also negotiate subscription policies such as monitoring frequency, number of POPs 120 monitored, location of the POPs 120 monitored, and so on. From operation 520, the method 500 proceeds to operation 530.

At operation 530, the CMC150 communicates the query to the CMS 140. The CMC150 may also provide a query scope that specifies which MEs 130 the CMC150 wishes to monitor. From operation 530, the method 500 proceeds to operation 540.

At operation 540, the CMC150 receives information about the ME 130 from the CMS140 in response to the query transmitted in operation 530. The CMC150 may locally aggregate the received. The CMC150 may also share the received information with the management server 210 or other associated consumers of the received information. From operation 540, the method 500 proceeds to operation 550.

At operation 550, the CMC150 provides a subscription service for requesting message delivery from the CMS 140. The method 500 may terminate after operation 550 or the method 500 may repeat continuously or periodically.

Turning now to FIG. 6, an illustrative computer architecture 600 may execute the software components described herein for cloud-based service and application monitoring. The computer architecture shown in FIG. 6 illustrates a conventional desktop, laptop, or server computer, and may be used to execute any aspects of the software components presented herein. It should be understood, however, that the described software components may also be executed on other example computing environments such as mobile devices, televisions, set-top boxes, kiosks, automotive information systems, mobile phones, embedded systems, and the like. The computer architecture 600 may apply to a computer acting as a cloud monitoring POP 120, CMS140, CMC150, or management server 210. The computer architecture 600 may execute program modules associated with cloud-based service and application monitoring, such as a cloud monitoring POP module 610, a Cloud Monitoring Service (CMS) module 620, a Cloud Monitoring Client (CMC) module 630, or any combination thereof.

The computer architecture shown in FIG. 6 may include a central processing unit 10 (CPU), a system memory 13 (including a random access memory 14 (RAM) and a read only memory 16 (ROM)), and a system bus 11 that may couple the system memory 13 to the CPU 10. The system memory 13 may provide memory for cloud-based service and application monitoring. A basic input/output system containing the basic routines that help to transfer information between elements within the computer 600, such as during start-up, may be stored in the ROM 16. The computer 600 may also include a mass storage device 15 for storing an operating system 18, software, data, and various program modules, such as those associated with cloud-based service and application monitoring. These program modules may include a cloud monitoring POP module 610, a Cloud Monitoring Service (CMS) module 620, or a Cloud Monitoring Client (CMC) module 630.

The mass storage device 15 may be connected to the CPU 10 through a mass storage controller (not shown) connected to the bus 11. The mass storage device 15 and its associated computer-readable media may provide non-volatile storage for the computer 600. Although the description of computer-readable media contained herein refers to a mass storage device, such as a hard disk or CD-ROM drive, it should be appreciated by those skilled in the art that computer-readable media can be any available computer storage media that can be accessed by the computer 600.

By way of example, and not limitation, computer-readable media may include volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information such as computer-readable instructions, data structures, program modules or other data. For example, computer-readable media includes, but is not limited to, RAM, ROM, EPROM, EEPROM, flash memory or other solid state memory technology, CD-ROM, Digital Versatile Disks (DVD), HD-DVD, BLU-RAY, or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can accessed by the computer 600.

According to various embodiments, the computer 600 may operate in a networked environment using logical connections to remote computers through a network such as the network 20. Network 20 may overlap cloud 110 or virtual cloud 220 in whole or in part. The computer 600 may connect to the network 20 through a network interface unit 19 connected to the bus 11. It should be appreciated that the network interface unit 19 may also be utilized to connect to other types of networks and remote computer systems. The computer 600 may also include an input/output controller 12 for receiving and processing input from a number of other devices, including a keyboard, mouse, or electronic stylus (not shown). Similarly, an input/output controller 12 may provide output to a printer or other type of output device (also not shown). Display device 30 may be used to provide output from computer 600 in the form of text, graphics, video, graphical user interface, any other user interface element, or any combination thereof.

As mentioned briefly above, a number of program modules and data files may be stored in the mass storage device 15 and RAM 14 of the computer 600, including an operating system 18 suitable for controlling the operation of a networked desktop, laptop, server computer, or other computing environment. The mass storage device 15, ROM 16, and RAM 14 may also store one or more program modules. In particular, the mass storage device 15, ROM 16, and RAM 14 may store program modules associated with cloud-based services and application monitoring for execution by the CPU 10. The mass storage device 15, ROM 16, and RAM 14 may also store other types of program modules.

In general, software applications or modules, such as cloud monitoring POP module 610, Cloud Monitoring Service (CMS) module 620, or Cloud Monitoring Client (CMC) module, when loaded into CPU 10 and executed, may transform CPU 10 and overall computer 600 from a general-purpose computing system to a special-purpose computing system customized to perform cloud-based services and application monitoring. The CPU 10 may be constructed with any number of transistors or other discrete circuit elements that may individually or collectively assume any number of states. More specifically, the CPU 10 may operate as one or more finite state machines in response to executable instructions contained within the software or modules. These computer-executable instructions may transform the CPU 10 by specifying how the CPU 10 transitions between states, thereby physically transforming the transistors or other discrete hardware elements that make up the CPU 10.

The physical structure of the mass storage device 15 or an associated computer-readable storage medium may also be transformed by encoding software or modules onto the mass storage device 15. The particular transformation of physical structure may depend on various factors, in different implementations of this description. Examples of such factors include, but are not limited to: the technology used to implement the computer-readable storage medium, whether the computer-readable storage medium is characterized as primary or secondary storage, and the like. For example, if the computer-readable storage medium is implemented in semiconductor-based memory, the software or modules may transform the physical state of the semiconductor memory when the software is encoded therein. For example, software may transform the state of transistors, capacitors, or other discrete circuit elements that make up a semiconductor memory.

As another example, the computer-readable storage medium may be implemented using magnetic or optical technology. In such implementations, when the software is encoded in magnetic or optical media, the software or modules may transform the physical state of the magnetic or optical media. These transformations may include altering the magnetic properties of particular locations within a given magnetic medium. These transformations may also include altering the physical features or characteristics of particular locations within a given optical medium to change the optical characteristics of those locations. Other transformations of physical media are possible without departing from the scope and spirit of the present description, with the foregoing examples provided only to facilitate this discussion.

Based on the foregoing, it should be appreciated that technologies for cloud-based service and application monitoring are provided herein. Although the subject matter presented herein has been described in language specific to computer structural features, methodological acts, and computer readable media, it is to be understood that the invention defined in the appended claims is not necessarily limited to the specific features, acts, or media described herein. Rather, the specific features, acts and mediums are disclosed as example forms of implementing the claims.

The above-described subject matter is provided by way of illustration only and should not be construed as limiting. Various modifications and changes may be made to the subject matter described herein without following the example embodiments and applications illustrated and described, and without departing from the true spirit and scope of the present invention, which is set forth in the following claims.

Claims (16)

1. A computer-implemented method for monitoring cloud-based services, the method comprising computer-implemented operations for:

interfacing with a cloud monitoring presence point having authority to collect information about managed entities;

registering the cloud monitoring point of presence with a cloud monitoring service using claims made by the cloud monitoring point of presence according to a claim-based security policy;

interfacing with a cloud monitoring client having authority to receive information about the managed entity;

receiving information about the managed entity from the cloud monitoring point of presence;

receiving a query from the cloud monitoring client;

in response to the received query being related to the managed entity, providing the information about the managed entity to the cloud monitoring client; and

providing a publish and subscribe model for distributing the information about the managed entity to the cloud monitoring service.

2. The computer-implemented method of claim 1, further comprising aggregating the information about the managed entity in a buffer.

3. The computer-implemented method of claim 1, further comprising registering the cloud monitoring client with the cloud monitoring service according to a claim-based security policy.

4. The computer-implemented method of claim 1, wherein the information about the managed entity comprises one of a health status, a performance metric, and an operational statistic.

5. The computer-implemented method of claim 1, further comprising managing redundancy of the information about the managed entity by adjusting a scope of authority of the cloud monitoring point of presence.

6. The computer-implemented method of claim 1, further comprising throttling the information about the managed entity by adjusting a policy of the cloud monitoring point of presence.

7. The computer-implemented method of claim 1, wherein the cloud monitoring client is associated with a management server.

8. The computer-implemented method of claim 1, wherein the cloud monitoring client aggregates the information about the managed entity with information about internal services.

9. A computer-implemented system for monitoring cloud-based services, the system comprising:

means for interfacing with a cloud monitoring presence point having authority to collect information about managed entities;

means for registering the cloud monitoring point of presence with a cloud monitoring service using claims made by the cloud monitoring point of presence according to a claim-based security policy;

means for interfacing with a cloud monitoring client having authority to receive information about the managed entity;

means for receiving information about the managed entity from the cloud monitoring point of presence;

means for receiving a query from the cloud monitoring client;

means for providing the information about the managed entity to the cloud monitoring client in response to the received query being related to the managed entity; and

means for providing a publish and subscribe model for distributing the information about the managed entity to the cloud monitoring service.

10. The computer-implemented system of claim 9, further comprising means for aggregating the information about the managed entity in a buffer.

11. The computer-implemented system of claim 9, further comprising means for registering the cloud monitoring client with the cloud monitoring service according to a claim-based security policy.

12. The computer-implemented system of claim 9, wherein the information about the managed entity comprises one of a health status, a performance metric, and an operational statistic.

13. The computer-implemented system of claim 9, further comprising means for managing redundancy of the information about the managed entity by adjusting a scope of authority to monitor points of presence with the cloud.

14. The computer-implemented system of claim 9, further comprising means for throttling the information about the managed entity by adjusting a policy with the cloud-monitored point of presence.

15. The computer-implemented system of claim 9, wherein the cloud monitoring client is associated with a management server.

16. The computer-implemented system of claim 9, wherein the cloud monitoring client aggregates the information about the managed entity with information about internal services.