Nagios is the Industry Standard Network Monitoring Engine. OK great so what’s that mean, well Nagios is a server that monitors your hosts and services and will inform you if something goes wrong and when it is fixed again. It can monitor network services, host resources and even network probes such as temperature and moisture.

These features as well as many more make Nagios, by far, the most complete open-source Network Monitoring tool on the market, however with all these features comes complexity and Nagios has obviously been designed with the experienced Network Administrator in mind. But don’t worry too much, its not that difficult to learn as long as you take it one step at a time, and in today’s tutorial we’re going to look at the first step, actually getting it installed

So let’s get started, the first thing we need to install in LAMP as this is the base in which runs, simply type in the following command in your terminal and follow the onscreen commands:

sudo tasksel install lamp-server

For more information on LAMP you can view my complete LAMP server tutorial here

Now we need to install Nagios, to do this type:

sudo apt-get install -y nagios3

This will install and configure Nagios 3 along with any the required dependencies you don’t already have. It may ask for a few input parameters such as internet address and login password, just follow the onscreen guidelines and you should be fine.

If you have completed these stops correctly you should be able to view your Nagios dashboard by typing in the following in your web browser substituting [IP ADDR] for your servers IP address.

http://[IP ADDR]/nagios3/

You’ll need to enter a username and password. Your username will be ‘nagiosadmin’, the password will be the same as the one you entered during setup.

Username:nagiosadmin
Password:entered during setup

Add hosts to your Nagios Server

No you have Nagios up and running you should be able to see your current server stats, (if not click on “Services” on the left side of the Nagios dashboard), but what if you want to add more hosts. Well it’s a little complicated at first but once you get used to it you’ll be fine. First we need to edit some config files to tell Nagios to monitor a new host, below is a diagram of all the Nagios config files:

define host{
        use                     generic-host            ; Name of host template to use
        host_name               localhost
        alias                   localhost
        address                 127.0.0.1
        }

Here we can see then the template is generic-host, the hostname and alias are set to localhost(127.0.0.1) and the address is set to 127.0.0.1. The use filed is important as if you enter a name here that doesn’t correspond to a template then Nagios will fail to start. The address field is also important, this is where you put the actual address for the server you want to monitor (either domain name or IP will work here). The host_name and alies fields are not as important and are only there to help the user distinguish between hosts. The difference between the two is host_name is read internally (so don’t use spaces or special characters) and alias is actually show to the user (you can use spaces and special characters).

So now it’s time to add your own host to your Nagios server, in this example we are going to add www.google.com as your new host, if you want you can subtitle your own attributes however I like to have Google as a host just to ensure my setup is correct. So start your favourite text editor and add the hollowing lines to the end of your /etc/nagios3/conf.d/localhost_nagios2.cfg

define host{
        use                     generic-host            ; Name of host template to use
        host_name               google
        alias                   Google
        address                 www.google.com
        }

to see the changes on your dashboard you need to restart Nagios, type:

sudo /etc/init.d/nagios3 restart

Now if you want to add your own hosts to your Nagios server repeat the last two steps substituting host_name, alias and address to your hosts details and restart Nagios to see the changes.

Please leave any comments or questions, thanks.

cd /usr/local/src
sudo wget http://prdownloads.sourceforge.net/sourceforge/nagios/nagios-3.2.2.tar.gz
sudo tar xvzf nagios-3.2.2.tar.gz
cd nagios-3.2.2
sudo ./configure --prefix=/usr/local/nagios --with-nagios-user=nagios --with-nagios-group=nagios --with-command-group=nagcmd --enable-nanosleep --enable-event-broker
sudo make all
sudo make install
sudo make install-init
sudo make install-commandmode
sudo make install-config
sudo update-rc.d -f nagios defaults
cd ..

ENHANCEMENTS

