How to enable Service Bus Relaying connections for Nodinite Log and Monitoring Agents
What is Service Bus Relaying? The Service Bus relay service from Microsoft enables the Nodinite Monitoring Service to talk with the Nodinite Monitoring Agents. These, may run in both an Azure datacenter and in your own on-premises enterprise environment (even remote on-premises, like your customers and business partners).
443 Listeners on Service Bus Relay over TCP requires 443 for Access Control token acquisition
5671-5672 Advanced Message Queuing Protocol AMQP
This means that you can install and host Nodinite Monitoring Agents anywhere and everywhere! Simply perform the installation and configure it for use with the Service Bus Relaying option.
There is acost associated with running the Nodinite Monitoring Agents using the Service Bus Relaying option.
Cost varies with:
- Number of installed agents using Service Bus Relaying
- Synchronization interval set on the Monitoring Agent Configuration
- State changes in exposed Resources - error-prone environments will cost slightly more...
- Also if the LogText changes - for custom-built Monitoring Agents, make sure the LogText only changes when necessary.
- Caching implemented or not - All Nodinite Monitoring Agents are built with caching support (ETAG). The Nodinite Monitoring Agents are designed and built with caching in mind to reduce costs and improve performance.
- Number of Remote Actions executed
Note: Using the Service Bus Relay induces costs and requires an account with a credit card associated
For the latest information about pricing, read more here.
Here you will find general information that applies to all Monitoring Agents and describes how to configure the communication using Service Bus Relaying.
- An Azure Subscription with a valid credit card
- Your account must be a least Contributor
- Endpoint address must be unique, when you have 2 or more agents of the same type, you may either choose to use separate Namespaces or change the endpoint address in the config file and set correspondingly in the general tab.
- Shared Access Signature security Key. See the following Microsoft article for more information MDSN.
The installed Monitoring Agent has a local configuration file (.config). Within this file, there is a commented Service Bus Relaying configuration. You need to remove the wrapping comments and enter your Service Bus Namespace details.
Note: This is a manual step and requires an RDP session and local administrative rights (a restart of the Monitoring Agent is required). After a restart, the README.txt file should now display the URI to use in the Monitoring Agent Configuration
Example content from a Nodinite Monitoring Agent configuration file
- Uncomment the behaviorExtensions section
- Uncommment this section.
- Change the keyName and key according to you setup in the Azure portal
- Simply uncomment this section.
- Uncomment this section
- Change the ServiceBusNameSpace according to your setup in the Azure portal
Create and select the namespace to use for your Service Bus
From within the Monitoring Agent Configuration, you must change the following settings:
- Service URL
- Enable Authentication
- Set the Authentication Key
In the Service URL field, enter the address to the installed [Monitor Agent][Monitor Agents] (copy this detail from either the Readme.txt file or from the <endpoint address ... section of %Monitoring Agent%.exe.config)
A connection using the Service Bus Relay, has the following format:
You must perform changes to the following three fields:
SharedAccessKeyName - According to your named policy, copy this name from the Azure Portal (Default name is RootManageSharedAccessKey)
SharedAccessKey - Copy from either primary or secondary key
AuthenticationKey - The AuthenticationKey is provided by the Nodinite Monitoring Agent. Copy this value from the local Readme.txt file
The following ports must be open for outbound communication with '*.servicebus.windows.net' from both the on-premise and the off-site location:
|443||HTTPS||Secure outbound traffic|
|5671, 5672||Secure AMQP|
|9350 - 9354||Net.TCP|
To debug connectivity related problems, you may enable WCF diagnostics logging, read more here
Add the following
<system.diagnostics> section to the local configuration file (.config)
Note: The Windows Service Account running the Agent must have write access to the configured folder (C:\Temp\WCFlog\ in the example below, change according to your needs/policy). Make sure the destination folder exists(!)
... <configuration> <system.diagnostics> <sources> <Monitoring Agent Configuration name="System.ServiceModel" switchValue="Information, ActivityTracing" propagateActivity="true" > <listeners> <add name="xml"/> </listeners> </Monitoring Agent Configuration> <Monitoring Agent Configuration name="System.ServiceModel.MessageLogging"> <listeners> <add name="xml"/> </listeners> </Monitoring Agent Configuration> <Monitoring Agent Configuration name="myUserTraceSource" switchValue="Information, ActivityTracing"> <listeners> <add name="xml"/> </listeners> </Monitoring Agent Configuration> </sources> <sharedListeners> <add name="xml" type="System.Diagnostics.XmlWriterTraceListener" initializeData="C:\Temp\WCFlog\Error.svclog" /> </sharedListeners> </system.diagnostics> </configuration> ...
Contact our Support for additional guidance if you fail to resolve the problem.
Note: There may be additional information written to the Windows Event logs.