Bug 847905 - Additional flexibility in alert template definitions wrt groups
Additional flexibility in alert template definitions wrt groups
Status: NEW
Product: RHQ Project
Classification: Other
Component: Alerts (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified (vote)
: ---
: ---
Assigned To: RHQ Project Maintainer
Mike Foley
Depends On:
  Show dependency treegraph
Reported: 2012-08-13 20:58 EDT by Elias Ross
Modified: 2012-08-13 20:58 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Elias Ross 2012-08-13 20:58:18 EDT
Feature request discussion:


"if there happens to be a group with this type of definition, I want to automatically create these alert defs on it, thank you"

Specific Use Case:

I am managing Flume resources, specifically 'collectors' which contain queued messages. Depending on the host, we have different levels of storage, so the number of messages in the queue can vary. We need to ensure these queues don't go over a certain count.

(I am eventually going to monitor the queue as a percentage of total capacity, once that number is exposed in JMX, but currently it is by a number only.)

Currently, I use alert templates. It would be nicer if instead of applying this template by resource type, to rather be able to restrict to resource type plus some other conditions, similar to 'dynagroups definitions'.

Of course, dynagroups work as well, but they are not as easy to edit.

Implementation proposal:

Retain the existing template screen. Have an additional tab when editing the alert definition to restrict this template to only resources meeting additional criteria. The initial tab could simply be a text box with possibly some hints or example restrictions.

Note You need to log in before you can comment on or make changes to this bug.