- 8 minutes to read

Managing the Monitoring Service

Understanding Monitoring Service Management

The Nodinite Monitoring Service is a critical service component in the v7 Core Services deployment that evaluates the health of Resources, synchronizes with Monitoring Agents, and delivers alerts through Alarm Plugins. As a Nodinite administrator, you manage its configuration, maintenance windows, and operational parameters to ensure reliable monitoring and compliance with your organization's policies.

You manage the Monitoring Service in the Nodinite Web Client. Installation settings, such as its port and service identity, are set in the Nodinite Portal (Servers step → Core platform services) and applied when you update the environment.

Key Management Capabilities

  • Configure behavior – Control Monitor Event and agent backup retention, and alarm retries, through System Parameters
  • Schedule maintenance – Temporarily mute alerts during planned downtime using User Notifications
  • Ensure alert delivery – Leverage the Alarm Queue for resilient alerts that survive temporary service outages
  • Manage monitoring service operations – Stop the service when you update Log Databases to prevent conflicts
  • Troubleshoot issues – Analyze service diagnostics files and Log Audits to resolve problems

System Parameters for Monitoring Service

The Monitoring Service behavior is controlled by System Parameters stored in the Nodinite Configuration Database. The Monitoring Service reads these:

The Monitoring Service Overview keeps this list with one line per parameter. To change a value, follow Manage System Parameters (requires the Administrator Role). Every value takes effect within about 15 seconds; the Monitoring Service never needs a restart for a System Parameter change.

Note

MissingEventsDays and CleanUpTimerInterval are read by the Logging Service, not the Monitoring Service. See the Logging Service Data Retention section.

Service Management Operations

Stopping the Service for Log Database Updates

When you update the schema of the Nodinite Log Databases, stop the Monitoring Service and the Logging Service first to prevent database write conflicts during the update.

The Update Log Database guide in the Web Client walks you through this:

  1. Stop Services – Use the Stop Services button to stop the Monitoring Service and Logging Service
  2. Update Database Schema – Run the generated DACPAC scripts
  3. Restart Services – Start both services again to resume normal operation

Important

Always stop the Monitoring Service before updating Log Databases. Failure to do so can cause update errors or database corruption. The MaintenanceMode System Parameter is a Web API flag and does not pause the services.

Maintenance Mode During Planned Downtime

During planned maintenance windows, you can temporarily suppress monitoring alerts and disable Auto Healing actions using Maintenance Mode, which you configure through User Notifications:

  • Set Type/Severity to Maintenance when creating a User Notification
  • Specify the Start time and End time for the maintenance window
  • Select All Monitor Views or a subset of Monitor Views to include
  • Optionally configure Recurrence for scheduled maintenance (e.g., weekly patching)

What Happens During Maintenance Mode

  • Mute alerts – Alarm Plugins will not send notifications for selected Monitor Views
  • Disable Auto Healing – Automated recovery actions on Resources are suspended
  • Display notification – Users see the maintenance window on the Dashboard and in the Notifications area

Tip

Use recurring maintenance windows for routine patching schedules (e.g., "Second Tuesday of every month, 2:00 AM - 4:00 AM").

Read more in What is a User Notification? - Maintenance Mode and Add or Manage User Notification.

Alarm Queue and Resilient Alert Delivery

New 7.x
Nodinite version 7 introduces the Alarm Queue for resilient alert delivery. If an Alarm Plugin fails to send an alert (due to network issues, service outages, or misconfiguration), the alert is queued for automatic retry. This ensures resilient alerts reach recipients even when temporary service disruptions occur.

How the Alarm Queue Works

  1. Alert fails to send – Network timeout, service unavailable, or authentication error occurs
  2. Entry added to queue – Alert payload and metadata are saved to the Alarm Queue
  3. Automatic retry – The Monitoring Service resends queued alerts, up to MaxRetries times (0 = retry forever), and gives each send at most TimeoutSeconds, as set in AlarmQueueSettings
  4. Success – Entry is removed automatically once the alert is successfully delivered
  5. Failure – After the last retry, the entry stays in the queue and is left alone; administrators must investigate

Benefits

  • Never lose critical alerts – Temporary outages won't result in missed notifications
  • Automatic recovery – Once the underlying issue is resolved, queued alerts are sent automatically
  • Full visibility – Queued entries remain visible for audit and troubleshooting

Note

If there are entries in the Alarm Queue, Nodinite displays a prominent alert for all users on the Dashboard, signaling the need for administrative attention.

Read more in the Alarm Queue Overview (queue management and purging) and What is an Alarm Queue Entry? (queue entries, retry logic, and manual removal).

Data Retention and Automated Cleanup

