Tenant Id - Not Part of URL
by Stefan Negrea
Hello Everybody,
I've been working on a PR for the upcoming Hawkular Metrics release that will remove the tenant id from the end-point URLs. The tenant id will be moved to either a header parameter or a query parameter. The query parameter is in place for cases (such as curl) where setting a header is not possible, difficult, or inconvenient.
Here is an example of the change:
Existing URL:
/{tenantId}/gauge/{metricId}/data
New URL:
/gauge/{metricId}/data
Tenant id set via:
1) header - tenantId
2) query parameter - tenantId
There are two exceptions to this rule, /tenants and /db/{tenantid}/series. The /tenants end-point will be changed into something different in the upcoming releases since it is mostly a management type API that does not belong in the same place with the regular metrics endpoint. And /db/{tenantid}/series end-point is needed in this exact format for compatibility with Influxdb compatible services.
Now, to the merits of this change. The tenant id is volatile, can change any time, and changes to it should be expected; but the rest of the URL is fixed. The second issue is that the tenant id is a security concern. So we were limited in design choices since a security concern was leaking as part of the URL.
So removing the tenant id from the URL will give us permanent & consistent addresses for resources (metrics and metric data points). And we will gain a lot of flexibility on the security side. In the future, users could authenticate with a user/pass combo and the backend would transform that into a tenant id to be used on the request. If the same user later decides to use a tenant id to pass along the request, the URL of the resources would not change. Another expectation is that tenant id is not sufficient, it is typically a combo of id + secret; so we would have resorted to a header or query param for the second piece of information (the secret).
This change will give us the flexibility to adjust the security model (the meaning of tenant ids and ways to validate them) without compromising the URL structure. This will help Hawkular Metrics as it gets integrated into more and more projects and products.
Here are the links to the JIRA and the PR for this change:
https://github.com/hawkular/hawkular-metrics/pull/202
https://issues.jboss.org/browse/HWKMETRICS-68
Thank you,
Stefan Negrea
Software Engineer
9 years, 2 months
Hawkular Metrics 0.3.3 - Release & Beyond
by Stefan Negrea
Hello Everybody,
I am happy to announce release 0.3.3 of Hawkular Metrics. The release is anchored by three major and notable changes: REST API reorganization, tenant id changes, and Docker + Kubernetes work.
1) REST API reoganization
- The API has been reorganized to follow a more traditional REST structure.
- The numeric metrics have been renamed to Gauage. Going forward the term number will be used for an overarching category of metrics (gauge, counter, histograms, etc.).
- The root of the project has been updated to be consistent with the rest of the Hawkular projects. The new root is http://host:port/hawkular/metrics
The attached pdf document has the comparison for the API changes between 0.3.1 and 0.3.3.
2) Tenant Id
The tenant id has been removed from the URL to either a header parameter or a query parameter. The query parameter can be used in cases (such as curl) where setting a header is not possible, difficult, or inconvenient.
The concept of tenant will be an integral part of the project going forward. But we wanted more flexibility in the way the tenant id for a request is derived. So removing the tenant id from the URL will give us permanent & consistent resource addresses (metrics and metric data points); and will gain a lot of flexibility on the security side. In the future, users could authenticate with a user/pass combo and the backend would transform that into a tenant id. If the same user later decides to use the tenant id header, the URL of the resources accessed with the user/pass combo would not change. Another expectation is that tenant id is not sufficient, it is typically a combo of id + secret; so we would have resorted to a header or query param for the second piece of information (the secret) in the long run anyway.
Here is an example of the change:
Existing URL:
/{tenantId}/gauge/{metricId}/data
New URL:
/gauge/{metricId}/data
Tenant id set via:
1) header - tenantId
2) query parameter - tenantId
There are two exceptions to this rule, /tenants and /db/{tenantid}/series. The /tenants end-point will be changed into something different in the upcoming releases since it is mostly a management type API that does not belong in the same place with the regular metrics endpoint. And /db/{tenantid}/series end-point is needed in this exact format for compatibility with Influxdb compatible services.
The attached pdf document includes the removal of the tenant id from the URL.
3) Docker and Kubernetes
Thanks to the amazing work done by Matt Wringe, we now have a subproject in Hawkular Metrics that can be used to create components to be run on Openshift/Fabric8 (https://github.com/hawkular/hawkular-metrics/tree/master/containers).
This includes:
a) A customized Cassandra docker image which uses a seed provider to automatically detect other nodes running behind the same service.
b) A standalone dockerized Hawkular Metrics image. This will startup a hawkular metrics instance which will automatically detect and connect to the Cassandra service.
c) A kubernetes application for a single step install into OpenShift or Fabric8. The zip can even be deployed via the drag-n-drop mechanism in the Fabric8 console!
This is the foundation for later integrations that would require the project package in the form of containers.
Github Release:
https://github.com/hawkular/hawkular-metrics/releases/tag/0.3.3
JBoss Nexus Maven artifacts:
http://origin-repository.jboss.org/nexus/content/repositories/public/org/...
Jira release tracker:
https://issues.jboss.org/browse/HWKMETRICS/fixforversion/12326937
Hawkular Metrics 0.3.4 and Beyond
Here is a list of features and enhancements that we planned for 0.3.4 and beyond.
1) Gauge Aggregates - Long-term storage of numeric metrics at the expense of losing some fidelity. The design has been already presented and discussed during 0.3.3 release cycle. The task queue work has already been started by John. We expect at least an initial implementation to land in 0.3.4.
3) Go client - will help with integrating with third party metrics collection framework. This work is the foundation for a Heapster sink.
4) Public Java API - following the work done in 0.3.1 for the core, the goal is to separate the implementation from a public API and make that available to clients
5) 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.2 is to increase coverage.
6) Improved docker and kubernetes support
A big "Thank you" goes to John Sanda, Thomas Segismont, Mike Thompson, Matt Wringe, and Heiko Rupp for their project contributions. Special mentions go to Jeeva Kandasamy, Jirka Kremser, and Michael Burman for their project help.
Thank you,
Stefan Negrea
Software Engineer
9 years, 2 months
Hawkular Alerts - 0.0.1-Snapshot pushed to master
by Jay Shaughnessy
Hawkular Alerts has been updated in master.
Given our latest Hawkular convention for versioning, the versioning has
gone backwards. We pushed Version 0.0.1-SNAPSHOT, changed from Version
1.0.0-SNAPSHOT. We maintain snapshot releases for use with Kettle.
But the version has changed to reflect API changes. Going forward we'll
maintain the version of 0.0.1 unless we have an API change, at which
point we'll up the micro-version. Eventually this will settle down and
we can move to versioned components, and avoid breaking API changes.
We've begun supplying developer documentation, here:
http://www.hawkular.org/docs/dev/alerts.html
What's NEW!
* Alert life-cycle support
o Alerts now support Open, Ack and Resolved states.
o This gives us the ability to store and display full start and
end times for an alerting "event".
* Trigger AutoResolve
o This replaces and builds on the former "trigger safety" feature.
o Optionally provide AutoResolve conditions and dampening to
toggle the Trigger from Firing mode to AutoResolve mode.
o Optionally have a Trigger's alerts set Resolved automatically,
when the trigger's AutoResolve conditions are satisfied.
* Trigger AutoDisable
o Optionally have a Trigger disable itself after firing.
o Mutes a trigger without the need to define AutoResolve.
* Rest Api control of the new features.
* Twilio SMS sender action
* Aerogear sender action
* Performance testing infrastructure
* Improved Rest API documentation
And for Hawkular Kettle!
* Data Filtering
o Only forward relevant metric and availability data for alert
processing.
o Remove the metrics and availability not used in any trigger.
And of course several fixes and improvements.
Coming Up:
* Moving the persistence back-end to Cassandra to leverage the Metrics
cluster (soon).
* PagerDuty action integration.
* Integration of the new 0.0.1 features into Hawkular.
Hawkular Alerts Team
Jay Shaughnessy
Lucas Ponce
Thomas Segismont
9 years, 3 months
Maven swagger plugin
by Gary Brown
Hi
The current version of the maven-swagger-plugin used by hawkular doesn't include derived types in the generated docs.
I've tried updating to 2.3.4 and it still does not work. From some basic tests with 3.0.0, it seems to produce the correct content in the json schema - but has slightly different attributes to the plugin configuration, which when updated does not seem to run the template correctly.
The other issue is some API changes when updating the com.wordnik:swagger-* dependencies in line with this maven plugin, as there have been some GAV and API changes.
Its not an urgent issue, but it looks like we will be impacted by changes when we need to upgrade, so thought I would raise the issue.
Regards
Gary
9 years, 3 months
Hawkular Metrics Openshift Containers
by Matt Wringe
I have a new subproject in Hawkular Metrics which sets up creating
components for Openshift/Fabric8
(https://github.com/hawkular/hawkular-metrics/pull/200).
There are 3 main parts
Cassandra: creates a custom seed provider to support
ReplicationControllers in Kubernetes, creates a folder/zip archive which
can be used to generate a Docker image. It may make sense to move the
Cassandra parts out to a separate project.
Hawkular Metrics: creates a folder/zip archive which can be used to
generate a Docker image
Kubernetes: pulls everything together into a single kubernetes
application. Can be used to deploy an application zip into fabric8 (via
drag and drop in the web console or via the maven plugin) or deploy all
the components into Openshift via the kubernetes.json configuration file.
The docker images are not created and deployed to a docker registry as
part of the build, it will just create a folder where you can run the
docker build from. None of the maven docker plugins I looked at seemed
to really work properly, so its still a manual process to do the build
(and push to a registry). Its something which needs to be improved.
The Cassandra service currently only supports adding new nodes to a
cluster and not removing them via the ReplicationController. This is due
to the replication factor being set to be 1 by default (which means when
a node is removed, so is the data it contained).
I believe the docker subproject of hawkular metrics is obsolete and can
be removed
(https://github.com/hawkular/hawkular-metrics/tree/master/docker), but
someone please correct me if I am wrong. It's scripts are referring to
the console which no longer exists as part of the project.
- Matt
9 years, 3 months
[GSoC] Hawkular Android Client
by Artur Dryomov
Hi everyone,
This year I will be working on the Hawkular Android client application as
part of the Google Summer of Code 2015 program.
The application itself will use Hawkular API and AeroGear SDK. In coming
days I’ll research these areas, especially documentation, and will try to
create some sort of architecture and basic design.
Thank you all for this opportunity!
Artur.
9 years, 3 months
