Prerequisites for the Nodinite Database Monitoring Agent

Prepare for a seamless deployment of the Nodinite Database Monitoring Agent by reviewing all technical and security prerequisites. This page outlines everything you need to ensure a successful installation and operation in your environment.

✅ Comprehensive software and OS requirements
✅ Clear user rights and security permissions
✅ Network and firewall settings for on-premise and cloud
✅ Support for SQL Server, Azure SQL, and PostgreSQL

This page describes the prerequisites for installing and running the Nodinite Database Monitoring Agent.

Instances of this agent can be installed on-premise using TCP/IP for local network access and/or in the cloud/off-site using Service Bus Relaying (see also the external link for additional information 'Azure Relay FAQs').

We recommend that you keep this agent close to Nodinite Core Services. This documentation covers local network setup (usually on the Nodinite application server)

Software Requirements

The Database Monitoring Agent is a Windows Service and is usually installed on the Nodinite application server.

Versions 6.0 and later make use of the .NET Framework 4.8 or later.
Versions 5.4 and subsequently make use of the .NET Framework 4.6.2 or later.
Versions before 5.4 make use of the .NET Framework 4.5.2 or later.

Supported Versions

Cloud technologies are evolving fast and Microsoft deprecates older versions of their API's every now and then. Nodinite will always support the API's supported by Microsoft. This means you need to update Nodinite and our Database Monitoring Agent from time to time.

This means you need to update Nodinite and our Database Monitoring Agent from time to time.

Make sure to subscribe to our Release Notes

What Windows User Rights does the Database Monitoring agent require?

The agent is installed as a Windows Service usually on the Nodinite application server. Virtual machines are supported.

• Local named account or domain account (preferred).
• Access and run-time rights
  • Follow the 'How to set logon as a Windows service right' user guide for detailed instructions.

What SQL Database User rights does the Database Monitoring agent require?

Remember, if applicable, repeat the grants on all nodes part of the monitoring.

The account used to connect to Microsoft SQL Server is specified in the Microsoft.Data.SqlClient connection string.

Tip

SQL Server Connection Strings: See the comprehensive SQL Server Connection Strings guide for:

• Connection string formats and examples (default instance, named instance, Always On Availability Groups)
• Certificate validation (Encrypt, TrustServerCertificate settings)
• Azure SQL Managed Instance connection strings
• Troubleshooting common connectivity issues
• Security best practices

Type of accounts supported:

• SQL User
• Integrated Security (The account running the Windows Service)

Least privileges (basic usage)

The least privileges required to use all monitoring features are listed below:

• Public - Account must be allowed to login(!)

Note

If you are using High Availability SQL Servers, accounts and rights must be applied on all instances since this information is not synchronized

Master Database

• DataReader
• db_ddladmin (see note)
• Grant Execute on xp_sqlagent_enum_jobs
• Grant View on any Definition

Important

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.

Grant Execute on xp_sqlagent_enum_jobs

Replace DOMAIN\user with your user in the example below:

USE Master
GO
GRANT EXECUTE ON xp_sqlagent_enum_jobs TO [DOMAIN\user];
GO

Example Script to grant the service account the right to read the information required to monitor SQL Server jobs.

Grant View on any Definition

To evaluate the size, the account in use must be granted 'VIEW ANY DEFINITION'.

USE Master
GO
GRANT VIEW ANY DEFINITION TO [DOMAIN\user];
GO

Example script to grant the service account the right to read the information required to monitor Database Size checks.

Grant View Server State

The agent queries the instance about some run-time information using dynamic views;This operation requires the VIEW SERVER STATE permission on the instance.

USE Master
GO
GRANT VIEW SERVER STATE TO [Domain\user]
GO

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

MSDB Database

• DataReader
• db_ddladmin
• SQLAgentReaderRole - Right to read jobs and history
• SQLAgentOperatorRole - Right to re-run jobs

Important

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.

Sample queries performed by the agent