The Monitoring Service purges old Monitor Events every hour (DaysToKeepMonitorEvents) and cleans Monitoring Agent configuration backups once a day and right after it starts (DaysToKeepMonitorAgentBackups). The Data Retention section of the Monitoring Service Overview describes both. Message data, incomplete BizTalk events (MissingEventsDays), and the CleanUpTimerInterval cleanup run belong to the Logging Service.

Tip

If you need longer retention for compliance (SOX, HIPAA, GDPR, etc.), increase the DaysToKeepMonitorEvents value before you need the history; purged events can't be restored. For large-scale environments with thousands of Resources, consider reducing retention to optimize database size.

Troubleshooting and Diagnostics

When experiencing issues with the Monitoring Service, Nodinite provides multiple diagnostic tools to identify and resolve problems.

Viewing Service Diagnostics

The Monitoring Service generates diagnostic files containing detailed operational information, error logs, and performance metrics. They are written below the Monitoring Service installation folder; the install path is set per server in the Portal (Servers step → Selected server).

Diagnostics file location (default install path):

C:\Program Files\Nodinite\{EnvironmentName}\MonitoringService\DiagnosticsFiles\

Note

Replace {EnvironmentName} with your environment name (e.g., DEMO, Production, Test). For example: C:\Program Files\Nodinite\DEMO\MonitoringService\DiagnosticsFiles\diagnostic.log.json.

Diagnostic File Format

  • Primary file: diagnostic.log.json – Current diagnostic log in JSON format
  • Rollover files: diagnostic.log_001.json, diagnostic.log_002.json, etc. – Previous diagnostic logs after rotation

Diagnostic File Contents

  • Service startup and shutdown events
  • Monitoring Agent synchronization attempts
  • Alarm Plugin execution results and error messages
  • Configuration changes and parameter values
  • Error stack traces and exception details
  • Performance metrics and timing information

Warning

Diagnostics files may reveal internal errors not visible in the Nodinite Web Client. Always review diagnostics when troubleshooting service behavior. If the files are missing, check that the service identity has write rights to the folder.

Using Log Audits for Investigation

All administrative actions related to the Monitoring Service are logged in Nodinite's Log Audits feature. Use Log Audits to:

  • Track configuration changes – See who modified Monitor Views, Alarm Plugins, or System Parameters
  • Investigate alert failures – Review Alarm Plugin execution history and error messages
  • Audit compliance – Generate reports for SOX, HIPAA, or ISO 27001 compliance requirements
  • Identify user actions – Determine who executed Remote Actions or disabled Auto Healing

To access Log Audits:

  1. Log on to the Nodinite Web Client
  2. Navigate to Administration | Tools | Log Audit Search
  3. Filter by date range, user, or action type
  4. Review audit records for relevant Monitoring Service activities

See Log Audit Search for querying and exporting audit logs.

Common Troubleshooting Scenarios

Problem Diagnostic Source Resolution
Alerts not being sent Alarm Queue + Diagnostics file Check for queued entries, review plugin configuration and AlarmQueueSettings, verify network connectivity
Alert Stylesheet fails Diagnostics file A Stylesheet with embedded scripts runs only when StylesheetScriptsEnabled is true
Monitoring Agent offline Diagnostics file + Log Audits Verify the agent is running, check firewall rules (Prerequisites), review synchronization logs
Missing resource state changes DaysToKeepMonitorEvents value + Log Databases size Adjust retention period, verify cleanup hasn't removed needed history
Auto Healing not executing User Notifications (Maintenance Mode) Confirm no active maintenance window is suppressing Auto Healing
Service won't start Diagnostics file + Windows Event Log Check database connectivity, verify the service identity set in the Portal (Core platform services) and its SQL rights (Prerequisites)

More answers are in the Monitoring Service Troubleshooting FAQ.

Best Practices for Monitoring Service Management

  • ✅ Review System Parameters quarterly – Ensure retention periods align with current compliance requirements
  • ✅ Monitor the Alarm Queue – Investigate any persistent queue entries promptly to prevent alert delivery failures
  • ✅ Schedule regular maintenance windows – Use recurring User Notifications for patching and planned downtime
  • ✅ Audit configuration changes – Regularly review Log Audits to detect unauthorized modifications
  • ✅ Test Alarm Plugins after changes – Verify alert delivery after modifying plugin configurations or credentials
  • ✅ Stop services before database updates – Always use the Update Log Database workflow to prevent database conflicts
  • ⚠️ Avoid manual service restarts during business hours – Schedule restarts during low-activity periods to minimize monitoring gaps

Note

Nodinite v6 is no longer supported, and the v6 Install and Update Tool is not used with v7. To move an existing v6 installation, follow Updating from v6 to v7.

Next Steps

System Parameters Overview
Manage System Parameters
Add or Manage User Notification

Monitoring Service

Configuration & Settings

Maintenance & Operations

Data Management

Troubleshooting