MTool: Performance Monitoring for Multi-platform Systems
Three-tier architecture turned out to be a good solution. We defined three different levels:
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.
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.
At this time we can provide the following system resources:
CPU information (user, nice, idle, sys, average)
Disk and memory information (free, used, swap)
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 188.8.131.52 # Second, monitoring time inter- # val in seconds 4 # Last, clients with access to # monitored hosts *.hermes.si 184.108.40.206 220.127.116.11 130.15.40.* 193.246.15.* 164.8.253.*
Free DevOps eBooks, Videos, and more!
Regardless of where you are in your DevOps process, Linux Journal can help!
We offer here the DEFINITIVE DevOps for Dummies, a mobile Application Development Primer, and advice & help from the expert sources like:
- Linux Journal
- Resurrecting the Armadillo
- High-Availability Storage with HA-LVM
- Real-Time Rogue Wireless Access Point Detection with the Raspberry Pi
- March 2015 Issue of Linux Journal: System Administration
- DNSMasq, the Pint-Sized Super Dæmon!
- Localhost DNS Cache
- Days Between Dates: the Counting
- The Usability of GNOME
- Linux for Astronomers
- You're the Boss with UBOS