The methods you wanted already existed on the local interface, they
just weren't exposed in the remote API. This was only a few minutes of
work, so I went ahead and promoted them in master.
commit 9363b498345b7977798274b27637f8a360f4675d
Author: Joseph Marques <joseph(a)redhat.com>
Date: Sun Aug 8 18:02:10 2010 -0400
move existing enable/disable/delete methods to remote API for
AlertDefinitionManager
So if you're building off of master, all you have to do is 'git pull',
rebuild the modules/enterprise/server/jar module, and you should be able
to start writing your CLI scripts. You can use the criteria-based
finder method to gather the ids/pks of the alert definitions you wish to
enable/disable:
-----
var criteria = AlertDefinitionCriteria();
criteria.addFilterResourceIds(<resourceIdsYouWishToDisableAlertDefinitionsFor>);
// or instead filter by something else more relevant to your use-cases
var alertDefs =
AlertDefinitionManager.findAlertDefinitionsByCriteria(criteria);
var alertDefinitionIds = // extract ids from alertDefs
AlertDefinitionManager.disableAlertDefinitions(alertDefinitionIds);
-----
Let us know how it goes.
-joseph
On 08/08/2010 03:22 PM, Steve Millidge wrote:
Thanks for the answers. Some thoughts from me.
I like the idea of planned down time so that the MTBF etc. aren't
affected as many of our customer's SLA's are based on unscheduled
outages and so will then be able to use RHQ to track these SLAs
effectively.
However I would still like to add the disabling of alerts to the
Remote API that way I can script any requirement we need around this
that doesn't fit the model above. For example we have a requirement to
disable an ESB node if it is "unhealthy", take some remedial action
then bring it back. This would require disabling the Availability
alert for a short time.
I'm happy to help with coding and give you a patch as I can now build
RHQ ;-)
Thanks
Steve Millidge
Director
C2B2
*Providing the foundations for Enterprise Scale Java.*
T: 08450 539457
M: 07920 100626
W:
www.c2b2.co.uk <
http://www.c2b2.co.uk/>
E: smillidge(a)c2b2.co.uk <mailto:smillidge@c2b2.co.uk>
*From:* rhq-users-bounces(a)lists.fedorahosted.org
[mailto:rhq-users-bounces@lists.fedorahosted.org] *On Behalf Of *Greg
Hinkle
*Sent:* 03 August 2010 23:15
*To:* rhq-users(a)lists.fedorahosted.org
*Subject:* Re: Disabling alerts programmatically
I think you may want operations, content and configuration changes to
still go through during maintenance periods to do the maintenance
though. Do we need to integrate this with availability reporting so we
can historically show planned or unplanned outage ratings as well?
Other things that might be nice are removing them from the suspect
metrics and down-resources views. Perhaps even cutting metrics from
the period from baseline analysis.
- Greg
On Aug 3, 2010, at 6:02 PM, Joseph Marques wrote:
+1 on this suggestion. The benefit to planned outages / black out
periods is that the system can internally freeze multiple difference
types of internal processes for the resource - alert firing, operation
invocations, and other forms of scheduled jobs against the resource.
On 08/03/2010 01:40 PM, Ian Springer wrote:
Something else that would address this type of thing is a new feature
which would allow a planned outage period to be scheduled for a
Resource (typically a server or a platform). During a planned outage,
avail-goes-DOWN alerts would automatically be disabled by the RHQ Server.
On 08/03/2010 01:21 PM, John Sanda wrote:
On 8/3/10 12:40 PM, Steve Millidge wrote:
Hi Steve,
I just spent a few minutes reviewing the APIs, and it does not appear
that we currently support disabling alert definitions
programmatically. You could open a feature request bug, and this might
be something that could get included in a future RHQ release. If you
are looking for a more immediate solution though, an alternative might
be a server-side plugin
(
http://www.rhq-project.org/display/RHQ/Server+Plugin+Development)
which gives even greater access to RHQ apis. And if you prefer a
scripting approach, I'd be happy to further discuss how you could
integrate scripting capabilities into a server-side plugin.
- John
Hi,
I've got a question or a future requirement.
I'm setting up an environment for a customer and we have a number of
alerts set so that if a JBoss server crashes it can be automatically
restarted. The problem is if an administrator wants to stop a server
or group of servers then they have to remember to disable the alert
before shutting down JBoss otherwise RHQ will just restart the JBoss
server.
Is there any way of scripting this using the CLI? If so I could create
a custom stop script that disabled the alert using the CLI.
Alternatively are there any plans to provide functionality that could
link whether an alert is disabled or enabled based on an operation.
This customer is migrating from WebLogic and they are used to the Node
Manager which can keeps track of which servers should be running and
which have been manually stopped and do the right thing.
Steve Millidge
Director
C2B2
*Providing the foundations for Enterprise Scale Java.*
T: 08450 539457
M: 07920 100626
W:
www.c2b2.co.uk <
http://www.c2b2.co.uk/>
E: smillidge(a)c2b2.co.uk <mailto:smillidge@c2b2.co.uk>
C2B2 Consulting Limited
Unit 33, Malvern Hills Science Park
Geraldine Road
Malvern
Worcestershire
WR14 3SZ
Registered in England and Wales: 4563419
Registered Office: Ardendale, Old Hollow, Malvern, Worcestershire
_______________________________________________
rhq-users mailing list
rhq-users(a)lists.fedorahosted.org <mailto:rhq-users@lists.fedorahosted.org>
https://fedorahosted.org/mailman/listinfo/rhq-users
_______________________________________________
rhq-users mailing list
rhq-users(a)lists.fedorahosted.org <mailto:rhq-users@lists.fedorahosted.org>
https://fedorahosted.org/mailman/listinfo/rhq-users
--
Ian Springer
Sr. Software Developer
JBoss Operations Network
Red Hat
ian.springer(a)redhat.com <mailto:ian.springer@redhat.com>
_______________________________________________
rhq-users mailing list
rhq-users(a)lists.fedorahosted.org <mailto:rhq-users@lists.fedorahosted.org>
https://fedorahosted.org/mailman/listinfo/rhq-users
_______________________________________________
rhq-users mailing list
rhq-users(a)lists.fedorahosted.org <mailto:rhq-users@lists.fedorahosted.org>
https://fedorahosted.org/mailman/listinfo/rhq-users
- Greg
_______________________________________________
rhq-users mailing list
rhq-users(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/rhq-users