• EXEC msdb.dbo.sp_get_sqlagent_properties
• 'SELECT dss.[status], dss.[status_desc]FROM sys.dm_server_services dss WHERE dss.[servicename] LIKE N'SQL Server Agent (%'`

SSISDB Database

• db_datareader - To list packages
• ssis_logreader (older versions of SQL Server) or ssis_admin (newer versions of SQL Server) - To get the execution history

All other

All other databases require: (for example when using custom Stored Procedures/AdHoc SQL commands)

• Public - Account must be allowed to login(!)
• DataReader and/or Execute Rights on the Stored Procedures/tables/Views/Objects part of your AdHoc queries
• db_ddladmin - for better performance

Important

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.

What Azure SQL Database User rights does the Database Monitoring agent require?

The account used to connect to Azure SQL Database is specified in the Microsoft.Data.SqlClient connection string.

Tip

Azure SQL Connection: See the Azure SQL Managed Instance section in the SQL Server Connection Strings guide for Azure-specific connection requirements, including authentication methods, encryption settings, and firewall configuration.

Type of accounts supported:

• SQL User

What PostgreSQL User rights does the Database Monitoring agent require?

The account used to connect to the PostgreSQL Database comes from information retrieved from the connection string. There can be any number of databases monitored. Type of accounts supported:

• PostgreSQL User

What Firewall settings are required for the Database Monitoring agent?

The Database Monitoring Agent has both inbound and outbound TCP based communication:

1. Between the Monitoring Service and the Database Monitoring Agent
2. Between the Database Monitoring Agent and SQL Server instances
3. Between the Database Monitoring Agent and Azure SQL Databases
4. Between the Database Monitoring Agent and PostgreSQL databases

The agent can be installed On-Premise using TCP/IP and/or in the Cloud using Service Bus Relaying (see also the external link for additional information 'Azure Relay FAQs').

1. Between the Monitoring Service and the Database Monitoring Agent

The following ports must be allowed on the Windows server where the agent is installed and running:

And further with one of the following options depending on your Nodinite version and deployment scenario:

Option 1a (Nodinite v7 - IIS hosted on local network)

Nodinite v7 hosts agents in IIS. When the agent is installed on the same server as the Nodinite application (typical scenario), no additional firewall rules are required between the Monitoring Service and the agent.

Note

Nodinite v7 IIS Hosting: When agents are hosted in IIS on the same server as the Nodinite application (typical installation), firewall rules are not required between the Monitoring Service and the agent. The custom port is assigned during installation via the Nodinite Portal and only needs to be opened if the agent is hosted on a remote IIS Windows Server.

Option 1b (Nodinite v6 and earlier - Windows Service on local network)

Nodinite v6 and earlier versions use Windows Services with RPC communication on port 8000.

Note

Nodinite v6 Legacy: Port 8000 is only used when agents have default installations on remote Windows servers using the legacy MSI installer. This port is not required for Nodinite v7 IIS-hosted agents.

Option 2 (Cloud/Hybrid - All versions)

Use Service Bus Relayed connections when Nodinite and the agent are on totally different networks (cloud, off-site, or across firewalls).

Nodinite uses the same principle technique as the On-Premise data gateway, see 'Adjust communication settings for the on-premises data gateway' user guide.

2. Between the Database Monitoring Agent and Database Servers

The following sections detail firewall requirements organized by service. Four types of servers participate in the monitoring interchange:

• Agent Server - Where the Nodinite Database Monitoring Agent is installed
• SQL Server - On-premises Microsoft SQL Server instances being monitored
• Azure SQL Database - Cloud-based Azure SQL Database instances being monitored
• PostgreSQL Server - PostgreSQL database instances being monitored (on-premises or cloud)
• Domain Controller (DC) - Active Directory server for Kerberos/LDAP authentication (when using Windows authentication)

SQL Server Connection (Agent → SQL Server)

Required for connecting to and monitoring on-premises Microsoft SQL Server instances.

Tip

Comprehensive SQL Server Firewall Guide: See the complete SQL Server Firewall Configuration page for detailed port requirements, Always On Availability Groups (AOAG) configuration, troubleshooting connectivity issues, and testing with PowerShell commands.

Azure SQL Database Connection (Agent → Azure SQL)

Required for connecting to and monitoring Azure SQL Database instances.

PostgreSQL Connection (Agent → PostgreSQL Server)

Required for connecting to and monitoring PostgreSQL database instances.

Authentication (Agent → Domain Controller)

Required if the agent authenticates to on-premises SQL Server instances using Windows authentication (domain credentials).

Note

DNS Resolution: All servers (Agent, SQL Servers, Azure SQL, PostgreSQL, and Domain Controllers) require outbound access to DNS on TCP/UDP port 53 for name resolution. This is already listed in section 1. Between the Monitoring Service and the Database Monitoring Agent and applies universally. You can optionally solve this using entries in the local hosts file on each server.

Tip

Azure SQL Database: No inbound firewall rules are required on the Azure SQL Database side. Azure automatically manages inbound connectivity. You only need to ensure the Azure SQL firewall allows the Agent Server's public IP address. See 'Azure SQL Database and Azure Synapse IP firewall rules' for details.

Important

Stateful Firewalls: Most modern Windows Firewall implementations are stateful, meaning inbound response traffic for established outbound connections is automatically allowed. The inbound rules listed above are primarily for reference and troubleshooting scenarios where stateful inspection may be disabled or restricted.

Frequently asked questions

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

Next Step

Install Database Monitoring Agent

Related Topics

Add or manage a Monitoring Agent Configuration
Monitoring
Administration