NetCrunch Guide

Program documentation is constantly updated with every new build. It is also available online.

Please help us make it better. If you find any topic incomplete or missing - let us know. Click on the small icon at the top right corner and send us an anonymous comment.

Monitoring Foundations

In this chapter, we explore the foundational principles of network monitoring through the concept of the monitoring pyramid. We introduce the three essential layers, Observability, Monitoring, and Notification, explaining their distinct roles and interconnections.

Introduction

Describing key monitoring layers and their role

Effective monitoring is the cornerstone of maintaining a healthy and efficient infrastructure in network management. The concept of monitoring can be visualized as a pyramid, where each layer builds upon the previous one to create a comprehensive strategy.

Observability

At the foundation lies observability, which involves collecting monitored data and events. This layer is crucial because information that is not observed is lost, and extensive data collection is essential for thorough analysis. Observability means gathering detailed insights about the system's behavior without immediately assessing or acting upon it.

Monitoring/Alerting

The second layer is monitoring, which begins with alerting. This is commonly misunderstood; alerts are not merely notifications, but events the monitoring system observes and can act upon. These alerts, particularly those categorized as warnings or informational, provide a detailed picture of network behavior over time. They are vital for automation and triggering corrective actions, helping to maintain network stability and performance.

Notifications

At the pinnacle of the pyramid is the notification layer. Notifications should only include critical alerts concerning crucial parts of the network infrastructure, demanding immediate action. This distinction is significant as many users mistakenly disable monitoring instead of just the notifications, analogous to "cutting off the leg because the toe hurts."

Understanding and implementing this pyramid approach ensures a robust and effective monitoring system, enabling proactive management and swift issue resolution.

Data Collection - Observability

Types of data collected across the network for a comprehensive overview

Definition and Importance

Data collection, often called observability in modern network management, forms the base of the monitoring pyramid. This layer continuously gathers various data and events from across the network. Observability is critical because it provides the raw information for analysis, troubleshooting, and decision-making. As the saying goes, "You can't manage what you don't measure." Collecting more data than initially needed ensures that no crucial information is missed, which can be invaluable for future analysis and understanding of network behavior.

Types of Data

A robust data collection strategy involves capturing a wide range of information, including:

• Network Traffic: Data packets traveling across the network help understand bandwidth usage, identify bottlenecks, and detect potential security threats. Monitoring network traffic is crucial for maintaining network performance and identifying unusual patterns that might indicate issues such as congestion or malicious activity.

• System Performance Metrics: CPU usage, memory utilization, disk I/O, and other performance indicators from servers and network devices. These metrics are essential for assessing the health and efficiency of the infrastructure. Monitoring these metrics helps predict potential failures and optimize resource allocation.

• Application Logs: Logs generated by applications running on the network. These logs provide insights into application behavior, errors, and user interactions. Application logs are invaluable for diagnosing application-specific issues, understanding user activity, and ensuring application security.

• User Activity: Data on user access and actions within the network. Monitoring user activity is crucial for security monitoring and compliance, helping detect unauthorized access, track changes, and ensure user actions align with organizational policies.

• Status Data: Information describing the state of various elements within the network and beyond, such as IoT devices. Status data can be determined internally, like the availability of a service, or received and checked from external sources. This data is essential for understanding the operational state of devices and systems, ensuring they function correctly, and detecting any deviations from expected behavior.

Collecting these types of data ensures a comprehensive view of the network's operation, enabling proactive management and swift resolution of issues. Organizations can maintain optimal network performance and security by integrating network traffic, system performance metrics, application logs, user activity, and status data into a unified monitoring strategy.

Benefits

Implementing a comprehensive data collection strategy provides several key benefits:

• Historical Data for Trend Analysis: By maintaining historical data, network administrators can identify trends and patterns over time, which helps in forecasting future needs and detecting long-term issues.
• Baseline Establishment for Normal Behavior: Collecting extensive data allows for creating baselines that define normal network behavior. These baselines are essential for detecting anomalies and potential problems.
• Root Cause Analysis for Issues: When problems arise, having detailed historical data enables more accurate and quicker root cause analysis, leading to faster resolution and minimizing downtime.

In conclusion, the data collection layer is the foundation of effective network monitoring. By prioritizing comprehensive data gathering and implementing robust storage and retention practices, organizations can ensure they have the necessary information to maintain network health, proactively address issues, and support informed decision-making.

Monitoring - Alerting

Identify common misconceptions about alerts. Learn about their role in network management and workflow automation

Definition and Distinction from Notifications

Monitoring, often associated with alerting, is the second layer in the monitoring pyramid. This layer involves the continuous observation of the network and the generation of alerts based on predefined conditions. It is crucial to distinguish alerts from notifications:

• Alerts as Events: Alerts are specific events triggered when monitored data meets certain criteria. These events can trigger automated responses, such as running scripts, adjusting configurations, or creating new alerts. Alerts help identify potential issues before they become critical.
• Common Misconception: Alerts are often mistakenly treated as notifications. However, alerts are not merely notifications; they are actionable events that provide insights into network behavior and can drive automated responses.

Types of Alerts

Alerts can be categorized into three main types, each serving a distinct purpose:

• Critical Alerts: These alerts indicate severe issues that require immediate attention. They are usually triggered by events that could lead to significant downtime or security breaches. Examples include server outages, security violations, and critical application failures.
• Warning Alerts: Signify potential issues that might not require immediate action but should be addressed to prevent escalation. These alerts help identify trends or conditions that could become critical if left unattended. Examples include high CPU usage, nearing disk capacity, and unusual network traffic patterns.
• Informational Alerts: Provide data about normal but noteworthy events within the network. These alerts help track changes, understand usage patterns, and maintain a historical record of network behavior. Examples include system reboots, user logins, and configuration changes.

Configuration and Management

Effective alert management involves careful configuration and ongoing adjustments to ensure relevance and accuracy:

• Setting Thresholds for Alerts: Establishing appropriate thresholds for triggering alerts is crucial. Thresholds should be based on historical data, industry standards, and specific organizational needs. Regularly review and adjust these thresholds to adapt to changing network conditions.
• Customizing Alert Parameters Based on Network Behavior: Different network environments have unique behaviors and requirements. Customizing alert parameters allows for more accurate detection of anomalies. This customization includes defining alert conditions, specifying alert severities, and setting up alert dependencies to avoid redundant alerts.

Benefits

Implementing a well-structured alerting system provides several key benefits:

• Automated Corrective Actions: Alerts can trigger automated scripts or workflows to address issues immediately, reducing the need for manual intervention and speeding up problem resolution.
• Comprehensive View of Network Behavior: Alerts provide real-time insights into network conditions, helping administrators understand current performance and anticipate potential problems.
• Improved Response Times and Reduced Downtime: By identifying and responding to issues promptly, alerts help minimize network downtime and improve overall system reliability. This proactive approach ensures that potential problems are addressed before they impact users.

In conclusion, the monitoring/alerting layer is essential for maintaining network health and performance. By effectively configuring and managing alerts, organizations can ensure timely responses to potential issues, automate corrective actions, and gain a comprehensive understanding of their network behavior. This approach enhances the ability to maintain a stable and efficient network infrastructure.

Notifications

Criteria and best practices for effective notifications in network management

Definition and Purpose

Notifications represent the top layer of the monitoring pyramid, where the most critical information is communicated to human operators. Unlike general alerts that can trigger automated responses, notifications are reserved for critical alerts that require immediate human intervention. These notifications ensure that relevant personnel promptly address issues impacting the network's core functionality.

Criteria for Notifications

To ensure the effectiveness of notifications, it is essential to adhere to strict criteria:

• Only Include Critical Alerts: Notifications should be limited to critical alerts that signify severe issues needing immediate attention. This ensures that the most pressing problems are prioritized and acted upon swiftly.
• Focus on Critical Parts of Network Infrastructure: Notifications should target the most crucial components of the network infrastructure, such as core servers, main communication links, and essential applications. This focus helps safeguard the network's critical functions and minimize the impact of any disruptions.

Best Practices

Implementing notifications effectively requires adherence to best practices designed to maximize their utility and minimize potential drawbacks:

• Avoiding Alert Fatigue by Minimizing Notifications: Excessive notifications can lead to alert fatigue, where operators become desensitized to alerts and may overlook or ignore them. To prevent this, minimizing notifications to only the most critical issues is crucial, ensuring each notification receives the necessary attention.
• Prioritizing Notifications to Ensure Important Alerts Are Addressed: Notifications should be prioritized based on severity and impact. This prioritization helps ensure that the most critical problems are addressed first, optimizing the response time and reducing the potential for significant network disruptions.

Common Pitfalls

Avoiding common pitfalls in the notification process is essential for maintaining an effective monitoring strategy:

• Disabling Monitoring Instead of Notifications: A common mistake is turning off monitoring due to overwhelming notifications. This approach is akin to "cutting off the leg because the toe hurts"—it addresses the symptom but not the underlying problem. Instead, refine the notification criteria to reduce noise without compromising overall monitoring.
• Misconception Analogy: Understanding the distinction between monitoring and notifications is crucial. Disabling notifications when overwhelmed should not lead to disabling the entire monitoring system. Instead, it requires fine-tuning the notification parameters to ensure they serve their purpose without causing unnecessary disruption.

In conclusion, the notification layer is critical to an effective monitoring strategy. Organizations can ensure their network infrastructure remains stable and resilient by focusing on critical alerts, adhering to best practices, and avoiding common pitfalls. Properly configured notifications enable timely human intervention, safeguarding the network's core functions and maintaining overall system performance.

Validating the Layered Monitoring Approach

Case studies and research on the layered monitoring approach for building the network monitoring strategy

alertingbest practicesmonitoringnetcrunchnetwork strategynotificationobservabilitypyramid model

Additional Information and Evidence

The layered monitoring approach is grounded in extensive research, case studies, and established industry standards. Here are some key references and insights supporting this approach:

• Research on Monitoring Best Practices
  Effective network monitoring relies on comprehensive data collection, proactive alerting, and targeted notifications. Keysight’s white paper on network monitoring emphasizes the importance of technologies like network packet brokers to filter and manage data efficiently.
  Keysight White Paper – Best Practices for Network Monitoring

• Case Studies Demonstrating Successful Implementation
  Apriorit discusses how detailed monitoring and proper data analysis improve network performance and issue resolution.
  Apriorit Case Study on Network Monitoring

• Industry Standards and Guidelines
  Established frameworks like NIST SP 800-137 and ITIL promote a structured monitoring strategy emphasizing data collection, alerting, and notification.
  NIST SP 800-137 – Continuous Monitoring Guidelines
  ITIL Best Practice Solutions

Benefits of the Layered Monitoring Approach

Adopting a layered strategy yields several key advantages:

• Comprehensive Monitoring and Data Availability
  Extensive observability ensures critical data is captured for deeper analysis and anomaly detection. This supports informed, strategic decisions.
  Keysight White Paper – Best Practices for Network Monitoring

• Facilitates Proactive Network Management
  Monitoring and alerting detect real-time issues and trigger automated responses to minimize impact.
  Apriorit Case Study on Network Monitoring

• Efficient Response and Resolution
  Critical notifications are directed to the right personnel to ensure rapid intervention and minimal downtime.
  NIST SP 800-137 – Continuous Monitoring Guidelines

In summary, the layered monitoring model—comprising observability, alerting, and notifications—is a validated, research-backed framework that enhances the ability to maintain healthy network infrastructure.

References

Books and Articles

• The Practice of Network Security Monitoring – Richard Bejtlich
• Network Management: Principles and Practice – Mani Subramanian
• Effective Monitoring and Alerting – Slawek Ligus and Stephen Thorne
• Keysight White Paper – Best Practices for Network Monitoring

Industry Guidelines

• NIST SP 800-137 – Continuous Monitoring Guidelines
• ITIL Best Practice Solutions
• ISO/IEC 27001 – Information Security Standard

References

Links to books, articles and industry guidelines

Books and Articles

• "The Practice of Network Security Monitoring: Understanding Incident Detection and Response" by Richard Bejtlich: This book provides a comprehensive overview of network security monitoring concepts and practices, including data collection and analysis techniques.
• "Network Management: Principles and Practice" by Mani Subramanian: This book covers various aspects of network management, including monitoring strategies and tools, providing foundational knowledge for understanding and implementing effective network monitoring.
• Keysight White Paper on Network Monitoring Best Practices: A detailed white paper discussing various best practices for network monitoring, emphasizing the importance of comprehensive data collection and proactive alerting. Read the white paper.
• "Effective Monitoring and Alerting" by Slawek Ligus and Stephen Thorne: This book explores strategies for building effective monitoring systems and creating meaningful alerts that help manage complex IT infrastructures.

Industry Guidelines

• NIST Special Publication 800-137: Information Security Continuous Monitoring (ISCM) for Federal Information Systems and Organizations: This document provides guidelines for establishing, implementing, and maintaining an effective continuous monitoring program. Explore NIST guidelines.
• ITIL (Information Technology Infrastructure Library) Best Practices: ITIL provides a comprehensive set of best practices for IT service management, including effective monitoring and alerting guidelines. Learn more about ITIL.
• ISO/IEC 27001: Information Security Management: This standard specifies the requirements for establishing, implementing, maintaining, and continually improving an information security management system, including guidelines on monitoring and measurement. Read ISO/IEC 27001 standard.

Expanding the Monitoring Horizon with NetCrunch

Read how NetCrunch goes beyond typical network monitoring to deliver a comprehensive service-based monitoring solution for industrial monitoring, smart city monitoring, IoT, and physical security systems

Network monitoring has evolved beyond traditional approaches to encompass a service-based model in today's interconnected world. This shift is driven by the increasing variety of devices and systems that connect to networks. NetCrunch exemplifies this modern approach by offering the capability to monitor virtually any device or service, from coffee machines to traffic lights, lab equipment, and physical security devices like alarms and cameras. Here's how NetCrunch goes beyond typical network monitoring to deliver a comprehensive service-based monitoring solution.

Beyond Traditional Network Monitoring

Traditional network monitoring focuses primarily on ensuring the performance and availability of network infrastructure—servers, switches, routers, and similar hardware. While essential, this approach is no longer sufficient in an era where an ever-growing array of devices and services are network-connected. NetCrunch expands the scope of monitoring to include:

• IoT Devices: Devices such as intelligent coffee machines, thermostats, and lighting systems.
• Industrial and Lab Equipment: Sensors, lab machines, and environmental monitoring tools.
• Smart City Infrastructure: Traffic lights, public transportation systems, and environmental sensors.
• Physical Security Systems: Alarms, surveillance cameras, and access control systems.

Treating Everything as a Service

NetCrunch's flexible architecture allows it to monitor any device or service that can connect to a network, treating them as services. Several key features facilitate this service-based approach:

• Custom Scripting and Telemetry: NetCrunch allows users to write custom scripts and send telemetry data to the platform. This capability is critical for integrating unique or non-standard devices into the monitoring framework.

• REST Protocol Integration: Using the ubiquitous REST protocol, NetCrunch can receive data from virtually any device or application. This open and flexible approach ensures that NetCrunch can adapt to various monitoring needs and device types.

• Expanding Protocol Support: With each new version, NetCrunch adds support for more protocols and extends its abilities to connect with an increasing variety of device categories. This continuous enhancement ensures that NetCrunch remains compatible with emerging technologies and devices.

Use Cases

Smart Facilities Management

Monitoring HVAC systems, lighting, and security devices in smart buildings. NetCrunch can provide real-time data on energy usage, environmental conditions, and security alerts.

Industrial IoT

Supervising the performance and status of industrial equipment and sensors. This includes real-time monitoring of production lines, equipment health, and environmental conditions in manufacturing facilities.

Healthcare and Laboratories

Monitoring critical lab equipment and environmental conditions. NetCrunch can ensure that lab conditions remain within specified parameters, preventing costly equipment failures or compromised experiments.

Smart Cities

Managing and monitoring public infrastructure such as traffic lights, street lighting, and public transportation systems. NetCrunch can help cities optimize traffic flow, enhance public safety, and improve energy efficiency.

Future-Proofing with NetCrunch

NetCrunch's commitment to expanding its monitoring capabilities ensures it remains a versatile and future-proof solution. As new devices and technologies emerge, NetCrunch's ability to integrate and monitor these innovations ensures that organizations can maintain comprehensive visibility and control over their entire network ecosystem.

In conclusion, NetCrunch's service-based monitoring approach allows it to go beyond traditional network monitoring, providing comprehensive oversight of various devices and services. By leveraging custom scripting, telemetry data, REST protocol integration, and continuous protocol expansion, NetCrunch offers a robust solution that adapts to the ever-evolving landscape of network-connected devices. This flexibility and extensibility make NetCrunch an invaluable tool for modern network management.

System Overview

Discover all of NetCrunch capabilities, concepts, and components.

NetCrunch employs unique concepts for data organization and monitoring settings management to monitor today's complex networks.

Architecture and Concepts

Overview of NetCrunch Server architecture. Learn more about Monitoring Engines, NetCrunch Consoles, databases, additional tools, and critical concepts of advanced network visualization.

Architecture

NetCrunch is a comprehensive system consisting of many components that communicate with each other. Most of them work on the NetCrunch Server, and configuration can be done with the Administration Console that users can run remotely (recommended). An additional NetFlow Collector with its database is also a part of the NetCrunch Server environment. The monitoring engine is responsible for performing monitoring tasks - the same set of processes included in the Monitoring Probe. The Dashboard server in the form of GrafCrunch Server can run on another machine.

The server works best on a dedicated machine (virtual or physical) with the appropriate resources assigned. If you want to process Gigabytes of data, you need SDD disks and a multicore machine. Read more in System Requirements.

NetCrunch Server also works well with vSphere Fault Tolerance, which provides continuous availability for NetCrunch Server.

NetCrunch Components

Server Services

The complete list of NetCrunch services is as follows:

NetCrunch Server

A central server provides monitoring logic, performance trend storage, and communication infrastructure for other components. It is a parent process for additional services, such as Monitoring Engine, NC Services and NC Event DB.

NC Services

Additional background processes working as server extensions. It handles actions, integrations, message processing, task scheduling, etc.

NC Event DB

It handles the event database and all its tasks.

NC Reports

Report rendering engine

NetCrunch Advanced SQL Server

Provides storage, processing, and controlled access to the Event Log data.

NetCrunch Flow Collector

Collects and analyzes flow data (NetFlow, sFlow, IPFix, and others).

NetCrunch Data Updater

Updates various files used by NetCrunch.

NetCrunch Guard Service

Watches server execution.

NetCrunch Web Server

NetCrunch embedded Web Server provides Web Console, Mobile Console, and REST API services. It uses the latest security patches and includes support for HTTPS, including TLS 1.3

NC Hooks

Webhook processing plugin for NetCrunch Web Server

NC REST API

Separate process for handling REST queries. Plugin for NetCrunch Web Server

Client Requester

Communication relay between Web Server and NetCrunch

Monitoring Engine

The monitoring engine process is the monitoring probe integrated into the server. It collects all monitoring data. It runs as a separate entity and manages separate engines for monitoring Network Services, SNMP, Interfaces, OS Monitors, Virtualization, and hundreds of sensors.

Operating system monitoring for Windows, macOS, Linux, Solaris, BSD, ESXi, or Hyper-V depends on appropriate node settings. See: Automatic Monitoring and Organizing.

Consoles

Administration Console

You can configure NetCrunch with the Desktop Administration Console, which you can install on any Windows system.
The console can utilize three different connection encrypted methods:

• local (TCP)
• WebServer (WSS)
• NetCrunch Connection Cloud (HTTPS, WSS)

We recommend using an SSL certificate for the NetCrunch Web Server, even for local use. This allows your Desktop Console to establish a secure SSL connection as well. For remote access, you can safely use the console over the internet through NetCrunch Connection Cloud.

The console caches large amounts of data and transfers only changes over the network, ensuring that updates appear instantly without requiring a manual refresh. It also supports the creation and saving of complex screen layouts, including multi-screen setups.

GrafCrunch

NetCrunch comes with a fork of the open-source project Grafana v7, one of the top open-source performance visualization projects. Grafana dramatically increases the possibilities of creating live performance dashboards and allows you to present data from various sources. Grafana has a separate installer and integrates with NetCrunch. It gives you an easy way to create dashboards from multiple NetCrunch Servers and other sources that Grafana supports.

Web Console

It is a modern HTML console that allows instant access to the server. It requires browsers not older than 1 year. You can manage access to the console through user accounts and access rights profiles.

Web Console provides mostly browsing capabilities. You might need an Administration Console to edit monitoring configuration and monitoring policies. Graphical Data views can be edited in Web Console, though.

Basic Concepts

NetCrunch was initially designed to monitor hundreds of devices and thousands of parameters. However, it scales seamlessly to monitor thousands of devices and hundreds of thousands of parameters using a single server. Our approach to scaling emphasizes both performance and ergonomics.

The policy-based configuration makes managing complex infrastructures straightforward. Rather than setting individual alerts and reports for each monitored node, which can be time-consuming in other programs, NetCrunch automatically applies these settings based on predefined policies. This significantly reduces the time required to configure and manage each node.

Network Atlas

It contains all your network data and helps you organize it into various views. Many of the views are created automatically.

The fundamental element of the Atlas is a network node—a single-address network endpoint. The Atlas Tree shows the hierarchy of all views and helps you quickly recognize the status of each element.

Atlas Views

Atlas begins with a top root view of all nodes. This view shows top-level dashboards such as Status, Top Charts, and Flows.

The rest of the views are divided into sections:

IP Networks

This section consists of IP network views/maps. Each network can be periodically re-scanned to reflect its current state, and you can create a custom graphical map for each view. By default, node view shows node icons automatically arranged by device model and OS name.

Sites

We introduced the concept of sites (aka address spaces) to prevent confusion when monitoring nodes with the same network addresses.

• Local - NetCrunch Server - means all addresses visible (local) by NetCrunch Server. You can place an additional Monitoring Probe within this address space for load balancing.

When two locations use the same private network address, they create two distinct sites.

Network Topology

This section contains views regarding network topology. It includes logical (routing) and physical connection maps (layer 2).

Routing Map

The view shows connections between IP networks and devices, providing these connections (routers).

Physical Connections

The top-level view shows connections between switches, and then each switch port mapping is represented on a separate view. Each segment (single switch) view automatically presents the traffic summary on each switch port.

Live Network Interface Status

NetCrunch offers views of ports and interfaces of the switch and provides live status for the particular interface.

Custom Views

This section allows you to organize your network data in any way you need. It contains both user-created views and predefined automatic views.

Dynamic Node Views & Folders

Based on typical customer atlases, we prepared many automatic (and dynamic) views for you, such as:

• Nodes with Issues
• Unresponding Nodes
• Responding Nodes with Active Alerts
• Monitoring Probes
• Receiver Nodes
• Business Status Nodes
• Server Types (i.e., Linux, Windows Server, etc.)
• Device Groups (Printers, Switches, Wireless, etc.)
• Workstation Types (Windows 7, Windows 8, Windows 10, etc.)
• Locations (Office, Building 1, Server Room - based on SNMP or manually entered data)
• Network Roles (Network, Printers, Servers, Workstations)
• Windows Domains
• Virtual Machine Hosts
• Organizations
• VLANs
• Operating System Monitoring
• Nodes Using Templates

The views are dynamic, which means they are automatically updated as needed.

Live Maps, Diagrams, and Dashboards (Graphical Data Views)

Graphical views are designed to present various performance and status data in graphical form. They can be diagrams or maps, where you can put many small elements. If they do not fit on the screen, you can drag and zoom as you would on regular maps.

Another option is to create a panel with given proportions and put elements inside it. Such a panel will fit a screen of a given proportion regardless of size. Panels are not scrollable and are always scaled to fit into available space.

Monitoring Dependencies

NetCrunch allows setting dependencies upon node routes, virtualization hosts, and known switch Layer 2 connections.

Monitoring Packs

Monitoring Packs can be assigned to a node automatically (by a specific rule like for every Windows Server or for every Cisco switch) or manually. NetCrunch comes with many predefined Monitoring Packs.

Automatic Monitoring by Device Types

Many predefined Monitoring Packs are automatically assigned to nodes based on the node Device Types' setting. The setting can be either automatically discovered or set manually.

Setting a proper Device Type is one of the essential tasks in configuring NetCrunch.

Device types will likely be set automatically for network components retrieved from Active Directory. NetCrunch can also automatically discover many SNMP devices.

Other devices, such as printers or Linux machines, need proper Device Types to monitor.

For example:

When you need to monitor a new macOS device, there are only two easy steps to do:

• add the device to the Atlas
• and set its device type to macOS system.

Then, the node will automatically receive a macOS Monitoring Pack.

It's that simple.

Events & Alerts

Alerts are an essential part of the monitoring program and one of its fundamental use cases. NetCrunch allows advanced alert processing, including correlation, conditional events, conditional actions, and escalation.

To clarify, whether we watch or not, events happen. "Event" becomes an "Alert" as we assign some reaction to it (it becomes an element of interest).

The simplest (default) action stores information about the event in the NetCrunch Event Log. We can assign a different list of actions to each event. The actions can include a notification (email, SMS texting) or some corrective actions, like executing scripts or programs (also on a remote machine). NetCrunch executes actions after the alert starts and when it's closed (finished).

External Events

As a monitoring program, NetCrunch is a primary source of status events and performance metrics alerts (counters). The program can also monitor external events. It matches incoming events with rules and triggers alerting actions for them. This feature allows you to trigger alerts and actions on SNMP traps, syslog messages, text logs, or Windows Event Log entries.

Active Alerts

As many alerts are short-lived and can be self-corrected (like connection or power loss), administrators should concentrate on existing problems instead of constantly looking into the log. NetCrunch simplifies alert management by correlating all internal alerts so they disappear from the Active Alerts view if closed.
The program allows for correlating external events (SNMP Traps, syslog, etc.) by defining the list of closing events for each external alert.

Conditional Alerts

Simple alerts work when alerting conditions are met, such as "node is down" or when some external notification has been received.

What about something that did not happen, or is it not happening regularly? You can solve such problems with conditional alerts, which allow more complex scenarios such as: notifying when the syslog message was not received or if an event happened in a specified time range.

Available conditions:

• On event
• if event happened after (x) of time
• if the event happened more than (x) times
• Only if within a time range
• Only if not within a time range
• If the event has not happened in a given time range
• if the event did not happen after (x) of time
• if the event is active for more than (x) of time

Correlation

Advanced correlation allows you to trigger events only if multiple events (from different nodes) have happened within a given time range or all are active simultaneously. Active event correlation requires all correlated alerts to be in an active state. This feature easily allows you to define an alert when two redundant interfaces are down.

Alert Actions and Escalation

In response to an event, NetCrunch can execute a sequence of actions. Actions can be executed immediately or with a delay (if the alert is not cleared), and the last action can be repeated. For example, you can send a notification to a particular person and then execute a server restart operation if the event remains active after some time.

See: Alerting Actions

Conditional Actions

Each action can be limited to run only if a triggering network node belongs to a given atlas view (these can be created by rules or manually) or within a given time range. This ability allows you to create flexible alerting scripts, such as sending different notifications depending on the node location. Alerting scripts can be used for multiple alerts, so you can limit actions to executing only when an alert is of a given severity.

Preventing False Alerts

NetCrunch uses various techniques to avoid false alerts or protect against alert floods, sometimes caused by device malfunctions. The program waits several seconds for a device to send a syslog message or SNMP traps to NetCrunch. If the same message appears several times, it won't trigger multiple alerts. NetCrunch uses an event suppression technique to detect false events caused by intermediate connection failures.

NetCrunch Tools

IP Tools

IP Tools is a set of network monitoring tools that allow testing the availability of devices and network services on a host, scanning ports, and checking the routes of test packets or connection bandwidth.

Performance Trend Analyzer

A tool for accessing NetCrunch performance data. You can analyze trend charts and data distributions for a given time. You can compare multiple parameters on a single chart.

SNMP MIB Compiler

This program allows compiling MIB files to extend NetCrunch's MIB library.

Reports

Allows for viewing and managing various NetCrunch reports.

atlasconsolemonitoringserver

Monitoring Architecture

architecturemonitoringmonitorsnetcrunchpackssensorsservices

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

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.

System Requirements

The basic requirements are a 64-bit Windows Server, 2 processors, and 3.5 GB of RAM—an SSD driver is also welcome. NetCrunch is designed to run efficiently on both virtual and physical server machines.

Hardware Requirements

Server

NetCrunch must be installed on a 64-bit Windows Server (Windows Server 2016, 2019, 2022, 2025). It has a web server and an embedded SQL database for storing and monitoring event data.

NetCrunch can be installed on a virtual machine, provided you assign at least 4 cores and 4 GB RAM.

More processors are better for monitoring 1000+ nodes; the recommended number in such cases is at least 8 CPU cores.
Monitoring a large volume of performance metrics (100,000 network interfaces) requires additional RAM (500,000 performance metrics will need an extra 4GB).

The other important component is the hard drive. We strongly recommend using SSD drives.

The Architecture and Concepts section explains why this is so important.

Administration Console

NetCruch Console runs on 32-bit or 64-bit Windows 10 or later systems with at least 4 GB of RAM. It requires a 24-bit color depth and high resolution. It should be run on at least Full HD screens or multiple monitors. The console also works excellently with touchscreen Windows tablets.

Web Console

Web Console is compatible with modern, evergreen browsers, including the latest versions of Chrome, Opera, Edge, Firefox, and Safari.

Antivirus on Server

Interference with NetCrunch

NetCrunch keeps part of the data in memory, while some are written to trend log files (NetCrunch opens thousands of them), and other data goes to an SQL database. A problem can occur when NetCrunch writes files containing a snapshot of in-memory data and antivirus software tries to access the file simultaneously.

Antivirus software sometimes causes high disk and processor utilization and may prevent NetCrunch from accessing data.

Excluding data folders

We know that sometimes you can't change the company policy, and after Solorigate, it seems even better practice to run security software on servers. In this case, you must exclude all data directories where NetCrunch writes data.

Our experience shows that servers sometimes behave strangely and uniquely, depending on the antivirus vendor.

Please also note that disabling antivirus software resembles disabling stability control in your vehicle—it's only partially off. The hooks installed in the system are still in place and unpredictably change the system's behavior. The other problem is that antivirus software might sometimes cause 100% utilization of the single processor.

Avoid Server Sharing

Depending on the processed data, NetCrunch can heavily utilize a server machine. Avoid competing for resources with other programs. NetCrunch contains many servers, such as the database, monitoring, web server, etc., so we are already putting a heavy load on a single machine.

In some cases, NetCrunch cannot process all data (events) due to hardware limitations. Remember that a single machine's speed is limited by its slowest components (hard drive, memory, or lack of cores).

Use Appropriate VM resources

Assign the machine an appropriate amount of processing time. Memory must also be physically available, as disk swapping should not occur. You need to reserve at least 4 cores and 4 GB. We recommend doubling these numbers for more than 100 to be monitored.

NetCrunch is a real-time Network Monitoring System.

What can I monitor?

NetCrunch can monitor nearly anything: devices, applications, systems, databases, and files. The program can be extended using scripts; data from various sources can be sent to NetCrunch or polled from files, databases, or websites.

There are many different usage scenarios for NetCrunch. In general, NetCrunch retrieves and processes three types of data:

Events

Information about some occurrences generated by NetCrunch or external sources such as Windows Event Log, SYSLOG, or SNMP trap.

Performance Counters (Metrics)

Numerical values (64-bit integer or floating-point)

Status

The status of various objects in NetCrunch, such as nodes, services, monitoring engines, etc.

The server allows you to set various conditions to filter incoming events or set alerts on performance counters. You can even create new calculated counters. See the Managing Calculated Performance Counters topic for details.

Network Infrastructure (SNMP)

NetCrunch can be used just for network monitoring, where we mainly pay attention to SNMP devices, such as printers, switches, routers, cameras, and others. NetCrunch supports SNMP v1/v2c/v3, including encryption and authentication.

Connectivity & Response Monitoring

NetCrunch monitors the availability of over 70 predefined TCP/UDP network services, including DNS, FTP, HTTP, POP3, SMTP, and more.

The program can monitor network service performance by counting the number of packets sent and received, calculating response times, and calculating the percentage of packets lost and received.

The program checks connectivity, validates service response, and measures response time for each monitored service. For each sensor, the program allows monitoring of various conditions (for example, the text contains some pattern, a file exists, and so on) and performance metrics (such as response time or data size).

You can create custom service definitions or duplicate an existing definition and change its port. Services support TCP, UDP, and SSL connections. Response patterns can be defined as text, binary data, or regular expressions.

Node Up/Down Status

NetCrunch determines node up/down status based on network service status and other monitors (in the case of servers). When a node is down, only the leading service is being monitored. So, a node is considered "down" when no services respond, and the node is considered "up" when the leading service responds.

DNS Health Monitoring

DNS is the most critical service in a network. Without it, nothing works at all. Therefore, monitoring the DNS service to check its availability is an obvious task for a monitoring system. However, availability monitoring only verifies whether the service is responding and what its response time is.

In addition to pure availability monitoring, NetCrunch allows you to verify DNS responses to given queries, which can enable you to discover unexpected (unauthorized) DNS changes.

Switch and Router Monitoring

NetCrunch supports switch and router monitoring, including the status of network interfaces, monitoring errors and discards, and bandwidth monitoring. It allows traffic to be monitored on interfaces, port mapping, and the creation of Layer 2 graphical maps.

NetCrunch allows you to monitor Cisco IP SLA operations. The program tracks the status of operations and also their performance metrics. Cisco IPSLA allows you to monitor VOIP jitter and other protocols and parameters.

Vendor-Specific Monitoring via SNMP

SNMP is very ubiquitous, but implementation varies. NetCrunch contains the MIB compiler, which allows you to add vendor-specific MIBs.

Since basic MIBs have only been partially defined in RFC documents, vendor MIBs are sometimes tricky to compile. If you have no experience compiling MIBs and find it difficult, please ask AdRem support for help. We will try to help you, and if the device is popular on the market, we can add it to the set of pre-compiled MIBs. Please note that NetCrunch's built-in database contains more than 8,850 vendor MIBs already.

Servers and Applications

NetCrunch supports agentless monitoring of the major operating systems, including Windows, macOS, Linux, BSD, Solaris, and VMWare ESXi. Additionally, the Windows system supports application monitoring by monitoring their performance parameters and service status.

You can also use SNMP to monitor these systems, but please be advised that using SNMPv2 can create a security loophole in operating systems, as SNMPv2 transmits data in plain text.

Windows Monitoring

Performance Counters

NetCrunch allows you to monitor all Windows performance counters, including disk counters remotely. The list of available counters depends on the particular system and applications installed. Nine different trigger types can be used to set alert triggers on counters.

Event Triggers for Counters

Windows Services

Monitoring Windows services is essential for monitoring most applications installed on Windows Server. The most frequent alert set on services is Service is not running. NetCrunch also offers a Windows services view in the node status window, allowing remote service control.

Windows Event Log

NetCrunch can remotely gather, filter, and analyze data from multiple Windows machines using WMI.

The program allows you to define simple alert filters to convert event log events into NetCrunch alerts. These filters are automatically converted into complex WQL queries.

WMI Sensors

NetCrunch includes 16 WMI sensors. WMI Perform resembles perfmon using WMI protocol, WMI Query object allows you to write your query, and then you can add alert triggers on result object properties. Process and Process Group summaries are handy for monitoring processes and their resources. Using the Process Group Summary sensor, you can easily track the total resources used by a web browser or other program using multiple process instances.

Hardware and Software Inventory

NetCrunch can collect hardware and software inventory information from Windows computers. The program shows detailed information about each machine and lists installed fixes. NetCrunch allows you to compare each audit and show hardware and software changes. The program includes a software summary view for multiple nodes.

Monitoring Files, Folders, and Text Logs

This type of monitoring is available for Linux (and other Unix family systems) and Windows. These file sensors allow you to monitor file presence, size, and if and when it was modified. It can also search file contents, find new text log entries, and convert them into NetCrunch alerts.

The Folder sensor allows you to monitor specific folder contents, such as when a new file is added or if any files are removed.

These sensors support FTP/s, HTTP/s, SSH/bash, SFTP, and Windows/SMB protocols.

Linux, macOS, Solaris, and BSD

NetCrunch can track over 100 performance counters to determine the health of Linux servers running kernel 2.4 or newer. The program has been tested to monitor the following Linux distributions: CentOS, RedHat, Fedora, Novell OES, Ubuntu Desktop, and Server.

NetCrunch also offers fully integrated Mac OS monitoring. All macOS versions are supported, including the latest one.

The most important parameters being monitored:

• System (uptime/downtime, logged-in users)
• Processor utilization
• Memory usage
• Disk usage
• Network interface statistics
• Processes (CPU & memory per process utilization)
• User (CPU & memory)
• TCP statistics

Monitoring VMware

NetCrunch supports ESXi versions 5.5 and later. It can connect directly to ESXi servers or through the vCenter server. When NetCrunch works in vCenter mode, and vCenter becomes unavailable, it can automatically switch to direct ESXi monitoring if you provide proper credentials for each ESXi server.

NetCrunch comes with pre-configured Automatic Monitoring Packs to monitor ESX when the device type is set to ESX.

Mail Server, Mailbox, and Email Monitoring

NetCrunch allows monitoring of mailboxes (IMAP or POP3), checking email content (extracting data or events from emails) using the Data Email sensor, or checking full mail server functionality by checking to send and receiving control email (Email Round-Trip Sensor)

SQL Database Monitoring

NetCrunch offers two sensors. The first allows checking a single-row answer from the SQL query, which can be treated as a status object. The second can interpret multiple rows as a list of metrics. This way, NetCrunch can monitor database connectivity and authentication (with empty SQL query), query execution time, and query results, which can be a single row representing a status object (so you can track changing the state of properties) or metrics that can be tend kept for trend or used for performance triggers. NetCrunch natively supports Oracle, SQL Server, MySQL, MariaDB connections, or any ODBC (system) source.

Security Monitoring - SSL Certificate Sensor

Every web sensor in NetCrunch can report an invalid certificate. NetCrunch also contains a separate SSL Certificate sensor, which can be applied to validate any SSL/TLS-based protocol certificate. The sensor can be used for any TLS-based service, not just HTTP/S.

Monitoring Device Uptime

NetCrunch contains universal sensor monitoring device uptime, connecting to the device using WMI, SSH, or SNMP protocols.

Monitoring Printers (SNMP)

The program allows to monitor printers using a printer sensor, which accesses all printer statuses and metrics.

RADIUS Sensor

The sensor checks the RADIUS protocol response and availability.

Cloud Monitoring

NetCrunch provides multiple sensors for Amazon AWS, Azure, and Google monitoring cloud services. You can add each sensor by creating a Cloud Service node.

Device Configuration Monitoring

NetCrunch can collect, store, and detect changes in device configuration. The configuration is stored as a text file that can be later used for editing or restoring purposes. The sensor and code are based on the Oxidized open-source project, ported to a NetCrunch environment.

Window Hardware Config

Similarly, NetCriunch collects the hardware configuration of Windows machines. The hardware configuration summary is available in the Nodes tab view.

Web Monitoring

Monitoring Web Pages or Applications

NetCrunch includes an advanced Web Page monitor that can load and render dynamic web pages containing Javascript as if a browser loaded them. It also allows you to check pages requiring the login (supporting standard HTML or custom login forms).

Available Web Page alerts:

• page size or load time
• page content change
• alert if the text is present or missing
• if a page does not exist
• page load error
• page resource load error
• page authentication error

Available performance metrics:

• % Availability
• HTTP Status Code
• JS Errors
• Load Time
• Main Frame Body Size
• Resource Count
• Resources Error Count
• Total Size

Monitoring HTTP Requests

This sensor is more suited for sending REST requests, so it simply retrieves data over HTTP and checks the response. It also allows you to check response content. It supports GET, HEAD, and POST requests.

Data Receiver Sensor

Allows defining a sensor on the node to receive data from an external source (device, script, app). Data can be sent using the REST API, and you can set alerts on collected metrics and status objects.

applicationcloudconfigmonitoringnetworkrest

NetCrunch Monitoring Objects

Explore a hierarchical data schema to organize monitoring across devices, sensors, services, and other monitoring targets, providing detailed insights into network health.

NetCrunch data schema hierarchical structure consists of several status objects. Top-level objects are nodes of various types, and then lower are other objects such as monitoring packs or sensors.

Object State

Object state names are designed to reflect their current status accurately:

• Critical, Error, or Down: The element is not functioning or is unresponsive.
• Warning: An issue requires attention, but no immediate action is needed.
• OK, Success: The element is functioning properly.
• Disabled: Monitoring of the element has been intentionally turned off.
• Unknown: The element's state is not determined because it has not been monitored or cannot be monitored.

Nodes

IP Node

The most common node type represents a device or virtual machine with an IP address.

Telemetry Node

The object represents the remote device without an IP address. So, you can send data and events using REST protocol to it.

Cloud Service

The object represents a single cloud service monitored. NetCrunch provides ready-to-use sensors to monitor over 30 cloud services from Azure, AWS, Google, and others.

Probe

It represents a remote monitoring engine, but it doesn't represent the device running the probe. You need to add it to the probe separately for monitoring.

Monitor

An internal element provides generic access to thousands of metrics through SNMP, WMI, VMware, etc. Monitors need to specify the monitoring target further. Monitors utilize monitoring packs for specific monitoring elements. Monitors are too generic to rely on their status.

Monitoring Pack

Each monitoring pack is a group of alerts or metrics that must be collected or monitored for a specific element, such as an application, service, or hardware. NetCrunch provides over 260 packs for monitoring SNMP, Windows, Linux, macOS, BSD, Solaris, and VMware.

Network Service

Network services are sensors specialized in protocol checks. They are lightweight, check the connectivity and response time, and verify the response from a given application. Network services are similar to IP SLA or NQA operations but are monitored from the NetCrunch Monitoring Engine (Server or Probe).

Sensors

Sensors are focused on specific monitoring needs such as monitoring a process, text log file, pending update, camera, SQL query, or web page.

Sensor Data Object

Sensor data objects are specific to a sensor. For a camera sensor, it's Snapshot Image, the last frame collected from the camera. Other objects might contain some data collected by the sensor. Sensor objects represent the status of the monitored object and specific data and might have a different status than the sensor itself. Other examples are the Web Page and Process objects. Currently, when the tooltip for the object is displayed, it displays data in a JSON form.

Alert

The status of the alert is designated by its severity level. Informational and minor alerts are often considered ok as they do not require attention.

SNMP Value

This object is only available if you add an alert on event for SNMP variable value to a given node. The objective is always a success state. If you need a stat,us look athe t alert associated with this object.

IP SLA/NQA Operation

First, you need to enable IP SLA or NQA monitoring on a node and add monitoring operations. Then, you can refer to these operations' status.

Composite Status

Technically, this is a node - a top-level object. It represents the summary (calculated) status of objects of any type, including Composite Status. See more in Composite Status

business statusip slamonitornetwork servicenqa.businessobjectspackprobereceiversensorsensor objectserviceslasnmpsnmp value

Automatic Monitoring and Organizing

You don't have to set up views and maps by hand or node by node. NetCrunch takes care of these tasks automatically.

Device Types

One essential part of the NetCrunch configuration process is setting proper Device Types for all nodes. NetCrunch detects a Device Type whenever possible by getting information from SNMP or Active Directory. If it can't, the Device Type can be set manually. Currently, operating system monitoring no longer depends on the node Device Type.

Operating System Monitoring

NetCrunch allows OS monitoring to be enabled in the node settings. The monitor can be enabled automatically if the device type is detected. Otherwise, you must manually enable the respective OS monitor for monitoring Windows, Linux, macOS, Solaris, BSD, or ESXi systems.

SNMP

Settings NetCrunch System Monitoring

SNMP monitoring depends on the profile you select for each node. The profile specifies the protocol's version and protocol-specific settings, such as community or username and password (v3).

To receive SNMPv3 traps, you must create SNMP notification profiles to provide authentication and encryption parameters. The profiles are matched with a trap by the User field. SNMPv1 and v2 traps do not need any profiles. All incoming traps are visible in the External Events window, simplifying the definition of alerts for incoming traps.

Monitoring Packs

NetCrunch has many automatic Monitoring Packs configured to be added to nodes when they meet certain conditions.

For example:

Basic Cisco (SNMP) Monitoring Pack

 Device Class should be "Hardware Router" or 
 a Switch Manufacturer name contains "Cisco."

Active Directory Monitoring Pack

 Operating System equals "Windows Server."
 Network Service List contains LDAP or "Secure LDAP" services.

You can view the complete list in the Monitoring Packs article.

Auto-Discovery

Networks are dynamic, and new devices connect over time. NetCrunch can automatically add them to the Network Atlas and start monitoring them.

Discovering Nodes

NetCrunch can run the auto-discovery process for each IP network and Active Directory container. All discovered nodes can be added automatically, or the program can display the results in a Server Tasks Notification Window so you can later decide which nodes to add.

Discovering Services and Device Types

The program automatically runs service discovery when the node is added to the Atlas. It's only checking the list of services set in Settings Monitoring Auto Discovered Services

The program also detects device type based on the information read from SNMP or Active Directory. If the device type can't be detected, it should be set manually.

The program also discovers ESX/i machines.

Read more about: Auto Discovery

Node and View Status Calculation

Node Status

NetCrunch automatically identifies every network service's status on the node, and at least one service must be monitored. If any service is not in the OK (green) mode, the node's status goes to the Warning state (yellow). When no service is responding, or all monitoring engines are DOWN, the node becomes DOWN (red).

The only service marked as* leading* is monitored when a node is in a DOWN state. If the service responds again, then the monitoring of all others starts again.

Node View Status

The view's status is calculated based on all node statuses included in the given view. If any node is in the Warning or DOWN state, the View Status is Warning.

When all nodes are DOWN, the view is DOWN, and when all nodes are OK, the view is OK.

Automatic Atlas Views

Based on typical Atlases used by our customers, we prepared many automatic views in NetCrunch. You can delete or edit them if they don't meet your data organization's needs. Grouping nodes makes creating reports and watching the status of a given group easy.
Each group's status is calculated based on the included elements (nodes or map links).

Dynamic Views

The dynamic view presents a group of nodes based on the filtering criteria (query).

Predefined Dynamic Views:

• Nodes with Issues
• Unresponding Nodes
• Responding Nodes with Active Alerts
• Monitoring Probes
• Receiver Nodes
• Business Status Nodes

Dynamic Folders

In addition to views, there is another level of grouping: The Dynamic Folder. It creates Dynamic Views automatically.

For example, we can quickly create the following hierarchy:

• Folder for each location
• Each view shows servers in a location grouped by OS types

List of predefined and automatic folders:

• Server Types (i.e., Linux, Windows Server, etc.)
• Device Groups (Printers, Switches, Wireless, etc.)
• Workstation Types (Windows 7, Windows Vista, Windows 8, 10, etc.)
• Locations (Office, Building 1, Server Room - based on SNMP or manually entered data)
• Network Roles (Network, Printers, Servers, Workstations)
• Virtual Machine Hosts
• Organizations
• VLANs
• Operating System Monitoring
• Nodes Using Templates
• Windows Domains

The views are dynamic, which means they are automatically updated as needed.

automaticconfigurationmonitoringpacks

Extending and Customizing

You can customize NetCrunch to suit your needs. Consider adding more MIBs and counters, creating views, and incorporating new device types, node fields, and node icons. Think about adding new background images for views, modifying notification message formats, defining new calculated counters, extending the node database, and developing alert action scripts.

NetCrunch comes with many predefined resources, like pre-compiled MIBs, Monitoring Packs, icons, etc. However, this might not be enough in the specific production environment, so we let you extend these resources accordingly.

Extending

SNMP MIBs

Now you can find any MIB for your device on the internet. You can find collections of more than 65 thousand MIB definitions.

NetCrunch has its own MIB compiler, allowing you to compile any MIB. Because some MIBs contain bugs, they may be cumbersome to compile.

If you have any problems compiling MIBs, please let us know, and we will try to compile MIBs for you.

SNMP Views

NetCrunch contains definitions of forms and tables displayed upon SNMP data from a device. There are groups of specific, detailed views for certain devices like printers, switches, or anything else.
Using these forms, you can change SNMP variables. You can also create custom view forms and tables using SNMP View Editor.

Custom Fields

Network nodes in NetCrunch are kept in an in-memory database and stored in XML files.
You can easily extend node data by adding additional fields. It will allow the classifying and grouping of the network data to suit your needs. The feature allows the creation of dynamic views based on these additional fields and using them to manage an alerting action as well.

Example:

Problem:

You want to notify a different group of Administrators (using groups is always more flexible than the single user) depending on the department and location where the server is located.

Solution:

Add a custom field for the department and set the location—set up dynamic node views based on the department and location fields. In the Alert action list, you can now define different notifications for each defined view.

Calculated Counters

Sometimes the device returns parameters that need to be calculated before further processing. For instance, the data needs to be divided, or we want to have percentages instead of raw values. You can solve such a problem by adding a Calculated Counter calculated upon the given expression. See Managing Calculated Performance Counters.

Custom Monitoring

You can extend NetCrunch monitoring using external scripts or programs or create a custom parser for data processing. The script can be run locally on the NetCrunch Server or remotely on other machines. You can also poll data using HTPP or let the parser process data received from a remote location using REST API. Read more in Sending Data to NetCrunch

Customizing

Custom Views

In NetCrunch, you can create your views of node groups that make managing alerts and reports easier. You can create your graphical views with customized icons and widgets.

There are separate tables for each node group view showing data specific to a given Monitoring Engine. You can customize each view easily.

Customizing of Administration Console Screen Layout

The Administration Console can be very flexible: it can run on multi-monitor systems, and you can create a custom multi-monitor layout.
As a second option, you can divide space and dock several windows to be visible on a large monitor. The layout is automatically stored, so NetCrunch will bring all windows to the same place when you run the console next time.

Customizing Notification Messages

Most events contain a large number of details describing the event context. You would not be able to see all of them in the text message on your smartphone or even in the email. You can create message formats suitable for notification types and specific alert types. Include the information you need. The program automatically creates HTML emails (you can also customize them) when sending an email, and it uses plain text for SMS/text messages.

Integrating NetCrunch with other NMS

You can easily integrate NetCrunch with existing management systems to extend its capabilities.

If you are already using some management system and would like to team it with NetCrunch as an extension of the overall network management system.

Integration by SNMP traps

If your system uses SNMP, the best way would be to use SNMP. You can monitor and collect data in NetCrunch and send alerts using SNMP traps to the external system. NetCrunch can automatically define SNMP traps for each alert defined, so after reading NetCrunch generated MIB, you can successfully receive these traps in an external system.

Integration by Event files

(hamburger menu)Settings Alerting & Notifications Alerting Scripts Add Alerting Script Add Logging Write to unique file This is most effective method of transferring events from NetCrunch to external program. You can use alerting action which can write each alert to the separate, uniquely named file.

The action allows using (write) some program periodically scanning the folder and importing event files to the external system. In this way, the disk is used as the queue for alerts. Each event can be stored in XML format.

Webhook Action

(hamburger menu)Settings Alerting & Notifications Alerting Scripts Add Alerting Script Add Logging Trigger Webhook

Webhook is a simple action that sends an HTTP request to a given URL with all event data as JSON or XML.

Integration by External Program

Unlike previous methods, this method should be used only for a small number of events, as it requires running the process for each transferred alert, which can be quite slow.

Exporting NetCrunch SNMP MIB with traps

(hamburger menu)Settings Monitoring Export NetCrunch SNMP MIB

After defining all alerts, you might decide to generate NetCrunch MIB, containing SNMP trap definitions for all NetCrunch-defined alerts.

Exporting Performance Trends Data

You can also periodically export performance data from NetCrunch and import it to the other systems.

Active Directory Integration

It makes agentless Windows monitoring much easier.

Server Integration

NetCrunch runs on Windows Server and needs to integrate with Active Directory in order to properly access other Windows machines in the domain.

Starting from Windows 2003, every newer Windows Server version takes security settings to a higher level. This makes it impossible to access Windows machines without explicitly setting access rights.

When installing on a Server in Active Directory

