Contents

• Getting Started
•     Overview
•     Architectural Principles
•     Transactions

• Samples
•     Web App Integration
•     Web App - Asp.Net Mvc3 Integration
•     Encryption
•     Full Duplex - Request/Response
•     Generic Host - Logging
•     PubSub
•     Versioning
•     Message Mutators
•     Unobtrusive
•     Data Bus
•     Scale Out

• Day to Day
•     Dependency Injection
•     Support for child containers
•     Logging
•     Messages as Interfaces
•     Introducing IEvent and ICommand
•     Unobtrusive mode messages
•     Unit Testing
•     One way/Send only endpoints

• Hosting
•     In Your Process
•     NServiceBus Host
•         Profiles
•     32-bit (x86) Host Process

• Management and Monitoring
•     Auditing
•     Monitoring
•     Msmq Information

• Scaling Out
•     Performance Information
•     Multi-Site with the Gateway
•         More about the Gateway
•     Multi-Server with the Distributor
•     Unit of work in NServiceBus 3.0
•         Unit Of Work implementation for RavenDB

• Publish-Subscribe
•     Overview
•     API and Configuration

• Long-Running Processes
•     Sagas

• Customization
•     Customizing Configuration

Monitoring NServiceBus Endpoints

Monitoring in NServiceBus is easier than in regular 3-tier systems due to its use of queuing.

When a system is broken down into multiple processes each having its own queue, we can quickly zoom in on which process is the bottleneck by looking at how many messages there are (on average) in each queue.

The only issue is that without knowing the rate of messages coming into each queue, and the rate at which messages are being processed from each queue, we can't know how long messages are waiting in each queue - the primary indicator of a bottleneck.

Unfortunately, despite the many performance counters Microsoft provides for MSMQ (including messages in queues, machine-wide incoming and outgoing messages per second, and the total messages in all queues) there is no built-in performance counter for the time it takes a message to get through each queue.

NServiceBus "Critical Time" Performance Counter

As a part of the NServiceBus installation, a new performance counter called "Critical Time" is added underneath the new "NServiceBus" category. All processes running with the NServiceBus Host collect this information but if you want them to expose it you need to include "NServiceBus.PerformanceCounters" as one of the arguments to the host process. You can find more information on how to do this here.

Since all performance counters in Windows are exposed via Windows Management Instrumentation (WMI) it is very straightforward to pull this information into your existing monitoring infrastructure.

Best Practices

If the system being monitored was designed according to the NServiceBus best practice of having each process (and by corollary each queue) handle only a single message type, you could then know how long each type of messages is waiting in the system.

This would enable you to provide the business with information on a use-case by use-case basis.
The business could, in turn, specify SLA requirements per use case which could then be monitored.

Based on this information, each process could be scaled independently using the distributor to make sure it stays within required service levels. This is Business Service Management (BSM) at its finest.