RHq-Metrics Use cases ( was Re: No concept of a platform? )

Heiko W.Rupp hrupp at redhat.com
Wed Jan 14 13:57:08 UTC 2015


I see the following use cases for rhq-metrics in itself and a larger context:

1)  embedded usage in WildFly console (standalone)

   a rhq-metrics (server ) instance + the wildfly-monitor are installed inside WildFly and the graphs
   in the console are rhqm-charts backed by the rhq-m server. 
   In the past we said that this uses the memory backend for quick startup and easy 

1b) like the above, but if people are happy to accept longer startup, it is using an embedded C*
  server that follows the WildFly lifecycle

1c) like 1b) but with an external C* instance. Probably quicker in startup than 1b), but much more
  complicated in setup and maintenance

2) embedded usage in WildFly console but with external RHQ-Metrics Server
  
  like 1) but with a standalone RHQ-Metrics Server somewhere in the network instead of the
  rhq-metrics server instance running on the WildFly server.
  in the WildFly-console are preferences that allow to set this remote server + credentials

  The standalone RHQ-Metrics server here could also be a (full featured) rhq.next instance

3) As part of rhq.next

4) Embedded in other (Red Hat) projects like e.g. OpenShift , where the other project also wants to store
  metrics and display graphs, but which has several means (perhaps including wildfly-monitor) to submit 
  data to rhq-metrics


While in theory 2-4 could also use memory backend or embedded C* server, I see them all with external
C* server(s).

  Heiko


> Am 14.01.2015 um 12:23 schrieb Thomas Segismont <tsegismo at redhat.com>:
> 
> Le 09/01/2015 11:14, Heiko Braun a écrit :
>> 
>> 
>> The primary goal is to provide access to historical runtime data (aka metrics) and availability information through the default management interfaces. The default interfaces are the wildfly web console and the CLI.
>> 
>> Ideally we would like to re-use as much as possible, this may include the rhq-metric UI or some of it’s components if it seem’s beneficial.
>> 
> 
> Thanks.
> 
> Is persistence across restarts of the standalone server or host controller a primary goal?
> _______________________________________________
> rhq-devel mailing list
> rhq-devel at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/rhq-devel

-- 
Reg. Adresse: Red Hat GmbH, Technopark II, Haus C, 
Werner-von-Siemens-Ring 14, D-85630 Grasbrunn
Handelsregister: Amtsgericht München HRB 153243
Geschäftsführer: Charles Cachera, Michael Cunningham, Paul Hickey, Charlie Peters



More information about the rhq-devel mailing list