Working with Grids
Nodes, Monitors, Active Alerts and Alert History are the same grid with different data in it. Columns, filtering, grouping and CSV export work identically in all of them, in both consoles.
Learning the grid once is worth more than learning four screens. Everything below applies wherever a grid appears.
Choosing Columns
Grid header menu Customize
Each grid ships with a sensible default set and offers far more — the Nodes grid alone has upwards of eighty, from hardware inventory to interface and virtualization detail. Show the ones your work needs and hide the rest.
Column choice is not cosmetic. It decides what filtering is available and what a CSV export contains, both described below.
Filtering
Each column filters itself. Open the filter from the column header and you get every value present in that column, each with the number of rows carrying it, so you can see the shape of the data before narrowing it.
For a column with many distinct values, type in the filter box to search the list rather than scrolling it.
Select any number of values. Filters on different columns combine, so a grid can be narrowed by status and by monitoring probe and by tag at once.
Excluding Instead of Including
Every filter can be inverted. Tick Exclude Selected and the grid shows only the rows that do not carry the selected values.
This is often the shorter question. "Everything except OK" is one click; selecting the other five statuses is five, and it silently goes wrong the day a sixth is added.
More Than One Attribute Per Column
Some columns filter on more than one property. The service column, for instance, filters both by protocol and by service status, presented as separate groups in the same popup — so "HTTP services that are down" is one filter rather than two.
Hiding a Column Suspends Its Filter
A filter only applies while its column is visible. Hiding a column does not discard its filter — it stops applying it, and the filter comes back when the column comes back.
This is deliberate: the grid is never filtered by a column you cannot see, so the rows on screen always agree with the filters on screen. It also means hiding a column can increase the number of rows shown, which is surprising the first time.
Grouping
Drag a column header onto the group panel above the grid, or use Group By from the header menu. Group by a second column to nest.
Expand all and Collapse all work on the whole grid, which makes grouping a fast way to count things: collapse everything and read the group headers.
A row can appear under more than one group. Grouping interfaces by VLAN puts an interface carrying three VLANs under all three headings, rather than forcing it into one.
Most grids cannot do this, so the row count of a grouped grid may legitimately exceed the number of records.
Hiding the group panel does not ungroup. The panel's close button hides the panel and leaves the grouping applied. To return to a flat grid use Ungroup.
grid-csv-export
Export to CSV
Grid header menu Export to CSV
The rule worth remembering is that the file matches the screen:
- only rows that pass the current filters are written — narrow the grid first, and the export is already the report
- only the visible columns, in the order they are displayed — hide and reorder columns to shape the file
- grouping is flattened; member rows are written, group headers are not
- values are exported as displayed, not as stored — a status reads
OK, a device type reads its name, a duration reads the way the grid shows it
The file is named after the view and the grid it came from, and downloads through the browser.
Dates and numbers are written the way your locale displays them, not in a neutral format. That is what makes the file readable, but check the separator settings when importing into a spreadsheet configured for a different locale.
Because the export follows the filters, the useful workflow is the obvious one: build the question in the grid, confirm the answer on screen, then export it. There is no separate report to configure, and no risk of the file disagreeing with what you checked.
- Migrating from PRTG
NetCrunch can read an existing PRTG installation and rebuild its devices and monitoring in the NetCrunch atlas, so a migration starts from your real environment rather than an empty one.
- Alert and Report Management
Read about scheduling reports, the difference between an event and an alert, Monitoring Packs, and message formats.
- Customizing NetCrunch Reports
Read about what custom reports you can create and how they can be done.
- 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.
- Alert Views
Active Alerts is one of the essential views showing current unresolved issues. NetCrunch tracks the state and correlates all internal events. When defining alerts for external events (SNMP, syslog, etc.), you can easily correlate by defining events that can close the alert.
- Getting Started
Learn how to create a NetCrunch API key and use it with both REST API and MCP Server access channels.
- Monitoring Packs
NetCrunch Monitoring Packs allow efficient management of monitoring settings. You can use them to create monitoring policies by setting node filters. They can also be assigned manually to the node (or multiple nodes using multiselection). Currently, the program includes more than 270 ready-to-use Monitoring Packs for monitoring devices, applications, and operating systems.
- Options: General