What is a Monitoring Event?
Track every heartbeat of your integration landscape with Nodinite Monitoring Events. Each event captures a moment in time—a state change, a threshold breach, or a status update—enabling real-time alerts, automated remediation, and comprehensive audit trails for operational excellence.
Key benefits:
- ✅ Real-time state tracking - Capture every change in monitored Resources instantly
- ✅ Alert automation - Trigger notifications when thresholds are breached
- ✅ Auto-healing enabled - Events drive automated remediation actions
- ✅ Historical analysis - Long-term event storage for troubleshooting and compliance
- ✅ Audit trail - Complete visibility into when, what, and why issues occurred
A Monitoring Event is a logged record of a state change or status update for a monitored Resource. These events are the foundation of Nodinite's proactive monitoring, alerting, and auto-healing capabilities.
The Monitoring Event Lifecycle
Discovers Resources] R[fal:fa-lightbulb-on Resource
Queue, Service, API, DB] MA -->|Monitors| R end subgraph "Event Generation" SC[fal:fa-exchange State Change
OK → Error
Error → OK] ME[fal:fa-chart-line Monitoring Event
Logged with timestamp] R -->|Triggers| SC SC -->|Creates| ME end subgraph "Response" MS[fal:fa-watch-fitness Monitoring Service
Processes events] ALERT[fal:fa-bell Alert
Email, ticket, etc.] HEAL[fal:fa-ambulance Auto Healing
Corrective action] ME -->|Evaluated by| MS MS -->|May trigger| ALERT MS -->|May trigger| HEAL end subgraph "Storage & Analysis" DB[fal:fa-database Log Databases
Historical records] HIST[fal:fa-history History View
Audit trail] ME -->|Stored in| DB DB -->|Powers| HIST end style ME fill:#fff4e1 style ALERT fill:#ffe5e5 style HEAL fill:#e8f5e9 style HIST fill:#e1f5ff
Diagram: From Resource state changes to automated responses—every Monitoring Event flows through Nodinite's intelligent processing pipeline
What Generates a Monitoring Event?
Monitoring Events are created whenever the Monitoring Service detects a change in the evaluated state of a Resource. The following scenarios generate events:
State Transitions
| From State | To State | Event Description | Typical Cause |
|---|---|---|---|
| OK | Error | Resource failure detected | Service stopped, queue full, threshold breached |
| Error | OK | Resource recovered | Issue resolved, service restarted |
| Warning | Degraded performance detected | High queue depth, slow response time | |
| Warning | Error | Situation worsened | Warning threshold exceeded |
| Any State | Unavailable | Resource cannot be reached | Network issue, service offline, misconfiguration |
| Any State | Connection Error | Agent communication failure | Monitoring Agent offline, network problem |
Non-Event Pattern Monitoring
Some monitoring scenarios generate events when no activity occurs within expected timeframes:
- File Folder Monitoring - No new files received in expected window
- Log File Monitoring - No log entries written (indicating stalled process)
- Scheduled Task - Task did not execute when expected
- Message Queue - No messages consumed (indicating stalled consumer)
💡Pro Tip: Non-event monitoring is critical for detecting "silent failures" where systems appear running but aren't processing work.
Monitoring Event Properties
Each Monitoring Event contains comprehensive information for troubleshooting and analysis:
| Property | Description |
|---|---|
| Timestamp | Exact date and time when the event occurred (UTC or local time) |
| Resource Name | The Resource that generated the event |
| Previous State | The state before the change (OK, Warning, Error, etc.) |
| Current State | The new state after evaluation |
| State Duration | How long the Resource was in the previous state |
| Log Text | Detailed message explaining the event (e.g., "Queue depth: 5000 messages") |
| Application | The Application the Resource belongs to |
| Category | The Category classification |
| Monitor View | The Monitor View displaying this Resource |
| Monitoring Agent | The Monitoring Agent that detected the change |
How Monitoring Events Drive Actions
Monitoring Events are the trigger mechanism for several critical Nodinite features:
1. Alert Distribution
When a Monitoring Event represents a state transition to Warning, Error, Unavailable, or Connection Error, the Monitoring Service evaluates configured Alarm Plugins:
- Email Alerts - Send notifications to responsible teams
- Ticket System Integration - Create incidents in ServiceNow, Jira, etc.
- Event Log - Write entries to Windows Event Log
- Webhooks - POST event data to external systems
Read more in the 'Alarm Plugins' and 'What is an Alarm Queue Entry' user guides.
2. Auto Healing
Monitoring Events that match Auto Healing configurations trigger automatic Remote Actions:
| Example Event | Auto Healing Response | Business Value |
|---|---|---|
| Windows Service stopped | Execute "Start Service" action | Zero-downtime recovery without manual intervention |
| BizTalk Receive Location disabled | Execute "Enable" action | Automatic recovery from transient backend issues |
| Queue depth exceeds threshold | Execute "Scale Out" or "Alert Priority Team" | Proactive capacity management |
Examples of Monitoring Events triggering automated remediation.
Read more in the 'What is Auto Healing' user guide.
3. Historical Analysis
All Monitoring Events are stored in Log Databases for long-term analysis:
- Troubleshooting - Identify patterns leading to failures
- Compliance - Audit trail for regulatory requirements
- Capacity Planning - Analyze trends over weeks/months
- SLA Reporting - Calculate uptime and availability metrics
The retention period is controlled by the DaysToKeepMonitorEvents system parameter.
Read more in the 'Resource State History' user guide.
Viewing Monitoring Events
In Monitor Views
Real-time events are displayed directly in Monitor Views:
Example Monitor View showing Resources with their current states—each state is the result of the most recent Monitoring Event.
Click any Resource to view its current state details and recent event log text.
In History Views
Historical events can be searched and analyzed:
Example Resource State History showing Monitoring Events over time, enabling root cause analysis and pattern detection.
Filter by date range, state transitions, or specific Resources to investigate recurring issues.
In the Dashboard
Critical Monitoring Events generate alerts displayed on the Dashboard:
Example Dashboard showing active alerts generated by recent Monitoring Events requiring attention.
Real-World Monitoring Event Scenarios
See how Monitoring Events power operational excellence:
| Integration Platform | Resource Type | Event Trigger | Outcome |
|---|---|---|---|
| BizTalk Server | Suspended Messages | Queue depth > 10 | Email alert + Auto-healing resume action |
| Azure Event Hub | Event Hub | No messages for 5 minutes | Alert to operations team |
| Windows Server | Windows Service | Service state: Stopped | Auto-healing starts service + Audit log entry |
| Azure Logic Apps | Logic App | Disabled after deployment | Auto-healing enables + Alert to DevOps |
| IBM MQ | Queue Manager | Queue depth warning threshold | Email alert (no auto-healing) |
| File System | File Folder | No files received in 30 minutes | Alert + Create ticket in ServiceNow |
FAQ
How long are Monitoring Events stored?
Event retention is controlled by the DaysToKeepMonitorEvents system parameter in the Configuration Database. Default is typically 90 days, but can be extended based on compliance requirements.
Do all Monitoring Events trigger alerts?
No. Alerts are only triggered for state transitions that match configured alert rules (typically Warning, Error, Unavailable, or Connection Error states). Transitions to OK may generate "recovery" notifications if configured.
Can I search historical Monitoring Events?
Yes! Use the Resource State History feature to search events by date range, Resource name, state transitions, and more.
What's the difference between a Monitoring Event and a Log Message?
- Monitoring Events - Track Resource state changes from Monitoring Agents
- Log Messages - Application/integration transaction logs from Log Agents
Both are stored in Log Databases, but serve different purposes: monitoring vs. transaction logging.
How do Monitoring Events enable Auto Healing?
The Monitoring Service evaluates each Monitoring Event against configured Auto Healing rules. When a match is found (e.g., "If Windows Service = Stopped, then Execute Start"), the system automatically executes the configured Remote Action.
Can I export Monitoring Events for external analysis?
Yes! Use the Web API to query historical events and export data for integration with BI tools, SLA reporting systems, or custom dashboards.
Next Step
Add or manage Resource
Add or manage Monitor View
Manage Monitoring Service
View Resource State History
Configure Auto Healing
Related Topics
Monitoring Architecture:
- Monitoring Service - Processes Monitoring Events
- Monitoring Agents - Generate Monitoring Events
- Resources - Source of Monitoring Events
- Monitor Views - Display real-time event states
Event-Driven Features:
- Alarm Plugins - Alert distribution from events
- Auto Healing - Automated remediation from events
- Remote Actions - Manual remediation actions
- Alarm Queue Entries - Failed alert handling
Data Management:
- Log Databases - Event storage
- Configuration Database - System parameters
- DaysToKeepMonitorEvents - Retention settings
- Reports - Event analytics via Web API
User Guides:
- Resource State History - View historical events
- Dashboard - Real-time event overview
- User Notifications - Maintenance mode & events