History   View   Links to this page Revision from: 2013 March 14 | 12:31 am
This is the revision from 2013 March 14 at 12:31 am   View the current live version of the article.

Quick 2.0 links: Meetings | Email archives | PM Scenarios | PM Specification | Examples

Contents

Goal

Enable simpler, more open, and more durable integration between monitoring tools and consumers of monitoring data for resources such as applications, computer systems, storage volumes, etc.

To join this working group

Please:

  1. Request a meeting invitation: contact Julie Bielski or send an email to the working group’s mailing list admins (note: remove NOSPAM from the destination domain name).
  2. Register for the Performance Monitoring mailing list.
  3. Follow the general community instructions that apply to each working group. It amounts to:
    1. registering for a site userid (once for the site - you can use the “Sign Up!” link in the left navigation bar to sign up),
    2. completing the Member Agreement (only upon joining your first OSLC WG), and
    3. completing the Working Group Participation Agreement (once for each specific WG you are joining).

Background

This working group will define a set of resources, formats and RESTful services that may be used by lifecycle tools such as operations dashboards, change management tools, asset management tools and others to obtain performance and availability metrics for resources. The need for this workgroup is further driven by web operations.

Some monitoring tools provide hundreds or more individual metrics about a range of resources. It is NOT our intent to reproduce that work in all its richness and detail. Only the subset needed to satisfy the in-scope scenarios will be included in the Performance Monitoring resource definitions, i.e. the subset that most/all tools would be able to provide and that participants can readily agree on.

The approach will be to define a small number of tightly constrained scenarios and to address those by drafting specifications, collecting implementation experience using those drafts, and then closing (finalizing) those specifications. This approach will decrease the barrier to sharing performance and availability metric data across multiple vendors and tools as part of the Operations Lifecycle. Future iterations of that process may be used to address additional scenarios and resource types. The initial focus will be on metrics for middleware health. There are many other monitoring domains that could be covered in future iterations such as storage, network, computer system, etc.

Specifications

2.0 is the first version of the documents below. The OSLC Core working group recommends that domain working groups use the specification version to indicate that they are based on the OSLC Core 2.0 specification. This working group chose to use a consistent version number for all related documents.

2.0 (Draft)

OSLC-PM 2.0 Specifications

Document Link Status
Performance Monitoring Specification 2.0 Converge

Supporting Documents

Document Link Status
PM Scenarios and Use Cases 2.0 Note
PM Vocabulary 2.0 Final Draft
Common Resource Type Vocabulary 2.0 Final
Architectural Direction 2.0 Note
Examples 2.0 Note
Implementation Reports 2.0

Milestones

Note: iterative specification validation will be occurring as the drafts evolve before finalization. The goal is to have at least 2 implementations of the specification before it is considered finalized.

Version Create Draft Specs Start Convergence Finalize Specs
2.0 2012-05-15 2012-10-26 2012-11

Resources

How to join a working group

Meetings

Mailing List

Register for the Performance Monitoring mailing list

Performance Monitoring mail archives

General OSLC Community