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)
6 years, 10 months
versioning schema
by Jiri Kremser
Hello,
I'd like to ask about the policy we want to use for the versioning schema. I've raised a PR [1] that will check the project version and fails the build if it's wrong. This should catch the releases with malformed versions. It's aligned with the JBoss project versioning [2], however, it's not clear how to use the "-SNAPSHOT" suffix. Peter has a good point in the PR comment that some use the x.y.z.Final-SNAPSHOT (final can be also AlphaN, BetaN and CRN) and some x.y.z-SNAPSHOT and when releasing, we add the Final/Alpha, etc.
Looking into wildfly repo, they use the former method. Is this what we want? I personally consider the latter method more natural and we use it in the inventory, despite the fact the hawkular/hawkular uses the x.y.z.AlphaN-SNAPSHOT.
jk
[1]: https://github.com/hawkular/hawkular-parent-pom/pull/54
[2]: https://developer.jboss.org/wiki/JBossProjectVersioning
6 years, 11 months
Hawkular Metrics 0.6.0 - Release & Beyond
by Stefan Negrea
Hello Everybody,
I am happy to announce release 0.6.0 of Hawkular Metrics. The release is anchored by enhancements for counter metrics, updates to the container infrastructure, and overall performance and stability enhancements.
Here is a list of major changes in this release:
1) Querying
* Metrics can now be searched with regexp filtering capabilities on tags
* Metrics queries now support logical AND for tags
2) Internal
* TenantId and type were moved to the MetricId instead of Metric class
* Implicit tenants (not manaully created prior to sending first set of metric data) are now created on metrics insertion
3) Container
* Updated to the latest Heapster version (0.17)
* The communication between the Hawkular Metrics and Cassandra containers have now been secured. This means that only Hawkular Metrics can communicate with its Cassandra containers.
4) Counters
* Per-minute rates can be retrieved via the /hawkular/metrics/counters/{id}/rate endpoint.
5) Task scheduling
* The scheduler API and schema has undergone several changes. It is now possible to group related tasks so that order of execution can be controlled when there are interdependencies. There is still ongoing work to support asynchronous job execution and to provide fault tolerance.
6) Ruby Client
* The project has now an official Ruby client, this joins the existing Go and Python clients. One of Hawkular Metrics' objectives is to be easy to integrate with; providing language specific clients is an important component for fulfilling this objective.
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
Github Release:
https://github.com/hawkular/hawkular-metrics/releases/tag/0.6.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/12327689/
Hawkular Metrics 0.7.0 & Beyond
1) Gauge Aggregates - The task scheduling work is now in place to enable server side aggregates at ingestion. The expectation is to release an initial implementation for this feature in 0.7.0.
2) Improved docker and kubernetes support - this is a long term goal for the project
3) Support for counters in Python & Golang clients
A big "Thank you" goes to John Sanda, Thomas Segismont, Mike Thompson, Matt Wringe, Michael Burman, Libor Zoubek, Jirka Kremser, and Heiko Rupp for their project contributions.
Thank you,
Stefan Negrea
Software Engineer
7 years
Hawkular performance reports are now available in perfrepo
by Filip Brychta
Hello,
you can now see results of perf tests like:
- Response time - min/max/avg
- Throughput min/max/avg
- Disk usage
- count of datapoints
for different parameters like:
- # of threads used for load generator
- # of datapoints in each request
- metric type
in perfrepo [1].
You should be able to add more charts and edit existing ones to see any combination you like.
Charts are interactive and you can display certain test execution by clicking on chart series.
Each test execution has number in name which match build number of jenkins job [2] where you can find artifacts like server.log, garbage collection log, iostat log for each run. (Those artifacts will be stored in perfrepo as well in a future)
Email me or vprusa to get credentials.
Please note that this is just our internal testing instance of perfrepo. Plan is to move to official redhat perfrepo instance as soon as the setup is tuned. Many annoying perfrepo bugs will be fixed there.
Please let me know what combinations and parameters you would like to see.
[1] - http://perfrepo.bc.jonqe.lab.eng.bos.redhat.com:8080/reports/metric/5
[2] - http://jenkins.jonqe.lab.eng.bos.redhat.com:9080/job/haw-perf-stability-w...
Filip
7 years
Hawkular metrics - generating load from more generators - results
by Filip Brychta
Hello,
as discussed on last haw perf meeting I tried to generate load from more generators.
Motivation for this was to find out If it's possible to max out hw resources on tested machine (PowerEdge R630, 16 cores) when generation heavy load from more load generators.
Quick answer is NO. Even though the load was generated from 5 machines from 1500 threads in total, CPU usage was never higher than 50% and maximal disk write speed was 15MB/sec.
Maximum throughput was ~19000 requests/sec when using ~ 900 threads. When adding more threads the throughput and cpu usage went actually down.
When bypassing cassandra calls in hawkular metrics and returning 200 response directly (see https://github.com/hawkular/hawkular-metrics/pull/411), single generator from 300 thread was able to generate load 45000 requests/sec.
All this means that the problem is really not on load generator side not being able to generate sufficient load. Hawkular is not able to max out resources on that machine in current configuration no matter how many threads are used for load generation.
Important note about perfcake (load generator we are using) is that it's not trying to break the server. For each thread it's sending new request only if previous request was done (response returned). So this means it's reporting maximum throughput which is hawkular metrics able to serve for given number of threads.
Results:
1 datapoint per request:
600 threads -> throughput ~18100 requests/sec
900 threads -> throughput ~19000 requests/sec
1200 threads -> throughput ~10300 requests/sec
1500 threads -> throughput ~ 10000 requests/sec
10 datapoint per request:
300 threads -> throughput ~5000 requests/sec
600 threads -> throughput ~3500 requests/sec
900 threads -> throughput ~3100 requests/sec
1200 threads -> throughput ~3100 requests/sec
1500 threads -> throughput ~ 3100 requests/sec
For all cases garbage collection was happening in regular periods ~3s. ( WF is running with -Xms64m -Xmx512m -XX:MaxPermSize=256m)
I tried a few runs with increased memory -Xms2048m -Xmx2048m -XX:MaxPermSize=256m:
1 datapoint per request:
900 threads -> throughput ~ 19800 requests/sec
1500 threads -> throughput ~ 19800 requests/sec
So for bigger number of threads the increased memory helped a lot. For 900 threads it helped a little. Throughput was stabilized before fist garbage collection occurred so it seems another increase of memory doesn't make sense.
See attached txt for more detailed results.
Filip
7 years
Datamining integration with Alerts
by Pavol Loffay
Hello,
I would like to integrate Datamining module with Alerts.
For alert prediction users should configure globally/on MetricType/Metric
prediction interval for how long ahead they want to be notified. For
example notify my if in two hours alert conditions are met (based on
prediction).
For start we could reuse defined conditions and evaluate them not only for
incoming data from Metrics(value at time t) but also from Datamining module
(predicted value at time t+prediction interval). If defined conditions are
met it will use the same actions(email, sms) as are defined for real
Metrics with changed description text(this is prediction). This would
require minimal configuration for users (only prediction interval, when
zero no predictions). What do you think?
Alert module would have cloned triggers+conditions for metrics being
predicted with some changed properties like dataId(match condition to
metric) and context information about metrics.
Datamining module would send predicted metrics(with changed id) to the same
topic as Metrics module does. With this approach there are no changes
required in Alert module.
Any comments or suggestions are welcome.
Console or other modules can still ask for predictions for any time in the
future. Datamining module does predictions on demand.
Regards,
Pavol
7 years
oshi and MacOS
by John Mazzitelli
Heiko - I think I remember you reporting this (but I can't remember where or when). See: https://issues.jboss.org/browse/HAWKULAR-838
This is because on MacOS the OSHI library uses the Swing file chooser dialog widget to obtain file system data.
Since MacOS is not an officially supported platform, do we want to do what this JIRA asks? That is, change kettle's startup options? This would also mean we'd have to somehow get the agent installer to also change WF/EAP startup options (not something I think we want to do - especially since this only affects MacOS).
We could add this to the agent install documentation for those on MacOS.
The other alternative is to disable file system data collection in the agent, assuming the user doesn't care about those metrics.
7 years
Proposal: ban srcdeps from releases
by Peter Palaga
Hi *,
this is yet another proposal from the series of changes that should make
the life easier for productization engineers and sustaining engineers.
While srcdeps [1] are showing themselves at their best while tinkering
across components, it is not 100% legal to depend on srcdeps artifacts
in releases.
Why:
(1) Releases are deployed to public Maven repositories where they are
made accessible to tools (IDEs, dependency/compatibility analyzers, ...)
that do not know how to handle srcdeps. For them, srcdeps are simply
unsatisfied dependencies and our artifacts depending on them appear as
disobedient to the common rules holding in public maven repositories.
(2) The productization tool chain can actually count to such tools too.
They are programmatically very strict about what is there in the
dependency hierarchy and I quite doubt that they are ready to adapt to
srcdeps.
The proposed solution:
With the next release, the srcdeps-maven-plugin will offer the option
[2] to fail with certain (configurable) profiles. The default being just
the "release" profile. This would reach Hawkular components with the
next release 27 of hawkular-parent. (Note that parent 26 is out,
although it still has not reached all Hawkular components.)
[1]
http://ppalaga.github.io/presentations/150929-srcdeps-maven-plugin/150929...
[2] https://github.com/l2x6/srcdeps-maven-plugin/pull/31
Best,
Peter
7 years
