I'm looking for the owner of the OpenShift namespace 'hawkular'. To
check if you own it, open the following URL and check the "Domains"
part. In my case, I see only "jpkroehling".
With the recent repackaging effort + the ManageIQ UI, we need to rethink
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,
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)
yesterday I successfully defended my thesis . I would like to thank to
everyone from Hawkular team who helped me with the problems I was facing.
Last but not least I would like to thank to company Red Hat for the
opportunity to work on this project.
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
Thanks in advance.
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.
"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.
In the client (instrumented) environment, Hawkular APM uses the ServiceLoader to obtain implementations for various components. This enhancement introduces a 'ServiceStatus' check, to determine whether an implementation is suitable to be returned (i.e. has all the config it needs).
This will enable the client to be packaged with multiple implementations of a particular interface, and enable selection of the appropriate impl at runtime based on the configuration (e.g. environment variables).
I am back to tell what is new going on in Android client of Hawkular
- Old metrics related classes modified to adjust metric from explorer
- Metric data is now fetched in terms of buckets
- Metric chart fragment now contain list to choose time limits
- Some other beutififation related to axis lables
Last but not the least Aerogear Pipe for android is modified to handle
special symbols in path param of REST call.
As always there is a visual video to enjoy the progress
What is next :-
- Most changes are added to only Gauge type at present and will be
extended to others after acceptace
I'm pleased to announce that Hawkular APM 0.9.0.Final has been released. The main purpose of this release is the rename of the project from BTM (Business Transaction Management) to APM (Application Performance Management), to reflect the wider scope of the project's capabilities.
This is the first release under the new project name, and consequently there are a number of naming related changes (e.g. REST endpoints, Java package/class names, model, etc) that mean this release is not backward compatible with the previous release.
The details of the release can be found here: https://github.com/hawkular/hawkular-apm/releases/tag/0.9.0.Final
As part of this release, we have also moved the documentation for the project to gitbook: https://hawkular.gitbooks.io/hawkular-apm-user-guide/content/