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