Create a failover cluster of monitoring servers, search for new devices on the network, and monitor the Linux performance metrics in the new version 7.5 of 10-Strike Network Monitor Pro

News, Updates , 0 Comments

We are breaking into spring with a new version of the program for monitoring video surveillance systems, servers and network equipment Network Monitor 7.5! Lots of improvements – both small and large. The most important thing is that we made a background search for new devices, added the ability to operate the program in a failover cluster, and added the new check of “Linux Metrics”. We tell you more about the main innovations.

Search for new devices

Finding new hosts on the network has become much easier. You don’t need to manually launch the scanner each time – the built-in task scheduler will do it automatically and completely unnoticed. Network scanning is performed by the monitoring server in the background. In case of detection of new addresses, the program notifies in several ways, as when performing checks. And if the graphical console is running at the time of notification, you will receive a message from which you can immediately go to the list of found hosts and add them to the monitoring database.

Search for new devices is implemented as one of the Scheduler tasks – look for this function there. For ease of configuration, we have moved it to a separate button on the main toolbar. To enable this task, you need to configure scanning parameters (range, methods, logins), notifications and launch interval.

Backup monitoring server for a failover cluster of monitoring servers

We have already made it possible to quickly reconnect the monitoring server to the backup database server if it fails. But what if the monitoring server itself fails? We have provided for this and made it possible for two monitoring servers with the same ID to work in the same network simultaneously without conflicts (in the version Pro that supports multiple monitoring servers).

Each installed monitoring server has its own unique ID, which allows you to distribute a set of checks between monitoring services. For example, a server with ID=1 performs one set of checks, and a server with ID=2 performs another. They do not intersect and do not create an excessive load on the network and database. If one of the servers stops working, then the checks assigned to it stop running, monitoring stops. But if you duplicate the monitoring server with the same ID, then the backup monitoring service will quickly start working in such a situation.

How to set this up? You need to install an additional monitoring server from a separate distribution and, when connecting to the DB for the first time, specify the ID of the server that needs to be backed up. For example, we already have a server with ID=1. We install another one on another physical computer and during setup we also assign it ID=1.

When launched, such a server will read the same set of checks from the database as the first instance. But it will not perform them as long as the first server is active. As soon as the backup server understands that the main one no longer runs checks, it will immediately start performing them without additional commands and settings. Thus, the backup monitoring server becomes the main one.

Of the two servers with the same ID, the one that started first becomes active. It performs checks, scheduler tasks, and starts an alert.

Reserving the monitoring server allows you to use the program in a failover cluster. If the DB server stops, the monitoring service automatically connects to the backup DB server, and if the monitoring server itself stops, checks start to be performed

Linux Performance Metrics

We have added a new check that can receive performance counters and other parameters using an agent installed in Astra, Alt, Debian, and Ubuntu OS:

  • CPU load, %
  • RAM load, %
  • Free RAM, MB
  • Virtual memory usage, MB
  • Virtual memory load, %
  • Disk load, %
  • Number of running processes
  • Continuous operation time, sec
  • Directory size, bytes

Different notification settings for Syslog and SNMP trap filter conditions

Previously, the program notified about all incoming SNMP trap and Syslog messages in uniform configured ways. In the new version, we have moved these settings to the level of individual filter conditions. For example, the program can now respond to messages from device 192.168.1.1 by sending e-mails to one address, and it can send messages from 192.168.1.2 to another e-mail. General notification settings have also remained. They are valid if the “Accept all messages” parameter is enabled, regardless of the filter.

All changes in the version 7.5 in a short list:

  • Pro: Added the ability to create a backup monitoring server, which, if the primary server fails, automatically takes over all its functions without downtime. This solution can be used when creating a failover cluster of monitoring servers.
  • Pro: Added function for detecting new hosts on the network. The search runs in the background. It is implemented in the monitoring service and is launched according to a specified schedule by the built-in task scheduler. When new hosts are detected, an alert is issued and the program offers to add them to the network map and to the host list.
  • Pro: Added the new “Linux Metrics” check, which works using our new remote Linux agent. The check allows you to obtain the CPU and disk load, RAM and virtual memory usage, the number of running processes, uptime, and directory size.
  • Added different alert settings for each SNMP trap and Syslog filter condition. Now the program can respond to each type of the incoming message in different ways.
  • Added the ability to connect the Private Key File authentication in the “SSH” check to establish a connection with a remote host via SSH.
  • The “Terminal name” parameter has been added for the “SSH” check in the program settings.
  • When adding hosts from an address list or ONVIF search, these hosts can be immediately added to the network map.
  • Pro: Added the ability to change the color of the gauge indicator when an alarm is triggered.
  • Pro: Added the ability to change the font color of a numeric indicator if it does not have a minimum and maximum value specified.
  • Pro: Added display of not only the text of areas and lines, but also their other parameters in the list of objects to configure actions in the monitoring check parameters. This makes it easier to find the desired map object.
  • Pro: When adding CCTV cameras from an ONVIF search to the network map, an RTSP link is now automatically added to the icon, which can be opened in the CCTV player using the CTRL+Click.
  • Pro: Web: The CCTV cameras tab in the web interface can now be hidden in the web application settings.
  • Pro: Web: Added remembering the last opened tab in the web interface and activating it when the page is refreshed.
  • Added the date displaying in charts for printing.
  • Improved the process of searching for cameras using the ONVIF protocol.
  • Pro: Fixed the issue when the map link icon did not change its status (color) if that map had another map link with a “red” (failed) status.
  • Pro: Fixed importing of some checks from the 10-Strike LANState Pro program (the bandwidth monitoring checks).
  • Pro: Fixed some problems with the program’s compatibility with Wine (Linux).
  • Fixed ability to edit the picture resolution field in the RTSP check.
  • Fixed problems with the email message encoding when sending messages using an insecure version of the SMTP protocol.
  • Fixed the SNMP trap source detection for SNMP trap v2c and v3 versions.
  • Fixed conversion of the uptime parameter received via SNMP trap v1 to seconds.
  • Fixed other found bugs.

Download the new version and update!