Quick 2.0 links: ![]() ![]() ![]() ![]() ![]() GoalEnable simpler, more open, more durable integration between monitoring tools and consumers of monitoring data about resources such as applications, computer systems, storage volumes, etc.To join this working groupPlease:
BackgroundThis working group will define a common set of resources, formats and RESTful services that usable by lifecycle tools such as operation dashboards, applications, and products to monitor resources. The need for this workgroup is further driven by web operations. Monitored resource definitions define the data about entities like applications, computer systems, storage volumes, etc. commonly used to observe a coarse-grained summary of a monitored resource's state, e.g. its self-reported health. Some monitoring tools collect 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 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, address those by drafting specifications, collect implementation experience using those drafts, and then close (finalize) those specifications. This will decrease the barrier to sharing monitored 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 application monitoring. This is a key resource type today. There are many other areas of monitoring that could be covered in the future iterations such as storage, network, computer system, etc.Specifications2.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
Supporting Documents
MilestonesNote: 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.
|
Participants
ResourcesHow to join a working group Meeting Agendas and MinutesMailing ListRegister for the Performance Monitoring mailing list Performance Monitoring mail archives General OSLC Community |