Skip to content

Commit

Permalink
Review of legacy docs
Browse files Browse the repository at this point in the history
  • Loading branch information
kbaley committed Mar 9, 2024
1 parent 4625f22 commit c57929a
Showing 1 changed file with 5 additions and 5 deletions.
Original file line number Diff line number Diff line change
Expand Up @@ -2,7 +2,7 @@

### Heartbeats

Version 2.2 of the Messaging bridge adds support for Heartbeats. The Heartbeat feature sends regular heartbeat messages from each messaging bridge transport to a ServiceControl instance. The ServiceControl instance keeps track of which endpoint instances are sending heartbeats and which ones are not. See the [Hearbeats plugin documentation](/monitoring/heartbeats/) for more information.
Version 2.2 of the NServiceBus Messaging Bridge adds support for the heartbeats feature. This feature sends regular heartbeat messages from each messaging bridge transport to a ServiceControl instance. The ServiceControl instance keeps track of which endpoint instances are sending heartbeats and which ones are not. See the [Hearbeats plugin documentation](/monitoring/heartbeats/) for more information.

Heartbeats can be configured on a per bridge transport basis. For each bridge transport that should send hearbeats, use the `.SendHeartbeatTo` as follows:

Expand All @@ -24,15 +24,15 @@ Heartbeat messages are sent with a default TTL of four times the frequency. As s

When heartbeats are being used in a [scaled-out Messaging Bridge that is using competing consumers](/nservicebus/bridge/performance.md#scaling-out-competing-consumers), each bridge transport must be configured with a unique name (see [Configuring transports](#auditing-configuring-transports)). The bridge transport name is used in the heartbeat messages so ServiceControl can track of all instances and identify which instance sent a given heartbeat message.

### Custom Checks
### Custom checks

Version 2.2 of the Messaging Bridge adds support for Custom Checks. The Custom Checks feature enables Messaging Bridge health monitoring by running custom code and reporting status (success or failure) to a ServiceControl instance. See the Custom [Checks plugin documentation](/monitoring/custom-checks/) for more information. For documentation on how to write custom checks, see the [Writing Custom Checks document](/monitoring/custom-checks/writing-custom-checks.md)
Version 2.2 of the Messaging Bridge adds support for custom checks. The custom checks feature enables Messaging Bridge health monitoring by running custom code and reporting status (success or failure) to a ServiceControl instance. See the [custom checks plugin documentation](/monitoring/custom-checks/) for more information. For documentation on how to write custom checks, see the [Writing Custom Checks document](/monitoring/custom-checks/writing-custom-checks.md)

The Custom Checks feature can be enabled per bridge transport by using `ReportCustomChecksTo` as follow:
The custom checks feature can be enabled per bridge transport by using `ReportCustomChecksTo` as follow:

snippet: configure-custom-checks

NOTE: Each custom check is executed once, and the result is sent to each bridge transport configured to report custom checks. When configured to [Bridge platform queues](#bridging-platform-queues), it is only necessary to report custom checks on one of the bridge transports. Otherwise, a custom check result will be reported multiple times to the same platform instance.
NOTE: Each custom check is executed once, and the result is sent to each bridge transport configured to report custom checks. When configured to [bridge platform queues](#bridging-platform-queues), it is only necessary to report custom checks on one of the bridge transports. Otherwise, a custom check result will be reported multiple times to the same platform instance.

#### Time-To-Live (TTL)

Expand Down

0 comments on commit c57929a

Please sign in to comment.