|
1 | 1 | --- |
2 | 2 | title: How does ServiceControl work? |
3 | 3 | summary: An overview of how ServiceControl collects and processes messages and data from an NServiceBus system |
4 | | -reviewed: 2022-10-19 |
| 4 | +reviewed: 2025-02-14 |
5 | 5 | --- |
6 | 6 |
|
7 | | -ServiceControl is a background process that will collect and store data and make it available via an HTTP API to ServicePulse and ServiceControl. |
| 7 | +ServiceControl is a background process that will collect and store data and make it available via an HTTP API to ServicePulse and ServiceInsight. |
8 | 8 |
|
9 | 9 | > [!NOTE] |
10 | 10 | > The ServiceControl HTTP API may change at any time. It is designed for use by ServicePulse and ServiceInsight only. The use of this HTTP API for other purposes is not supported. |
@@ -57,16 +57,16 @@ graph LR |
57 | 57 |
|
58 | 58 | [Recoverability](/nservicebus/recoverability/) is an important feature in NServiceBus. It enables automatic retries and continuity within a system, as failed messages will be moved aside to allow other messages to be processed while the errors are investigated. Those error messages contain business data that must eventually be processed. |
59 | 59 |
|
60 | | -NServiceBus will move messages it cannot process to an [error queue](/nservicebus/recoverability/#fault-handling). This is where ServiceControl comes into play to consume these messages. ServiceControl will pick up the message and store it in an internal database. ServiceControl uses an embedded RavenDB instance for the internal database. After it is stored in the database, the message is made available to ServicePulse and ServiceInsight for visualization, retries, and other operations. |
| 60 | +NServiceBus will move messages it cannot process to an [error queue](/nservicebus/recoverability/#fault-handling). This is where ServiceControl comes into play to consume these messages. ServiceControl will pick up the message from the queue and store it in its RavenDb database. After it is stored in the database, the message is made available to ServicePulse and ServiceInsight for visualization, retries, and other operations. |
61 | 61 |
|
62 | 62 | > [!NOTE] |
63 | | -> It is recommended not to provide end-users with the ability to retry messages. The message could fail again and end up in ServiceControl once again. It could be even more problematic when many messages are retried during a peak in message processing. This will result in even more messages being processed by an endpoint, causing valid messages to be delayed even longer. |
| 63 | +> It is recommended not to provide end-users with the ability to retry messages. The message could fail again and end up in ServiceControl once again. It could be even more problematic when many messages are retried during a peak in message processing. This will result in even more messages being processed by an endpoint, causing valid messages to be delayed even longer. Potentially even more messages can fail due to locking in your saga persistence. |
64 | 64 |
|
65 | 65 | Find out more about [failed messages](/servicepulse/intro-failed-messages.md) in ServicePulse. |
66 | 66 |
|
67 | 67 | ### Audit instances |
68 | 68 |
|
69 | | -To enable ServiceInsight to visualize the message flow through the system, it must have access to every message that has been successfully processed by the system. This requires endpoints to [enable auditing](/nservicebus/operations/auditing.md). ServiceControl consumes these messages and stores them in its internal database. |
| 69 | +To enable ServiceInsight to visualize the message flow through the system, it must have access to every message that has been successfully processed by the system. This requires endpoints to [enable auditing](/nservicebus/operations/auditing.md). ServiceControl consumes these messages and stores them in its database. |
70 | 70 |
|
71 | 71 | ServiceInsight will retrieve the data from ServiceControl via the HTTP API and use header information (added by NServiceBus during message processing) to figure out which message caused other messages to be sent, including which sagas were accessed when the [SagaAudit plugin](/nservicebus/sagas/saga-audit.md) is configured in an endpoint. |
72 | 72 |
|
|
0 commit comments