Network Monitoring with Linux
Predictably, the compilation process can be set in motion by typing:
On our systems, etherload (a tool to monitor Ethernet load) fails to compile. etherload is not covered here, we hope this problem will be rectified in a future release.
Now install the software:
Use su to log in as root and type:
make rootExpect another failure due to etherload not compiling.
That completes the installation procedure. Now all that remains is getting NOCOL to do justice to your network.
Sample configuration files for the monitors are installed in /etc/samples under your proposed NOCOL tree. Take a look at these to become familiar with how it works.
One of the first things you may want to monitor is whether machines on your network are up and running. The traditional way to do this is to see whether they are responding to a ping request.
To deal with UNIX machines on your network (those running an RPC port mapper), create a file called rpcpingmon-confg in the /etc directory, typing something like this:
POLLINTERVAL 300 kenny kenny.your-network.com kyle kyle.your-network.com cartman 184.108.40.206
The POLLINTERVAL indicates how often NOCOL should “sweep” the network. In our example, it will sweep every 300 seconds (5 minutes). Following that is a list of the machines to monitor: the first column is the “friendly name” and the second column contains the TCP/IP host name or IP address.
For non-UNIX machines (routers, Windows boxes, etc.), you should create a separate file called ippingmon-confg. The format is the same.
NOCOL includes many other monitors (see The NOCOL Suite) which you should investigate and configure to suit your needs. The sample configuration files do a good job of explaining their actions and how to set them up.
A few minor scripts must be tweaked before NOCOL can start analyzing your network. Again, these are all located under the directory where you installed NOCOL.
The Perl script bin/keepalive_monitors handles the auto-starting of the monitors. Around line 32, you will find the following two lines (ignore wrapping):
PROGRAMS="noclogd etherload ippingmon rpcpingmon nsmon ntpmon portmon" PROGRAMS="$PROGRAMS radiusmon hostmon tpmon"
Alter these lines to include only the monitors you have actually configured. To match the two discussed here, you could condense them to one line:
PROGRAMS="ippingmon rpcpingmon"The script bin/notifier deals with sending warning e-mails to the addresses specified during configuration. By default, it will send a single e-mail when a site has been marked “critical” for more than two hours. If you are feeling confident with Perl, you can specify additional addresses to contact after even more time has elapsed. Specify these addresses in the AFTERx lines:
AFTER2=" AFTER3=" AFTER5="email@example.com"NOCOL comes with a custom crontab file which will automatically carry out any housekeeping required, such as ensuring all the monitors are running and rotating logs. To install it, enter the /bin directory in your NOCOL tree and type:
su nocol crontab crontab.nocol
To finally get NOCOL going, run the keepalive_monitors script located in the bin directory. Provided everything has gone well, the monitors will get to work.
If this fails, type ps aux | grep nocol (to see if the monitors are running), go back and check that you followed the instructions correctly.
Chances are, you will want to see what NOCOL is reporting. The simplest tool is netconsole which can be run either at the console or via a TELNET session. Run it and enter your terminal type when prompted (vt220, for example). The console screen will appear and will most likely be empty. The default is to show only CRITICAL events.
Pressing the l key lets you change the viewing mode. Set it to level 4 (INFO), and you will see all the information your configured monitors have gathered. See Listing 1 for an example. Play around with the levels until you find the one that most suits your needs. The h key will display a comprehensive help screen.
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!
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Managing Linux Using Puppet
- Non-Linux FOSS: Caffeine!
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Tech Tip: Really Simple HTTP Server with Python
- Doing for User Space What We Did for Kernel Space
- Rogue Wave Software's Zend Server
- Parsing an RSS News Feed with a Bash Script
- SuperTuxKart 0.9.2 Released