Creating alert definitions with CLI
by Michael Burman
Hi,
About the long standing RFE (BZ 617202), I'd like to ask for your opinions. I've done some work and a preliminary implementation that would make creating definitions through CLI as close as possible to the GUI interface. Now I would like to have some opinions, if I'm taking the right route and if you have any wishes. I try to employ the builder-pattern in this case and I tried to use existing domain-models (I haven't changed any existing ones to preserve backwards compatibility) whenever it made sense.
So here's the sort of query language I have in place now ("working" example):
AlertDefinitionTemplate template = new AlertDefinitionTemplate()
.enabled(true)
.description("description")
.name("name")
.priority(AlertPriority.MEDIUM)
.alertProtocol(BooleanExpression.ANY);
// Set recovery rules
template.recovery()
.disableWhenFired(false);
// Set dampening rules
template.dampening()
.category(AlertDampening.Category.CONSECUTIVE_COUNT)
.occurences(2);
// Add AlertConditions
template.addCondition(AvailabilityCondition.class)
.availability(AlertConditionOperator.AVAIL_GOES_DOWN);
template.addCondition(AbsoluteValueCondition.class)
.comparator(AlertConditionOperator.GREATER_THAN)
.value(90.0)
.metric(11465);
Function names might not be consistent yet in all cases (I've tried to keep them short, but in some cases I couldn't think of very short descriptive one). There's no PR yet for this.
- Micke
9 years, 5 months
RHQ plugins by iAd
by Elias Ross
I have just released a number of plugins, mostly for monitoring OSS
software here:
https://github.com/genman/rhq-plugins
Some of them are a bit rough around the edges, but most have been in
use for many years at my company.
The most significant one, I think, is the SNMP plugin, which can
generate a working plugin descriptor for any device that has a MIB.
Included are plugin descriptors for Citrix Netscaler, Fusion-io, and
NetApp filer generated by the plugin. Obviously cleaning up the
descriptor may be required in some cases.
For the full list: https://github.com/genman/rhq-plugins/blob/master/README.md
9 years, 5 months
Fwd: [wildfly-dev] Management Model: Squatter Resources
by Heiko W.Rupp
Something to consider (& possibly chime in) for support of future WildFly versions in the as7 plugin
> Anfang der weitergeleiteten Nachricht:
>
> Von: Jeff Mesnil <jmesnil(a)redhat.com>
> Datum: 30 Oct 2014 11:40:07 CET
> An: Heiko Braun <hbraun(a)redhat.com>
> Kopie: WildFly Dev <wildfly-dev(a)lists.jboss.org>
> Betreff: Aw: [wildfly-dev] Management Model: Squatter Resources
>
> I’m integrating HornetQ 2.5 in WildFly and I have a new use case for resources that is related to singleton/squatter resources.
>
> In HornetQ 2.5 they have completely rewritten the HA configuration. Basically, a server can be configured as live-only, replicated (master, slave, or colocated) or using shared-store (again as a master, slave or colocated).
>
> To represent this in the management model, I have added several resources under hornetq-server:
>
> /subsystem=messaging/
> hornetq-server=*/
> ha-policy=live-only
> ha-policy=replicated-master
> ha-policy=replicated-slave
> ha-policy=replicated-colocated
> ha-policy=shared-store-master
> ha-policy=shared-store-slave
> ha-policy=shared-store-colocated
>
> I have constraints for this ha-policy resource:
> * There can at most one child for this type of resource (no child means no HA). This is enforces during the MODEL stage.
> * The child can only be named using one of the 7 values above (i.e. there is no resource definition for ha-policy=*, using any other name would fail)
>
> Each ha-policy definition has a different set of attributes. Using an attribute group to represent the HA policy does not seem a good fit as some of them have subresources too.
>
> I wonder if that representation fits with our roadmap and whether it can be considered as a singleton (as there can only be one resource of that type among). I have the additional constraints of having only one chile for that type that is not covered by your proposal though.
>
> I especially wonder how the console (and to a lesser extent the cli) can deal with this resource.
>
> Heiko, is it something that would make sense for the console based on this resource description:
>
> [standalone@localhost:9990 hornetq-server=default] ./ha-policy=*:read-resource-description(recursive-depth=1)
> {
> "outcome" => "success",
> "result" => [
> {
> "address" => [
> ("subsystem" => "messaging"),
> ("hornetq-server" => "default"),
> ("ha-policy" => "replication-colocated")
> ],
> "outcome" => "success",
> "result" => {
> ...
> }
> },
> {
> "address" => [
> ("subsystem" => "messaging"),
> ("hornetq-server" => "default"),
> ("ha-policy" => "replication-master")
> ],
> "outcome" => "success",
> "result" => {
> ...
> }
> },
> {
> "address" => [
> ("subsystem" => "messaging"),
> ("hornetq-server" => "default"),
> ("ha-policy" => "shared-store-slave")
> ],
> "outcome" => "success",
> "result" => {
> ...
> }
> },
> {
> "address" => [
> ("subsystem" => "messaging"),
> ("hornetq-server" => "default"),
> ("ha-policy" => "live-only")
> ],
> "outcome" => "success",
> "result" => {
> ...
> }
> },
> {
> "address" => [
> ("subsystem" => "messaging"),
> ("hornetq-server" => "default"),
> ("ha-policy" => "shared-store-master")
> ],
> "outcome" => "success",
> "result" => {
> ...
> }
> },
> {
> "address" => [
> ("subsystem" => "messaging"),
> ("hornetq-server" => "default"),
> ("ha-policy" => "replication-slave")
> ],
> "outcome" => "success",
> "result" => {
> ...
> }
> },
> {
> "address" => [
> ("subsystem" => "messaging"),
> ("hornetq-server" => "default"),
> ("ha-policy" => "shared-store-colocated")
> ],
> "outcome" => "success",
> "result" => {
> ...
> }
> }
> ]
> }
>
> jeff
>
> --
> Jeff Mesnil
> JBoss, a division of Red Hat
> http://jmesnil.net/
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
--
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
9 years, 5 months
RHQ plug-in runs-inside + new subcategories
by Larry O'Leary
Hello
The first part for what I need is pretty simple. To be able to create my
plug-in which runs-inside an existing one. For that I can use the
runs-inside element.
My plug-in is exposing many new services for which I would like to be
organized under a single subcategory under the parent. Based on the work
that was done in https://bugzilla.redhat.com/show_bug.cgi?id=796480 this
is also possible. However, that assumes the subcategory was already
defined in the parent plug-in.
Is it possible to organize my services under a new subcategory under the
parent without modifying the parent plug-in? For example:
The parent plug-in has its own descriptor and can not be modified:
<plugin parent>
<server name="a">
<subcategories>
<subcategory name="foo"/>
</subcategories>
</server>
</plugin>
My custom child plug-in extends the parent plug-in's resource type by
adding new services:
<plugin child>
<service name="a-child" subCategory="bar">
<runs-inside>
<parent-resource-type name="a" plugin="parent">
<subcategories>
<subcategory name="bar" />
<subcategories>
</runs-inside>
</server>
</plugin>
Basically I need the ability to define new subcategories for the parent
plug-in type a from within my custom child plug-in. This will then allow
be to map my new service(s) a-child to the subcategory bar.
Thanks,
--
Larry O'Leary
https://plus.google.com/+LarryOLeary
9 years, 5 months
Sizing guidelines for future RHQ inventories
by Lukas Krejci
Hi all,
we are starting to re-think RHQ to bring it forward to the cloud-ready, IoT
and other brave new worlds and would like to hear your feedback on what an RHQ
inventory might "look like" in the future.
I am basing the below on the forum article
https://developer.jboss.org/en/rhq/blog/2014/09/25/thoughts-on-inventory-... (including comments and links) which describes in high level our
current thinking about the architecture of the new inventory.
I just pulled some random numbers almost out of thin air (the sizing is based
on the anecdotal evidence I gathered from the community about the sizes of the
larger inventories people are managing).
I'd like gather feedback on both the numbers and the structure of the
inventory.
To mimick the basic, still important, tree structure of the classic RHQ
inventory:
* there is 1000 agents (machines)
* There are 50 resource types
* Hierarchy is 7 elements deep
* There are 10 types of top level resources
* 5 of the top level resources have children (think servers per machine)
* only 2 resources have full 7 element deep hierarchy
* There are 10 resource groups
* All resources are part of at least 1 group (either explicitly or implicitly)
* Every resource has 5-10 metric schedules, 2 operations
* Plugin config of each resource has 2-20 properties
* Resource config of each resource has 2-20 properties
To mimick the new requirements:
* Each resource is part of 1 application (either explicitly or implicitly)
(did I hear these are the same as mixed groups? ;) )
* 1% of the resources is part of 10 applications (shared infra like db server)
* Each resource has 5-10 versions (to mimick changes in config/schedules)
* There are 10000 "miniagents" (some on machines managed by the "real" agents,
some outside of them)
* Each miniagent defines 1-10 resource types
* 5 of these resource types are equivalent to the resource types from full-
blown agents
* mini-agent defines 1-20 resources which have metrics and configs with the
same sizing as on the real agent. No operations though.
WDYT?
I am going to use these guidelines as a basis for a benchmark that should help
us choose the right storage solution for the data.
The benchmark will be mostly focused on query performance because the inflow
of the data won't be that huge with rhq-inventory (meaning the rate of change
of the inventory itself is not going to be big). The rhq-inventory endpoint
will have a high throughput component that will establish identity of the
input data but that is mostly not going to end up being persisted. It is most
probably going to be merely routed somewhere else (metrics, audit, alerts,
...).
Thanks,
Lukas
9 years, 6 months
Server plugin contributions to RHQ
by Elias Ross
I just released this project:
https://github.com/genman/rhq-server-plugins
These are plugins that might make sense as part of RHQ or not. But
they are useful for me at least, and maybe some other users.
Somewhat related to RHQ is this project that I also released:
https://github.com/genman/jmx-annotations
If you dig into this directory
https://github.com/genman/jmx-annotations/tree/master/annotations/src/mai...
you will see that there are RHQ specific annotations that you can put
on your CDI beans, and when exposed through JMX, there is meta-data
present in MBeanInfo which can be used to automatically create an RHQ
agent plugin descriptor. (The plugin generator I plan to release as
well...) For example:
@ManagedAttribute
@Units("bytes")
@Description("Total bytes sent in response")
@MeasurementType("trendsup")
@DefaultInterval(1000 * 60 * 5)
public long getBytesSent() {
return bytesSent;
}
I'm trying to release the Agent plugins as well, but there is a lot of
code and the approvers are a bit alarmed.
9 years, 6 months
Java updates available
by Heiko W.Rupp
Hey,
just as FYI:
Oracle has released updates for Java 7 and 8 which fix some *critical security issues*.
See http://www.oracle.com/technetwork/java/javase/downloads/index.html
Open JDK 7 has also been updated to 7u71
--
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
9 years, 6 months
AUTO: David A. Webster is out of the office (returning 10/13/2014)
by David A. Webster
I am out of the office until 10/13/2014.
On Vacation, will be back Monday, August 18.
Note: This is an automated response to your message "Please review pull
request for "Bug 1004977 - Datasource configuration changes SHOULD NOT
require a complete reload/restart of EAP"" sent on 10/8/2014 11:07:12 AM.
This is the only notification you will receive while this person is away.
**
This email and any attachments may contain information that is confidential and/or privileged for the sole use of the intended recipient. Any use, review, disclosure, copying, distribution or reliance by others, and any forwarding of this email or its contents, without the express permission of the sender is strictly prohibited by law. If you are not the intended recipient, please contact the sender immediately, delete the e-mail and destroy all copies.
**
9 years, 6 months
Please review pull request for "Bug 1004977 - Datasource configuration changes SHOULD NOT require a complete reload/restart of EAP"
by Thomas Segismont
Hi,
I've been fighting with the Datasource subsystem the last couple of days
and eventually sent a pull request for "Bug 1004977 - Datasource
configuration changes SHOULD NOT require a complete reload/restart of EAP"
Here's the commit summary.
====
"Enabled" attribute is no longer an editable configuration property (it
will still be available on (xa-)datasource creation).
Instead, users will have to use the "Enable"/"Disable" operations.
"Enable"/"Disable" definitions have been changed to include a new
"allow-resource-service-restart" property, defaulting to false.
If set to true, the corresponding management request header will be
added. This allows to disable/enable a datasource without a server reload.
The datasource component update configuration logic has been enhanced to
send only configuration changes. It requires an extra request
to read the current datasource config, but it avoids a server reload or
datasource disable/enable cycle if the user only wants to
change a set of properties which do not require it.
Also, a new specific component class has been added for the datasources
subsystem resource type. It used to be shared with the (xa-)datasource
component.
While in the beginning it probably was easier to have a single class for
code sharing between the "Create Child Resource" process and the "Update
Configuration Process",
the (xa-)datasource component logic has become quite complex so it's
safer to have separate component classes.
Eventually, the plugin descriptor has been updated to document that some
(xa-)datasource properties cannot be unset if they already have a value.
====
Would any one like to review? I'm currently writing new AS7 plugin
itests for the datasource component and I'll hopefully push them tomorrow.
https://github.com/rhq-project/rhq/pull/136
Thanks,
Thomas
9 years, 6 months