Prerequisites for the Monitoring Service
The Monitoring Service is a Windows Service and is very easy to install on a single box machine where you may have virtually no administration at all to get everything working. On the other hand, in a locked down distributed environment spanning multiple servers with network load balancing, firewalls, network zones (WLAN's), domains, DNS, group policies, anti virus/antimalware you may end up spending a lot of hours to get every piece of the puzzle in place.
|SMTP - Monitoring Service must be allowed to send emails|
Use the checklist above to verify that you have performed all steps required to get Nodinite flying (most probably already managed when you performed similar tasks for the Configuration Database)
Alerts are sent using Alarm Plugins and it is very common to use any of the Nodinite e-mail plugins.
The Nodinite Monitoring Service must be allowed to send emails and this is often governed by your organizations policies.
The Monitoring Service is involved in SQL Server related operations and Nodinite uses the Windows Service Microsoft Distributed Transaction Coordinator (DTC) that is responsible for coordinating transactions that span multiple resource managers. We have written a dedicated tutorial for Nodinite with our best practices for how to install and configure the DTC Windows Service.
You must configure the DTC as documented otherwise Nodinite will not be able to function
The Monitoring Service is a Windows Service and requires privileges as described in the 'Windows Service Account' page.
- The Windows identity must have SQL rights, see next paragraph
- This service should always be running
- This service should not be clustered, contact our support if you need technical assistance
- DCOM Local Activation Permission
The Windows domain account being used for the Monitoring Service must have the following SQL rights assigned (least privileges):
- public - Rights to logon to instances and databases
- db_ddladmin - se note below
db_ddladmin is required for the service account to have proper rights to read statistics. Without this permission, performance may be degraded, especially true for remote servers (linked servers). Read more here. Contact our support if you have any questions about this.
All Nodinite specific databases
- Grant Execute rights on all existing and future stored procedures:
GRANT EXECUTE TO [Domain\user]
Replace [Domain\user] with the Windows account being used for the Monitoring Service
NodiniteLog_* (can be multiple )
The Monitoring Service requires both inbound and outbound ports to be opened. Since Nodinite is highly configurable, the actual ports in use may differ from what's being exampled here.
- TCP Ports between Monitoring Service and Monitoring Agents The following ports must be allowed on the Windows server where the agent is installed and running:
|53||DNS||The Agent needs to know where your other servers/services are (can sometimes optionally be solved using entries in the local hosts file)|
And further with 'Option 1' or 'Option 2' as documented next:
|8000||RPC||Communication initiated by the Monitoring Service|
Use Service Bus Relayed connections when Nodinite and the agent are on totally different networks.
Nodinite uses the same principle technique as the On-Premise data gateway, see 'Adjust communication settings for the on-premises data gateway' user guide.
The following Ports must be open for outbound communication with '*.servicebus.windows.net' from both on-premise and off-site:
|443||HTTPS||Secure outbound traffic|
|5671, 5672||Secure AMQP|
|9350 - 9354||Net.TCP|
Monitoring Service and Alarm Plugins
- 25 - SMTP as described in RFC 5321
- 443 - SSL
- 587 - SMTP-MSA as described in RFC 6409
- 465 - SMTPS as described in RFC8314 (Not common any more)
- Any other port your custom built Alarm Plugin may require
- TCP Ports between Monitoring Service and SQL Server
443 Listeners on Service Bus Relay over TCP requires 443 for Access Control token acquisition
5671-5672 Advanced Message Queuing Protocol AMQP
Nodinite shows the state of the Monitoring service for Users within the Web Client. The Web Client asks the Web API which in turns queries the Monitoring Service. The Monitoring Service uses the Web API to provide all its features.
Alerts are distributed by the Monitoring Service for Monitor Views when a configuration matches a changed state of Resources. The alert is pushed to each 'Alarm Plugin'. Nodinite ships with default alarm plugins and it is possible for you to add your own Alarm Plugins. These are DLL's written in any .NET language. Templates and SDK is intended for use with C#.
Depending on what external services your custom built Alarm Plugin uses you may need ensure open TCP ports according to the requirements of that external service provider.
You simply copy the DLL to the 'Plugins' folder of the Monitoring Service. If the DLL is being replaced then you must restart the Monitoring Service.
Make sure the DLL after the copy paste operation is not blocked by Windows. Right-click on the DLL and select properties. Click on the Unblock button if that option exists
- TCP Ports between Monitoring Service and SQL Server
For performance reasons the Monitoring Service accesses the databases directly using the Windows Service Account configured.
You must ensure that TCP ports used are allowed by your firewalls, depending on location of the SQL database the actual ports used may differ. The following Windows Services are involved:
|53||DNS||The Agent needs to know where your other servers/services are (can sometimes optionally be solved with user-defined entries in the
|88||Kerberos||Review 'Microsoft Kerberos' user guide|
|135||DTC/RPC||This port is shared between many Windows Services|
|1433/...||SQL Server instance ports (multiple)||Depends on policies and settings on target environment. Please review the How to configure RPC dynamic port allocation to work with firewalls user guide|