Adding Alerts
Configure alerting by attaching conditions to monitored data on nodes, sensors, or services. Alerts define when NetCrunch should react to changes in state or thresholds.
Alerts are configured within node monitoring settings by attaching conditions to existing monitoring sources such as services, OS metrics, or custom sensors.
Where Alerts Come From
Alerts in NetCrunch are not standalone objects. They are always tied to:
- Node status
- Network services (e.g. PING, HTTP)
- Operating system monitoring (Windows, Linux)
- SNMP data
- Custom sensors
- Data pushed via native formats (JSON, XML, CSV)
- Syslog, SNMP traps, Web Messages
This means:
- No data → no alert
- Alerts are conditions on monitored values or states
Basic Flow
1. Select or Create a Node
- Locate an existing node in Atlas
- Or add a new node
2. Open Node Settings
- Open Node Settings
- Go to the Monitoring tab
3. Choose Monitoring Source
In the Monitoring tab, identify where the alert should be attached:
-
Existing tiles (recommended):
- Status Monitor
- Node Status
- Service Status
- CPU, Memory, Disk
- Network
-
Or add a new sensor:
- Custom sensor
- Web request
- Script
- External data
4. Add Alert Condition
- Open the selected monitoring tile
-
Define alert conditions:
- Thresholds
- State changes
- Availability
- Custom logic
OS-Based Monitoring Alerts
If OS monitoring is enabled (e.g. Windows):
Alerts can be added directly to: - CPU - Memory - Disk - Services - Event Log
These are:
- Pre-structured
- Optimized for common scenarios
- Extendable via custom alerts
Custom Alerts
Custom alerts allow:
- Defining thresholds on any metric
- Combining multiple conditions
- Creating domain-specific logic
They are available in:
- OS monitoring sections
- Sensors
- Custom data ingestion
Scaling Alert Configuration
Multi-Node Configuration
Alerts can be added to multiple nodes by:
- Multi-selecting nodes
- Applying changes once
Monitoring Packs
Monitoring Packs are the primary scaling mechanism.
Automatic Assignment
- Assigned using expressions
- Example: all Windows servers, all routers
- Applied dynamically
Manual Assignment
- Applied directly to selected nodes
- Supports multi-selection
Benefits:
- Consistency
- Reusability
- Reduced manual work
Sensors and External Data
Alerts can also be based on:
- Script results
- Web checks
- API queries
- Imported data
NetCrunch supports ingesting structured monitoring data using:
- JSON
- XML
- CSV :contentReference[oaicite:1]{index=1}
This enables:
- Alerting on external systems
- Integration with other tools
- Custom telemetry pipelines
Key Principles
- Alerts are always attached to monitoring data
- Monitoring must exist before alerting
- Use packs for scale, not manual configuration
- Prefer built-in monitors before creating custom ones
UI Context
The Monitoring tab in Node Settings is the central place for:
- Adding monitoring sources
- Attaching alerts
- Managing sensors
It provides:
- Tile-based structure
- Quick access to common monitors
- Expandable architecture for custom monitoring
Pitfalls
- Adding alerts without proper monitoring setup
- Duplicating alerts across nodes instead of using packs
- Overusing custom alerts instead of built-in logic
- Ignoring data source quality (alerts depend on it)
Summary
Alerting in NetCrunch is tightly integrated with monitoring. Instead of creating alerts separately, users attach alert logic directly to monitored data sources, ensuring consistency, scalability, and real-time responsiveness.