Is it possible to monitor event emitters / event listeners?

[NikkoJaca]

I was wondering if it is possible to monitor the event emitters (those who are emitted using the emit() facade), and as well as the event-listeners? I was trying to look at Laravel Horizon, but can't seem to monitor them through manually defined tags. Maybe there is another way other than Laravel Horizon?

Hoping for your positive feedback and any suggestions are appreciated! Thank you very much! 😄

[aibarra11]

are you needing it for production or development/debugging?

if its the later, you can just go into your redis server, redis-cli and use the MONITOR command. You can watch the XADD and XREADs scroll past. This is what i do during dev and even testing shared environments.

horizon looks at the queue. this is more on the streams functionality of redis. If you want to monitor this is production, that's a different story - you'll need to interact with Redis using the above method or create another service. Not sure if there's a way to dump everything that happening in Redis to a log.

hope that helps some

[prwnr]

This is how aibarra wrote.

It is more of a limitation of Redis, that its not providing any "good" way of getting the list of active streams. There are two ways of getting this out with what Redis currently provide - mentioned by aibarra MONITOR command that yields everything that happens in Redis and there you can watch over the rows and find XADD calls to see what streams got created. The other way is to periodically check keys * list, walk over the items and check the type of the key in Redis if its a stream.

With either option, you can find what streams "started" and from that place you can run php artisan streamer:listen command.

I personally am using the second option, with checking keys * periodically (of course with local in-memory cache of what keys I verified) and Im starting listener for each stream key that is not yet started (I had some problems with MONITOR option within my code, but I dont remember what was that exactly).

However, both options are rather not suggested for production - especially the monitor one as far as I know, cause it logs almost, if not, everything and that may be insecure.

if you are BRAVE enough, you can try to build locally my https://github.com/prwnr/swarm that I am using with my team for development. It does what I said above, watches over keys * and starts listener command for each one - with an option to re-start it if it "dies" - however IT IS BUGGY, but does what I need it for and unfortunately I dont have much time to fix the bugs.

For production I would suggest using supervisor with streamer listener jobs defined in it, but you will need to know what streams you want to listen to. I really hope that Redis will add a method to list all incoming streams names eventually.