Hi Anton,
You will find my answers inline.
Le 12/03/2016 23:52, Anton Okolnychyi a écrit :
Hi, all!
My name is Anton Okolnychyi. I am keen on participating in GSOC 2016.
That's why I am; trying to gather relevant information to write a nice
proposal for a "Hawkular-agent for vert.x" project on GSoC 2016.
Thanks to Thomas Segismont for his initial advice. I have analyzed the
existing functionality of the vertx-hawkular-metrics module, its current
features, and architecture. In addition, I have investigated Hawkular's
REST APIs of Metrics and Inventory services. Currently, the
vertx-hawkular-metrics module reports only to the Metrics service. The
idea that is available in the scope of GSOC 2016 is to enhance
vertx-hawkular-metrics' capabilities. In particular, enable reporting to
the Inventory service of Hawkular.
Exactly.
As a result of my research, I have some questions. It would be great if
someone can answer them.
1. Since the main goal of the project is to actually enable reporting to
the Inventory service, one should come up with an appropriate graph
architecture of Inventory which should contain resources(vertices),
relationships between them(edges) and optionally assigned metrics to
each resource (I am aware of many to many relationships here). The
vertx-hawkular-metrics module currently has metrics that cover the
following: datagram/udp, event bus, tcp, http client, http server.
That's why one can define the corresponding resources for these metrics
in the Inventory (e.g. Event Bus, Net Client, HTTP Client, Datagram
socket, HTTP Server, Net Server etc.). Will that make sense? Am I going
in the right direction? Alternatively, we can define a resource that
will cover several metrics at once. If you have anything that is
important to include as a resource in the Inventory, please, share that
with me.
I believe your model is correct:
Event bus resource has event bus metrics
NetClient resource has NetClient metrics
... etc
We might want to have event bus handlers as separate resources with
their own metrics.
2. The vertx-hawkular-metrics module collects only counters and gauges
and reports them via the POST request to /metrics/data (correct me if I
am wrong). Would it make sense/be interesting to also handle some
availability metrics? The Hawkular API allows to do that and the current
architecture of the vertx-hawkular-metrics is flexible enough to
integrate a new metric type quite easily. Probably, this question should
be asked on the vertx-dev list. But if someone knows the answer or has
any possible applications/suggestions in mind I would be glad to hear.
I can definitely answer that as I wrote the vertx-hawkular-metrics module :)
It would make sense to add availability metrics as well, yes. I didn't
include them in the current implementation because to me, they make
sense when you report to inventory as well. Otherwise it is not clear
what a resource is (and why it would be up/down/etc...).
Thanks in advance! Any help is highly appreciated!
Thank you for your interest!
Sincerely,
Anton Okolnychyi
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev