Adds ETL based compression methods in the core for Gauge data (for now, I will later in the PR add support for counters & availabilities also).

After this PR is merged, I recommend replacing Deflate with LZ4 again (since we need speed due to the ETL processing)

This PR for now is missing the job scheduler stuff, that is coming later to this same PR.

This is WIP. At the time of writing this, gauge inserts / fetches work correctly, but for example metrics_idx queries rely on the partition keys and that needs to be fetched from the temp tables also (otherwise our unit tests fail because they test two things and not just insert / delete like they claim to)

HWKMETRICS-83 Create glue code component to integrate with hawkular-bus

This pull request is comprised of three commits.

• Implement an InsertedDataPoint event stream

The MetricsService interface now exposes an #insertedDataEvents method. The method returns a hot Observable emitting Metric objects, when their data has been succesfully inserted.

Clients can subscribe to this Observable (preferably on a dedicated scheduler!) and they will get notified.

• Fire @ServiceReady event when MetricsService is initialized

The Metrics JAX- RS module now fires a CDI @ServiceReady event. This event can be observed by a "super"-module in order to know when the MetricsService instance is initialized.

The event is fired just before the MetricsServiceLifecycle status changes to "STARTED", so that clients can subscribe to the #insertedDataEvents observable before new data points are accepted.

• Introduce Hawkular Metrics Component module

There is a new "hawkular-metrics-component" WAR module. It is meant to replace "hawkular-metrics-api-jaxrs" module in Hawkular deployment.

This new WAR is a "super"-module: it uses Maven WAR plugin overlay mechanism to add extra classes to the standalone metrics web application.

The extra classes allow to subscribe to the #insertedDataEvents observable and publish messages on the bus.

In order to make the migration easy, I have shamelessly copied Alerts' AvailDataMessage and MetricDataMessage classes. Theses messages are posted on to the "HawkularAvailData" and "HawkularMetricData" topics, respectively.

After this PR is merged we only need to change the agent code to remove the "double-push" part. And change Hawkular POM to switch to the new Metrics component, that's it.

You may notice that the integration test class borrows a lot from the RESTTest class in rest-tests module. I think we need to introduce a new 'test-utils' module, in a DRY approach. But I wouldn't want to block this PR and would rather do this as a separate PR.

This is an experimental PoC to study the demand publishing pattern inside hawkular-services/metrics. I have opened the PR with the intention to record the comments but this is just a WIP draft to continue the discussion of HAWKULAR-1102 issue, this could lead in something formal to contribute or definitely discard it, but making technical proposal may help in any case. First, @FilipB it could be possible for you to build a hawkular-services distribution with these changes and run the performance tests ? Thanks.

This PR adds an endpoint for fetching stats (i.e., bucket data points) from multiple metrics in a single request. Right now it only supports gauges and counter. I will update the endpoint to also support gauge and counter rate stats as well. I wanted to go ahead submit the PR for review though because adding support for rates is mostly boiler plate along with additional integration tests.

@lucasponce would it make sense to include availability stats as well?

A missing timestamp will result in rejecting the entire request before processing it.

Note: this is implement in handler code rather than using JAX-RS framework features beacuse of divergence between the two JAX-RS standards. If/when one of the standards is dropped this code could be revisited although this implementation is simpler and easier to extend.

HWKMETRICS-330 Update filter to be async

A bit of context first. Hawkular Metrics is a reactive application and calls to a blocking API should be avoided as much as possible.

The Openshift integration library had a servlet filter mechanism to authenticate users. The filter code used the JDK's HTTP client to call Kubernetes' master server. While this was alright has a first implementation (in order to provide the feature as quickly as possible), it is a serious limitation to reach our performance goals.

There were two problems to tackle:

1. choose an async HTTP client API
2. make the filter code asynchronous

For the HTTP client, I considered a few options: Netty, vert.x, Undertow. I picked undertow because it does not add a new dependency, we can reuse the io threads (instead of creating yet another thread pool). The downside is that the Undertow client API is low-level (no pool implementation) and not well documented.

For the filter code, my first try was to use servlet async API from the filter. But RestEasy throws an exception because it wants start the async exchange itself. I wrote to the resteasy-user list but got no reply. And even if we had a fix, we would have to wait for a new RestEasy and Wildfly release. So I wrote an Undertow extension which is executed in io threads before the servlet handler is involved.

The implementation consists in pooling Undertow HTTP client connections and filering the Metrics client requests (only dispatch to the servlet handler if the user is authenticated).

While working on the implementation I had to find a way to share the MetricsRegistry between the webapp code and the authenticator code. So there's a MetricsRegistry provider class in core-util now.

Also, I enhanced the Gatling scenario file to support multiple authentication mechanisms (none, Hawkular integration, Openshift htpasswd file, Openshift token). I took the opportunity to document the scenario options in the project README.

Note that performance enhancements will be more visible in environments where Kubernetes reponse time is minimal.

This PR requires PR #818 to be merged first. This removes the calls to metricsService.findMetric() in cases where it's not needed. This reduces the amount of Cassandra calls in read requests that use tags (other than fetching full metric definition).

HWKMETRICS-291 Provide different strategies for C* statement grouping

This PR introduces a contract for batching strategies.

So far, two strategies are implemented:

• use batch statements
• use single statement

We can add variations of the first strategy if needed.

The user can choose the batching strategy with configuration. If batch statement strategy is chosen, batch statement size can be configured.

It's a kind of duplication of the GET endpoints "gauges/stats" and "counters/stats". The reason is the same as the one explained here: https://issues.jboss.org/browse/HWKMETRICS-410 and which ended up in duplicating GET "gauges/raw" endpoint to POST "gauges/raw/query" in a similar way.

Also added integration tests

Implements logical AND for filtering with tags. Also adds a MatchType enum to be used, which has a following meaning:

• ANY = logical OR
• ALL = logical AND