metric default intervals

smillidge at c2b2.co.uk smillidge at c2b2.co.uk
Wed Sep 28 07:40:20 UTC 2011


Purely as a user I think the more metrics enabled out of the box the better.

Typically ops people will not know what they want to monitor in a JEE app server so the more data available when problems occur the better. If people have to enable all metrics individually then most won't be enabled until it's too late.

My ideal monitoring system would gather every metric available to it at all times with very very low metric overhead :-)
Sent from my BlackBerry® wireless device

-----Original Message-----
From: Charles Crouch <ccrouch at redhat.com>
Sender: rhq-devel-bounces at lists.fedorahosted.org
Date: Tue, 27 Sep 2011 22:00:02 
To: <rhq-devel at lists.fedorahosted.org>
Reply-To: rhq-devel at lists.fedorahosted.org
Subject: Re: metric default intervals

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
> 
_______________________________________________
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