For me, it all started with this
post . Habrayuser
gsandul decided to write a guide book on the monitoring system
The Dude , and I helped him to the best of my ability. If you have a desire to positively evaluate this post, then all the bonuses to the author of the book - he deserved it more.
All comments, suggestions, etc. Please write in the comments - this will allow to take into account errors and omissions in the following parts of the book.
Under the cut the first part.
So let's get started.
Introduction
Among the existing monitoring systems, Dude is positioned as the best in terms of price / quality ratio product. This is true because it is distributed free of charge. However, despite being free, it is not inferior, and often exceeds commercial products. I know many examples of successful use of this software, ranging from commercial banks and Internet providers to government agencies.
Dude functionality allows you to monitor individual servers, as well as networks and network services of any degree of complexity. In most cases, the capabilities of this software are not used to the maximum. This is due primarily to the lack of quality documentation. Even an experienced system or network administrator will need several weeks to properly set up system monitoring if he starts from scratch. This book is designed to simplify the study of this product.
Surely, you will not find here the answers to all the questions that arise when using Dude. After all, the purpose of this book is not a description of each of the possible system settings. However, most likely, after reading you will be able to independently solve any problem of monitoring your system.
')
Strictly speaking, what you are reading now is not documentation on Dude. This is a monitoring book with Dude. If you simply read the headings of this book, you will probably get the feeling that everything is written messy, and the author shuffles off from one topic to another. I assure you it is not. The procedure for submitting information is thought out, you just need to read in a row what is written and then, at some stage, you will understand this product and be able to use it effectively.
This book describes the monitoring of network devices, mainly Cisco routers and switches, as well as servers running Windows, Linux, FreeBSD. Unfortunately, the work with the operating system RouterOS is not considered here, since I do not have devices running under its control.
Brief description of system features
Monitoring the state of the system, as a rule, is carried out by one or several workstations or servers. The monitoring system is called a Network Management Station (NMS) - a network management station. Further, the system on which Dude is installed may be called NMS. Dude supports both active and passive type of monitoring.
Supported monitoring types
There are two types of monitoring: active and passive.
Active monitoring involves polling devices at regular intervals in order to determine the availability of the devices themselves and the services they provide, as well as checking the current state of the devices, such as the percentage of CPU usage, disk usage, temperature on the chassis, and others. With Dude, you can do this monitoring. Moreover, in Dude, basically, all monitoring is carried out in this mode.
Passive monitoring means waiting for devices to report events occurring in the system. Usually such messages are sent by devices using the syslog protocol or using SNMP Trap. As for working with SNMP Traps, Dude, despite its excellent support for SNMP, does NOT support working with them. However, this software product is well implemented work with syslog messages. The following chapter is devoted to this.
Active monitoring, supported survey types and information delivery
The fact that Dude can do in the active monitoring mode is written on his page:
- automatic network scanning and map display;
- device type detection and manufacturer determination;
- monitoring devices and connections between them and warning of failures;
- displaying devices in graphical form with the ability to add your images;
- simple installation and use;
- You can build your network maps with the addition of non-standard devices;
- supports monitoring via SNMP, ICMP, DNS, UDP and TCP for devices that support these protocols;
- You can graphically display the use of connections between devices;
- launch remote administration tools directly from the console;
- works under client-server architecture;
- runs and runs under Linux and FreeBSD in Wine, MacOS in Darwine, Windows;
- and much more…
In fact, the basic functions of the Dude are enough to solve the basic tasks of monitoring. But, thanks to the excellent support of the SNMP protocol, as well as the processing functions of the responses received from SNMP devices, it is possible to carry out very complex and high-quality monitoring.
Client, Server, Agent. How it works
Before proceeding with the installation and configuration of the monitoring system, it is necessary to select the location - the physical server where your NMS will be located. Moreover, there may be several such servers. For some installations, it may be sufficient for the NMS to be located on the workstation of a system or network administrator. It all depends on what you want to receive.
If you do not need round-the-clock monitoring of services, you can install Dude on your workstation and monitor the system only when you are behind the workplace. However, most of the time monitoring should be round-the-clock, therefore it is necessary to install a monitoring system on servers that work around the clock.
As for the load on the system from the Dude, it is minimal. An example from practice: a server on an Intel Pentium III processor with a clock frequency of 800 Mts and a 256 MB RAM running FreeBSD copes with monitoring about 50 network devices and servers. It is also worth considering that at the same time 3 people were connected to the server using the Dude client at the same time and, moreover, Apache + Cacti + syslog-ng + smsd were running and running on it.
When choosing a server location, you need to be guided by two criteria: the minimum remoteness of the server from the main devices that need to be monitored and the capacity of the Internet channel between the monitoring server and stations with clients that will connect to it. To understand why this is so, you need to know how the server, client and client work in conjunction with the server.
Client server
Client-server architecture is understandable to almost any IT specialist. There are some features of the implementation of this architecture in Dude.
You must immediately make a reservation that the client and server must be the same version. The version used will be the one that is installed on the server. If you installed a version on the client that is different from the one on the server, then when you connect to it, you will be asked to upgrade the client version to the server version, even if the client has a later version. The update will be performed automatically, and the client will download the files needed for the update from the server and restart.
A client can be connected to only one server, and several clients can be connected to the server at the same time. Graphically, this is shown in the figure.

