hawkular services with embedded c profile - need PR reviewed/merged
by John Mazzitelli
I just submitted a new PR for hawkular services:
https://github.com/hawkular/hawkular-services/pull/22
This re-introduces the ability to build Hawkular Services with embedded Cassandra if you want.
This will ONLY embed Cassandra IF you build with the special Maven profile -Pembeddedc.
If you never build with that profile, Hawkular Services will build as it does now (that is, requires you to install and start your own Cassandra separately).
So this will allow developers to continue doing what they've been doing (that is, no need to run a standalone C*) if they want.
Again, the default build is NOT to embed Cassandra. You must explicitly tell Maven you want to embed C* via -Pembeddedc to get this feature.
7 years, 10 months
Hawkular Community - Distribution
by Stefan Negrea
Hello Everybody,
I want to give an update on the Hawkular Community distribution since
Hawkular Services is now on a good track.
The Hawkular Community distribution will be built on top of the Hawkular
Services with two additions: Embedded Cassandra and Hawkular UI. The
Embedded Cassandra was removed from the Hawkular Services but will make its
way into the community distribution. The Hawkular UI will be the original
web interface from previous Hawkular bundle but updated to work with
Hawkular Services.
In the short term, the Hawkular Community distributions will be just a
rebundling of Hawkular Services with the Embedded Cassandra. The repository
for this effort is: https://github.com/hawkular/hawkular-community
The Hawkular UI updates are now in the planning stages and I will provide
an update as soon as the timeline becomes more clear. The code has been
relocated this new repository: https://github.com/hawkular/hawkular-ui
Lastly, I renamed old hawkular/hawkular repository
hawkular/hawkular-dist-old, marked it as archived, and removed access to
it. The new url: https://github.com/hawkular/hawkular-dist-old . My initial
reaction was to update hawkular/hawkular for the new community
distribution. But after looking at the commit and pull request history it
did not make sense to continue using that repository. Also, it would have
been really confusing to keep the repository with the old name knowing it
will probably be never be updated again, if somebody takes a look at the
org and spots that repository it may wonder if the community is still
active.
A note about the hawkular/hawkular rename, Github has automatic redirects
for renamed repositories. If somebody navigates to the old url, they will
be redirected to the new name. So as long we do not have another
hawkular/hawkular, the old url will keep working (which is is a good idea
given existing links and forks). But we should never ever name anything
again hawkular/hawkular because it is a very misleading name.
Thank you,
Stefan Negrea
7 years, 10 months
Hawkular Services 0.0.3.Final
by Juraci Paixão Kröhling
Team,
Hawkular Services 0.0.3.Final has just been released.
This version includes Agent 0.19.0.Final and features the removal of the
embedded Cassandra. You'll need a local installation of Cassandra
running before you start the server.
The distribution can be downloaded here:
https://repository.jboss.org/nexus/service/local/repositories/releases/co...
As the previous distributions, the Agent has to be configured with an
user. This can be accomplished by:
- Adding an user via bin/add-user.sh like:
./bin/add-user.sh \
-a \
-u <theusername> \
-p <thepassword> \
-g read-write,read-only
- Changing the Agent's credential on standalone.xml to the credentials
from the previous step or by passing hawkular.rest.user /
hawkular.rest.password as system properties (-Dhawkular.rest.user=jdoe)
Known issue:
https://issues.jboss.org/browse/HWKINVENT-186
- Juca.
7 years, 10 months
Performance testing (and PR #519)
by Michael Burman
Hi,
So the discussion on #hawkular pointed out that our current metrics performance testing is seeing a regression in the performance, after the merging of PR #519. I found this odd as I had done a lot of testing for this feature, including multiple runs of JMH (OpenJDK's Java benchmarking tool) and using a profiler to witness reduced CPU usage as well as reduced GC activity. The issue surrounds over RxJava's concatWith vs. mergeWith. Now, concatWith creates internal Queues and other stuff to keep track of the stuff, whereas mergeWith does not.
So, Filip's tools say mergeWith is slower, my intuition/profiler and benchmarking says otherwise. Odd situation, but there's a small difference in testing methologies here. I've done testing against hawkular-core-service (that is, only the internal handling), while Filip uses the whole Wildfly in his testing. Although the performance degredation is quite severe with JAX-RS involved, it shouldn't cause different end results.
The test results for my runs with JMH are here (with first the end results and then individual runs and statistics).
https://gist.github.com/burmanm/e3b1ab0e67bcae189072718d39b66b6c
The test that is run here is:
https://github.com/hawkular/hawkular-metrics/blob/master/integration-test...
Which mimics the behavior in which multiple concurrent senders are sending 1 metric in each call. With our backend, there's not a huge difference if we send everything in one request or single requests (this is more JAX-RS issue). The tests are using both 1 datapoint per 1 metric and 10 datapoints per 1 metric. The performance is returned as inserted metrics per second (so multiply by 10 the second result -> 9012 metrics / second -> 90120 datapoints / second).
Let the flaming begin.. or something ;)
Other notes:
There are other important optimization strategies involved with the 1 metric 1 datapoint scenario. First one is changing the behavior of indexUpdates. Removing unnecessary index updates doubles the performance from 13k metrics to 26k metrics per second. Second optimization strategy with single Cassandra node deployments is to force datapoint writing to use batch statements (with different partitions - which isn't normally recommended), that increases the performance from the 26k to >60k. I'm trying to find better solution for the latter case, but haven't so far found one.
- Micke
7 years, 10 months
Hawkular Commons 0.7.3.Final released
by Juraci Paixão Kröhling
Team,
Hawkular Commons 0.7.3.Final was just released. This release includes
the JAX-RS filter for requiring Hawkular-Tenant, as well as the
annotation `@TenantRequired`, where you can mark a specific class or
method as required or not required.
PRs to Alerts and Inventory will follow shortly. I also expect to be
able to send a PR to Metrics soon.
- Juca.
7 years, 10 months
Prepare for Hawkular Services 0.0.3.Final
by Juraci Paixão Kröhling
Team,
We'll have a release of Hawkular Services tomorrow, for version
0.0.3.Final.
This release will include the removal of embedded Cassandra. There
should not be anything required for individual components, but it would
be good if you'd test the current Hawkular Services master to see if
your component is working as expected.
If there are version changes required, send a PR by EOD today.
- Juca.
7 years, 10 months
services build has a problem
by John Mazzitelli
This recently changed and doesn't work like it did before. I can't figure out what's wrong.
The -Pdev build isn't working correctly (and neither is the non-dev build).
When you build without -Pdev, the agent should be disabled by default. But it is not, and you will get agent errors on startup.
When you build with -Pdev, the agent should be enabled and with the hawkualr.rest.user/password properties set inside standalone.xml. But they are not, and you again get agent startup errors.
This used to work a few days ago.
The .xsl that used to tweak the standalone.xml doesn't seem to be doing what it was supposed to do. Look here:
https://github.com/hawkular/hawkular-services/blob/master/feature-pack/sr...
See where it sets the system properties to control the agent enabled flag and the credentials? This isn't doing anyting that I can see because the distro doesn't have any system proeprties in standalone.xml, but this used to work. We'd get those <system-properties> elements in standalone.xml.
I can't figure out what changed. Hoping someone knows the deal and can put this back.
7 years, 10 months
Some progress on Dockerization of Hawkular-services
by Heiko W.Rupp
Hey,
I was able to make some progress with Dockerizing Hawkular-services
More technical details below
As it is relatively hard (not impossible) to do stuff like adding a user
inside a (immutable) docker container or to edit standalone.xml to
enable the agent, we need to decide how we add the (default) user
to hawkular docker container and also if/how to enable the embedded
agent.
Also as we more understand hawkular-services as one package,
we should perhaps figure out if we really need the flexibility to
modify standalone.xml on the fly with all our snippets and templates
or if we create a 'hardcoded' one that can be used for the process
going forward.
At the moment wildfly10 is our base and will be for a longer period,
so the server-supplied standalone.xml will not change anyway.
Anyway my Poc is at
https://github.com/pilhuhn/hawkular-services/tree/dockerize-all-the-things
There are 3 routes that I went (basically refining the process)
(If you want to run any you first need to
$ mkdir -p /tmp/opt/hawkular
as this is where the docker run commands expect the data for now
To get a 'working server' you need to "mvn install -Pdev first"
1) dist/ creating a Dockerfile by hand and manually running docker build
Dockerfile
and then docker-compose to run a container from this image linked to a
C* 3.5 one.
Base image is the jboss/base-jdk:8 one and the Dockerfile basically
overlays the
whole hawkular-services distribution on top
You can run this with $ docker-compose up
2) docker-dist/ here maven creates the Dockerfile on the fly and feeds
it to Docker.
This uses the fabric8.io docker plugin from Roland Huss.
Again it uses the same base image + overlay as 1). The container tag is
derived from the
maven properties.
To build and run you can go into the directory and then
$ mvn docker:build
$ mvn docker:start
3) docker-dist2/ Similar to 2) this uses the mvn docker plugin, but this
time is uses
jboss/wildfly:10.0.0.Final as the base image. Unfortunately it still
overlays the whole
wildfly from us, but we should be able to filter that out.
The good thing is though that the image is already much smaller as in 2)
To build and run the same process as 2) applies
*
The next step is now to figure out how to only apply our changes and not
to
supply the base wildfly into the conatiner. I certainly need help from
someone
with maven-fu :)
But while the current state is not optimal it shows that this is very
much doable
and we should proceed.
Heiko
7 years, 10 months
