What is the Nodinite Monitoring Service?
The Nodinite Monitoring Service delivers proactive, end-to-end monitoring and alerting for your integration landscape. This service ensures you stay informed about system health, resource status, and critical events—empowering you to act before issues impact your business.
✅ Real-time alerts and notifications with flexible Alarm Plugins
✅ Self-service configuration with role-based Monitor Views
✅ Seamless integration with distributed Monitoring Agents and Auto Healing
The Nodinite Monitoring Service ensures you are always aware of your system's health, based on your custom alerts configuration. This configuration is managed through self-service enabled Monitor Views. The Monitoring Service periodically synchronizes the status of the Resources that your Monitoring Agents monitor, records each state change as a Monitor Event, and executes Remote Actions.
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 together with the other Core Services. Check the Prerequisites first. It reads its settings from the Configuration Database and stores Monitor Events in the Log Databases.
For operational guidance, see Manage the Monitoring Service.
Key System Parameters for Monitoring Service
The Monitoring Service reads these System Parameters. Change them in the Web Client as described in Manage System Parameters; a new value takes effect within about 15 seconds, without a restart.
- DaysToKeepMonitorEvents - Days to keep Monitor Events, the Resource state history (default
90) - DaysToKeepMonitorAgentBackups - Days to keep Monitoring Agent configuration backups (default
90) - AlarmQueueSettings - Retries and send timeout for the Alarm Queue (default
{"MaxRetries":3,"TimeoutSeconds":120}) - SqlServer - SQL Server, listener, and Linked Server names used to reach the Log Databases
- StylesheetScriptsEnabled - Allow embedded scripts in the Stylesheets that format alerts
Message retention and its cleanup run (MissingEventsDays, CleanUpTimerInterval) belong to the Logging Service, not the Monitoring Service.
Features
Operations performed by the Monitoring Service or commands issued by a user come from the following configurations and functionality:
- Manage the Monitoring Service – Maintenance windows, the Alarm Queue, diagnostics, and Log Audits
- Pushing Alerts using Alarm Plugins
- Alarm Queue – Resilient alert delivery ensures no alerts are lost if plugins fail (Nodinite v7+)
- Periodic synchronization with configured Monitoring Agents
- Execute Remote Actions – Secure transfer and audit logged operations initiated by a User or an Auto Healing configuration
- Data Retention – Hourly purge of old Monitor Events and daily cleanup of Monitoring Agent configuration backups
Pushing Alerts
When a Resource changes in a way that matters for a Monitor View, the Monitoring Service evaluates your alert rules and may push notifications by Alarm Plugins. Nodinite ships with various mail and Windows Event Log plugins.
- E-mail with options
- Windows Event Log – for use with, for example, SCOM
- HTTP Webhook – for issue-tracking and incident management systems
Note
Nodinite v7 loads only the four built-in Alarm Plugins; it does not load custom or 3rd-party Alarm Plugin DLLs. To reach an issue-tracking or incident management system, use the HTTP Webhook plugin.
If an Alarm Plugin fails to send, the alert goes to the Alarm Queue and the Monitoring Service retries it as set in AlarmQueueSettings.
When Alerts Are Sent
| Scenario | What an administrator should expect |
|---|---|
| A Resource changes to another effective state | Nodinite evaluates the affected Monitor View and sends alerts according to your Monitor View and Alarm Plugin configuration. |
| A Resource is edited, but the effective state stays the same | No alert is sent. |
| You explicitly add a Resource, or create a new include filter that brings it into a Monitor View | The affected Monitor View can send a notification if the change affects what operators need to know. |
| The overall Monitor View state stays the same | Only resource-level alerts may be sent. View-level alerts remain quiet. |
| Maintenance Mode or postponed Auto Healing applies | Monitoring continues, but alert delivery can be delayed or suppressed until the condition should be reviewed again. |
| There is no affected Resource to include in the notification | Nodinite skips the alert instead of sending an empty message. |
Nodinite also keeps change scope tight. A change that belongs to one Monitor View does not fan out to unrelated Monitor Views.
Important
Some membership-only changes may remain silent today. The most important examples are when a Resource leaves a Monitor View, re-enters because an exclusion was removed, or starts matching an older include filter without a separate state change. If these transitions matter operationally, review Monitor View history after filter changes or maintenance work.
The Monitoring Service is responsible for making you aware—Nodinite is Always Aware.
Provide Self Service configurations using Monitor Views
The Monitoring Service determines who to notify and how, based on Alarm Plugins configured globally or customized with one or more Monitor Views. With role-based Monitor Views, you can push alerts for a single Resource or combine Resources from different Monitoring Agents to create end-to-end monitoring and alerts for individual system integration workflows, tailored to your solution's dependencies.
Highly configurable, role-based Monitor Views provide self-service for end-users and customizable options for pushing alerts.
Periodic Synchronization
The Monitoring Service performs periodic synchronization with the Monitoring Agents. Different Monitoring Agents can have individual synchronization settings, configured via a Monitoring Agent Configuration.
Generic illustration for any type of resource being monitored by a product/service-specific Monitoring Agent.
Synchronization with Monitoring Agents wherever they are
The Monitoring Agents can be installed on-premise or anywhere else. The Monitoring Service can communicate with the Monitoring Agents using any of the following options:
- Direct connection to the agent's IIS web site, on the agent port set in the Portal (Nodinite v6 agents used port 8000)
- Install anywhere using Service Bus Relaying
The firewall rules for both options are in the Prerequisites.
Data Retention
The Monitoring Service cleans up its own history. You control how long it keeps data with two System Parameters:
| Data | System Parameter | Default | When the Monitoring Service cleans it |
|---|---|---|---|
| Monitor Events (Resource state history shown in Resource State History and Monitor View history) | DaysToKeepMonitorEvents | 90 days |
Every hour |
| Monitoring Agent configuration backups | DaysToKeepMonitorAgentBackups | 90 days |
Once a day, and right after the service starts. The 10 newest backups per agent and all pinned backups are always kept. |
Purged Monitor Events are gone; raise DaysToKeepMonitorEvents before you need the longer history. Message data, Log Events, and Log Audits follow the Logging Service retention rules instead.
Frequently asked questions
Find solutions to common problems and answers to the Nodinite Monitoring Service FAQ in the Troubleshooting user guide.
How does the Monitoring Service know what to monitor?
A Nodinite Administrator registers each Monitoring Agent in the Web Client (Add or manage Monitoring Agent). The Monitoring Service then synchronizes with every registered agent and fetches the Resources it reports.
How does the Monitoring Service know about the evaluated state of a Resource?
A Nodinite Administrator configures the Resources:
- The evaluated state comes from the configuration of each Resource, such as its Expected State
- The Auto Healing operations to perform also come from the configuration of Resources (Auto Healing)
How does the Monitoring Service know how to push alerts?
A Nodinite Administrator configures the Monitor Views. The Alarm Plugins, configured either globally or customized in one or more Monitor Views, decide who to send to, when to delay, and when to stay quiet.
Next Steps
Add or manage Monitoring Agent
Add or manage Monitor View
Manage Alarm Plugins
Manage the Monitoring Service
Related Topics
Monitor Views Overview
Monitoring Agents
What is a Monitoring Event?
Alarm Queue
System Parameters
Logging Service
Web API
Core Services
Web Client