AS7 plugin: Hibernate Query Cache resource type

Alan Santos asantos at redhat.com
Thu Dec 5 20:58:55 UTC 2013


On Dec 3, 2013, at 2:48 PM, Heiko W.Rupp <hrupp at redhat.com> 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
> 

I’m with you on the need to remove things from current inventory (e.g. caches) but an arbitrary date seems wrong.  Whats so special about 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
> 
> -- 
> Reg. Adresse: Red Hat GmbH, Technopark II, Haus C, 
> Werner-von-Siemens-Ring 14, D-85630 Grasbrunn
> Handelsregister: Amtsgericht München HRB 153243
> Geschäftsführer: Charles Cachera, Michael Cunningham, Paul Hickey, Charlie Peters
> 
> _______________________________________________
> 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