• The default option is to run the program on the local system account (which makes easy accessing local resources and communication between server components) and set up default credentials, common profile, or credentials for each machine (it's easy as you can use multi-selection to do it). The only drawback is that it might cause a security warning on some server systems, as the process running on the local system account attaches first as a machine object (machines are separate objects in the AD), and then it logins with given credentials.

• You can run NetCrunch Server services on a domain account that is a member of a local Administrator group of each monitored computer (including the server running NetCrunch Server). Sometimes it can be a good solution, but it can be also hard or impossible to configure. It requires modifying AD security policies (remember they need time to replicate).

Setting Active Directory account for the NetCrunch will give you:

• Proper security settings to remotely access performance data (Remote Registry, WMI, CIM).
• Access to AD information about computers and their systems.

You will still be able to access other Windows machines by giving local credentials for them, but it means that you have to input the necessary settings for each of them individually

User Accounts Integration

NetCrunch can use Active Directory user accounts as NetCrunch users. This allows keeping single passwords and makes management easier.

All you need to do is tick the Active Directory User checkbox when adding a new user. The username should be in the format: <Domain>\.

Managing NetCrunch Users through Active Directory Groups

You can manage access to NetCrunch by assigning access profiles to Active Directory groups.

Member of such group will be able to login to NetCrunch with AD credentials, and he will receive the NetCrunch account automatically. NetCrunch will assign an access profile according to the group setting.

If the user is a member of multiple AD groups, he will receive his profile according to the order of groups.

active directoryadad groupsgroupsintegration

Distributed Monitoring

Learn about monitoring probes that expand on-premises monitoring into distributed environments across multiple sites and address spaces

NetCrunch allows distributed monitoring using Monitoring Probes. The probe is a single agent installed remotely and can monitor an isolated network without additional agents.

Monitoring Probes can also be installed at the same place as NetCrunch Server, and you can offload the monitoring part of the network to additional probes with a single click.

The Concept

We designed distributed monitoring to be seamlessly integrated into the existing monitoring concept. If the node is located in a separate address space, its address gets an additional suffix with its name.

the above diagram has been created in NetCrunch

For example:

• When you see 192.168.0.234, it means it's the network address local to NetCrunch (Local - NetCrunch Server)
• Where 192.168.0.234@New York is the address located in the New York address space

Sites

$$

Monitoring Probe

The monitoring probe provides all monitoring and scanning features except the flow collector.

Adding nodes to be monitored by Monitoring Probe

1. First, you should add a Monitoring Probe node to NetCrunch Atlas. It doesn't have to be installed yet.
2. Add an IP Node and select your probe from the Monitoring Providers list

You can add sensors to the node and install the probe agent anytime.

Installing Monitoring Probe

1. Ensure the probe's NetCrunch communication port (default 12009) is accessible. You might need to map ports on your firewall.
2. Install the probe on the Windows machine. It can even be a Home edition as it doesn't violate the Microsoft CAL license. It's an agent that will connect to the server and other machines. It should work on any Windows system but is tested to run on Windows 10 or newer (an x64-bit system is required).
3. After Installing the software probe, the configurator starts automatically.
4. You must log in to NetCrunch using your NetCrunch account, select the probe node, or create a new one.
5. The probe agent receives an authentication token, which will be used for sending data to NetCrunch.

Connection

NetCrunch monitoring probe uses a native client protocol connection to NetCrunch that uses AES256 encryption with the Diffie-Hellman key exchange algorithm. Because the probe connects to the server, it can be located behind NAT and use the dynamic IP address.

Data Receiver

So the question is how you can use it. You need to add the Data Receiver sensor and send data to it. Read more about Sending Data to NetCrunch. You can build your agent script (in any language) or use the existing one to create a parser for data format.

address spacedistributedmonitoring proberemote proberemote sensor

NetCrunch Connections

Learn how clients and remote components connect to the NetCrunch Server — locally, through HTTPS, or via the NetCrunch Connection Cloud (NCC). Understand supported protocols, security levels, and available connection types.

Accessing NetCrunch

NetCrunch supports various connection types to enable access from consoles, browsers, remote probes, and external systems. Depending on your environment, you can use direct TCP, HTTPS, or NCC to securely connect.

Clients

NetCrunch allows connections from several types of clients:

• Desktop Console
• Web Console (Browser)
• Monitoring Probes
• API Clients & Webhooks

Administration Console (Desktop)

The NetCrunch Administration Console is the most powerful and optimized client, designed for fast, real-time interaction. It caches a large amount of data locally and synchronizes only the changes with the server, providing high responsiveness and reduced load.

It supports fine-grained access control, so it is no longer limited to administrators. Users with proper access rights can perform limited administration tasks — such as managing specific nodes or views — without requiring full administrative privileges.

Supported Systems

• Windows 8 or newer (recommended: Windows 11)
• Supports multi-monitor and touch devices

Connection Methods

• Encrypted TCP – Use server address or name (port 12009)
• Secure WebSocket (HTTPS) – Connect via Web Server (wss://your-server)
• NCC (Cloud) – Use license ID (e.g., YZ-123-456) as the connection key

Features Exclusive to the Admin Console

• Configure monitors, sensors, and monitoring packs
• Manage alerting policies and response actions
• Edit node properties and apply monitoring roles
• View full alert and event history
• Use diagnostic tools: Logs, SNMP Tools, Perfmon Explorer
• Import/export configuration templates
• Access Object Explorer and MIB Browser
• Manage NetCrunch modules and task schedules
• Delegate limited admin permissions per view or node
• Faster performance than the Web Console due to local caching

Web Console (Browser)

The Web Console provides access through modern HTML5 browsers and is ideal for remote visibility and lightweight tasks.

Features

• View and edit Graphical Views
• Browse Atlas Tree, Events, and Reports
• Role-based access per user or group
• Excellent for executives or helpdesk roles

Supported Browsers

• Edge 86+, Safari 15.4+, Chrome 86+, Firefox 86+, Opera
• Internet Explorer is not supported

Monitoring Probe

The NetCrunch Probe is a remote monitoring engine designed to operate behind NAT/firewalls in branch offices or customer sites.

Connection Methods

• TCP (12009) – Standard direct connection
• HTTPS WebSocket – Secure relay through Web Server
• NCC Cloud – Simplest and most secure method

Sending Data to NetCrunch

External data can be pushed into NetCrunch through:

• Webhooks for status and event injection
• REST API for metrics and status objects
• Data Parsers for log or file-based input

Security & Protocols

NetCrunch supports multiple access paths. Each has a different level of security and use case:

Direct TCP (Port 12009)

• Security: Medium
• Encrypted, no certificate validation
• LAN-only or via VPN

HTTP

• Security: Low
• Unencrypted, not suitable for production

HTTPS (Self-Signed)

• Security: Medium
• Encrypted, browser warnings expected

HTTPS (Valid Certificate)

• Security: High
• Full encryption + certificate validation
• Required for secure WebSocket (wss://)

NetCrunch Connection Cloud (NCC)

• Security: High
• Requires no port forwarding or NAT traversal
• Works via outbound HTTPS (port 443)
• Supports:
  • Desktop Console
  • Web Console
  • Remote Probes

Use @<license-id> as the server address when connecting (e.g., @YZ-123-456).

Communication Scenarios

The following diagram summarizes the three common deployment scenarios:

• Local Deployment (LAN) – Direct TCP & HTTPS
• HTTPS-Only Deployment – For DMZ or simplified security models
• Cloud Relay (NCC) – No inbound traffic needed

Diagram created using NetCrunch Graphical Views.

Deployment Considerations

• In HTTPS-only mode, all connections to the server are inbound. This typically requires firewall rules or a reverse proxy (e.g., NGINX, HAProxy) in front of the NetCrunch server to properly route and secure access.
• In Cloud Relay (NCC) mode, the server initiates a single outbound HTTPS connection (port 443) to the NCC relay. No inbound connectivity is required.
  This architecture is highly resilient and is an ideal solution for zero trust environments, where inbound ports are blocked and all communication must be explicitly initiated and authenticated.

Related Topics

certificatecloudconnectionconsoledata receiverhttpweb

NetCrunch Connection Cloud (NCC VPN)

A resilient, secure platform for zero-configuration access to NetCrunch from any location — ideal for modern, zero trust environments.

Overview

NetCrunch Connection Cloud (NCC) provides a reliable, secure, and cost-effective way to access the NetCrunch Server from any location without requiring firewall changes or VPN configuration. Much like point-to-point VPNs, NCC establishes an encrypted HTTPS tunnel from the server to the cloud — enabling remote access without exposing any inbound ports.

Unlike traditional VPNs, NCC does not expose the internal network. Instead, it functions as a relay, brokering HTTPS connections from clients (e.g., Console, Browser, Probe) to the server.

The only requirement is that the server must be able to make an outbound connection on port 443.

Key Features

Zero Configuration Access

• No need to expose ports or reconfigure firewalls.
• The NetCrunch server connects outbound to the NCC service.
• Users connect using a simple ID (your license number).

Optimized for Zero Trust Environments

• No inbound connectivity required to your internal infrastructure.
• Minimizes attack surface and simplifies perimeter security.
• Works with any network that allows outbound HTTPS traffic.

High Availability & Regional Redundancy

• NCC runs in multiple regions for low-latency, fault-tolerant access.
• Connections are relayed via the geographically closest NCC node.

Secure Data Transmission

• No data is stored in the cloud — NCC functions purely as a tunnel.
• HTTPS is used end-to-end between client and server.
• NCC never sees decrypted monitoring data or credentials.

Enterprise Customization

• Enterprise customers can request a private NCC node, ensuring that connections bypass public relays entirely.
• Enables complete isolation and compliance with sensitive data requirements.

Full Client Compatibility

NCC supports secure connection from:

• Desktop Console — Choose “Connection Cloud” and enter your license ID
• Monitoring Probes — Use @<license-id> instead of an IP address
• Web Console — Open https://ncconsole.net/rc/connect/<license-id> in your browser

The <license-id> is your NetCrunch license number, visible in the About box of the Console.

GDPR Compliance

NCC is designed from the ground up to comply with strict privacy laws like the GDPR.

Data Privacy by Design

• NCC stores no personal data or monitoring content.
• It acts solely as a connection broker, forwarding encrypted HTTPS traffic.
• No metadata is retained about sessions beyond what is required to establish routing.

Regional Data Flow

• Connections are routed through the closest NCC region.
• Regional relaying helps reduce cross-border data movement.
• For enterprise customers, private relays can be deployed in specific countries or data centers.

Enterprise-Level Security

• Exclusive nodes ensure single-tenant isolation.
• Supports secure TLS transport with certificate validation.
• Future roadmap includes support for MFA and SSO.

By meeting these criteria, NCC helps organizations stay compliant while maintaining top-tier network security.

Why Choose NCC?

• Perfect for remote workers, branch offices, and MPLS-free environments
• No NAT, port forwarding, or VPN configuration
• Maintains outbound-only security posture
• Enables a true zero trust deployment model
• Backed by high-availability relay infrastructure

Connecting

To connect using NCC:

• Desktop Console → choose Cloud Connection and enter your license ID (e.g., @YZ-123-456)
• Monitoring Probe → enter @<license-id> in the server field
• Web Console → visit
  https://ncconsole.net/rc/connect/<license-id>

The license-id is your NetCrunch license number.

Excerpt from the NetCrunch Connections diagram — highlighting the Cloud Relay (NCC) communication model.
Diagram created using NetCrunch Graphical Views.

Related Topics

cloudconnection cloudnccsecure connectionvpnzero trust

NetCrunch Licensing

NetCrunch licensing is node-based and allows monitoring of switch port interfaces whose number equals or is lower than the number of nodes.

Node License

NetCrunch licensing is based on the number of nodes, but we also count the number of monitored interfaces. If the number of monitored interfaces exceeds the number of nodes, additional interface licenses are required for the excess interfaces.

For instance, with a license for 500 nodes, you can monitor 500 nodes AND 500 interfaces. If you want to monitor 500 nodes and 700 interfaces, you'll need 500 node licenses AND an additional 200 interface license for the excess.

If you do not monitor switches only, then you only look for the total number of monitored nodes (devices). In other cases, If you want to monitor layer 2 connections of your switches, then you need a license covering the total number of switch ports that you wish to monitor that exceeds the total number of switches.

Additive

NetCrunch licenses are additive. This means that, for example, if you purchase a 100 node/interface license and then decide to get a 50 node/interface license, you will have a total of 150 nodes/interfaces license. You can purchase an additional node pack at any time and add it to your NetCrunch - no need to reinstall or software restart, you just need to refresh the license.

Interface Monitoring

By default, interface monitoring is enabled only on SNMP devices. However, interface monitoring can be enabled on all monitored nodes, if desired. Interface monitoring can be adjusted on a per-node basis within NetCrunch preferences.

By default, only All Active type interfaces are monitored. 'Other' or 'Loopback' type interfaces do not count for license size unless you adjust the monitoring schema manually.

It's possible to create an interface monitoring schema to include only interfaces that match the filter you need.

To change the default schema or create additional schemas, go to (hamburger menu)Settings Monitoring Interface Monitoring Settings

interfacelicensingnodeport

Configuration

Everything you should know about configuring NetCrunch, including Initial configuration, alerts and reports.

Before You Begin

Configuration of NetCrunch can be easy or hard - depending how you start. There are many configuration possibilities, and if you know which one to choose in a given situation - everything becomes simple.

1. Read Architecture and Concepts to quickly review the options.
2. Important task you need to perform first: Windows Monitoring Setup.

Discovering your Network

This article will help you get through network discovery and the initial configuration process.

To monitor your network, NetCrunch must know device addresses, their names, and how to connect to them (credentials, types, etc.). The Network Atlas is a database holding all that information, so that the first step will be adding nodes to your Network Atlas.

Manually

You can add nodes from a file, and then you can do the rest of the setup manually. It's even possible to create an empty Atlas and add every node manually, but it's unlikely you would need that feature.

Nodes can be added from the text file, containing either names or addresses of nodes - one per line.

By Network Discovery Wizard

tabDiscoveryMethod

Discovery Methods

Search Active Directory Domain

The program searches Active Directory and adds all devices, including other operating systems like macOS machines.

The program scans only the Domain, where the NetCrunch Server machine object is located.

All machines from Active Directory will be added even if they are currently not connected to the network.

Discover IP Networks

The program will scan a given range of network addresses using ICMP (ping) packets. Only connected and responding nodes can be discovered in this way, so results may vary depending on when you perform the discovery.

tabNetworkSelection

Networks to Be Discovered

NetCrunch fills the list with known networks; you can add more networks as desired.

The program uses ICMP PING packets to discover nodes in a given network, and only nodes responding to ICMP PING packets are added.

Discover and scan neighborhood networks option

During the discovery process, NetCrunch finds connections to neighborhood networks. Enable this option if you want NetCrunch to follow these links automatically. You can limit the scanning depth by specifying the number of maximum hops to remote networks.

Discovery Mode

All Devices

The program will try to find and add as many devices as it can find. It will look into SNMP and use PING sweep.

Infrastructure Devices Only

The program will skip workstations.

Only devices matching SNMP filter

Build a filter query that will include desired devices. The program will try to communicate with any given SNMP profiles and determine which profile needs to be used for the device.

tabSNMPMode, tabSNMPSettings

Configure SNMP Profiles

This is the point where you should enter all the SNMP profiles used by your SNMP devices.

If you fail to do this now, you can enter them later, but you will have to assign them to each device one by one.

If you enter the SNMP profiles now, the program will automatically determine which profile is used by which device, and devices will be marked as SNMP manageable. Additionally, device types should be discovered (by sysObjectId SNMP variable or device SNMP name), and automatic monitoring will be set.

SNMP Agents Port

SNMP Discovery assumes that you use only one SNMP port for all devices in your network. By default, SNMP agents respond on a port 161. If you use different ports for different devices, you have to set them up manually.

tabNetworkServices

Select Network Services To Be Discovered

NetCrunch recognizes and can monitor about 70 network services. Discovering all of them might be time-consuming and might generate unnecessary network traffic. As a result, we decided to include 14 common services by default, and you can add more services as desired.

Here you can also set the initial parameters for each monitored network service.

Repeat Count

The number of requests to be sent in one monitoring check to determine the average response time properly

Additional Repeat Count

The number of additional requests to be sent in case base requests fails.

Timeout

Time after which NetCrunch gives up on waiting for a response

You can decrease timeouts if you monitor network devices in a network with low latency. Default values should work great, even for internet connections.

Next Step...

After NetCrunch discovers all your devices, it starts discovering network services on each device in the background.

This is a time for further configuration: automatic Monitoring Packs, setting credentials, setting NetCrunch users and administrator profiles, and default alerting scripts.

Go to: Configuration Wizard

create atlasdiscoverynetwork discovery

Configuration Wizard

Configure automatic Monitoring Packs, set credentials for different systems, set up NetCrunch users, and profile for the Administrator. Customize the default alerting script.

tabMonitoringAreas

Automatic Monitoring Packs

Each Monitoring Pack contains the definition of alerts and data that needs to be collected by NetCrunch. NetCrunch contains predefined Monitoring Packs and bounds them to nodes upon filtering rules.

tabCredentials

Monitoring Credentials

To monitor anything, NetCrunch must connect to various systems using the proper credentials. You can set all default credentials (to be used if you do not set a specific one for the node) for supported operating systems (Windows, Linux, BSD, macOS, Solaris, ESX/i).

tabAlertingScript

Notification Scheme

All predefined alerts use the Default Alerting Script. You can edit it later in detail, but you can make some preliminary settings here.

Go to: Configuration Tips

config-wizard

Network Atlas Views

Read about types of views and how they organize your data.

The Network Atlas is a part of the Automatic Monitoring and Organizing concept. It is a central repository of all views, grouping network nodes by categories such as nodes from the same network, a single layer 2 segment, or nodes within the same area.

The fundamental element of the Atlas is a network node: a single-address network endpoint. Because many devices use multiple interfaces, they can be grouped, and then you can decide to monitor only the primary interface.

Atlas Views

The Atlas Views hierarchy helps you recognize each node group's status. A top-level (root) view of the Atlas contains all nodes, sub-views, and dashboards showing aggregated information for all nodes.

Common Views Properties

• Alerting & Data Collection - You can define alerts that will be inherited by all nodes in the view.
• Top Charts - Specify a list of top charts for the view.

Atlas Sections

Below the Top Level Views are four main sections of the Atlas Views.

IP Networks

This section consists of IP network views/maps. Each network can be periodically re-scanned to reflect its current state. Network maps are usually automatically arranged, and the device model and OS name group nodes.

Each IP node is a part of some network view. Deleting a node from any IP Network View will cause deletion from the Atlas. Deleting the View will delete all nodes contained in the View.

Sites

Networks are grouped into sites. By default, local networks are those accessible directly by NetCrunch Server's network interfaces.

(0.0.0.0/8) - Empty Network

Sometimes, a node is specified by its name, and its address has not been resolved yet. In this case, it belongs to the empty network view.

Specific Properties

• Automatic node rediscovery - You can set (enabled by default) each network to be automatically scanned to find active nodes. The minimum rediscovery time is 1 hour. You can also specify the exclusions list.

• Discover New Nodes - you can manually start the discovery of network nodes.

Network Topology

Routing Map

An automatically created view shows a map of logical connections between IP networks. The view is updated automatically when NetCrunch detects changes in topology or on demand. You can edit the map and adjust node positions. A routing map is automatically created for each address space.

A routing map can be automatically laid out as a graph or hybrid map.

Sample Routing Map

Physical Connections

This section contains a hierarchy of views showing Layer 2 connection segments. Each view is automatically arranged and shows the traffic summary for each switch port.

To start monitoring Physical Connections, you need to point the switches to be used to a network topology map. Switches must be defined in the Atlas and have correctly set SNMP profiles.

After you click on (hamburger menu)Settings Monitoring Physical Connections Monitoring, the Physical Segments Configuration Wizard will start. It will try to find switches that match the above requirements. If you can't find the switch but know it supports RFC 1493 MIB, please check if it's in the Atlas and its device type is set to Switch.

To create topology maps, NetCrunch primarily uses protocols such as STP and Cisco CDP, and LLDP, as a fallback, uses SNMP Forwarding Tables (RFC 1493). Make sure you have enabled CDP or LLDP to ensure the best results.

NetCrunch can create a layout depending on the topology, such as a tree, star, or graph.

Example Tree Topology

Custom Views

This section allows you to organize your network data. Here, you can add your own Node Group Views and manage them using folders. You can create graphical maps for the view and create links between them. You can also create automatic folders to manage automatically created views.

Automatic Views & Folders

The primary goal of NetCrunch is to monitor the network's state as it changes over time. It’s better to set up and configure views based on rules to maintain dynamic network relations.

Predefined

Based on typical customer Atlases, we prepared some Automatic Views (aka dynamic views) for you:

• Nodes with Monitoring Issues
• Unresponding Nodes
• Responding Nodes with Active Alerts
• Monitoring Probes
• Receiver Nodes
• Composite Status Nodes
• Unknown Device Type
• Server Types (Linux, Windows Server, etc.)
• Device Groups (Printer, Switch, Hardware Router, etc.)
• Workstation Types (Windows 8, Windows 10, Windows 11)
• Locations (Office, Building 1, Server Room - based on SNMP or manually entered data)
• Network Roles (Networking, Servers, Workstations, Printers, Other)
• Windows Domains
• Virtual Machine Hosts
• Organizations
• VLANs
• Operating System Monitoring
• Nodes Using Templates

All Automatic Views are dynamic; they are automatically updated as needed. By default, all empty views are hidden. These views can be modified, and you can treat them as examples of how easy it is to create dynamic views in NetCrunch.

Automatic Folders

You can create a set of automatically updated views as data changes. For example, you want a separate view of each city where devices are located.

You need to specify the node field for creating views, and you may also decide to make only separate views consisting of more than five elements. Otherwise, nodes will be placed on a single view.

As these views are automatically created and deleted, you can't manage alerts and reports using them.

Specific Properties

• Node Filtering - Specify the filtering condition
• Folder Content - Specify the grouping field and manage groups and their icons
• Appearance - Set an icon for the folder

Dynamic Views

The views are managed through specified filtering conditions (query).

Example:

The domain equals ad.adrem

Specific Properties

• Node Filtering - Specify filtering conditions

Graphical Views

graphical-views

Graphical Views allow creating live visual dashboards, maps, and diagrams to represent network and system status. They combine diagrams and widgets with interactive, responsive rendering that adapts to user roles and device type.

Graphical Views are flexible, real-time visualizations used in dashboards, maps, and diagrams. They support both panel-style dashboards and boundless map canvases, offering a unified visual experience.

Key Concepts

• Panel Views – designed with a fixed aspect ratio and responsive layout. Panels automatically scale to fit the display area, making them ideal for dashboards optimized for desktops, tablets, phones, or large displays. Two scaling modes are available:

  • Fit all widgets – scale the panel so only visible elements fill the screen.
  • Fit entire panel – scale the full layout area regardless of content.

• Boundless Maps – scrollable and zoomable freeform canvases ideal for visualizing layouts without screen constraints. Background images (e.g., floorplans or logical schematics) can be freely positioned. These maps are designed for manual panning and zooming, useful when content intentionally exceeds screen size.

• Dynamic Content – elements like shapes, lines, icons, and text can be linked to live NetCrunch objects such as nodes, services, or metrics. Their appearance dynamically changes based on object state (e.g., color, visibility, shape).

• Theming – views automatically adapt to the user's light or dark theme preference. NetCrunch uses a single view definition across themes, unlike other platforms that require duplicating views per style.

Types of Graphical Views

Each view type supports specific layout and interaction patterns:

Free-form Diagrams

Used to build logical or status-oriented network diagrams. Objects can be positioned manually and connected using live status lines.

Image: Simple network diagram

Boundless Maps

Used for large, navigable visualizations with no fixed layout size. Suitable for: - Floorplans - Wiring diagrams - Device placement maps

Image: Operating boundless diagram

Users can add a background image and freely arrange visual elements without zoom constraints.

Dashboard Panels

Responsive visual containers designed with a fixed aspect ratio. They scale to fit display dimensions while preserving layout. Ideal for: - Mobile dashboards - Status displays - Kiosk and wall-mounted views

Image: Simple dashboard example

Two smart scaling modes allow for optimizing visibility either by content or full panel size.

Image-based Panels

Use a background image (e.g., rack, datacenter, topology drawing) placed inside a fixed-aspect panel. The image can be scaled and positioned relative to the panel, with live elements overlaid.

Image: Sample floor plan with camera widget

Geographical Maps

Predefined region-based maps with geo-location support. Over 100 maps are available (e.g., countries, states, regions). Unlike embedded browser maps (e.g., Google Maps), these are vector-based contour maps. - Users can place elements based on coordinates. - Locations can be resolved via Google’s geolocation service. - Suitable for regional monitoring dashboards or location-aware topologies.

Image: Camera locations across the world

Theming Support

• Users can switch between light and dark modes.
• A single view supports both themes automatically.
• View elements and background adapt accordingly—no duplication needed.

atlasboundless viewschartsdashboardsdiagramsgeo mapgraphicalgraphical viewsimage panelip networklayer 2mapsresponsive designsegmentsthemingviewview typesvisualization

Alert and Report Management

Read about scheduling reports, the difference between an event and alert, Monitoring Packs, and message formats.

Monitoring Packs and Node Settings

Although alerting and reporting serve different purposes, their settings are very similar.

NetCrunch manages alerts and data collectors in the same place through Monitoring Packs and Node Settings.

Report Scheduling

To collect data for reports, add data collector to specific Monitoring Packs or nodes. To create a report, you need to select one of the defined Report Scheduling Schemes (or define your new one) and specify the user or a group which should receive the report.

Read more about Customizing NetCrunch Reports

Events and Alerts – what's the difference?

As we assign an event condition to be watched or received by the program, it turns into an alert containing a log of operations taken and the response to the event.

In other words: the program is the alert guard watching for specified event conditions. When we decide to create a new alert, the default action is to write it to the NetCrunch Event Log. You can assign a common Action List to an alert or create custom sequences of each alert's actions.

Defining Events

Each Monitoring Engine defines its own set of events to watch. There are many predefined event conditions, mainly to track well-known object states such as Windows Services, Network Services, Nodes, etc.

There are many more events than defined in the software. For instance, when you monitor external Syslog events, you need to describe which ones you want to be NetCrunch events. If you decide to turn all Syslog messages into a single event definition, you won't set different alerts for different messages.

The most important types of events you can define are Event Triggers for Counters, which you can set on any performance counter value and allow you to set logic for observed counter values.

Common Event Definitions

When you create a new event condition to set an alert, you can save it for later use and add it later to another node or policy. Both nodes (or Monitoring Packs) will share the same event condition. You can modify it for one node or all nodes sharing the same condition when you want to change it.

By default, NetCrunch saves all new rules as common definitions.
If you want to change this setting, uncheck Save as common definition before saving a new event. If you want to manage common definitions or remove unused ones, go to NetCrunchAlerting & NotificationsMonitoring Packs and PoliciesCommon Alerts

Setting Alerts & Reports

Setting alerts using Monitoring Packs: SettingsAlerting & NotificationsMonitoring Packs and Policies.

You can override or add alerts and Monitoring Packs to a node or multiple nodes by clicking on a node (or selecting multiple nodes) Node SettingsMonitoring

See Managing Multiple Node Settings

Report Types

There are two main types of reports: aggregated for a group of nodes and single node reports. Both of them need data.

Data collection management is very similar to alert management. It needs to be specified for a specific node. You can do it through Monitoring Packs, Atlas Views, or set it directly in the Node Settings window.

Monitoring Packs

Automatic Monitoring Packs

Automatic monitoring packs specify a node filtering condition, allowing you to automatically apply the Monitoring Pack to nodes.

Most predefined Automatic Monitoring Packs bind through a specifying operating system type and some additional conditions.

Example:

NetCrunch adds Active Directory monitoring pack settings to node if

Operating System is equal to Windows Server and,

Network Service List contains any of the following LDAP, LDAPS.

Each Automatic Monitoring Pack has an Exclusion List, which specifies nodes that should be excluded from the given condition.

Static Monitoring Packs

You can add a Static Monitoring Pack manually to a node using Node SettingsMonitoring, or you can open the properties of the Monitoring Pack and click on the Assigned to page.

See the list of predefined Monitoring Packs

Global Monitoring Packs

Settings Alerting & Notifications Monitoring Packs and Policies

In the NetCrunch Monitoring Packs & Policies window, you can find the Global group.

It contains a list of special predefined Monitoring Packs. Some apply to all nodes; some are Monitoring Packs that refer to globally collected data such as NetFlow traffic summary. When you modify the Node Status pack, be aware that each alert will be automatically monitored for all nodes.

• Node Status - sets monitoring alerts of node status for all nodes.
• Service Status - alert on connection reliability degradation, PING RTT > 1000 ms, Any Service is DOWN, Any Service is UP.
• Global Flows - You can set triggers on summary counters from the NetFlow server. See: Network Traffic Monitoring.
• NetCrunch - sets alerts for adding or removing nodes from the Atlas, NetCrunch Server auto restart, and automatic backup of the atlas. You can also set a NetCrunch Status Event: a heartbeat event generated periodically containing NetCrunch status.
• NetCrunch Self Monitor - this monitoring pack for NetCrunch Server monitoring contains alerts about various NetCrunch Server components. It contains alerts about NetCrunch maintenance, backup, and more.
• NetCrunch Audit - tracks all NetCrunch users' logins and logouts, including failed logins to the program's desktop and web consoles.
• Network Traffic (SNMP) - defines data collection for traffic monitoring: Summary of Network Traffic, Network Traffic by Interface, Interfaces Utilization. It's automatically applied to devices with SNMP and interface monitoring enabled. See: Network Traffic Monitoring.
• Correlations - here, you can add alerts triggered when two or more alerts on different nodes happen simultaneously. For example, alert when two connection links are down. You can add correlations using the Active Alert state or by defining the time range window where all events must be triggered.
• Physical Segments - this automatic monitoring pack applies to all nodes connected to a switch. It contains alert rules related to changing the physical linkage of the node.

Overriding Monitoring Pack settings

When you add Monitoring Packs to the node (or if they've been added as automatic Monitoring Packs), the node settings become a sum of settings from multiple packs applied to the node.

You may override the settings for a specific node. Select a node (or multiple nodes) and open Node SettingsMonitoring and click on the desired Monitoring Pack, then you will be able to disable or override alert actions defined by the given Monitoring Pack. The automatic Monitoring Pack can be disabled on a particular node.

Alerting Actions

Actions are executed as a reaction to an alert. Actions are always grouped in the Action List sequence.

See Alerting Actions

Action List (aka Escalation Scripts)

The action list is the sequence of actions executed in response to the alert. It's grouped according to the execution delay time.

Escalation

Some actions may be executed immediately, and others may wait several minutes to start. The last action in the list can be repeated until the alert is closed ( the issue is resolved). You can also define a list of actions executed when an alert is closed. Each action can have restrictions allowing to execute it only in certain conditions, such as alerts in a certain time range. The node only being a member of a given Atlas View or alert has to have a certain severity.

Managing Message Formats

Settings Alerting & Notifications Message Formats

Event descriptions are very different. There are several fields common to each NetCrunch event, but most of the data come from various external sources like Syslog, SNMP traps, Windows Event Log, or different Monitoring Engines.

Defining a single message format for each event and notification target is hard. It's rather apparent that sometimes you might expect to receive an HTML email full of content and other times a short SMS with only the most essential info identifying the problem.

Another application for Message Formats is passing parameters to various external actions like executing a program or writing event data to a file.

Internally, NetCrunch uses the XML format for event representation. Although it's a text format, you can hardly call it a "human-readable" format.

You can see the default message format assignments for all actions in this window.

Message Format Types

There are eight predefined message formats used by different actions:

• txt - text format
• short-txt - short text format
• sms-txt - short text for SMS messages
• syslog - text message for sending to syslog server
• export-txt - text format
• email - HTML email format
• email-txt - text email format
• ticket - text email format

Modifying Message Format Assignment

Each action type has a default message format assigned. You can change the assignment by clicking on a format name in the Message Formatcolumn.

Customizing Message for Specific Event

Switch to page Message Definitions. Here you can see message definitions grouped by Message Format. You can define a custom message format for a specific event or an event class for each message format.

Example:

We want to create a custom SMS text message for the Node State Event to include the Location field's value.

1. Click sms-txt.
2. Click on Add in the bottom left corner.
3. Select Node State Event from the event 'Class' drop-down menu. In the 'Event' field, select .
4. Edit the displayed message content. Click Add Parameter to add the Location parameter. You can remove the fields you do not want to include in these alerts.
5. Save the modified message by clicking OK.

alertcustomformatmanagingmessagereports

Customizing NetCrunch Reports

Read about what custom reports you can create and how it can be done.

Options

Settings Resources Reports

Limit the size of email with reports

Enable the option to avoid sending large emails, as some reports can have multiple pages and be too large for your mailbox.

Add footer signature

It will be placed at the bottom of each report page. It can be: atlas name, netcrunch server or custom text.

Add logo image

An image of size 100x40 pixels will be placed on every page footer. If you select a larger image, it will be automatically resized.

Creating Custom Reports

Settings Alerting & Notifications Policies Monitoring Packs and Policies

You can add new reports to the Monitoring Pack or directly to the node. For instance, you may want to add a PING availability report for the specific node.

1. Open Node Settings
2. Click PING
3. + Add Collector
4. Double-click the in the Network Service Reports section.
5. Click OK (add a description for the newly created report).

This will add predefined [PING] Availability Report

NetCrunch contains several template reports, predefined reports, and the ability to create custom reports. Template reports are pre-defined reports that need only parameterizing.

Template Reports

Network Service Reports

Service Availability

The report contains:

• Total uptime and downtime summary,
• Chart of service response time in a given time range,
• Chart of service failure rate in a given time range

Network Service Map Reports

The report summarizes and compares a given number (10 by default) of top nodes.

Service Availability

The report contains a comparison of:

• Check Time - Nodes with the lowest and highest average check time
• Failure Rate - Nodes with the lowest and highest average failure rate

Service Response Processing Time

The report compares nodes with the lowest and highest average response processing time.

Service Uptime

• Service Availability (by total service uptime)
• Service Unavailability (by total service downtime)
• Longest service uptime and longest service downtime

Performance Reports

Chart Report for Performance Counter

Single Node

This report allows for presenting multiple counters' trends in one document. It shows a single-line trend chart for a given time range. You can choose to have 4 charts per page or just one.

Multiple Nodes

This report is similar to a single node, but trends from multiple nodes (and the same counter) can be grouped on a single chart. You can customize the number of trends put on a single chart.

Node Performers Counters View

This report includes the list of monitored counters with their current values.

Custom Report

You can add a custom report for any counter you want to monitor for a given node or group of nodes.

Scheduling Reports

You can have each report you add to a Monitoring Pack or Node Setting be automatically created and scheduled.

Scheduling Scheme

Settings Resources Report Scheduling Scheme

Each report can be scheduled using a predefined schema with criteria for each report type (daily, weekly, monthly). You need to specify the recipients. createcustomizereports

Event Triggers for Counters

NetCrunch allows for the setting up of various threshold conditions on performance data regardless of origin. This works for all performance data channels, from SNMP data to data received through the REST API.

Thresholds

Thresholds trigger an event when a value is crossing a given border. Depending on the direction's change, it can be a rising or falling threshold condition.

A simple threshold specifies only the threshold value and the direction.

Rising threshold example:

% Processor Utilization > 50%

Falling threshold example:

% Free Disk Space < 10%

Hysteresis

Hysteresis can be used to avoid generating too many threshold events on fast-changing values. This is done by setting an additional resetting value.

Example:

Trigger on

% Processor Utilization > 50%

Reset if

value <= 45%

Thresholds can be configured based on the last value or the average value calculated over a specified time range.

Flat Value Trigger

This trigger generates an event when the counter has (or has not) the same value in the given period.

Example:

% Processor Time = 25 for the last 5 samples

State Trigger

This trigger generates an event when the monitored value changes from one value to another. You need to specify at least one value.

Example:

Network Card Error State changes from <any> to 5

The event can be reset when the value changes to the previous state or any other value.

Value Missing/Exists Trigger

This trigger generates an event if value exists or is missing (can't be read or received) in a given time range.

Example:

There might be no value until an error occurs, so the program can react to a value exists condition instead.

Delta Trigger

This trigger alerts you when the current counter value keeps growing or decreasing by a given value. You can also define the opposite condition when the counter is not growing or decreasing as expected. Delta is the difference between the last and the previous value.

Example:

 Device Internal Timer Delta    < 1 

Deviation Threshold Trigger

This trigger allows you to specify how a counter value can differ from the calculated average over a given period. The deviation can be set as a percentage or by absolute value.

Example:

Trigger on

% Round Trip Time Deviation > 10%

Reset if

Deviation < 8%

Calculate an average for the last

3 samples

Range Trigger

This trigger simplifies configuration. Instead of two separate thresholds for a low and high boundary, you can specify a range. The event triggers if a counter value is in the range or outside the range. Additionally, you can specify the reset tolerance value.

Example:

Trigger on

Server Room Temperature is outside the range [ 20 ... 22 ]

Reset if

Falls in the range with a margin of 2

Baseline Threshold Trigger

This trigger allows setting thresholds for deviation from observed baseline data. The program collects baseline data over a week and stores them for reference. The baseline is calculated for each hour and each day of the week.

The user can specify the allowed deviation from the baseline value (by a number or a percentage).

Example:

Trigger on

Server Room Temperature deviation from baseline > 1

Limit Trigger

This trigger allows you to set an alert on a limit on the aggregated value of a given parameter. For example, it might be the number of bytes transmitted per day or week.

It works to counter-represent value per second or accumulate values (increasing).

Available periods:

• current hour
• current day
• week, starting on Monday - Sunday
• month, starting on a specified month-day

averagebaselineeventhysteresislimitperformancerangethresholdtriggers

Managing NetCrunch Users and Notifications

NetCrunch supports a flexible, role-based user system with access control for views, nodes, and features. You can integrate accounts with Active Directory, define granular access rights, and control notifications per user or group. This topic explains how to manage user accounts, access profiles, and notifications effectively.

access profilesactive directoryadmin accessdesktop consolenotification groupsnotification profilesoauthorganizationpassword resetshared useruser managementuser rightsweb console

User Access in NetCrunch

NetCrunch allows fine-grained control over what users can see and do. This applies to both the Desktop Console and Web Console, with different capabilities:

• Desktop Console: Fully supports user permissions and now allows delegated administration—users can be given limited admin rights scoped to nodes, views, or specific features.
• Web Console: Primarily designed for viewing and interacting with monitored data. It supports access profiles for restricting features, but does not yet offer full administrative functionality. We’re actively working on expanding these capabilities.

Both consoles require users to authenticate. Access rights, personalization settings, and notification profiles are stored per user on the server.

Types of User Profiles

Built-in Admin Profile

NetCrunch includes a predefined Admin user that always has full access—similar to a root account. It cannot be deleted. Its password can be reset from the Desktop Console using User & Access Rights Manager → Change Password.

Resetting the Admin Password Using NCCLI

If the Desktop Console is unavailable or the built-in Admin account becomes inaccessible, you can reset the password using the NetCrunch Command-Line Interface (NCCLI).

To do this:

1. Open a terminal on the NetCrunch server
2. Navigate to the NetCrunch\bin directory
3. Run the following command:
   nccli.exe reset-admin-password

Replace your_new_password with the desired password. This resets the password for the Admin account immediately. You must run this command with administrative OS privileges.

This method ensures password recovery even when no console access is available.

Standard User Profile

Every standard user has:

• A personal login and access profile
• Notification settings
• Console preferences
• Optional AD integration

You can assign users full or read-only access, or create custom access profiles for fine control.

Shared or Public Profiles

You can create shared login accounts (e.g., noc-operator) with restricted permissions. To prevent unauthorized changes:

• Enable: User cannot modify profile or password
• Ensure the profile has a defined password
• Disable profile editing in the Access Profile

This is useful for rotating operators, kiosks, or NOC stations.

Authentication Options

Local Accounts

Users can authenticate directly with credentials defined in NetCrunch.

Active Directory Integration

NetCrunch supports full AD integration, allowing centralized account management.

User Account Linking

You can link a NetCrunch user to an AD account via the Link with AD Account option. This syncs login identity and delegates password handling to AD.

AD Group Integration

Assign access profiles to AD groups to enable role-based control. When an AD user logs in:

• NetCrunch checks group membership
• The first matching access profile is applied
• If no match is found, login is denied
• If the user loses group membership, access is revoked automatically

You can control group evaluation order and priorities.

Organizations

NetCrunch supports multi-tenant visibility via organizations.

• Each user belongs to one organization (default is <root>, which sees all nodes).
• Nodes can be assigned to specific organizations.
• Users only see nodes and views relevant to their assigned organization or marked as public.

This model is ideal for MSPs, large enterprises, or restricted internal teams.

Access Profiles

Access Profiles define what a user is allowed to do or see. They control:

• UI visibility (settings, maps, dashboards, tools)
• Access to configuration features
• Permissions to edit, acknowledge, or reset data
• Profile edit rights

Predefined Profiles

• Administrator Access – Full control
• Read Only – View-only access

You can create custom profiles and assign them to users or AD groups.

Notification Profiles

Each user can define notification rules for themselves or receive alerts via assigned Notification Groups.

Personal Notification Profiles

• Each user may define multiple channels: Email, SMS (via GSM), Web Push, or integrations
• Profiles can include time filters (weekdays, time ranges)
• Message templates can be customized per channel

Notification Groups

Use groups to assign notifications by role or function (e.g., “On-call Tier 1” or “Network Engineers”). Users inherit group notifications and can override or disable them.

Password Reset and User Maintenance

Password resets and security actions are managed in the User & Access Rights Manager.

• Admins can reset passwords or force password change on next login
• Locked accounts can be unlocked
• Expired credentials can be updated manually or via AD sync

Summary

NetCrunch provides a flexible, secure user model:

• Multiple consoles, shared or personal access
• Role-based delegation using access profiles
• Full support for Active Directory
• Notification routing via profiles and groups
• Organizational scoping for multi-team environments

Whether you're managing a single admin or dozens of operational users, NetCrunch ensures each user has the right view, the right tools, and the right alerts—nothing more, nothing less.

Managing NetCrunch Access Profiles

Access Profiles in NetCrunch define what users can see and do in the system. They form the foundation of role-based access control and allow scalable, high-performance delegation of privileges to individuals and groups. This topic explains how to design and apply Access Profiles to achieve the right balance between security and usability.

access controlaccess profileaccess scopeactive directory integrationatlas accessnetcrunch permissionsnode accessrole-based accessserver rightsuser permissionsuser rightsview access

Overview

Access Profiles in NetCrunch represent reusable, role-based permission sets that define access to:

• Program features (like dashboards, settings, server operations)
• Atlas views (containers, dashboards, maps)
• Specific nodes and their functions

Unlike many systems that tie permissions directly to users (and slow down as the number of users increases), NetCrunch applies permissions through shared profiles. This makes access evaluation extremely fast, even in large environments, and simplifies administration.

Each user—whether local or AD-authenticated—can have one access profile, either assigned directly or inherited through group membership.

Two Strategies for Assigning Access

NetCrunch supports two core strategies for designing access:

Deny by Default (Recommended)

This is the default model:

• Start with no access to anything
• Explicitly add access only to required views, nodes, or features

This approach is safer, easier to audit, and minimizes accidental overexposure.

Allow by Default

In this model:

• Grant access to all views and nodes initially
• Selectively deny access to sensitive or restricted elements

This approach can be useful in smaller environments or for quick setup, but it's less secure by nature.

Both strategies can be implemented in the same UI by adjusting the Atlas Defaults and View/Node Overrides in the profile editor.

Role-Based Model

Access Profiles should be treated as roles, not per-user settings.

• You create roles like "NOC Operator", "Tier 2 Support", or "Server Admin"
• Assign those profiles to multiple users or AD groups
• This ensures consistency and centralizes permission changes

Changing access rights in one profile instantly affects all assigned users, avoiding duplication and misalignment.

Profile Assignment

• For local users: assign the Access Profile directly in their account settings
• For Active Directory users: assign the profile to an AD group
  • When the user logs in, NetCrunch checks group membership
  • If multiple groups match, the first matched profile (based on order) is applied
  • If the user loses group membership, access is revoked

There is no limit to the number of access profiles you can define.

Access Rights Structure

NetCrunch uses a hierarchical, path-based access model. Each object or operation can be granted:

• Deny – Block access to the item or function
• Access – Allow viewing, reading, or executing
• Manage – Allow configuration or editing

Access rules are evaluated from longest path to shortest. This means more specific rules override broader defaults.

Examples:

• Node → basic access to the node
• Node > Events → access specifically to the node’s event view
• Atlas View > Nodes → access to all nodes within a view, but not necessarily to the view itself

Access Scope

Access profiles can define rights in three scopes:

Program

Controls access to core system features:

• Server settings
• Monitoring tools
• Logs and system info
• Desktop Console access (via "Server Administration" right)

Atlas Defaults

Set default rights for all nodes or views unless overridden.

• Useful for “Allow by default” strategy
• Can grant view access without node access (or vice versa)

Views & Nodes

Here you define specific overrides—either granting or denying access at the element or feature level.

• Override default behavior from the Atlas Defaults
• Restrict access to sensitive views or critical nodes
• Allow visibility to a view but hide specific nodes in it

This distinction is key: having access to a view doesn't mean the user can see every node inside it.

Administration Console vs Web Console

Currently, the Desktop Console requires the Server Administration access right to run. It is not restricted by view or node-level permissions. However, NetCrunch now supports delegated use of the Desktop Console—you can assign limited admin rights via access profiles, allowing trusted users to configure selected nodes or views.

The Web Console, on the other hand, fully honors access profiles for all Atlas objects and supports granular restriction. While it currently lacks some administrative features, they are planned for future versions.

Summary

Access Profiles in NetCrunch are lightweight, scalable, and built for performance. Designed around roles, not individuals, they allow fast permission evaluation even in large user environments. Whether you're using a deny-first model for strict control or an allow-all model with exceptions, NetCrunch keeps access control simple, auditable, and efficient—with no artificial limits on how many profiles you define.

Managing Calculated Performance Counters

See how you can create calculated counters from existing ones.

Settings Resources Calculated Performance Counters

We created Calculated Counters to create counters calculated from source counter data upon a given arithmetic expression. For example, we may require a counter representing a percentage of free memory, but a particular Cisco device delivers only raw memory values.

Calculated counters Extend counters from the given Monitoring Engine by arithmetic calculations.

After defining them, you can access them like any other counters from the given Monitoring Engine. For existing calculated counters, the counter expression can be edited. You can also add new calculated counters.

Creating New Calculated Counter

pgcPage1

Click Add Calculated Counter and select Target Monitoring Engine

Select from the list the monitor to which the calculated counter will be added.

pgcPage2

Set Counter Name

Each counter is defined by its Object, Name, and Instance. Since instances are specific to each object's performance counter, you should specify the object for the counter first.

Calculated Counters can inherit instances from source counters only if they extend the existing source object.

For example:

Performance Object Name

Cisco Memory

Performance Counter Name

% Memory Used

pgcPage3

Edit Counter Expression

To create a counter, add the desired counters and use an arithmetic operation to create an expression. When you add a new counter to the expression, the program automatically creates a variable name and puts it into the expression.

Example:

 100 * (ciscoMemoryPoolUsed / (ciscoMemoryPoolUsed + ciscoMemoryPoolFree))

calculated counterscountersperformancevirtual counters

Devices with Multiple Network Interfaces

Monitor multi-interface devices with granular control and flexible grouping options

In NetCrunch, each IP Node represents a single network interface, not the whole device. This design enables granular monitoring, as each interface may run different services and require distinct monitoring profiles.

To simplify the view and reduce data collection on less critical interfaces, NetCrunch allows you to group multiple interfaces under one primary node:

• Primary Interface: Fully monitored with performance data collected
• Secondary Interfaces: Placed into Simplified Monitoring, checking only the up/down status without storing performance metrics

Grouping Interfaces

There are several ways to combine multiple interfaces into a single logical device:

• Select multiple nodes and use Represent nodes as one device
• Open the Primary Interface properties and add Secondary Interfaces
• Open a Secondary Interface and select its corresponding Primary Interface

This approach keeps monitoring efficient and organized, especially for servers or infrastructure devices with multiple NICs.

device-groupinginterfacesmonitoringnetworking

Time Restriction Scheme

Custom scheduling options for monitoring, alerts, and notification, allowing for precise control over various program activities.

The program uses time restrictions to define time conditions for various elements, such as node monitoring, alerting conditions, or notification schemes.

In recent versions, the time restriction scheme has been extended to allow different schemes to be set for each weekday. You can select a single time range by including or excluding a specific time range, providing greater flexibility in scheduling.

Time Restriction Scheme is used for:

Actions

You can set when an action can be executed.

Event Condition

For some conditions such as: event not happened in the time between.

Notification

In the user profile, each notification type can have different time range settings. For example, you can receive some notification types on weekdays and others on weekends.

Atlas Monitoring

Here, you can set a global monitoring scheme for Atlas.

Node Monitoring Scheme

Each node can have its monitoring time scheme.

Node State Alert

You can set an alert if the node is not in the right state at the given time (for example, in instances when it should be DOWN at night).

Action Restrictions

Tailored action restrictions for complex and situational action execution in response to alerts, such as time-specific activities, location-based notifications, and critical condition responses.

Each action can have its restrictions.

This makes action lists more flexible as you can limit the execution of the action to:

• Alert Severity
• Time Range (see Time Restriction Scheme)
• Node Importance (execute notification for critical nodes)
• Node Group
• Organization

This allows for defining complex conditions and action lists.

Usage Examples

Run different actions for different times of day or weekday

Define two actions and set different times of the day or different weekdays.

Run actions based on node location

You may want to notify different groups of administrators depending on the node location. NetCrunch creates Atlas views for locations. Also, you can create custom views based on custom fields (be it additional information like department or some organizational unit name) and assign each view to each action.

Restart the server if the alert is critical after some time. Weekend nights only.

You might assign a restart action to a specific alert, but you might also decide to restart servers after a certain amount of time if the issue remains unresolved. This needs limiting action only to nodes being members of the Servers view. As each action has time after it executes since the alert started, you can decide to run restart after some time. Additionally, you might want to repeat these steps only on weekend nights.

Managing Event Log Views

Automatic and customizable event log views with a visual query builder for efficient filtering, enabling tailored analyses without a need for time-consuming text searches.

Automatic Views

Several views are created automatically and can be selected from the drop-down menu. These views are generated for Monitoring Packs and Sensors, providing quick access to relevant information.

Creating Custom Views

NetCrunch can store millions of events in a history event log. These events are fully searchable, but searching them in the text form would be very slow.
To make it easy, we added a visual query builder, which allows you to create filtering conditions for the database. Once you define your view, you can store it and select it later.

You can create views using many event fields. You can also search for event parameters.

Filtering Event Parameters

We recommend creating a bracket condition and adding parameter names and their values as desired.

Time Range

The view definition doesn't contain the time range, which is selected for each view separately.

Managing Multiple Node Settings

Read how to change node settings, such as monitoring time and device type for multiple nodes, and how to manage the alerting and reporting settings differently.

You can always select multiple nodes, but if you want to manage nodes as a group, consider creating a separate Atlas view for the group.

Creating a new Atlas View by selecting multiple nodes and dragging them into the Custom Views section is effortless.

Changing Node Settings

NetCrunch allows you to manage multiple node settings easily. Select multiple nodes in a table or on the graphical icon view, and then select Node Settings from the context menu.

You can use existing Atlas views to narrow your selection.

For instance, if you want to select all Windows servers, you can view Atlas TreeCustom ViewsServer TypesWindows Server and press Ctrl+A to select all nodes in the view. Then, you can select Node Settings from the context menu or press Shift-F2.

Managing Alerts & Reports

We strongly encourage you to create Monitoring Packs with the same settings for multiple nodes. Then, you can select multiple nodes and add your new Monitoring Pack to them.

On every single node, you can override settings assigned by Monitoring Packs. For instance, you can change actions (add some) or even disable some alerts.

When you select multiple nodes, however, you can only add or remove Monitoring Packs.

managingnodes

Configuring Notification Services

Read to configure emails and text messages (SMS) with NetCrunch notifications.
You can receive notifications about alerts and reports as emails or text messages (SMS). First, you need to set up the configuration parameters.
Go to the Options page and click `Notification' option.

Configuring external email server

You can use the built-in NetCrunch mechanism or you can define a list of external SMTP mail servers. The system also supports the TLS encryption protocol, if needed.

Configuring GSM modem or phone

For alert notifications via text messages (SMS), you need to select the COM port used to communicate with the mobile phone, SMS settings and options related to the GSM device such as the PIN of the SIM card.
You may also need to enter AT+C commands if they require additional configuration.

You can even use a standard cable attachment, which after installation will be visible in the system as one of the computer's COM ports.

COM Port

Shows the COM port selected for communication with the mobile phone. Clicking the Browse button opens the GSM Device Discovery dialog window, where you should choose/configure the appropriate COM port and test if NetCrunch can connect to the device. If there are any connection problems, check the modem documentation to see what speed is required to work properly.

SMS Settings

Limit to Single Message

Messages longer than 160 chars will be split into several messages. You will receive them as a single piece, but you will pay for the number of messages at your operator's rates.

Encoding

The Auto option is enabled by default here. Change it if you receive text messages with encoding issues.

Modem Settings

PIN

You can set the PIN number of the SIM card related to your GSM device.

Initialization AT+C Commands

Select this check box if the modem requires additional initialization AT+C commands.

deviceemailgsmmodemnotificationoptionssmssmtp

Managing Node Custom Data

You can easily extend the NetCrunch node database by adding custom fields to each node. This allows for creating views and controlling alerting action execution.

NetCrunch allows you to add custom fields to node properties. There are several predefined fields. Some fields (like Info1 and Info2) are there for compatibility with old versions. Fields can be used to organize data.

You can add these fields: number, text, date, time, or picklist.

Additionally, Text type can be converted to a picklist anytime and vice-versa.

Custom node fields can create dynamic views (defined by filtering conditions). Atlas View membership also controls alerts and action execution. See Action Restrictions

Configuration Tips

Read what configuration problems you should fix to make sure everything works fine.

NetCrunch does many things automatically, but it needs your input in some places. For instance, it's necessary to provide proper credentials to access operating systems and valid SNMP profiles.

Resolve the Monitoring Issues

Monitoring Issues are problems related to the monitoring process. They require your attention. In most cases, they are related to invalid or missing credentials.

Fix Missing Device Types

NetCrunch uses Device Types to implement automatic monitoring. For example, if a device is not set to be a Windows type, Windows monitoring will not start or even be accessible for the node.

Open a network map and look for icons with a question mark, which indicates that they are missing a device type. NetCrunch automatically detects device vendors, which can help set the device type.

Only Windows (and other systems if added to Active Directory) and SNMP devices should have their device type set automatically. You must manually set their device type for other devices (those displayed as the "unknown device type").

Review the Settings page

Please check the Settings page to see what is enabled or disabled in your monitoring configuration.
For example, you can enable monitoring of the Physical Segments or NetFlow here.

Adding Custom Root Certificates to NetCrunch

NetCrunch uses node.js for secure SSL/TLS & HTTPS connection. Some of the certificate authorities might be not included. You can add additional root certificates to the external\Root Certificates folder in the NetCrunch Server data directory.

The certificate must be in PEM format.

certificateconfigurationissuesroottips

Node Monitoring Templates

Use templates for streamlined setup, allowing creation from existing nodes or scratch, customizable section inclusions, and easy application to IP nodes, with interactive sensor configurations requiring reference nodes for detailed settings.

[+] Monitoring Template

You can create a template from scratch or choose the existing node as a source for the template. Additionally, you can assign the template to the prototype node.

The template can contain all sections or sections that can be excluded, so when the template is applied to the node, it won't override these parts.

Except for sensors, you can set up all node monitoring settings similarly, like on the real monitored node. When setting a sensor, you need to select a reference node. Many sensor configurators are interactive and need to pull some data from the actual node. For example, the WMI sensor may need to read WMI classes; the SQL sensor needs a list of databases.

Using Templates

You can use templates for IP nodes monitored by NetCrunch Server. Monitoring probe nodes are not supported. Using templates is even easier than creating them.

1. Select the template for the node.
2. Template sections will cover your node settings. You can see the settings applied underneath.
3. You can override the settings of a particular section by clicking on the pencil icon at the top right corner.

monitoringtemplates

Core Monitoring

Everything about monitoring configuration. Read how you can monitor various aspects of the network hardware and software.

Monitoring Concepts

Review basic concepts like Monitoring Engines, Node State Monitoring, and how to disable monitoring.

The main purpose of NetCrunch is to monitor your network. It also offers you documenting and organizing services.

So, everything in NetCrunch is well organized - the Atlas root is at the top, the views go below, then there are nodes, and finally, on the lowest level, there are various objects and their performance metrics and status objects.

Monitoring Engines

Monitoring Engines simplifies the monitoring configuration, as they are responsible for a certain monitoring channel.

For example, you might define many things being monitored using the SNMP Engine. Still, all of them share the same configuration parameters for a particular node such as SNMP port and profile to be used. A very similar situation happens with other operating systems where the configuration contains credentials for the connection.

NetCrunch Monitoring Engines

• SNMP - requires SNMP to be configured on node
• Windows - Windows monitor must be enabled
• Linux - Linux monitor must be enabled
• macOS - macOS monitor must be enabled
• BSD - BSD monitor must be enabled
• Solaris - Solaris monitor must be enabled
• Inventory - requires Windows OS monitor to be enabled
• VMware ESX/i & vCenter - monitoring of vCenter, ESXi and virtual machines
• Network Services (MPMON) - multi-protocol monitor
• Flow Analyzer
• Sensor Engine - provide various scalable sensor monitors

Monitoring Sensors

The list of sensors is constantly growing.

See full list in Sensors

Node State Monitoring

The central part of monitoring is determining the node state. Everything being monitored on the node depends on its state.

When the node is considered to be DOWN, the node's monitoring almost stops until NetCrunch recognizes that the node is responding again.

NetCrunch determines the node state upon monitoring of network services (see: Network Services Monitoring).

Read more about Monitoring of Network Nodes

Managing Monitoring Engines

When you go to Node SettingsMonitoring, you will get the list of monitors available (bound) to the node. There you can manage engine properties for the node.

Monitoring by Device Type

Some monitoring packs use Device Type information (especially SNMP devices) to be enabled for a specific device only. In the case of the SNMP monitoring, the program automatically detects Device Type upon SNMP object data.

Read more in Automatic Monitoring and Organizing

Monitoring Issues

We decided to make issues related to the monitoring process to stand out from other problems related to your network services and devices. They are usually related to wrong or missing credentials or Windows security settings.

See also: Configuration Tips

Disabling Monitoring

As the monitoring is enabled by default, it's more interesting to know how you can disable it. You can disable it at any level.

Disabling the Atlas

Atlas Properties

You can disable monitoring for the entire Atlas. You can disable it for some time (for maintenance) or schedule being disabled for a future time range.

Disabling the Network

IP NetworkProperties

You can go to IP Networks and disable monitoring of a specific Network indefinitely, or just for a given time period.

Automatically by Dependencies

NetCrunch manages monitoring dependencies that should reflect connection dependencies. If properly set, NetCrunch automatically disables the monitoring of nodes depending on a certain connection. This helps to lower monitoring traffic and also prevents false alerts.

Read more in Preventing False Alarms

Understanding NetCrunch Data Formats

NetCrunch supports multiple structured data formats for monitoring input, sensor results, and external integrations. This topic explains the native data formats, internal data storage mechanisms, and how to send data into the system using these formats.

Overview

NetCrunch processes both input and output data using well-defined formats to ensure interoperability, performance, and clarity. You can send structured data using file-based sensors, telemetry nodes, or API endpoints. Internally, NetCrunch uses purpose-built databases to store event logs, trends, status states, and atlas definitions.

Native Input Formats

These formats are supported by file-based and script-based sensors, including Data File Sensor, Script Sensor, and Telemetry Node.

NetCrunch JSON

The most flexible and recommended format. It allows sending multiple counters and complex status objects with metadata.

{
  "cpu.usage": 47.5,
  "disk.free": {
    "value": 13000,
    "message": "13 GB free",
    "critical": true,
    "class": "critical",
    "retain": true
  }
}

NetCrunch XML

Same schema as JSON, but expressed in XML. Useful in legacy systems.

<values>
  <cpu.usage>47.5</cpu.usage>
  <disk.free class="critical" message="13 GB free">13000</disk.free>
</values>

NetCrunch CSV

Lightweight format for numeric counters. Uses key-value pairs.

cpu.usage,47.5
disk.free,13000

Custom Formats via Parsers

If your data is not in a native format, you can define a custom parser.

Supported parsing methods:

• CSV parsing
• Key-value pair extraction
• Regular expressions
• XPath (for XML)
• JSONPath (for JSON)
• JavaScript expressions

Internal Data Storage

NetCrunch uses purpose-built internal databases to separate concerns and improve performance:

Use Cases & Format Mapping

Summary

NetCrunch supports multiple structured formats and interprets them intelligently to update counters, trigger alerts, and display statuses. For best results, use JSON and include full metadata such as status class and messages.

csvcustom parsersdata formatsintegrationjsonnetcrunch storagestatus dbtelemetrytrend dbxml

Monitoring of Network Nodes

Read about node state evaluation and node monitoring settings.

As the node represents a single network endpoint (not the device), a primary monitoring subject, everything else in monitoring depends on the node state.

Node State

NetCrunch defines the following node states:

OK

Everything is fine - the node and its services are responding.

Warning

There is some problem with a service or the Monitoring Engine on the node. Monitoring Issues also turn node into a Warning state.

DOWN

Node is not responding - in this state, only one service is monitored to bring the node back to the normal monitoring state.

Unknown

Node state can't be determined - for example, the node has no IP address or has not been monitored yet.

Disabled

Node monitoring is disabled for some reason. There are many reasons why the node is disabled, such as: by Atlas, by Time Restrictions, by the User, or by Dependency.

Simplified Monitoring

The program determines only a node and a service state by checking network services availability (PING) without tracking performance metrics.

Extended Service Monitoring

In some cases, the status of the node can be determined in the second interval.

Read more about Network Services Monitoring

Monitoring Dependencies

The monitoring of each node can depend on its parent node (network switch or router). This causes an automatic disabling of node monitoring in case the parent link or device is DOWN.

Read more in Preventing False Alarms

Prioritization and Event Suppression

In large networks with remote intermediate routers, NetCrunch organizes monitoring by priorities. By default, the nodes being closer to NetCrunch Server and intermediate routers are monitored before others.

Monitoring Time Mask

When a node is active in certain hours or days, you might limit monitoring to a given time range and weekdays.

Network Services Monitoring

Availability and performance monitoring of 70 network services such as FTP, HTTP, SMTP, etc.

The monitoring of network services is the basic monitoring type in NetCrunch. A node state is determined basically by the availability of network services. When a node is in the DOWN state, it's only monitored by a single network service.

Availability and Response Time

Services monitoring checks basically:

• Connectivity
• Response received
• Response Time and Failure Rate

NetCrunch sends a request, appropriate for a given service protocol, and then checks if the response matches the defined response. The process should be at least repeated 3 times to measure response time, and then the average response time is calculated. For each request, you can set an appropriate time to wait for a response.

Each monitored service provides the following performance metrics:

• Round Trip Time - total time to send and receive a single response or a connection time for extended services
• Check Time - total checking time (including sending multiple requests in extended mode)
• % Failure Rate - calculated per each service checking
• % Packets Lost - calculated per each service checking

Leading Service

Monitoring in seconds interval

For some critical nodes, you might want to react in seconds instead of minutes. Then you can check for leading service monitoring Monitor in seconds interval.

The option will let the leading service be monitored more often than once per minute whenever a node is DOWN or alive. As an option, you can set NetCrunch to determine the node state solely upon the state of the leading service; otherwise, it can check other services immediately after the leading service fails.

Customizing Existing Services

NetCrunch allows the monitoring of network services by their respective default ports. When you need to monitor a service on different ports, go to SettingsResourcesNetwork Services and choose New Service. Then you will be able to duplicate the service with the new name and different port. For example, define HTTP_8080 for checking HTTP on port 8080.

Simple TCP checking service

In some cases, all you need is a simple TCP port connection checking without sending any further data. In order to create simple TCP port checking go to Settings Resources Network Services, click New Service and select a desired option.

Defining Custom Services

As a third option, you might decide to create a full request/response checking service definition. In order to create such definition, go to Settings Resources Network Services click New Service and select Create from Scratch option.

1. Set Protocol Type (TCP, UDP, or TLS/SSL) and Port Number.
2. Define the Request to be sent (after connection if TCP is used) - you can enter either text or binary data in the hexadecimal format.
3. Define response patterns. You can set multiple patterns and decide how they should be checked. Patterns can be text, hexadecimal binary data, or regular expression. Pattern matching options are:
   • any of the added patterns match
   • all of the added patterns match
   • none of the added patterns match

Automatic Discovery of Network Services

As the node status depends on the services, each time a new node is added to the atlas, NetCrunch automatically discovers services running on the node. By default, NetCrunch is configured to check only a subset of all defined services.

You can manage the list of services being automatically discovered in Settings Monitoring Auto Discovered Services

Troubleshooting

To get some monitoring services to work properly, an additional configuration task should be performed.

DHCP Server Checking Restrictions

• NetCrunch must be able to open the 68 UDP (DHCP client) port to receive a response to the DHCP inform request. The monitoring will not be working if NetCrunch is running on a machine where the DHCP Server has been installed, as it uses the same port.

• The IP address of the NetCrunch machine must be included in any checked DHCP Server Scope (WINDOWS DHCP Server tested). For example, if the machine where NetCrunch is running has the address 192.168.1.100, and the DHCP Server is on 192.168.88.10, then the server must have the scope with any range from 192.168.1.x addresses. A Linux-based DHCP Server must have the authoritative option enabled.

Monitoring MSSQL Express

To monitor MSSQL Express, the TCP/IP protocol must be enabled, and the server instance must accept a remote connection on TCP port 1433. Please refer to the MSSQL Express documentation for information about enabling the TCP/IP and allowing the remote connection to the server instance.

SSH Service

NetCrunch allows monitoring of SSH service using a protocol ver. 1 and/or ver.2. By default, the SSHv2 protocol is monitored on the network nodes. Use SSHv1 service in the case when the node supports the older version of SSH.

ftphttpmonitoringnetworkservices

Network Traffic Monitoring

NetCrunch supports many flow protocols as application monitoring using Cisco NBAR.

NetCrunch supports two technologies that allow network traffic monitoring. The first gathers information from switches about the traffic on particular ports, and the second can collect flow data from routers and switches.

Monitoring Traffic on Switch Ports

Switches collect statistics about traffic on their ports, which are available in Physical Connections views. These views can give an overview of traffic between two switches or between the switch and servers.

You can see aggregated traffic information in the last hour or the last 24 hours. When you select a link on the map, you can open the Connection Status details and the traffic history.

Monitoring Traffic with NetFlow

Introduction

There are many flow-export formats on the market today. Netflow is a Cisco trademark (aka cflow), but similar protocols include jFlow, rFlow, NetStream, AppFlow, and sFlow.

For the NetFlow suite of protocols, we often see version 5 (supported by most devices), some combined v5/v7 (the Catalysts), and some version 9 of the newer devices.

Supported Flow Technologies

NetCrunch supports the following flow protocols:

• NetFlow v1, v5, v8, v9, and IPFix,
• NetStream
• CFlow
• AppFlow
• rFlow

NetCrunch collects and analyzes received flows for aggregation in the 15-minute and 1-hour ranges. This allows you to analyze data in a short period and store long-term performance trends.

Currently, NetCrunch supports single flow aggregation to receive data from multiple flow sources. However, they are aggregated together on a single dashboard.

Performance

Currently, Netcrunch flows can receive up to:

~ 3000 packets/sec

~ 35000 flows/sec (average 12 flows per packet)

sFlow Disclaimer

NetCrunch is capable of receiving sFlow, but the protocol's statistical nature requires different processing and data aggregation over a much longer period.

NetFlow Views

NetFlow Dashboard

Overview Flows

NetCrunch shows global flow traffic statistics on the top Atlas Dashboard. When you click on any chart bar, you can see traffic details for a selected element.

The view shows the current aggregated statistics from all flow sources sending data to NetCrunch.

Flow Analytics

NetCrunch allows you to analyze traffic using various criteria. The program allows you to create custom application definitions and supports Cisco NBAR technology for application monitoring.

The program also allows the creation of custom application definitions based on protocol and ports.

Node Traffic

flowmonitoringnetnetflowswitchtraffic

Monitoring SNMP Devices

NetCrunch provides complete SNMP monitoring, including support for v3, traps, and MIB compiler.

SNMP was developed on UNIX back in 1988 - so it's a pretty mature technology now. Despite various new protocols, it's probably the most widely implemented management protocol today. SNMP is defined in RFC (Request For Comments) by IETF (Internet Engineering Task Force) and is used everywhere: servers, workstations, routers, firewalls, switches, hubs, printers, IP phones, appliances...

SNMP Versions

Today, most devices support SNMPv2c. There are available agents for operating systems, but they can be a security loophole if they don't use SNMPv3. On the other hand, network virtualization helps separate traffic so that VLANs can separate older SNMP devices.

Top hardware devices usually support SNMP v3, which adds more security to the protocol (authentication and encryption). NetCrunch supports all SNMP versions: SNMP v1, SNMP v2c, and SNMPv3, including decoding traps. NetCrunch SNMP implementation supports SNMPv3 following encryption algorithms: DES, 3DES, AES 128, AES 192 and AES 256.

Please note that SNMPv3 is more expensive in processing power (because of encryption) on both sides - the device and SNMP manager application.

To avoid device overload, we recommend limit pending SNMP requests in SNMP Settings ( icon in SNMP section) on any nodes that use SNMP.

SNMP Profiles

NetCrunch uses SNMP profiles to manage communities and passwords for SNMP. The profiles allow you to use the same SNMP security settings for multiple nodes. SNMP Profiles encapsulate settings necessary to communicate with the particular SNMP Agent.

Profiles define the SNMP protocol version and information related to protocol version and security settings: the community string (SNMPv2); or authentication user, password, and encryption to be used (SNMPv3).

Additionally, the profile allows specifying different protocols for reading and writing operations. For example, you can set up reading operations to use SNMPv2 and disable writing.

To receive and decode SNMPv3 traps, you need to define a separate SNMPv3 Traps & Trap Info profile.

Because SNMPv2 is much more efficient (it allows asking for multiple values at once), we recommend using SNMPv2 for monitoring.

Monitoring SNMP Variables

To access SNMP data on a particular node, you must make it SNMP enabled by Node SettingsMonitoringSNMP. To create an alert on the SNMP counter value, you need to set up a Performance Trigger alert.

Setting Alerts on Numerical Values

Select the node, open Node SettingsMonitoring, and you'll see the SNMP section grayed out. Please enable it. NetCrunch will use the default profile. Set the proper profile in SNMP monitor settings.

Now you can click on the Custom monitoring pack, add New Event for SNMP Performance Counter, choose one of Event Triggers for Counters, and select the SNMP variable as the counter.

We have the following options for SNMP counters:

Enter OID

This option allows you to enter an arbitrary OID number - you might obtain it just from the device using a simple MIB walker tool. Using OID allows accessing SNMP data even if you do not have the MIB for the device.

Select from MIB

To select an SNMP variable, you can browse SNMP MIB data. This method requires first importing and compiling MIB data into the NetCrunch MIB database. NetCrunch includes a database of 8700 popular MIBs. There are also websites maintaining their own set of MIBs. You can download them and use the NetCrunch MIB compiler to extend your MIB database.

Predefined Counter

This option is about choosing from predefined SNMP counters - these are some standard counters used. You can extend this list for later use to avoid tedious MIB tree browsing.

Setting Alerts on Text Values

Besides numerical values, you can also monitor text values returned by the SNMP agent. To do this, you have to select <New Event for SNMP Variable Value> and enter OID or select the object from the MIB database. Then you can check the following conditions:

• Value equals to given value
• Value not equals to given value
• Value contains given value
• Value does not contains given value
• Value matches regular expression
• Value does not match regular expression
• Value changed
• Value unchanged

Creating of Monitoring Pack for SNMP

Settings Alerting & Notifications Monitoring Packs and Policies

Select SNMP only from the restrictions drop-down menu when creating a new monitoring pack.

SNMP Views

SNMP only describes the variables and get/set operations, so browsing the OID MIB tree is somewhat tricky. SNMP tables often refer to other tables and raw data is not readable.

NetCrunch SNMP Views allow for creating tables and forms that are more human-readable, allowing reading and entering SNMP data.

Additionally, views are automatically managed according to device type and supported MIB.

Receiving SNMP Traps

Check if the SNMP trap listener is enabled. Settings Monitoring SNMP Trap Receiver

Node SettingsMonitoring or Settings Alerting & Notifications Monitoring Packs and Policies

NetCrunch allows receiving SNMPv1 traps, SNMPv2c, and SNMPv3, including encryption. To turn a trap into an alert, you must define an alert on the node sending the SNMP trap message.

NetCrunch receives all traps and puts them in the External Events window. You can add the necessary node and trap with one click in this window, even if the node didn't exist in the atlas before.

To receive SNMPv3 traps, you need to define SNMPv3 Traps & Trap Info first. Otherwise, the program won't be able to decode trap data.

The profile also contains the field for 'Remote SNMP Engine Id,` which you have to set according to the SNMPv3 trap specification ([see RFC2570](http://www.ietf.org/rfc/rfc2570.txt)).

Read more in Receiving SNMPv3 Notifications

Forwarding SNMP Traps

Settings Monitoring SNMP Trap Receiver

After receiving an SNMP trap, NetCrunch can forward it "as is" to another SNMP manager.

MIB Compiler

NetCrunch MIB compiler allows you to extend the NetCrunch MIB database used to select SNMP traps and variables during configuration and resolve OID to names for incoming SNMP data (traps).

It's an advanced multi-pass compiler that can set up module name aliases to compile otherwise incompatible modules.

mib compilersnmpsnmp trapsnmp viewstrap

Custom SNMP Views

Manage custom SNMP Views for specific device types to make displaying and setting SNMP data much more accessible.

There are two types of views. The form view can contain separate SNMP variables like sysLocation or sysUpTime, and the grid view can represent an SNMP table, e.g., ifTable.

Form View

The Form view is used to display a set of SNMP variables.

name: Example
type: form
fields:
  - caption: Description
    var:
      type: oid
      ref: 1.3.6.1.2.1.1.1.0
  - caption: Location
    var:
      type: oid
      ref: 1.3.6.1.2.1.1.6.0
    writable: true

Editable Field

Add writable: true attribute to make a field editable. To edit SNMP values, you need to have a read-write profile defined on the node.

Auto-refresh Field

NetCrunch can read the variable periodically every given number of seconds. Add autoRefresh: 15 attribute to refresh the value every 15 seconds.

Concatenated Field

You can use the concatenated field to display two SNMP values in one field.

fields:
  - caption: Machine
    var:
      type: concat
      refs:
        - type: oid
          ref: 1.3.6.1.2.1.1.5.0 
        - type: oid
          ref: 1.3.6.1.2.1.1.6.0 
      concat: $1 in $2

The standard format for a concat attribute is $1 $1, but you can add some text between the variables.

Calculated Field

You can calculate the field value from two SNMP variables.

fields:
  - caption: Total ICMP packets
    var:
      type: expr
      refs:
        - type: oid
          ref: 1.3.6.1.2.1.5.1.0
        - type: oid
          ref: 1.3.6.1.2.1.5.14.0
      expression: "+"

Possible expressions:

• + sum
• - subtraction
• * multiplication
• / division
• % percent calculation

Table View

The Table view is used to display a set of SNMP columns. All specified columns must belong to the same SNMP table. You can join a column from another SNMP table, but the indexing of the rows in both tables must be consistent, or you have to specify the lookup reference.

name: Example Table
type: grid
columns:
  - caption: Description
    var:
      type: oid
      ref: 1.3.6.1.2.1.2.2.1.2
    display:
      width: 20
      sort: asc
      summary: count
  - caption: In Octets
    var:
      type: oid
      ref: 1.3.6.1.2.1.2.2.1.10
      dataType: int
    display:
      width: 20
      summary: sum
    autoRefresh: 15
  - caption: Out Octets
    var:
      type: oid
      ref: 1.3.6.1.2.1.2.2.1.16
      dataType: int
    display:
      width: 20
      summary: sum
    autoRefresh: 15
    format:
      type: convert
      format:
        from: B
  - caption: ifType
    var:
      type: oid
      ref: 1.3.6.1.2.1.2.2.1.3

To group data by a column, add groupBy column caption attribute:

groupBy: ifType

Column Display Properties

Optionally you can set default column properties

display:
  width: 20
  sort: asc
  summary: count

• width - default column width
• sort - default sorting (asc or desc)
• summary - displays column summary footer. Possible values: count, sum, min, max

Editable column

Add the writable: true attribute to make a column cell field editable. A read-write profile must be defined on the node to edit SNMP values.

Auto-refresh Column

NetCrunch can refresh column data periodically every given number of seconds. Add autoRefresh: 15 attribute to refresh all column rows every 15 seconds.

Concatenated Column

Use the concatenated column to display row values from two SNMP columns in one column.

columns:
- caption: Machine
  var:
    type: concat
    refs:
      - type: oid
        ref: 1.3.6.1.2.1.1.5.0
      - type: oid
        ref: 1.3.6.1.2.1.1.6.0
    concat: $1 in $2

The standard format for the concat attribute is $1 $1, but you can add some text between the variables.

Calculated Column

You can create a column in which each row contains a value calculated from the corresponding rows of two other columns.

columns:
  - caption: In + Out
    var:
      type: expr
      refs:
        - type: oid
          ref: 1.3.6.1.2.1.2.2.1.10
        - type: oid
          ref: 1.3.6.1.2.1.2.2.1.16
      expression: "+"

Possible expressions: - + sum - - subtraction - * multiplication - / division - % percent calculation

Lookup Column

In SNMP, the values in a given column often refer to data from another table.

For example, the ipNetToMediaIfIndex(1.3.6.1.2.1.4.22.1.1) column of the ipNetToMediaTable(1.3.6.1.2.1.4) table contains the ifIndex of the interface on which this entry is effective. We need to display the name of the interface taken from ifDescr(1.3.6.1.2.1.2.2.1.2). To do this, we need to define the lookup reference:

- caption: Interface name
  var:
    type: lookup
    ref: 1.3.6.1.2.1.4.22.1.1
    lookup: 1.3.6.1.2.1.2.2.1.2

Joining Tables

You display columns from different SNMP tables if the indexing of the rows in both tables is consistent (that is, the second table is an extension of the first table).

Examples are the tables ifTable(1.3.6.1.2.1.2.2.1.2) and ifXTable(1.3.6.1.2.1.31.1.1).

In the example below, two columns will be displayed: ifDescr(1.3.6.1.2.1.2.2.1.2) from ifTable, and ifName(1.3.6.1.2.1.31.1.1.1.1) from ifXTable.

name: Join Example
type: grid
columns:
  - caption: ifDescr
    var:
      type: oid
      ref: 1.3.6.1.2.1.2.2.1.2
  - caption: ifName
    var:
      type: lookup
      ref: index
      lookup: 1.3.6.1.2.1.31.1.1.1.1

Data Format

You can add a unit symbol to the value:

format:
  type: str
  format: $1 Unit

Scaling

You can multiply the value if necessary:

var:
  type: oid
  ref: 1.3.6.1.2.1.2.2.1.16
  dataType: int
  scale: 0.001
  precision: 2
dataType: int

You can limit the number of decimal places by adding the precision attribute.

Conversions

You can set up unit conversion automatically. For example, if the value is in bytes:

format:
  type: convert
  format:
    units: Digital
    from: B

The displayed value will automatically be changed to KB, MB, etc.

Possible input units: - bytes (B, KB, MB, GB) - bits (b, Kb, Mb, Gb)

SNMP Time

Converting SNMP TimeTicks (hundredths of a second) to human readable time format:

- caption: Uptime
  var:
  type: oid
  ref: 1.3.6.1.2.1.1.3.0
    dataType: time10msec
    format:
      type: time
      format: elapsed

snmp views

Cisco IP SLA operations

NetCrunch supports Cisco IP SLA technology.

Sensors

IP SLA Single Operation

Node SettingsMonitoringAdd IP SLA OperationIP SLA Single Operation

This sensor allows monitoring of the status of IP SLA operations on the Cisco devices. Select the operation previously defined on a Cisco device when you add the sensor. Operations are grouped by protocol type.

Program can alert on the following conditions:

• Operation cannot be completed successfully
• Operation is not active or does not exist on the router

Additionally, you can set performance triggers (thresholds) on the following metrics:

• % Availability
• Completion Status - status code of the operation.
• RTT - Operation completion time (ms).

IP SLA Multi-Operation

Node SettingsMonitoringAdd IP SLA OperationIP SLA Multi-Operation

The sensor can monitor all operations of a given type, or it can select operations by their parameters:

• Operation id (specify list or range)
• Target IP address
• Admin tag
• Operation group

Unlike a Single IP SLA Operation sensor, the operation configuration cannot be modified.

Default Metrics

• % Availability
• Operation RTT

Sensor alerts

• Any of the monitored operations have an invalid state.

Status

In the node status window, NetCrunch shows the status of all IP SLA operations defined on the Cisco device.

ciscoipslasnmp

Essential Sensors

DNS Query, System Uptime, RADIUS, SSL Certificate & SSH Remote Ping.

dns-query

DNS Query Sensor

Node SettingMonitoringAdd Monitoring SensorDNS Query DNS service is the most vital part of every infrastructure. NetCrunch allows checking for DNS query results and detects unwanted changes.

DNS sensor allows you to check if the DNS responses are valid. This helps identify problems in DNS or to check whether records have been altered.

This sensor allows you to send a query for a name or an address to a given DNS server (you should add it to the DNS server node). You can enter a name to check (a domain name), and you can define alerts to check if DNS records match expected results. Predefined sensor alerts include

• Query execution error
• Request timeout
• No DNS records in response.

Also, you can set an alert on Response time and Check time. You can query IPv4 and IPv6 addresses.

You can match a value of the following record types:

• Location Record (LOC)
• Mail Exchange Record (MX)
• Name Server Record (NS)
• Resolve Canonical Name (CNAME)
• Resolve IPv4 Address (A)
• Resolve IPv6 Address (AAAA)
• Resolve Name (PTR)
• Service Locator (SRV)
• Start of Authority (SOA)
• Text Record (TXT)

Each record can be tested for conformance with a given pattern.

system-uptime

System Uptime Sensor

Node SettingMonitoringAdd Monitoring Sensor System Uptime Sensor supports WMI, SSH/Bash and SNMP.

The sensor monitors device uptime measured in seconds.

Predefined sensor alerts:

• Authentication error
• Connection Error
• Device has been restarted

Also, you can set an alert on Response Time and Check Time.

radius

RADIUS Sensor

The sensor checks the user authentication process and validates the response from the RADIUS server. If you need checking service responsiveness only, then you can use Network Services and RADIUS service from the list. See Network Services Monitoring.

Predefined sensor alerts:

• Request error
• Request timeout

Sensor measures:

• RADIUS.Sensor/Check Time
• RADIUS.Response/Time

The sensor allows setting alert on response conformance equals or doesn't equal given value.

ssl-certificate

SSL Certificate Sensor

The sensor can check any SSL/TLS connection (SSH and any other protocol working on TLS). It checks the SSL certificate expiration date and the certificate properties. The sensor allows the checking of all certificate fields.

Predefined sensor alerts:

• Connection Error
• Certificate Expired
• Certificate is about to expire
• Certificate changed
• Certificate has been revoked
• Weak public key
• Certificate authority invalid

The sensor shows warning status if the certificate is not authorized or the public key is too short. You can set an alert on the certificate field conformance and status object change for the certificate or public key.

Besides, you can set an alert on such metrics as Response Time, Check Time and a number of Days Until Certificate Expires.

ssh-remote-ping

SSH Remote Ping

The sensor checks connectivity from a remote system by running Ping remotely by the SSH server.

It allows setting threshold on the following counters:

• % Availability
• Response Time
• Check Time

Predefined sensor alerts:

• Connection Error
• Authentication Error
• Ping timeout

You can also add an alert when the Ping Response object status changed.

certificatednsradiusremote pingsecuritysshssluptime

Composite Status

Although the above statement is perfectly valid and exactly describes how the Composite Status, it doesn't answer why and when you might need it.

Because the names of object states are different, we need to clarify them.

• error is a synonym for Down or Critical.
• success is a synonym for OK.

Let's start with an example.

As the user, I want to see the internal system's status, which depends on two internet connections, DNS, AD, and the web server. Internet connections are redundant, but all other elements are critical to the system.

You might decide to create a Business Status Node and add each element to the appropriate group in such a case. As the node can be part of another Business Status, you can even build up a tree of statuses.

Besides placing such status on the dashboard map and alerting, you can document logical dependencies of process elements.

The overall status of the Composite Status is calculated upon element groups and is the highest status of each group. The order of statuses: Unknown OK Warning Error.

Critical

The group state is the highest state of any element in the group. For example, if any element is in the Warning state, the group state is Warning.

Redundant

If any element is in the Warning or Error state, then the composite status object is in the Warning state. If all elements are in the Error state, the composite status is Error.

Influential

If any element is in the Errorstate, then the resulting state is Warning. Even if all elements are in the Error state, the whole group state will be at the most Warning.

businessbusiness statuscomposite

Data File Sensor

The sensor allows getting data from various sources and processes them to get metrics and status values.

FTP/S, HTTP/S, SSH/Bash, SFTP, Windows/SMB, TFTP

The sensor loads data from a file or URL using one of the predefined file formats (including custom formats). It can alert on retrieved metrics and status values.

Available alerts:

• Alert on Monitoring Sensor counter
• File does not exist
• File exists
• File modified
• File is empty
• File is not empty
• File access error
• Authentication error
• Connection error
• File has not been updated within a given time range (file age)
• File updated too often (file age)
• File read error

Supported File Formats

Native Data Formats

NetCrunch can receive counters and status objects at once. It supports JSON and XML formats that allow passing both counters and statuses, and additionally, it supports a rather simplistic CSV format for counter metrics.

<NetCrunch JSON>

This is a very straightforward format. Each counter must be a numeric value. Status objects can be represented by simple string values or by complex objects, including custom data. This data can be displayed later in the widgets and status window.

{
  "counters": {
     "crm/emails-in-1h": 10.2,
     "crm/emails-out-1h": 231
  },
  "statuses":  {
       "AC"  : "On",
       "Power": "On"
  }
}

Complex status objects may look like this:

{
  "statuses" :  { 
      "Disk C:" : {
                    "value" : "ok",
                    "message" : "Working fine",
                    "critical": true,
                    "data" : { 
                        "type" : "SDD", 
                        "upTimeSec" : 123431  
                     }
     }      
  }
}

The status object can contain fields such as:

• Value - a status value that can be any string. When one of the standard values is used, NetCrunch will use the value for calculation in alert conditions. The field is required to recognize the status object; otherwise, the whole object will be treated as a text string. Standard values are: ok, error, warning, disabled, unknown.

• Name - the name of the object; it does not have to be unique. (optional)

• Message - this can be a message describing the state (for example, error message). (optional)
• Received - a time when the status has been read. (optional)
• Retain - how long status will be valid if no new status is received. If no new data is received, status turns to unknown.
• Class - status class. If specified, the status history will be saved to the database. The class helps UI understand data associated with the status and display it appropriately.
• Data - custom data. It can be any JSON object, except if the class points to one of the well-known classes, it must conform to the class data format.

<NetCrunch XML>

 <nc>
    <counters>
       <counter path="xobj/cnt.1">123</counter>
       <counter path="xobj/cnt.2">245</counter>
    </counters>
    <statuses>
       <status name="AC" message="Everything fine">OK</status>
       <status name="Fan">
            <value>OK</value>
            <message>OK</message>                
            <critical>true</critical>
            <data>
                <type>High speed</type>
            </data>
       </status>
    </statuses>
 </nc>

<NetCrunch CSV >

This is a simple format to pass a list of counters and their values.

object,counter,instance,value

Additionally, you can pass only two values where the first one will be treated as a counter path and the second one as its value.

counterpath, value

Example

      Fan Speed,123
      SensorB,Temperature,Room,22
      SensorC,Temperature,Outside,15 
      SensorD/Temperature.Rack 1,26   

As you can see, you can mix formats inside a single document.

Custom Data Formats

You can make NetCrunch understand any format using Data Parsers, allowing parsing and analyzing external data. The result is always a list of counters and status objects.

See Data Parsers

customdataparser

Monitoring Printers

NetCrunch delivers sophisticated printer monitoring capabilities by utilizing SNMP protocols, facilitating detailed tracking and management of printer performance.

Printer Sensor

The Printer Sensor in NetCrunch goes beyond simple supply-level monitoring. It tracks various printer statuses and can alert you to alarms and performance issues, ensuring a comprehensive oversight of printer health. It's most effective with printers that support Printer MIB v2, a standard that offers in-depth insights into printer status and performance metrics.

Alerts

NetCrunch's Printer Sensor offers detailed and specific monitoring through several alert types:

• Alert on Performance Counter Metric: Notifies you if specific printer performance metrics exceed predetermined thresholds.
• Alert on a Status Object: Keeps you informed about changes in key printer statuses, such as operational readiness or maintenance requirements.
• Printer Alert: General alerts for a range of detected printer issues, from paper jams to connectivity problems.
• Authentication Error: Informs you of any authentication issues, ensuring secure and authorized printer access.
• Request Timeout: Alerts you if the printer fails to respond within a set time frame, indicating potential communication or hardware issues.

Counters

The Printer Sensor also tracks the following metrics:

• Printed Page Count: This feature tracks the number of pages the printer prints. You can set a Limit Threshold to receive an alert when the number of pages printed exceeds the threshold value within a specified period (e.g., day, week, etc.).
• Colorant Containers\% Fill Level: The percentage of ink or toner remaining in each colorant container.
• Supplies\% Remaining: The overall percentage of remaining printer supplies, like ink or toner.
• Receptacles\% Remaining: The remaining capacity percentage in waste receptacles, like toner collection units.

Default Alerts

NetCrunch includes pre-configured alerts for common issues, enabling immediate responses:

• Alert on Authentication Error
• Alert on Request Timeout
• Cover is Open
• Low Container Filling Level
• Printer Critical Alert
• Receptacle is Full
• Colorant Container Nearly Empty
• Limited Space in Receptacle

IPMI Monitoring

Intelligent Platform Management Interface (IPMI) is a set of computer interface specifications for an autonomous computer subsystem that provides management and monitoring capabilities independently of the host system's CPU, firmware (BIOS or UEFI) and operating system.

IPMI supports two types of authentications: one-key and two-key authentication. One-key authentication requires the user password. The encryption key consists of only 0's (default). Two-key authentication requires both the user password and non zero encryption key. NetCrunch sensors support both types of authentication. The encryption key can be set in the credential profile window.

basic-ipmi

Basic IPMI Sensor

IPMI v2.0/RMCP+

This sensor can monitor various hardware parameters such as system temperature, fan speed, power supply voltages, etc. The availability of these parameters depends on the hardware monitored and the IPMI configuration of the monitored device.

Common parameters:

• voltage
• fan rpm
• temperature

Available parameters for the particular device will be displayed when selecting the counters when setting up the threshold. Some counter descriptions may include thresholds values.

Credentials:

Enter your username and password for the IPMI.

Counters:

• Value [units] or % Value

Default Report

contains the following metrics:

• Basic IPMI.Fan\Value [RPM]
• Basic IPMI.Fan\% Value
• Basic IPMI.Temperature\Value [degrees C]
• Basic IPMI.Voltage\Value [Volts]

Default Alerts:

• Request Timeout
• Authentication Error

generic-ipmi

Generic IPMI Sensor

IPMI v2.0/RMCP+

This IPMI sensor can monitor all possible parameters received from the monitored device. A filter allows specifying the exact parameters to be monitored. Parameters can be filtered based on their type, entity (i.e., location), and name.

Common numeric parameters:

• voltage
• current
• fan rpm
• temperature
• altitude

The sensor also reads non-numeric parameters containing status messages.

Credentials

Enter your username and password for the IPMI.

Alerts

• Request Timeout Error
• Authentication Error
• Event on status Object Change
• Event for Monitoring Sensor Counter

ibm-imm-ipmi

IBM IMM IPMI

This IPMI sensor is configured to monitor all essential metrics from an IBM IMM device.

Monitored parameters:

• Temperature
• Power Supply
• Power Unit
• Fan
• Current
• Voltage

Default Report

contains the following metrics:

• IMM IPMI.Fan\Value [RPM]
• IMM IPMI.Temperature\Value [degrees C]
• IMM IPMI.Voltage\Value [Volts]

Alerts:

• Request Timeout Error
• Authentication Error
• Fan status has changed
• Temperature status has changed
• Power Supply status has changed
• Power Unit status has changed

hp-ilo-ipmi

HP iLO IPMI

This IPMI sensor is configured to monitor all essential metrics from an HP iLO device.

Monitored parameters:

• Temperature
• Power Supply
• Power Unit
• Fan
• Current

Default Report

contains the following metrics:

• iLO IPMI.Fan\% Value
• iLO IPMI.Temperature\Value [degrees C]
• iLO IPMI.Current\Value [Watts]

Alerts:

• Request Timeout Error
• Authentication Error
• Fan status has changed
• Temperature status has changed
• Power Supply status has changed
• Power Unit status has changed

dell-idrac-ipmi

Dell iDRAC IPMI

The sensor is configured to monitor all essential metrics from a Dell iDRAC device.

Monitored parameters:

• Fan
• Temperature
• Voltage
• Memory
• Physical Security
• Drive Slot
• Critical Interrupt
• Power Supply

Default Report

contains the following metrics:

• iDRAC IPMI.Fan\Value [RPM]
• iDRAC IPMI.Temperature\Value [degrees C]
• iDRAC IPMI.Voltage\Value [Volts]

Alerts:

• Request Timeout Error
• Authentication Error
• Fan status has changed
• Temperature status has changed
• Power Supply status has changed
• Voltage status has changed

ipmi-log

IPMI Log Sensor

The IPMI Log sensor can retrieve logs from the System Event Log (SEL), a non-volatile repository for system events, and certain system configuration information. Alerts can be set on new log entries that match user-defined expressions. Logs can be filtered based on their IPMI sensor type, event message, and event transition direction(event_dir).

Example:

A log entry with the following fields:

• IPMI sensor type: "processor",
• message: "processor presence",
• transition direction: "Assertion Event"

This indicates that the event was generated because a processor has become present (inserted). The same log entry but with the transition direction field set to "Deassertion Event" would indicate that the event was generated because the processor had become not present (removed).

Credentials

Enter your username and password specified for the Intelligent Platform Management Interface.

Alerts:

• Request Timeout Error
• Authentication Error
• Alert on text log entry

Performance Metrics

• Sensor.Check Time

basic ipmidelldell idracgeneric ipmihpibmidraciloimmipmiipmi loglogsensor

Dell EMC Sensor

The Dell EMC Sensor is designed to monitor the health status and power consumption of a Dell EMC storage device. This is achieved using the Unisphere Management REST API. With this sensor, users can monitor vital information related to file systems, Logical Unit Numbers (LUNs), and storage pools present within the Dell EMC system.

Options:

1. Connection Profile: This allows you to specify details about how to connect to the Dell EMC system.

2. Authentication Profile: Define the authentication credentials required to access the Unisphere Management REST API.

Alerts:

• Connection Error: Triggered if there's an issue connecting to the Dell EMC system.
• Authentication Error: Raised if there's an authentication problem when trying to access the system.
• Filesystem space is almost full: Alerts the user when the storage space in the file system is nearing its limit.
• Pool space is almost full: Notifies the user when the storage space in a pool is close to being full.
• System Health Status Alert: Generated if there's any change in the overall health status of the Dell EMC storage device.

Default Reports:

Filesystem Report:

• Dell EMC.Filesystem\Used Size [bytes]: Represents the amount of storage space currently being used in the file system.

LUN Report:

• Dell EMC.LUN\Snap Size [bytes]: Indicates the snapshot size of a LUN.

Pool Report:

• Dell EMC.Pool\Free Size [bytes]: Shows the amount of storage space available in a pool.
• Dell EMC.Pool\Used Size [bytes]: Displays the amount of storage space that's already been utilized in a pool.
• Dell EMC.Pool\Snap Size Used [bytes]: Represents the amount of snapshot storage space used in a pool.

System Report:

• Dell EMC.System\Current Power [watts]: Displays the current power consumption of the Dell EMC storage device.

dellemc

Text Parsing Expressions

The parsing expression task lists named values (key-value pairs) for the given text. These fields allow later message filtering and can be treated as counters or status objects. Each expression requires declaring the list of variables that will be returned by the expression.

Comma Separated Values

This is probably the simplest format to parse. Variable names describe each column, and the default separator is the comma.

Key-Value Pairs

This format is useful when data are encoded as a series of key-value pairs separated by one additional separator. For example:

from:John;val:10

In this case, Pair Separator would be ; and Value Separator :

Another example can be ini encoding:

speed = 10
acceleration = 0

In this case, Pair Separator would be \n and Value Separator =

Regular Expression

Regular expressions are powerful and very useful in pattern matching. NetCrunch uses a Javascript implementation of regular expressions and matches variables by the order of matching groups.

Example - Log4J log format

We created a regexp pattern for a popular Log4J format.

(\d{4}-\d{2}-\d{2}) (\d{2}:\d{2}:\d{2},\d{3}) \[(.*?)\] ([^ ]*) +([^ ]*) - (.*)$          

We assigned to the following variables (fields):

• Date
• Time
• Thread
• Severity
• Module
• Message

Apache Common Log Format

This allows decoding Apache logs using the Common Log Format. All you need to do is provide the format used to configure the given log.

Refer to Apache documentation for more.

XPath/DOM Selectors

NetCrunch supports XML paths for retrieving data from XML. Only paths returning single values are supported.

Example

 <doc>
    <amount>10.2</amount>
    <user name="John" id="123"/>
 </doc>

We can extract all variables using the following paths:

• /doc/amount
• //user/@name
• //user/@id

Conditional Selectors

You can select the element's attribute by selecting the node element using another attribute. In our example, we could get the user's name by selecting the element by its id.

  //doc/user[@id='123']/@name

DOM Selectors

The XPath expression also supports DOM selectors (aka CSS selectors), which you can use to select node values. However, if you need an attribute value, you cannot specify it using a standard CSS selector. Therefore, we extended the syntax by adding the '|' pipe character, after which you can add the attribute name.

So, the following path will produce the same result as the XPaths above.

• doc > amount
• user|name
• user|id

JSON Path

NetCrunch supports JSON Path paths for retrieving data from JSON data. Only paths returning single values are supported.

Example

    {
       "doc"  :  {
        "amount": 22,
        "user" :  {
            "name" : "John",
            "id" : 100
         }
      }
   }

We can extract all variables using the following paths:

• $.doc.amount
• $..user.name
• $..user.id

Javascript

Javascript looks like the ultimate solution for cracking data. You can use regular expressions and the Javascript engine (V8) to implement the latest language standard.
Your script executes in strict mode in a separate and sandboxed NodeJS engine and is killed if it exceeds the time limit.

The Input

Script input is in the text variable.

The Output

As a result of the script, NetCrunch expects the result variable to be an object with properties matching declared variables (fields).

Example

Let's imagine that we are receiving an email containing JSON. It will be quite simple to use Javascript to extract the data we need.

Test Text

{
   "probe_1" : {
       "temp" : 10 
    }
} 

Variables

• Temperature

The Script

// Parse input data from the text variable
const data = JSON.parse(text);

// set result or return result object
result = {
      temperature: data.probe_1.temp 
}

Python

The parser allows you to write custom scripts in Python language (v. 3.7.0) to crack text data. In addition to regular runtime (you can't load any external modules), we provided the most desirable utilities for parsing JSON and XML data formats. (JSON, ElementTree)

The Input

Script input is in the text variable.

The Output

As the script's result, NetCrunch expects the result variable to be a Python dictionary object with properties matching declared variables (fields).

Example

Test Text

{
   "probe_1" : {
       "temp" : 10 
    }
} 

Variables

• Temperature

The Script

# Parse data from input
data = json.loads(text)

# set result properties
result['temperature'] = data['probe_1']['temp']

domemailexpressionjsonpathlogparsingpythonselectortexttext logxpath

Data Parsers

Data Parsers transform and analyze external data, returning NetCrunch counter metrics and status objects.

Data parsers allow the transformation of external data into NetCrunch JSON format, describing counters and status objects. Several sensors can use Data Parser to retrieve these data from external sources.

XPath/DOM Data Parser

You can define a list of counters, status objects, and their respective paths. You can use either XPath or CSS selectors, depending on your preference. While CSS selectors are typically used to select DOM nodes, we have extended the syntax to include attribute names by adding a '|' pipe character after the selector.

Example

    <doc>
        <amount>10.2</amount>
        <user name="John" age="123"/>
    </doc>

Selectors

• To get Amount you can use XPath selector //doc/amount or DOM selector doc > amount
• To get specifically John age you can select it by //doc/user[@name='John']/@age or by extended DOM selector doc > user[name='John'] | age.

JSONPath

JSONPath is similar to XPath in that it has similar capabilities. For simple paths, you can use simple dotted paths.

Example

{
  "main" : {
      "temperature" : 10.2,
      "humidity" : 66
  }
}    

This is a simple example but very similar to the actual data provided by one of the public weather APIs.

• Temperature can be selected by simple main.temperature
• For Humidity we can use JSONPath $..humidity

Data Parser Script (JavaScript)

JavaScript is a good solution for parsing data, as you can use regular expressions and the whole power of the JavaScript engine (V8), which implements the latest ECMAScript language standard.

Your script executes in strict mode in a separate and sandboxed NodeJS engine and is killed if it exceeds the time limit. In addition to regular runtime (you can't load any external modules), we provided the most desirable utilities for parsing JSON, XML, and HTML data formats.

Test Console

Data Parser editor is a small development environment that allows you to test a script by running it in an actual NetCrunch scripting engine. You can provide test data and use console objects to log messages to the test console.

Script Parameters and The Result

Your script receives two parameters:

• data - it contains input data. It can be text as a buffer object. It depends on the data type you expect from the source.
• result - script result object that simplifies providing a list of counters and status objects.

Counters

The counter metric represents numerical values observed by NetCrunch. This is one of the fundamental building blocks of NetCrunch. The counter path describes:

• Object - if left blank, the sensor identification will be used as the object. It describes the measured subject. The programming term describes the class of the measured subject. For example, Process, Disk.
• Counter - The name of the metric. For example, Temperature, % Utilization%.
• Instance—identifies the object's instance. It's optional, so it can be a disk ID, process name, etc.

Counter Path Format

<Object>/<Counter>.<Instance>

Examples

Process/% Processor Utilization.NCServer.exe
WebSite/Current Visitors

Status Objects

The Status Object describes the state of the monitored object. It can be simply a string or more complex data. Unlike for counters, there are no special requirements for the status object name.

Well-known status values:

• unknown
• ok
• warning
• error

Complex Status Object

           "Disk C:" : {
                         "value" : "ok",
                         "message" : "Working fine",
                         "retain" : 5,
                         "critical": true,
                         "data" : { 
                            "type" : "SDD", 
                            "upTimeSec" : 123431  
                          }
            }      

The status object can contain fields such as:

• Value - a status value that can be any string, but if one of the standard values is used, NetCrunch will use the value for calculation alert conditions. The field is required to recognize the status object. Otherwise, the whole object will be treated as a text string. Standard values are: ok, error, warning, disabled, unknown.

• Name - a name for the object, it does not have to be unique. (optional)

• Message - this can be a message describing the state (for example, an error message). (optional)
• Received - a time when the status has been read. (optional)
• Retain - how long will the status be valid if no new status is received after it becomes unknown?
• Class - status class. If specified status history will be saved to the database. The class helps UI understand data associated with the status and display it appropriately.
• Data - custom data. It can be any JSON object, except if class points to one of the well-known classes, it must conform to the class data format.

Providing Result

All result functions can be chained.

result.counter('Value', 10).counter('Value 2', 20);

result.counter(path,value)

Add counter value to the sensor result.

 result.counter('% Utilization', 23.5);

result.counter(obj)

You can add multiple counters as a single object.

 result.counter( {
    "Temperature" : 33,
    "Humidity" : 65
 });

result.status(name,value[,message])

Set the status of the object:

  result.status('Door 1', 'closed' ).status('Door 2', 'opened');

result.status(obj)

Set complex status object.

 result.status('Light 1', { 
   value : 'ok',
   data : {
     color: 'red'
     switchedOn : "2021-03-11T22:20:59.903Z"
  }

result.error(message)

You can set the '@parser' status object, which will change the sensor status as its status is marked as critical. This way, if data are not what you expect, you can pass the error to the sensor.

   result.error('Missing section')

result.warning(message)

Use it to change the sensor status set to 'warning'.

Examples

We assume you are familiar with ES6. You can use the older syntax as JavaScript is backward compatible.

Simple

It uses one of the simplest formats for data encoding. It's just a series of values without names, separated by a comma.

Test Data

  10.2, 30, 100

Script

       data.split(',').forEach((value,ix) => result.counter(`Value ${ix}`,  value));

Parsing XML/HTML data

As natively, JavaScript does not offer an XML parser, so we added one. You can use XPath and CSS selectors to select elements or attributes.

Simple XML document

NetCrunch includes a DOM parser. You can use it at a low level (please refer to xmldom.js on the Internet) by using the DOMParser constructor or by using a convenient DOM class we provided.

DOM

doc.nodes(xpath)

returns all elements matching the given XPath.

Example

  <doc>
      <value name="Temp">10.2</value>
      <value name="Fan Speed">100.2</value>          
   </doc>   

Script

   const doc = new DOM(data);
   doc
       .nodes('//value')       
       .map(e => ([e.getAttribute('name'), e.firstChild.data ])
       .forEach(([name,value]) => result.counter(name, value));

The script above will return all values with proper names as counters.

doc.selectByXPath(path)

returns values of elements matching the path.

doc.valueByXPath(path)

returns a single (first) value regardless of the number of matching elements.

valueByCSS(path)

converts the CSS selector into XPath and calls valueByXPath to retrieve a single value. To select an attribute value, add the attribute name after the pipe |. For example:

 val[name='Temperature'] | value

Allows you to select the value from the following element:

 <val name="Temperature" value="23.5"></val>

cssToXPath(selector)

This function converts a CSS selector to an XPath. To select an attribute value, you can append the attribute name after the pipe separator.

For example:

  val[device='Fan'] | rpm

Data

<doc>
   <value1>13.10</value1>
   <value2>345</value2>
</doc> 

Script

 const doc = new DOM(data);
 result
    .counter('Values/Value 1',  doc.valueByXPath('//value1'))
    .counter('Values/Value 2',  doc.valueByXPath('//value2'));

CSS Selectors

You can also use familiar CSS selectors using doc.selectByCSS

   doc.selectByCSS('value1') 

Parsing JSON Data

JavaScript has a built-in parser for JSON data and converts its native JavaScript objects.
Your script can use two methods to access the attributes of objects.

selectProperty(obj,path)

Select a property by a dotted path.

selectByJSONPath(obj,path)

Select the property element by JSONPath.

Example

Let's try to parse data in a way that is similar to weather API services.

Data

{
  "main" : {
      "Temperature" : 22,
      "Humidity" : 66
  }
}

Script

   const doc = JSON.parse(data);
   result
       .counter('Temperature', selectProperty(doc, 'main.Temperature'))
       .counter('Humidity',   selectByJSONPath(doc, '$..Humidity'));

Data Parsers (Python)

The parser allows you to write custom scripts in Python language (v. 3.7.0) to parse data from your sensors. In addition to regular runtime (you can't load any external modules), we provided the most desirable utilities for parsing JSON and XML data formats. (JSON, ElementTree)

Test Console

Data Parser editor is a small development environment that allows you to test a script by running it in an actual NetCrunch scripting engine. You can provide test data and use console objects to log messages to the test console.

Script Parameters and The Result

Your script receives two parameters:

• data - it contains input data. It can be text as a buffer object. It depends on the data type you expect from the source.

• result - script result object that simplifies providing a list of counters and status objects.

Counters

The counter metric represents numerical values observed by NetCrunch. This is one of the fundamental building blocks of NetCrunch. The counter path describes:

• Object - if left blank, the sensor identification will be used as the object. It describes the measured subject. The programming term describes the class of the measured subject—for example, Process, Disk.

• Counter - The name of the metric. For example, Temperature, % Utilization%.

• Instance - identifies an instance of the object. It's optional. So it can be disk id, process name, etc.

Counter Path Format

<Object>/<Counter>.<Instance>

Examples

Process/% Processor Utilization.NCServer.exe

WebSite/Current Visitors

Status Objects

The status object describes the state of the monitored object. It can be simply a string, or it can be more complex data. Unlike for counters, there are no special requirements for the status object name.

Well known status values:

• unknown
• ok
• warning
• error

Complex Status Object

"Disk C:" : {
               "value" : "ok",
                "message" : "Working fine",
                "retain" : 5,
                "critical": True,
                "data" : { 
                    "type" : "SDD", 
                    "upTimeSec" : 123431

                  }
    }

The status object can contain fields such as:

• Value - a status value that can be any string, but if one of the standard values used, NetCrunch will be able to use the value for calculation alert conditions. The field is required to recognize the status object; otherwise, the whole object will be treated as a text string. Standard values are: ok, error, warning, disabled, unknown.

• Name - a name for the object; it does not have to be unique. (optional)

• Message - this can be a message describing the state (for example, error message). (optional)

• Received - a time when the status has been read. (optional)

• Retain - how long status will be valid if no new status is received. After this time, the status becomes unknown.

• Class - status class. If specified status history will be saved to the database. The class helps UI understand data associated with the status and display it appropriately.

• Data - custom data. It can be any Dictionary object, except if the class points to one of the well-known classes, it must conform to the class data format.

Providing Result

All result functions can be chained.

result.counter(path,value)

result.counter('Value', 10).counter('Value 2', 20)

Add counter value to sensor result.

result.counter(obj)

result.counter('% Utilization', 23.5)

You can add multiple counters as a single object.

result.counter( {
    "Temperature" : 33,
    "Humidity" : 65
 })

Simply set the status of the object

result.status(obj)

result.status(name,value[,message])

result.status('Door 1', 'closed' ).status('Door 2', 'opened')

Set complex status object

result.status('Light 1', { 
   "value" : 'ok',
   "data" : {
     "color": 'red'
     "switchedOn" : "2021-03-11T22:20:59.903Z"
  }

You can set the '@parser' status object, which will change the sensor status as its status is marked as critical. This way, if data are not what you expect, you can pass the error to the sensor

result.error(message)

result.error('Missing section')

Examples

Test Data

10, 15, 4.5

Script

for id, val in enumerate(data.split(', ')):
  result.counter('Value ' + str(id), float(val))

Exceptions

Scripts that are using 'import', 'exec', 'eval', 'compile' are not allowed.

Sensors Using Data Parsers

Data File Sensor

This sensor can retrieve data from various sources such as:

• Windows File
• HTTP/S (file or page)
• FTP/S
• SSH (SFTP or Bash)

Read more...

Scripting Sensors

You can run scripts on NetCrunch Server machine or remotely using the shell on a target machine using SSH.
Read more...

Data Sensor

The Data Sensor sensor allows receiving data from an external source (agent). Data can be sent as JSON (native NetCrunch format) and in any other format that can be transformed using NetCrunch Data Parser.
Read more...

REST HTTP

It can send an HTTP request, including custom requests with URL query parameters. It also allows setting custom headers and cookies for the request. In combination with Data Parser, it can get any data from an external source.
Read more...

datadomhtmljavascriptjsonpathparserparsingpythonxmlxpath

ICMP Jitter Sensor

The sensor sends a series of ICMP packets and calculates Jitter based on RTT.

Jitter is a typical problem of the connectionless networks or packet-switched networks. Each packet can be transmitted by a different path and arrive at different times from the emitter to the receiver.

Jitter means interpacket delay variance. When multiple packets are sent consecutively from a source to a destination, for example, 100ms apart, and if the network is behaving ideally, the destination should receive the packets 100ms apart. But if there are delays in the network (like queuing, arriving through alternate routes, and so on), the arrival delay between packets might be greater than or less than 100ms.

If the difference is positive, it is counted in positive jitter. A negative value is counted in negative jitter.

Counters:

• Average Time
• Maximum Time
• Minimum Time
• Jitter
• Negative Jitter
• Positive Jitter
• % Packet Loss
• Packet Count

Alerts:

• Request Timeout
• Connection degradation
• Jitter is high
• Jitter is very high

References

• RFC 1889, A.8 Estimating the Interarrival Jitter
• CISCO IPSLA ICMP Jitter

icmpicmp-jitter

Traceroute Sensor

The sensor can alert when the number of hops to the destination has changed

The sensor executes traceroute to host using ICMP Echo requests.

Parameters:

• Timeout (ms) - timeout for each hop
• Maximum hop count

Counters:

• Hop Count

Alerts:

• Number of hops has changed
• Trace is incomplete

traceroute

Monitoring of Network Interfaces

NetCrunch provides detailed monitoring of network interfaces for SNMP-enabled devices, combining flexible policy-based selection, full duplex-aware metrics, real-time delta calculations for errors and discards, VLAN and MAC mapping, CDP/LLDP-based topology view, and a best-in-class interface visualization and alerting system.

NetCrunch monitors network interfaces using a policy-driven approach that enables precise, automatic selection of interfaces to monitor. Monitoring is based on SNMP, allowing support for a wide range of network devices including switches, routers, firewalls, servers, and other equipment.

Each monitored interface provides detailed traffic, status, error, and topology-aware data, supporting advanced visualization and alerting capabilities.

Interface Monitoring Overview

When SNMP monitoring is enabled on a device, NetCrunch automatically adds an Interface Sensor to the node. This sensor uses a Monitoring Policy to determine which interfaces are included. Not all interfaces are monitored — typically, only those matching the configured policy (such as active, Ethernet, or IP interfaces) are selected.

Monitoring includes:

• Bandwidth usage tracking
• Admin and operational status
• Errors and discards (delta-based)
• VLAN and MAC address mapping
• Interface grouping and visualization
• Duplex-aware utilization tracking
• CDP/LLDP-based physical segment discovery

Configuring Interface Monitoring

Monitoring Policies

Interface selection is driven by Monitoring Policies. Policies use filter expressions to automatically include or exclude interfaces based on criteria like type, status, or description.

Common built-in policies:

• All – Includes all SNMP-reported interfaces.
• All active (default) – Includes interfaces that are up and active.
• Ethernet only – Selects only Ethernet interfaces.
• IP only – Selects only interfaces with an assigned IP address.
• Custom filter – Create a custom expression based on any available interface properties.

Policies can be selected during node configuration at
Node SettingsMonitoringInterfacesEdit Sensor Settings.

64-bit Counters

NetCrunch prefers 64-bit counters when available (device must support SNMPv2c or SNMPv3). 64-bit counters prevent overflow issues on high-speed links (such as 1 Gbps, 10 Gbps, or faster).

When 64-bit counters are unavailable, NetCrunch falls back to 32-bit counters but provides warnings if overflow risk is detected.

Interface Identification Templates

Correctly identifying interfaces across device reboots is crucial. SNMP indexes (interface IDs) can change, but names like ifAlias or ifDescr usually remain stable.

You can customize the identification template using tokens:

• $ifAlias
• $ifDescr
• $ifName
• $ifIndex

Example template:
$ifAlias|$ifDescr|$ifName

This instructs NetCrunch to use ifAlias first, then ifDescr, then ifName as fallback.

Template configuration is available at
Node SettingsMonitoringInterfacesIdentification Settings.

Monitored Metrics and Counters

NetCrunch monitors a wide range of interface metrics. Deltas are calculated automatically to provide rate-per-second values.

Speed Override

In real-world scenarios, the interface speed reported by SNMP might not match the actual usable link speed because:

• Hardware limits and software configuration differ
• Internet Service Providers assign logical speeds (e.g., 500 Mbps over 1 Gbps port)
• Virtual interfaces report generic speeds
• Speed autonegotiation issues or interface misreporting

To ensure accurate bandwidth utilization calculations, NetCrunch allows manual overriding of interface speed.

Configuration path:
SettingsMonitoringInterface Monitoring Settings

You can manually set:

• Correct link speed (e.g., 100 Mbps, 1 Gbps, 10 Gbps)
• Correct unit (bps, Kbps, Mbps, Gbps)

Errors and Discards Tracking

NetCrunch tracks delta values for errors and discards:

• Delta counters measure changes between polling intervals, not accumulated totals.
• Users can reset counters at any time to start a fresh observation period.
• This helps isolate intermittent issues such as cable faults, duplex mismatches, or congestion.

VLAN & Connected Device Insights

NetCrunch displays VLAN membership and connected devices directly within the interface view.

• Each interface shows VLAN assignments
• Side panel displays connected MAC addresses and IP mappings
• Hovering or clicking on a VLAN column reveals full VLAN names and tags
• Connected nodes are automatically linked if known in the Atlas

All this data is visible without external tools or config parsing.

Physical Segment Visualization

NetCrunch uses CDP and LLDP protocols to map physical Layer 2 links, including:

• Aggregated (trunk) links
• Port-channel interfaces
• Bandwidth load on each segment
• Topology views with click-through to live traffic stats

Interface links are drawn as network segments, and clicking them reveals:

• Interface description
• Traffic chart (Live, 24h, 7d, 30d)
• Input/output byte counts
• Errors and discards

Interface Grouping and Views

Interfaces can be grouped for better navigation and analysis.

Grouping Options:

• By Switch
• By VLAN
• By Switch and VLAN
• Ungrouped View

Alerts for Network Interfaces

NetCrunch includes alerting options for:

• Interface state (UP/DOWN)
• Bandwidth utilization (%)
• Errors and discards (by count or percentage)
• Any other metric threshold

Threshold types include:

• Value, Range, Deviation, Delta, Limit, and others

Alerts are policy-driven and can be reused across multiple nodes and groups.

Licensing and Interface Monitoring

• Monitored interfaces consume license units
• Default: monitors only active interfaces
• Use filters to avoid monitoring:
  • Loopback interfaces
  • Tunnels or virtual devices
  • Disabled ports

What Makes NetCrunch Unique

• Policy-based interface selection with reusable filters
• Interface names identified via customizable templates
• Bandwidth metrics include both Full- and Half-Duplex modes
• Errors and discards are tracked as deltas, not just totals
• VLANs and MAC addresses are fully visible
• CDP/LLDP is used to draw Layer 2 topology
• Users can override reported interface speed to ensure accurate utilization
• Live views, graphs, and clickable topology map are built-in — no separate tools required

NetCrunch doesn’t just read interface counters — it understands network topology and presents actionable, integrated insights.

Telemetry in NetCrunch

Telemetry enables systems to push metrics and logs into NetCrunch without polling. This topic explains when to use telemetry and how NetCrunch supports it via Telemetry Nodes and the OTLP cloud gateway.

What Is Telemetry?

Telemetry is the process of automatically collecting measurements from remote systems and sending them to a central monitoring platform. Unlike traditional polling (e.g., SNMP, WMI), telemetry:

• Is pushed from the source instead of pulled by the server
• Supports real-time streaming of data
• Is ideal for cloud-native, distributed, or event-driven systems

When to Use Telemetry

Telemetry is the right choice when:

• You have systems without direct network visibility (e.g., behind NAT or firewall)
• You want faster alerting or metric freshness
• You’re collecting data from serverless apps, containers, or CI/CD pipelines
• You want to integrate with OpenTelemetry agents, SDKs, or exporters

How NetCrunch Supports Telemetry

NetCrunch implements telemetry collection using two key mechanisms:

1. Telemetry Node

A virtual node type that is used to represent any data endpoint that sends data via REST.

• Anchors incoming metrics or status objects
• Supports JSON/form data payloads
• Accepts data via local REST API or cloud relay endpoint
• Stores received values as counters or alert statuses
• Requires no IP address or discovery

2. OpenTelemetry Gateway (Cloud-Based)

NetCrunch offers native support for OTLP (OpenTelemetry Protocol) for receiving telemetry from OpenTelemetry-compatible agents or exporters.

Supported Endpoints

• Logs:
  https://otlp.netcrunch.io/v1/[serverId]@[sensorId]@[nodeId]/logs

• Metrics:
  https://otlp.netcrunch.io/v1/[serverId]@[sensorId]@[nodeId]/metrics

Traces are not currently supported.

How Logs Are Processed

• Received as NetCrunch alerts (with no active state)
• All logs match the default Any Event rule unless filtered
• To filter logs, use the rule: Event for Received Telemetry Event
• Key log fields become alert parameters:

How Metrics Are Processed

OTLP metrics are converted to NetCrunch counters using a standardized path model:

• Metrics are stored as standard counters
• Description and unit will be added to metadata (feature in progress)

Histogram Support

Histograms will be supported in the future and stored in a dedicated high-volume time-series database.
Currently: not yet implemented.

Summary

Telemetry in NetCrunch enables modern, scalable monitoring for dynamic environments. Whether through the lightweight Telemetry Node or OTLP integration, you can now collect rich logs and metrics from virtually any platform, without needing traditional polling.

cloud metricslog ingestionnetcrunch cloudnetcrunch telemetry nodeobservabilityopen telemetryotlpotlp gatewaypush metricstelemetry

Telemetry Node

A Telemetry Node is a NetCrunch node type for receiving metrics, statuses, and events from external systems via REST or OTLP. It anchors telemetry data for cloud, IoT, or custom systems, and replaces the older REST Receiver with a unified, event-capable design.

Overview

In NetCrunch, every monitoring object must be tied to a node. The Telemetry Node is purpose-built for ingesting external metrics, statuses, and events—ideal for workloads and devices that cannot be polled or exist outside the direct network (e.g., cloud, scripts, IoT, embedded).

Common uses:

• Remote or embedded systems
• Cloud applications & APIs
• IoT/headless devices
• Apps/scripts pushing telemetry

How to Add a Telemetry Node

1. Click the Add (+) button at the top of the NetCrunch UI.
2. In the popup menu, select:
   Other → Telemetry Node (label may also appear as "Telemetry Receiver").
3. Enter the desired node name and choose visibility options.
4. Confirm. NetCrunch assigns a nodeId and creates the default Telemetry Sensor (sensorId).

The sensor is always created and cannot be removed, only disabled.

Node Type Transition

• The REST Receiver node type is now deprecated and replaced by Telemetry Node.
• Telemetry Node:
  • Supports event ingestion
  • Uses sensorId as the main identifier (not just nodeId)
  • Sensors are auto-added (can be disabled but not deleted)
  • Legacy REST Receivers still work but are superseded

Supported Input Protocols

All data is routed to the Telemetry Node Sensor (nodeId + sensorId).

REST Endpoints

• Local REST:
  https://<nc-server>/api/rest/1/sensors/<sensorId>@<nodeId>/update
• Cloud REST:
  https://gw.netcrunch.io/tm/v1/<serverId>@<sensorId>@<nodeId>/update

Example Payload

{
  "counters": { "system/cpu.load": 0.75 },
  "statuses": {
    "uptime": {
      "value": "ok",
      "data": { "statusCode": 1 },
      "message": "System running for 3 days"
    }
  }
}

OTLP Gateway (OpenTelemetry)

• Metrics:
  https://otlp.netcrunch.io/v1/<serverId>@<sensorId>@<nodeId>/metrics
• Logs:
  https://otlp.netcrunch.io/v1/<serverId>@<sensorId>@<nodeId>/logs

Notes:

• Traces not supported.
• Logs = non-active alerts. Metrics = counters.
• Histogram support planned.

Event Ingestion Endpoints: Telemetry Node vs Web Message Sensor

Important: The endpoint for sending events is different for Telemetry Nodes compared to classic Web Message Sensors. Using the wrong endpoint means events will not be processed.

Telemetry Node Event Endpoint

For Telemetry Nodes, events must be sent to the sensor endpoint:

https://<nc-server>/api/rest/1/sensors/<sensorId>/event

• The event is linked to the specific sensor (sensorId) created for the Telemetry Node.
• This is required for all Telemetry Node event alerts to work.

Web Message Sensor (Legacy) Event Endpoint

For legacy Web Message Sensors (non-telemetry), events must be sent to the node endpoint:

https://<nc-server>/api/rest/1/node/<nodeId>/event

• The event is linked directly to the node (nodeId).

Why This Matters

• Telemetry Node: expects events by sensorId.
• Web Message Sensor: expects events by nodeId.

If you send events for a Telemetry Node to the node/<nodeId>/event endpoint, they will not be processed.

Quick Reference

Sending Data – Examples

Cloud REST Update

curl -X POST https://gw.netcrunch.io/tm/v1/SRV-1@sensor42@node91/update \
  -H "Content-Type: application/json" \
  -d '{"counters":{"system/disk.freeMB":12800},"statuses":{"system/fan":{"value":"ok","message":"normal"}}}'

Local REST Event

curl -X POST https://<nc-server>/api/rest/1/sensors/sensor42/event \
  -H "Content-Type: application/json" \
  -d '{"message": "failed login"}'

• Event fields: message, description, attributes (additional params like user, time, etc.)

Alerting on Events

• Event alerts support filtering on event fields.
• Empty filter = match all.

Node Behavior & Monitoring

• Telemetry Node anchors all incoming metrics, statuses, and events
• Supports dashboards, alerting, and historical data
• Can receive Monitoring Packs and policies
• Appears in topology views (unless hidden)

Summary

Telemetry Nodes deliver a push-based model for observability—ideal for remote/cloud/IoT data, with robust REST and OTLP support and direct event ingestion. They simplify integrating external or serverless systems with NetCrunch monitoring.

event endpointnetcrunchobservabilityotlp gatewaypush monitoringreceiver noderemote metricsrest apisensor updatetelemetry node

Server and Application Monitoring

Agentless monitoring of operating systems, virtualization, logs, applications, and services.

Application Monitoring

NetCrunch supports monitoring many applications by Monitoring Packs. It's also easy to create agents for sending data to NetCrunch.

Monitoring Windows Applications

NetCrunch contains predefined monitoring packs for common Windows applications.

Custom Monitoring

Using Windows Services and Counters

You can look at various Monitoring Packs defined in NetCrunch. Any other application can be monitored in a very similar way - if it supports perfmon counters; otherwise, you can rely on monitoring Windows services and processor and memory parameters for specific processes.

Using Scripts and Agents

This is another option for monitoring Windows applications and any other application, including the hosted remote application or even websites.

You can create a script, which will poll necessary information for NetCrunch, or modify the existing application to send REST requests to NetCrunch.

It doesn't involve much programming as you can use cUrl, an open-source project available for almost any platform.

You can find it at http://curl.haxx.se.

Read more about Sending Data to NetCrunch.

Managing Monitoring Credentials

To access monitored systems, NetCrunch needs valid credentials for each system. You can manage these credentials using profiles or set custom credentials for each node and system separately.

To maintain compatibility with previous versions, one default profile for each operating system is defined. You can create more profiles by pressing the plus button at the window's top right corner.

You can manage credentials used for connecting to monitored systems in Settings Monitoring Monitoring Credentials Manager

All credentials are stored securely on the NetCrunch Server, and the console can never retrieve passwords.

credentialspasswords

Operating System Monitoring

Read about monitoring Windows, macOS, Linux, BSD, Solaris, and ESXi systems.

NetCrunch monitors all operating systems without installing any agents. It's convenient but sometimes requires extra settings to be set on monitored systems.

Windows

Monitoring Windows computers without agents depends on two factors:

• Correct Windows setup – allowing remote access to the system and retrieving performance information.
• Setting OS Monitoring in node properties – it must be enabled and set to Windows.

Secure and Credential-Aware Monitoring

NetCrunch is designed to monitor Windows systems securely. It:

• Uses Kerberos authentication when operating in Active Directory environments.
• Falls back to NTLM or local credentials if needed.
• Uses a combination of native Windows protocols (RPC, SMB) and WMI depending on the task and available access.
• Applies least-privilege credential use by supporting multiple credential profiles per node.

This ensures compatibility across Windows versions and deployments, even with strict domain policies.

Windows Setup for Monitoring

Windows is the most common desktop OS, but its security configuration can complicate monitoring. Many challenges are automatically resolved when systems operate in an AD domain.

Before enabling monitoring, review the detailed setup steps in the Windows Monitoring Setup topic. We also provide a shell script for configuring standalone systems.

What can be monitored

Windows monitoring includes Windows services, Event Logs, and performance counters. Additional insights are possible with WMI sensors for software, hotfixes, and hardware. You can explore example configurations in the available Monitoring Packs for Windows.

Enable Windows-specific monitoring via:
Node Settings Monitoring Windows

Windows Services

Windows Services monitoring tracks both service states and installation lifecycle.

NetCrunch observes and alerts on the following service states:

• Service is Running
• Service is Paused
• Service is Stopped
• Service is not Running

It also detects service installation or removal events, which are distinct from state changes:

• Service Installed – the service appeared in the system
• Service Uninstalled – the service disappeared from the system

These are treated as event-based alerts, not state-based ones. This distinction is important for software that installs new versions by uninstalling and reinstalling the service — where NetCrunch captures that transitional moment.

Alerts can be defined for:

• A specific service name
• Services matching a regular expression
• All services

Manual service inspection is available at:
Node Status Windows Windows Services

Config Sensors (Device Inventory)

NetCrunch provides a set of configuration sensors (formerly inventory monitor) for monitoring hardware and software configuration changes. Although Windows machines can be monitored with RPC, these sensors require access to WMI, so make sure WMI is enabled and not blocked on the destination machine.

Hardware (WMI)

Using this sensor, you can download and monitor for changes in the hardware configuration of Windows-based hosts. The hardware configuration includes information about the processor, memory, installed disks (storage), video (graphic card), and monitor.

Software (WMI)

The sensor collects information about installed software, including installation date, version, and vendor. It can notify you when new software is installed, uninstalled, or updated.

Hotfixes (WMI)

The sensor collects information about installed hotfixes. It can notify you when a hotfix is installed or uninstalled.

Windows Event Log

NetCrunch can monitor Event Log entries on a given computer. It does it with a WQL query that NetCrunch automatically builds upon your parameters. You can set up this monitoring by adding an alert to the Windows Event Log sensor in Node SettingsMonitoring. Many of the predefined Monitoring Packs also enable Event Log monitoring.

Hyper-V Monitoring

NetCrunch allows monitoring Hyper-V services, but you must configure the node to monitor Windows first as it runs on Windows. Then, NetCrunch automatically detects the system is running Hyper-V services and ads.

WMI Sensors

NetCrunch provides several WMI sensors that include executing custom query and monitoring processes, performance counters, or file shares.

Performance Counters

Windows offers many built-in performance counters, which the installed applications extend. NetCrunch allows the defining several types of Event Triggers for Counters on Windows counters. You can set up triggers by adding a new alert to a node or the Monitoring Pack. Settings Alerting & Notifications Monitoring Packs and Policies

Windows OS Monitoring Packs

Windows Applications

Actions

Linux

NetCrunch monitors Linux without agents using an SSH script, which is automatically copied to a remote machine.

Preparing Node for Linux Monitoring

1. Open Node Settings > Monitoring and enable OS monitoring by selecting Linux from the drop-down menu.

2. Now, you can see the parameters to monitor Linux. Enter SSH credentials unless you use default settings for Linux or add a new credentials profile.

Linux Monitoring Packs

Actions

Scripts

BSD

NetCrunch monitors BSD without agents using an SSH script, which is automatically copied to a remote machine.

Monitoring Packs

Actions

Solaris

NetCrunch monitors Solaris without agents using only an SSH script, automatically uploaded to the remote machine.

Monitoring Packs

Actions

macOS

NetCrunch monitors macOS without agents using only an SSH script, automatically uploaded to the remote machine.

Monitoring Packs

Actions

Other Operating Systems

VMware ESXi

NetCrunch supports direct monitoring of ESXi or using vCenter. Read more in VMware Monitoring.

Legacy Systems

IBM AIX and AS/400

IBM AIX and AS/400 systems can be monitored via SNMP.

IBM Monitoring Packs

Novell NetWare

As each NetWare system has a pre-installed SNMP agent, monitoring is possible using SNMP.

NetWare Monitoring Pack

bsdesx/iesxifree bsdlinuxmacmonitoringopen bsdososxsolariswindows

Monitoring Disk Parameters on Unix family systems

Read what disk performance metrics can be monitored on Linux, macOS, BSD, and Solaris.

Linux

Counters

• Reads completed - The total number of reads completed successfully.

• Reads merged - Reads adjacent to each other may be merged for efficiency. Thus two 4K reads may become one 8K read before it is ultimately handed to the disk, and so it will be counted (and queued) as only one I/O. This field lets you know how often this was done.

• Sectors read - The total number of sectors read successfully.

• Read Bytes - The total number of bytes read successfully.

• Milliseconds spent reading - The total number of milliseconds spent by all reads (as measured from __make_request() to end_that_request_last()).

• Writes completed - The total number of writes completed successfully.

• Writes merged - Writes which are adjacent to each other may be merged for efficiency. Thus two 4K writes may become one 8K write before it is ultimately handed to the disk, and so it will be counted (and queued) as only one I/O. This field lets you know how often this was done.

• Sectors written - The total number of sectors written successfully.
• Write Bytes - The total number of bytes written successfully.
• Milliseconds spent writing - The total number of milliseconds spent by all writes (as measured from __make_request() to end_that_request_last()).
• I/Os currently in progress - The counter that should go to zero. Incremented as requests are given to appropriate struct request_queue and decremented as they finish.
• Milliseconds spent on I/Os - This counter increases so long as I/Os currently in progress is nonzero.
• Weighted milliseconds spent on I/Os - This counter is incremented at each I/O start, I/O completion, I/O merge, or read of these stats by the number of I/Os in progress I/Os currently in progress times the number of milliseconds spent doing I/O since the last update of this field. This can provide an easy measure of both I/O completion time and the backlog that may be accumulating.
• Transferred Bytes - The sum of Read Bytes and Write Bytes.
• Transferred sectors - The sum of Sectors read and Sectors written.
• Average requests size (Bytes) - The average size (in bytes) of the requests issued to the device.

Average queue length - The average queue length of the issued requests to the device. - Average time for I/O requests (ms) - The average time (in milliseconds) for I/O requests issued to the device to be served. This includes the time spent by requests in the queue and the time spent servicing them. - Average read requests time (ms) - The average time (in milliseconds) for reading requests issued to the device to be served. This includes the time spent by requests in the queue and the time spent servicing them. - Average write requests time (ms) - The average time (in milliseconds) for write requests issued to the device to be served. This includes the time spent by requests in the queue and the time spent servicing them.

Calculated counters

• Reads completed/sec - The total number of completed reads (requests).
• Writes completed/sec - The total number of writes completed (requests).
• Reads merged/sec - The total number of reads merged.
• Writes merged/sec - The total number of writes merged.
• Sectors read/sec - The total number of sectors read.
• Sectors written/sec - The total number of sectors written.
• Read Bytes/sec - The total number of bytes read successfully.
• Write Bytes/sec - The total number of bytes written successfully.
• Transferred Bytes/sec - The total number of bytes read and written.
• Transferred sectors/sec - The total number of sectors read and written.

macOS

Counters

• Completed I/Os - The sum of completed reads and writes.
• Transferred Bytes - The sum of bytes read and written.

Calculated counters

• The total number of completed I/Os/sec
• The total number of bytes read and wrote/sec

BSD, Free BSD, Net BSD, Open BSD

Supported BSD distributions

• FreeBSD: Reads completed, Read Bytes, Writes completed, Write Bytes, Completed I/Os, Transferred Bytes, Seconds spent on I/Os, Transactions queue length, Reads completed/sec, Writes completed/sec, Read Bytes/sec, Write Bytes/sec, Transferred Bytes/sec, Completed I/Os/sec
• NetBSD: Reads completed, Read Bytes, Writes completed, Write Bytes, Completed I/Os, Transferred Bytes, Seconds spent on I/Os, Reads completed/sec, Writes completed/sec, Read Bytes/sec, Write Bytes/sec, Transferred Bytes/sec, Completed I/Os/sec
• OpenBSD: Completed I/Os, Transferred Bytes, Seconds spent on I/Os, Transferred Bytes/sec, Completed I/Os/sec

Counters

• Reads completed - The total number of reads completed successfully.
• Read Bytes - The total number of bytes read successfully.
• Writes completed - The total number of writes completed successfully.
• Write Bytes - The total number of bytes written successfully.
• Completed I/Os - The sum of Reads completed and Writes completed.
• Transferred Bytes - The sum of Read Bytes and Write Bytes.
• Seconds spent on I/Os - The total number of seconds spent by all reads and writes.
• Transactions queue length.

Calculated counters

• Reads completed/sec - The total number of completed reads (requests).
• Writes completed/sec - The total number of writes completed (requests).
• Read Bytes/sec - The total number of bytes read successfully.
• Write Bytes/sec - The total number of bytes written successfully.
• Transferred Bytes/sec - The total number of bytes read and written.
• Completed I/Os/sec - The sum of Reads completed and Writes completed

Solaris

Solaris 10 and Solaris 11 are supported.

Counters

• Reads completed - The total number of reads completed successfully.
• Read Bytes - The total number of bytes read successfully.
• Writes completed - The total number of writes completed successfully.
• Write Bytes - The total number of bytes written successfully.
• Completed I/Os - The sum of Reads completed and Writes completed.
• Transferred Bytes - The sum of Read Bytes and Write Bytes.
• Elements in wait state.
• Elements in run state.
• I/Os currently in progress - The sum of Elements in wait state and Elements in run state.
• Milliseconds spent waiting - Cumulative wait (pre-service) time.
• Weighted milliseconds spent waiting - Cumulative wait length*time product.
• Milliseconds spent running - Cumulative run (service) time.
• Weighted milliseconds spent running - Cumulative run length*time product.
• Milliseconds spent on I/Os - The sum of Milliseconds spent waiting and Milliseconds spent running.
• Weighted milliseconds spent on I/Os - The sum of Weighted milliseconds spent waiting and Weighted milliseconds spent running.
• Soft errors - A disk sector fails the CRC check and needs to be re-read.
• Hard errors - Re-read fails several times for CRC check.
• Transport errors - Errors reported by I/O bus.
• Total errors - The sum of Soft errors, Hard errors and Transport errors.
• Average wait queue length.
• Average run queue length.
• Average transactions queue length - The average queue length of the requests issued to the device.
• Average wait time for I/O requests (ms).
• Average run time for I/O requests (ms).
• Average time for I/O requests (ms) - The average time (in milliseconds) for I/O requests issued to the device to be served.
• Average requests size (Bytes) - The average size (in bytes) of the requests issued to the device.

Calculated counters

• Reads completed/sec - The total number of completed reads (requests).
• Writes completed/sec - The total number of writes completed (requests).
• Completed I/Os/sec - The total number of completed IO requests.
• Read Bytes/sec - The total number of bytes read successfully.
• Write Bytes/sec - The total number of bytes written successfully.
• Transferred Bytes/sec - The total number of bytes read and written. bsddiskfree bsdlinuxmac os xmacosmonitorsolarisunix

Windows Monitoring Setup

Reading this topic will make your Windows monitoring experience much better.

NetCrunch can monitor Microsoft Windows systems without installing additional agents. However, tightened security rules make remote monitoring possible only after the initial configuration, depending on your Windows environment.

MONITORING SERVER

NetCrunch Server can be installed on Windows Server 2016 or later. If you manage most of the servers by Active Directory, installing NetCrunch on a machine within an Active Directory domain is the better option. This method makes configuration much easier.

MONITORED SYSTEMS

SERVERS

Most server systems come with an enabled firewall, which blocks remote administration. It is the first step you need to take. It could be done either from Active Directory Group Policies or manually one by one. We suggest using a simple script.

Download it here: www.adremsoft.com/download/SetWinForNC.zip.

WORKSTATIONS

If you manage your workstations by Active Directory, preparing them for monitoring will be the same as for the servers (by Active Directory Group Policies or using the script).

Monitoring of workstations in Workgroups requires manual configuration. You can choose to use the built-in local Administrator account or create a new account and manually assign necessary rights directly to this monitoring account.

CONFIGURATION STEPS OVERVIEW

1. Setting Access Rights
   NetCrunch needs a user account for monitoring that has proper access rights to DCOM, WMI (root\cimV2), and (Read Access) to the registry key (HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Perflib.
   The easiest way (not the only one) you can do it is by adding this user to the local Administrators group.

2. Setting Firewall Rules
   Firewall rules must allow traffic of RPC, Performance Monitoring, Named Pipes, and WMI.

3. Enabling PerfMon monitoring
   The Remote Registry service must be running, and its startup type should be Automatic.

CONFIGURING ACTIVE DIRECTORY DOMAIN

If you manage most of the servers by Active Directory, the best solution is installing NetCrunch on a server in the Active Directory domain and creating a dedicated user for monitoring. If you have not yet created such a user in your Active Directory, you should abort your NetCrunch installation now and configure your Active Directory first, allowing time for the user to propagate across your machines. You can start the NetCrunch installation again after your configuration has been propagated to all servers – it takes approximately 2 hours.

This is done for NetCrunch to discover all servers in the AD and automatically set up monitoring for them. Other servers in untrusted domains or workgroups can be configured separately (see Configuration of Separate Windows Server section below).

SETTING ACCESS RIGHTS

STEP 1 - CREATE USER FOR MONITORING

Create an Active Directory user account (for example, nc-mon-user) used by NetCrunch Server for monitoring. You will be asked later for this user's credentials during the NetCrunch installation.

STEP 2 - SET UP THE RIGHTS FOR THE USER

The user account needs administrative rights to all monitored Windows computers (including the server where NetCrunch Server is installed). There are two different ways to accomplish this, depending on your Active Directory architecture and your needs:

IF IN A SINGLE DOMAIN WHERE YOU WANT TO MONITOR ALL MACHINES

Create an Active Directory group (e.g., Monitoring Users) and add the previously created nc-mon-user account. Then use Group Policy to add that group to the local Administrators group on each monitored computer, using Restricted Groups.

IF MULTIPLE TRUSTED DOMAINS OR ONLY A SUBSET OF COMPUTERS NEEDS MONITORING

It would be best to use Group Policy to modify local Administrators' groups (on each monitored Windows machine).

a) Create an Active Directory group named Monitoring Users and add a previously created user account (nc-mon-user) to it.

b) Create a new Group Policy Object (GPO) and name it, for example, Local Administrators group membership for NetCrunch.

c) Create the rule for Monitoring Users' group membership.

Go to: Computer Configuration Policies Windows Settings Security Settings Restricted Groups

and add Monitoring Users to the local Administrators group using the section 'This group is a member of.'

d) Link the Local Administrators group membership for NetCrunch GPO to the appropriate Organization Unit(s) (OU) in your Active Directory domain(s).

SETTING FIREWALL RULES

1. Create a new Group Policy Object and name it, for example, "Windows Firewall rules for monitoring by NetCrunch."
   For Windows Server 2016 or later, go to: Computer Configuration Policies Windows Settings Security Settings Windows Defender Firewall with Advanced Security and add these rules to Inbound Rules, choosing them from a predefined list: File and Printer Sharing, Windows Management Instrumentation (WMI-In), Remote Event Log Management, Performance Logs and Alerts.

2. Link Windows Firewall rules for monitoring by NetCrunch GPO to the appropriate Organization Unit(s) (OU) in your Active Directory domain(s). For security reasons, it is recommended to customize remote administration rules to narrow the list of allowed IP addresses to the address of your NetCrunch Server only.

ENABLING PERFMON MONITORING

1. Create a new Group Policy Object and name it, for example, Windows services for monitoring by NetCrunch.
2. Setup Remote Registry service.
   Go to: Computer Configuration Policies Windows Settings Security Settings System Services and set Remote Registry Windows service startup mode to Automatic.
3. Link Windows services for monitoring by NetCrunch GPO to appropriate Organization Unit(s) (OU) in your Active Directory domain(s).
   After the policy refresh, the service should start immediately on every computer.

CONFIGURING OF SEPARATE WINDOWS SERVERS

SETTING ACCESS RIGHTS

Create nc-mon-user account using shell commands and add it to the local Administrators group.

net user /add nc-mon-user <Password>
net localgroup Administrators /add nc-mon-user

SETTING FIREWALL RULES

For Windows Server 2016 or later

you can create a rule for the IP address of the NetCrunch server only.

New-NetFirewallRule -DisplayName "NC-Mon-In" -Direction Inbound -RemoteAddress %IP% -Action Allow -Protocol TCP
New-NetFirewallRule -DisplayName "NC-Mon-Out" -Direction Outbound -RemoteAddress %IP% -Action Allow -Protocol TCP

ENABLING PERFMON MONITORING

Set up Remote Registry service startup and start the service.

Set-Service -Name RemoteRegistry -StartupType Automatic
Start-Service RemoteRegistry

DISABLING UAC REMOTE RESTRICTIONS

This step is no longer required for modern systems and has been removed in accordance with current best practices.

COMPLETE SCRIPT CAN BE DOWNLOADED FROM: this link

Summary of Technologies Used by NetCrunch

Windows technologies have been built layer by layer, one on top of another. For example, RPC is working on top of the Named Pipes, Remote Registry needs RPC, and WMI uses DCOM, which is also using RPC for communication. Everything needs proper settings of firewall and security settings. Here is the shortlist of technologies used by NetCrunch that need adequate configuration:

1. RPC & Named Pipes – Needs enabling File Sharing, firewall settings
2. Remote Registry – Needs firewall settings and Remote Registry service running
3. WMI & DCOM – Needs Firewall settings, DCOM & WMI security settings

It is straightforward and fastest way to do when the user designated for monitoring is a member of the local Administrators group – as described in this document.

It is the simplest way to configure servers for monitoring, but not the most secure. When you need to tighten your security settings even more, setting up specific rights for the monitoring account is possible but may vary depending on your configuration. Please contact Microsoft support for help.

You may also contact AdRem support for an example of how other users NetCrunch users have modified their Windows Monitoring Setup.

access rightsactive directoryfirewallmonitoringperfmonsetupwindowsworkstations

Hyper-V Monitoring

Monitor summary of hypervisor services and state of virtual machines run by Hyper-V

Hyper-V Server

Hyper-V services run on Windows, so you must configure the node to monitor Windows first. Then, NetCrunch automatically detects the system is running Hyper-V services and ads Hyper-V Server Monitoring Packs, which tracks the state of Hyper-V services.

You can automatically add all Hyper-V guests to NetCrunch Atlas and alerts or collectors on Hyper-V metrics in the' Hyper-V' settings. You can also go to Custom settings and add standard metrics visible through the perfmon Windows monitor.

In the Node Status window, you can see the state of all virtual machines located on a given server.

Virtual Machines

If you monitor Hyper-V servers, NetCrunch recognizes the machine running on the Hyper-V server and shows the additional information in the Node Status window.

You can also add various alerts regarding the state of the virtual machine and its guest performance metrics. You can do this by clicking on Hyper-V/VM in the Node setting section.

Available State Alerts:

• Enabled state
• Health State
• Operational state

Available Counters:

• % Guest CPU Usages
• % Guest Memory Free
• % Guest Memory Usage
• % Host CPU Usage
• % Host Memory Usage
• Guest Assigned Bytes
• Guest Available Bytes
• Host Memory Bytes
• Uptime

Hyper-V Server View

The view gives you a quick overview of monitored Hyper-V hosts. When NetCrunch discovers any Hyper-V Server, it creates them automatically.

Hyper-V VM View

You can see all the information about all monitored Virtual Machines per map and on the Atlas level.

hyper-vvirtualwindows

WMI Sensors

NetCrunch offers a collection of WMI sensors. Basic sensors are designated to serve specific purposes such as monitoring perfmon, process, shares, or time difference. The advanced sensor is more general and allows us to explore WMI classes or create custom WQL queries.

WMI sensors do not require a Windows OS monitor to be enabled on the node. In such a case, you must select an appropriate credential profile for each sensor.

Basic Sensors

These sensors don't require any knowledge about WMI or CIM. In particular, WMI Perform resembles the object names and counter names of the Perfmon.

wmi-perfmon

WMI Perfmon

WMI performance data comes from the perfmon provider, so we decided to use the same UI for WMI performance monitoring as perfmon. You don't need to use cryptic class names to get to the data. The sensor does this job. If you feel using class names is necessary, use the WMI Data sensor.

file-shares

File Shares

This sensor monitors the status of Windows Share. You can enter the share name manually or from the list.

process-group-summary

Process Group Summary Sensor

The sensor extends the Process sensor functionality by tracking multiple processes and using the wildcard (*) in the process name. It also supports monitoring child processes of a specified process when the Include child processes option is enabled, allowing you to view combined metrics for an entire process tree.

Selecting Processes by Name

You can specify multiple processes and separate them by commas. You can also use partial names using *. For example, 'nc*' will select all processes starting with 'nc'.

Include Child Processes

In addition to tracking top-level processes, the Include child processes option lets the sensor monitor all child processes spawned by a given parent process. This is particularly useful for monitoring services or applications that create multiple subprocesses or worker threads under distinct process identifiers.

Key Points:

• Automatic Child Detection: When Include child processes is enabled, the sensor recursively identifies child processes based on parent process ID relationships.
• Aggregated Metrics: Child processes are monitored alongside their parent, and performance data is aggregated, providing a single set of metrics for the entire process group hierarchy.
• Flexible Configuration: You can enable or disable Include child processes for any specified process name or pattern, allowing you to focus on what is most relevant to your environment.

Counters Tracked

When monitoring either individual or grouped processes (including child processes), the following counters are available:

• % Processor Utilization: The combined CPU usage for all selected processes.
• Handles: The total number of open handles, including those from child processes.
• Instances: The count of currently running process instances matched by the selection criteria.
• Memory Working Set (bytes): The sum of working set memory used by the parent, including child processes.
• Threads: The total number of threads across the process group.
• Virtual Bytes: The total virtual memory size utilized by the selected processes.
• Private Bytes: The total amount of memory allocated exclusively to the selected processes.

Note: Process names are case-insensitive in WMI.

By leveraging the ability to group processes and include their children, you gain a comprehensive view of resource usage and performance, simplifying monitoring complex applications and services that rely on multiple subprocesses.

process

Process Sensor

The Process Sensor allows you to monitor the health and performance of a specific process running on a target machine. By tracking various system resource counters, you can ensure that critical processes remain stable, efficient, and responsive over time.

Key Performance Counters

The sensor provides detailed insights into several performance metrics, including:

• % Processor Utilization: Shows the percentage of CPU time the process is consuming.
• Handles: Reflects the number of open handles (to system resources such as files, registry keys, etc.) that the process holds.
• Instances: Indicates how many instances of the monitored process are running.
• Memory Working Set (bytes): Represents the amount of memory currently used by the process.
• Threads: Displays the number of active threads within the process.
• Virtual Bytes: Identifies the process's total virtual memory.
• Private Bytes: Reports the process's total memory allocated.

These counters help you proactively detect unusual resource consumption, such as memory leaks, CPU spikes, or excessive handle usage, enabling timely troubleshooting and corrective action.

Process Identification Methods

When multiple processes share the same executable name or run with similar parameters, uniquely identifying the correct process instance is essential. The Process Sensor supports multiple identification methods to ensure accurate and reliable selection:

• By Name:
  Specify the process name (e.g., chrome.exe) to monitor. The sensor will generate a monitoring issue by default if multiple instances are found unless further criteria are provided.

• By Name and Parameters (Regular Expression):
  Combine the process name with command-line parameters to distinguish between different instances. A regular expression can be applied to the full process name (including extension) and its command-line arguments, helping you isolate a specific instance when multiple identical processes are running.

• By Command Line Regular Expression:
  Instead of relying on the process name, use a regular expression directly on the command-line arguments. For instance, you might match a particular Java application instance by its unique JAR file name or a specific parameter that differentiates it from other JVM instances.

Ensuring Unique Identification

The sensor will report a monitoring issue if more than one process instance matches the specified criteria. This safeguard prevents ambiguous situations where the sensor cannot determine which process instance to track.

To avoid conflicts:

• Refine your regular expression to match a unique parameter.
• Use a more specific process name if possible.
• Assign a unique Sensor ID when relying on name-based matches. This step is beneficial if you need to monitor multiple similar processes and want to track each one as a distinct entity in your monitoring environment.

By leveraging these identification methods and tracking critical performance counters, the Process Sensor helps maintain stable and predictable operations, offering a clear path to identifying and resolving performance-related issues with key processes in your infrastructure.

ad-replication

AD Replication Sensor

This sensor checks a Windows Domain Controller for replication errors. To use this sensor, add it to the machine, which is Domain Controller, and provide the credentials necessary to access the root\MicrosoftActiveDirectory namespace. The sensor shows one status per each one discovered AD partition.

Microsoft documentation about AD partitions

Statuses:

The total number of statuses depends on the Domain Controller configuration. Three statuses always occur:

• Domain Partition Replication Status
• Configuration Partition Replication Status
• Schema Partition Replication Status

Each status contains below data (properties):

• NumConsecutiveSyncFailures - number of consecutive sync failures
• IsDeletedSourceDsa - If the source is deleted
• TimeOfLastSyncAttempt - time of the last sync attempt
• LastSyncResult - result of the last sync
• TimeOfLastSyncSuccess - time of the last sync success
• ModifiedNumConsecutiveSyncFailures - number of modified consecutive sync failures
• ReplPendingOp:PositionInQ - number of pending replication operations
• DisableScheduledSync - If the scheduled sync is disabled

Default Alerts:

• "Alert on any partition replication error" - This alert will be generated if any status value changes to "Error," - which means replication has failed.

Credentials

You can use any credential that allows access to the root\MicrosoftActiveDirectory namespace. Administrative rights might be required.

pending-reboot

Pending Reboot Sensors

Check if the machine is waiting for a reboot because of the updates.

windows-updates

Windows Updates

The sensor monitors the status of Windows updates on a computer. Allows triggering an alert on a failed update.

registry

Registry Sensor

This sensor uses WMI to monitor Windows Registry objects specified by path.

The registry sensor alerts you when a subkey or value list is changed.

Possible alerts:

• Registry key does not exist
• The list of subkeys has changed
• The list of values has changed
• Specified subkey exists or does not exist
• Specified value exists or does not exist
• Alert on selected value content

registry-counters

Registry Counters Sensor

This sensor uses WMI to get and monitor numeric values from the Windows Registry.

• to the numeric value - the sensor returns one counter with this value
• to the key - each numeric value is an instance of the counter

This sensor can utilize thresholds in NetCrunch to monitor different scenarios:

• The port of the application saved in the registry should match exactly a given value by using a "Flat Value" event condition that is different from what is set in the alert
• Value of key that should be '0' and is set to '1' - this can be monitored by 'State trigger' as an event condition

remote-ping

Remote Ping

The sensor checks connectivity from a remote system by running Ping remotely.

It allows setting a threshold on the following counters:

• % Availability
• Response Time

time-difference

Time Difference

The sensor checks the time difference between a remote machine and the reference machine (NetCrunch Server or NTP server).

The sensor provides one counter, which is Difference sec.

wmi-hdd-health

WMI HDD Health

This sensor can monitor the HDD disk health state if the disk implements SMART technology, predicting disk failure.

It allows many counters, which depend on specific vendor implementation.

battery

WMI Battery

The sensor monitors the battery connected to the computer system. It can be a battery or any external battery (like UPS) connected to a computer.

Sensor alerts:

• When AC power is lost, the battery is discharged
• On battery hardware error
• When the battery level is low

windows-task-scheduler

Windows Task Scheduler Sensor

The sensor monitors the status of Windows Task Scheduler tasks. It allows triggering an alert if task configuration has changed or if a task was not run on time.

You can use various alerts to monitor tasks.

• task enable/disabled
• task configuration has changed
• The last task run has failed
• the task has not been run since the specified amount of time

Additional Info:

One sensor can monitor several tasks specified by name or regular expression.

iis-application-pool

IIS Application Pool

The sensor monitors the state and performance of the selected IIS Application Pool, providing insight into its operational status, resource utilization, and error conditions. This enables administrators to address issues proactively before they impact end-users.

Possible alerts:

• Application Pool is not running: Triggered if the monitored Application Pool becomes unavailable.
• The application pool has been restarted: Indicates that the pool was recently restarted, which may occur due to resource constraints, deployment changes, or configuration updates.
• Worker process failures: Alerts if worker processes (w3wp.exe) encounter errors or terminate unexpectedly.
• Alert on connection error: Notifies administrators if the Application Pool cannot accept or establish connections.
• Alert on authentication error: Indicates that client requests fail due to authentication issues.

Data Collector

IIS Application Pool Data Collector – This collector provides key performance counters and operational health metrics for the selected Application Pool. It includes:

• Worker Process Counts: Monitors the number of active worker processes, helping you understand resource allocation and concurrency.
• Worker Process Failures: Tracks the frequency of worker process crashes or failures, allowing early detection of problematic deployments or configuration settings.
• Basic Health Indicators: Gathers status information, including whether the Application Pool is currently started or stopped, enabling timely intervention when problems arise.

By leveraging these metrics, you can ensure your IIS Application Pool remains stable, responsive, and securely accessible to users.

Advanced Sensors

These sensors require a bit of knowledge about querying WMI objects.

wmi-data

WMI Data

The sensor allows the selection of the WMI class and instance key to retrieve object properties. The sensor enables processing multiple objects (and that's why it needs an instance key property).

The sensor allows setting alerts only on performance counters. Each numeric property of the selected class becomes a counter.

Beware that some classes may return large datasets as the sensor does not filter any instance.

Example

another way to monitor processes

Namespace

root\CIMV2

WMI Class

Win32_Process

Instance Key

Name

wmi-object

WMI Object

The sensor monitors a specific WMI object without writing a WQL query. So, in addition to the WMI Data sensor, an instance value must be set. It is compared for equality, so you can't filter objects by several properties.

The sensor also allows setting alerts on performance counters and treats each object's numeric property as a counter. Additionally, it allows for tracking status properties.

Status alert tracks change from one value to the other. You have continuously tracked status values and set them to appropriate ones.

Finally, you can store the last object data in the program database. Widgets or UI can later access these data.

wql-query$object

WQL Query:Object

The WMI Object sensor has some limitations. For example, you can filter instances by a single field only. Unfortunately, simple things tend to be limited, while flexible ones quickly become complicated.

Example

another way to monitor the process

Namespace

root\CIMV2

wql-query

WQL Query

SELECT * FROM win32_Process WHERE name = 'NCServer.exe'

Now, you can access counters of the given process or set the status alert for property changes.

batterychargefilehddmicrosoftobjectperfmonpingqueryregistryremoteschedulersharessmartsummarytaskupswindowswmiwql

WBEM Sensors

WBEM stands for Web-Based Enterprise Management. It's a set of technologies that describe and share management information about various devices across different platforms. NetCrunch includes three WBEM sensors - Data, Object, and WQL Query: Object that allows access to all available WBEM classes.

WBEM Sensors are similar to their WMI Data, Query, and WQL Object counterparts.

General WBEM requirements

CIM Server (CIMOM) should be launched on a monitored machine along with CIM Providers to use these sensors.

Sensors support HTTP or HTTPS connections.

Credentials may be required, but it depends on the implementation of WBEM installed on a given machine.

wbem-data

WBEM Data

The sensor allows selecting WBEM class and instance key to retrieve object properties. The sensor enables the processing of multiple objects (and it's why it needs an instance key property).

The sensor allows setting alerts on performance counters only. Each numeric property of the selected class becomes a counter.

Some classes can return large datasets because the sensor does not filter any instance.

Requirements (standard for all WBEM sensors) To use this sensor, add it to the machine which has launched CIM Server (CIMOM) and some CIM Providers.

Example:

Processes monitoring:

Namespace

root/cimv2

WBEM Class

CIM_Process

Instance Key

Name

wbem-object

WBEM Object

The sensor monitors a specific WBEM object without writing a WQL query. So, in addition to the WBEM Data sensor, it requires an instance value to be set. The sensor checks it for equality, so you can't filter objects by several properties.

The sensor also allows setting alerts on performance counters and treats each object's numeric property as a counter. Additionally, it allows for tracking status properties.

Status alert tracks change from one value to the other. In such cases, you can always track status values and set them to appropriate values.

Finally, you can store the last object data in the program database. Widgets or UI can later access these data.

It is allowed to monitor only instances with unique instance property values.

wbem-wql-query$object

WBEM WQL Query: Object

WBEM WQL Query: Object Sensor The WBEM Object sensor has some limitations. For example, you can filter instances by a single field only. Unfortunately, simple things are limited, while flexible ones quickly become complicated.

It allows retrieving data of specific CIM Class instances by writing a WQL query. The query must point to only one instance.

Example

Monitoring of specific process

Namespace

root\cimv2

WQL Query

SELECTt * FROM CIM_Process WHERE name = '-bash'

Now you can access counters of the given process or set the status alert on property change.

linuxobjectqueryunixwbemwql

TACACS+ Sensor

TACACS+ provides access control for routers, network access servers, and networked computing devices via one or more centralized servers. TACACS+ provides separate authentication, authorization, and accounting services.

The TACACS+ sensor checks the server connectivity and tries to authenticate a specified user. Sensor requires - TACACS server shared secret - used for data encryption - user (with password) to authenticate

The sensor should be added to the TACACS+ server machine.

Alerts:

• alert on connection error
• alert when user authentication failed

Counters

• Response time - total execution time of all queries in the TACACS session

tacacs

Cisco CBQOS

NetCrunch's Cisco CBQoS (Class-Based Quality of Service) Sensors offer a sophisticated solution for monitoring Quality of Service statistics through SNMP. This tool is instrumental in analyzing key QoS metrics, providing network administrators with detailed insights to refine QoS policies effectively.

Detailed QoS Insights

The Cisco CBQoS Sensors in NetCrunch enable comprehensive monitoring of QoS statistics, crucial for optimizing network performance and traffic management. The main areas of monitoring include:

• ClassMap Statistics: Gain in-depth statistical information related to ClassMaps, which helps in understanding how different classes of network traffic are being managed and prioritized.

• Match Statement Statistics: Access detailed statistics associated with Match Statements to analyze how specific traffic is identified and categorized within the network.

• Queueing Action Statistics: Examine statistics related to Queueing Actions, offering insights into how various traffic classes are being queued and handled, essential for effective bandwidth management and traffic shaping.

Default Alerts and Reports

Alerts

NetCrunch automatically generates alerts to keep administrators informed about critical issues, including:

• Authentication Error: Notifies when there are issues with SNMP authentication, ensuring secure and reliable data collection.
• Request Timeout: Alerts when SNMP requests to devices time out, indicating potential communication issues or device malfunctions.

Reports

NetCrunch provides default reports for comprehensive analysis, such as:

• Class Map Statistics Report: This report presents a detailed overview of the traffic in each class map, providing valuable data for evaluating the effectiveness of QoS policies.

Enhanced Decision-Making

With these tools, network administrators can make more informed decisions regarding QoS policies, leading to improved network performance and efficiency.

cbqosciscomonitoringqos

LDAP Monitoring

LDAP Authentication Sensor checks the user authentication process via LDAP that is used by directory services such as MS Active Directory.

LDAP Authentication Sensor

The sensor connects to LDAP (Lightweight Directory Access Protocol) server and tries to bind using a specified Distinguished Name and password.

LDAP Bind operation is used to authenticate clients (and the users or applications behind them) to the directory server.

Sensor alerts when bind operation cannot be completed (e.g., because specified credentials are invalid).

The sensor supports both plaintext and SSL/TLS connections and LDAP v2 and v3 protocols. Bind operation can be performed with a simple (plain text) authentication mechanism or using SASL (Simple Authentication and Security Layer) - Digest (MD5), NTLM/Negotiate, and Kerberos can be used.

Notice

Distinguished Name is commonly the string that uniquely identifies an entry in the Directory Information Tree, like:

cn=John Doe,ou=people,dc=example,dc=com

For Windows Active Directory, use either :

Domain\user

or

user@domain

Alerts:

• Connection error
• Authentication error

Counters

• Response time

adldapopenldap

Monitoring Files and Folders

NetCrunch allows monitoring files, folders, and text logs.

Node SettingsMonitoringAdd Monitoring Sensor

file

File Sensor

FTP/S, HTTP/S, SSH/Bash, SFTP, Windows/SMB, TFTP

NetCrunch contains a single sensor that allows monitoring files using one of the five common protocols. You can monitor file size, file changes, accessibility, or when it has been updated (file age).

Critical File Events

• Authentication Error
• Connection Error
• File does not exists
• File read error

Warning File Events

• Alert on Monitoring Sensor counter
• File exists
• File is empty
• File is not empty
• File modified
• File access error
• File has not been updated within the given time range (file age)
• File updated too often (file age)

text-file

Text File Sensor

FTP/S, HTTP/S, SSH/Bash, SFTP, Windows/SMB

The sensor allows the monitoring of file properties and file content. The content can be searched globally or per line.

File content event monitor can search for some text using plain text patterns or regular expression. The incremental search will monitor only new occurrences in a file.

Text File Line event monitor tries to match lines, and if a new line is found, an alert is triggered. A search pattern can be plain text or a regular expression. If multiple text lines match the search pattern, the program can group them into a single alert.

Critical File Events

• Authentication Error
• Connection Error
• File does not exist

Warning File Events

• Alert on Monitoring Sensor counter
• File exists
• File is empty
• File is not empty
• File modified
• File access error
• File has not been updated within a given time (file age)
• File read error
• File updated too often (file age)
• File Content event
• Text File Line event

Example: Alerting on cron log

For example, we want to know when there is at least 1 job ran on exit. So let's see a sample cron log:

Nov  5 01:01:01 localhost CROND[22826]: (root) CMD (run-parts /etc/cron.hourly)
Nov  5 01:01:01 localhost run-parts(/etc/cron.hourly)[22826]: starting 0anacron
Nov  5 01:01:01 localhost anacron[22836]: Anacron started on 2015-11-05
Nov  5 01:01:01 localhost anacron[22836]: Normal exit (1 job run)
Nov  5 01:01:01 localhost run-parts(/etc/cron.hourly)[22838]: finished 0anacron

We can define the following expression to a more specific line:

anacron.*Normal exit \([1-9]*

Performance Metrics

• Text.File.Sensor/Check Time
• Text File.Properties/Size

data-file

Data File

FTP/S, HTTP/S, SSH/Bash, SFTP, Windows/SMB

The sensor loads data from a file using one of the predefined file formats. It supports native NetCrunch XML, JSON, and CSV and allows processing data through Data Parsers, allowing for any data.

folder

Folder Sensors

FTP/S, SSH/Bash, Windows/SMB

The folder sensor allows observing folder content. The sensor can trigger alert when the file is deleted and on various other conditions.

Critical Folder Events

• Authentication Error
• Connection Error
• Folder access error
• Folder does not exist

Warning Folder Events

• Folder empty
• Folder exists
• Folder not empty

Monitoring Folder Content

You can check the list of files matching the given file mask.

• Files exist
• Files not exist
• New file added
• File removed
• Last modified file in the folder is older than...
• Oldest file in the folder is older than...
• Last modified file in the folder
• Oldest file in the folder

Performance Metrics

• Folder.Sensor/Check Time
• Folder. Properties/File Count
• Folder.Properties/Size (bytes)

filefile monitoringfile sensorsensortexttext log

Monitoring Text Logs

NetCrunch allows monitoring text file content and has a special sensor for text logs.

Node SettingsMonitoringAdd Monitoring Sensor

NetCrunch allows two levels of monitoring of log files. Simple monitoring can be configured with file sensors (using remote windows, FTP or HTTP), which look for a specific text pattern in log files.

More advanced log monitoring is possible with Text Log sensor, which can parse the file, and then the program can collect and alert on parsed entries.

Text Log Sensor

FTP/S, HTTP/S, SSH/Bash, SFTP, Windows/SMB, TFTP

This sensor parses a file and converts each entry into a list of properties, which later can be filtered like any other type of log (Windows Event Log, syslog). This gives you more control over how alerts are triggered and allows better analysis of collected log entries in the event log.

Text Log sensor can remotely monitor large log files on Windows (tested on gigabyte files) and using SSH/Bash connection. Unfortunately, FTP or HTTP requires whole files to be downloaded.

NetCrunch contains sample text log formats and allows defining custom formats using text parsing expressions.

Text Log Parsing Expressions

Settings Resources Text Parsing Expressions Text Log Expressions

Separated Values (CSV)

Best suited for simple log formats where each line contains fields separated by a single character.

For example, such a line can look like this:

  11/19/15 7:20:38 am,Information,Monitor started

And we can define that the program should convert this to fields:

• Time
• Severity
• Message

Regular Expressions

In the case of logs where there is no separator between fields, we can use regular expressions. The expression must contain search groups to identify each field.

Simple example.

In this example, our log can contain a number at the beginning and then a message until the line's end.

10345 : Error during loading module.

Expression:

([0-9]*) : (.*)

We can define two fields to manage such log:

• ProcessId
• Message

Parsing expression editor allows immediate testing of your expressions:

Log4J Log Format

This is a widely used log format by Java programs. It's a good example of using regular expressions to monitor the log entries.

Apache Log Format Expression

Apache logs can be formatted using special formatting strings. NetCrunch can reverse-engineer these formats to parse a given log. To parse the log, you need only copy the log format string from the configuration and put it into NetCrunch expressions.

Javascript Expression

You can write a simple code to parse input text.

Prerequisites

• input text is in text variable
• The output object is the result variable, and its properties should match the defined variables
• you have to add each variable name to the list of variables

Alerts

• Authentication error
• Connection error
• File read error
• File access error
• File does not exist
• File exists
• File has been updated within a given time range (file age)
• File is empty
• File is not empty
• File modified
• File updated too often (file age)
• Alert on the text log entry

For example, for our simple log, we can define an alert:

Counters

The program can also trigger an alert on the following performance counters:

• Text Log.Sensor.Check Time
• Text Log.Properties/Log Entries Processed
• Text Log.Properties/Size

logmonitorsensortexttext+log

Monitoring Web Pages & Data

NetCrunch can monitor requests, pages, and data on the web.

Node SettingsMonitoringAdd Monitoring Sensor

NetCrunch includes two sensors for web monitoring.

web-page

Web Page Sensor

The sensor renders the page like a web browser. It loads all resources and runs scripts. It's intended for monitoring modern pages or applications. It supports standard login and custom login forms.

Options

• Connection Profile
• Authentication Profile
• Load images
• Run Javascript
• Follow redirects

Alerts:

• Alert on Monitoring Sensor counter
• Web page does not exist
• Web page loading error
• Page resource load error
• Page content changed
• Alert on HTML element check
• Connection Error
• Authentication Error

Checking Page Content

You can test page content in two ways. First, you can search for text patterns using regular expressions within the HTML or text content. Second, you can define a DOM selector to locate an element on the page and then check the text or attributes of that element (or list of elements).

Performance Metrics:

• Web Page.Sensor.Check Time
• Web Page.Page/% Availability - Availability is 100% if HTTP responds with status 200 (OK), otherwise is 0%
• Web Page.Page/HTTP Status Code - Status code returned by the server
• Web Page.Page/JS Errors - JavaScript execution error (exception) count
• Web Page.Page/Load Time - Total page loading time (ms)
• Web Page.Page/Main Frame Body Size - Length of the page's mainframe content (bytes)
• Web Page.Page/Resource Count - Page resource count
• Web Page.Page/Resources Error Count - Page resource loading error (timeout) count
• Web Page.Page/Total Size - Total length of all page resources (bytes)

Report

Default report added collects: % Availability, Load Time , Total Size, Resource Count, Resource Error Count. These parameters are also available in the @trend-viewer.

basic-http

Basic HTTP Sensor

This sensor sends a single request and can alert based on the response code or specific response data. It supports GET, HEAD, and POST requests. The sensor allows you to set custom headers and cookies for the request. Additionally, it can follow redirects (disabled by default) and alert if there are issues with the SSL certificate.

Alerts:

• Alert on Monitoring Sensor counter
• HTTP response code is not OK
• Server responded with error code
• Certificate expired
• Certificate is about to expire
• Certificate changed
• Certificate revoked
• Alert on SSL Certificate field conformance
• Connection Error
• Authentication Error

Performance Metrics:

• Basic HTTP.Sensor.Check Time
• Basic HTTP.Response/% Availability - Availability is 100% if HTTP responds, otherwise is 0%
• Basic HTTP.Response/Content Length - Response content length (bytes)
• Basic HTTP.Response/Length - Full HTTP response length in bytes (includes header size)
• Basic HTTP.Response/Time - HTTP response time (ms)

Report

By default, the sensor adds a report containing: % Availability, Response Time, and Content Length charts. These metrics will be collected and available as a report or through @trend-viewer

rest-http

REST HTTP

Similar to the Basic HTTP sensor, this sensor can send a single request and alert based on the response code or specific response data. Additionally, it can send any type of HTTP request, including custom requests, and easily add URL query parameters. It also allows setting custom headers and cookies for the request. Additionally, it can follow a redirect (the option is off by default) or alert if there is a problem with the SSL certificate.

Alerts:

• Alert on Monitoring Sensor counter
• HTTP response code is not OK
• Server responded with error code
• Certificate expired
• Certificate is about to expire
• Certificate changed
• Alert on SSL Certificate field check
• Connection Error
• Authentication Error

Performance Metrics:

• REST HTTP.Sensor.Check Time
• REST HTTP.Response/Content Length - Response content length (bytes)
• REST HTTP.Response/Length - Full HTTP response length in bytes (includes header size).
• REST HTTP.Response/Time - HTTP response time (ms)

The sensor enables the processing of any received data and converts it to counters and status objects using Data Parses.

HTTP/s File Sensor

Check remote file content and authentication parameters, monitor remote text logs, file size or change time, presence, and more. See Monitoring Files and Folders.

htmlhttphttpsrestsensorwebweb+pageweb+sensor

VMware Monitoring

See how to monitor virtual machines, datastores, hardware status, and the performance counters of host and guest VMs.

NetCrunch supports ESXi version 4 or newer. It can connect directly to the ESXi servers or through vSphere vCenter. In the case of vCenter failure or maintenance, it can switch to direct mode automatically.

NetCrunch comes with pre-configured Automatic Monitoring Packs to monitor ESX as soon as OS monitoring is set to ESX.

Monitoring Modes

vCenter

It requires adding a vCenter Sensor to a machine hosting a vCenter server. The sensor will automatically switch detected ESXi machines to vCenter mode. Features such as active alarms and configuration issues are available in vCenter mode only.

Direct

You should use this mode only if you do not run vCenter to manage your ESXi host or fall back when vCenter is not available. It requires specifying credentials per each ESXi server, which can be different than vCenter credentials.

ESXi View

The view gives you a comprehensive at the state of monitored ESX hosts.

ESXi/VM View

You can see all information about all monitored Virtual Machines per map and on the Atlas level.

ESXi System Views

Virtual Machines

StatusSystem ViewsVirtual Machines

For each ESXi machine, NetCrunch lists all virtual machines running on the given ESXi. You can add the virtual machine to the Atlas to be monitored. It's possible only if the machine is running, and it has an IP address assigned.

Datastores

StatusSystem ViewsDatastores

NetCrunch allows the monitoring of VMware data stores. You also see their properties in the node status window.

Hardware Status

StatusSystem ViewsHardware Status

NetCrunch tracks all hardware statuses provided by the ESX server.

Counters can be monitored by ESX or using the VM machine instance Counters.

Performance Counters

NetCrunch provides counters for both the host ESX system and guest VM.

You can set triggers on those values using Event Triggers for Counters.

Datastore - Counter Object

• % Free Space
• Capacity Bytes
• Free Space Bytes
• Host Count
• Uncommitted Space Bytes
• Virtual Machine Count

Summary - Counter Object

The object provides performance counters for a given ESX server.

• % CPU Usage
• % Memory Usage
• Disk IO rate Bytes per sec.
• Network Utilization Bytes per sec.
• Running VM Count
• Total VM Count
• Up Time
• Used CPU Hz
• Used Memory Bytes

Virtual Machine -Counter Object

The object provides performance counters for a given guest system (VM).

• % CPU Usage
• % Guest Memory Usage
• % Host Memory Usage
• Disk IO Rate Bytes per sec.
• Guest Used Memory Bytes
• Host Used Memory Bytes
• Network Utilization Bytes per sec.
• Used CPU Hz

Alerts

If you want to add alerts to the single ESX server, go to Settings Alerting & Notifications Monitoring Packs and Policies. You can add new or overwrite alert rules defined by ESX Monitoring Pack.

ESXI Alert Types

• Alert on ESXi Hardware Status change
• Alert on ESXi Alarm state
• Alert on Performance Counter Threshold

The other option is to modify ESX Monitoring Pack and then go to Monitoring > Monitoring Packs & Policies and edit the selected monitoring pack located in the VMware section.

Adding ESXi guests

Node SettingsMonitoringESXi

You may decide to add each guest system to NetCrunch automatically. Each guest will be automatically monitored according to the defined Automatic Monitoring Packs.

The option is disabled by default.

When the option is enabled, and you want to remove a VM guest from Atlas, you need to set a specific exclusion in the Network View. Otherwise, the machine will be added over and over again.

datastoreesxihardwarestatusvcentervirtualvmvmwarevspherevsphere-vcenter-server

Apache Web Server Monitoring

Monitor most popular Apache web servers.

Node SettingsAdd Monitoring SensorApache Web Server

NetCrunch allows the monitoring performance of Apache web servers. The Apache sensor allows you to monitor various performance metrics grouped in objects like Country, Summary, and Virtual Host.

Summary Counters

• Bytes Per Second
• Client Count
• Process Count
• Requests Per Second
• Total Requests
• Total Transfer
• Up Time

Country and Virtual Host Counters

• Avg CPU Time
• Avg Request Elapsed Time
• Avg Request Processing Time
• Client Count
• Max CPU Time
• Max Request Elapsed Time
• Max Request Processing Time
• Transfer

apachemonitorsensorweb server

Monitoring Mail Services

NetCrunch allows monitoring mail content, mailboxes, and checking basic mail server functionalities using a round trip email sensor.

Node SettingsAdd Monitoring Sensor

NetCrunch allows various aspects of email monitoring.

Supported Protocols

All email sensors support IMAP4/S and POP3/S.

mailbox

Monitoring Mailbox - Mailbox Sensor

This sensor allows for monitoring of mailbox authentication, activity, performance, and size. You can check if the mailbox is properly processed by checking the oldest email in the mailbox or receiving the last message. The sensor is operating on the mailbox owned by another user, so the sensor is not changing the mailbox's content.

Available alerts:

• Authentication Error
• Connection Error
• Protocol Error
• Mailbox Activity Events: (if the oldest message is older than..., no new messages received in last...)
• Alert on Monitoring Sensor Counter

Performance Counters:

• Mailbox.Sensor.Check Time
• Mailbox.Properties/Number of Messages
• Mailbox.Properties/Size of Largest Message
• Mailbox.Properties/Size of Messages

data-email

Monitoring Emails - Data Email Sensor

The sensor allows triggering alerts based on email sender, subject, or body. It can match emails using simple text patterns or using parsing expressions (i.e., regular expressions, scripts). The sensor can extract data from email content and turn them into performance metrics.

Available alerts:

• Authentication Error
• Connection Error
• Protocol Error
• Alert on Email Message
• Alert on Status Object Change
• Alert on Monitoring Sensor Counter

Performance Counters:

• Data Email.Sensor/Check Time
• Data Email.Sensor/Received Messages
• Data Email.Object

email-round-trip

Monitoring Mail Server - Email Round Trip Sensor

This sensor is intended to check the mail server functionality by sending and receiving test emails. It must use a dedicated mailbox, and it removes test emails from the mailbox automatically.

Available alerts:

• Email has not been received
• Email has not been sent
• Authentication Error
• Connection Error
• Protocol Error
• Alert on Monitoring Sensor Counter

Performance Counters:

• Email Round-Trip.Sensor/Check Time
• Email.Round-Trip.Email/Receiving Duration
• Email.Round-Trip.Email/Sending Duration
• Email.Round-Trip.Email/Total Duration

contentemailemail dataimap4mailboxpop3round tripsensorsmtptext

Sending Data to NetCrunch

Read how to send data to NetCrunch and create a custom monitor. You can easily turn any application or script into a NetCrunch agent.

Data Receiver Sensor

You can add the Data Receiver Sensor from the sensor list on any node. The configuration here is very minimal. It needs a name, and it automatically creates an API key for an external agent expected to send data to NetCrunch. The API key consists of the sensor name (without spaces) and node id number. For example, an API key can be JMX@1034, if we name our agent "JMX."

You can add multiple sensors on a single node for each application you need to monitor.

Data Format

The sensor can process data in various formats using specific data parsers. By default, it uses native NetCrunch JSON format, but you can easily create a custom parser.

Retention Time

Because NetCrunch does not know how often you will send data to it, you need to specify a "retention time" for data, after which it will expire and be cleared out of memory.

REST API

We wanted to keep the API for the sensor straightforward. The simplest tool you can use to send requests to NetCrunch is cUrl open source project, available for almost any platform. You can find it at curl.haxx.se

The API consists of only 5 requests:

Update

POST /api/rest/1/sensors/<api-key>/update

By default, sensor expects <NetCrunch JSON> data format. So, the request payload should be application/json content type

Example

 {
    "retain": 1,
    "counters": {
        "PBX/line status.0" : 1,
        "PBX/line status.1" : 0
     },
     "statuses":  {
       "AC"  : "On",
       "Power": "On"
     }
 }           

As you can see, you can send multiple statuses and counters in a single request.

Status Objects

Beside simple status values (key, value pairs), NetCrunch allows tracking of status objects. The status object can be described by the JSON object and can contain additional user data.

For example:

 {  
      "statuses" :  { 
           "Disk C:" : {
                          "value" : "ok",
                          "message" : "Working fine",
                          "retain" : 5,
                          "critical": true,
                          "data" : { 
                             "type" : "SDD", 
                             "upTimeSec" : 123431  
                          }
           }      
       }
    }

The status object can contain fields such as:

• value - a status value that can be any string, but if one of the standard values is used, NetCrunch will use the value for calculation alert conditions. The field is required to recognize the status object, otherwise, the whole object will be treated as a text string. Standard values are: ok, error, warning, disabled, unknown.

• name - the name of the object, it does not have to be unique. (optional)

• message - this can be a message describing the state (for example, error message). (optional)
• received - a time when the status has been read. (optional)
• retain - how long status will be valid if no new status is received after this status becomes unknown. The time is in minutes.

• data - custom data. It can be any JSON object, except if class points to one of the well-known classes, it must conform to the class data format.
• critical - when true the sensor status will reflect highest status of a given object

Sensor Status Calculation

When your object contains the "Critical" field, it will influence whole sensor status; otherwise, sensor status is based on active alerts state.

Any object set to "critical": true will set sensor status to the highest alert level (error or warning). If the object is non-critical ("critical": false), then the sensor is in error state only if all objects are in error state, and it is in warning state when any of its objects are in error or warning state.

Counter

GET /api/rest/1/sensors/<api-key>/counter?<parameter-list>

Example

 <nc-server-address>/api/rest/1/sensors/<api-key>/counter?Temp=65&Wind=4&@retain=5

Counter/inc Counter/dec

As NetCrunch stores counter values in memory, the agent can increment it without storing its actual value. The request will increase or decrease the counter by the given value.

Example

 <nc-server-addres>/api/rest/1/sensors/<api-key>/counter/inc?Door.Opened=1

Status

GET /api/rest/1/sensors/<api-key>/status?<parameter-list>

Example

 <nc-server-address>/api/rest/1/sensors/<api-key>/status?Door=Opened&@retain=5

Sending data to multiple nodes - shared URLs

By default, the data URL is pointing to a single sensor on a single node, but if you want to supply data to multiple nodes, you can use a shared URL. To do this, check Use the shared URL option in the sensor configuration.

Now your data should be in the form of a JSON array, and each sensor object has to contain node identification, which is node DNS name or IP address depending on node Identification Type.

For example:

Example

[ 
 {
    "node": "192.168.10.1"
     "statuses":  {
       "AC"  : "On",
       "Power": "On"
     }
 } ,
 {
    "node": "test.lab"
     "statuses":  {
       "AC"  : "Off",
       "Power": "Off"
     }
 }                     
 ]

Web Messages

You can easily send event messages to NetCrunch using an HTTP request. The program accepts POST and GET requests.

Service URL

 http://<nc-server>/api/rest/1/event/<node-identification>

Node identification is a node IP address or DNS name.

Find more information below.

agentapidatadata receiverdata sensorgenericjsonmonitorobjectrestsensorstatus

NetCrunch Self Monitor

Read about how NetCrunch monitors itself.

NetCrunch Server is like any complex application with multiple processes, lots of data processing, and high demand for storage. In fact, NetCrunch has multiple logs and monitors thousands of parameters.

These parameters are essential when diagnosing potential performance problems. Be aware: the program is always limited to the hardware capabilities it's running on.

So, NetCrunch Self Monitor is the monitor that watches the NetCrunch Server.

Some programs merely hide problems, which is troublesome, mainly because it creates the illusion that something is working when in actuality, it's not. It's hard to detect and impossible to solve when there is no visible problem. Most problems are caused by overloading - NetCrunch Server overloading or monitored device overloading. Many Cisco devices have protection against too many monitoring requests sent to the device. In many cases, the solution is simple: increasing monitoring time or timeouts.

The status of the NetCrunch server is available on the NetCrunch Server Status dashboard.

Alerts

Settings Alerting & Notifications Monitoring Packs and Policies Global NetCrunch Self Monitor

The global monitoring pack contains default alerting settings for this monitor, and they trigger Default action.

NetCrunch alerts on:

• (Critical) SNMP monitoring heavily overloaded
• (Warning) SNMP monitoring overloaded
• (Warning) Network Services monitoring overloaded
• (Critical) Database overloaded. Some events have been dropped
• (Warning) Writing to the database is slow
• (Critical) Low disk space (< 512MB). Please free up some space on the NetCrunch data disk.
• (Warning) Low disk space (< 1GB. Please free up some space on the NetCrunch data disk.
• (Critical) The system is low on memory (< 512MB)
• (Critical) Virtual memory for NetCrunch Server fragmented. Performance might be negatively affected. A machine restart is required.
• (Warning) Physical Segments not refreshed on time
• (Warning) Database size is close to maximum capacity
• (Warning) System is running for too long
• (Warning) Server handle usage too high
• (Warning) Atlas backup had been executed more than two days ago
• (Critical) the Last backup failed
• (Warning) Limit of licensed nodes nearly reached
• (Critical) NetCrunch license is about to expire
• (Warning) New NetCrunch version available
• (Warning) NetCrunch maintenance subscription is about to expire
• (Critical) NetCrunch trial period is about to expire

SQL Query Sensors

SQL sensors allow for measuring connectivity, query execution, and result data processing as metrics or statuses. Supported databases: Oracle, SQL Server, PostgreSQL, MySQL, MariaDB, ODBC.

Supported Databases

ODBC

NetCrunch supports ODBC sources and several native drivers. It requires x64 ODBC drivers to be installed. Please remember that you must use System DSN because NetCrunch runs as a service process and can't access your User DSNs.

SQL Server

To use the SQL Query Sensor in NetCrunch, install ODBC Driver 18 for SQL Server on the NetCrunch server. This ensures compatibility with SQL Server 2008 and later, including SQL Azure.

Oracle

The program supports Oracle 11 up to 23, depending on the drivers you install. OCI v19 is the latest driver supported, but it will work with newer databases.

Installing Oracle Instant Client drivers

1. Go to Oracle.com and search for Instant client windows x64.
2. Download basic client x64.
3. Extract the contents to \external\Requesters or other folders, but you must add the path to the system Path variable.
4. Restart the NetCrunch Server service.

PostgreSQL

The latest driver is installed with NetCrunch. No further installation is needed.

MySQL, MariaDB

The latest driver is installed with NetCrunch. No further installation is needed.

Managing Database Connections

Each sensor allows the creation of connection profiles. If you do not save the profile, it's named ** Custom** and saved only for a given node.

If you saved the connection profile, you could reuse it for multiple SQL sensors, even on another node, if they use the same settings. You can edit the profile from the sensor setting, but to save changes, you have to save it and override the previous profile settings. Otherwise, the profile will automatically become Custom.

You can also manage database profiles in the Credential Manager. Settings Monitoring Main Monitoring Credentials Manager Database connection

Checking if the sensor can connect to a database

OK. You set the credentials, and now it is time to connect. Select the database selection button, and you should see the list of databases or get an error message.

sql-query$object

SQL Query:Object

It allows executing a query returning a single row. It can also be used with an empty query to check database authentication and connectivity. The row can represent an object, and the columns can represent object properties. The sensor allows setting an alert on the status of object properties.

1. Select a connection or create a new one with proper database credentials.
2. Select the database from the list.

You can keep your query empty. Then, the sensor will only connect to the given database, and its status will reflect database connectivity.

When you write your SQL query query, ensure it will return a single data row. This row of data can now be used to monitor status change values.

You can test your sensor query by clicking the test icon at the window's top right corner.

Predefined alerts:

• Authentication error
• Connection error
• Empty result set
• Query execution error

sql-query$data

SQL Query:Data

Allows executing a query returning multiple rows. Columns can be used as a source for metrics. The metrics enable threshold alerts to be triggered and used for reporting.

1. Select a connection or create a new one with proper database credentials.
2. Select the database from the list.
3. Enter the SQL query query.
4. Select the Instance Column to identify rows in the table.

Now, you can add counters and set thresholds.

Example

Let's try grouping table elements by name and counting them. This way, we can create a single counter; the instance is the name.

   SELECT COUNT(*) AS Count, Name FROM MyTable GROUP BY Name

In this case, we have a single metric, Count, and the Name column will be the instance column.

No Database option

Some queries aren't directly related to any database. The 'No Database' option allows for selecting multiple databases and data related to them in queries.

Example

   SELECT      sys.databases.name,
       CONVERT(int,SUM(size)*8/1024) AS [Total disk space]
   FROM        sys.databases
   JOIN        sys.master_files
   ON          sys.databases.database_id=sys.master_files.database_id
   where sys.databases.database_id > 4
   GROUP BY    sys.databases.name
   ORDER BY    sys.databases.name

Remarks

SQL sensors require being configured with the actual database connection. The query needs to be executed to select counters and status objects properly. - Only columns of numerical types can be used for counters. Use the CAST expression (or CONVERT in T-SQL) and alias name to cast the text column into numerical type. - Maximum number of returned values is 1000 - Default Request timeout is 15000 (15 seconds)

databasemariadbmicrosoftmysqlodbcoraclepostgresqlsqlsql server

IP Camera Sensor

HTTP/S, ONVIF

NetCrunch's IP Camera Sensor efficiently monitors your camera systems, capturing snapshot images to verify connectivity. These images are displayed in the node status window and can also be integrated into network maps using the Snapshot Image widget for enhanced visual monitoring.

Predefined Alerts

The sensor is equipped with essential alerts to maintain the security and functionality of your camera system:

• Connection Error
  Triggered when the sensor fails to connect to the camera.
• Authentication Error
  Notifies you in case of issues with camera authentication.

Image-Related Alerts

These alerts are specifically designed to monitor changes or anomalies in camera images:

• Alert if Camera Image Differs from Reference
  This alert is raised when the current image differs from a predefined reference image. The sensitivity can be adjusted:
  • Low: Suitable for areas with varying lighting, such as rooms with windows.
  • Medium
  • High: Best for areas where lighting remains constant.
• Alert if Camera Image May Be Tampered
  Triggered when the image appears obscured or covered, indicating potential tampering.
• Alert if Camera Image Has Changed
  Raised when any change is detected in the image, depending on the sensor’s monitoring interval.
• Alert on Motion Detection
  Activated when differences between the current and previous images suggest motion, deactivating when the image stabilizes.

Adding Snapshot Image Widget to a Graphical Data View

Integrate real-time camera snapshots into your network maps by following these steps:

1. Edit View.
2. Add Camera Snapshot Widget.
3. Select your preferred Image Source from the dropdown menu in the Data tab.

iNodes Sensor

The sensor monitors usage of iNodes on Linux machines

The inode is a data structure in a Unix-style file system that describes a filesystem object such as a file or a directory. Each iNode stores the attributes and disk block location(s) of the object's data.

On many types of file system implementations, the maximum number of inodes is fixed at file system creation, limiting the maximum number of files the file system can hold.

Performance Counters:

• Inodes % Free
• Inodes Available
• Inodes Free
• Inodes Used

Default Alerts:

• % Free iNodes is less than 10%

Monitoring

This sensor requires standard access. (used by Linux monitor)

inodes

Docker Container Sensor

The sensor monitors basic statistics of the Docker container

The sensor uses Docker Engine REST API to communicate with the container.

Performance Counters:

• % CPU Usage
• % Memory Usage
• Interface bytes IN
• Interface bytes OUT

Statuses:

• State
• Uptime

Default Alerts:

• The container is not running - Alert generated when NetCrunch detects the container is not in the 'running' state.

Monitoring

To monitor the Docker container, you have to enable remote API.

To enable remote API:

• Open /lib/system/system/docker.service file with any text editor

  vi /lib/systemd/system/docker.service
  

• Find the line which starts with ExecStart and add -H=tcp://0.0.0.0:2375

  ExecStart=/usr/bin/dockerd -H tcp://0.0.0.0:2375 -H unix:///var/run/docker.sock
  

• Save the Modified File

• Reload the docker daemon

  systemctl daemon-reload
  

• Restart the container

  sudo service docker restart
  

• Open a port on the firewall if necessary.

• To test that API is accessible, try to run test on the docker sensor, make sure you added that sensor to the proper node (just configured one)

containerdockerrestsensor

Monitoring VoIP/SIP Services

The sensor checks connectivity and validates the response of SIP service

Basic SIP Sensor

This Basic SIP sensor is configured to monitor connectivity or session initiation with SIP Server (SIP Phone System). Monitored are an error code and response time for "OPTIONS" or "INVITE" request only. In addition to the error code, the sensor returns a description of each error. The sensor supports SIP platform services such as FreeSWITCH, Asterisk, OnSIP, FreeSWITCH Legacy, Asterisk Legacy.

Counters

• Response time

Alerts

• Invalid response
• Connection error

sensorsipvoip

DICOM C-Echo Sensor

The Sensor checks connectivity and validates response from DICOM capable system

The C-ECHO DICOM sensor monitors the availability of DICOM capable by sending a C-ECHO request. In fact, this very similar to what does regular Ping, so it's also called often DICOM Ping. The sensor verifies the DICOM handshake protocol and checks if the target system is properly answering DICOM messages.

Parameters

Calling EA Title

Calling AE Title- The Application Entity (AE) that initiates the DICOM messaging service request. It is based on the Source DICOM Application Name. This parameter identifies the Application Entity (AE) that shall contain the requestor of the A-ASSOCIATE service. It is based on the Source DICOM Application Name.

Called EA Title

Called AE Title- The Application Entity (AE) that is the intended acceptor of the service request. It is based on the Destination DICOM Application Name. This parameter identifies the Application Entity that shall contain the intended acceptor of the A-ASSOCIATE service. It is based on the Destination DICOM Application Name.

Counters:

• Response time

Alerts:

• Alert on association rejected
• Invalid response
• Connection error

dicomdicom-echoecho

Scripting Sensors

Netcrunch delivers hundreds of monitoring facilities such as monitoring packs and sensors, but we want you to be not limited to them. Script sensors are essentials in filling any gaps in delivering monitoring data to NetCrunch.

Unlike other systems, we do not force you to deliver data in one native data format, because there are thousands of scripts written for open source systems already. We want these scripts to be adaptable to NetCrunch, and this is the role of Data Parsers that are responsible for translating data returned by an external script to NetCrunch native format.

remote-ssh-script

Remote SSH Script Sensor

The Remote SSH Script Sensor in NetCrunch allows for the execution of scripts on remote machines via SSH, providing a powerful tool for remote system management and data collection.

Overview

This sensor is designed to remotely execute a script that is located on a target system. It utilizes an SSH connection to securely run the script, making it an ideal choice for managing and monitoring servers, network devices, and other systems in a secure and efficient manner.

Sensor Settings

Configuring the Remote SSH Script Sensor involves several key settings:

• SSH Connection and Credentials
  Specify the details of the SSH connection, including the server address, port, and the necessary credentials (username and password or SSH key) for authentication.
• Script Path
  Define the exact path to the script on the remote system. Ensure the script is accessible and executable by the user provided in the SSH credentials.
• Execution Timeout
  Set a timeout period for the script execution. This prevents the script from running indefinitely and helps in managing resources effectively.
• Optional Script Parameters
  Enhance the flexibility of the script execution by adding parameters. These can be static values or dynamically mapped from node properties. To configure these parameters, refer to the script configuration window under 'Script Sensor' for comprehensive guidance.

Default Alerts

NetCrunch provides several pre-configured alerts for common issues that might arise during the sensor's operation:

• Connection Error
  Triggered when the SSH connection to the remote machine fails.
• Authentication Error
  Occurs if there are issues with SSH credentials or permissions.
• Script Execution Error
  Alerts when the script fails to execute within the specified timeout or due to other errors during execution.

Available Alerts

Beyond the default alerts, NetCrunch offers additional alerting options to provide more granular monitoring:

• Monitoring Sensor Counter Alert
  Get notified when specific sensor counters exceed predefined thresholds.
• Status Change Event Alert
  Trigger an alert when there's a change in object status, as determined by the Data Parser's output.