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(a)redhat.com>
Sender: rhq-devel-bounces(a)lists.fedorahosted.org
Date: Tue, 27 Sep 2011 22:00:02
To: <rhq-devel(a)lists.fedorahosted.org>
Reply-To: rhq-devel(a)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(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/rhq-devel
_______________________________________________
rhq-devel mailing list
rhq-devel(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/rhq-devel