- 11 minutes to read

Prerequisites for the Nodinite Monitoring Service

Prepare your environment for a seamless Nodinite Monitoring Service deployment. This page lists what the Monitoring Service needs from your network, Windows, and SQL Server, so that the installation succeeds and the service can reach your Monitoring Agents, Alarm Plugins, and databases.

In Nodinite v7 on Windows, the Monitoring Service is one of the Core Services: an IIS web site of its own on the Core Services host. You set its port and service identity in the Nodinite Portal (Servers step → Core platform services), and the generated CLI package installs it. The general v7 requirements are in the Install Nodinite v7 prerequisites summary; this page adds what is specific to the Monitoring Service.

Nodinite Monitoring Service Checklist

The Monitoring Service is easy to install on a single server, but in distributed or locked-down environments (with load balancing, firewalls, network zones, domains, DNS, group policies, antivirus, etc.), you may need to address additional requirements for a smooth setup.

Verified Topic
SMTP - Monitoring Service must be allowed to send emails
MSDTC
Windows rights
Database rights
Firewall

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).

SMTP Settings

Alerts are sent using Alarm Plugins and it is very common to use any of the Nodinite e-mail plugins. If alerts don't arrive, see Alarm Plugin troubleshooting.

The Nodinite Monitoring Service must be allowed to send emails and this is often governed by your organization's policies.

The SMTP ports are listed under Between the Monitoring Service and the Alarm Plugin targets.

Microsoft Distributed Transaction Coordinator (DTC)

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.

What Windows rights does the Monitoring Service require?

The Monitoring Service runs under the service identity you set in the Portal: the Service Account Defaults of the Auth step, or a separate account per service when you clear Same account for all Services in the Servers step. Group Managed Service Accounts (gMSA) are supported. The CLI configures the IIS web site and its application pool with this identity during installation; you don't set it by hand.

Service Account Requirements

  • The service account must have Logon as a Service rights - see How to set Logon as a Service right
  • The service account must have appropriate SQL Server rights (see next section)
  • The service account must have write rights to the installation folder, so that the service can write its diagnostics files
  • This service should always be running
  • This service should not be clustered - To contact our support, read more on the Support page and learn how to get technical assistance
  • DCOM Local Activation Permission is required for the service to function properly

How It Works

With this identity, the Monitoring Service reads its settings and System Parameters from the Configuration Database, coordinates with Monitoring Agents, executes Remote Actions, and delivers alerts through Alarm Plugins.

What SQL Rights does the Monitoring Service require?

The Windows domain account being used for the Monitoring Service must have the following SQL rights assigned (least privileges). The SQL Server instance and connection are set in the Portal (Infrastructure step); the SqlServer System Parameter holds the server, listener, and Linked Server names that the service uses at run time.

Master

The grants depend on the type of SQL Server instance:

>= SQL Server 2016 < SQL Server 2016
db_owner db_datareader

Grant VIEW SERVER STATE rights.

GRANT VIEW SERVER STATE TO [Domain\user]

Replace [Domain\user] with the Windows account being used for the Monitoring Service.

If applicable, repeat the grant on all nodes part of an AOAG environment.

Nodinite Databases

All databases on all SQL Instance(s)—where Configuration Database and Log Databases databases are located:

Scope Permission / Role Description Microsoft Docs Link
Instance/Database public Right to log on to SQL instances and databases used by Nodinite public role
Database db_ddladmin Required so the service account can run necessary DDL (and read statistics) for performance-sensitive operations, especially across linked servers db_ddladmin

Important

db_ddladmin is required for the service account to have proper rights to read statistics. Without this permission, performance may be degraded, especially for remote servers (linked servers). Read the linked server query performance guidance. Contact our support if you have any questions about this.

All Nodinite specific databases

Database Permission Description Microsoft Docs Link
Configuration Database db_datareader Grants read access to all tables and views db_datareader
Configuration Database db_datawriter Grants write access to all tables and views db_datawriter
Configuration Database db_ddladmin Allows running DDL statements (e.g., create/alter/drop objects) db_ddladmin
Configuration Database sysadmin/db_owner Required for certain administrative tasks (e.g., shrinking databases) sysadmin, db_owner
NodiniteLog_* db_datareader Grants read access to all tables and views db_datareader
NodiniteLog_* db_datawriter Grants write access to all tables and views db_datawriter
NodiniteLog_* db_ddladmin Allows running DDL statements (e.g., create/alter/drop objects) db_ddladmin
NodiniteLog_* sysadmin/db_owner Required for certain administrative tasks (e.g., shrinking databases) sysadmin, db_owner

