Concepts

Teams

In Fleet Manager, you're most likely part of a team, as this is the recommended way of managing users and their access to accounts.

Teams offer a model where accounts (i.e. individual environments/systems/networks) can be created and "hosted", thus giving all members of the team access.

Team members can have one of two roles:

1. Member – can only view information on the team
2. Administrator – can create accounts, invite other members, and promote members from Member to Administrator

All team members can retry messages, archive them, edit alert rules, etc.

Accounts

Accounts in Fleet Manager are namespaces for queues and machines, as every queue and machine is identified by its name within an account.

Typically, you want at least one Account for each environment (like development/test/staging/production) you have, but you might also want Accounts for each application you have running if they're comprised of many bus instances/queues/machines.

Each Rebus instance configured to forward events to Fleet Manager will forward its events to a specific account! – which one is determined by an account ID embedded in the API key you use to configure the plugin.

⚠️ Please be aware that all Rebus instances connected to a specific account MUST BE CONNECTED TO THE SAME MESSAGE BROKER INSTANCE, otherwise Fleet Manager's message retry mechanism and delayed messages functionality will not work as expected. In other words, any Rebus instance connected to an account must be able to reach any other Rebus instance via its input queue.

Plugin

"The plugin" is what makes it possible for a Rebus instance to connect with Fleet Manager. You configure the plugin by installing the Rebus.FleetManager NuGet package, and then you call the EnableFleetManager extension method (with at least a URL and an API key) somewhat like this (if you're using Microsoft DI):

services.AddRebus(
    configure => configure
        .(...)
        .Options(o => o.EnableFleetManager(url, apiKey))
);

or like this (if you're using a container adapter for an older DI container):

Configure.With(...)
    .(...)
    .Options(o => o.EnableFleetManager(url, apiKey))
    .Start();

and then that instance will report various things to Fleet Manager.

You can read more about configuring the plugin here: Configuring the Fleet Manager Plugin

Dead-letter Queues

If you've worked with Rebus before, you're probably used to having poison messages (i.e. messages that cannot be consumed due to exceptions) stored in an "error queue" (which in the literature is also known as "dead-letter queue", "poison message queue", etc.).

Fleet Manager changes that!

The plugin will, when you EnableFleetManager, install itself as the default way to handle poison messages in your Rebus instance. This means that messages will no longer be stored in a dead-letter queue, they will be saved in Fleet Manager instead!

Poison messages are saved in Fleet Manager with an at-least-once delivery guarantee, and Fleet Manager does deduplication based on the message ID and the source queue name, so failed messages are guaranteed to be handled with exactly-once semantics.

This means that your poison messages can be seen in Fleet Manager – and you can even return them to their source queues (or any other queue known to Fleet Manager) from the UI.