The idea is to create a "Metrics subsystem", that can be used by RHQ  as well as other systems like WildFly, Fabric8 and so on.

It is composed of two general parts:

• Storage
• Display

as seen in this drawing (just a first draft for illustration purposes):

Display: Here we will create AngularJS directives, that can be used to talk to the backend service (and also other services that use the same API) and which will then graph the data for one or more metrics over a (given) period of time. If no time range is supplied, a default of last 8h will be used.

The storage system itself consists of a few parts

• Core: this is the central backbone and marked in green in above example
• Storage Backends (mutually exclusive), only C* or the memory backend will be supported in the 1st iteration.
  • Internal Cassandra cluster: a Cassandra cluster that is managed by the storage system and which is only used for storage
  • External Cassandra cluster: like above, but the storage system is (re)using an already existing Cassandra cluster
  • Memory: this is used for cases where RHQ-Metrics is supposed to be fully embedded into other projects to provide rapid prototyping / response
• Rest-API: Allows to store and retrieve data

  • An important detail here is the id-translator that allows to register strings as metric names instead of the numeric ids that are normally used, so that users can e.g. send the data id as host1:cpu4:idle, which is then converted to an (internal) id of 1234 (or vice-versa, to be decided)

• Aggregation: data compaction to reduce the storage needed for long term storage. Only available with C* backends
• Processing Extensions (orange, only with C* backends)
  • Baselining: calculates baselines of the stored metrics
  • .. more extensions/plugins, that the user can load into the system.
• Communication-Extensions (bordeaux): Allow other systems to upload and retrieve data in their native dialect
• Access control (optional in embedded mode): allow to specify who may access what metrics. Granularity to be defined.

There will be several ways to use the service:

• embedded inside another process (e.g. WildFlyAS).
  • with a single 'embedded' C* instance
  • backed by a memory-based structure
• Standalone with own C* cluster
• Standalone with a remote (=already existing) C* cluster

REST-Api

The REST-Api will need endpoints to support the "native encoding" of metrics by default; transport encoding is JSON, other encodings like XML or Yaml should be supported as well

• PUT metrics
• GET metrics f(time range)
• GET additional stuff (baseline data , ... )