Alert and Report Management

Read about scheduling reports, the difference between an event and an 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 a data collector to specific Monitoring Packs or nodes. To create a report, select one of the predefined Report Scheduling Schemes (or define a new one) and specify the user or group that 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 becomes an alert containing a log of the operations performed 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, primarily to track well-known object states such as Windows Services, Network Services, and Nodes.

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 can't differentiate actions, messages, or severities.

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 a single node or for 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 specified operating system type and some additional conditions.

Example:

NetCrunch adds Active Directory monitoring pack settings to the node if

Operating System is equal to Windows Server and,

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

Each Automatic Monitoring Pack includes an Exclusion List that specifies nodes to exclude 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 automatically be monitored across 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 a time window during which all events must be triggered.
• Physical Segments - This automatic monitoring pack applies to all nodes connected to a switch. It contains alert rules for changes to the node's physical linkage.

Overriding Monitoring Pack settings

When you add Monitoring Packs to the node (or if they're added automatically), the node settings are a sum of the 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 by 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 that allow it to be executed only under certain conditions, such as alerts within a specific time range. A node can only be a member of a given Atlas View or alert if it has 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 comes from various external sources, such as Syslog, SNMP traps, Windows Event Log, and 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 to identify the problem.

Another application of Message Formats is passing parameters to various external actions, such as executing a program or writing event data to a file.

Internally, NetCrunch uses XML to represent events. 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 to it. 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 event class.

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