Merge pull request #6970 from Particular/mt_cleanup

menu and content tweaks

menu/menu.yaml

@@ -1571,9 +1571,9 @@
       Url: servicecontrol/transport-adapter
   - Title: MassTransit
     Articles:
-    - Title: Connector Settings
+    - Title: Introduction
       Url: servicecontrol/masstransit
-    - Title: Docker Deployment
+    - Title: Deployment
       Url: servicecontrol/masstransit/docker-deployment
   - Title: Migrations
     Articles:

platform/masstransit.md

@@ -6,7 +6,7 @@ reviewed: 2025-01-23
 
 The Particular Service Platform is now offering its error management capabilities for MassTransit endpoints on RabbitMQ and Azure Service Bus under the [early access license - for free](https://particular.net/eula/early_access).
 
-This functionality automatically detects and ingests messages from the [error](https://masstransit.io/documentation/concepts/exceptions#error-pipe) and [dead-letter](https://masstransit.io/documentation/concepts/exceptions#dead-letter-pipe) queues for all endpoints running in a MassTransit system.  
+This functionality ingests messages from specified [error](https://masstransit.io/documentation/concepts/exceptions#error-pipe) or [dead-letter](https://masstransit.io/documentation/concepts/exceptions#dead-letter-pipe) queues for endpoints running in a MassTransit system.
 The platform provides an aggregated view of the information necessary to detect, diagnose, and fix problems causing the errors as well as the ability to send failed messages to be reprocessed.
 
 ![MassTransit Fault Management](masstransit-overview-s.png  "width=715")
@@ -32,13 +32,14 @@ During the [early access period](https://particular.net/eula/early_access), this
 
 ### Easy to remove
 
-As the error management capability is packaged in containers, removing it is very simple and straighforward:
+As the error management capability is packaged in containers, removing it is very simple and straightforward:
 
 1. Disable the [ServiceControl-MassTransit-Connector](https://hub.docker.com/r/particular/servicecontrol-masstransit-connector) container
-2. [Retry all the failed messages](/servicepulse/intro-failed-message-retries#servicepulse-interface-retrying-failed-messages)
-3. [Validate that all pending retries have completed](/servicepulse/intro-pending-retries)
-4. [Remove all 4 containers from your system](/servicecontrol/masstransit/docker-deployment)
-5. Done!
+1. [Retry all the failed messages](/servicepulse/intro-failed-message-retries.md#servicepulse-interface-retrying-failed-messages)
+1. [Validate that all pending retries have completed](/servicepulse/intro-pending-retries.md)
+1. [Remove all 4 containers from your system](/servicecontrol/masstransit/docker-deployment.md)
+1. (Optional) Remove the queues utilized by [ServiceControl and the Connector](/servicecontrol/masstransit/#what-queues-are-created)
+1. Done!
 
 ### Questions? Concerns?
 

servicecontrol/masstransit/docker-deployment.md

@@ -1,84 +1,27 @@
 ---
-title: MassTransit Connector Docker Deployment
+title: Deploying MassTransit Connector
 summary: Configuring and running the MassTransit Connector and the rest of the Particular Platform
 reviewed: 2024-12-02
 component: ServiceControl
 ---
 
 ## Overview
 
-When MassTransit is used with the rest of the platform, there are in total 4 containers that get deployed:
+When MassTransit is used with the rest of the platform, there are in total 4 containers that need to be deployed:
 
 1. [particular/servicecontrol](https://hub.docker.com/r/particular/servicecontrol)
 1. [particular/servicecontrol-ravendb](https://hub.docker.com/r/particular/servicecontrol-ravendb)
 1. [particular/servicecontrol-masstransit-connector](https://hub.docker.com/r/particular/servicecontrol-masstransit-connector)
 1. [particular/servicepulse](https://hub.docker.com/r/particular/servicepulse)
 
-The `particular/servicecontrol` and `particular/servicecontrol-ravendb` containers are used to ingest messages from the `error` queue. The `particular/servicecontrol-masstransit-connector` container reads messages from the MassTransit system's error queues and moves them into the `error` queue to be ingested by ServiceControl. The `particular/servicepulse` container exposes a web interface to allow users to retry failed messages back to the MassTransit system.
+The `particular/servicecontrol` and `particular/servicecontrol-ravendb` containers are used to ingest messages from the `error` queue.
 
-## Docker Compose 
+The `particular/servicecontrol-masstransit-connector` container reads messages from the MassTransit system's error queues and moves them into the `error` queue to be ingested by ServiceControl.
 
-> [!NOTE]
-> Depending on the transport, a corresponding block in the `environment` section of the file needs to be uncommented and connection information provided. The RabbitMQ section is uncommented by way of example.
+The `particular/servicepulse` container exposes a web interface to allow users to retry failed messages back to the MassTransit system.
 
-```dockerfile
-name: particular-platform-masstransit-recoverability
-x-transport: &transport-env
-  environment:
-    RAVENDB_CONNECTIONSTRING: "http://servicecontrol-db:8080"
-    ALLOWMESSAGEEDITING: true
-    SHOW_PENDING_RETRY: true
-
-     #[RabbitMQ]
-    TRANSPORTTYPE: "RabbitMQ.QuorumConventionalRouting"
-    CONNECTIONSTRING: "host=host.docker.internal"
-    MANAGEMENTAPI: "http://guest:guest@host.docker.internal:15672"
+## Getting started
 
-    #[AzureServiceBus]
-    #TRANSPORTTYPE: "NetStandardAzureServiceBus"
-    #CONNECTIONSTRING: "<connection-string>"
+The first step is to configure and deploy the `particular/servicecontrol` image, to do this follow [this deployment guide](/servicecontrol/servicecontrol-instances/deployment/containers.md).
 
-    #[Amazon SQS]
-    #TRANSPORTTYPE: "AmazonSQS"
-    #AWS_REGION: "<region>"
-    #AWS_ACCESS_KEY_ID: "<access-key>"
-    #AWS_SECRET_ACCESS_KEY: "<secret-access-key>"
-    #CONNECTIONSTRING: "Region=$AWS_REGION;AccessKeyId=$AWS_ACCESS_KEY_ID;SecretAccessKey=$AWS_SECRET_ACCESS_KEY"
-
-services:
-  service-control-db:
-    container_name: servicecontrol-db
-    image: particular/servicecontrol-ravendb:6
-    volumes:
-      - sc-data:/var/lib/ravendb/data
-  service-control:
-    depends_on:
-      service-control-db:
-        condition: service_healthy
-    container_name: servicecontrol
-    image: particular/servicecontrol:6
-    command: "--setup-and-run"
-    ports:
-      - 33333:33333
-    << : [*transport-env]
-  masstransit-connector:
-    container_name: masstransit-connector
-    image: particular/servicecontrol-connector-masstransit:latest
-    command: "--setup-and-run"
-    << : [*transport-env]
-  service-pulse:
-    depends_on:
-      - service-control
-    container_name: servicepulse
-    image: particular/servicepulse:latest
-    ports:
-        - 9090:9090
-    environment:
-        - SERVICECONTROL_URL=http://localhost:33333/api/
-        - ENABLE_REVERSE_PROXY=false
-        - SHOW_PENDING_RETRY=true
-        - ALLOW_MESSAGE_EDITING=true
-
-volumes:
-  sc-data:
-```
+After that, follow the instructions in Docker Hub on [How to use this image](https://hub.docker.com/r/particular/servicecontrol-masstransit-connector).

servicecontrol/masstransit/index.md

@@ -1,12 +1,10 @@
 ---
 title: MassTransit Connector for ServiceControl
-summary: Configuration and running the MassTransit Connector for ServiceControl
+summary: Introduction to the MassTransit Connector for ServiceControl
 reviewed: 2024-09-04
 component: ServiceControl
 ---
 
-## Overview
-
 The [MassTransit Connector for ServiceControl](https://hub.docker.com/r/particular/servicecontrol-masstransit-connector) is part of the Particular Service Platform, which adds error queue and dead letter queue monitoring to MassTransit systems. This container runs alongside the existing MassTransit system and monitors for any faulted messages that occur within the system.
 
 ## How the MassTransit Connector works
@@ -19,6 +17,8 @@ ServiceControl reads the faulted message, extracting information and metadata ab
 
 The ServiceControl MassTransit Connector creates a queue for transferring messages from ServiceControl back to a consumer's input queue. By default, the queue name is `Particular.ServiceControl.Connector.MassTransit_return`, which can be changed by overwriting the default value using the `RETURN_QUEUE` environment variable.
 
+It also creates a "poison" queue that it starts with the same name as the `RETURN_QUEUE` and appends `.poison` to it. By default, the queue name is `Particular.ServiceControl.Connector.MassTransit_return.poison`. This queue is  only used if there are any messages that the connector fails to process. Should any messages fail to this queue, a warning is raised in the `Custom Checks` section of ServicePulse
+
 In addition, ServiceControl creates queues necessary to facilitate the process of retrying failed messages. These are:
 
 * `error`
@@ -35,7 +35,3 @@ The `Particular.ServiceControl.staging` queue ensures that messages aren't dupli
 The `Particular.ServiceControl.errors` queue tracks any internal errors that may occur within ServiceControl.
 
 Other transport-specific queues might also be created. For example, when using RabbitMQ, a queue called `nsb.v2.verify-stream-flag-enabled` will be created to validate that the setup of the RabbitMQ broker enables streams and quorum queues.
-
-## Settings
-
-For a list of all the supported settings, head over to https://hub.docker.com/r/particular/servicecontrol-masstransit-connector.