Weekly Docs Review

monitoring/custom-checks/writing-custom-checks.md

@@ -1,7 +1,7 @@
 ---
 title: Writing Custom Checks
 summary: Authoring one-off or periodic checks with the Custom Checks plugin
-reviewed: 2022-02-28
+reviewed: 2024-10-30
 component: CustomChecks
 versions: 'CustomChecks:*'
 ---
@@ -10,9 +10,9 @@ To create a custom check, create a new custom check class:
 
 snippet: CustomCheck
 
-When the custom check executes, it should return a pass or fail status, and in the case of failure, a descriptive message. This status and descriptive message will be sent to ServiceControl and will appear in the [ServicePulse UI](in-servicepulse.md) and in [ServiceControl integration events](notification-events.md).
+When the custom check executes, it should return a pass or fail status and, in the case of failure, a descriptive message. This status and descriptive message will be sent to ServiceControl and will appear in the [ServicePulse UI](in-servicepulse.md) and in [ServiceControl integration events](notification-events.md).
 
-All custom checks are executed when the endpoint starts up. If the optional interval is specified then the custom check will be executed periodically.
+All custom checks are executed when the endpoint starts up. If the optional interval is specified, the custom check will be executed periodically.
 
 snippet: PeriodicCheck
 

monitoring/metrics/index.md

@@ -1,7 +1,7 @@
 ---
 title: Metrics
 summary: Collect metric data about endpoint performance using the Metrics plugin
-reviewed: 2022-02-28
+reviewed: 2024-10-30
 component: Metrics
 versions: 'Metrics:*'
 related:
@@ -13,7 +13,7 @@ related:
 
 partial: opentelemetry
 
-The Metrics plugin collects metric data about the performance of running endpoints. This data can be forwarded to a ServiceControl monitoring instance and then viewed in ServicePulse.
+The Metrics plugin collects metric data about the performance of running endpoints. This data can be forwarded to a ServiceControl monitoring instance and viewed in ServicePulse.
 
 To see performance monitoring in action, try the [standalone demo](/tutorials/monitoring-demo/).
 
@@ -49,15 +49,15 @@ To enable collecting metrics in an environment:
 
 ## Performance impact on system resources
 
-A ServiceControl monitoring instance is more lightweight than a regular ServiceControl instance. Nevertheless, it is not recommended to host a monitoring instance on the same machine that is hosting production endpoint instances.
+A ServiceControl monitoring instance is more lightweight than a regular ServiceControl instance. Nevertheless, it is not recommended to host a monitoring instance on the same machine as production endpoint instances.
 
 ### Wire usage
 
-Each endpoint instance collects performance metrics which are buffered and then sent. A single metrics message contains a batch of values written in a compact binary format, making reporting very lightweight.
+Each endpoint instance collects performance metrics, which are buffered and then sent. A single metrics message contains a batch of values written in a compact binary format, making reporting very lightweight.
 
 ### Storage usage
 
-A Service Control Monitoring instance processes Metric. The metric data is stored in RAM only. Logfiles are still written to disk. The metrics data are stored for at most one hour. A 100MB process can hold state for at least 100 endpoint instances.
+A Service Control Monitoring instance processes Metrics. The metric data is stored in RAM only. Logfiles are still written to disk. The metrics data are stored for at most one hour. A 100MB process can hold state for at least 100 endpoint instances.
 
 ### CPU usage
 

persistence/mongodb/document-version.md

@@ -5,15 +5,15 @@ component: mongodb
 versions: '[2,)'
 related:
  - persistence/mongodb
-reviewed: 2022-02-18
+reviewed: 2024-10-30
 ---
 
 MongoDB provides no out-of-the-box concurrency control. A common pattern for supporting concurrency is using a document version number (`int`) that is used as a filter for update statements:
 
 snippet: MongoDBUpdateWithVersion
 
-By updating the document with a filter specifying the expected current version of the document, no update will be made if another process has incremented the version before the current process is able to. This makes sure only one process/thread can update the saga at a time.
+By updating the document with a filter specifying the expected current version of the document, no update will be made if another process has incremented the version before the current process is able to. This ensures only one process/thread can update the saga at a time.
 
-This pattern requires an element in the `BsonDocument` to store the current version value. Instead of requiring the user provide this as a property of their saga data type, this package uses the MongoDB client's BSON serializer to add a version element to the serialized saga data as it is initially created and stored in the collection. When the serialized `BsonDocument` is later fetched, the version element's current value is retrieved before deserializing it to the saga data type. The current value is then retained for the lifetime of the saga message processing and is used to create the update filter.
+This pattern requires an element in the `BsonDocument` to store the current version value. Instead of requiring the user to provide this as a property of their saga data type, this package uses the MongoDB client's BSON serializer to add a version element to the serialized saga data as it is initially created and stored in the collection. When the serialized `BsonDocument` is later fetched, the version element's current value is retrieved before deserializing it to the saga data type. The current value is then retained for the lifetime of the saga message processing and is used to create the update filter.
 
-By default, the `BsonDocument` element is named `_version`.
+By default, the `BsonDocument` element is named `_version`.

samples/consumer-driven-contracts/sample.md

@@ -1,16 +1,16 @@
 ---
 title: Consumer-driven Contracts sample
 summary: NServiceBus sample that shows a consumer-driven contract (CDC) approach to messaging.
-reviewed: 2022-02-25
+reviewed: 2024-10-30
 component: Core
 versions: '[6,)'
 ---
 
 ## Introduction to consumer-driven contracts
 
-This sample shows a [consumer-driven contract](https://martinfowler.com/articles/consumerDrivenContracts.html)(CDC) approach to messaging. The essence of consumer-driven contracts is that the ownership of the contract is inverted. Instead of the producer providing the definition, consumers define the contract they expect, and it's up to the producer to fulfill it.
+This sample shows a [consumer-driven contract](https://martinfowler.com/articles/consumerDrivenContracts.html)(CDC) approach to messaging. The essence of consumer-driven contracts is that the ownership of the contract is inverted. Instead of the producer providing the definition, consumers define the contract they expect, and it's up to the producer to fulfil it.
 
-In NServiceBus terminology, "producers" are called "publishers" and "consumers" are called "subscribers". Contracts translate to message contracts and are defined using plain C# types. To honor a consumer contract, the producer would make the relevant message contract inherit from the consumer contract type.
+In NServiceBus terminology, "producers" are called "publishers", and "consumers" are called "subscribers". Contracts translate to message contracts and are defined using plain C# types. To honor a consumer contract, the producer would make the relevant message contract inherit from the consumer contract type.
 
 ## Contracts as interfaces