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, 4 months
Resourcetype again
by Heiko W.Rupp
Hey,
we have said that we do no longer want the very strict resource types
that
we had in RHQ. We also identified that we need resource types to define
capabilities like metric types with their units etc. The newest addition
now
are operations and resource config.
I believe that for a certain kind of resource - e.g. "WildFly 8.2", that
"we" manage
we should not have the agent/feed supply the types, but Hawkular should
do so.
A user may still decide to extend that to supply its own data, but we
need to be
careful when dealing with it.
For security relevant things we can not let the client/feed just provide
resource
type data, as otherwise it is too easy to work around checks.
For WildFly there are a bunch of RBAC roles [1,2] that need to map to
what
we (will) have in Hawkular, which we may define as just what WildFly
has.
In fact that will be beneficial, as users will already know how WildFly
RBAC works
and can apply it to Hawkular. Plus if the user already has its org
members in
a central KeyCloak with role mappings, we can hook up to that instance
and get the mappings "for free".
Now for operations on WildFly (not only the classic RHQ-operations, but
also modifying
resource config), RBAC in WildFly is "hiding" whole sub-trees, but also
(iiuc) individual attributes
if you do not have the right role:
role=SuperUser:
[standalone@localhost:9990 /] cd /core-service=management/access
[standalone@localhost:9990 access] ls
audit authorization
role=Monitor:
[standalone@localhost:9990 /] cd /core-service=management/access
[standalone@localhost:9990 access] ls
audit
With enough privileges it is possible to see the access definitions
under /core-service=management/access=authorization/constraint=*
While it is possible for WildFly to obtain the security levels
(automatically)
from the WildFly Metadata, we still need to find a good way to add this
information
into our resource types, as the UI may need to react to them and not
show a
restart button for user that only has the Monitoring role. In theory we
could
just issue the operation with the user perms and see it fail on WildFly
side, but that
is certainly not user-friendly and thus not desired.
For other kinds of resource like Tomcat we probably need to encode the
roles
to the best of our knowledge.
Heiko
[1] http://blog.arungupta.me/role-based-access-control-wildfly-8/
[2] http://www.dzone.com/articles/configuring-rbac-jboss-eap-and
7 years, 5 months
[Metrics] JAX-RS 1.1 implementation update
by Thomas Segismont
Hi,
This morning I've fixed the remaining issues in the JAX-RS 1.1
implementation branch. The REST API test suite is now fully passing
against both JAX-RS 1.1 and 2.0 implementations.
I've added a 'diff.txt' file in the 'api' [1]. Reviewers should
carefully look at handler code differences.
Regards,
Thomas
[1] diff -r --exclude=target metrics-api-jaxrs metrics-api-jaxrs-1.1 >
diff.txt
7 years, 6 months
Maven, Continuous and Reproducible
by Peter Palaga
Hi *,
I think I found a way how to make our process more continuous, while
staying with stock Maven and Components in separate git repositories.
The core of the idea is that we actually do not need to release the
components because they are not our deliverables (yes, except for
Metrics). If we were able to declare the dependencies using git
revisions and build them on the fly, we could get rid of both SNAPSHOTS
and releases.
I have written srcdeps-maven-plugin [1] today that does exactly that:
* It collects dependencies with versions matching
{whatever}-SRC-{git-commit-hash}
* It checks out {git-commit-hash} of their sources to
~/.m2/dependency-sources
* It changes the version in the sources to
{whatever}-SRC-{git-commit-hash}
* Builds the artifacts and installs them to the local repository
* All the above happens before the dependency resolution starts
so it is fully transparent for the rest of Maven.
* The -SRC- dependencies are build only if they are not found in local
repository - so they prolong the build only when upgrading.
How to try it out:
#Make sure that you have maven 3.2.5 or newer:
mvn -version
# build the plugin
cd ~/git
git checkout https://github.com/ppalaga/srcdeps-maven-plugin.git
cd srcdeps-maven-plugin
mvn clean install
# build hawkular with the plugin
cd ../hawkular
git remote add ppalaga https://github.com/ppalaga/hawkular.git
git fetch ppalaga
git checkout -b 150819-srcdeps
mvn clean install ...
[1] https://github.com/ppalaga/srcdeps-maven-plugin
7 years, 6 months
Extra back-end for our front-end
by Viliam Rockai
Hey all,
As we put more and more functionality into Hawkular, the more and more
logic is put into the front-end itself, too. From my perspective, we're
dealing with too much stuff that doesn't even belong to the front-end
anyway. I believe we should create a new back-end module, which would
connect all the existing modules with the front-end. This module may
even be maintained by the front-end team, since it'll evolve and mutate
very fast - to suit the UI needs. There are several use-cases which call
for such module. For example to create all the alert entities needed for
alerting you need to create a:
* Trigger (per alerting "entity")
* Dampening (one or more)
* Condition (one or more)
Each of those has its separate endpoint and creation of each may fail.
So basically we should (we don't do that yet, we just assume everything
went all right) even deal with transactions in the front-end right now.
>From the UI perspective, this is just a single entity "Alert
definition". Another question is - when should those objects be created?
Once you add an URL - that's pretty easy (for URLS). But, in my opinion,
for JVMs they should be created once the resource is discovered, not the
1st time the resource is accessed by UI. And the situation will be more
complicated with new resources. Being able to get some predefined sets
of metrics would be another nice feature. I.e., right now, we do 3
requests (User, maximum, committed) to get the data for the "JVM Heap
Usage" graph (and other graphs, too). Being able to process those data
on a server and send it the the front-end in one bulk would be pretty
neat.
I believe adding a new module to the back-end, which role would be to
connect the UI to the rest of Hawkular services would be beneficial for
performance, testability and robustness of the whole app.
WDYT?
Viliam
7 years, 6 months
Add JDBC Driver support in Agent
by Peter Palaga
Hi *,
there is a requirement for Agent to support adding JDBC drivers
https://issues.jboss.org/browse/HAWKULAR-517
The named Jira does not name any standalone/domain/local/remote related
limitations for the functionality, hence the functionality should be
there for all modes.
As already noticed on IRC, WildFly 9's jboss-cli.sh offers the
possibility to add a module, but it works only for the local machine in
standalone mode. Remote servers or domain mode are not supported.
So clearly, for now, we can support the standalone local mode using the
same means as jboss-cli, but how should we proceed further?
Should we
(a) wait for WildFly to implement the missing functionality, or
(b) contribute to Wildfly or
(c) create a minimal Agent to install on remote servers to provide the
functionality missing in WildFly itself (as proposed by Heiko)?
Thanks,
Peter
7 years, 7 months
