I'm definitely in favor of tuning down out of the box collection and
letting customers enable or increase collection intervals on the types
and metrics that interest them. In fact, I think I would prefer if:
1) Metric settings could be saved with a name, like a preset, and
set/reset.
2) Your new defaults came as something like "Standard Collection".
3) Out of the box nothing was set/enabled (i.e. no collection).
4) Users could save their own presets, and then be allowed to set/reset
their own presets in addition to the "Standard Collection" provided by
the plugin descriptor.
5) Be able to turn off, or set the entire resource population to
standard collection.
Although it's possible that out of the box information may not be
collected that could help investigate an issue, I think the downside of
collecting large amounts of unwanted data, the increased strain on
db/bandwidth/agent CPU, is worth avoiding.
On 9/26/2011 12:11 PM, John Mazzitelli wrote:
of course I mentioned the wrong BZ - its actually:
https://bugzilla.redhat.com/show_bug.cgi?id=741331
On 09/26/2011 12:06 PM, John Mazzitelli wrote:
> This is :
https://bugzilla.redhat.com/show_bug.cgi?id=642416 [<--WRONG]
>
> I am going to go through our plugin XML metadata for all plugins and I
> will remove most of the default intervals. I will also turn off many
> metrics (defaultOn="false")
>
> This is because most of the metrics are not interesting to most people
> so there is no need to collect them out of box (this will lessen the
> load on the server, agent and DB backend as well).
>
> Also, the fallback interval defaults will be increased. When a metric
> definition is parsed from metadata and persisted, the default collection
> interval (if not explicitly stated in the plugin descriptor XML) is
> determined in: MetricsMetadataParser.parseMetricsMetadata().
>
> Based on the kind of metric (dynamic, trait, calltime), whether it is a
> "summary" metric or a "detail" metric, and based on if it is a
metric
> for a platform, server or service resource, we determine a default
> collection interval. I am going to increase those defaults. Here is the
> current defaults, along with my proposed increases - let me know what
> you think about the new values (too high? too low?). The intervals
> listed below are in minutes:
>
> DEFAULTS
> Metric Type Current, New
> =================================================
> NUMERIC METRICS:
> SUMMARY:
> Platform: 1 10
> Server: 5 20
> Service: 10 30
>
> DETAIL: (these are just doubled from above)
> Platform: 2 20
> Server: 10 40
> Service: 20 60
>
> TRAITS:
> SUMMARY: 10 30
> DETAIL: 30 60
>
> CALLTIME: 1 10
>
> ANY OTHER METRIC: 10 30
>
> (side note: for those not familiar, a metric is set as a "summary"
> metric by the "displayType" attribute in the<metric> metadata -
its
> just a way to let the system know you want to show its graph on the main
> Monitoring tab - if it is a "detail" as opposed to "summary"
metric, the
> graph isn't shown by default and we just show the data in the Tables
> subtab of the Monitoring tab).
> _______________________________________________
> 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