Hawkular BTM 0.8.0.Final
by Gary Brown
Hi all
I'm pleased to announce the availability of version 0.8.0.Final of the Hawkular BTM project. The release can be found here: https://github.com/hawkular/hawkular-btm/releases/tag/0.8.0.Final
The main focus for this release has been adding Distributed Tracing capabilities to the project, and general UI improvements:
* Distributed Tracing
- New UI tab to display aggregated end to end view of activities across a distributed application
- Supporting REST operations
* Numerous UI improvements, including
- Simplified Business Transaction overview page, including active and disabled business transactions
- Common filter sidebar used by Application Performance and Distributed Tracing pages
- Filtering on inclusion/exclusion of properties and/or faults
- Finer grained control over start/end date and time on Application Performance and Distributed Tracing pages
* Deriving end to end completion time
* Deriving latency information from interactions between services
* Instrumentation rules for
- RxJava
- Netty
* Many bug fixes.
I would like to thank the following people for their contributions to this release:
Alexandre Mendonça - thanks for all the cool UI work in this release
Gabriel Cardoso - thanks for providing feedback and support on the UI style
Andrew Dinn - thanks for continued (and very responsive) support with the use of Byteman
Juraci Paixão Kröhling - thanks for continued support with integration with Hawkular Accounts
Andrea Scarpino - thanks for identifying and helping to fix issues with the SQL driver instrumentation
Regards
Gary
9 years, 6 months
Running perf tests with 2 h-metrics instances on the same host - results
by Filip Brychta
Hello,
I finished quick testing of two h-metrics instances running on the same host both using the same external cassandra node.
Motivation for this was to find a bottleneck.
>From previous testing we know following:
- with additional h-metric instance the throughput was increased almost linearly
- question was why it's not possible to get higher throughput from single h-metrics instance while we know that cassandra node is not the bottleneck
Test:
1 - run perf tests against 1 h-metrics with 4GB memory using one external cassandra node
2 - run perf tests against 2 h-metrics with 2GB memory each (on the same VM as previous test) using one external cassandra node (again the same VM as previous test)
3 - compare results
Results:
- for small msgs (1 metrics per request) there was almost no difference -> CPU was fully utilized -> for small msgs the CPU is bottleneck
- for bigger msgs (100 metrics per request) total throughput was almost 2 times better -> it's possible to get 2 times better throughput from the same VM -> neither cpu, nor memory, nor network is the bottleneck -> h-metrics is doing some kind of throttling
- I tried 500 metrics per request as well but I was getting timout exceptions. Maybe it was too much for this VM.
Filip
9 years, 7 months
System requirement for hawkular server
by Austin Kuo
Hi all,
When I was trying to running the server on my VM (2G memory), it shows
```
…
java.lang.OutOfMemoryError
Java HotSpot(TM) 64-Bit Server VM warning: INFO:
os::commit_memory(0x00007f4d913cc000, 12288, 0) failed; error='Cannot
allocate memory' (errno=12)
```
Wondering how much memory & CPU is sufficient for it?
Thanks!
9 years, 7 months
How to gradually remove unfitting old REST APIs?
by Lukas Krejci
This stems from the mention of deprecating the REST API of inventory and
making the new API the default one, forcing the existing clients to change.
I think this is a generic problem with the "emergent design" of iterative
development - sometimes the stuff you come up with turns out to be wrong and
you need to toss it away. At the same time, we need to minimize the "damage"
we do to the existing clients.
Let me just copy the relevant parts from the other thread and answer them
inline:
> > In 0.17.0.Final we will introduce a new REST API and will deprecate the
> > current one (most probably by moving it to
> > /hawkular/inventory/deprecated).
>
> This way you break all existing clients !
>
I know... At the same time Inventory is still not stable, it's 0.x.y, and the
current REST API really is broken in some ways.
I'd rather encourage clients to move away from it than keep it forever.
> You may either move the new api to a new prefix
I want the new API to be the default when inventory goes stable.
> Or use content negotiation where the new api gets a content of e.g.
> application/hawkular-inventory+json;v2
Again, I don't want to keep the old stuff around when inventory goes stable.
So having the new stuff as a v2 doesn't really make sense when v1 is going
away and will not be available in the future.
> A request without that content type gets the old endpoints and
> semantics.
> A request with that content type in the request will access the
> new endpoints (which may be separate or overlay the old ones)
> with potentially new data formats.
>
> This way clients can upgrade as they want
Content negotiation or new root context for the new API is certainly the clean
solution here, I can't argue that. It requires no change on the clients that
want to keep using the old API.
But I really want to prod the clients to upgrade, because I don't intend to
maintain the old API moving forward. So the "solution" is to actually MOVE the
old API to a new context root "/deprecated" (and I don't say it is the ideal
one and I am open to be persuaded to use another).
This will have 2 consequences:
* if you want to keep using the old API, update your client to use the new
context root. This usually should be as simple as changing a constant in the
client with the new context root. After this change, the clients are free to
upgrade as they want.
* the new REST API remains "clean" - no need to specifically ask for it.
There are other options:
* When the old API is called, "compute" the new URI (if possible) and return
301. According to the spec, the clients should "relink" and use the new URI in
the future. The drawback here is that IMHO this is messy for the clients -
they don't have an idea WHY is this being done, nor are they explicitly told
about the new capabilities of the new API. Additionally, this can only work if
the old and new URIs are "mappable" and the actual content format doesn't
change.
* Add a Warning: 299 - "Deprecated. Consider upgrading to new API." header
(https://tools.ietf.org/html/rfc7234#section-5.5). If the clients look at the
response headers, this gives them the information about the deprecation. Con -
this might be missed by the clients.
--
Lukas Krejci
9 years, 7 months
the new hawkular services distro
by John Mazzitelli
I am playing with the new hawkular services distro to see if it can get me moving again with the "no more accounts, need to pass tenant header" stuff:
https://github.com/hawkular/hawkular-services/pull/1
Has anyone played with this? It appears there is no default user created so that means this isn't a fully working distro yet - at least you can't unzip, run, and expect things to work.
There doesn't exist a -Pdev profile that you can use to build a distro for demo and developer purposes (like our old kettle builds, -Pdev would give you a jdoe:password user to play with).
Am I missing something or is this just not fully cooked yet?
9 years, 7 months
Hawkular Inventory 0.16.0.Final Released
by Lukas Krejci
Hi all,
I'm happy to announce the release of Hawkular Inventory 0.16.0.Final.
The most important change in this release is the alignment of authorization
and tenant selection with the rest of the Hawkular components.
>From now on, Inventory no longer depends on Keycloak for authentication and
instead is using JAAS. Any authenticated user is allowed to do anything by
default.
The tenant is no longer deduced from the authenticated user but is selected
using the Hawkular-Tenant header (which is therefore required in every request
to inventory).
This moves inventory more into a role of a "backend service" which delegates
more granular authentication and authorization to the application layer above
inventory.
That said, the authorization logic has been factored out and made pluggable
and a mechanism to check per-entity CRUD privileges is still in place. We just
swapped the default implementation for a "permissive" one and changed the way
we figure out the tenant.
Apart from this big change, the following enhancements and fixes have been
included in the release:
* all internal properties, stored as "__foo" in the backend, are now available
for filtering as "foo".
* SwitchElementType filter has been "promoted" to the API so that it is usable
by the API clients.
* Hawkular Commons dependency has been updated to 0.7.2.Final
In 0.17.0.Final we will introduce a new REST API and will deprecate the
current one (most probably by moving it to /hawkular/inventory/deprecated).
This work is well underway but unfortunately didn't make it for 0.16.0.Final.
Huge thanks go out to Peter Palaga who did all the security related changes in
this release and Jirka Kremser who provided the generic mapping of internal
properties.
--
Lukas Krejci
9 years, 7 months
Building hawkular failed
by Austin Kuo
Hi guys,
I was trying to build the latest repo on master.
It complained that
```
[ERROR] import yargs from ‘yargs';
[ERROR] ^^^^^^
[ERROR]
[ERROR] SyntaxError: Unexpected reserved word
[ERROR] at exports.runInThisContext (vm.js:53:16)
[ERROR] at Module._compile (module.js:414:25)
[ERROR] at Object.Module._extensions..js (module.js:442:10)
[ERROR] at Module.load (module.js:356:32)
[ERROR] at Function.Module._load (module.js:311:12)
[ERROR] at Module.require (module.js:366:17)
[ERROR] at require (module.js:385:17)
[ERROR] at Liftoff.handleArguments
(/Users/akuo/Developer/hawkular/hawkular/console/target/gulp-build/node_modules/gulp/bin/gulp.js:116:3)
[ERROR] at Liftoff.<anonymous>
(/Users/akuo/Developer/hawkular/hawkular/console/target/gulp-build/node_modules/gulp/node_modules/liftoff/index.js:192:16)
[ERROR] at module.exports
(/Users/akuo/Developer/hawkular/hawkular/console/target/gulp-build/node_modules/gulp/node_modules/liftoff/node_modules/flagged-respawn/index.js:17:3)
```
…
[ERROR] Failed to execute goal
com.github.eirslett:frontend-maven-plugin:0.0.26:gulp (gulp build) on
project hawkular-console: Failed to run task: ‘gulp.js build --production
--no-color' failed. (error code 1) -> [Help 1]
Anyone knows how to fix this?
Thanks
9 years, 7 months
Do we still need the nest? Or: do we still need Wildfly Patching?
by Juraci Paixão Kröhling
Bringing a discussion from IRC to the mailing list: do we still need the
Nest? It seems that the only reason we need the Nest at this point is
that it provides Wildfly Patching support.
Considering that we'll ship an appliance and RPMs, do we still have the
requirement of supporting Wildfly Patching?
- Juca.
9 years, 7 months
