Getting started with Docker
by Anton Hughes
Hi guys
Im following the quick-start guide using Docker guide on your website.
It says if I go to localhost:8080 then I should get the login screen.
However, I get the standard WF9 screen, without any login page.
Should I delete the docker image and try again? Or is the remote docker
image out of date?
thanks,
Anton
[image: Inline image 1]
8 years, 10 months
Release schedule
by Juraci Paixão Kröhling
Team,
Based on the discussed that followed the last release, here's the
adjusted scheduled based on the next release. Although those are only
*suggestions*, I'll be following that for Accounts.
- Thursday before the release: Parent, Commons and Accounts
- Friday before the release: Inventory, Metrics, BTM
- Monday before the release: Command Gateway, Agent, Alerts
- Tuesday (release day): Hawkular
Once Accounts is released, I'll be submitting a PR for the downstream
components.
- Juca.
8 years, 10 months
Hawkular Alerts 0.6.0.Final Released!
by Jay Shaughnessy
Hawkular Alerts 0.6.0.Final has been Released!
* Event Support
This major new feature incorporates Events into Hawkular Alerts. Events:
* Are more lightweight than Alerts
* Record things of interest
* Can be injected via an API call
* Can be generated via a Trigger
* Can have actions performed on them (for Trigger-generated Events)
* Can be used as Trigger conditions
For more on Events there is some general information here (more to come):
http://www.hawkular.org/docs/dev/alerts.html
And Lucas provides some great examples here:
https://github.com/lucasponce/hawkular-examples/tree/master/events
* WebHooks Action Plugin
Hawkular Alerts 0.6.0.Final introduces a new Action plugin for WebHook
notifications.
There have been some changes to the REST endpoints as we refine the model.
Of course there are fixes and minor enhancements as well. A Jira
Summary for the release is here:
* https://issues.jboss.org/secure/ReleaseNote.jspa?projectId=12315924&versi...
The next scheduled release is 0.7.0, targeted for December 9, 2015.
Hawkular Alerts Team
Jay Shaughnessy (jshaughn(a)redhat.com)
Lucas Ponce (lponce(a)redhat.com)
8 years, 10 months
Gulp version 3.9.0+ required for Hawkular UI Dev builds
by mike thompson
NOTE: this is only relevant if you are doing Hawkular UI development. This process is transparent to the normal build process.
In an effort to ‘ES6 All the things!” All of the Hawkular UI repos have been updated to use Gulp 3.9.0+ which allows gulp to use ES6 in its gulpfile (via Babel ES6 translator). This means that gulpfile.js filename has changed to gulpfile.babel.js and is written in ES6. All of the previous gulp commands work the same as they always have.
To determine what version of gulp is installed:
gulp —version
If the version returned is less than 3.9.0 then you need update the version. To update the version:
sudo npm update -g gulp
or
sudo npm install -g gulp
8 years, 10 months
First round of perf tests with more cassandra nodes - results
by Filip Brychta
Hello,
I did first quick perf testing of haw metrics STANDALONE with more cassandra nodes and it showed some interesting results.
Important note is that hawkular and cassandra cluster were running on VMs with shared storage. Which is very poor design for cassandra cluster but it still showed some patterns which will be true for every setup.
Witch proper cassandra cluster (dedicated disks, CommitLog and SSTables on different disks, ...) the results should be definitely better.
Summary of what was found (something is obvious even without testing):
- small messages (1 datapoint per request) utilize heavily cpu on hawkular host and cassandra hosts are utilized gently
- bigger messages (100 datapoints per request) are less demanding on hawkular host's cpu, cassandra hosts are utilized little bit more
- with week cpu on hawkular host, adding more cassandra nodes makes performance even worst
- for small messages (1 datapoint per request) even with sufficient cpu on hawkular host the performance improvement was only ~ 25% when number of nodes in the cluster was increased from 1 to 2
- for bigger messages (100 datapoints per request) with sufficient cpu on hawkular host the performance improvement was ~ 75% when number of nodes in the cluster was increased from 1 to 2
- for small messages (1 datapoint per request) even with sufficient cpu on hawkular host the performance does NOT scale up with more cassandra nodes (see results - performance dropped when 4th node was added)
- for bigger messages (100 datapoints per request) with sufficient cpu on hawkular host the performance scales up but not linearly (this could be caused by shared storage and with proper cassandra cluster the results will be better)
Questions:
- why is the performance getting worst when adding 3th and 4th storage nodes when sending small messages and having sufficient cpu on hawkular host?
About the test:
- load generator was hitting following endpoint http://${server.host}:${server.port}/hawkular/metrics/gauges/data
- one test run takes 4 minutes
- message with one datapoint looks like this [{"id":"gaugeID","data":[{"timestamp": "@{CurrentTimestamp}", "value": 10.12}]}]
- load generator was using 300 threads (each thread is acting like single client) and was sending messages containing 1 or 100 datapoints
- hawkular metrics is deployed on wildfly-9.0.2.Final
- metrics version: "Implementation-Version":"0.12.0-SNAPSHOT","Built-From-Git-SHA1":"c35deda5d6d03429e97f1ed4a6e4ef12cf7f3a00"
Results:
===================================================
VMs with 2 cores and shared storage, 4GB of memory.
===================================================
300 threads, 1 datapoint, hawkular_metrics | org.apache.cassandra.locator.SimpleStrategy | {"replication_factor":"1"
++++++++++++++++++++++++++++++++
1 cassandra node ~ 3945 req/sec
2 cassandra nodes ~ 3751 req/sec
3 cassandra nodes ~ 3318 req/sec
4 cassandra nodes ~ 2726 req/sec
In this case the cpu on hawkular VM was fully used and adding more cassandra nodes actually made performance worst.
Cpu on cassandra nodes was never fully used
300 threads, 100 datapoint, hawkular_metrics | org.apache.cassandra.locator.SimpleStrategy | {"replication_factor":"1"
++++++++++++++++++++++++++++++++
1 cassandra nodes ~ 102 req/sec
2 cassandra nodes ~ 138 req/sec
3 cassandra nodes ~ 188 req/sec
4 cassandra nodes ~ 175 req/sec
With week cpu on hawkular VM and big messages (100 datapoints in each) there is still some improvement when adding more cassandra nodes.
Cpu on cassandra nodes was never fully used
===================================================
Hawkular VM with 4 cores, cassandra VMs 2 cores and shared storage,4GB of memory.
===================================================
300 threads, 1 datapoint, hawkular_metrics | org.apache.cassandra.locator.SimpleStrategy | {"replication_factor":"1"
++++++++++++++++++++++++++++++++
1 cassandra node ~ 5150 req/sec
2 cassandra nodes ~ 5667 req/sec
3 cassandra nodes ~ 5799 req/sec
4 cassandra nodes ~ 5476 req/sec
With stronger cpu on hawkular VM adding more cassandra nodes improves performance but there is a drop when 4th node is added.
Cpu on cassandra nodes was never fully used
300 threads, 100 datapoint, hawkular_metrics | org.apache.cassandra.locator.SimpleStrategy | {"replication_factor":"1"
++++++++++++++++++++++++++++++++
1 cassandra nodes ~ 111 req/sec
2 cassandra nodes ~ 173 req/sec
3 cassandra nodes ~ 206 req/sec
4 cassandra nodes ~ 211 req/sec
With stronger cpu on hawkular VM adding more cassandra nodes improves performance.
Cpu on cassandra nodes was never fully used
===================================================
Hawkular VM with 8 cores, cassandra VMs 2 cores and shared storage,4GB of memory. Cpu on hawkular machine is used 30-40%
===================================================
300 threads, 1 datapoint, hawkular_metrics | org.apache.cassandra.locator.SimpleStrategy | {"replication_factor":"1"
++++++++++++++++++++++++++++++++
1 cassandra node ~ 5424 req/sec
2 cassandra nodes ~ 6810 req/sec
3 cassandra nodes ~ 6576 req/sec
4 cassandra nodes ~ 6094 req/sec
Why there is a drop for 3th and 4th node?
300 threads, 100 datapoint, hawkular_metrics | org.apache.cassandra.locator.SimpleStrategy | {"replication_factor":"1"
++++++++++++++++++++++++++++++++
1 cassandra nodes ~ 97 req/sec
2 cassandra nodes ~ 168 req/sec
3 cassandra nodes ~ 222 req/sec
4 cassandra nodes ~ 241 req/sec
Please let me know what you would like to see in next rounds of testing.
Filip
8 years, 10 months
where should integration/glue code and tests live?
by John Sanda
I am currently working on accounts integration in metrics. The integration code lives in the hawkular-component module in the metrics repo. Now I want to write some integration tests to verify that things work as expected. I don’t really think that integration/glue code belongs in the component repo. I want to make sure that wherever it lives I can still get feed back from CI builds when changes are made. When I make a change to component code in the metrics repo, the CI build runs and checks for regressions by running tests. There is a pretty quick feedback loop which is very important. If the glue code is living elsewhere, I would like for a a CI build to get kicked off at some point after the metrics CI builds completes successfully so that I can find out if any of my changes to the component code caused a regression in the glue code. And of course if I make a change directly in the glue code, I should get the feedback from the check-in CI job. In RHQ we had a build pipeline with jenkins that handled this for us. Is this possible with travis?
For now I am putting the glue code and tests in the metrics repo so that I can have the CI feedback loop, but I see this as a short term solution. It may work fine in this instance, but what about when I want to test some other integration? I will be pulling in more hawkular dependencies and eventually hit circular dependencies. And the quick feedback that I get from the component CI build will get a lot slower in the process.
- John
8 years, 10 months
Cassandra upgrade
by John Sanda
We are currently running Cassandra 2.2.2. I believe that 3.1.1 is the latest version, and it was released on December 21. There are some pretty significant changes in 3.x. From a development standpoint, I think it absolutely makes sense to upgrade. I would like to know what others think (Heiko in particular). There are other considerations like productization build changes and OpenShift integration. There would be a data migration involved with OpenShift since we already shipped Cassandra 2.x. When upgrading across major versions, you are supposed to run the sstableupgrade utility on each table. We would need to do this for OpenShift. Whether or not we choose to upgrade now, we will need to deal with this migration step in OpenShift at some point.
- John
8 years, 10 months
how to use the installer from command line
by John Mazzitelli
I'm just sending this to document it for myself :) but this could be useful to others...
This is a quick way you can download the agent installer and install it in a WildFly server instance from a console:
1) Download the installer from a running Hawkular instance, using curl's --user option to pass in the Hawkular credentials:
curl --user jdoe:password --data 'managed-server-name=YourManagedServerName&username=jdoe&password=password' --remote-name --remote-header-name --url http://localhost:8080/hawkular/wildfly-agent/installer
This connects to the Hawkular Server with the --user credentials and downloads a pre-configured installer and stores it under the file name "hawkular-wildfly-agent-installer.jar" (that's what --remote-name and --remote-header-name magically does). When you run the installer, it will install an agent that will connect to Hawkular using jdoe/password credentials as specified by username=X&password=X (those credentials are stored inside the installer; there is a way to ask the installer to encrypt those credentials so it isn't stored in plain text, but I won't get into that here). It will use the name "YourManagedServerName" when identifying WildFly resources that it stores in inventory (see managed-server-name=)
To run the installer, get the absolute directory name of your installed WildFly server where you want the agent installed (for example: /opt/wildfly) and pass that in as a command line option to the installer like this:
java -jar hawkular-wildfly-agent-installer.jar --target-location=/opt/wildfly
That's it. Your agent is installed. Next time you run that WildFly instance, the agent should run, connect to Hawkular Server, and begin monitoring and reporting inventory.
There is more that can be done. I won't get into details here but you can download the installer with that target-location already preconfigured (if your agents are all stored in the same location like /opt/wildfly, it might be easier to just preconfigure the installer to always use that and not have to pass it in each time when executing the installer). You can encrypt the passwords so they are stored in the installer in an encrypted form. You can use hawkular-account tokens rather than username/passwords for the agent (so the agent can connect to hawkular server using a token and not a user/pass). You can have the agent disabled by default when installed in case you don't want it running yet. You can define SSL credentials if you want the agent to talk to hawkular server over SSL/https. The installer can be configured in all these ways either when you download or even afterwards (you can pass in your own installer configuration file so customize it however you want).
8 years, 10 months
agent can now report when the server needs to be reloaded/restarted
by John Mazzitelli
I released a new command-gateway and wildfly-agent today. The agent can now report when a WildFly server needs to be restarted or reloaded in order to pick up changes. There is a server-state resource config property on the WildFly server resource, and when the UI sends a websocket request to do something, it will get back a server-refresh-indicator in the websocket response if a restart or reload is required.
8 years, 10 months
Hawkular Metrics 0.11.0 - Release
by Stefan Negrea
Hello Everybody,
I am happy to announce release 0.11.0 of Hawkular Metrics. This is a large release anchored by query API enhancements, large under-the-cover refactoring of the metric models, and support for deploying the project on Wildfly 10.
Here is a list of major changes in this release:
1) Query API Updates
* Limit and Sort Order for raw data queries (HWKMETRICS-334, HWKMETRICS-62, HWKMETRICS-51)
- limit and order parameters are now available for raw data queries on all metric types
- limit - integer representing the maximum number of raw data points to be returned
- order - either ASC or DESC and based on the timestamp of the data point
- if both are specified than limit is applied from the start of the sorted list
- for defaults and additional details please visit:
https://github.com/hawkular/hawkular-metrics/blob/release/0.11.0/api/metr...
* Ability to query all metric raw or aggregate metric data (HWKMETRICS-331)
- fromEarliest query parameter was added to allow querying for all available data for a metric
- this allows querying all data without specifying start and end
- data retention for the metric is taken account, so the max time span is from `now` to `now - data retention`
* Fixed the url for querying rate data across multiple metrics (HWKMETRICS-332)
* Filtering metrics by id (HWKMETRICS-234)
- with tag filtering enabled, it is now possible add id filtering via id parameter
- id parameter supports regex
2) Internal Updates
* Model refactoring (HWKMETRICS-326, HWKMETRICS-323)
- this was a large effort to consolidate the internal domain model without changing any of the user APIs
- this change will help the documentation efforts for future releases as well as a consistent data structure for the REST APIs
3) Hawkular Integration
* The integration with Hawkular has now been updated to use asynchronous messages (HWKMETRICS-337)
4) Wildfly 10 - Deploying & Running
* Deploying and running the project on Wildfly 10 is now fully supported
* IMPORTANT - Support for Wildfly 9 is deprecated and will be completely dropped in the next release
Github Release:
https://github.com/hawkular/hawkular-metrics/releases/tag/0.11.0
JBoss Nexus Maven artifacts:
http://origin-repository.jboss.org/nexus/content/repositories/public/org/...
Jira release tracker:
https://issues.jboss.org/browse/HWKMETRICS/fixforversion/12328918
Hawkular Metrics Clients
* Ruby: https://github.com/hawkular/hawkular-client-ruby
* Python: https://github.com/hawkular/hawkular-client-python
* Go: https://github.com/hawkular/hawkular-client-go
A big "Thank you" goes to John Sanda, Thomas Segismont, Mike Thompson, Matt Wringe, Michael Burman, Libor Zoubek, and Heiko Rupp for their project contributions.
Thank you,
Stefan Negrea
Software Engineer
8 years, 10 months
