Funny compilation issue on Hawkular? Downgrade to JDK 1.8.0_51 for a minute
by Juraci Paixão Kröhling
Team,
We just had a case today about Hawkular failing to build on my machine
after updating to a specific version of the Agent. While *this* specific
issue is going away with a change from Peter, you might still see this
for a while.
So, if you see a build error on Hawkular related to a compilation issue
for
agent/hawkular-dmr-client/src/main/java/org/hawkular/dmr/api/OperationBuilder.java
, you can just:
- switch to Oracle's or OpenJDK's 1.8.0_51
- cd ~/.m2/dependency-sources/agent
- mvn clean install
- build Hawkular (with whatever JDK you want)
The third step will build the required version of Agent inside srcdep's
cache directory, effectively bypassing the issue.
- Juca.
9 years, 1 month
some new agent features
by John Mazzitelli
Just wanted to blast out a message about some new wildfly agent features.
1) Agent now supports secure communications between itself and any of its managed WildFly servers. I documented how to enable security in the management interface of WildFly here:
https://github.com/hawkular/hawkular.github.io/blob/pages/src/main/jbake/...
2) Agent now supports monitoring JMX resources via Jolokia interface.
The agent now can collect JMX metrics and availability data and can inventory JMX resources in the same manner as it can with DMR resources using the Jolokia interface (Jolokia is a very nice REST interface to JMX). Just as we have <metric-dmr>, <avail-dmr>, <resource-type-dmr>, <remote-dmr>, and related DMR settings in the agent subsystem, we now have <metric-jmx>, <avail-jmx>, <resource-type-jmx>, <remote-jmx> settings as well. So the agent can be given metadata that tells it what to do. As with remote WF servers, the agent also supports secure comm to the remote jolokia JMX server.
There are a few things currently on the TODO for the agent:
1) utilize the new inventory "name" attribute - they now have "name" as a first-class setting - I need to see what the agent has to do to use it
2) utilize the inventory's "operation" metadata - I believe operations are now first class concepts in inventory - I need to figure out how to populate it
3) provide a mechanism for the agent to detect runtime changes to inventory. Right now, after the agent does its initial inventory scan, that's it. The inventory is fixed, all resource configuration is fixed, and all we do is collect metrics. The caveat is that if someone deploys a new app or adds a new JDBC driver, we force a new scan. We need a way to detect new resources in inventory (and old resources removed from inventory) and we need a way to detect changes to resource config. This should work for both DMR and JMX inventory items.
4) Need a way to consume wildfly notifications that other subsystems emit and figure out how to send that to a hawkualr events subsystem.
5) Peter is implementing/has implemented the JDBC driver CRUD and datasource CRUD, gonna see how easy it is to implement reload.
I'm sure I'm forgetting something, but .. that's what I remember.
9 years, 1 month
Travis cache pruning
by Peter Palaga
Hi *,
because we had no cache pruning in place, the cached ~/.m2/repository in
hk main became too bing. As a consequence of that, when Travis attempted
to zip the cached folder, the cache archive made the disk full and not
only that the cache could not be uploaded outside of the transient
docker container, also all subsequent tasks (deployment of SNAPSHOTs)
failed.
I could not find a working pruning script quickly enough. To solve the
problem temporarily at least, I deleted the cache manually under
https://travis-ci.org/hawkular/hawkular/caches
Best,
Peter
9 years, 1 month
Hawkular Inventory 0.6.0.Final released
by Lukas Krejci
Hi all,
I'd like to announce that we've just released Hawkular Inventory 0.6.0.Final.
This release doesn't have many new features, in fact it doesn't have any. This
is purely a bugfix release but we decided to bump the minor version anyway
because of the one big improvement we've made. The read queries should now be
way more performant than they used to (up to an order of magnitude).
The release includes:
* improved logging of initialization failures
* adaptation to the new bus API introduced in Hawkular Bus 0.7.x
* more consistency checks on relationships of inventory entities
* streaming serialization should now work (still off by default) giving a
slight speed boost to REST calls
* Many querying optimizations (collapsing of hops into a single index lookup,
more indices on frequently queries properties, reducing the number of
scenarios requiring backtracking in graph queries, filtering on mirrored
immutable properties of vertices on edges) giving up to an order of magnitude
speed up on read REST calls.
* Moved integration tests to the component so that we can properly test all
scenarios conveniently.
* Fixes to support windows paths in configuration.
This release was made possible thanks to the contributions of the following
fine gentlemen:
Jay Shaughnessy
Jirka Kremser
John Mazzitelli
Lukas Krejci
Pavol Loffay
Peter Palaga
Future releases already have some pull requests ready for inclusion - namely:
* introduction of "name" as a first-class property on entities (instead of
being just a free-form unindexed user-defined property),
* move of feeds from environments directly under tenants, making it possible
to easily move feeds between envs and requiring 1 less thing to remember by
feeds (this will break clients but is hopefully worth it given the early stage
of development of everything Hawkular).
Well under way is the development of "metadata packs", aka "global resource
types". A feature that will enable feeds to very quickly check for presence of
a set of resource, metric and operation types with precise properties
(configurations, parameters, units, etc.) by computing their "content hash"
locally and checking with inventory if a pack with such hash exists.
Thanks,
Lukas
9 years, 1 month
ActiveMQ and JMS
by John Sanda
Hawkular uses ActiveMQ for JMS. I learned earlier this week that ActiveMQ implements JMS 1.1 but not 2.0 which has been out for some time and is in WildFly 9. JMS 2.0 has some nice changes including async sending of messages. In JMS 1.1 the client blocks until the server acknowledges successful delivery of the message. In 2.0 the sender can receive that acknowledgement asynchronously via a callback.
HornetQ is the default JMS provider in WildFly 8/9. If I am not mistaken part of the reason to go with ActiveMQ was due to the uncertainty around the future of HornetQ. HornetQ is now ActiveMQ Artemis[1] and will be the JMS provider in WlidFly 10haw. It does not look like ActiveMQ will implement JMS 2.0 any time soon which again, has been out for some time. Can/should we consider switching to HornetQ/Artemis?
[1] https://activemq.apache.org/artemis/ <https://activemq.apache.org/artemis/>
- John
9 years, 1 month
hawkular.org
by Thomas Heute
I have proposed a rework of hawkular.org.
The idea is to make it more clear what features are offered. The actual
management console is pushed back a bit as this is less advanced than the
services such as metrics + alerts.
The PR is here, and can be previewed here for the next 3 days:
http://209.132.178.114:10108/
With Thomas's work on the REST API documentation, it should help people who
just need metrics+alerting(+inventory?+BTM?) to understand how they can use
Hawkular.
Now I think we also need a trimmed down package to download for those
users. Metrics+Alerts for now probably ? It could be named "Hawkular Core"
or "Hawkular Services", ideally "Hawkular Middleware Management Console ?
(JBMC upstream)" would build on this.
WDYT ?
Thomas
9 years, 1 month
how to configure Hawkular Kettle for SSL/HTTPS
by John Mazzitelli
Here are some basic instructions on how to get SSL configured and working in Hawkular Kettle. I still have to verify that everything works wrt inventory, but this should be what needs to get done to get SSL/https working. Note that the securityRealm agent attribute is a new attribute that will be added to the agent shortly - it is not available in the latest agent release.
You should run these commands from within kettle's standalone/configuration directory.
1) If you do not have a keystore with your own private key/certificate, you can generate a self-signed cert. We will assume this is for testing purposes only so this will be a valid certificate for your localhost only (see "CN=localhost" and the Subject Alternative Name of 127.0.0.1):
keytool -genkey -keystore hawkular.keystore -alias hawkular -dname "CN=localhost" -keyalg RSA -storepass hawkular -keypass hawkular -validity 36500 -ext san=ip:127.0.0.1
Again, make sure your new "hawkular.keystore" is in kettle's standalone/configuration directory.
2) If you did create your own self-signed certificate, you will need to tell your Java VM that it can trust it. You do this by adding your self-signed cert to the cacerts file.
2.a) First, export your certificate from your keystore file (hawkular.keystore if you followed instructions in step 1) into a file called hawkular.cert:
keytool -export -alias hawkular -file hawkular.cert -storepass hawkular -keystore hawkular.keystore
2.b) Now import your self-signed certificate into your Java's CA certificates file - this makes your certificate trusted by your Java apps:
keytool -import -keystore $JAVA_HOME/jre/lib/security/cacerts -alias hawkular -storepass changeit -file hawkular.cert
You can examine your certificate and answer the prompt to indicate you do trust that certificate. If you want to automate this, you can pass in the -noprompt command line argument and it will automatically add the certificate without asking you for confirmation.
3) Now that your keystore is generated and trusted, you have to tell Hawkular Kettle to use your keystore when using SSL. Add a security-realm first:
<management>
<security-realms>
<security-realm name="UndertowRealm">
<server-identities>
<ssl>
<keystore path="hawkular.keystore" relative-to="jboss.server.config.dir" keystore-password="hawkular" key-password="hawkular" alias="hawkular" />
</ssl>
</server-identities>
</security-realm>
4) Now add an HTTPS listener, using your new security-realm that is configured with your new keystore:
<server name="default-server">
<https-listener name="https" security-realm="UndertowRealm" socket-binding="https"/>
5) Turn on SSL in the agent by adding these two attributes to the <storage-adapter> element:
* useSSL="true"
* securityRealm="UndertowRealm"
9 years, 1 month
https and accounts/keycloak
by John Mazzitelli
I'm trying to figure out what does or does not work over HTTPS. So I configured kettle with my own self-signed keystore using these instructions:
http://blog.eisele.net/2015/01/ssl-with-wildfly-8-and-undertow.html
I can see the UI at https://localhost:8443 - I first had to tell Firefox to accept the certificate (so I know its really going over SSL). And the fact I can see the login screen tells me the SSL setup is OK and I'm able to access the UI over https. However, when I try to log in, I get an exception - and its a similar exception I get when the agent tries to call into kettle.
Has anyone tried accessing kettle over https and have you seen any keycloak issues when doing so? (nudge, nudge, juca :-)
Here's the exception I get when I try to log into the UI - I'm curious if there are other configuration settings we need to get HTTPS to work:
384109 [default task-21] ERROR io.undertow.request - UT005023: Exception handling request to /hawkular/accounts/personas/current
java.lang.RuntimeException: Unable to resolve realm public key remotely
at org.keycloak.adapters.AdapterDeploymentContext.resolveRealmKey(AdapterDeploymentContext.java:134)
at org.keycloak.adapters.AdapterDeploymentContext.resolveDeployment(AdapterDeploymentContext.java:83)
at org.keycloak.adapters.PreAuthActionsHandler.preflightCors(PreAuthActionsHandler.java:71)
at org.keycloak.adapters.PreAuthActionsHandler.handleRequest(PreAuthActionsHandler.java:47)
at org.keycloak.adapters.undertow.ServletPreAuthActionsHandler.handleRequest(ServletPreAuthActionsHandler.java:68)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.server.handlers.MetricsHandler.handleRequest(MetricsHandler.java:62)
at io.undertow.servlet.core.MetricsChainHandler.handleRequest(MetricsChainHandler.java:59)
at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:282)
at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:261)
at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:80)
at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:172)
at io.undertow.server.Connectors.executeRootHandler(Connectors.java:199)
at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:774)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
Caused by: javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
at sun.security.ssl.Alerts.getSSLException(Alerts.java:192)
at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1937)
at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:302)
at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:296)
at sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1478)
at sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:212)
at sun.security.ssl.Handshaker.processLoop(Handshaker.java:957)
at sun.security.ssl.Handshaker.process_record(Handshaker.java:892)
at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1050)
at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1363)
at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1391)
at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1375)
at org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:535)
at org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:403)
at org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(DefaultClientConnectionOperator.java:177)
at org.apache.http.impl.conn.AbstractPoolEntry.open(AbstractPoolEntry.java:144)
at org.apache.http.impl.conn.AbstractPooledConnAdapter.open(AbstractPooledConnAdapter.java:131)
at org.apache.http.impl.client.DefaultRequestDirector.tryConnect(DefaultRequestDirector.java:611)
at org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:446)
at org.apache.http.impl.client.AbstractHttpClient.doExecute(AbstractHttpClient.java:863)
at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82)
at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:106)
at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:57)
at org.keycloak.adapters.AdapterDeploymentContext.resolveRealmKey(AdapterDeploymentContext.java:105)
... 16 more
Caused by: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
at sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:387)
at sun.security.validator.PKIXValidator.engineValidate(PKIXValidator.java:292)
at sun.security.validator.Validator.validate(Validator.java:260)
at sun.security.ssl.X509TrustManagerImpl.validate(X509TrustManagerImpl.java:324)
at sun.security.ssl.X509TrustManagerImpl.checkTrusted(X509TrustManagerImpl.java:229)
at sun.security.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:124)
at sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1460)
... 35 more
Caused by: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
at sun.security.provider.certpath.SunCertPathBuilder.build(SunCertPathBuilder.java:145)
at sun.security.provider.certpath.SunCertPathBuilder.engineBuild(SunCertPathBuilder.java:131)
at java.security.cert.CertPathBuilder.build(CertPathBuilder.java:280)
at sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:382)
9 years, 1 month