The server stores, uses and modifies the current configuration to perform monitoring. Actually, the server conducts system probing, gives alerts if failures have occurred, saves the results of probing in its configuration for later output in graphical form. By itself, the server is not able to graphically display the network diagram. To obtain a graphic image, as well as some types of alerts about system failures, the client is used. Even if Dude is working on your workstation, to display all the information received by the local server during the monitoring process, you need to connect to the local server with a local client.
The client does not store any information, except located in the RAM, i.e. intended for display. The main purpose of the client is to draw a beautiful picture and, in case of failures or other events, display it in the client console for easy perception. The second purpose of the client is a graphical user interface designed to configure the server.
When you complete a client process, all data stored in its RAM is deleted from it. Other data, except for settings for connecting to the server, the client does not store. Therefore, when loading the client, it is necessary to load all the necessary data from the server every time.
The amount of data uploaded by the client is relatively high - it can reach several tens of megabytes. If you connect to the server locally or via a local network, then there will be no noticeable delays when the client starts. However, when you connect via Internet channels, the delays can be quite noticeable. In general, if your access speed to the server is more than 10 Mbit / s, the delays are acceptable, but if your access speed is significantly lower than this value, then the client download may take several minutes.
After downloading the configuration to the client, the server constantly communicates with it, passing on only changes to it. This process consumes a small capacity of the Internet channel - about 30-50 Kbps. In this case, the server communicates with all clients simultaneously, i.e. any changes in configuration or in the status of sensing immediately become available to all customers. If, for example, on one of the clients to change the location of the device image on the map, then on other clients the image will immediately shift. Therefore, one of the criteria for selecting the location of the server is the bandwidth to the channel.
Another criterion for choosing the location of a server is its distance from the main servers. The closer to them the monitoring server, the better. For example, in this case, the loss of packets to the servers will be much less and there will be no false positives of the monitoring system. But not only therefore. Sometimes it is necessary to determine the availability of services on your network from a specific location, and it is not always the subnet where the IT employee’s workstation is located.
Consider an example from practice.

There is an office of some organization, let's call it the control center. From this office, operational management of the server and network infrastructure located in the data center hundreds of kilometers from the control center. Usually 5 client workstations are connected to the Dude server from the control center. Despite the fact that a large amount of data is transmitted between the Dude server and clients via the Internet, the server location was chosen in the data center. This was mainly done because the picture, if the server were located in the control center, would not be objective. For example, in the event of a malfunction of the Internet channel in the control center, there would be a false alarm of the monitoring system, while in fact in this case the servers in the data center performed their functions in the normal mode, i.e. there was no damage to the business. The advantages of this scheme also include minimal packet loss between the monitoring server and devices, as well as small delays in the transmission of packets.
In the example described above, everything is fine in terms of minimal packet loss and time delays between the NMS and the devices that are being monitored. However, devices that need to be monitored can also be located in the network control center. You can install an additional Dude server in the local network of the control center, but this creates inconvenience because the client can only be connected to one Dude server. This problem can be solved using the additional Dude server as the Agent of the main one.
Servers and agents
Dude developers made this definition for Agents: Agents are other Dude servers that can perform probing on behalf of this server, thus allowing access to parts of networks that are not directly accessible to this server, or simply transfer part of the work to a location closer to the device being polled.
After reading this definition, many questions immediately arise. In order to properly understand what it means, you need to have an idea how it works.
Here are the main provisions of the work of a bunch of agents and servers:
- when you install a server, an agent is also installed;
- any Dude server can act as an agent for an arbitrary number of servers;
- any Dude server can have an arbitrary number of agents;
- the server connects to the agent and gives it tasks to perform those or other probes, while the configuration of the probes — what, how, with what parameters and when it will be executed — is transmitted by the server to the agent;
- the agent simply starts the probes, then the results of the probing are provided to the server for storage and subsequent display on the client;
- Dude server can only act as an agent;
- If you use the server only as an agent, then the server does not store any configurations other than the one needed to authenticate the server.
The easiest way to understand how this works is by examining some geographically distributed organization.

The organization has its headquarters and two remote offices. At the same time, office number 1 has its own staff of IT specialists, but office number 2 does not. Along with the servers and the network, these headquarters specialists are responsible for the servers and network infrastructure of office No. 2 and partly for the servers and network infrastructure of office No. 1. A separate server is designed for VoIP maintenance staff, which is located in office No. 1.
In this case, we have 4 Dude servers. Moreover, servers A and B are simultaneously servers and agents of other servers, server C performs only server functions, server D - only agent functions.
When you connect to different servers, the picture will be different.
Compare what a VoIP Specialist sees

with what headquarters employees see

It should be noted that some equipment is monitored independently by several servers. For example, data network equipment. However, in this case, if the headquarters employees need to have a complete picture of all network equipment, then the VoIP escort employees only, say, one router and a switch that includes VoIP equipment.
Server D, which works only as an agent, does not contain any maps at all and does not monitor anything on its own. However, its presence is important, at least from the point of view that the specialist responsible for VoIP will be able to assess the delays and the level of packet loss from the second office to headquarters.
In addition, for various reasons, not always networks, or part of networks, may be available from other offices. For example, for reasons of security policy on the switches of office number 2 may not be prescribed routes by default. Also, a VPN may not be configured between offices and Internet access may be provided only through a proxy server.
There are many options for using a bunch of servers and agents. How to use the scheme with agents, and whether to use it at all, you have to decide for yourself, based on the configuration of your network.
Installation
Dude was written under the Windows operating system. The distribution comes as an executable exe file. You can download it from the
developers site.
Windows
Installing on Windows is trivial. To install, download the distribution from the manufacturer’s website and run it. You will be asked to read and accept the license agreement, then the following dialog will appear

It is recommended to set everything as default. the installed software does not take up a lot of disk space, and then you may need all the functionality. Functions that are unnecessary during the subsequent work, for example, the server part, can and even will need to be disabled after installation.
The next dialog will prompt you to choose the installation location, after which the installation will start, which will take a few seconds. Upon completion of the installation, you can immediately launch the software and proceed to its configuration, which will be described in more detail below.
Linux FreeBSD
Installation under these operating systems is more laborious, however, if you have experience working with them, it will not cause any special difficulties.
It should be immediately noted that the installation and launch must be done under the root user. Running under another user is possible, but due to the nature of working under wine, if you start the software without being root, you will not be able to run the ping utility. Moreover, the ping test will not work, which will lead to the loss of one of the main functionals.
The installation algorithm is as follows:
- install X-Windows;
- install wine;
- Run the Dude installation from X-Windows;
- launch Dude from X-Windows itself.
Installation details for various Linux distributions: Debian, RedHat, CentOS and others, you can find at this
link .
A more interesting task is to run the Dude server under FreeBSD in the automatic Start Up process, in Windows terms, as a service. Although this task is considered on the example of FreeBSD, it can certainly be realized under Linux using the same, and maybe other, means.
Example of starting a server under FreeBSD without using a keyboard and monitor as a Windows Service
Under Windows Dude, you can run as a service using the tools of the program itself - as described below. Starting as a service is necessary to ensure that after a server overload for any reason - whether it is a power failure or a scheduled reboot - Dude automatically loads and performs its functions. In addition, launching as a service means saving a terminal license and server resources.
Dude under FreeBSD must be run from X-Windows. This implies, at least, connecting to a keyboard and monitor server, launching Xorg or another window manager like Gnome or KDE, then launching Dude under wine.
This problem can be solved using Xvfb. Xvfb is an X11 virtual server that performs all graphical operations in memory only, without displaying them on the screen. Xvfb also does not require the presence of input devices such as keyboard or mouse.
In addition to Xvfb, you must also install the monit daemon. The installation of this daemon is due to the fact that if you try to run Dude from scripts that are started at system start, located in /usr/local/etc/rc.d/, then you will not succeed. The reason that Dude does not start from /usr/local/etc/rc.d/ is not fully defined by me, since I am not a FreeBSD top-class expert. However, everything else, using the monit daemon can be considered good practice if you need to ensure self-healing after the failure of other daemons.
The installation described was done under FreeBSD 7.0 and 7.2. To simplify the description of the installation process, the installation from the ports is shown, but in order to save time, you can install everything using packages:
- Install xorg
cd / usr / ports / x11 / xorg
make; make install clean - Install wine
cd / usr / ports / emulators / wine /
make; make install clean - Install Xvfb
cd / usr / ports / x11-servers / xorg-vfbserver /
make; make install clean - Install monit
/ usr / ports / sysutils / monit /
make; make install clean - Install wget
cd / usr / ports / ftp / wget /
make; make install clean
Then you need to configure and run xorg - how this is done, you can easily find it on the Internet. Running xorg to install Dude needs to be done as root. After running xorg, download the Dude installation file from the manufacturer’s site.
wget www.mikrotik.com/download/dude/3.5/dude-install-3.5.exe
Run the installation
wine ~/dude-install-3.5.exe &
After the installation is completed, you need to run Dude under xorg once to perform the initial minimum configuration, for which you need to enter the command
wine ~/.wine/drive_c/Program\ Files/Dude/dude.exe
In the next dialog you need to select the interface language

The following window will start.

Press the button

and remove all the checkboxes

Next click

and select the item shown below.

Presets are ready. Click OK, close the Dude console, exit xorg.
To enable the automatic startup procedure after a system reboot, you must:
- Enable autorun monit at startup, for which register a line in /etc/rc.conf
monit_enable="YES"
- Create a script /usr/local/etc/rc.d/startXvfb.sh with the following contents
#!/bin/sh
/usr/local/bin/Xvfb -shmem -screen 0 800x600x16 &
- Create a script to run Dude - /root/dudestart.sh
#!/bin/sh
DISPLAY=:0 /usr/local/bin/wine /root/.wine/drive_c/Program\ Files/Dude/dude.exe &
- Create a configuration file for the / usr / local / etc / monitrc daemon (you need to fix the IP address on your)
# Check if Virtual X-windows process started
check process Xvfb with pidfile /tmp/.X0-lock
start program = "/usr/local/etc/rc.d/startXvfb.sh"
# Check If Dude started do not start if Xvfb is not runnig
check host dude with address 192.168.0.250
start program = "/root/dudestart.sh start"
if failed port 2210 then start
depends on Xvfb
- Set the attributes of the newly created files necessary for launching and working.
chmod 600 / usr / local / etc / monitrc
chmod 700 /root/dudestart.sh
chmod 700 /usr/local/etc/rc.d/startXvfb.sh
To check the launch, you must start the monit daemon
/usr/local/etc/rc.d/monit
Next, give the command
netstat -an | grep 2210
the result should be
tcp4 0 0 *.2210 *.* LISTEN
and more, for verification you can give
ps -ax | grep dude
The result should be
58905 ?? S 591:12.24 /root/.wine/drive_c/Program Files/Dude/dude.exe (wine)
The server with Dude is ready - now you can run the Dude client on another workstation under any of the supported operating systems and begin to configure it. You can also restart FreeBSD to make sure 100% that everything is working as it should.
First start
It is assumed that the first installation will be performed on the NMS. However, the first launch is the same for the server part and for the client part, if you set everything up by default.

When you first start you will be asked to choose the interface language and then start scanning the local network.
Localization
Here is a window for selecting localization will be displayed when you first start Dude

Dude software is well localized. At the same time, both the menu and various program messages are localized. However, I prefer and recommend using the original English version for the following reasons:
- the name of the event folders is localized, which creates some confusion if you first installed the localized version for some language and then decided to switch to the original language;
- if you have at least one person on the staff who does not speak the localization language, then sometimes insurmountable difficulties will be created for this part of the staff;
- if you read documentation in English every day, then it should often be easier for you to understand the English version than the localized one;
- despite, in general, good localization, some things are translated inaccurately. For example, you can compare how the definition of the agent was translated by me and how it determines the translation supplied with the installation program.
You yourself have to decide which language to use, but the English version will be discussed later in this book.
Network Scan on First Run
In the next window you will be prompted to scan the local network.

Dude will automatically determine the network and its mask according to the IP settings of your network card. You can run a scan, but it can most likely be ineffective until you first configure Dude. In any case, the network scan can be started at any time, in addition, the scan can be launched in automatic mode with a periodicity defined by you. Details of network scanning issues are described below. At this stage, I recommend to cancel this operation.
First run as client only
If you plan to use this installation only as a client, then immediately you need to do two things:
- change the default password for the administrator;
- stop the local server.
Why it should be done, see security issues. How to change the password is discussed below in the section on user management.
Graphical User Interface (GUI)
GUI Dude is intuitive and easy to use. Its various features will be considered gradually as they are used.
General view of the area
First you need to consider globally what it is

The interface can be divided into six main parts:
- Global local client and local server settings;
- Global settings of the server to which the client is currently connected;
- The left panel is the navigation panel for various features of the software product;
- – , – , , , , ;
- ;
- , , , , .
,


, :
- . , , , , , ;
- . , .

IP- Dude – , , loopback – 127.0.0.1.
, IP- . Dude IP- DNS.
firewall , TCP. 2210 2211 .


, .
Local server settings
Local server settings are determined by clicking its status button. 
.
, – , – . , – , .

. .
«All Time» , , . , , .
«As service» , , .. . «The Dude Server» , .
, , , Settings

, , .
Undo, redo
Buttons

. , .., , , , , , . , , , . Misc .
Backup
Buttons

.

, . gz. Dude . , , Dude, , .
– .

.
Server Settings
, – .


, , , .
Reset. (!) Dude, .. «» , . , , , . , .
To be continued...