The new pricing plans of NServiceBus come with limits on daily message throughput.
What would be the best way of monitoring the daily throughput? Any recommendations?
Logging?
Auditing + “Search by date” in ServiceInsight?
Given that auditing is enabled for all receive endpoints, would the number of messages passing through the audit queue during a day be “an accurate” metric?
Customers that are NOT running ServiceControl monitoring
If customers are not running ServiceControl monitoring in their production environment, we count endpoints and measure throughout using transport-specific techniques.
For broker-based transports, we estimate the number of logical endpoints by counting the queues in the broker.
For MSMQ, we still count the queues but we may need to ask additional questions in order to translate those numbers into a count of logical endpoints. E.g. is the customer using a distributor or sender-side distribution?
In both cases, it would be handy to get the full list of queue names (as we can do some processing on them later) but if the customer does not want to provide them then a count is OK.
Each transport also has it’s own way of measuring throughput.
See the documentation for the transport the customer is using:
MSMQ
SQL
RabbitMQ
Azure Service Bus (including the .NET Standard version)
In general, I think this is a good solution. However, in our future setup, I foresee big bursts of messages at times where it’s hard to be present and monitor it.
We are using Azure Service Bus as transport, where there’s quite good message throughput metrics. Might be possible to look at outgoing messages (I assume this means messages where a processing attempt has been made) for all non-NServiceBus-platform queues? Some messages might fail and be retried later, of course, so it won’t be 100% correct.
Anyways, it would be a nice addition to ServiceControl and ServicePulse to track and present the message throughput per day, the last X days. Just a counter that is. Might submit an improvement issue for this on GitHub.