AS7 plugin: Hibernate Query Cache resource type
Heiko W.Rupp
hrupp at redhat.com
Tue Dec 3 19:48:00 UTC 2013
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
--
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
More information about the rhq-devel
mailing list