NOCTUA by init.at THE FLEXIBLE MONITORING WEB FRONTEND

Transcription

1 NOCTUA by init.at THE FLEXIBLE MONITORING WEB FRONTEND init.at informationstechnologie GmbH - Tannhäuserplatz 2 - A-1150 Wien - Dieses Dokument und alle Teile von ihm bilden ein geistiges Eigentum von init.at und dürfen für ö ffentliche Zwecke nicht ohne Erlaubnis verwendet werden.

2 1 Why NOCTUA by init.at NOCTUA benefits from more than ten years of init.at experience in the field of monitoring complex infrastructures and networks. NOCTUA is based on the proven technologies Nagios/Icinga. Not only have the functions been expanded comprehensively, installation and management in particular have been made much easier. ADVANTAGES OF NOCTUA Quick and easy installation Central monitoring and remote management of all devices via web frontend Automatic notification in the event defined values being exceeded or failures that cannot be removed remotely Effortless allocation of the monitoring tasks by your systems administrator Can be controlled via script Connection to AD and LDAP servers Future security thanks to ongoing development and updates Training and support from specialized NOCTUA developers With large and complex networks it is inefficient and almost impossible to configure the monitoring software manually. NOCTUA reduces the time required for this process to a minimum, so that you can save time and money effectively for the monitoring of your infrastructure. NOCTUA achieves this by means of the following features and technical characteristics. 2 NOCTUA Features 2.1 Web interface Time-wasting fiddling with the Nagios configuration is a thing of the past with NOCTUA. NOCTUA provides an easy-to-use yet powerful web interface for the worldwide tested open source monitoring solution Nagios/Icinga. With NOCTUA, even complex infrastructures can be recorded within a very short period and monitored automatically. With the help of filters, you can also find the device you seek within seconds from among hundreds of monitored devices. 2.2 Device groups

3 When entering the details of your devices, these can already be structured into device groups. This means, for example, that one type of check can be activated with one single click for any number of devices. 2.3 Network topology Determine your network topology in order to define the dependencies between your network devices. NOCTUA supports you in this with a flexible visualization of your network, so that you always maintain an overview. 2.4 Flexible checks With NOCTUA you can define checks in the accustomed Nagios/Icinga syntax and allocate the checks flexibly to the devices and groups. Check templates help you to define basic settings such as monitoring intervals or notification settings. However, there is no need to start at zero: NOCTUA makes the initialization easy for you and already provides the most important checks. 2.5 Users and alerts The monitoring of the devices is only part of every good monitoring solution. Alerts must be sent rapidly and directly to the correct user (groups). NOCTUA eases the management of users, notification groups and also escalation stages. 2.6 Scalability When monitoring large networks, a large number of checks per time period is important in order to identify problems and failures quickly. NOCTUA supports network monitoring in a master/slave architecture, as shown in Figure [2]. In such a case, the slaves carry out the actual monitoring. Only passive checks are defined on the master. This means that the slaves forward their monitoring information to the master. If the master does not receive any information from a slave within a defined time period, he raises the alarm. 2.7 High availability

4 In order to safeguard against the failure of the monitoring, the monitoring master can be operated in a HA setup. Here, a clone of the master is ready to take over the functions of the master automatically in the event of a fault. 2.8 Individual development For very large, dynamic or special networks, init.at offers many possibilities for development, such as: Automatic configuration per network crawler Individual graphical evaluation Special importer module for customer-specific formats Ongoing configuration import from existing data sources 3 Technical overview 3.1 Architecture Figure [1 - attached] provides an overview of the architecture of NOCTUA. From a user perspective, the web frontend is in the foreground. All aspects of the monitoring configuration can be managed easily and quickly via this web frontend. The configuration itself is placed in an SQL database, which can be provided optionally with a MySQL or PostgreSQL server. When requested by the user via the web frontend, the component md_config_server generates a new Nagios/Icinga configuration in accordance with the information from the database. At this point in time the monitoring is already being operated with the new configuration, and newly added devices or checks are considered in the next monitoring interval. The status of the infrastructure can be seen in the Nagios/Icinga web frontend. The component snmp-relay serves to develop interactively status information from SNMP devices based on performance and to save these intermediately. A typical example are switches, which often require many minutes to develop a complete SNMP tree. The component collserver is optional and runs on servers that are monitored. collserver collects special information about the server, such as which VMs are running or what type of RAID controller is installed. coll-relay forwards check instructions or results to the relevant positions. More than 95% of NOCTUA is written in Python. The remaining 5% was implemented in C. The use of Python allows access to the comprehensive standard library. In order to

5 ensure reliable and efficient communication, especially in network monitoring, the network stack of NOCTUA is based on 0MQ. 3.2 Network monitoring Figure [2 attached] shows an overview of NOCTUA in the master/slave setup. The master here is the central instance that prescribes the configuration to the slaves. The slaves each carry out their checks independently and send only the check results back to the master. Network monitoring makes sense and is even necessary in many different scenarios. With very large networks, performance reasons could lead to selecting this setup option. The option then becomes necessary when the master cannot make a connection with all devices that need to be monitored due to the topology. In such as case, monitoring slaves act as bridges in these parts of the network. 3.3 Technical prerequisites NOCTUA instances (master and slave) are operable on the current versions of the following Linux distributions: SUSE Linux Enterprise Server OpenSUSE Red Hat Enterprise Linux Server Fedora CentOS Ubuntu LTS Debian Wheezy A PostgreSQL or MySQL database is an absolutely necessary prerequisite. This usually runs on the same server as the master instance. CPU, RAM and disc requirements depend on the number of devices and checks. An SMTP server is required for the sending of alerts by mail, which serves as a relay. For the sending of alerts by text message, a corresponding solution is required such as a hardware SMS gateway. The configuration (network, database, mail, etc.) of the hosts on which NOCTUA instances are to be run is carried out by the customer. For the visualization of large networks in the NOCTUA web frontend, the browser should be as up-to-date as possible due to the JavaScript and SVG performance.

6 Figure 1: Overview NOCTUA DB server with network and device configuration Configuration for Nagios/Icinga Information about nodes to enable writing of specific checks Check programs for complex operations that benefit from caching Service to generate configurations for the Nagios/Icinga monitoring daemons

7 Figure 2: NOCTUA in the Master/Slave Setup for Network Monitoring Network monitoring with NOCTUA Central Icinga instance (master) Decentral instance (slave)