AS7 plugin: Hibernate Query Cache resource type

Jay Shaughnessy jshaughn at redhat.com
Thu Dec 5 18:05:50 UTC 2013


There are lot of good ideas here but at the moment I recommend that this 
type be removed from autodiscovery.  It's completely bogging down AS7 
servers, including the RHQ Server resource, and is rendering master/4.10 
unusable.

We have to come up with some better approaches to high cardinality 
service types because keeping it as is sucks up tons of agent and server 
resources for very little, if any, gain.


On 12/3/2013 2:48 PM, Heiko W.Rupp wrote:
> Not sure if that is covered below:
>
> we must also be able to
>
> - remove an entry from inventory and tell the system that this one should
> not show up again
> - remove an obsolete resource automagically -- e.g. some Ispn cache (
> the query cache?) is valid as long as the app stays up and will be re-created
> under a different id on next app start. We should be able to remove those old
> caches automatically after e.g. 7 days
>
> Allow to templatize those rules so that a use can have a ruleset DEV that
> has e.g. more aggressive cleanup, while a ruleset PROD will leave old
> entries for 14 days
>
> Am 03.12.2013 um 20:41 schrieb Larry O'Leary <loleary at redhat.com>:
>
>> It seems that this should be configurable per resource type, resource
>> category, and even resource. As suggested in the past, logic dictates
>> the following situations:
>>
>> - Resources (platforms, servers, services) are auto discovered and auto
>> imported
>> - Resources (platforms, servers, services) are auto discovered and
>> manually imported
>> - Resources (...) are manually discovered and auto imported
>> - Resources (...) are manually discovered and manually imported
>> - Based on resource type configuration, individual resources can be
>> treated differently
>>
>> Currently, resource categories have the following settings:
>>
>> Platform: Auto Discover / Manual Import
>> Server: Auto Discover / Manual Import
>> Service: Auto Discover / Auto Import
>>
>> But with the added granularity based on resource types (and even
>> resource specific settings) I should be able to do something like:
>>
>> Auto discover everything except Query Cache services. Meaning that the
>> only way to get a Query Cache service into inventory is to perform a
>> manual discovery (preferably rooted at its parent). Then the question is
>> will it appear in the discovery queue or will it be auto imported? The
>> answer to that question is determined by the auto import setting for the
>> resource category, resource type, or parent resource.
>>
>> I could also set the default to auto discover everything and manually
>> import everything. Meaning that in order for a server or even one of its
>> services to get added to inventory, I must select it from the discovery
>> queue and explicitly import it. But perhaps I have a development JBoss
>> AS server that I want to auto discover and import all of its services
>> automatically. So, I should be able to configure, at the AS server
>> resource level, to auto discover and auto import all child servers and
>> services.
>>
>> Just a suggestion. By re-thinking how inventory is discovered and
>> handled, we can make it possible for the user to determine what the
>> right thing should be. Thus, preventing a bandage approach that
>> addresses a single use-case that may not apply to all users.
>> -- 
>> Larry O'Leary
>> https://plus.google.com/+LarryOLeary
>>
>>
>> On Tue, 2013-12-03 at 18:10 +0100, Thomas Segismont wrote:
>>> My opinion is that Query Cache resources should not be auto discovered
>>> whereas JMS queues should be.
>>>
>>> Waiting for more input before taking action.
>>>
>>> Le 29/11/2013 12:49, Michael Burman a écrit :
>>>> Hi,
>>>>
>>>> Costel, on the other hand, JMS queues and their changing sizes are the
>>>> only thing we really monitor in our environment. That's a quick way to
>>>> find out if something is wrong, when queue's message amounts keep
>>>> growing (or a certain service shows such behaviour).
>>>>
>>>> There's no silver bullet to keep just certain resources.
>>>>
>>>>    - Micke
>>>>
>>>>
>>>> On Fri, Nov 29, 2013 at 1:17 PM, Costel Cosman <costelcsmn at yahoo.ro
>>>> <mailto:costelcsmn at yahoo.ro>> wrote:
>>>>
>>>>     Hi Thomas,
>>>>
>>>>     I was thinking the same thing with other resources too, like the
>>>>     EJBs, JMS queues, etc.
>>>>
>>>>     In our company we use RHQ to monitor production JBoss servers with a
>>>>     lot of EJBs but no one is really interested to monitor these EJBs or
>>>>     at least they are interested in monitoring only some of them.
>>>>     These useless resources bring unnecessary load on both RHQ server
>>>>     and agent. By default they are checked for the availability and have
>>>>     some metrics enabled.
>>>>
>>>>     An idea would be to have a lazy discovery for these resources - at
>>>>     request, maybe some configuration in the Connection Settings of the
>>>>     parent resource to enable the discovery of such child resources,
>>>>     maybe define a regexp pattern for the resource names we are
>>>>     interested in.
>>>>
>>>>
>>>>     Regards,
>>>>     Costel
>>>>
>>>>
>>>>     ------------------------------------------------------------------------
>>>>     *De la:* Thomas Segismont <tsegismo at redhat.com
>>>>     <mailto:tsegismo at redhat.com>>
>>>>     *Către:* rhq-devel at lists.fedorahosted.org
>>>>     <mailto:rhq-devel at lists.fedorahosted.org>
>>>>     *Trimis:* Vineri, 29 Noiembrie 2013 12:27:48
>>>>     *Subiect:* AS7 plugin: Hibernate Query Cache resource type
>>>>
>>>>     Hi everyone,
>>>>
>>>>     I fixed "Bug 1033130 - [AS7] Exception during discovery of Query Cache
>>>>     resources of RHQ Server resource" this week.
>>>>
>>>>     So what? Well now if you inventory RHQ server resource you get more
>>>>     than
>>>>     2000 query cache resources showing up. Which of course costs you CPU
>>>>     and
>>>>     memory.
>>>>
>>>>     You can of course just ignore this resource type (via the admin pages).
>>>>
>>>>     So I was wondering: shouldn't we change such resource types to no
>>>>     longer
>>>>     auto discover them but only allow manual add?
>>>>
>>>>     Opinions?
>>>>
>>>>     Thanks,
>>>>     Thomas
>>
>> _______________________________________________
>> 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