Automating NetCrunch Setup

NetCrunch contains many time and effort saving features that seek to either minimize the requirements for excessive maintenance or configuration of your monitoring system. This article will focus on these time-saving features, how to configure and leverage them. As a monitoring system, NetCrunch is designed to provide a low-maintenance, self-sustaining IT infrastructure monitoring solution without the need for continued and on-going configuration or scope adjustment,

Discovery of Devices

Finding your important devices and knowing where to look for them is accomplished in 2 phases: Initial setup, and on-going Scheduled Discovery. During Initial Setup, you have the ability to perform simple and bulk one-time device discovery actions such as adding one node. Persistent device discovery is accomplished by configuration of a Network entry in the IP Networks View of the NetCrunch Atlas. Not only will this serve in the processes of initial device discovery, but encapsulates the scope and configuration of ongoing device discovery.

There are 4 distinct methods for populating devices in NetCrunch. 3 single-use or bulk, and 1 persistent:

• Add Single IP Node - single-use
• Import from Active Directory (Windows Domain) - single-use or bulk
• Import from file (parse CSV or hosts file) - single-use or bulk
• Scan IP Network - persistent

By configuring specific IP Network entries, NetCrunch provides a framework for describing both the initial scope for device discovery as well as the persistent and ongoing discovery behavior required for self-maintenance. Simply designate an IP range (starting IP/mask), device filter and auto discovery schedule. NetCrunch will both find your devices as well as watch for new devices automatically. Device discovery exceptions are also enumerated in the IP Network element.

Discovery of Services

While finding a device is a great first step, NetCrunch seeks to understand the value of a device in your infrastructure portfolio, This is partially accomplished by identifying what services a device is providing an understanding if that service has a role in your overall Business Continuity Strategy.

Once a device is initially discovered, NetCrunch will evaluate the device's services against a list of user designated Auto Discovered Services. This list consists of key IT services (DNS, LDAP, SQL Server, etc...) that is used to determine device availability beyond a simple ping and is a foundation feature that separates NetCrunch from other solutions in the Network Monitoring System space. Once services are discovered, NetCrunch will natively hand-shake with each using a protocol-specific request/response method. You now have the ability to monitor for fundamental symptoms and ultimately the experience of IT issues: Service-specific Up or Down, Fast or Slow.

Device Types and Meta Data

NetCrunch has the ability to perceive and characterize devices into 2 broad categories: OS specific and SNMP. This provides a simple framework for building and maintaining the necessary meta-data of your monitored device portfolio and is the foundation of NetCrunch's ability to support high levels of automation via comprehensive device characterization. This is the last piece of the automation puzzle and is the final (transparent) action taken to enable all subsequent automatic actions in NetCrunch. With proper credentials for OS and/or SNMP, NetCrunch harvests comprehensive and device specific meta-data which is then used to drive policy-based monitoring methods and strategies.

For SNMP devices, NetCrunch uses the Device Type Manager to characterize and supplement the NetCrunch metadata system. An extensive list of known devices is provided, along with the following data used to describe the device for automatic monitoring pack assignment or other policy-based actions:

• Device Class: Server, switch, router, etc...
• Manufacturer: Cisco, Brocade, F5, etc...
• Model: ASA5520, Big IP, etc..
• sysObjectID: SNMP oid
• Text Description
• Representative Icon

Device type association is performed during initial device discovery only. It is a best practice to confirm all SNMP device types during your trial evaluation and supplement the Device Type Manager as you may require. Device type association can be easily changed in the Properties tab of the Node Settings.

Automated Monitoring Strategies

Let's take quick stock of where we are, and what NetCrunch now knows:

• Where a device is, and where to look
• What the device does by hand-shaking with its critical services
• What kind of device it is, and it's describing meta-data

NetCrunch is now positioned to effectively complete an agentless monitoring strategy as described in the various Monitoring Packs that are now applied automatically. Automatic monitoring pack assignment represents the final stage in device discovery and is the policy element that describes metrics or statuses for alerting or trend analysis. Each automatic Monitoring Pack uses a meta-data driven filter definition that acts as a description language for device association. Any changes made to automatic Monitoring Packs will be reflected automatically to all device members. Manual Monitoring Packs are also available, but require user interaction for correct assignment.

Monitoring strategies can be applied automatically via meta-data driven filters on Monitoring packs, or they can also be applied via:

• IP Network: provide network location (IP Network) based monitoring strategies
• Custom Views: Abstracts monitoring strategies based Custom View membership

The use case might be to add event log monitoring to SQL instances on developer machines. In this case, a Dynamic Custom view targeting (filtering) Windows Workstations running the SQL Server service would not only configure this correctly for all current developers but also cover any new SQL developer machines that might be discovered.

Sensor Templates

Device level sensor configurations and deployment can also be streamlined thru the use of Node templates, which allow the user to copy some or all of a device's monitoring strategy, as reflected in the device node settings. The main value of templates is that they can include individually configured sensors. Similar devices can be multi-selected and a Node Template applied via Node Settings.

Layer 2 Topologies

By simply enabling the Physical Segments View, NetCrunch will then automatically and routinely collect MAC addresses, STP, RSTP, and CDP data from your switches. You will then receive both a comprehensive layer 2 overviews of your monitored switching portfolio, as well as drill down, port level visibility of your individual network segments. These views can be updated manually as required, and have a default refresh rate of 15 minutes. If your topology is fairly stable, this can be adjusted to every 30 minutes or hourly to reduce LAN/WAN traffic.

Automatic Monitoring Dependencies

NetCrunch has the ability to deduce device monitoring dependencies once the following criteria have been met:

• The Network Atlas is populated with devices: servers, switches, routers, etc...
• Physical Segments is enabled with valid SNMP credentials
• VMware infrastructure hosts with valid API credentials

By combining monitored device inventory from the Network Atlas with switch device connection data (MAC address tables) and VMware host and guest inventory, NetCrunch will process and populate device level monitoring dependencies. This effectively reduces cascading alerts which can flood users with notifications and generate needless alerting events. This feature is manually invoked and is best performed once NetCrunch ha been fully populated.

Automated Views

Leveraging the comprehensive device meta-data and node-based policy filters, NetCrunch provides a convenient set of Custom Views that organize and arrange logical groups of devices according to a variety of intelligent classifications:

• Device Type
• Device Role
• Operating System
• Network Location
• Custom ( Meta Data ) filter views

These Custom views or Meta data driven filtered views are available in 2 types:

• View: Simple custom View using a bulk node selection using meta-data (dynamic), or manually assigned membership
• Folder: A custom view with automatic sub-views using metadata summary fields

netcrunch setupsetup