This table lists the minimum SQL Server permissions required for the Nodinite Monitoring Service's Configuration Database and Log Databases. Ensure these grants are set for uninterrupted operation, maintenance, and automation.

For the full rights matrix and non-sysadmin operating model, see SQL Server Sysadmin Requirements.

Grant Execute rights on all existing and future stored procedures for the account used by the Monitoring Service:

GRANT EXECUTE TO [Domain\user]

Replace [Domain\user] with the Windows account being used for the Monitoring Service.

What Firewall settings are required for the Monitoring Service?

The Monitoring Service runs the monitor checks and sends alerts, so it talks to more hosts than any other Core Service: the Monitoring Agents, the Web API, the mail server and other Alarm Plugin targets, SQL Server, and the domain controller. The Monitoring Service opens almost every connection itself. The diagram shows each host, with the port on the arrow, drawn from the side that opens the connection.

graph LR subgraph "Nodinite Core Services Server" roMS["fa:fa-watch-fitness Monitoring Service - IIS"] roWebAPI["fa:fa-cloud-sun Web API - IIS"] end subgraph "Nodinite Agent Server" roAgent["fa:fa-monitor-waveform Monitoring Agent - IIS"] end subgraph "Azure Service Bus Relay - off-site agents only" roRelay["fa:fa-cloud *.servicebus.windows.net"] end subgraph "Off-site Agent Server" roAgentRemote["fa:fa-monitor-waveform Monitoring Agent"] end subgraph "SQL Server" roConfig["fa:fa-database Configuration Database"] end subgraph "Mail server and alarm targets" roSMTP["fa:fa-envelope SMTP server"] roHook["fa:fa-globe HTTP Webhook targets"] end subgraph "Domain Controller" roDC["fa:fa-server DNS, Kerberos, LDAP"] end roMS -->|"Agent port"| roAgent roWebAPI -->|"Agent port"| roAgent roMS -->|"443, 5671-5672, 9350-9354"| roRelay roAgentRemote -->|"443, 5671-5672, 9350-9354"| roRelay roMS -->|"Web API port"| roWebAPI roWebAPI -->|"Monitoring Service port"| roMS roMS -->|"TCP 1433, MSDTC 135 + RPC"| roConfig roMS -->|"25 or 587"| roSMTP roMS -->|"443"| roHook roMS -->|"53, 88, 389"| roDC

Diagram: the Monitoring Service, and the Web API for user actions, call each Monitoring Agent on the agent's port; or through Azure Service Bus Relay for off-site agents; it calls the Web API, SQL Server, the mail server, alarm targets, and the domain controller. Only the Web API calls back in.

Ports Set in the Nodinite Portal

On Windows Server, each Core Service, including the Monitoring Service and the Web API, is its own IIS web site with its own port, and so is each Monitoring Agent. You choose the Core Services ports per environment in the Portal (Servers step → Core platform services), the agent ports in the Agents step, and confirm them in the Allocated ports summary before you download the package. Ports in examples, such as 40000–40004, are examples only. Open exactly those ports; the CLI configures the IIS bindings but not your firewalls.

Between the Monitoring Service and the Monitoring Agents

The Monitoring Service opens the connection to each Monitoring Agent, using the address set on the agent's Connection tab. The Web API also calls the agent directly, at the same address, when users run Remote Actions, view metrics, open the agent's Remote Configuration, take configuration backups, download diagnostics, or check the agent's status. Both run on the Core Services Server, so one rule covers both. When the agent runs on the Core Services Server, no firewall rule is needed. Each agent's own Prerequisites page lists the ports between the agent and the system it monitors.

Direction Source Destination Protocol Port(s) Purpose Notes
Inbound Core Services Server (Monitoring Service and Web API) Agent Server TCP (HTTP or HTTPS) Agent port Monitoring Service: poll Resources. Web API: Remote Actions, metrics, Remote Configuration, backups, diagnostics, status One port per agent, set in the Portal; only needed when the agent runs on another server
Outbound Core Services Server (Monitoring Service) Azure Service Bus Relay (*.servicebus.windows.net) TCP 443, 5671–5672, 9350–9354 Reach off-site agents through Service Bus Relaying Only for agents on another network; HTTPS, AMQP over TLS, and Net.TCP relay
Outbound Off-site Agent Server Azure Service Bus Relay (*.servicebus.windows.net) TCP 443, 5671–5672, 9350–9354 The agent listens on the relay No inbound rule on the agent's network; same principle as the on-premises data gateway
Outbound Agent Server DNS server TCP/UDP 53 DNS name resolution The agent must resolve its targets and, for Service Bus Relaying, the relay host name

