<div dir="ltr"><div>Hi, all! </div><div><br></div><div>My name is Anton Okolnychyi. I am keen on participating in GSOC 2016. That&#39;s why I am trying to gather relevant information to write a nice proposal for a &quot;Hawkular-agent for vert.x&quot; project on GSoC 2016. </div><div><br></div><div>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&#39;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&#39; capabilities. In particular, enable reporting to the Inventory service of Hawkular. </div><div><br></div><div>As a result of my research, I have some questions. It would be great if someone can answer them.</div><div><br></div><div>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&#39;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.</div><div><br></div><div>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. </div><div><br></div><div>Thanks in advance! Any help is highly appreciated!</div><div><br></div><div>Sincerely,</div><div>Anton Okolnychyi</div></div>