MTool: Performance Monitoring for Multi-platform Systems

An article giving us all the information about a new tool for performance monitoring of distributed systems.
Architecture of MTool

Three-tier architecture turned out to be a good solution. We defined three different levels:

  1. Client software

  2. Item middleware

  3. Platform dependent daemons

To monitor specific systems you must be connected to the network; actually, you have to connect to the middle-tier Java server. Client side presents just a GUI (Graphical User Interface). Since it is written in Java, a Java capable browser is all you need. After you make a connection to the Java server, the GUI code is transferred to your local machine. Code is then interpreted with the Java built-in interpreter (if you use Netscape, for example).

The central point of our system is the middle-tier Java server. It not only holds Java classes to be transferred to the local clients, but it also takes care of the monitoring. The Java server is a program that runs all the time but demands only a few system resources. It connects to monitored computers and asks them for new data. Communication is handled via sockets and is very simple. We also introduced a very simple protocol for data transfer.

Client Software

On the client side, one must run a starting applet to bring up the basic window in which all the computers to be monitored are listed (see Figure 2). Once we choose a computer's name from the list, a second window appears containing all the information about the observed system. We used a tabbed panel to display different types of data. We've chosen a tabbed panel to ease the upgrade procedure. If we add new system information, there is no problem with the graphical interface—we simply add a new panel.

Figure 2. Main MTool Window

At this time we can provide the following system resources:

  • CPU information (user, nice, idle, sys, average)

  • Disk and memory information (free, used, swap)

  • Network traffic

  • Processes

  • User connections

Figure 3. CPU Usage Panel

Figure 4. Disk Information and Memory Usage Panel

Figure 5. Network Transport Panel

Figure 6. Processes (preconfigured selection) Panel

Figure 7. Users Connections Panel

Middleware—Java server

The Java server is designed to run on an independent computer, but it can also run on a client of one of the monitored computers. The communication with the monitored computers via sockets is quite short and lasts only as long as the data transfer. At any time we can choose how often the Java server requests system resource data. At that time, a “ping” is sent to all monitored computers. At the ping, mtoold is awakened by inetd. Then mtoold reads system resource information and forwards that information to the middle-tier Java server. After completion the mtoold daemon “sleeps” until the next server's ping. The platform-dependent mtoold therefore uses system resources for only a very short time.

For its operation, the Java server is supported by one configuration file, named MTool.conf. The first part of this file contains the list of computers to be monitored, then the time between monitoring intervals, and last the list of client computers authorized to communicate with the Java server and thus monitor selected computer systems. We can use IP addresses or IP host names or both. As you can see from the sample configuration file below, one can also use the asterisk wild card in defining the domain name or the subnetwork address.

# First, the hosts to be moni-
# tored
cebelica.uni-mb.si
mravljica.uni-mb.si
cmrlj.uni-mb.si
strela.fcs.uni-mb.si
grom.uni-mb.si
164.8.253.16
# Second, monitoring time inter-
# val in seconds
4
# Last, clients with access to
# monitored hosts
*.hermes.si
130.216.54.51
164.8.253.99
130.15.40.*
193.246.15.*
164.8.253.*
______________________

Webinar
One Click, Universal Protection: Implementing Centralized Security Policies on Linux Systems

As Linux continues to play an ever increasing role in corporate data centers and institutions, ensuring the integrity and protection of these systems must be a priority. With 60% of the world's websites and an increasing share of organization's mission-critical workloads running on Linux, failing to stop malware and other advanced threats on Linux can increasingly impact an organization's reputation and bottom line.

Learn More

Sponsored by Bit9

Webinar
Linux Backup and Recovery Webinar

Most companies incorporate backup procedures for critical data, which can be restored quickly if a loss occurs. However, fewer companies are prepared for catastrophic system failures, in which they lose all data, the entire operating system, applications, settings, patches and more, reducing their system(s) to “bare metal.” After all, before data can be restored to a system, there must be a system to restore it to.

In this one hour webinar, learn how to enhance your existing backup strategies for better disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible bare-metal recovery solution for UNIX and Linux systems.

Learn More

Sponsored by Storix