Network Monitoring Software: Architecture Considerations

The enterprise IT environment is continuing to experience significant changes. An organization’s network monitoring software solution has to be capable of supporting future requirements, whether it is growth in the volume of monitored components, new custom applications/devices that need to be monitored, or different use models. If you are in the midst of considering an upgrade from your open-source or point monitoring tools, or replacing an inflexible legacy solution, make sure whatever solution you are evaluating is scalable, open and extensible to ensure that it is future-proof.

A key limitation of traditional network management systems is the existence of a centralized database for processing of performance data. Even if the collection of data is managed by distributed components, the solutions invariably require centralization of the data for processing and alert generation. For large infrastructures, this introduces a significant performance bottleneck. The multiplier effect of the amount of data that needs to be processed as new devices are added is enormous.

Capturing and processing these metrics in a single centralized database will put immense pressure on the overall application, creating a significant bottleneck. A key consideration in a replacement solution is whether it is based on a distributed architecture that does not have centralized database bottlenecks. For example, some solutions will have both distributed collection capability and a distributed database architecture. In these solutions, individual data gathering components will often have small local databases that are able to process tens of thousands of metrics every few minutes to generate alarms as needed, and also store the data locally for multiple years. Monitoring consoles receive notifications as they occur, and are able to retrieve performance data from these separate databases when needed for analysis and reporting. No sophisticated database scaling or specialized database administration expertise is required for these systems.

A next generation network performance monitoring software system also has to support different points of integration depending on the stage of the service management lifecycle, whether it be configuration of devices and tests, establishing user privileges, capturing performance data from custom applications/systems, initiating actions/notifications in external ticketing systems, or displaying performance data on external portals. In many modern data center environments, the monitoring software has to be capable of accepting performance data feeds from custom applications. This could also include processing syslogs and event logs generated by applications. Certain events generated by the network monitoring system may require initiating an action or process in some external system (e.g. ticketing).

All of these requirements need to be supported via flexible, open APIs and plug-in frameworks within the monitoring system. Make sure your replacement solution exposes a rich set of two-way APIs and open extensibility for integrating with existing systems or technology. The API and external feeds need to provide interface points to either import or export data throughout the IT environment. Ensure that the API supports standard technology, such as Web Services, Java, Perl and C, and allows provisioning and updating users, devices and tests (see solution example).

In summary, comprehensive monitoring functionality in and of itself is not sufficient. You need to make sure that whatever solution you select adheres to the basic architecture tenants of scalability, availability, openness, flexibility and extensibility (see complete list of key requirements). It is a dynamic IT environment around us. Make sure your network monitoring software system can keep up as you move forward.