<commit_before>---
title: Monitoring NServiceBus Endpoints
summary: Introduction on NServiceBus endpoints monitoring approaches and tools
tags:
- ServicePulse
- Monitoring
- Audting
- Service Level Agreement
- Heartbeat
---
Monitoring in NServiceBus is easier than in regular three-tier systems due to the use of queuing and message-based communication. Given the fact that generally messages are an atomic piece of information that drives the system we can say that it is enought to know where a message comes from, what it has changed, as a consequance of the handling process, and finally where it is going.

This article will cover the following topics:

* Monitoring primers;
* Service Level Agreement;
* Performance Counters;
* Audit and Error queues;
* ServicePulse;
* Heartbeat and Checks;

##Monitoring Primers

When a system is broken down into multiple processes monitoring becomes a key aspect not only from a system maintenance, DevOps, point of view, but also from the system behavior point of view. Losing control of what the system does and why the system behaves in a certain way can rapidly become a problem hard to manage.

NServiceBus monitoring tools and practices levarage the intrinsic power that a messaging architecture brings to the table to allow an easy and powerfull monitoring process.

When a system is a messaging based system you can quickly identify which process is the bottleneck by examining how many messages are in each queue; you can quickly understand where a message is stuck and why and you can quickly indentify reasons that caused a message to be delivered to a specific endpoint by tracking its route from the beginning to the end.

##Service Level Agreement

A SLA, as the name implies, is an agreement between the involved parts. When speaking about endpoints and messages a SLA is a mean to express that a given endpoint must consume, handle in NServiceBus terminology, messages within a given amount of time, otherwise the SLA itself is not respected.

##Performance Counters

Performance Counters are one of the NServiceBus monitoring foundation, Operating System level counters allows us to identify bottlenecks in our endpoints by examining how many messages (on average) are 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, you can't know how long messages are waiting in each queue, which is 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 performance counters
<commit_msg>Fixing typo<commit_after>---
title: Monitoring NServiceBus Endpoints
summary: Introduction on NServiceBus endpoints monitoring approaches and tools
tags:
- ServicePulse
- Monitoring
- Audting
- Service Level Agreement
- Heartbeat
---
Monitoring in NServiceBus is easier than in regular three-tier systems due to the use of queuing and message-based communication. Given the fact that generally messages are an atomic piece of information that drives the system we can say that it is enought to know where a message comes from, what it has changed, as a consequance of the handling process, and finally where it is going.

This article will cover the following topics:

* Monitoring primers;
* Service Level Agreement;
* Performance Counters;
* Audit and Error queues;
* ServicePulse;
* Heartbeat and Checks;

##Monitoring Primers

When a system is broken down into multiple processes monitoring becomes a key aspect not only from a system maintenance, DevOps, point of view, but also from the system behavior point of view. Losing control of what the system does and why the system behaves in a certain way can rapidly become a problem hard to manage.

NServiceBus monitoring tools and practices levarage the intrinsic power that a messaging architecture brings to the table to allow an easy and powerfull monitoring process.

When a system is a messaging based system you can quickly identify which process is the bottleneck by examining how many messages are in each queue; you can quickly understand where a message is stuck and why and you can quickly identify reasons that caused a message to be delivered to a specific endpoint by tracking its route from the beginning to the end.

##Service Level Agreement

A SLA, as the name implies, is an agreement between the involved parts. When speaking about endpoints and messages a SLA is a mean to express that a given endpoint must consume, handle in NServiceBus terminology, messages within a given amount of time, otherwise the SLA itself is not respected.

##Performance Counters

Performance Counters are one of the NServiceBus monitoring foundation, Operating System level counters allows us to identify bottlenecks in our endpoints by examining how many messages (on average) are 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, you can't know how long messages are waiting in each queue, which is 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 performance counters

{'fraction_non_alphanumeric': 0.027617549379479113, 'fraction_numerical': 0.0, 'mean_word_length': 4.815040650406504, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 3, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '3518506', 'n_tokens_mistral': 1275, 'n_tokens_neox': 1222, 'n_words': 881}