I can do that.
What I would also like to do is investigate how easy it would be to
implement some kind of "template" system. Today our "metric templates"
are not templates at all - they are merely the Measurement Definitions
of the metrics.
I would be nice to add something to the schema in which we can have
"templates" that consist of two things - whether or not a metric is
enabled or disabled and what its collection interval is. We could then
apply these templates to either: a) the Measurement Definition (thus
setting up the metric defaults) or b) current measurement schedules
(thus changing the metric settings in current use by the agents).
We could add metric metadata to allow plugins to predefine these
"templates". Even if they are just a hardcoded set of templates, like
"basic" or "debug" or "recommended". Something like:
<metric-template name="basic">
<metric name="FreeMemory" enabled="true"
collectionInterval="60000"/>
...
</metric-template name="basic">
I havent thought this all the way through, but I think we are going to
need something like this to help manage metric collection better.
On 09/27/2011 10:00 PM, Charles Crouch wrote:
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