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
1 year, 7 months
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
1 year, 7 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
1 year, 7 months
Hawkular.org
by Thomas Heute
With the recent repackaging effort + the ManageIQ UI, we need to rethink
hawkular.org.
It's tricky to keep it simple, what to download, for what usecase... And at
the moment it's getting outdated.
IMO, it should be trivial for end users to figure out:
- What to download
- where to download and how to install the server
- find/browse/download the various options to feed the server with data
(WF agent, ptrans supported protocoles, ...)
- find/browse/download options to use/read the data: (ManageIQ,
Grafana...)
and for the developers
- find/browse/download the client libraries (Ruby, Python...)
- Find client libraries documentation
- Find examples...
We should probably not separate/fork Hawkular Services from Hawkular
"community" too much, beside the installation procedure and few things that
we would mention as only available in the "larger" package. I use the term
"Hawkular Server" in the mind map for the 2 "flavors".
Please propose improvements to the draft attached that represents the
website structure. (A square is not necessarily a page, it may be a section
of a page)
Thomas
9 years, 11 months
Sync with Inventory
by Austin Kuo
Hi all,
I’m currently investigating how to sync with inventory server.
Here’s the example scenario:
Consider the following problem. A user creates version 1 of the app with
two http servers, one listening on port 8080, the other on port 8181. In
version 2, the http server listening on port 8181 is no longer needed.
When the old version is stopped and the new version started, there will be
just one http server listening. The application is not aware of the
previous state. What should we do so that the second http server is removed
from Inventory?
Thanks in advance.
10 years
Metrics and use of metrics_idx
by Michael Burman
Hi,
This sparked my interest after the discussions in PR #523 (adding cache to avoid metrics_idx writes). Stefan commented that he still wants to write to this table to keep metrics available instantly, jsanda wants to write them asynchronously. Maybe we should instead just stop writing there?
Why? We do the same thing in tenants also at this time, we don't write there if someone writes a metric to a new tenant. We fetch the partition keys from metrics_idx table. Now, the same ideology could be applied to the metrics_idx writing, read the partition keys from data. There's a small performance penalty, but the main thing is that we don't really need that information often - in most use cases never.
If we want to search something with for example tags, we search it with tags - that metricId has been manually added to the metrics_idx table. No need to know if there's metrics which were not initialized. This should be the preferred way of doing things in any case - use tags instead of pushing metadata to the metricId.
If we need to find out if id exists, fetching that from the PK (PartitionKey) index is fast. The only place where we could slow down is if there's lots of tenants with lots of metricIds each and we want to fetch all the metricIds of a single tenant. In that case the fetching of definitions could slow down. How often do users fetch all the tenant metricIds without any filtering? And how performance critical is this sort of behavior? And what use case does list of ids serve (without any information associated to them) ?
If you need to fetch datapoints from a known metricId, there's no need for metrics_idx table writing or reading. So this index writing only applies to listing metrics.
- Micke
10 years
inventory/deprecated not so easy to use
by John Mazzitelli
From: http://www.hawkular.org/docs/rest/rest-inventory.html#_api_endpoints
"The old API has been kept so that clients can gradually move to the new API, but the old API has moved from /hawkular/inventory to /hawkular/inventory/deprecated. The clients using the old API will have to be modified to use the new endpoint but are otherwise unaffected."
This isn't exactly true. Not ALL the API from <0.17.0.Final is there at /deprecated - if I'm using some of the old API I have to modify the code, but not all.
Jay tried using the old agent with the new inventory, and he switched the inventory context from "hawkular/inventory" to "hawkular/inventory/deprecated" (there is a inventory-context attribute on <storage-adapter> in the agent config for just such an emergency - just a change to the standalone.xml setting).
However, it failed because the "/bulk" API isn't available under /deprecated. So if anyone has a client that wants to talk to the old inventory, they need to know WHICH API was deprecated (feeds/ deprecated, bulk/ was not) and ONLY change those calls to use the /deprecated URL (e.g. change the code to use /entity/feed, but leaving /bulk alone). Which kinda sucks because now you have to pinpoint what calls need to change in the code and change code - when it would be much easier to simply be able to change a configuration setting and not have to change or recompile/build any code - you can just use the old client as is with the config change.
In other words, if I have an inventory client wants to use the old inventory API, it should switch to "/deprecated" URL and expect it all to work as before.
10 years
