metric default intervals

Charles Crouch ccrouch at redhat.com
Wed Sep 28 02:00:02 UTC 2011


How about we consider just collecting continuing to collect all summary metrics and disabling all the other metrics?
Then everyone will continue to see all the graphs they would have done previously, and we're also taking advantage of the fact that someone has decided previously that a particular summary metric is important enough to want to display, versus the non-summary one.

Note: Non-summary metrics also appear in the Summary>Resource Measurements portlet.

----- Original Message -----
> re: https://bugzilla.redhat.com/show_bug.cgi?id=741331
> 
> I created a temporary branch for this work: feature/metric-tweek
> 
> After looking at the metrics and trying to see what we absolutely
> have
> to have enabled, I came to the conclusion we don't have many that we
> absolutely have to have enabled :) This is of course all IMHO, I'm
> sure
> others have diametrically opposed opinions, and I reserve to change
> my
> mind at any time for any reason.
> 
> But that said, out of box it would be nice to have "something"
> enabled
> to at least a) give the user a warm and fuzzy feeling to see pretty
> graphs which indicates things are working properly and b) provides a
> way
> to do a "quick demo" or proof of concept to people that just want to
> install and quickly see how things work and get a feel for the kind
> of
> things RHQ can do. Without ANY metrics enabled, newbies will need to
> know how to do the extra steps of enabling some metrics, which could
> be
> annoying if all they want to do is quickly install and just see
> things
> "work".
> 
> So, here's what I am enabling off the bat in this new branch:
> 
> PLATFORM PLUGIN
>    Platform resource type ("Windows", "Linux", "AIX", etc):
>       Architecture trait  --\
>       Hostname trait  -------\__ summary traits that show in the
>       resource
>       OS Name trait   -------/   view header, so we should enable
>       these
>       OS Version trait------/
>       Free Memory
>       Free Swap Space
>       Used Memory
>       Used Swap Space
>       System Load
>       User Load
>       Distribution Name trait ----\__ these are on the Linux
>       Distribution Version trait--/   platform type only
> 
>    "Network Adapter" resource type:
>       Inet4Address trait
> 
> JBOSS-AS 4 PLUGIN
>    "JBoss AS Server" resource type:
>      JVM Free Memory
> 
> JBOSS-AS 5 PLUGIN
>    "JBoss AS Server" resource type:
>      JVM Free Memory
> 
> Nothing else is enabled in any other plugin. Why not do anything in
> the
> JBossAS 7 plugin? Because Heiko is still developing that so I didn't
> want to touch its code - but we will want to probably enable
> something
> in there too.
> 
> Well, that's it. The idea is that we show some basic platform metrics
> and one basic metric for each EAP instance. Other than that, we don't
> turn on anything else by default. We'll let the user tell us what
> metrics they are interested in, rather than us telling them what we
> think they might be interested in.
> 
> I also think we need to consider something that Jay proposed - some
> kind
> of "template set" where we can say, "switch to template set 'common'"
> and the "common" template set has collection intervals and default
> enable settings for common metrics (these could be what our current
> defaults are). We could pre-can some template sets like "debug" (this
> enables everything) and "basic" (these enable very few metrics with
> long
> collection intervals) and all things in between. Not sure how this
> could
> look in the UI or how to implement it, but its an idea we could think
> about to help users customize their metric collections and yet help
> them
> avoid clobbering the metric subsystem with tons of metrics the user
> isn't even interested in or wants to look at.
> _______________________________________________
> rhq-devel mailing list
> rhq-devel at lists.fedorahosted.org
> https://fedorahosted.org/mailman/listinfo/rhq-devel
> 


More information about the rhq-devel mailing list