Application Health Summary

Business Goal

Reduce Mean Time to Root Cause a performance problem with an application middleware resource.

Technical Goals

1. Data providers will update, in real time, the health and performance of an application's middleware resource components.
2. A central registry will contain a reconciled and current view of the application components. The middleware resources that support the application are reconciled across multiple data providers.
3. The consumers of the application's health are able to dynamically determine the health of the components. Any time a user hovers over the icon representing the middleware resource, an OSLC client will dynamically determine the current providers and federate their data about the resource into a UI preview.

Preconditions

Postconditions

Steps

1. An existing resource (e.g. web application server) is used to host an application.
2. An application health consumer queries for monitoring information about the resource.
3. The application health provider responds with a set of Best Practices metrics that summarize the health of the web application server and its applications.
4. The end user visualizes the current health of the application server and its applications through the UI preview and uses that information to determine if the performance problem is a trend or an anomoly.
5. Based on their determination, the user opens a ticket, launches into a deep-dive monitoring tool, or runs some automation to quickly resolve a known issue.

Examples

Variations

1. This scenario does not preclude other resource types besides applications (e.g. computer systems, network switches, etc.)

Detailed Steps

Assumptions: The consumer and provider have shared knowledge about a target resource

1. Consumer queries the resource registry for a monitoring service provider URL for the selected resource

1. Resource registry looks up resource record for resource and determines if any monitoring service provider URLs have been registered for it
2. Resource registry finds monitoring service provider URL and returns the URL to the consumer as an RDF response

2. Consumer invokes a GET method on monitoring service provider URL that was returned to it by the resource registry for the selected resource

1. Consumer indicates compact XML in the content-type header because the receiving client is a UI preview window/iframe
2. Consumer connects to monitoring service provider and issues a GET request on its URL for the target resource

3. Monitoring Service provider responds to the UI preview with an HTML page embedded in a compact XML document

1. Monitoring Service provider maps OSLC resource to an internal resource name
2. Monitoring Service provider gets Best Practices health metrics data for resource
3. Monitoring Service provider builds an HTML page, embedding the data and any UI elements (e.g. chart, labels) needed to display it
4. Monitoring Service provide encodes a response document as compact-XML and returns it to the requesting consumer

4. Consumer displays HTML page in UI preview window/iframe

5. Based on the content returned, user takes appropriate action