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 7.2.0 and later require .NET 10 Hosting Bundle.

Versions 7.2.0 and later require the .NET 10 Hosting Bundle—monthly updates are recommended to maintain security patches and performance improvements.
.NET 10 minimum OS: Windows Server 2012 / 2012 R2.
Versions 6.0 - 7.1.x require .NET Framework 4.8 or later.
Versions 5.4 and later require .NET Framework 4.6.2 or later.
Versions before 5.4 require .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

AI Diagnostics

Version 7.2.0 and later includes AI Diagnostics for intelligent error analysis and troubleshooting assistance. AI Diagnostics helps identify root causes of monitoring failures, suggests configuration fixes, and provides contextual guidance for common database issues.

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.

Service Account Options ^{New 7.2.0}

• Group Managed Service Account (gMSA) - Recommended for automated password management. See Configure Group Managed Service Accounts (gMSA) for setup instructions.
• Traditional Account - Use a local named account or, preferably, a domain account.
  • 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

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)

Least privilege is mandatory when you use custom monitoring statements and script collections.

Use the centralized guide for security boundaries, impersonation, connection string isolation, and reusable examples:

Secure Custom Database Scripts and Actions

Least privileges for custom monitoring and script collections

If you use SQL Statements with monitoring statements or User Action Scripts, apply these prerequisites before production rollout:

• Use dedicated SQL identities per scope (monitoring vs action scripts).
• Point connection strings to specific target databases whenever possible.
• Grant only required permissions (SELECT and explicit EXECUTE where needed).
• Never reuse the Database Monitoring Agent service account for custom script execution.
• Validate custom SQL logic in non-production before enabling it for users.

For complete examples and risk scenarios, see Secure Custom Database Scripts and Actions.

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 top 3 performance killers for linked server queries. 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 run-time information using dynamic management views (DMVs). The required permissions depend on your SQL Server version.

Important

SQL Server 2022+: Microsoft introduced granular server state permissions, but the Database Monitoring Agent requires BOTH VIEW SERVER STATE and VIEW SERVER PERFORMANCE STATE to access all necessary DMVs. Grant both permissions as shown below.

SQL Server 2022 and later (required):

USE Master
GO
-- Required for operational DMVs and legacy views
GRANT VIEW SERVER STATE TO [DOMAIN\user];

-- Required for performance monitoring (CPU, memory, disk, waits)
GRANT VIEW SERVER PERFORMANCE STATE TO [DOMAIN\user];
GO

SQL Server 2019 and earlier:

USE Master
GO
-- Grants access to all server state DMVs
GRANT VIEW SERVER STATE TO [DOMAIN\user];
GO

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

Permission comparison:

Note

On SQL Server 2022+, some DMVs were moved under the new VIEW SERVER PERFORMANCE STATE permission while others remain under VIEW SERVER STATE. Both permissions are required for full monitoring capability.

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 top 3 performance killers for linked server queries. Contact our support if you have any questions about this.

Sample queries performed by the agent

-- Check SQL Server Agent properties
EXEC msdb.dbo.sp_get_sqlagent_properties;

-- Check SQL Server Agent service status
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 top 3 performance killers for linked server queries. 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

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?

Where you install the Nodinite Database Monitoring Agent in relation to the Nodinite Monitoring Service and the databases you monitor determines your firewall configuration. The diagram shows every host involved, with the agent on its own server; each arrow starts at the side that opens the connection.

Network diagram: the Monitoring Service calls the agent, and the agent connects to every monitored SQL Server, Azure SQL Database, and PostgreSQL database. Dashed arrows are optional hops.

Note

When the agent runs on the Core Services Server (the typical installation), you need no firewall rule between the Monitoring Service and the agent.

Between the Monitoring Service and the Database Monitoring Agent

The Monitoring Service opens every connection; the agent never calls it. On Windows Server, Nodinite v7 hosts the agent as its own IIS web site, on a port you set per environment in the Nodinite Portal (Servers step).

Option: Service Bus Relaying (cloud or hybrid)

Use Service Bus Relayed connections when Nodinite and the agent are on different networks. Both sides connect outbound to the Azure Relay namespace, so neither server needs an inbound rule. Nodinite uses the same principle as the on-premises data gateway; see 'Adjust communication settings for the on-premises data gateway' and the 'Azure Relay FAQs'.

Tip

For configuring, testing, and troubleshooting AMQP ports 5671 and 5672, see AMQP Port Configuration - 5671 and 5672.

Between the Database Monitoring Agent and SQL Server

Required for monitoring on-premises Microsoft SQL Server instances. See SQL Server Firewall Configuration for Always On Availability Groups (AOAG) and PowerShell connectivity tests.

Between the Database Monitoring Agent and Azure SQL Database

Required for monitoring Azure SQL Database. All connections are outbound from the Agent Server to *.database.windows.net. With the Redirect connection policy (the default for clients inside Azure), the client first reaches the gateway on 1433 and then connects to the database node on a port in the 11000–11999 range; see 'Azure SQL Database connectivity architecture'.

Tip

Azure manages inbound connectivity on the Azure SQL side; you only need a server-level firewall rule that allows the Agent Server's public IP address. See 'Azure SQL Database and Azure Synapse IP firewall rules'.

Between the Database Monitoring Agent and PostgreSQL

Required for monitoring PostgreSQL databases, on-premises or in the cloud (for example IBM Cloud).

Between the Database Monitoring Agent and the Domain Controller

Required when the agent authenticates to SQL Server with Windows authentication (domain credentials). Review 'Microsoft Kerberos'.

Between the servers and DNS

Important

Stateful Firewalls: Most Windows Firewall implementations are stateful, so response traffic for established outbound connections is allowed automatically. The inbound response rules above are for reference and troubleshooting.

Frequently asked questions

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

Next Steps

Install Database Monitoring Agent

Related Topics

Add or manage a Monitoring Agent Configuration
Monitoring
Administration
Secure Custom Database Scripts and Actions
SQL Statements