[EnMasse] Dispatch router metrics to hawkular

David Ingham dingham at redhat.com
Mon Mar 27 07:52:39 UTC 2017


I'm not sure if you're all on the Hono list but this topic is currently
active over there too - see attached. It be great if we could recommend
something for the Hono guys that is in line with our thinking in EnMasse
before some completely different approach gets adopted.

-----Original Message-----
From: enmasse-bounces at redhat.com [mailto:enmasse-bounces at redhat.com] On
Behalf Of Ulf Lilleengen
Sent: 27 March 2017 08:46
To: enmasse at redhat.com
Subject: [EnMasse] Dispatch router metrics to hawkular

Hi,

I have been working on exporting metrics from EnMasse, and have this working
for Artemis (using jolokia). I would also like to export metrics from the
qpid dispatch router.

Exposing metrics to the hawkular agent is either done using jolokia,
prometheus or custom JSON. Jolokia is mostly relevant for java components,
and custom JSON is ... custom.

Prometheus has a nice python library that can be used for exposing metrics
over an http interface that will be polled every X seconds by the hawkular
agent (running on all hosts). So here are a few alternatives for exposing
the metrics:

a) A component running in the admin pod that will export metrics for all
routers (using AMQP management to collect them from all routers)
b) A component running alongside each router that will report metrics for
that router only (using AMQP management to collect them)
c) As alternative b), but as a compile-time plugin for the router

I think a) could be useful for both reporting metrics and as an API for the
enmasse console. The disadvantage I think would be that metric collection
depends on a single component that could limit the scalability in a large
network and possibly impact the other AMQP traffic. It would also be working
differently from broker metrics reporting and (likely) other enmasse
components.

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) in each router pod.

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 I have a hunch that having a http interface
integrated like that is controversial in AMQP-land :)

wdyt?

--
Ulf

_______________________________________________
enmasse mailing list
enmasse at redhat.com
https://www.redhat.com/mailman/listinfo/enmasse
-------------- next part --------------
An embedded message was scrubbed...
From: "Hudalla Kai \(INST/ECS4\)" <kai.hudalla at bosch-si.com>
Subject: Re: [hono-dev] Metrics
Date: Mon, 27 Mar 2017 08:43:42 +0100
Size: 7800
URL: <http://listman.redhat.com/archives/enmasse/attachments/20170327/87bb0707/attachment.eml>


More information about the enmasse mailing list