Title: Monitor Services
Course: CIS 208: Linux/UNIX III: Intermediate System Administration, Networking, and Security ~ For IGNITE Review > Section: Learning Modules

Monitor Services

In the previous module we saw how resources on servers can be monitored, and there is another type of monitoring which is used for network services.  This type of monitoring consists of ensuring that services are responding in a timely manner and possibly notifying system administrators when key services are non-responsive.

For example, an organization may want to monitor several web servers to ensure that a web based application is running.  While it is possible to simply check that ports 80 and 443 respond, it would be possible that the application is failing while the ports are responsive.  Ideally there would be a test to ensure that a specific webpage opens and has specific content.  However this test could fail for many reasons, such as the web server not running, a database being unavailable, a change in DNS, a change in the firewall on the server, a changed IP address, a cable being unplugged or even a router not responding.

Creating a single test will not quickly identify the source problem, so it is common to create multiple tests for individual dependencies.  In this sense, a ping response from a router or a DNS lookup could be considered a service which can be monitored.  However, if several tests are implemented, many alerts could be issued, causing even more confusion.

The key to efficient monitoring is to create multiple tests and to establish a hierarchy of dependencies.  This allows multiple sources to be identified, but limits the number of alerts which are issued.  In the example mentioned above, the URL test for the webpage would depend on httpd responding.  The httpd service would depend on port 80 responding.  The port 80 test would depend on the IP address responding and it would depend on the router being up.  Likewise the httpd service, the database server and the DNS test would depend on the router being up.

In this scenario, if the router went down, every test would fail, but only one alert would be issued.  This would significantly speed up the process of troubleshooting why the application stopped working!  On the other hand, if httpd stopped responding while port 80 was responding, the sysadmin could quickly rule out network or firewall issues and could focus immediately on the httpd service.

In addition to alerting system administrators and assisting in troubleshooting, service monitoring can be helpful for others.  It is possible to allow users and managers to see when there is a problem and when things have returned to normal.  Also managers are often interested to see uptime reports showing the percent of time that services are up and running.