Automatic Transfer

OCS Inventory NG (Next Generation)  [1] is an inventory system that gathers information about hardware and software running on your network. OCS uses an SNMP-based discovery mechanism to inventory network components. The agent collects information about:

• logical drives and partitions,
• operating systems running on network hosts,
• installed programs, and
• connected monitors.

It also stores the collected data in a MySQL database. You can configure OCS to organize and categorize the inventory data for a quick overview of network information.

OCS was developed by a French team using Perl and PHP and is released under the GPLv2. The project is supported by FactorFX, which offers commercial support and training.

One really interesting feature of OCS is its support for SOAP web messaging services, which makes the OCS inventory data available to other applications and thus leads to some very useful automation scenarios. In this article, we describe how to channel OCS inventory data to the OpenNMS network monitoring tool. Combining OCS with OpenNMS means you can automatically monitor the devices in the OCS inventory and even send failure notifications if a device on the network is misbehaving.

OCS

OCS uses a software agent that is available for the Linux, Unix, Windows, OS X, and Android operating systems. You can download the OCS server, agents, plugins, and tools from the project website [2]. The OCS project documentation [3] and forum  [4] will help you get started installing and configuring OCS.

OpenNMS

The OpenNMS network management platform [5] was predominantly developed in Java and is released under the GPLv3+. In the project, there is no distinction between the free community and the proprietary enterprise version. OpenNMS Group Inc. provides commercial training, support, and development.

The application focuses on error and performance monitoring. As a platform, an extensive provisioning system is available that can integrate various external data sources. In OpenNMS, these tasks are handled by the provisiond process. For example, DNS zones and virtual machines from VMware vCenter can be automatically monitored and synchronized.

HTTP is used to transfer the XML format data to OpenNMS. You have several ways of assigning monitors, for example, for HTTP, SMTP, IMAP, and JDBC. Either service detectors automatically discover these services or they can be assigned manually. A mixture of the two variants is also possible. Policies can be used to categorize systems automatically or to specify the network interfaces from which to capture performance data. To support use in larger environments, OpenNMS was built on an event-based architecture.

Creating Connections

If you use OCS, you have access to extensive information on server systems in a central inventory, which would also be very useful for monitoring. Models or serial numbers identified by the OCS agents can deliver helpful information in a message to the OpenNMS Administrator in the event of a failure. OCS also frequently covers systems that are not relevant for monitoring, such as workstations or systems that are still in the development environment.

If you want to manage systems with OCS and automatically transfer the data for OpenNMS-based monitoring, a setup like the one outlined in Figure 1 is a good idea.

Figure 1: Scenario for integrating OCS inventory and OpenNMS.

Installation of the OCS agents ensures that OCS actually sees the systems to be monitored later on. New server systems are provisioned in the special development environment. In this example, systems in the environment are uninteresting for monitoring in OpenNMS and are simply listed in the OCS inventory. Before server systems go into production, you need to test them in a staging environment. If there are any problems, the development team is informed. Messages about malfunctions affecting systems from the production environment are routed to the Network Operation Center. Monitoring is only interested in the systems in staging and production.

To show how monitoring profiles can be implemented for a specific server, the example distinguishes between mail, web, and database servers. It assumes that the stable version 1.12.3 of OpenNMS [6] is installed, along with OCS version 2.1RC1 [7] on a CentOS 6.5 server.