diff --git a/servicecontrol/audit-instances/deployment/powershell.md b/servicecontrol/audit-instances/deployment/powershell.md index aed33273050..27aa27d6f3a 100644 --- a/servicecontrol/audit-instances/deployment/powershell.md +++ b/servicecontrol/audit-instances/deployment/powershell.md @@ -35,7 +35,7 @@ include: powershell-new-configuration > [!NOTE] > The address of a ServiceControl Error instance must be provided to send notifications to. -Once a ServiceControl Audit instance is created, it must be added to the ServiceControl Error instance as a [remote](/servicecontrol/servicecontrol-instances/remotes.md) to be included in results returned to [ServiceInsight](/serviceinsight/) or [ServicePulse](/servicepulse/). Use the `Add-ServiceControlRemote` cmdlet to add a remote to the Error instance: +Once a ServiceControl Audit instance is created, it must be added to the ServiceControl Error instance as a [remote](/servicecontrol/servicecontrol-instances/remotes.md) to be included in results returned to [ServicePulse](/servicepulse/). Use the `Add-ServiceControlRemote` cmdlet to add a remote to the Error instance: snippet: ps-add-audit-remote diff --git a/servicecontrol/audit-instances/index.md b/servicecontrol/audit-instances/index.md index a7831c4c2aa..99f8a91bc1f 100644 --- a/servicecontrol/audit-instances/index.md +++ b/servicecontrol/audit-instances/index.md @@ -7,7 +7,7 @@ redirects: - servicecontrol/audit-instances/persistence --- -Each endpoint in the system can be [configured to send audit copies of every message that is processed into a central audit queue](/nservicebus/operations/auditing.md). ServiceControl Audit instances consume and store the messages sent to the audit queue and make them available for visualizing message flows in [ServiceInsight](/serviceinsight/) or [ServicePulse](/servicepulse/). +Each endpoint in the system can be [configured to send audit copies of every message that is processed into a central audit queue](/nservicebus/operations/auditing.md). ServiceControl Audit instances consume and store the messages sent to the audit queue and make them available for visualizing message flows in [ServicePulse](/servicepulse/). ServiceControl Audit can optionally forward these messages into an [audit log queue](configuration.md#transport-servicecontrol-auditforwardauditmessages) for further processing if required. @@ -19,7 +19,6 @@ graph LR SC[ServiceControl
Instance] AuditQ --> SCA - ServiceInsight -.-> SC ServicePulse -.-> SC SCA --> AuditLog[Audit.Log
Queue] @@ -30,10 +29,10 @@ graph LR Data about audit messages is exposed via an HTTP API from a ServiceControl Error instance, which aggregates the data stored in [all connected ServiceControl Audit instances](/servicecontrol/servicecontrol-instances/remotes.md#overview-sharding-audit-messages-with-competing-consumers). > [!IMPORTANT] -> Connecting ServiceInsight or ServicePulse directly to a ServiceControl Audit instance is not supported. +> Connecting ServicePulse directly to a ServiceControl Audit instance is not supported. > [!NOTE] -> The ServiceControl HTTP API is designed for use by ServiceInsight or ServicePulse only and may change at any time. Use of this HTTP API for other purposes is discouraged. +> The ServiceControl HTTP API is designed for use by ServicePulse only and may change at any time. Use of this HTTP API for other purposes is discouraged. ## Persistence diff --git a/servicecontrol/capacity-and-planning.md b/servicecontrol/capacity-and-planning.md index ccd75221738..e108b6dd44b 100644 --- a/servicecontrol/capacity-and-planning.md +++ b/servicecontrol/capacity-and-planning.md @@ -24,7 +24,7 @@ The location of the database has a significant impact on overall system performa The storage size that ServiceControl requires depends on the production load and is directly related to the quantity and size of messages that flow into the system. -ServiceControl provides "recent-history" storage to support ServicePulse and ServiceInsight monitoring and debugging. This is different to a data archiving system that is intended to provide long-term archiving and storage (measured in years, subject to various business or regulatory requirements). +ServiceControl provides "recent-history" storage to support ServicePulse monitoring and debugging. This is different to a data archiving system that is intended to provide long-term archiving and storage (measured in years, subject to various business or regulatory requirements). ServiceControl is configured with default expiration policies that delete old messages after predefined time periods. The expiration policies may be customized to decrease or increase the amount of time that data is retained, which impacts the storage requirements of ServiceControl. diff --git a/servicecontrol/contracts.md b/servicecontrol/contracts.md index fbb776a4e9b..d2e83edef18 100644 --- a/servicecontrol/contracts.md +++ b/servicecontrol/contracts.md @@ -52,7 +52,7 @@ snippet: ServiceControlEventsConfig snippet: MessageFailedHandler > [!WARNING] -> Endpoints that subscribe to ServiceControl events should _not_ use the same `error` and `audit` queues as other endpoints. Using the same `error` queue could cause an infinite feedback loop if processing a `MessageFailed` message failed. Using the same `audit` queue will cause the processing of the `MessageFailed` messages to be included in the ServiceInsight and ServicePulse messages search results. This could confuse users searching for a given failure since both the failure and the failure notification will be shown. See also: [Recoverability](/nservicebus/recoverability/) and [Audit Queue Settings](/nservicebus/operations/auditing.md). +> Endpoints that subscribe to ServiceControl events should _not_ use the same `error` and `audit` queues as other endpoints. Using the same `error` queue could cause an infinite feedback loop if processing a `MessageFailed` message failed. Using the same `audit` queue will cause the processing of the `MessageFailed` messages to be included in the ServicePulse messages search results. This could confuse users searching for a given failure since both the failure and the failure notification will be shown. See also: [Recoverability](/nservicebus/recoverability/) and [Audit Queue Settings](/nservicebus/operations/auditing.md). #### Registering the publisher for message-driven publish/subscribe diff --git a/servicecontrol/how.md b/servicecontrol/how.md index 9c892cc16c8..1ed9c2841a4 100644 --- a/servicecontrol/how.md +++ b/servicecontrol/how.md @@ -4,10 +4,10 @@ summary: An overview of how ServiceControl collects and processes messages and d reviewed: 2025-07-06 --- -ServiceControl is a background process that will collect and store data and make it available via an HTTP API to ServicePulse and ServiceInsight. +ServiceControl is a background process that will collect and store data and make it available via an HTTP API to ServicePulse. > [!NOTE] -> 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. +> The ServiceControl HTTP API may change at any time. It is designed for use by ServicePulse only. The use of this HTTP API for other purposes is not supported. ## How ServiceControl receives data @@ -57,7 +57,7 @@ graph LR [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. -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. +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 for visualization, retries, and other operations. > [!NOTE] > 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. @@ -66,9 +66,9 @@ Find out more about [failed messages](/servicepulse/intro-failed-messages.md) in ### Audit instances -To enable ServiceInsight and ServicePulse to visualize the message flow through the system, ServiceControl 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. +To allow ServicePulse to visualize the message flow through the system, ServiceControl 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. -ServiceInsight or ServicePulse 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. +ServicePulse 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. ### Monitoring instances diff --git a/servicecontrol/import-failed-messages.md b/servicecontrol/import-failed-messages.md index 581e3d947a8..1953e753ac1 100644 --- a/servicecontrol/import-failed-messages.md +++ b/servicecontrol/import-failed-messages.md @@ -19,7 +19,7 @@ Messages can fail to be imported into the ServiceControl database for the follow Messages that fail to be imported are stored in the ServiceControl database in the `FailedAuditImports` and `FailedErrorImports` collections. -In addition, a log with the failure reason is written for the message in the `%ServiceControl/LogPath%` ([error instances](/servicecontrol/servicecontrol-instances/configuration.md#logging-servicecontrollogpath)/[audit instances](/servicecontrol/audit-instances/configuration.md#logging-servicecontrol-auditlogpath)) `\FailedImports\{Audit|Error}\%failureid%.txt`. These messages will not be visible in ServiceInsight or ServicePulse. +In addition, a log with the failure reason is written for the message in the `%ServiceControl/LogPath%` ([error instances](/servicecontrol/servicecontrol-instances/configuration.md#logging-servicecontrollogpath)/[audit instances](/servicecontrol/audit-instances/configuration.md#logging-servicecontrol-auditlogpath)) `\FailedImports\{Audit|Error}\%failureid%.txt`. These messages will not be visible in ServicePulse. ## Failed message custom check @@ -29,7 +29,7 @@ When a failed import is detected in the ServiceControl database, the [**Message To reimport the failed messages, the instance must be shut down and started from a command line using one of the following commands: -While in import mode, ServiceControl or ServiceControl Audit will not process its input queues. Once the message is re-processed successfully, it is available in ServicePulse and ServiceInsight. +While in import mode, ServiceControl or ServiceControl Audit will not process its input queues. Once the message is re-processed successfully, it is available in ServicePulse. The custom check will no longer be displayed if all failed imports have been successfully reimported. diff --git a/servicecontrol/index.md b/servicecontrol/index.md index 9bec19efcae..d0bc1b0efec 100644 --- a/servicecontrol/index.md +++ b/servicecontrol/index.md @@ -8,7 +8,7 @@ isLearningPath: true include: servicecontrol -For more information on how ServiceControl, ServicePulse, and ServiceInsight work together, refer to [the Particular Service Platform](/platform/) article. For a quick overview of the different instances, what they do and how to configure endpoints, refer to the [how does ServiceControl work](/servicecontrol/how.md) article. +For more information on how ServiceControl and ServicePulse work together, refer to [the Particular Service Platform](/platform/) article. For a quick overview of the different instances, what they do and how to configure endpoints, refer to the [how does ServiceControl work](/servicecontrol/how.md) article. ### ServiceControl instance types @@ -17,7 +17,7 @@ There are three types of instances that can be created: - [Error instances](/servicecontrol/servicecontrol-instances/) This is the most commonly used ServiceControl instance and indispensable to ensure the smooth operation of an NServiceBus system. Together with ServicePulse, it provides the ability to visualize and retry failed messages. - [Audit instances](/servicecontrol/audit-instances/) - Audit instances provide valuable information about the message flow through a system. Among other things, this is used by ServiceInsight and ServicePulse to help visualize a distributed system. + Audit instances provide valuable information about the message flow through a system. Among other things, this is used by ServicePulse to help visualize a distributed system. - [Monitoring instances](/servicecontrol/monitoring-instances/) Monitoring instances performance monitoring and analyzing additional metrics and are useful for keeping track of the health of a distributed system. diff --git a/servicecontrol/license.md b/servicecontrol/license.md index 7289c218142..6f86ec00940 100644 --- a/servicecontrol/license.md +++ b/servicecontrol/license.md @@ -49,10 +49,6 @@ snippet: config-licensepath > [!NOTE] > This is the same setting to configure a license path for an NServiceBus 7 or lower endpoint. This license configuration option is [no longer supported in NServiceBus 8](/nservicebus/upgrades/7to8/#change-to-license-file-locations) or later endpoints. -## Using ServiceInsight - -A machine-wide license file can be installed using [ServiceInsight](/serviceinsight/license.md) which can then be used by ServiceControl. - ## Troubleshooting ### ServiceControl license was updated, but ServicePulse reports the license has expired diff --git a/servicecontrol/migrations/replacing-audit-instances/index.md b/servicecontrol/migrations/replacing-audit-instances/index.md index 36bf289b779..20f22a95b63 100644 --- a/servicecontrol/migrations/replacing-audit-instances/index.md +++ b/servicecontrol/migrations/replacing-audit-instances/index.md @@ -40,16 +40,13 @@ errorQ -- ingested by --> sc[ServiceControl
Error] auditQ -- ingested by --> sca[Original
ServiceControl
audit] sc -. connected to .-> sca sp[ServicePulse] -. connected to .-> sc -si[ServiceInsight] -. connected to .-> sc classDef Endpoints fill:#00A3C4,stroke:#00729C,color:#FFFFFF -classDef ServiceInsight fill:#878CAA,stroke:#585D80,color:#FFFFFF classDef ServicePulse fill:#409393,stroke:#205B5D,color:#FFFFFF classDef ServiceControlError fill:#A84198,stroke:#92117E,color:#FFFFFF,stroke-width:4px classDef ServiceControlRemote fill:#A84198,stroke:#92117E,color:#FFFFFF class endpoints Endpoints -class si ServiceInsight class sp ServicePulse class sc ServiceControlError class sca ServiceControlRemote @@ -81,16 +78,13 @@ auditQ -- ingested by --> sca2[New
ServiceControl
audit] sc -. connected to .-> sca sc -. connected to .-> sca2 sp[ServicePulse] -. connected to .-> sc -si[ServiceInsight] -. connected to .-> sc classDef Endpoints fill:#00A3C4,stroke:#00729C,color:#FFFFFF -classDef ServiceInsight fill:#878CAA,stroke:#585D80,color:#FFFFFF classDef ServicePulse fill:#409393,stroke:#205B5D,color:#FFFFFF classDef ServiceControlError fill:#A84198,stroke:#92117E,color:#FFFFFF,stroke-width:4px classDef ServiceControlRemote fill:#A84198,stroke:#92117E,color:#FFFFFF class endpoints Endpoints -class si ServiceInsight class sp ServicePulse class sc ServiceControlError class sca,sca2 ServiceControlRemote @@ -117,16 +111,13 @@ auditQ -- ingested by --> sca2[New
ServiceControl
audit] sc -. connected to .-> sca[Original
ServiceControl
audit] sc -. connected to .-> sca2 sp[ServicePulse] -. connected to .-> sc -si[ServiceInsight] -. connected to .-> sc classDef Endpoints fill:#00A3C4,stroke:#00729C,color:#FFFFFF -classDef ServiceInsight fill:#878CAA,stroke:#585D80,color:#FFFFFF classDef ServicePulse fill:#409393,stroke:#205B5D,color:#FFFFFF classDef ServiceControlError fill:#A84198,stroke:#92117E,color:#FFFFFF,stroke-width:4px classDef ServiceControlRemote fill:#A84198,stroke:#92117E,color:#FFFFFF class endpoints Endpoints -class si ServiceInsight class sp ServicePulse class sc ServiceControlError class sca,sca2 ServiceControlRemote @@ -159,16 +150,13 @@ errorQ -- ingested by --> sc[ServiceControl
error] auditQ -- ingested by --> sca2[New
ServiceControl
audit] sc -. connected to .-> sca2 sp[ServicePulse] -. connected to .-> sc -si[ServiceInsight] -. connected to .-> sc classDef Endpoints fill:#00A3C4,stroke:#00729C,color:#FFFFFF -classDef ServiceInsight fill:#878CAA,stroke:#585D80,color:#FFFFFF classDef ServicePulse fill:#409393,stroke:#205B5D,color:#FFFFFF classDef ServiceControlError fill:#A84198,stroke:#92117E,color:#FFFFFF,stroke-width:4px classDef ServiceControlRemote fill:#A84198,stroke:#92117E,color:#FFFFFF class endpoints Endpoints -class si ServiceInsight class sp ServicePulse class sc ServiceControlError class sca2 ServiceControlRemote diff --git a/servicecontrol/migrations/replacing-error-instances/index.md b/servicecontrol/migrations/replacing-error-instances/index.md index 1f6ba43b682..bc697108613 100644 --- a/servicecontrol/migrations/replacing-error-instances/index.md +++ b/servicecontrol/migrations/replacing-error-instances/index.md @@ -15,7 +15,7 @@ See [Replacing an Audit Instance](../replacing-audit-instances/) for similar gui ## Overview -ServiceControl Error instances serve as the central access point for both Error and Audit data. When ServicePulse or ServiceInsight requests data from the API, those requests are either answered by the Error instance directly or passed through to one or more Audit instances in a scatter/gather pattern. So it is possible to create a new Error instance configured to communicate with the same Audit instance(s) and begin using the new Error instance to consume messages from the error queue. The critical aspect is to protect any active error messages during the transition that might still contain any valuable business data. +ServiceControl Error instances serve as the central access point for both Error and Audit data. When ServicePulse requests data from the API, those requests are either answered by the Error instance directly or passed through to one or more Audit instances in a scatter/gather pattern. So it is possible to create a new Error instance configured to communicate with the same Audit instance(s) and begin using the new Error instance to consume messages from the error queue. The critical aspect is to protect any active error messages during the transition that might still contain any valuable business data. Keeping this in mind, an Error instance that can't be upgraded can be replaced without downtime. The process follows these steps: @@ -63,4 +63,4 @@ Now that the only valuable error messages are held in the error queue, the Error Once complete, the old Error instance has been successfully replaced with a new one. -If the procedure involved creating a new instance, rather than a forced upgrade, it will be necessary to adjust the connection information for ServicePulse and ServiceInsight to connect to the new Error instance's URL. \ No newline at end of file +If the procedure involved creating a new instance, rather than a forced upgrade, it will be necessary to adjust the connection information for ServicePulse to connect to the new Error instance's URL. \ No newline at end of file diff --git a/servicecontrol/migrations/windows-to-containers.md b/servicecontrol/migrations/windows-to-containers.md index f5c87ff9751..bdb2b4cadc3 100644 --- a/servicecontrol/migrations/windows-to-containers.md +++ b/servicecontrol/migrations/windows-to-containers.md @@ -21,7 +21,7 @@ When the objective is to migrate from Windows hosting to container-based hosting ## Migrating Audit instances -Migration of an Audit instance is only necessary if audit message data must be preserved. Audit data is regularly deleted after it reaches the end of its retention period, so when considering a migration, it's necessary to consider whether the value of the audit data, as used by ServiceInsight and ServicePulse, is worth the added complexity of the migration procedure. +Migration of an Audit instance is only necessary if audit message data must be preserved. Audit data is regularly deleted after it reaches the end of its retention period, so when considering a migration, it's necessary to consider whether the value of the audit data, as used by ServicePulse, is worth the added complexity of the migration procedure. See the article [Replacing an Audit instance](/servicecontrol/migrations/replacing-audit-instances/) for migration instructions. The procedure includes creating a new audit instance in parallel with the old one, and disabling audit ingestion on the old instance. In this way, audit data is served from both instances until all the audit data in the Audit instance reaches its retention period and is deleted, after which the old audit instance can be removed. diff --git a/servicecontrol/securing-servicecontrol.md b/servicecontrol/securing-servicecontrol.md index 836d53613b4..d1aa7e27d15 100644 --- a/servicecontrol/securing-servicecontrol.md +++ b/servicecontrol/securing-servicecontrol.md @@ -8,25 +8,25 @@ related: - servicecontrol/backup-sc-database --- -ServiceControl serves as the back-end service for ServicePulse and ServiceInsight, supplying these client applications with the information required for their functionality. It does so by exposing an HTTP API that can be accessed by these and other third-party tools. +ServiceControl serves as the back-end service for ServicePulse, supplying these client applications with the information required for their functionality. It does so by exposing an HTTP API that can be accessed by these and other third-party tools. The information gathered, stored, and exposed by ServiceControl contains all the messages audited and forwarded to the audit and error queues (including their metadata, headers, and body). This requires unlimited access to the ServiceControl embedded database and to all the information contained within the system's audited messages. -It is critical to limit access to the ServiceControl instance, including accessing its data through its clients (ServiceInsight and ServicePulse), and accessing directly through the HTTP API. +It is critical to limit access to the ServiceControl instance, including accessing its data through its clients (ServicePulse), and accessing directly through the HTTP API. ### Post-installation: secure and limited access by default When installing ServiceControl, the default installation will limit access from the local host only. Any attempt to access the service's HTTP API from outside the machines on which it is installed results in an `access denied` message. -This applies also to accessing ServiceControl from ServicePulse and ServiceInsight. Using the default settings, these tools can access ServiceControl only when they are installed on the same machine as ServiceControl. +This also applies to accessing ServiceControl from ServicePulse. Using the default settings, these tools can access ServiceControl only when they are installed on the same machine as ServiceControl. ### Extending access by changing host name ServiceControl can be accessed from other machines by [setting a custom host name and port number](/servicecontrol/setting-custom-hostname.md). The scope of the access extension allowed by this change depends on the specified custom host name and port number. It also depends on various network limitations (e.g. proxy, firewall, DNS settings) that may limit access to the specified ServiceControl host and port. -Note that ServicePulse and ServiceInsight users must access the ServiceControl HTTP API using the specified custom host name and port number, so ensure that the network rules enable access when specifying these details (as well as when applying the various limiting network rules and policies). +Note that ServicePulse users must access the ServiceControl HTTP API using the specified custom host name and port number, so ensure that the network rules enable access when specifying these details (as well as when applying the various limiting network rules and policies). ### Limiting access and data visibility diff --git a/servicecontrol/servicecontrol-in-practice.md b/servicecontrol/servicecontrol-in-practice.md index b2d676fce78..0647b133e1a 100644 --- a/servicecontrol/servicecontrol-in-practice.md +++ b/servicecontrol/servicecontrol-in-practice.md @@ -25,10 +25,10 @@ In addition: ## Message throughput considerations -Depending on the number of endpoints and message volume, audit messages can have a significant impact on performance. Turn off [message auditing](/nservicebus/operations/auditing.md) if it is not needed. The primary reason for the audit ingestion capability of ServiceControl is to support system analysis with ServiceInsight or ServicePulse. If ServiceInsight or ServicePulse message visualizations are not in use, turn off messaging auditing for each endpoint. Message auditing may be important for some endpoints but not others. +Depending on the number of endpoints and message volume, audit messages can have a significant impact on performance. Turn off [message auditing](/nservicebus/operations/auditing.md) if it is not needed. The primary reason for the audit ingestion capability of ServiceControl is to support system analysis with ServicePulse. If ServicePulse message visualizations are not in use, turn off messaging auditing for each endpoint. Message auditing may be important for some endpoints but not others. > [!NOTE] -> If message auditing is required without the use of ServiceInsight or ServicePulse, configure endpoints and ServiceControl to use different audit queues. Audit messages going to an audit queue that is not managed by ServiceControl must be cleaned up manually. +> If message auditing is required without the use of ServicePulse, configure endpoints and ServiceControl to use different audit queues. Audit messages going to an audit queue that is not managed by ServiceControl must be cleaned up manually. Turn off [audit forwarding](/servicecontrol/errorlog-auditlog-behavior.md) if it is not needed. ServiceControl sends a copy of each audited message to a configured audit forwarding queue. If these messages are not being used, turn this feature off. diff --git a/servicecontrol/servicecontrol-instances/deployment/scmu.md b/servicecontrol/servicecontrol-instances/deployment/scmu.md index f1be030a9f6..fba1a3cebf9 100644 --- a/servicecontrol/servicecontrol-instances/deployment/scmu.md +++ b/servicecontrol/servicecontrol-instances/deployment/scmu.md @@ -42,7 +42,7 @@ There are [three types](/servicecontrol/#servicecontrol-instance-types) of Servi 2. If multiple instances for different systems are installed on the same server, a name like `Particular.SystemName` is a common option. 2. Select the appropriate user account. Note that ServiceControl instances will run as Windows Services in the background. - 3. Be aware of the port numbers as these are used by ServicePulse and ServiceInsight to connect to ServiceControl. + 3. Be aware of the port numbers as these are used by ServicePulse to connect to ServiceControl. 4. Configure the [retention period](/servicecontrol/how-purge-expired-data.md) for each instance. 5. Configure the name of the queue that messages should arrive in. This queue is important to endpoints that send error and audit messages to these ServiceControl instances, as well as [plugins](/servicecontrol/servicecontrol-instances/configuration.md#host-settings-servicecontrolinstancename). diff --git a/servicecontrol/servicecontrol-instances/hardware.md b/servicecontrol/servicecontrol-instances/hardware.md index a9dcc80eaa2..6120338c95c 100644 --- a/servicecontrol/servicecontrol-instances/hardware.md +++ b/servicecontrol/servicecontrol-instances/hardware.md @@ -62,7 +62,7 @@ In general, [the smaller the messages](https://particular.net/blog/putting-your- For audit messages, lower the [`ServiceControl.Audit/MaxBodySizeToStore`](/servicecontrol/audit-instances/configuration.md#performance-tuning-servicecontrol-auditmaxbodysizetostore) setting to skip storage of larger audit messages. This setting will only reduce load if non-binary [serialization](/nservicebus/serialization/) is used. > [!WARNING] -> When using ServiceInsight or ServicePulse, the message body is not viewable for messages that exceed the `ServiceControl/MaxBodySizeToStore` limit. +> When using ServicePulse, the message body is not viewable for messages that exceed the `ServiceControl/MaxBodySizeToStore` limit. ### Separate disks for database and index files diff --git a/servicecontrol/servicecontrol-instances/index.md b/servicecontrol/servicecontrol-instances/index.md index 92d0a35f606..c196e46eed6 100644 --- a/servicecontrol/servicecontrol-instances/index.md +++ b/servicecontrol/servicecontrol-instances/index.md @@ -10,8 +10,8 @@ redirects: --- A ServiceControl Error instance: -* Monitors [the central `error` queue](/nservicebus/recoverability/configure-error-handling.md#error-queue-monitoring) and stores the failed messages making them available for manual retries using [ServicePulse](/servicepulse/intro-failed-messages.md) or [ServiceInsight](/serviceinsight/managing-errors-and-retries.md). -* Aggregates and forwards data from [Audit instances](/servicecontrol/audit-instances/) for visualization in [ServiceInsight](/serviceinsight/) or [ServicePulse](/servicepulse/). +* Monitors [the central `error` queue](/nservicebus/recoverability/configure-error-handling.md#error-queue-monitoring) and stores the failed messages making them available for manual retries using [ServicePulse](/servicepulse/intro-failed-messages.md). +* Aggregates and forwards data from [Audit instances](/servicecontrol/audit-instances/) for visualization in [ServicePulse](/servicepulse/). * Collects and serves [heartbeat](/monitoring/heartbeats/) and [custom check](/monitoring/custom-checks/) data for presentation by [ServicePulse](/servicepulse/health-check-notifications.md) * Publishes [integration events](/servicecontrol/contracts.md) that can be handled by user built [endpoints](/nservicebus/messaging/publish-subscribe/publish-handle-event.md) that can perform a custom action when those events occur. * If [configured](/servicecontrol/servicecontrol-instances/configuration.md#transport-servicecontrolforwarderrormessages), forwards failed messages to an [error log queue](/servicecontrol/errorlog-auditlog-behavior.md) for custom processing. diff --git a/servicecontrol/servicecontrol-instances/remotes.md b/servicecontrol/servicecontrol-instances/remotes.md index 5caef428dea..718aef7a0a0 100644 --- a/servicecontrol/servicecontrol-instances/remotes.md +++ b/servicecontrol/servicecontrol-instances/remotes.md @@ -7,11 +7,11 @@ redirects: - servicecontrol/servicecontrol-instances/distributed-instances --- -[ServiceInsight](/serviceinsight/) and [ServicePulse](/servicepulse) retrieve data from a [ServiceControl instance](/servicecontrol/servicecontrol-instances/) using an HTTP API. In some installations, that data may reside in multiple ServiceControl instances. The ServiceControl Remotes features allows a ServiceControl instance to aggregate data from other ServiceControl instances, providing a unified experience in ServiceInsight and ServicePulse. +[ServicePulse](/servicepulse) retrieves data from a [ServiceControl instance](/servicecontrol/servicecontrol-instances/) using an HTTP API. In some installations, that data may reside in multiple ServiceControl instances. The ServiceControl Remotes features allows a ServiceControl instance to aggregate data from other ServiceControl instances, providing a unified experience in ServicePulse. ## Overview -One ServiceControl Error instance is designated as the _primary_ instance. All other ServiceControl instances are _remote_ instances. The HTTP API of the primary instance aggregates data from the primary instance and from all the remote instances. ServiceInsight and ServicePulse are configured to connect to the primary instance. +One ServiceControl Error instance is designated as the _primary_ instance. All other ServiceControl instances are _remote_ instances. The HTTP API of the primary instance aggregates data from the primary instance and from all the remote instances. ServicePulse is configured to connect to the primary instance. > [!NOTE] > The term _remote_ refers to the fact that remote instances are run in separate processes. The primary instance and one or more remote instances can run on the same machine. @@ -29,20 +29,17 @@ Endpoints[endpoints] -- send audits to --> AuditQueue(audit queue) Endpoints -- send errors to --> ErrorQueue(error queue) ErrorQueue -- ingested by --> ServiceControl[ServiceControl
primary] -ServiceInsight -. connected to .-> ServiceControl ServicePulse -. connected to .-> ServiceControl AuditQueue -- ingested by --> ServiceControlAudit[ServiceControl Audit
remote] ServiceControl -. connected to .-> ServiceControlAudit classDef Endpoints fill:#00A3C4,stroke:#00729C,color:#FFFFFF -classDef ServiceInsight fill:#878CAA,stroke:#585D80,color:#FFFFFF classDef ServicePulse fill:#409393,stroke:#205B5D,color:#FFFFFF classDef ServiceControlPrimary fill:#A84198,stroke:#92117E,color:#FFFFFF,stroke-width:4px classDef ServiceControlRemote fill:#A84198,stroke:#92117E,color:#FFFFFF class Endpoints Endpoints -class ServiceInsight ServiceInsight class ServicePulse ServicePulse class ServiceControl ServiceControlPrimary class ServiceControlAudit ServiceControlRemote @@ -59,7 +56,6 @@ Endpoints[endpoints] -- send audits to --> AuditQueue(audit queue) Endpoints -- send errors to --> ErrorQueue(error queue) ErrorQueue -- ingested by --> ServiceControl[ServiceControl
primary] -ServiceInsight -. connected to .-> ServiceControl ServicePulse -. connected to .-> ServiceControl AuditQueue -- ingested by --> ServiceControlAudit1[ServiceControl Audit 1
remote] @@ -69,13 +65,11 @@ AuditQueue -- ingested by --> ServiceControlAudit2[ServiceControl Audit 2
re ServiceControl -. connected to .-> ServiceControlAudit2 classDef Endpoints fill:#00A3C4,stroke:#00729C,color:#FFFFFF -classDef ServiceInsight fill:#878CAA,stroke:#585D80,color:#FFFFFF classDef ServicePulse fill:#409393,stroke:#205B5D,color:#FFFFFF classDef ServiceControlPrimary fill:#A84198,stroke:#92117E,color:#FFFFFF,stroke-width:4px classDef ServiceControlRemote fill:#A84198,stroke:#92117E,color:#FFFFFF class Endpoints Endpoints -class ServiceInsight ServiceInsight class ServicePulse ServicePulse class ServiceControl ServiceControlPrimary class ServiceControlAudit1,ServiceControlAudit2 ServiceControlRemote @@ -93,7 +87,6 @@ Endpoints1 -- send errors to --> ErrorQueue(error queue) Endpoints2[endpoints
group 2] -- send errors to --> ErrorQueue ErrorQueue -- ingested by --> ServiceControl[ServiceControl
primary] -ServiceInsight -. connected to .->ServiceControl ServicePulse -. connected to .-> ServiceControl Endpoints2 -- send audits to--> AuditQueue2(audit queue 2) @@ -105,13 +98,11 @@ ServiceControl -. connected to .-> ServiceControlAudit2[ServiceControl Audit 2 ServiceControlAudit2 classDef Endpoints fill:#00A3C4,stroke:#00729C,color:#FFFFFF -classDef ServiceInsight fill:#878CAA,stroke:#585D80,color:#FFFFFF classDef ServicePulse fill:#409393,stroke:#205B5D,color:#FFFFFF classDef ServiceControlPrimary fill:#A84198,stroke:#92117E,color:#FFFFFF,stroke-width:4px classDef ServiceControlRemote fill:#A84198,stroke:#92117E,color:#FFFFFF class Endpoints1,Endpoints2 Endpoints -class ServiceInsight ServiceInsight class ServicePulse ServicePulse class ServiceControl ServiceControlPrimary class ServiceControlAudit1,ServiceControlAudit2 ServiceControlRemote @@ -119,7 +110,7 @@ class ServiceControlAudit1,ServiceControlAudit2 ServiceControlRemote ### Multi-transport deployments -When a system uses multiple transports, the [Messaging Bridge](/nservicebus/bridge/) can be used to allow management of the entire system by single instances of ServicePulse and ServiceInsight. +When a system uses multiple transports, the [Messaging Bridge](/nservicebus/bridge/) can be used to allow management of the entire system by single instances of ServicePulse. ```mermaid graph TD @@ -129,7 +120,6 @@ primaryA -. connected to .-> auditC subgraph Transport A ServicePulse[ServicePulse] -. connected to .-> primaryA -ServiceInsight[ServiceInsight] -. connected to .-> primaryA endpointsA[endpoints] -- send errors to --> errorQueueA[error queue] endpointsA -- send audits to --> auditQueueA[audit queue] errorQueueA -- ingested by --> primaryA[ServiceControl
primary] @@ -154,14 +144,12 @@ end classDef Endpoints fill:#00A3C4,stroke:#00729C,color:#FFFFFF classDef Bridge fill:#a8a032,stroke:#00729C,color:#FFFFFF -classDef ServiceInsight fill:#878CAA,stroke:#585D80,color:#FFFFFF classDef ServicePulse fill:#409393,stroke:#205B5D,color:#FFFFFF classDef ServiceControlPrimary fill:#A84198,stroke:#92117E,color:#FFFFFF,stroke-width:4px classDef ServiceControlRemote fill:#A84198,stroke:#92117E,color:#FFFFFF class endpointsA,endpointsB,endpointsC Endpoints class bridgeB,bridgeC Bridge -class ServiceInsight ServiceInsight class ServicePulse ServicePulse class primaryA,primaryB ServiceControlPrimary class auditA,auditB,auditC ServiceControlRemote @@ -173,7 +161,7 @@ It is possible to create a multi-region deployment using remotes. ```mermaid graph TD -insight[ServiceInsight] -..-> crossRegionPrimary[Cross Region
ServiceControl
primary] +pulse[ServicePulse] -..-> crossRegionPrimary[Cross Region
ServiceControl
primary] crossRegionPrimary -. connected to .-> primaryB subgraph Region B @@ -197,21 +185,19 @@ end crossRegionPrimary -. connected to .-> primaryA classDef Endpoints fill:#00A3C4,stroke:#00729C,color:#FFFFFF -classDef ServiceInsight fill:#878CAA,stroke:#585D80,color:#FFFFFF classDef ServicePulse fill:#409393,stroke:#205B5D,color:#FFFFFF classDef ServiceControlPrimary fill:#A84198,stroke:#92117E,color:#FFFFFF,stroke-width:4px classDef ServiceControlRemote fill:#A84198,stroke:#92117E,color:#FFFFFF class endpointsA,endpointsB Endpoints -class insight ServiceInsight -class servicePulseA,servicePulseB ServicePulse +class pulse,servicePulseA,servicePulseB ServicePulse class primaryA,primaryB,crossRegionPrimary ServiceControlPrimary class auditA,auditB ServiceControlRemote ``` -In this deployment, each region has a full ServiceControl installation with a primary Error instance and an Audit instance. Each region can be managed and controlled via a dedicated ServicePulse. +In this deployment, each region has a full ServiceControl installation with a primary Error instance and an Audit instance. Each region can be managed and controlled via a dedicated ServicePulse instance. -A new cross-region primary instance is added to allow ServiceInsight to show messages from both regions. This cross-region instance includes each region-specific primary instance as a remote allowing it to query messages from both. The cross-region instance must disable error message ingestion management by setting with the value [`ServiceControl/IngestErrorMessages`](/servicecontrol/servicecontrol-instances/configuration.md#recoverability-servicecontrolingesterrormessages) option to `false`. +A new cross-region primary instance is added to allow another ServicePulse instance to show messages from both regions. This cross-region instance includes each region-specific primary instance as a remote allowing it to query messages from both. The cross-region instance must disable error message ingestion management by setting with the value [`ServiceControl/IngestErrorMessages`](/servicecontrol/servicecontrol-instances/configuration.md#recoverability-servicecontrolingesterrormessages) option to `false`. ### Zero downtime upgrades @@ -291,8 +277,8 @@ To change the address of a remote instance to a new host and/or port number: ## Considerations -- Pagination in ServiceInsight may not work as expected. For example, each page may contain a different number of items, depending on how those items are distributed across the various ServiceControl instances. -- If the primary instance cannot contact a given remote instance, data from that remote instance will not be included in any views in either ServiceInsight or ServicePulse. +- Pagination in ServicePulse may not work as expected. For example, each page may contain a different number of items, depending on how those items are distributed across the various ServiceControl instances. +- If the primary instance cannot contact a given remote instance, data from that remote instance will not be included in any views in ServicePulse. - Multi-instance configuration is not possible the ServiceControl Management utility. - Incorrect configuration may cause cyclical dependencies. For example, instance A may attempt to get data from instance B, and instance B may attempt to get data from instance A. - It is recommended to run _only one_ primary instance. Multiple primary instances are _not recommended_. diff --git a/servicecontrol/troubleshooting.md b/servicecontrol/troubleshooting.md index 270d050cd68..f51a66bce99 100644 --- a/servicecontrol/troubleshooting.md +++ b/servicecontrol/troubleshooting.md @@ -87,7 +87,7 @@ When encryption is enabled, SQL Server uses a certificate to encrypt communicati To fix this error, [update the SQL Server installation with a valid certificate and update the ServiceControl machine to trust this certificate](https://docs.microsoft.com/en-us/sql/database-engine/configure-windows/enable-encrypted-connections-to-the-database-engine) or add `Encrypt=False` to the connection string if encryption is truly not necessary. -## Unable to connect to ServiceControl from either ServiceInsight or ServicePulse +## Unable to connect to ServiceControl from ServicePulse Attempt to connect to the ServiceControl instance's URL using a web browser. A valid response with JSON data should be returned. If not, verify that network configuration and/or firewall settings do not block access to the ServiceControl port specified in the URL. @@ -210,7 +210,7 @@ Resolution: - Consider disabling message bodies and headers *Full-Text search* as this causes most resource utilization for CPU and disk IO. This can be disabled in the latest version of ServiceControl by configuring each ServiceControl instance: open configuration (gear icon), scroll down to Advanced Configuration and set "Full-Text Search On Message Bodies" to Off, finally select Save, and then restart the instance. > [!WARNING] -> Disabling *Full-Text Search* causes text search to be unavailable in ServiceInsight and ServicePulse. +> Disabling *Full-Text Search* causes text search to be unavailable in ServicePulse. ## Saga audit data retention custom check failure diff --git a/servicecontrol/upgrades/1to2.md b/servicecontrol/upgrades/1to2.md index 8541d3c5008..ba7e44fc877 100644 --- a/servicecontrol/upgrades/1to2.md +++ b/servicecontrol/upgrades/1to2.md @@ -43,7 +43,7 @@ Clicking the upgrade link will: ### Side-by-side upgrade process -A side-by-side upgrade process minimizes downtime in ServiceControl and allows for a controlled migration between versions. Instead of upgrading the existing version 1 instance of ServiceControl, the version 1 instance is left running but is configured so that it no longer ingests any messages. A new instance of ServiceControl version 2 is installed and configured to ingest messages from the audit and error queues that the version 1 instance was previously configured to ingest from. The new instance is also configured as a master instance of the previous instance. This results in two instances of ServiceControl, where the new instance will ingest any future messages, and the version 1 instance will contain all messages previously ingested, but will no longer process new messages. All ServiceInsight and ServicePulse instances must then be configured to connect to the new instance of ServiceControl. Since the new instance is the master instance for the version 1 instance, ServiceInsight and ServicePulse will show audited messages from both the version 1 instance as well as the new instance of ServiceControl. +A side-by-side upgrade process minimizes downtime in ServiceControl and allows for a controlled migration between versions. Instead of upgrading the existing version 1 instance of ServiceControl, the version 1 instance is left running but is configured so that it no longer ingests any messages. A new instance of ServiceControl version 2 is installed and configured to ingest messages from the audit and error queues that the version 1 instance was previously configured to ingest from. The new instance is also configured as a master instance of the previous instance. This results in two instances of ServiceControl, where the new instance will ingest any future messages, and the version 1 instance will contain all messages previously ingested, but will no longer process new messages. All ServicePulse instances must then be configured to connect to the new instance of ServiceControl. Since the new instance is the master instance for the version 1 instance, ServicePulse will show audited messages from both the version 1 instance as well as the new instance of ServiceControl. The process for a side-by-side upgrade is as follows: @@ -61,9 +61,9 @@ The process for a side-by-side upgrade is as follows: ``` 4. Start both instances of ServiceControl -5. Configure ServiceInsight and ServicePulse to connect to the new instance of ServiceControl instead of the version 1 instance +5. Configure ServicePulse to connect to the new instance of ServiceControl instead of the version 1 instance -At this stage, new messages will be ingested by the version 2 instance of ServiceControl, while ServiceInsight and ServicePulse will show data from both instances. The next step is to migrate error messages from the version 1 instance to the new instance. To do this, retry all of the failed messages back into production. If the messages fail again, they will be sent back to the error queue, which means they will be ingested by the new instance of ServiceControl again. +At this stage, new messages will be ingested by the version 2 instance of ServiceControl, while ServicePulse will show data from both instances. The next step is to migrate error messages from the version 1 instance to the new instance. To do this, retry all of the failed messages back into production. If the messages fail again, they will be sent back to the error queue, which means they will be ingested by the new instance of ServiceControl again. 6. Using ServicePulse, retry all of the failed messages currently in the version 1 instance of ServiceControl 7. Configure ServicePulse to connect to the new instance of ServiceControl diff --git a/servicepulse/install-servicepulse-in-iis.md b/servicepulse/install-servicepulse-in-iis.md index d89d3b0db9b..b71fe87bfbf 100644 --- a/servicepulse/install-servicepulse-in-iis.md +++ b/servicepulse/install-servicepulse-in-iis.md @@ -144,12 +144,6 @@ There are three roles defined: - `SPFailedMessages`: members can manage failed messages (retry, delete, groups etc.). - `SPMonitoring`: members can manage monitoring (e.g. enabling/disabling heartbeat monitoring for a particular endpoint). -### Limitations - -If ServiceControl is secured with an authentication module other that Windows authentication, ServiceInsight will not be able to connect to the REST API exposed via IIS. ServiceInsight version 1.4 or greater is required to use Windows authentication. - -Older versions of ServiceInsight can still be used locally, bypassing the security by connecting to the ServiceControl port directly using the `http://localhost:33333/api` URL. - ## Upgrading ServicePulse hosted in IIS When ServicePulse is hosted in IIS, the upgrade process is as follows: diff --git a/servicepulse/intro-archived-messages.md b/servicepulse/intro-archived-messages.md index 634ba3fd873..fe81187015f 100644 --- a/servicepulse/intro-archived-messages.md +++ b/servicepulse/intro-archived-messages.md @@ -12,7 +12,7 @@ Archiving can be useful for failed messages that no longer have business value. Archiving in ServicePulse means that the failed messages are marked as `Deleted`. Data from a deleted message is still available, but it is no longer displayed in the Failed Messages list in ServicePulse, is not counted by the Failed Messages indicator in the ServicePulse dashboard, nor will it appear in any failed message groups. > [!NOTE] -> Deleted failed messages are still included in [ServiceInsight](/serviceinsight/) and [ServicePulse](/servicepulse/) diagrams and search results. +> Deleted failed messages are still included in [ServicePulse](/servicepulse/) diagrams and search results. ## Deleting messages diff --git a/servicepulse/intro-editing-messages.md b/servicepulse/intro-editing-messages.md index f31384d93ec..6309f5179be 100644 --- a/servicepulse/intro-editing-messages.md +++ b/servicepulse/intro-editing-messages.md @@ -56,7 +56,7 @@ Message bodies can be edited before they are retried. This is only possible for ## Retrying edited messages > [!WARNING] -> Retrying messages after editing the message headers can cause message processing failures and/or visualization issues in the ServicePulse and ServiceInsight. +> Retrying messages after editing the message headers can cause message processing failures and/or visualization issues in ServicePulse. When retrying an edited message it is possible that the original failed message will have been resolved by another user, retried successfully by another user, or [expired as part of the automated processes](/servicecontrol/how-purge-expired-data.md). In those scenarios, the new message will not be dispatched and the retry of the edited message will fail. diff --git a/transports/learning/index.md b/transports/learning/index.md index fc4cf2e2b3f..9a19aa58365 100644 --- a/transports/learning/index.md +++ b/transports/learning/index.md @@ -17,7 +17,7 @@ Added in Version 6.3. include: learning-usages -[ServiceControl](/servicecontrol/) (and therefore [ServicePulse](/servicepulse/) and [ServiceInsight](/serviceinsight/)) are only supported for demonstration purposes through the use of the [Platform Sample package](/platform/platform-sample-package.md). +[ServiceControl](/servicecontrol/) (and therefore [ServicePulse](/servicepulse/)) are only supported for demonstration purposes through the use of the [Platform Sample package](/platform/platform-sample-package.md). ## Transport at a glance