Host identifier
In NServiceBus, all messages sent to the audit queue include two extra headers: $.
and $.
. These extra headers uniquely identify the running host for the endpoint, i.e. the operating system host (not to be confused with NServiceBus.
).
The host ID is used by ServiceControl to map a running endpoint to the host where they are deployed. This information is then displayed in ServicePulse and ServiceInsight so it's possible to identify in which host the endpoint is running.
The default values in most scenarios is the machine name for $.
and a hash of the running executable's path concatenated with the machine name for $.
.
Overriding the host identifier
There are scenarios where the rules used by NServiceBus to generate a hostid
and hostdisplayname
are not adequate and the user needs to take control, e.g. in environments where endpoint upgrades are done to a new path or when self-hosting in Azure deployments.
Manual configuration is required when deployments may end up in different paths than previously deployed versions (e.g. using Octopus Deploy). The hostid
must remain the same across restarts unless the physical host has changed.
endpointConfiguration.UniquelyIdentifyRunningInstance()
.UsingNames(
instanceName: "endpointName",
hostName: Environment.MachineName);
// or
var hostId = CreateMyUniqueIdThatIsTheSameAcrossRestarts();
endpointConfiguration.UniquelyIdentifyRunningInstance()
.UsingCustomIdentifier(hostId);
Stable host identifiers when using Docker
Docker containers hosted in Kubernetes pose unique challenges to creating a stable host identifier, as a Deployment will not have a stable, unique identifier. This results in the endpoint having a new, random identity in ServicePulse and ServiceInsight every time the Pod containing the endpoint is (re)scheduled on a different node.
Instead of a Deployment, an endpoint can be deployed to Kubernetes using a StatefulSet, which provides stable, unique network identifiers, allowing the host identifier to be specified as shown above.