- About Us
This app has absolutely nothing to do with guarding anything. KSysguard lets you manage processes and monitor resources on local or remote systems. According to the documentation, it can be built on Solaris, BSD, and Linux.
KSysguard is actually two applications; a GUI front end, where you can configure sets of worksheets to represent different machines or different monitoring scenarios, and a backend daemon which essentially feeds data to the front end. The back end daemon can be started at boot time or invoked manually from the front end, even if the daemon is on a remote host.
The GUI front end, by default (on SUSE 9.1, anyway), starts up with two sample worksheets configured for you, browseable with a tabbed interface. On the left is a tree view of the different hosts you're connected to, and expanding those trees gives you a view of what sensors are available for them. Figure 1 gives you a view of the KSysguard workspace. Note the tabbed interface on the right, where I have several worksheets configured, while the tree view on the left shows a good number of sensors I have access to on my local machine.
Going beyond defaults
Surprisingly, I found connecting to remote hosts and creating new
worksheets in the workspace to be very easy. There are various methods of
connecting to a remote host; the interface even lets you issue a "custom
command" to connect with. What I found easiest in my environment was to use
SSH (with SSH keys, by the way). The command I issued to talk to a test box
named opus, for example, was
ssh opus ksysguard. Once the command is run,
a tree for opus appears in the left pane, and I can browse the available
sensors on opus.
To put these sensors to use, I need to create a worksheet. This couldn't be easier. Simply click the New icon to invoke a dialog asking for a name for the worksheet, the number of rows and columns to create, and the update interval. Fill this out, click OK, and you're presented with an empty worksheet, with empty table cells waiting to be used. Now, browse the tree view for a sensor you want to use, and click and drag it into whichever cell you want that sensor to appear in. If the sensor you're using doesn't have "Table" in its name, you'll be asked how you want it to look. The choices are "Signal Plotter," "Multimeter" (which is just a digital number representing the value returned by the sensor), "Bar Graph," and "SensorLogger." I haven't found a use for these last two, but feedback from more experienced users is welcome, and hereby solicited. The colors used and the ranges measured by each sensor are customizable.
|Click to enlarge|
In the first figure you probably noticed that there are three measurements being taken in the "Physical Memory" cell. This is a result of dragging three separate sensors into a single cell. This is probably not useful for many sensors, especially if the value ranges vary greatly, which can make the output a little hard to read. Experiment with this and you'll find some useful combinations that'll save you some real estate on each worksheet.
For many of the sensors, and on most hosts, it should be simple enough to
create a 3x6 worksheet and drag 18 different sensors into the cells, pick
"Signal Plotter" as the view type, and you're on your way! However, there are a
couple of sensors that should probably have their own worksheets. For example, on machines
that have a lot of users or a lot of processes, you'll probably want to use the
"Process Controller" sensor in its own worksheet. This very useful sensor is
essentially a GUI version of the
top command. You can sort by any field
(finding resource hogs has never been easier), see a tree view of the
processes, and even filter the list to view only your processes, system
processes, or user processes. Since you can't use your space bar to update the
view (a la
top) there's a refresh button, and there's also a "kill" button.
If you're running KSysguard as a normal user, of course, you can only kill
processes you own. The figure below shows the process control worksheet for my local
machine in "tree" mode.
|Click to enlarge|
Room for improvement
While I've started using KSysguard on a regular basis, and I recommend it to others, there's room for improvement. For one thing, this being a KDE application, it would make sense to integrate it with KPopUp and allow for alerts to be issued at certain threshholds, since it's not possible to view every sensor cell for every machine in a single worksheet. Alternatively, maybe the developers could build a "Summary" worksheet so that these alerts could simply be listed there, in a logview-type format. Also, it would be useful to be able to configure color changes based on thresholds in the signal plotter views. For example, I'd like my System Load signal plotter sensors to turn orange if the load creeps beyond, say, 6, and red if it goes over 10.
There are minor annoyances in the application, but they're mostly annoying only when you're first getting started using it. For example, if you drag two sensors to a cell, then discover that was not a stellar move on your part, you can't simply drag one sensor away from the cell -- you have to remove the sensor from the cell completely and start over. I understand why this is the way it is, but it would be good if there were a friendly way of reconfiguring a cell without starting over.
None of the abovementioned issues have kept me from using KSysguard. What's there works; I'd just like more power. What kind of admin would I be if I wouldn't? In the end, I think that as the program develops and evolves, it will become an extremely powerful tool. I highly recommend you check it out!