On the way to the M1 release ...
by Heiko W.Rupp
Hey,
I see those things that need (at least) to be done/fixed for the next
Wed release:
- pinger does not respond to deletions (HAWKULAR-235/-263)
- inventory does not delete metrics on resource deletion HWKINVENT-45
(if INV can not make it, can UI send the delete metrics requests ?)
- duplicate URL addition HAWKULAR-255
- alerts is not multi-tenant yet (PR is sent, but may be too disruptive
?) HWKALERTS-40
-- Add url fails across tenants for same url (HAWKULAR-277 contains a
possible solution)
-- marking alerts as resolved (needs above PR for the backend)
- working pagination
- working availability charts
- move everything on non-snapshot releases
- update / write documentation on hawkular.org
As we will most probably not have full app servers functionality,
we should disable that tab so that users are not confused by it
and re-enable and work on it after the release.
Similar for the embedded agent.
Can we please concentrate on the above (and what else is needed that is
not yet on the list) to get
the release out?
8 years, 10 months
Hawkular Metrics 0.3.4 - Release & Beyond
by Stefan Negrea
Hello Everybody,
I am happy to announce release 0.3.4 of Hawkular Metrics. The release is anchored by stability improvements and Docker + Kubernetes work.
Here are the release highlights:
1) InfluxDB Compatibility Layer
- pretty printing of query results with the 'pretty' query parameter
- absolute moment operands in queries (ex: select * from test where time > 1501560s and time < 4560546h)
- various fixes which allow to integrate nicely with Grafana (declaring Hawkular Metrics as an InfluxDB 0.8 datasource)
2) RxJavaMigration
- big refactoring to use RxJava instead of Guava's ListenableFuture
- RxJava provides a much richer API for building asynchronous programs
3) Server Start-up
- the server no longer requires Cassandra to be started first
- any client requests will get back a 503 response code if the server has not fully initialized due to Cassandra being down at start up time
4) Docker and Kubernetes
- all project docker images are now available in Docker Hub! Get them here:
https://registry.hub.docker.com/u/hawkular/hawkular-metrics/
https://registry.hub.docker.com/u/hawkular/hawkular-cassandra/
- improved replication controller support now means that both the Hawkular-Metrics and Cassandra images can be scaled up or down
- various other smaller improvements, including better support for when containers startup
5) REST API (IMPORTANT!)
- tenantId header was renamed to Hawkular-Tenant
- tenantId header fallback was removed
- GET {id}/tags only returns the tags, not the whole definition anymore
- GET {id} returns the metric definition (see HWKMETRICS-110 [1] for known issue)
6) UI Explorer
- was removed from the project
- discussions are underway to find a new home for the functionality and code (probably hawkular-ui-components)
- npm is no longer required to compile the project
7) Task Queue
- a generic task queue was designed and developed as part of this release
- provides functionality for scheduling and executing background tasks or jobs
- task execution is
scalable - automatically distributed among Hawkular Metrics servers
durable - Tasks are persisted
fault tolerant - Tasks are rescheduled for future execution when there is a failure
- it will serve as the foundation for
computing/storing aggregated metrics (i.e., rollups)
deleting metrics
changing data retention
- this functionality will be basis for any background task based design for the project
Github Release:
https://github.com/hawkular/hawkular-metrics/releases/tag/0.3.4
JBoss Nexus Maven artifacts:
http://origin-repository.jboss.org/nexus/content/repositories/public/org/...
Jira release tracker:
https://issues.jboss.org/browse/HWKMETRICS/fixforversion/12327259/
Hawkular Metrics 0.3.5 and Beyond
1) Gauge Aggregates - Long-term storage of numeric metrics at the expense of losing some fidelity. With task queue released in 0.3.4, the expectation is to start the actual implementation 0.3.5.
2) Update REST testing - while the current set of tests is a good gauge for regressions, the overall coverage is still low. The plan for 0.3.5 is to increase coverage.
3) Improved Docker and Kubernetes support - this is a long term goal for the project
4) RXJava - the initial transition from Guava was done in 0.3.4. Future releases will build upon this foundation.
A big "Thank you" goes to John Sanda, Thomas Segismont, Mike Thompson, Matt Wringe, Michael Burman, and Heiko Rupp for their project contributions. Special mentions go to Jeeva Kandasamy and Jirka Kremser for their project help.
[1] https://issues.jboss.org/browse/HWKMETRICS-110
Thank you,
Stefan Negrea
Software Engineer
8 years, 10 months
new agent to support port offsets
by John Mazzitelli
This is for https://issues.jboss.org/browse/HAWKULAR-285 . I presume supporting port-offsets is so we can run integration tests on different ports so they don't step on other app servers running on the same machine.
I fixed this in the agent - it now gets address/port values the "official" WildFly way via socket-binding-group/socket-binding (that is, we use the same configuration mechanisms all other WildFly subsystems use). This also fixes the issue of having to have ${jboss.bind.address} and ${jboss.http.port} variables in the agent's "url" attribute. That's because the "url" attribute is no longer required.
You will notice now the agent running in kettle doesn't configure any URL in <storage-adapter>. That's because the default is to assume it is running co-located with the server components, in which case the agent will look at the <socket-binding> for "http" and use its address and port (defined in the normal WildFly location down at the bottom of standalone.xml). So you can use port offsets and it will work.
To support agents running external from the server components, there is a new attribute in the agent's <storage-adapter> called "serverOutboundSocketBindingRef". If this is set, you must have a <outbound-socket-binding> setting of the same name in your socket-binding-group. This defines where your hawkular server is. The agent will use those socket binding settings to know where to talk to Hawkular server components. For example, if your agent has this:
<storage-adapter serverOutboundSocketBindingRef="hawkular" ... />
You need to tell WildFly (and hence the agent) about that outbound binding in the socket-binding-group like this:
<socket-binding-group default-interface="public" name="standard-sockets" port-offset="${jboss.socket.binding.port-offset:0}">
...
<outbound-socket-binding name="hawkular">
<remote-destination host="your-external-hawkular-server-hostname" port="8080"/>
</outbound-socket-binding>
...
When you do this, the agent will use "http://your-external-hawkular-server-hostname:8080" as its URL to the hawkular server.
This will get into kettle when this PR is merged: https://github.com/hawkular/hawkular/pull/162
8 years, 11 months
logging categories
by John Mazzitelli
I created a JIRA [1] and PR [2] so that when we build a dev build you'll get the console to show DEBUG log messages. In production mode, it stays at INFO level. I also added additional logging categories - double check that I added your component's logger categories correctly. In addition, I removed xsl:if checks and changed to xsl:choose in the .xsl.
Merge at your earliest convenience, please :)
[1] https://issues.jboss.org/browse/HWKINVENT-55
[2] https://github.com/hawkular/hawkular/pull/149
8 years, 11 months
What should -Pdev do?
by Peter Palaga
Hi *,
sorry, for bringing this up so late on this list. I discussed this on
#hawkular but probably outside US office hours and I totally
underestimated the amount of emotions some of us are tied by to -Pdev.
There was a change by me recently that changed a little bit how -Pdev
behaves.
Originally, a -Pdev just produced a bundle in which the default
configuration was changed to suit the dev use case: esp. one had jdoe
loaded by invoking simply standalone.sh.
As I worked on fixing the end to end tests in Hawkular, Lucas was fixing
the REST tests in alerts. We both had the problem that the hawkular
bundle that maven has downloaded from JBoss Nexus was build without
-Pdev and as a consequence of that we could not run our integration
tests by simply taking the bundle. We had to unzip the bundle, do what
-Pdev does and only after that we could start it.
Hence, as a solution, I have prepared
https://github.com/hawkular/hawkular/pull/134
which caused that the stuff originally present only in bundles built
with -Pdev became available by default, but to use that dev stuff,
wildfly needs to be started with
standalone.sh -c standalone-itest.xml
because standalone-itest.xml is the place where the dev configuration is
activated.
With this change, there is only one way to build a hk bundle, hence
there is only one bundle to distribute and download but you can do both
dev and prod things with it. Not having jdoe/password by running the
default config is a good thing from the security PoV.
The bottom line is that -Pdev in the present master has one small issue
that I fixed in https://github.com/hawkular/hawkular/pull/148
Please comment.
Thanks,
Peter
8 years, 11 months
[process] tickets and PRs
by John Sanda
Does there need to be a pull request for every ticket? Put another way, do all commits to master need to come by way of PRs? I think that there are scenarios where a manual merge makes more sense.
- John
8 years, 11 months
Alert Email Config
by Jay Shaughnessy
It's not totally clear what we want to do in Hawkular to configure the
smtp server for use with the e-mail action plugin for alerts. OOB WFly
is configured for smtp server localhost:25. This generally does not
work in dev envs.
So, we deploy the e-mail action plugin, we supply the e-mail address in
Hawkular user registration, and then we just generate server log
warnings when it doesn't work. It's easily remedied with a a manual
edit. For us we can set it to the RH corp smtp server, which will work
fine as long as you run from behind the VPN, or on the corp net.
We could hardcode this into our Dist but I'm not sure if we want to
publicize that host.
Otherwise, a manual edit is required unless we provide for some sort of
build-time command line prop to be applied to Dist by the build.
Thoughts?
8 years, 11 months
how to get literal $ in .xsl
by John Mazzitelli
BTW: if anyone knows how to fix this, let me know.
In the agent configuration, Thomas H. wanted to be able to configure the agent to talk over a different IP/port than localhost:8080 (specifically the one Wildfly binds to - jboss.bind.address and jboss.http.port).
In the standalone.xml config, this actually works:
<storage-adapter type="HAWKULAR"
username="jdoe"
password="password"
url="http://${jboss.bind.address:127.0.0.1}:${jboss.http.port:8080}"/>
However, when I try to get that url value to be added to the default standalone.xml via our XSL, I get an error.
So, this line here:
https://github.com/hawkular/hawkular/blob/mazz/wip/dist/src/main/resource...
I want to be:
url="http://${jboss.bind.address:127.0.0.1}:${jboss.http.port:8080}"/>
But XSL parser dies. I tried using "\$" and "$" to no avail. Anyone know how to get a literal $ to be parsed here?
8 years, 11 months
