Flower: Ability To Monitor Multiple Brokers?

Created on 31 Jul 2013  路  19Comments  路  Source: mher/flower

Is there anyway I could use one flower instance to monitor Multiple Brokers?

I have a live and production environment and I wanted to monitor both of my brokers on a single flower instance. Is this possible? Or should I stick to different queues ?

enhancement

Most helpful comment

馃憤 this is a pretty essential feature IMO, especially for 'largish' projects that want to shard their application responsibilities (i.e. micro-services) up into smaller pieces

All 19 comments

Flower doesn't support multi-broker monitoring

Is this still the case?

yes

If I were inclined to contribute code to fix that, would you be interested in that? How heavy a project might it be?

I'll be glad to merge your PR or help to implement it. Multi broker support is not a trivial fix. It will require refactoring in many places.

Could somebody name those places?

Hi, anyone know if this turned into anything? Multiple broker support would be a massive +

I am working on a paas project, in production, more than 500+ celery(in docker), use same rabbitmq with different vhost....and then, I need to figure out how to manage all the workers and tasks.

Is someone working on this?

I setup a demo to monitor multi broker.

https://github.com/wklken/flower

recv.capture(limit=3, timeout=None, wakeup=True)

and, in app __init__, I add 10 cname - celery.Celery(broker=xxxx) to a dict called capp_dict,
in Events loop, I change the code and add gevent

                threads = []
                for cname, capp in self.capp_dict.iteritems():
                    event_handler = partial(self.on_event, cname)
                    threads.append(gevent.spawn(run_capture, capp, event_handler))
                gevent.joinall(threads)

result: 10 brokers, each loop receive 3 events, task 0.2s.

I am not so familar with celery and tornado, any good ideas?

Currently, Events is one thread with gevent, I am thinking about how to make it take less time.(If I have 500 brokers, each loop will take 100s, unacceptable).

I need some advices:_)

Hey @wkiken / do you think you could share some tip (documentation) on how to setup multiple brokers with your fork ? Even if I have to hardcode something like you suggest that would be great.

I have 4 brokers (runnning on 4 machines) that I'd like to monitor.

@bsergean
flower just support one broker url, I modified some code use gevent to monitor the event of multiple brokers, but I got 500+ brokers....It does not work well.
finally, I install flower on every docker. and export the api via the http sock file.

I would also love to monitor multiple brokers. @mher can you maybe send me a bit about where I would need to look to start making this modification? I'd really love to help out and contribute to make this able to monitor mulitple vhosts / brokers. Thanks!

@mher multiple people here offered help with this feature, and just asked for a stating point where to look at.
Do you think it's possible for them to accomplish it?
Thanks!

馃憤 this is a pretty essential feature IMO, especially for 'largish' projects that want to shard their application responsibilities (i.e. micro-services) up into smaller pieces

Is there anyone working on this feature? I just want to make sure if someone has already started working on this or not...

I setup a demo to monitor multi broker.

https://github.com/wklken/flower

recv.capture(limit=3, timeout=None, wakeup=True)

and, in app __init__, I add 10 cname - celery.Celery(broker=xxxx) to a dict called capp_dict,
in Events loop, I change the code and add gevent

                threads = []
                for cname, capp in self.capp_dict.iteritems():
                    event_handler = partial(self.on_event, cname)
                    threads.append(gevent.spawn(run_capture, capp, event_handler))
                gevent.joinall(threads)

result: 10 brokers, each loop receive 3 events, task 0.2s.

I am not so familar with celery and tornado, any good ideas?

Currently, Events is one thread with gevent, I am thinking about how to make it take less time.(If I have 500 brokers, each loop will take 100s, unacceptable).

I need some advices:_)

I setup a demo to monitor multi broker.

https://github.com/wklken/flower

recv.capture(limit=3, timeout=None, wakeup=True)

and, in app __init__, I add 10 cname - celery.Celery(broker=xxxx) to a dict called capp_dict,
in Events loop, I change the code and add gevent

                threads = []
                for cname, capp in self.capp_dict.iteritems():
                    event_handler = partial(self.on_event, cname)
                    threads.append(gevent.spawn(run_capture, capp, event_handler))
                gevent.joinall(threads)

result: 10 brokers, each loop receive 3 events, task 0.2s.

I am not so familar with celery and tornado, any good ideas?

Currently, Events is one thread with gevent, I am thinking about how to make it take less time.(If I have 500 brokers, each loop will take 100s, unacceptable).

I need some advices:_)

@wklken
Can you please provide the mentioned code? I checked your branches but it does not exist. It might be useful for our use case as we have only 2-3 brokers (not 500).

I'm confused how Flower works, so please bear with me, but for this multi-broker thing, can't we implement websockets? So the flow model for multiple brokers would be to have a load balancer (for me, on AWS, it'd be an Application Load Balancer) point to one instance/machine and have all celery brokers output their tasks via websockets to that one machine.

I've not used Flower that much, so this also could possibly not make sense... @mher

Just want to point out that my previous employer where we implemented flower, has recently ditched it completely. Mostly due to problems like this (and the fact that it doesn't scale for systems that consume millions of events per day)

There are no plans to work on this feature at the moment until someone decides to contribute to the project.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

pnijhara picture pnijhara  路  3Comments

ckcollab picture ckcollab  路  8Comments

Linux-oiD picture Linux-oiD  路  4Comments

jobec picture jobec  路  3Comments

Darkheir picture Darkheir  路  3Comments