Diagnostics HTTP listener #94

Closed
mookid8000 opened this Issue May 10, 2012 · 13 comments

Projects

None yet

4 participants

@mookid8000
Member

It would be awesome if a RebusBus had some kind of diagnostics endpoint that could possibly be accessed at localhost/inputQueueName where information about available handlers etc could be accessed

@mookid8000
Member

Having thought a little bit about this, I think it's clear that HTTP stuff should never enter the Rebus core.

It could be nifty though, if MEF entered the core, allowing bundles to be picked up. This would allow for e.g. a HTTP diagnostics endpoint to be activated, allowing for interrogating an endpoint with a webbrowser.

Other stuff could be picked up as well :)

@ssboisen
Contributor

What kind of information do you imagine would be available to the plugin? I would be interested in implementing this functionality with MEF including a selfhosting http-server which would be able to supply whatever information would be available through the API offered by Rebus.

Off the top of my head cool functionality could be:

  • Inspection of the queues on said node hosting the http-server - sorta like a webbased snoop?
  • Graphs which shows the flow of message throughput over time through the webinterface. This would probably require the pluging to be able to access information about when new messages arrive or can this type of temporal information be deducted directly from the queues? - Something like this might be nice to have in order to predict future spikes in trafic and thus do whatever is necessary to scale?
  • Maybe the plugin should be able to register itself as a IHandleMessage so every single message gets dispatched to the plugin?

    Or am I misunderstanding what the purpose of the plugins would be?

@asgerhallas
Contributor

I've been thinking about exactly this for some time now, but have not had time to do anything about it. It would be very cool (and useful and improve transparency in production and ease operation) to have something like this.

A few random thoughts on features in no particular order, not thought through and possibly overreaching :)

  1. It would be nice if in addition to inspection of queues, one could move messages from error-queue to source-queue.
  2. Would it be viable to have several nodes register at some "central" node, so you could watch multiple nodes at the same time in the same user interface? That could make for some real interesting visuals of message flow. I'm not sure that should be the default, though.
  3. I could be nice to have access to the logs for a node too - and if there actually was some central user interface, it would bring a lot of transparency to watch several nodes' logs at the same time.
  4. Should the plugin actually use regular handlers? What if the plugin handler throws? I'd rather let it do something outside the transaction. As I see it, none of the information required is so urgent it can't wait 'till after the commit.
  5. Sagadata for a particular message in the error queue.
  6. Overview of message ownership and subscribers.

I hope that wasn't too random.

@mookid8000
Member

Well.... start out by thinking of that one single feature that you would like the most when you're doing your work with Rebus ... there's an awfull lot being mentioned here! :)

One thing that sounded extremely interesting to be though, was if Rebus endpoints could do something like this:

Configure.With(yaddayadda)
    .AllowInterrogation()
    .Etc

which would cause the Rebus endpoint to e.g. use ZeroMQ UDP to make a central service aware of its existence, which in turn would cause that central service to start watching that Rebus endpoint, periodically asking it for statistics and stuff like that.

This would allow for creating a cool control panel where all of your Rebus services could be watched.

Just a thought :)

@mookid8000
Member

Some of the most relevant pieces of info would be:

  • which endpoint mappings does the service have? And some way of spotting whether another service is actually feeding off of each endpoint... this way, it would be easy to spot dead ends
  • is errorQueueMessageCount > 0? (RED ALERT!!!11)

Another thing I though about was stuff like a historized graph of input queue length, average message-time-in-queue, stuff like that, but these things are probably much better expressed with WIndows performance counters...

@asgerhallas
Contributor

Yep, just wanted to unload some ideas to enable some focus :)

Such a facility that makes Rebus shout out about it's existence, do yout think it should be baked in or come in the form of MEF extensibility?

@mookid8000
Member

It would probably be best if the existing hooks and extensibility points could be used...

@asgerhallas
Contributor

@ssboisen and @mookid8000 are you showing up for the next hackernight? :)

@asgerhallas
Contributor

"It would probably be best if the existing hooks and extensibility points could be used..."

I think so too...

@ssboisen
Contributor

I won't since it was moved to the 5. of september which is the day my girlfriend hands in er master thesis - unfortunately :)

@mookid8000
Member

I will be hacking in the night, yes

@mookid8000
Member

This task is rendered redundant and uninteresting by the sheer awesomeness of the FleetKeeper (described in #140)

@mookid8000 mookid8000 closed this Oct 11, 2012
@rasmuskl
Contributor

Aw - and here I was awaiting the glory of BusDriver to report back to the FleetKeeper.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment