Diary of a Network Geek

A screensaver that monitors your server.

This may not seem like much of a “tool”, since it’s pretty passive, but when you have a server that’s getting old and failing, being able to quickly glance at what its performance is like can be a real benefit.  And, for the past eight months, I’ve been running a server that, to be honest, was a little too old to be in production.  People would complain about it pretty much constantly, even, I suspect, when it may not have been the actual problem they were suffering from.  I’ve since replaced the server, but I kept running Systemometer on both the old server, which now serves as strictly a backup server, and the new, shiny, Windows 2012 server, just so everyone can see the difference.

But, let me be really specific about this; Systemometer is a configurable monitoring tool that shows system performance and resources in a spider chart. Seeing the varying shapes of displayed polygon, representing a visual pattern drawn based on normal, or critical, system states. Once you get used to it, this snapshot view helps to read the overall system status at a glance. Just looking at the screenshot in this post, which will enlarge if you click on it, you can see that a lot of information is displayed.  Notice, for instance, that there are 12 “CPU”s listed.  Since this is a modern, multi-core server, those are really just all the cores being displayed, with the current processor time in yellow and the average processor time in green.  If I wanted to, I can also set Systemometer to display the maximal processor usage, but as this is a new server, I haven’t bothered to set that.  The same goes for the number of processes the server is handling, as well as the number of threads.  Also displayed is the physical and virtual memory usage, total drive space used and the hard drive seek time.  Notice how almost everything falls well within that red circle on the display?  That’s because the server is new and being used well below it’s capacity, by design.  This is the second server upgrade I’ve done since I’ve been at this company, and I’d like to not have to do one again soon.  That’s also why the number of threads is reading like it’s in the red, even though it’s not.  The new server is so new that not all metrics have been calibrated to display correctly.
Also, notice that the two performance polygons are yellow and green.  The yellow is the current usage while the green is the average usage.  It may be hard to tell the difference between the two because I took this screen shot on a Sunday afternoon with minimal usage.  Of course, the server being primarily a file server and an Active Directory server, the average usage is pretty constant in any case.

It may not be obvious from the screen shot, but I’m running this as a screen saver, which is only one option for using Systemometer.  It can also be used as a kind of replacement performance monitor instead of using the built-in Task Manager for that function.  Actually, one way I validated the results I was seeing from Systemometer was to run it next to Task Manager and compare the displayed performance information.
Personally, I like running it as a screen saver because I can quickly check on my server as I walk past the screen into or out of my office.  Also, it seems to impress people who see it and can’t make heads or tails of what they’re seeing.  It’s not big, fancy monitoring system, but unless you really know what you’re looking at, the average person isn’t going to figure that out!

Finally, the other reason I use Systemometer is that it’s free!
Yep, that’s right, absolutely free.  Of course, it may not ever get updated again, but I’m okay with that, as long as it still works as it has been so far.

So, I promised you more technical stuff here, right?

Well, stop yer grinin’ and grab yer linen, ’cause here come a fist full of links with some great advice for network administrators, all from TechRepublic:
First, if you’re a real network admin, you’ve dealt with traffic issues on file servers.  Issues that have hidden sources.  Unknown processes that jam up your network connections until your users scream for your head.  So, how do you deal with that when you’re on a budget and don’t have a lot of tools?  Well, one way is to use “netstat” to look at what process is running on what port and sending what volume of data.  If you’re on Unix, you probably already know about this tool, but if you’re on Windows, check out “Netstat tips and tricks for Windows admins“.  It may save your bacon one day.

Second, you probably have wireless in your network now, too, right?  But, it may not always work quite the way you want.  Once again, users will scream bloody murder if they can’t read their blogs on their iPhone, so, how do you find out what’s jamming up your WIFI network so that no one can connect?  Read through “Troubleshooting for wireless connectivity issues” to get you started on running down the problem.

Thirdly, if you’re a REAL network administrator, you probably have at least one Linux box in your network.  Something that runs an open source network inventory or monitoring tool or, maybe even, an actual Linux file server.  In any case, sooner or later, even that sad, little, neglected Linux box will have disk space issues, so here are “10 things you can do when the drive on your Linux box is full“.

And, finally, my personal favorite.  You hear a lot of buzzwords floating around these days in IT shops, but “the cloud” is the most common magic cure for all ills.  Personally, I’m not so sure.  I worry about things like, oh, you know, security and auditing and connectivity issues and little details like that which seem like they might be an issue for the magic cloud computing panacea.  Turns out, I’m not the only one.  So, go see why Patrick Gray says “The cloud doesn’t matter“.

Advice from your Uncle Jim:
"If we only wanted to be happy, it would be easy; but we want to be happier than other people, which is almost always difficult, since we think them happier than they are."
   --Montesquieu

What do you run on your monitor server?

Do you think you’re too small to run a monitoring server? Well, I have two local servers, a remote web server and a remote e-mail server that I’m in charge of worrying about and I run a monitoring server. It’s not much of a server, really, just an old workstation to which I added a bunch of spare memory and a large, clean hard drive. Naturally, I run Linux on my monitoring server, which, ironically enough, I named Monitor. Specifically, Monitor runs Red Hat Fedora.

Monitor runs Nagios, which I’ve mentioned before. With Nagios, I monitor both my main file server and my accounting SQL server. I also watch the off-site web server and the SMTP and POP3 e-mail services on the managed e-mail server we have through our ISP, just to make sure they’re up and running. (It’s a long story on why we have that, but, rather than run my own, to reduce hassle, headache and potential disaster, I let someone else worry about it.) Nagios tells me the status of drive space, the memory usage, the CPU usage and uptime on both servers. On the accounting SQL server, it verifies that the SQL service is available and that users can log into it. On the file server, it tells me the status of the Backupexec modules. Unfortunately, I haven’t figured out a way to get Nagios to tell me more than the running status of Backupexec, but, in my spare time, I still try to find a way to have it report the status of the last backup or restore job run. No joy yet, but I keep trying.

I also have a browser window open to the SolarWinds installation at our ISP. They monitor inbound and outbound traffic over the Internet connection we have. Usually, I keep a window open on the standard “interface details” reports which update regularly. Most of the time, I also open a window to the weekly history report on the min/max/average packets in and out. I have to update that manually, but it lets me quickly compare today’s traffic to network traffic for the past week. It’s nice to see those trends!
Lately, I’ve been keeping a browser window open to the national weather forecast, by hour, for our local area. In hurricane country, keeping track of the weather can be vitally important! But, if you live in snow country, the same thing would probably be true, too. I don’t recall heavy snow causing an outage during my time up North, but it’s not out of the realm of possibility.

Finally, I almost always have Wireshark running a packet capture, too. If I see a sudden spike in traffic, having a packet capture already running could make a big difference. I have that capture set to save files locally, too, just in case. I’ve been setting the capture to rotate nine files and to keep the files at seven megabytes each. That should give me a pretty good spread of captured network data if I ever need to go back and diagnose a traffic problem. And, since the machine is actually kind of stinky hardware and crashes on occasion, when I restart the packet capture, I rename the base file using the current date. That way, I can tell at a glance when the capture was started.

One day, I’d like to move this all to another machine that’s more stable, faster and has more drive space, but, until then, this works. It’s only on the private network, so I can’t look at it directly from the Internet, but, it still does enough for me. One of these days, I’ll look into some of Nagios’ data presentation modules and teach this old dog a few new tricks, like automated uptime reports and that kind of thing.

Hopefully, that hasn’t bored too many of my non-geek readers. And, I hope it’s given my geek readers something to think about. So, tell me in the comments, if you have a monitoring server/station/whatever, what does it run? If you don’t have one, why not?