In ServiceControl versions 4 and above, a ServiceControl Audit instance manages the audit queue. Data about audit messages is exposed via an HTTP API on a ServiceControl Error instance. This API is used by ServiceInsight for visualizing message flows.
Each endpoint in the system should be configured to send audit copies of every message that is processed into a central audit queue. A ServiceControl Audit instance reads the messages in the audit queue and makes them available for visualization in ServiceInsight. ServiceControl Audit can optionally forward these messages into an Audit Log queue for further processing if required. In some cases, it might be useful to exclude certain message types from being forwarded to the audit queue. This can be accomplished with a custom behavior in the pipeline.
Each ServiceControl Audit instance stores data in an embedded database. Audit data is retained for 30 days. This retention period can be customized.
Connected to a ServiceControl instance
When using ServiceControl Management to create a new ServiceControl instance, a connected ServiceControl Audit instance is automatically created. Using PowerShell, create the ServiceControl instance first, then the ServiceControl Audit instance.
When auditing NServiceBus messages there must be at least one ServiceControl audit instance. ServiceInsight connects directly to the ServiceControl Error instance, which will aggregate the data stored in all connected ServiceControl Audit instances.
Connecting ServiceInsight directly to a ServiceControl Audit instance is not supported.
Notifications
Each ServiceControl Audit instance sends notification messages to a ServiceControl Error instance.
Endpoint detection
When a ServiceControl Audit instance detects a new endpoint, it sends a notification to the ServiceControl Error instance. The Error instance keeps track of all of the endpoints in the system and can monitor them with heartbeats and custom checks.
Successful retry detection
When a ServiceControl Audit instance detects that an audited message is the result of a retry, it sends a notification to the ServiceControl Error instance.
Health monitoring
ServiceControl includes some basic self-monitoring implemented as custom checks. These checks are reported in ServicePulse along with other custom checks.
MSMQ transactional dead letter queue
A machine running MSMQ has a single transactional dead letter queue. Messages that cannot be delivered to queues located on remote machines are eventually moved to the transactional dead letter queue. ServiceControl monitors the transactional dead letter queue on the machine it is installed on. The presence of messages in this queue may indicate problems delivering messages for retries.
Azure Service Bus staging dead letter queue
Every Azure Service Bus queue has an associated dead letter queue. When ServiceControl sends a message for retry, it uses a staging queue. ServiceControl monitors the dead letter queue associated with the staging queue. The presence of messages in the dead letter queue indicates problems delivering messages for retries.
Failed imports
When ServiceControl is unable to ingest an audit or error message, an error is logged and the message is stored separately. ServiceControl monitors these messages. For more information, see re-importing failed messages.
Error message ingestion process
When ServiceControl has difficulty connecting to the configured transport, the error message ingestion process is shut down for sixty seconds. These shutdowns are monitored. The time to wait before restarting the error ingestion process is controlled by the ServiceControl/TimeToRestartErrorIngestionAfterFailure setting.
Message database storage space
ServiceControl stores messages in an embedded database. If the drive containing the database runs out of storage space, message ingestion fails and the ServiceControl instance stops. This may cause instability in the database, even after storage space is increased. The remaining storage space on the drive is monitored. The check reports a failure if the drive has less than 20% remaining of its total capacity. This threshold is controlled by the ServiceControl/DataSpaceRemainingThreshold setting.
Critical message database storage space
This is similar to the Message database storage space check. However, in this case, if the drive containing the database has less than 5% remaining of its total capacity, message ingestion on the ServiceControl instance is stopped to prevent data loss, and a failure is reported. This threshold is controlled by the ServiceControl/MinimumStorageLeftRequiredForIngestion (for the error instance) and ServiceControl.Audit/MinimumStorageLeftRequiredForIngestion (for the audit instance) settings.