Between the Monitoring Service and the Web API

The Web Client shows the state of the Monitoring Service to Users: it asks the Web API, which queries the Monitoring Service. The Monitoring Service also uses the Web API for its features. Both run on the Core Services Server, so no rule is needed unless a host firewall restricts local traffic.

Direction Source Destination Protocol Port(s) Purpose Notes
Outbound Core Services Server (Monitoring Service) Core Services Server (Web API) TCP (HTTPS) Web API port Monitoring Service features Set in the Portal
Inbound Core Services Server (Web API) Core Services Server (Monitoring Service) TCP (HTTPS) Monitoring Service port Status and operations requested from the Web Client Set in the Portal

Between the Monitoring Service and the Alarm Plugin targets

Alerts are distributed by the Monitoring Service for Monitor Views when a configuration matches a changed state of Resources; each alert is pushed to each Alarm Plugin. Nodinite v7 loads only the built-in Alarm Plugins; custom or 3rd-party plugin DLLs are not loaded.

Direction Source Destination Protocol Port(s) Purpose Notes
Outbound Core Services Server (Monitoring Service) Mail server TCP 587 or 25 Send alarm e-mail (SMTP submission or SMTP) 587 per RFC 6409; 25 per RFC 5321. Mail policies often govern who may relay; see SMTP Settings
Outbound Core Services Server (Monitoring Service) Mail server TCP 465 Send alarm e-mail over implicit TLS (SMTPS) Only if your mail server requires it, per RFC 8314
Outbound Core Services Server (Monitoring Service) Webhook target, issue tracker, or chat service TCP (HTTPS) 443, or the target's port Deliver alerts with the HTTP Webhook Alarm Plugin Allow the host names of each target

Between the Monitoring Service and SQL Server

For performance reasons, the Monitoring Service accesses the databases directly using its service identity. The SQL Server, MSDTC, and domain controller ports are shared by all Nodinite components; their full details live in SQL Server Firewall Configuration.

Direction Source Destination Protocol Port(s) Purpose Notes
Outbound Core Services Server (Monitoring Service) SQL Server (Configuration Database) TCP 1433 Read configuration, store state Default instance port; the Log Databases are reached through the Configuration Database's Linked Servers. Named instances and changed ports: Core Services to SQL Server
Outbound Core Services Server (Monitoring Service) SQL Server UDP 1434 SQL Server Browser Only for a named instance without a port in the connection string; see SQL Server Browser Service
Both Core Services Server (Monitoring Service) SQL Server TCP 135 + dynamic RPC range MSDTC distributed transactions Configure MSDTC on both servers; see Core Services to SQL Server

Between the Core Services Server and the domain controller

Direction Source Destination Protocol Port(s) Purpose Notes
Outbound Core Services Server Domain Controller (DNS server) TCP/UDP 53 DNS name resolution Resolve agent, SQL Server, mail server, and relay host names; hosts-file entries are a fallback
Outbound Core Services Server Domain Controller TCP/UDP 88, 389 Kerberos and LDAP for Windows authentication to SQL Server and agents See Domain Controller ports

What to get right

  • No fixed default ports: the Monitoring Service, Web API, and agent ports are what you set in the Portal; check the agent's Service URL on its Connection tab when an agent shows as unavailable.
  • Same server: no rule is needed between the Monitoring Service and an agent that runs on the Core Services Server.
  • Versions: Nodinite v6 agents and the v6 Monitoring Service used TCP port 8000; see Why do Nodinite use port 8000, and replace those rules with the Portal ports when you follow Updating from v6 to v7.
  • Outbound-only off-site agents: with Service Bus Relaying, only outbound HTTPS (443) and the relay ports to *.servicebus.windows.net are needed, from both sides.
  • DNS (53): every host must resolve the others by name, including the agent host names in the Service URLs.

Frequently asked questions

Additional solutions to common problems and the Nodinite Monitoring Service FAQ exist in the Troubleshooting user guide.

Note

Nodinite v6 is no longer supported. To move an existing v6 installation, follow Updating from v6 to v7; its Monitoring Service used TCP port 8000, so update your firewall rules to the new Portal ports.

Next Steps

Install Monitoring Service
Install Nodinite v7
System Parameters

Alarm Plugins
Alarm Plugin troubleshooting
Configuration Database
Core Services
Log Databases
Monitoring Agents
Monitoring Service
Monitor Views
MSDTC
Remote Actions
Resources
Service Bus Relaying
SQL Server Firewall
gMSA accounts
Troubleshooting
Uninstall Monitoring Service
Update Monitoring Service
Users
Web API