PDF

Monitoring Architecture

NetCrunch supports multiple types of monitoring techniques, each suited to different levels of control, flexibility, and scale. This topic explains the key architectural types — network services, monitors, and sensors — and clarifies when to use each for best results.

Overview of Monitoring Types

NetCrunch defines three core monitoring categories:

  • Network Services – Application-layer service probes that test responses, not just open ports.
  • Monitors – High-level modules with shared credentials and connection config, used with monitoring packs.
  • Sensors – Standalone checks targeting specific metrics, services, or custom logic.

Each category serves a different purpose and optimizes different aspects of the monitoring workflow.

Network Services

Network services operate at the application protocol level, not just the transport level.

Key Properties
  • Purpose: Verify that a service responds correctly to a real request, not just that the port is open.
  • Behavior:
    • Sends protocol-specific requests (e.g., HTTP GET, SMTP HELO).
    • Validates response content and timing.
    • Measures latency and detects incorrect or failed responses.
  • Configuration: Centralized; can be auto-applied during discovery or assigned manually.
  • Customization: Users can create custom service definitions for proprietary protocols or extended validation.
  • Examples: HTTP, SMTP, DNS, LDAP, POP3, SSH, SNMP.

These are useful for confirming basic service availability and performance without requiring full sensors. They’re widely used in discovery and network-level health checks.

Monitors

Monitors are high-level modules that use shared configuration to efficiently manage a wide range of systems.

Key Properties
  • Purpose: Collect broad sets of metrics across nodes using one set of credentials and connection rules.
  • Behavior:
    • One configuration defines access credentials (e.g., SNMP, WMI, SSH, REST).
    • Metrics and checks are defined by monitoring packs.
    • A monitor manages many nodes of the same type efficiently.
  • Advantages:
    • Reduces repetition by applying the same connection settings across nodes.
    • Ideal for infrastructure-wide monitoring (e.g., all Windows servers).
    • Monitoring packs define alerts, counters, and metrics in reusable groups.
Examples
  • Windows Monitor
  • SNMP Monitor
  • Linux/SSH Monitor
  • ESXi Monitor

Monitors are powerful building blocks. They act as gateways for monitoring packs, enabling broad observability with minimal configuration effort.

Sensors

Sensors are individual monitoring objects applied directly to nodes or templates.

Key Properties
  • Purpose: Collect targeted metrics, validate conditions, or trigger alerts based on custom logic.
  • Behavior:
    • Each sensor operates independently.
    • Requires per-sensor configuration, including credentials or input parameters.
    • Flexible and granular — suitable for custom monitoring pipelines or isolated targets.
  • Inheritance: WMI-based sensors can optionally reuse the WMI Monitor configuration.
Examples
  • Basic HTTP
  • SQL Query:Data
  • IPMI Log
  • DICOM C-Echo
  • File, Folder, and Log parsers
  • Text Log, Data File
  • REST API sensors

Sensors are perfect when monitors are not available or when fine-grained control is required. They can monitor APIs, run remote scripts, or analyze logs from external systems.

When to Use Each Type

Situation Recommended Monitoring Method
Verify web server availability Network Service (HTTP)
Monitor CPU, memory, disk on all Windows nodes Windows Monitor + Monitoring Packs
Track backup job status from Veeam Veeam Sensor
Test REST API for JSON metric REST HTTP Sensor
Confirm that DNS resolves a domain DNS Network Service or DNS Query Sensor

Legacy and Forward Strategy

Some legacy network services (e.g., CHARGEN, FINGER, QDAY) remain for compatibility but may be deprecated in future versions. These services reflect older protocols and rarely-used checks.

Future monitoring logic favors monitors and sensors, which offer more flexibility, scalability, and integration options.

Summary

NetCrunch separates monitoring into three architectural types:

  • Monitors manage large groups of nodes via a central config and monitoring packs.
  • Sensors provide precise control and customization per check.
  • Network Services validate service responses at the protocol level and serve as fast, lightweight probes.

Choosing the right type depends on your scale, granularity needs, and monitoring strategy.

architecturemonitoringmonitorsnetcrunchpackssensorsservices