Observium is more than a monitoring system

Network monitoring with intuition

For a long time I am a reader of Habr, but to write an article made me want to answer questions and, probably, first-hand dialogue. I apologize for the possible confusion of the article - "Chukchi is not a writer."

On Habré there are already several articles devoted to this system ( “Monitoring Cisco network equipment in the Observium system” , “Observium - installing a monitoring system” ) and I would like to supplement them. There are no installation or configuration instructions in the article, all of this is in the official documentation and at the links above.

The article has many pictures, some are hidden under the spoilers.

Observium, as the slogan on the main site says, is a system for monitoring and monitoring network devices and servers. Moreover, the list of supported devices is huge and is not limited only to network devices, the main condition is that the device supports SNMP. But besides SNMP, the collected information can be supplemented by other methods and protocols, for example, syslog, rancid, unix-agent.

A bit of history. Initially, the system was created by “a subject of His Majesty” Adam Armstrong around 2005-2006 (unfortunately, he himself does not remember the exact date). Later, developers joined the project, including your humble servant. At first, the system was called Kikker (2005-2006), then Project Observer (2006–2008), ObserverNMS (2008–2010), and finally in 2010 it acquired the current name Observium. The main logo is an industrial-looking hamster.


The main goal of the creation was to create a system with the simplest control and monitoring of devices, which remains to this day.

The distribution model of the system is divided into Community (released every 6 months) and Subscription (available to subscribers through continuous stable / rolling updates).

Many people are familiar with systems such as cacti, prtg, mrtg, but none of them can be compared in terms of the convenience of adding devices and the number of sensors supported (by default).

How the process of adding a new device to the system looks like:

1. Add the device name (on the command line or web interface).
2. We wait 5-10 minutes until the discovery processes and the first poller are completed, that's all.

In practice, to add a new device, the default settings are enough, you only need to specify authorization parameters, but they can also be added to the general configuration and the system will automatically check all the specified authorization parameters.
Adding a device, see under the spoiler
Adding a new device:

Adding a device

A device has been added, we are waiting for the discovery / poller to complete:

Device added

Device Overview:

Linux device

In addition, adding new devices is possible in an automated mode from a file with a list of devices and / or through device discovery via CDP / LLDP and BGP / OSPF protocols.

After the device has been added to the system, its entire "life" cycle will be monitored automatically. For example, if the memory is increased or a new sensor is added or a port is added / removed, this will all be detected without manual intervention.

The entire collection of statistics is divided into 2 main processes:
  • discovery , where the basic detection of sensors or counters supported on this device is performed;
  • poller , where detected sensors are polled every 5 minutes;

There are also 2 additional processes that work together with the poller process, but they only go in the version for subscribers:
  • bill , calculation of billing information on individual ports for users;
  • alert , this is a relatively recent process for generating notifications for almost any parameter collected by the system.

The processes, in turn, are divided into modules corresponding to the information collected. There are many modules, the main ones are os, system, ports, mempools, processors, sensors and others. In the screenshot above you can see that such parameters as OS, version, device filling are collected.

And finally, the modules are divided into MIBs, a list that is taken from the definition file for various operating systems.

The information varies depending on the device manufacturer, type and sensors available for a particular device. Under the spoiler are a few examples:
Various devices
Cisco 7600
7606 Cisco 2960C
Cisco 2960C
Olivetti printer

Overview page:

Overview page

A few more spoilers
Overview of all devices:


Quick search:


Search by IP / MAC / ARP / FDB:




RANCID and history of configuration changes:


The system integrates with various external utilities, such as syslog, rancid (including showing the latest changes), collectd, smokeping, nfsen.
Sensor monitoring is supported over IPMI.
There are monitoring services such as Apache, Nginx, Mysql, Bind and others, through unix-agent.
Monitoring of some virtualization systems is supported.

As mentioned above, the paid version has a process for active notifications. It will not replace systems such as nagios / icinga or zabbix, as it is currently limited to 5-minute intervals for polling devices, but it is able to provide 60% of the notification needs. And for systems with a small (<50) number of devices, he is completely ready to replace any other system. Under the spoiler are some more pictures for him.
Active notifications
Validation rules:
Current notifications:
Notification log:

With pictures, probably enough, just do not show. Most of the features can be seen on the demo page ( oh, just the request not to create a habraeffect ) here .

For the rest, please ask questions and suggestions if you need to supplement the article with something.

Also popular now: