[rhq.metrics] Standalone RHQ Metrics Chart Tags (First Cut)
by mike thompson
The purpose of the standalone tags is to provide a lighter weight version of the rhq-metrics tags so that they can work in a standalone web page. A wiki page could embed the chart tags, and in a few lines of code pull data from various metrics on several rhq-metrics machines updating the live values at specified refresh intervals. This lowers the barrier of entry on creating custom metric dashboards.
To make this even easier we have a button in the top right of the metrics console that when pressed copies the correct html for the graph show to the clipboard. Now, just paste it into the page and add the proper javascript libraries to page for instant gratification.
Example:
<rhqm-chart chart-type="area"
metric-id="hrupp-rhq-metrics-saas.wildfly.heap-memory-usage.used"
metric-url="http://10.3.10.81:8080/rhq-metrics/metrics/"
time-range-in-seconds="86400"
refresh-interval-in-seconds="60"
chart-height="250"></rhqm-chart>
There is still more work to be done slimming down the dependencies and making a bower package for it. Incorporating the more advanced features of the full blown charting directive is also outstanding.
— Mike
And Here is the cut-n-paste button:
9 years, 5 months
RHQ plugin can't find class in included jar
by Ken Louie
Hi,
I recently updated one of our RHQ plugins to include an implementation of ws-management. I added the following jars to the lib/ folder within the plugin jar:
wiseman-core.jar
wiseman-client.jar
We have a ResourceComponent which uses an API, which in-turn uses ws-management to make configuration changes to one of our other servers. However, when we call this API in our ResourceComponent , and it tries to use ws-management, I'm getting the following error:
java.lang.reflect.UndeclaredThrowableException
at com.sun.proxy.$Proxy70.updateResourceConfiguration(Unknown Source)
at org.rhq.core.pc.configuration.LegacyConfigManagement.executeUpdate(LegacyConfigManagement.java:87)
at org.rhq.core.pc.configuration.UpdateResourceConfigurationRunner.call(UpdateResourceConfigurationRunner.java:121)
at org.rhq.core.pc.configuration.UpdateResourceConfigurationRunner.run(UpdateResourceConfigurationRunner.java:109)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:178)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:292)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.lang.Exception: java.lang.NoClassDefFoundError: Could not initialize class com.sun.ws.management.transfer.Transfer
at org.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:639)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
... 3 more
Caused by: java.lang.NoClassDefFoundError: Could not initialize class com.sun.ws.management.transfer.Transfer
at com.sun.ws.management.client.impl.TransferableResourceImpl.setTransferProperties(TransferableResourceImpl.java:451)
at com.sun.ws.management.client.impl.TransferableResourceImpl.get(TransferableResourceImpl.java:531)
at com.sun.ws.management.client.impl.TransferableResourceImpl.get(TransferableResourceImpl.java:516)
at com.sun.ws.management.client.impl.TransferableResourceImpl.get(TransferableResourceImpl.java:504)
I'm not sure why this is happening. The class: com.sun.ws.management.transfer.Transfer exists in wiseman-core.jar, which is included in the lib/ directory within the plug-in jar. I'm pretty sure this is the right location to put the jars, since I have other jars in this lib/ folder, and the plug-in seems to use them just fine (i.e. it seems to be able to use wiseman-client.jar) .
Does anyone know why this issue would be happening, and how I could resolve it? Appreciate the help
Thanks
9 years, 5 months
Using rhq-devel for RHQ.next discussions
by Thomas Segismont
Hi everyone,
Are you all ok that we use the rhq-devel for RHQ.next discussions? Can
we use a prefix for this emails? Maybe [rhq.next]?
Regards,
Thomas
9 years, 5 months
Aggregation Time Slices - BZ 1161806
by Stefan Negrea
Hello Everybody,
I want to start a discussion about BZ 1161806 [1]. We discovered an issue with a few integration tests [2] in the server-metrics module about a week ago. What seemed just a few bad tests or an environmental problem led to the discovery of a bigger problem with metrics aggregation. This email is just a summary of the BZ contents with the goal to make sure we did not miss anything. A big thank you goes to John Sanda and Jay Shaughnessy for helping with the solution and code fixes.
1) Background
- All metric data is stored with epoch time, not timezone dependent
- Aggregation is done in time slices. For example, the 6 hour aggregation for a single metric is sliced into data aggregates at 00:00, 06:00, 12:00, and 18:00
- 1 hour aggregation is not sensitive to timezones (or DST transitions) because top of the hour is top of the hour regardless of timezone
- 6 and 24 hour aggregations were sensitive to timezones (and DST transitions) because the slices were calculated in local timezone
2) Impact
- Aggregation for 1 hour metrics was minimally impacted - only DST transitions could cause at most 1 hour to not be computed due to clock rolling
- Aggregation for 6 hour metrics and 24 hours metrics was highly impacted:
- When DST transitions occur, the aggregation indexes would not be queryable until the DST transition was beyond the metrics index query boundaries
- In an HA environment with RHQ servers in different timezones, when switching servers the aggregation for past data would stop working
3) Solution
- Switch the time slices for 6 and 24 hour aggregates to be based on UTC timezone regardless of the local timezone
- The metrics indexes updates slated for RHQ 4.13 will rebase the 6 and 24 hour timeslices to UTC time slices
- The BZ has a nice diagram [3] that we used to find a good solution for the time slice rebasing
4) Future
- Will investigate the impact on RHQ 4.12 and prior to see if any fixes are needed
- We are too late to release a fix for RHQ 4.12 and prior just address the DST transitions because most of the countries have switched for over 2 weeks (the query boundary for metrics indexes)
- We strongly recommend everybody to update to RHQ 4.13 once it is released
All feedback is welcome ...
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1161806
[2] https://github.com/rhq-project/rhq/blob/master/modules/enterprise/server/...
[3] https://bugzilla.redhat.com/attachment.cgi?id=956797
Thank you,
Stefan Negrea
Software Engineer
9 years, 5 months
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, 6 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, 6 months
RHQ and Java 9
by Heiko W.Rupp
Java 9 is trying to modularize the platform and as such is changing how things are laid out and potentially also downloaded / installed.
The proposed changes are listed here: http://openjdk.java.net/jeps/220
One that may affect RHQ is "Removed: rt.jar and tools.jar",
where some plugins (jmx) or tooling (maven build) are currently relying
on tools.jar being present.
We need to keep an eye on this and test RHQ with early versions of 9
as soon as JigSaw has been added to Java 9
--
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