http://www.codeplex.com/NSBManagement 

Here is the link to the project. At the moment I only have an Endpoint Monitoring & Status Reporting piece and a Server piece to fire events if an endpoint stops sending heartbeats as well as to aggregate and re-broadcast performance metrics sent by the endpoints. As for reporting performance endpoints can define pluggable "IEndpointStatusProbe" classes to take and send measurements. I created a simple PerfCounterProbe that you can configure in the app.config that will sent Performance Counter results from the local computer.

The best way to see what is going on is to play with the Samples - I have a win forms app for each of three types of endpoints - a Managed Endpoint that is reporting status, a Monitor Server endpoint and a Monitor Client endpoint to consume and display the events broadcast by the server.

--- In nservicebus@yahoogroups.com, "Symon Rottem" <s.rottem@...> wrote:
>
> I'd be interested to see that. Please do notify when you've put it up.
>
> Cheers,
>
> Symon.
>
> On Fri, May 16, 2008 at 8:07 PM, Nathan Stults hereiam@... wrote:
>
> > Well, you're probably right that such things don't belong in the bus
> > itself, but I believe they still have a place in a satellite open source
> > project. J What is exciting to me about NSB is that it is open source,
> > rather simple, and you can use it to easily and quickly get a nice
> > asynchronous messaging system up for a project of virtually any size or
> > budget. I come from the SMB world and a lot of times the big expensive tools
> > aren't realistic for our customers (or us, for that matter). Not only that,
> > my monitoring needs are probably simple enough such tools aren't warranted.
> > I would like my endpoints to have a heartbeat, and I'd like the system to
> > let someone know if the heartbeat stops, and I'd like to know how many
> > messages my endpoints are processing and how quickly. That is about it.
> >
> >
> >
> > But beyond just monitoring, I want to go to a dashboard and see a list of
> > all my endpoints, named appropriately and with pretty green or red
> > indicators of health J. I would like to know when they go online and when
> > they go offline, and I'd like to be able to send them simple commands from a
> > single location (like why don't you log your messages for a while). I'd also
> > like a simple service registry so I know what kinds of services are living
> > in my little service world and what they do, what kinds of messages they
> > accept, what kind of events they publish, and what endpoints they have and
> > what their addresses are. Even though my service / endpoint count is likely
> > to be quite low, relatively speaking, I don't feel in control of the bigger
> > picture with all these autonomous services flaunting their own authority,
> > without being able to automatically keep track of them all in one place.
> >
> >
> >
> > I have no big-enterprise experience, so this kind of thing is probably
> > handled with big tools and heavy customization in that space, but speaking
> > from a different place having a set of reasonable, out-of-the box, tweak em
> > if you need to tools for these kinds of tasks would be pretty enticing,
> > especially if they too are open source, free and modifiable to suite my
> > particular needs.
> >
> >
> >
> > Anyway, I've started a little project to provide a generic implementation
> > for a shadow of these features (heartbeat, simple status / health /
> > performance reporting and a health monitoring / status report aggregation
> > server (service)) and will probably be adding more stuff later over time
> > like a transport with a processing pipeline, a service/endpoint registry
> > service, etc. It uses .NET 3.5 and the latest trunk version of NSB (such as
> > the multiple-message-handlers-per-class stuff) so it probably isn't so "out
> > of the box" for many people, but I'll throw it up on codeplex soon in case
> > anyone might find it useful (or would like to contribute).
> >
> >
> >
> > *From:* nservicebus@yahoogroups.com [mailto:nservicebus@yahoogroups.com] *On
> > Behalf Of *Udi Dahan
> > *Sent:* Friday, May 16, 2008 5:13 AM
> > *To:* nservicebus@yahoogroups.com
> > *Subject:* RE: [nservicebus] Re: Storing Messages for
> > Troubleshooting/Replay
> >
> >
> >
> > I've had the thought of creating such an infrastructure having done
> > something similar a couple of times, in a couple of different ways for
> > various clients. It's a non-trivial undertaking and leads to companies
> > searching for a different support model than the current open-source-y-ness
> > of nServiceBus.
> >
> >
> >
> > In other words, it's about creating products.
> >
> >
> >
> > That's a bit different than what nServiceBus is.
> >
> >
> >
> > Just for a bit of background about the name "nServiceBus", I thought you
> > might like this:
> >
> >
> >
> > The letter "n" at the beginning, so common in .NET open source projects,
> > has the same pronunciation as the Hebrew word "אין", written "Ein", which
> > means "non existent", or when put before something, "there is no…".
> > Therefore, nServiceBus would mean, in the Matrix kind of way:
> >
> >
> >
> > There is no service bus.
> >
> >
> >
> > But I digress.
> >
> >
> >
> > Since the way you'd monitor such a system would depend on the actual
> > technologies used, and since monitoring tools for these technologies are
> > already provided by big companies (like CA), why would you want to implement
> > your own?
> >
> >
> >
> > --
> >
> > Udi Dahan - The Software Simplist
> >
> >
> >
> > *From:* nservicebus@yahoogroups.com [mailto:nservicebus@yahoogroups.com] *On
> > Behalf Of *nstults
> > *Sent:* 07 May 2008 20:35
> > *To:* nservicebus@yahoogroups.com
> > *Subject:* [nservicebus] Re: Storing Messages for Troubleshooting/Replay
> >
> >
> >
> > I'm seeing a pretty common theme in recent questions to this forum
> > regarding the managment/monitoring aspects of a messaging system and
> > how they are or could be implementing using NServiceBus. From central
> > endpoint configuration to endpoint "heartbeats" and performance
> > notifications to message recording / tracing / whatever. It feels to
> > me that there may be quite a few users or potential users of
> > NServiceBus who would greatly benefit from a fairly robust management
> > system that could provide some of the same kinds of candy Neuron
> > offers. The ever so famous Enterprise Integration Patterns book
> > outlines a number of great patterns that could be easily implemented
> > for this system that would be universally applicable int its
> > Management and Monitoring chapter.
> >
> > As Udi says elsewhere, it's "just NServiceBus programming", but from
> > where I sit it's also infrastructure - not something that needs to be
> > created over and over again or heavily customized per domain.
> >
> > Anyway, my rambling point is that in our shop we're going to have to
> > start creating this stuff anyway, as I imagine others of you out
> > there are too - is anyone interested in collaborating on a set of
> > NServiceBus extensions to add a generic and reasonably extensible set
> > of bus management & monitoring capabilities to NServiceBus so we all
> > don't have to build everything from scratch?
> >
> > --- In nservicebus@yahoogroups.com <nservicebus%40yahoogroups.com>,
> > "William C. Pierce"
> > wcpierce@ wrote:
> > >
> > > Hey Udi,
> > > In your recent InfoQ article "Spectacular Scalability with Smart
> > Service
> > > Contracts" you mention that after you transitioned your system to
> > something
> > > more stateful you ran tests "using the messages we recorded from the
> > > previously unsuccessful launch." What mechanism did you use to
> > record all
> > > messages? Did you forward a copy of all messages to some sort
> > of "log"
> > > queue and then use a replay runner to re-send them back to your
> > > server/distributor? Or simply persist them to the file system or
> > database?
> > >
> > > I see great value in recording messages for audit/instrumentation
> > purposes
> > > as well as being able to recreate usage scenarios in a test
> > environment.
> > > Just looking for a little direction.
> > >
> > > -Bill
> > >
> >
> >
> >
> > No virus found in this incoming message.
> > Checked by AVG.
> > Version: 7.5.524 / Virus Database: 269.23.9/1416 - Release Date: 05/05/2008
> > 17:11
> >
> >
> >
>
>
>
> --
> Symon Rottem
> http://blog.symbiotic-development.com
>