[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Hi,
I have been working on exporting metrics from brokers EnMasse, and was
just proposing a few alternatives for exporting metrics from the Qpid
Dispatch Router [1]. Since hono is using many of the same components as
EnMasse, it would be great to hear you're thoughts on this as well.
Since EnMasse runs on OpenShift, being compatible with hawkular is
important. Although hawkular itself works well with dropwizard, a common
way to export metrics is through a hawkular openshift agent. The agent
runs on all hosts and can be configured to pull metrics from either
jolokia, prometheus or custom JSON endpoints every N seconds. Jolokia is
mostly relevant for java components, and custom JSON is ... custom. It
might also be that other endpoints like dropwizard is supported in the
future.
Prometheus has a nice python library that can be used for exposing
metrics over http, and I'd like to explore this option further. Here are
a few alternatives I proposed for exposing the metrics for the router:
a) A component running centrally that collects and exports metrics for
all routers (using AMQP management to collect)
b) A component running alongside each router that will report metrics
for the co-located router only (using AMQP management to collect locally)
c) As alternative b), but as a compile-time plugin for the router
I think a) has the disadvantages of "monitoring AMQP over AMQP". Metrics
collection would also depend on a single component that could limit the
scalability in a large network and possibly impact other AMQP traffic.
It would also be working differently from how we report metrics from
other components in EnMasse.
b) is probably the quickest way to get something working. It only
involves talking over the local interface, and leaves scalability
concerns of metric collection to hawkular. The disadvantage is that we
have to run an extra container (although very light-weight) for each router.
I think c) would benefit additional users deploying the dispatch router
themselves and that wants to use it with prometheus-compatible
monitoring tools. At the same time having a http interface in the router
might be controversial and a longer process to get integrated.
[1] https://www.redhat.com/archives/enmasse/2017-March/msg00009.html
On 22. mars 2017 13:55, Pellmann Marc (INST/ECS4) wrote:
Hi Christian,
thank you, for your input! I also thought about the management extension
from AMQP - qpid router uses this, too. I could imagine that one writes
a AMQP management reporter for Dropwizard Metrics, if this is needed.
But I would expect, that something like Graphite or Amazon Cloud Watch
would be the first candidate in typical installations?!
Mit freundlichen Grüßen / Best regards
*Marc Pellmann*
Bosch Software Innovations GmbH
INST/ECS4
Schöneberger Ufer 89-91
10785 Berlin
GERMANY
www.bosch-si.com
Registered office: Berlin, Register court: Amtsgericht Charlottenburg,
HRB 148411 B
Executives: Dr. Ing. Rainer Kallenbach, Michael Hahn
------------------------------------------------------------------------
*Von:* hono-dev-bounces@xxxxxxxxxxx <hono-dev-bounces@xxxxxxxxxxx> im
Auftrag von Renz Christian (INST/ESW INST/ECS7)
<christian.renz@xxxxxxxxxxxx>
*Gesendet:* Mittwoch, 22. März 2017 13:40
*An:* hono developer discussions
*Betreff:* Re: [hono-dev] Metrics
Hi Marc,
IMHO, this is a very good idea and a necessary feature. Looking at the
usage perspective, it might be interesting to differentiate between
developer monitoring (“printf debugging”) and production monitoring.
From a developer perspective, I like how many MQTT brokers make internal
metrics easily available under the $SYS/ topic structure. One idea to
combine both could be to make monitoring data available through standard
metrics/logging frameworks, as you suggest, and additional publish it
into either a certain topic structure like $SYS, or even into a system
tenant (although that would limit the use of Hono across several
unrelated tenants).
HiveMQ has some interesting thoughts why $SYS is a bad idea for
production monitoring of MQTT brokers, although most of these can be
adressed with configuration and/or access control changes:
http://www.hivemq.com/blog/why-you-shouldnt-use-sys-topics-for-monitoring/
Regards,
Christian
--
*Christian Renz*
Bosch Software Innovations GmbH
Development Core Products (INST/ESW)
Schöneberger Ufer 89-91
10785 Berlin
GERMANY
www.bosch-si.de
www.blog.bosch-si.com <http://www.blog.bosch-si.com/>
Registered office: Berlin, Register court: Amtsgericht Charlottenburg,
HRB 148411 B
Executives: Dr.-Ing. Rainer Kallenbach; Michael Hahn
*Von: *<hono-dev-bounces@xxxxxxxxxxx> im Auftrag von "Pellmann Marc
(INST/ECS4)" <Marc.Pellmann@xxxxxxxxxxxx>
*Antworten an: *hono developer discussions <hono-dev@xxxxxxxxxxx>
*Datum: *Mittwoch, 22. März 2017 um 13:27
*An: *"hono-dev@xxxxxxxxxxx" <hono-dev@xxxxxxxxxxx>
*Betreff: *[hono-dev] Metrics
Hi,
I would like to propose the introduction of metrics in Hono - e.g. the
number of connections etc. It should be easily extend-able and since we
want to scale out horizontally we need to collect the metrics over all
instances - a push system might fit well.
Since Hono built on Vert.x, I looked into it, for possibilities to
instrument Hono metrics. It turns out, that Vert.x has a metrics module
for there own metrics but no API to collect custom metrics. For there
own metrics they have two implementations - one with Dropwizard Metrics
(default) and an other with Hawkular - encapsulated over an SPI.
I think for our Hono application it might be overkill to also implement
different metrics providers. I think it would be fine to just use
Dropwizard Metrics, which has different reporters to send the
metrics to e.g. Graphite, Ganglia (or also Hawkular and Prometheus) or
just use JMX or logger for development.
There would be also the option to use Spring Boot Actuator, which has
there own, more abstract metrics (which will be mapped to Dropwizard
Metrics, when in classpath). But for this, Hono would depend on Spring
Boot Actuator directly in core code, which is not so nice.
Any thoughts about this or experiences with metrics frameworks?
Mit freundlichen Grüßen / Best regards
*Marc Pellmann*
Bosch Software Innovations GmbH
INST/ECS4
Schöneberger Ufer 89-91
10785 Berlin
GERMANY
www.bosch-si.com
Registered office: Berlin, Register court: Amtsgericht Charlottenburg,
HRB 148411 B
Executives: Dr. Ing. Rainer Kallenbach, Michael Hahn
_______________________________________________
hono-dev mailing list
hono-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/hono-dev
--
Ulf
