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
New and noteworthy in hawkular-parent 25
by Peter Palaga
Hi *,
hawkular-parent 25 brings the following:
* srcdeps-maven-plugin 0.0.5
* meets the promisses falsely done for 0.0.4:
* less console output
* built without tests
* wildfly-maven-plugin 1.1.0.Alpha4
I have sent PRs to all components repos.
Thanks,
Peter
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
7 years, 6 months
batch vs async inserts
by John Sanda
Many of you have probably seen warnings in the Hawkular server log like,
--------------
WARN 15:55:59 Batch of prepared statements for [hawkular_metrics.data, hawkular_metrics.metrics_idx] is of size 5665, exceeding specified threshold of 5120 by 545.
--------------
This warning is generated due to batch statements being larger that a threshold defined in cassandra.yaml. It defaults to 5 KB. When the batch statement is larger than that threshold, Cassandra logs the warning. Note that the threshold is based on the actual size of the payload, not the number of statements in the batch. We should stop seeing this warning in 0.7.0 release of Metrics. See HWKMETRICS-252[1] for details.
The general advice in the Cassandra community is to favor async writes in parallel over batch inserts when you are trying to improve or optimize write performance. Unlogged batches across multiple partitions is almost always a bad idea. The one exception is with unlogged batches in which all of the mutations are for the same partition. In that case, Cassandra performs the writes atomically. This is how we use batch inserts in metrics. Interestingly I have seen threads on the Cassandra mailing list that still discourage the use of batch inserts even in this case. This thread[1] provides some really interesting insights and analysis on unlogged batch inserts vs async inserts. The thread references a document with some performance analysis that is worth a look.
[1] https://issues.jboss.org/browse/HWKMETRICS-252 <https://issues.jboss.org/browse/HWKMETRICS-252>
[2] http://www.mail-archive.com/user%40cassandra.apache.org/msg43976.html <http://www.mail-archive.com/user@cassandra.apache.org/msg43976.html>
7 years, 6 months
Fwd: [wildfly-dev] Powershell scripts
by Heiko W.Rupp
Windows devs FYI
Forwarded message:
> From: Tomaž Cerar <tomaz.cerar(a)gmail.com>
> To: wildfly-dev(a)lists.jboss.org <wildfly-dev(a)lists.jboss.org>
> Subject: [wildfly-dev] Powershell scripts
> Date: Tue, 29 Sep 2015 17:29:42 +0200
>
> Hey guys,
>
>
> just heads up, I've managed to prepare[1] all powershell scripts to
> replace
> the aging .bat ones.
>
> New scripts unify most of the shared "code" that all scripts use by
> including common.ps1,
> and each script only has the code that differs from common behavior
> they
> all share.
>
> As result of move we now have much more reliable and faster scripts
> that
> share common code,
> which helps with maintaining a lot.
>
> New scripts (domain.ps1 & standalone.ps1) now support --background
> (also
> controllable via .conf.ps1)
> option that runs the process in background and remembers its pid and
> as
> such add support for
> feature that until now was only in *nix version of scripts.
>
> I would like to propose this PR for inclusion to WildFly 10. As it
> doesn't
> alter any existing behavior
> but just adds & improve the script experience on Windows.
>
> As we get to test and verify that new scripts don't break/include any
> currently available option/action
> I would also like to remove the batch scripts[2], so they would just
> do
> call out to their .ps1 counter parts.
>
> Once this scripts get merged, I will send PR to also add PS scripts
> for
> WildFly full defined scripts,
> given that most of the functionally is already in "common.ps1" new
> scripts
> will be just simple 5 liners [3]
>
>
> --
> tomaz
>
>
> [1] https://github.com/wildfly/wildfly-core/pull/1118
> [2] https://github.com/wildfly/wildfly-core/pull/1126
> [3]
> https://github.com/ctomc/wildfly-core/blob/powershell/core-feature-pack/s...
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
7 years, 6 months
Switching personas is now implemented
by Juraci Paixão Kröhling
Team,
The first screens for Organizations are now implemented, which means
that the account switcher (top-right corner) now includes the
organizations that the user might switch to.
The "SwitchedPersona" event was already implemented, and I think a
feature or two was already prepared for that ("Inventory" comes to my
mind). For other screens, I don't think it's currently correct, so,
please test your screens and see if any action is required once this
event occurs.
The general rule is: if you got data that is dependent on the current
tenant, you might want to re-load the data. Same for permissions: if you
checked the permission before showing an item on the screen, you might
want to re-evaluate that for the "current tenant".
As reminder: the documentation for the events produced by Accounts can
be found here:
http://www.hawkular.org/docs/dev/accounts.html#_frontend_events
And this is an example of how to use it:
http://git.io/vc3CL
- Juca.
7 years, 6 months