* Patch to new_mini_epn to allow any command line length without breaking on extra trailing or leading whitespace (Ray Bengen)
* Patch to mini_epn to allow any command line length (Thomas Guyot-Sionnest)
* Patch to speed up loading of state retention data (Matthieu Kermagoret)
* Custom notifications are now suppressed during scheduled downtime (Sven Nierlein)
* Added code to warn user about exit code of 126 meaning plugin is not executable (bug #153)
* Scheduled downtime can now start on SOFT error states (bug #47)
* Main window frame URL can now be specify with a “corewindow=” parameter
* Improved config CGI shows commands, command args in an easier to use manner (Jochen Bern)
* Added ability for NEB modules to override execution of event handlers (Sven Nierlein)
* Custom macros are no longer cleaned/stripped as they are user-defined and should be trusted (Peter Morch)

FIXES

* Fix for choosing next valid time on day of DST change when clocks go one hour backwards
* Fix for nagios now erroring when “Error: Could not find any contactgroup matching…” displayed
* Fix tap tests for Solaris 10 and newer versions of Test::Harness
* Fix for notifications not being sent out when scheduled downtime is cancelled (Daniel Pouzzner)
* Fix for first notification delay being calculated incorrectly, and notifications potentially going out early (Pawel Malachowski)
* Fix for text of scheduling downtime of all services on a host (Holger Weiss)
* Fix for services inheriting notification period from hosts if not defined (Gordon Messmer)
* Fix for incorrect service states on host failures (bug #130 Petya Kohts)
* Fix for incorrect service state attributes being set on host failures (bug #128 Petya Kohts)
* Fix for non-scheduled hosts and services not being updated in NDOUtils
* Fix for typos in TAC, CMD CGIs (bugs #150, #144, #148)
* Fix for types in documentation (bugs #145, #105, #106)
* Fix for incorrect host state counts in status CGI when viewing servicegroups (bug #72)
* Fix for new Splunk integration query parameters (bug #136)
* Fix for extra field header in availability CSV export (bug #113)
* Fix for macro processing code modifying input string (Jochen Bern)
* Fix for update check API
* Fix for CGI speedup when persistent=0 for comments
* Fix for event execution loop re-scheduling host checks instead of executing them if service checks are disabled (bug #152)
* Fix for segfaults on Solaris (Torsten Huebler)
* Fix for incorrect comment expiration times being passed to event broker (Mattieu Kermagot)
* Doc updates related to cleaning of custom macros (Peter Valdemar Morch)
* Fix to sample notify-service-by-email command (bug #62)
* Fix for retaining host display name and alias, as well as service display name (Folkert van Heusden)

This is a great way to scale you applications, before you had to make your applications scalable in a cluttered environment, that meant that when the load increased on your servers you would add new instances to handle the load. Your application must then be able to handle and use new instances in order to increase latency.

Developing applications to work across several instances is quite complex and therefor increases development time. With this new feature you will not have to worry so much about running your applications across several servers as you’ll be able to upgrade the single server to handle the load.

There is of course some pitfalls to relying on this kind of system, that being what happens when you reach the fastest instance type and you still need more power, well you’re going to have to add more instances and have a system that can accommodate this. The second is you can only upgrade and instance type with a stopped instance, therefore if you want to increase your power you’re going to have to stop your service. A simple way around this problem would be to start up an identical instance, switch your service to it, then upgrade your existing instance and switch back to it. Even with these small problems EC2 remains a great platform for testing and implementing small-scale applications and the ability to increase the instance type is a great addition to the great service Amazon Web Services.

So does it live up to expectations, well I’m going to run some LINPACK benchmarks on this new instance to see how fast it relay is, and compare it to the other amazon instances. So…

Well, I didn’t expect that, obviously I knew it was going to be much faster then the “m1.small” instance, but I didn’t think it would be much faster then “c1.xlarge” and it turns out the new cc1.4xlarge its nearly twice as fast. The nice thing about using LINPACK as a benchmark is we can directly compare it to the www.top500.org top 500 supercomputer list and the new “Cluster Compute Quadruple Extra Large” has around the same CPU as the “Thinking Machines Corporation CM-5/1024” which was one of the fastest supercomputers in the world in 1994.  Being able to cluster this kind of power over a 10Gigabit Ethernet connection gives us a  huge amount of CPU power, good luck finding something to do with it though. For more info on amazons new Cluster Compute instance go to http://aws.amazon.com/ec2/hpc-applications/.