Disabled metrics are still collected
Thomas Segismont
tsegismo at redhat.com
Mon Mar 17 10:41:02 UTC 2014
I wanted to reply that it may have something to do with having a GUI
opened and pointing to the Metrics tab of the resource.
Then I checked the commit log, saw it was actually the problem, and was
already fixed by almighty Jay:
https://github.com/rhq-project/rhq/commit/98b52a8c85836b6b5dbd8f2996a7037f52a92637
Thomas
Le 11/03/2014 14:23, Jay Shaughnessy a écrit :
>
> You're right, plugins can query for metrics in any fashion that makes
> sense. But, after some initial looking, this has to do with the
> requested metrics. It seems they can get wonky after certain changes in
> the schedules and/or enablement. I'm going to look further today. I
> don't think it's a horrible issue because, at least for me, an agent
> restart brought the schedules back to a steady state. So, it seems to
> only affect resources whose schedules get updated while the agent is
> running, and not every time (and I don't yet have it pinned down as to
> what the magic changes need to be to make this happen).
>
>
> On 3/11/2014 4:36 AM, Michael Burman wrote:
>> Are you sure this isn't because of how the agent-plugin has been
>> created? At least the SQL plugins do something like: SELECT metric1,
>> metric2, metric3, metric4 FROM metrics style of queries, which means
>> they'll collect all the data once the getValues is requested, but they
>> only report the values which are requested by the server (those which
>> are enabled). In this example it wouldn't make sense to collect each
>> value separately, since it reduces the load to gather them all at
>> once, but of course this would be dependant on the resource type.
>>
>> - Micke
>>
>>
>>
>> On Mon, Mar 10, 2014 at 9:01 PM, Jay Shaughnessy <jshaughn at redhat.com
>> <mailto:jshaughn at redhat.com>> wrote:
>>
>>
>> Yow - let me take a look at this right now...
>>
>>
>> On 3/10/2014 11:20 AM, Larry O'Leary wrote:
>>
>> While looking into another issue dealing with metric collection
>> failures, I have stumbled across something strange. I can see
>> metrics
>> being collected by the agent for metrics which are not
>> enabled. Is this
>> expected?
>>
>> In my case I am working with a non-Tx datasource resource from
>> the AS7
>> plug-in. Even though many of the metrics are disabled by
>> default, I am
>> seeing some disabled metrics included in the measurement
>> collection
>> request:
>>
>> PreparedStatementCacheCurrentSize
>> PreparedStatementCacheMissCount
>> PreparedStatementCacheMissCount
>> PreparedStatementCacheAddCount
>> PreparedStatementCacheAccessCount
>> PreparedStatementCacheAccessCount
>> PreparedStatementCacheDeleteCount
>> PreparedStatementCacheDeleteCount
>> PreparedStatementCacheHitCount
>> PreparedStatementCacheHitCount
>> AverageBlockingTime
>> AverageCreationTime
>> MaxCreationTime
>> TimedOut
>> TotalCreationTime
>> TotalCreationTime
>> TotalBlockingTime
>> TotalBlockingTime
>>
>>
>> If this is happening with other resources and resource types,
>> I can
>> imagine that the load generated on and by the agent is much
>> higher then
>> what would be expected.
>>
>> http://ur1.ca/gt6mv contains the log message showing these
>> disabled
>> metrics being included in the getValues call. Something to
>> note is that
>> even though the above metrics are disabled, the PC reports them as
>> enabled as seen in the log message.
>>
>> Is this expected? A bug? Something we are already aware of?
>>
>>
>> _______________________________________________
>> rhq-devel mailing list
>> rhq-devel at lists.fedorahosted.org
>> <mailto:rhq-devel at lists.fedorahosted.org>
>> https://lists.fedorahosted.org/mailman/listinfo/rhq-devel
>>
>>
>>
>>
>> _______________________________________________
>> rhq-devel mailing list
>> rhq-devel at lists.fedorahosted.org
>> https://lists.fedorahosted.org/mailman/listinfo/rhq-devel
>
>
>
> _______________________________________________
> rhq-devel mailing list
> rhq-devel at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/rhq-devel
>
More information about the rhq-devel
mailing list