Monitoring Dependencies

NetCrunch simplifies the task of monitoring by automatically determining device dependencies based on how your devices are connected to your network, eliminating the need to manually build device hierarchies to manage alerts. One of the biggest challenges of monitoring is how to make sense of it all: Firewall, switches, servers, virtualization, clients. Add wide-area networks, along with cloud services and you basically have one of the more daunting philosophical challenges in IT. NetCrunch seeks to make this easier by understanding how your devices are connected to your network.

Most networks leverage a hub-spoke topology. Business critical resources and key services and applications are concentrated in a central location. This facilitates a shortest-path approach and eliminates the need to daisy chain networks to provide access, as seen in peer-to-peer topologies. In other words, if you have 2 branch locations, you would choose to connect both locations directly to the home office (hub-spoke) rather than connecting the 2 branches together, then servicing both through a single connection (peer-to-peer). While in certain cases this is unavoidable, inherent in peer-to-peer topologies is the creation of dependencies. These relationships and risks exist in your network.

By interpreting your network and device topology, we have distilled the choices of how to monitor your network down to one simple decision: Where should I place my monitoring server? The answer is simple: In the middle, and NetCrunch figure it out.

Dependencies: Network Topology vs Monitoring Topology

NetCrunch uses SNMP, supplemented with data from your VMware servers (if present) to build both the Physical Segments view and Monitoring dependencies. While your Physical Segments view focuses on network topology and how devices are connected to switches, Monitoring Dependencies interprets network topology relative to the NetCrunch server.

Monitoring Dependencies: How to use

Upon install, monitoring dependencies are configured as one-to-one. In other words, NetCrunch will assume that you wish to monitor the availability of each device individually, and receive alerts regardless of how they are connected. This is desirable if your NetCrunch use-case does not include your network or VMware virtualized infrastructure. To leverage the full capabilities of our ability to determine connectivity and topology relationships relative to the NetCrunch server, SNMP access to switches and routers, as well as VMware API access is required.

NetCrunch allows you to use 2 methods for managing device dependencies, which ultimately dictates how you will receive alerts from cascading (peer-to-peer) device relationships. Automatic dependency calculation is the best and easiest approach to managing what is typically a challenging element of your monitoring strategy,

• Automatic dependency calculation
  • Uses SNMP, VMware API
  • Must be manually refreshed after the initial loading of Atlas and a refreshed with major changes
  • Dependency setting can be managed and changed at a device level.
  • Dependency settings, including device level, can be reset by rescanning
• Manual dependency setting
  • User determined dependencies based on business logic

By routinely rescanning your device dependencies, NetCrunch will stay ontop of how you devices are connected, allowing you to focus on the challenges of IT, rather than wrestling your monitoring solution.

dependenciesdependencymonioring dependencies