Difference between revisions of "UnifiedInstrumentationMetering"
| Line 1: | Line 1: | ||
__NOTOC__ | __NOTOC__ | ||
= Unified Instrumentation and Metering = | = Unified Instrumentation and Metering = | ||
| + | |||
| + | == Overview == | ||
| + | |||
| + | With Ceilometer, Tach and [[StackTach]], there are some very cool initiatives going on around instrumentation and metering/monitoring within [[OpenStack]] today. | ||
| + | |||
| + | However, due to incredible speed of development within [[OpenStack]] many of these efforts have been performed in isolation from each other. Now, we are reaching a level of maturity which demands we stop reinventing the wheel and agree upon some shared infrastructure. This need is necessary for a variety of reasons: | ||
| + | |||
| + | 1. We want to make it easier for new projects to build on the existing [[OpenStack]] notification message bus. | ||
| + | 1. Less code is good. We shouldn't need three different workers for extracting notifications from [[OpenStack]]. | ||
| + | 1. Notifications are large and there's a lot of them. We only want to process and store that data once. | ||
| + | 1. Archiving of data is a common problem, we shouldn't need several different ways of doing it. | ||
| + | |||
| + | == Instrumentation vs Metering/Monitoring == | ||
| + | |||
| + | [[attachment:instrumentation.png]] | ||
| + | |||
| + | [[attachment:metering.png]] | ||
Revision as of 12:13, 1 November 2012
Unified Instrumentation and Metering
Overview
With Ceilometer, Tach and StackTach, there are some very cool initiatives going on around instrumentation and metering/monitoring within OpenStack today.
However, due to incredible speed of development within OpenStack many of these efforts have been performed in isolation from each other. Now, we are reaching a level of maturity which demands we stop reinventing the wheel and agree upon some shared infrastructure. This need is necessary for a variety of reasons:
1. We want to make it easier for new projects to build on the existing OpenStack notification message bus. 1. Less code is good. We shouldn't need three different workers for extracting notifications from OpenStack. 1. Notifications are large and there's a lot of them. We only want to process and store that data once. 1. Archiving of data is a common problem, we shouldn't need several different ways of doing it.
