Application Level ping: alp

Ron Jachim

The ability of users to access systems and the applications that reside on those systems is a fundamental concern in any organization, and ensuring such access is the most basic task of all systems administrators. The organizational concern is sufficient, in fact, that many, more sophisticated organizations have established service level agreements (SLAs) under which a specified level of access is guaranteed by the IT staff as part of the departmental charge-back arrangement.

What can you, as a systems administrator, do to address user concerns about system uptime? One approach is to utilize SNMP to log which hosts are up. This requires SNMP monitoring to be installed, which is expensive, complex, and can be inefficient. A less expensive solution is to set up a computer as a logging unit that uses the ping command to query each significant host and network device (e.g., every 10 minutes). This will allow you to demonstrate the uptime of your hardware and linkages.

Such a system-response arrangement is simplistic, however, in that it only shows half of the picture. What about the user who cannot access email because the IMAP server crashed? To that user, the system is still down, and your demonstrated uptime appears suspect.

One approach to monitoring applications is to run a script on the server to check the results of the ps command every 10 minutes or so. But what if you do not have control over that host? The answer is a single-sided socket client that tries to connect with the server application on the host. This amounts to an application level ping, or alp. While ping works at the lower regions of the OSI Reference Model, testing basic network connectivity, alp works at the higher regions of the OSI Reference Model, testing the ability to connect with applications.<>