Despite this adding another thing to install and coordinate (HJA), it seems like it could work.  The discovery and all the config support is already impl'd in HJA, so no need to redo it in HOSA.  And adding new endpoint support shouldn't be too big.  HJA in HOSA mode couldn't/shouldn't cache too much, right?  The inventory is likely not huge and is already in memory, but metrics that aren't consumed quickly should likely be discarded.  I agree with Micke, we (and by we I probably mean Joel) should add required inv support in the GoLang client, similar to what we already have in the ruby client and some Java "helpers".  HJA would not have any ability to push to HOSA, right?  So changes in inventory would likely have a [short] delay before being pulled by HOSA.
On 4/26/2017 4:12 PM, John Mazzitelli wrote:
Because Origin Metrics is locked down. Without special privileges (that only HOSA and Heapster have) no one can write to the Origin Metrics that is installed in the OpenShift cluster.

And, yes, we asked. :) This was plan B.

----- Original Message -----

I would have replied to my own mail, but I have no idea where it's
actually surfing at the moment. Perhaps it's using NCSA Mosaic to load
Gmail.

In any case, second thing, why is only HOSA allowed to contact the
metrics and not the Java-agent? Perhaps we should also consider allowing
it to report directly to the metrics instance (both ways could be
supported).

   -  Micke


On 04/26/2017 07:35 PM, John Mazzitelli wrote:

The first use-case for needing HOSA to collect and store inventory has come
in - from the Fuse team, specifically. This email is going to explain the
current plan to get this to happen. Feel free to chime in with thoughts.

Right now, HOSA does not support collecting and storing inventory. HJA (and
HWFA) supports collecting and storing inventory along with metrics.

HOSA has the privileges necessary to write directly to Origin Metrics. HJA
does not.

We need to combine these to get what we need (and we need this soon because
Fuse needs it).

Currently, the idea is:

a) HJA will have a new storage adapter mode "HOSA" (right now it has
"HAWKULAR" and "METRICS" - the former is to support running with a full
hawkular server such as when running within CloudForms and the latter is
for when running with just a H-Metrics server). With this new HOSA mode,
HJA will not store metrics or inventory directly into H-Metrics. Instead
it will "cache" the data and wait for HOSA to come and ask for the data.

b) HOSA will have a new endpoint type "hawkular" (right now it has
"prometheus" and "jolokia" and "json"). This new type will tell HOSA to
read data from some HJA (which will including inventory data) and HOSA
will simply pass that data on to Origin Metrics. HOSA will read both
metrics and inventory from HJA and HOSA will store that data directly to
Origin Metrics essentially making HOSA a proxy to Origin Metrics.

I don't know if HOSA will decorate the data with its own metadata (like
tags and things) or if it will truly be a pass-through. I suspect HOSA
will need to massage the data it gets from HJA to ensure the data IDs are
unique across the OpenShift cluster and things like that.

That's the overall idea. I'm sure there are going to be stumbling blocks
along the way that is going to force us to change some things around. But
at a high level, I think it should work. HJA caches inventory and metrics
rather than writing directly to an H-Metrics server - and HOSA will
collect that cached data in HJA and it will be the one to store it in
Origin Metrics.
_______________________________________________
hawkular-dev mailing list
hawkular-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev

_______________________________________________
hawkular-dev mailing list
hawkular-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev


_______________________________________________
hawkular-dev mailing list
hawkular-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev