MTool: Performance Monitoring for Multi-platform Systems
Quite a long title for such a small software package, but it describes exactly the content of this article. In our networked world, the amount of information is growing and becoming less manageable. The first idea for developing a performance tool came from the CERT engineer (Gygi), who works for one of Europe's academic networks—SWITCH, Swiss Academic and Research Network. SWITCH's head office is located in Zurich. Less than two dozen highly qualified engineers operate some 50 sites throughout Switzerland as well as the central SWITCH system at ETH Zurich computing center.
While SWITCH is already using some performance monitoring tools, the procedures are far from satisfactory. Each time the engineers want to monitor a remote system, they have to log in and use common tools such as top, ps, df, etc. This introduces undesirable security risks.
What SWITCH needed was a simple, reliable, secure tool that could be easily used from any authorized place in the network (or Internet). The tool should be compact—it must not use much of the system's resources. Furthermore, it should be multi-platform oriented. Even though SWITCH maintains mostly Sun workstations, the number of Linux boxes and other UNIX systems that they monitor is not negligible. As a first step we were interested in monitoring basic system resources: CPU/memory/swap usage and some specific processes (daemons such as inetd). These resources provide a snapshot of a monitored system. In the second phase we decided to observe some additional parameters such as network traffic, disk usage, user/ftp connections and some other processes.
The demands for a multi-platform, secure tool brought us to a simple decision—Java. As we have a strong students' Java team at our lab, Java was chosen as the basic development tool. Java is a network-oriented, robust tool and provides enough security for our requirements. We won't go into details of the language, but it was also clear that Java was not appropriate for the system-level programming needed to access system resources. For that reason, we chose a three-tier architecture (see Figure 1). This architecture represents a response to some of the drawbacks of the standard two-tier client/server network architecture. Client/server applications are quite easy to program; the problem is how to manage client-side software. The problem is even bigger when we require a multi-platform environment. Three-tier architecture introduces so-called middleware (e.g., the Java server in Figure 1). Basically, the middle software residing on the server represents a bridge between a client and a server. The middle tier is not only capable of handling more client connections, but also provides a more secure method of communication. Since the middleware and the client part can be written in Java, we come to a very important issue—platform independence.
Clients are no longer expected to use platform-dependent code. Even more, a copy of a Java-enabled network browser such as Netscape would suffice. Developers can now take a break, since they don't have to write a lot of platform-dependent versions of their software. This basic idea is also used on network computers (NC). Whenever the developers change the client's code, a new version can be made available for distribution on the middle-tier server. Then next time the client runs the program, the new version is automatically downloaded. The platform-dependent software which provides information to the clients over the middleware is written in ANSI C. The communication between middleware and the server is done using sockets.
As we have already mentioned, we had a daemon (mtoold) written for Sun workstations since they represent a majority in Switzerland's academic network. However, our environment is mainly equipped with HP workstations; we also have more than 70 Linux boxes around the classrooms and labs, as well as Windows 95/NT computers. We've learned a lot from Linux since 1993, when we built our first Linux box using the 0.99pl15 kernel. Linux has made tremendous progress since that time.
Thus, for us, Linux as a development “playground” was a logical choice. Linux has a well documented /proc file system. (See “The /proc File System and ProcMeter” by Andrew M. Johnson, Linux Journal, April 1997.) Linux is the best documented operating system available. What we missed most was a good Java development tool. If Linux had a GUI like Symantec's Visual Cafe, we would have been very happy indeed. At that time, we were still forced to use the command-line Java compilers and interpreters that come with the standard Java Development Kit (JDK 1.0.2 or JDK 1.1.1). So, we used Visual Cafe under Windows for creation of the user interface, then manually added some specific code.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- Stunnel Security for Oracle
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- SUSE LLC's SUSE Manager
- SourceClear Open
- Managing Linux Using Puppet
- My +1 Sword of Productivity
- Google's SwiftShader Released
- Parsing an RSS News Feed with a Bash Script
- Non-Linux FOSS: Caffeine!
- SuperTuxKart 0.9.2 Released
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide