RHQ Metrics - 0.2.7 & Hawkular Future
by Stefan Negrea
Hello Everybody,
I want to summarize the latest release of the RHQ Metrics project and the future of the project.
1) RHQ Metrics migrates to Hawkular organization
Release 0.2.7 of the RHQ Metrics is the last one from the current repository. But do not panic! Beyond the mechanics of the transfer and rename, the development will continue with the regular crew.
For the migration, two project repositories (rhq-metrics and rhq-metrics-openshift) will just be transferred to the Hawkular organization. The code from rhqm-charts was already moved to Hawkular, so we will just close the RHQ repository. We will have a follow up communication once all the infrastructure is in place under the new organization.
2) RHQ Metrics 0.2.7 was released today
This release has mainly stability fixes and minor enhancements. The Keycloak integration was delayed and not part of this release (as announced in the planning notes). For more details checkout the Github release notes.
Github Release:
https://github.com/rhq-project/rhq-metrics/releases/tag/0.2.7
JBoss Nexus Maven artifacts:
http://origin-repository.jboss.org/nexus/content/repositories/public/org/...
2) OpenShift Cartridge for RHQ Metrics 0.2.7
The cartridge supports RHQ Metrics 0.2.7, 0.2.6, and 0.2.5. Just a reminder, the cartridge is the simplest and easiest way to get a public facing instance of RHQ Metrics in just a few minutes with a single command. The cartridge configures Cassandra, Wildfly, and RHQ Metrics (REST interface and UI console) to run in a single gear. For more details please visit the Github repository of the project.
Sample command to create a new RHQ Metrics deployment:
rhc app create test_app https://raw.githubusercontent.com/rhq-project/rhq-metrics-openshift/maste...
Github Repository:
https://github.com/rhq-project/rhq-metrics-openshift
A big "Thank you!" goes to John Sanda, Mike Thompson, Heiko Rupp, and Thomas Segismont for their project contributions.
Any discussion, suggestions or contributions are more than welcomed; so feel free to reply to this email or comment directly on the various forum threads.
Thank you,
Stefan Negrea
Software Engineer
_______________________________________________
rhq-devel mailing list
rhq-devel(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/rhq-devel
11 years
generation of message POJOs via JSON schema
by John Mazzitelli
There is this really nice maven plugin that takes JSON schema and generates Java POJOs annotated with GSON annotations. I took this stuff and created a sample module in the bus repo and see how it works. It works very nicely and I think we can use this very easily in our stuff.
First, here is a site that discusses JSON schema if you aren't familiar (its essentially like XML Schema only for JSON):
http://json-schema.org/documentation.html
We can use this maven plugin to generate an API that our Java components can use to talk to each other. To see what the generated code looks like with any JSON schema, here's a play area where you can see it in realtime:
http://www.jsonschema2pojo.org/
Here's what my sample JSON schema looks like (you'll see it uses primitives as well as sets/lists and embedded types (see address type) and a set of embedded types (see phoneNumbers):
https://github.com/hawkular/hawkular-bus/blob/master/hawkular-bus-samples...
Here is where my test code creates the message via the POJO API that was generated by the maven plugin:
https://github.com/hawkular/hawkular-bus/blob/master/hawkular-bus-samples...
If we use this stuff, we write the JSON schema which automatically provides documentation that non-Java clients can use to know what the clients need to send/consume, or they can use the schema themselves to generate their own client code. We use the schema internally to generate Java POJOs that we then use in our Java components (like what my sample code demonstrates).
Here is what the maven plugin usage looks like - its pretty simple:
https://github.com/hawkular/hawkular-bus/blob/master/hawkular-bus-samples...
11 years, 1 month
Forecasting of bad things
by Heiko W. Rupp
Something I was talking about for a while ...
I saw this today in Android 5 - they give you (when the device is running on battery) not only a
chart about past battery consumption (dark green), but also about estimated future depletion (grey-green)
and on top of the chart the current state (40%) + an estimate that the battery will last ~4 more days at the
same usage level.
--
Heiko Rupp hwr(a)pilhuhn.de
Blog: http://pilhuhn.blogspot.com @pilhuhn
11 years, 1 month
Notification messages
by Gary Brown
Hi
Started looking at Hawkular alerts with an eye on RTGov eventually using the notification mechanism to represent what we currently store/display as 'situations'. Had a couple of questions:
1) The notification message currently has a notifierId - so does this mean an alert trigger will only have a single notifer? Or could a single alert (notification message) potentially be sent to multiple notifiers (e.g. twitter, email, etc.) - and if so require a notifierId list?
2) Only other field is currently a description, which is fine for targets such as email, twitter etc, but in RTGov 'situations' are also used to hold other information that can be used to understand the source of the problem, and tie it back to the originating business transaction. Will it be possible to add such fields to the notification message, even though they may not be relevant for the email/sms/twitter type notifiers?
Regards
Gary
11 years, 1 month
maven stuff
by John Mazzitelli
Right now I've seen version strings as 1.0-SNAPSHOT, 1.0.0-SNAPSHOT and 1.0.0.Alpha1-SNAPSHOT.
We need to come to a consensus and be consistent. From what I understand, people prefer:
1.0.0-SNAPSHOT
I would like to go through all our components and change their versions to be that. It would be nice to have our first distro release at least be consistent in naming of versions.
In addition, its getting annoying with having to rely on release versions of parent pom. I'm again waiting on release 8 because I added a new maven plugin to the parent. We should move every pom over to use 8-SNAPSHOT so we can keep picking up changes. We are moving fast, and its slowing us down (well, me down for one) because we now have poms that need parent pom v6 and v7 and my stuff is waiting on 8. We can release when we get some kind of product out.
There is also discussion that lucas k brought up - why not have version string for parent pom follow the same convention as everything else (that is, why not make 8-SNAPSHOT to be 1.0.0-SNAPSHOT instead?) I'll let others decide that later. I agree we should at least be consistent in version format for everything.
11 years, 1 month
kettle build
by John Mazzitelli
<tl;dr>
1. Nest/Kettle builds now use XSLT to tweak the standalone.sh, rather than us having to maintain a full version of it in git.
2. Kettle is now in master branch - just "mvn install" in hawkular repo and you'll get it.
3. Still getting a metrics error - see below for stack trace.
</tl;dr>
I refactored the way the nest distro and the kettle distro configures the wildfly server.
For those that are unaware, the "nest" is a wildfly build that includes the bus infrastructure and the nest deployer - its a "container" that we can deploy things into (like alerts, or inventory, or even agent components in the future - its meant to be clusterable in the future with the bus being the communications conduit between nests).
The "kettle" is that nest distribution with all of our hawkular integration components deployed inside - inventory, alerts, metrics, embedded C*, the UI console, etc.
It now uses XSLT (via the xml maven plugin) to tweak the out of box wildfly standalone.xml. So we no longer have our own full standalone.xml in git - we take the one that comes with wildfly and tweak it for our needs via XSLT.
Also, the kettle is now in the hawkular repo master branch. Everything should be in the nexus snapshot repo, so if you just git clone hawkular and "mvn install", you'll get the kettle distro in hawkular/kettle/target (its a zip file - just unzip it and run standalone.sh like any other wildfly).
There is still a metrics error when you run the kettle - nothing that I did, I don't think. Here's the exception - does someone know what this is?
20:18:16,273 WARN [org.jboss.weld.deployer] (MSC service thread 1-5) JBAS016006: Could not load portable extension class org.hawkular.metrics.restServlet.EagerExtension: java.lang.ClassNotFoundException: org.hawkular.metrics.restServlet.EagerExtension from [Module "deployment.hawkular-metrics-api-jaxrs-0.3.0-20150220.180642-17.war:main" from Service Module Loader]
at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:213) [jboss-modules.jar:1.3.3.Final]
at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:459) [jboss-modules.jar:1.3.3.Final]
at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:408) [jboss-modules.jar:1.3.3.Final]
at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:389) [jboss-modules.jar:1.3.3.Final]
at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:134) [jboss-modules.jar:1.3.3.Final]
at org.jboss.as.weld.deployment.processors.WeldPortableExtensionProcessor.loadExtension(WeldPortableExtensionProcessor.java:131) [wildfly-weld-8.2.0.Final.jar:8.2.0.Final]
at org.jboss.as.weld.deployment.processors.WeldPortableExtensionProcessor.loadAttachments(WeldPortableExtensionProcessor.java:117) [wildfly-weld-8.2.0.Final.jar:8.2.0.Final]
at org.jboss.as.weld.deployment.processors.WeldPortableExtensionProcessor.deploy(WeldPortableExtensionProcessor.java:81) [wildfly-weld-8.2.0.Final.jar:8.2.0.Final]
at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:159)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_31]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_31]
at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_31]
11 years, 2 months
Metrics reporting into hawkular-metrics
by Heiko W.Rupp
Hey,
we need to have an endpoint that accepts a list of
<name, timestamp , value> triples.
The current
@POST
@Path("/{tenantId}/metrics/numeric/data")
@Consumes(APPLICATION_JSON)
public void addNumericData(@Suspended final AsyncResponse asyncResponse, @PathParam("tenantId") String tenantId,
List<NumericDataParams> paramsList) {
does not work (not technically).
A client (think "agent") will not send a list of dozens of metric values for one metric id. And then in a next request for another.
Especially not, when an agent is monitoring 10 resources and is then reporting their data. All reported metrics will have
a different id.
The other similarly challenged endpoint is
@POST
@Path("/{tenantId}/metrics/numeric/{id}/data")
@Consumes(APPLICATION_JSON)
public void addDataForMetric(@Suspended final AsyncResponse asyncResponse,
@PathParam("tenantId") final String tenantId, @PathParam("id") String id, List<NumericDataPoint> dataPoints) {
The metric id is passed on the URL-Path and thus requires a new request per metric to report.
The above 2 endpoints may be consistent with their respective GET endpoints, but here we have the use case that I want
to read mass data for one single id.
Reporting use cases are different.
11 years, 2 months
Importing JBoss BoMs to Hawkular Parent
by Peter Palaga
Hi John,
was there any discussion (that I may have missed during my PTO) around
importing the jboss-javaee-7.0-with-all to parent? Could you please
justify the idea once again for me?
I must say I'd veto the change if I was at work. Here is why:
(1) Tying to WildFly only. The change might be understood like this. I
am not sure this was your intention, but please consider that importing
another similar BoM (say EAP BoM) in paralel would in fact be extremely
impractical, because of version conflicts.
(2) Pulling in many artifacts we do not use, do not need, some of them
maybe being implicitly unwanted ones. But having them in parent is
actually legalizing them without any discussion. That is especially
dangerous.
(3) "Political" dependence on WildFly. WildFly may do changes at any
time in their BoMs that may have bad consequences in Hawkular.
The bottom line is that it would be much better to avoid situations this
through discussing proposals prior to merging them in master. I have
proposed explicit parent contribution rules in
https://github.com/hawkular/hawkular-parent-pom/pull/13 Feel free to
comment on them.
11 years, 2 months
