Apache is perhaps the most well known and widely deployed web servers, having originally been released back in 1995 and currently deployed on a large number of web servers (although losing ground to NGINX). As an important part of the classic LAMP stack, it is a critical component in your web serving architecture, and if you’re not currently – you should be monitoring Apache.
Enabling Apache monitoring with mod_status
Most of the tools for monitoring Apache require the use of the mod_status module. This is included by default but needs to be enabled. You will need to specify an endpoint in your Apache config:
<Location /server-status> SetHandler server-status Order Deny,Allow Deny from all Allow from 127.0.0.1 </Location>
This will make the status page available at http://localhost/server-status on your server. We have a full guide to configuring this. Be sure to enable the ExtendedStatus directive to get full access to all the stats.
Monitoring Apache from the command line
Once you have enabled the status page and verified it is working above, you can make use of command line tools to monitor the traffic on your server in real time. This is useful for debugging issues and examining traffic as it happens.
The apache-top tool is a popular method of achieving this. It is often available as a system package e.g. apt-get install apachetop but can also be downloaded from the source, as it is only a simple Python script.
Apache monitoring and alerting – Apache stats
Using apache-top is useful for real time debugging and examining what is happening on your server right now, but it is less useful if you want to collect statistics over a period of time. This is where a monitoring product such as Server Density will come in. Our monitoring agent supports parsing the Apache server status output and can give you statistics on requests per second and idle/busy workers.
Apache has several process models but the most common is to have worker processes running idle waiting to service requests. As more requests come in then more workers will be launched to handle them, up to a configured maximum. At that point the requests will be queued and your visitors will experience delays. This means it’s important not just to monitor the raw requests per second but also how many idle workers you have.
A good way to approach configuring Apache alerts is to understand what kind of baseline traffic your application experiences and set alerts around this e.g. alert if the stats are significantly higher (indicating a sudden traffic spike) and if the values are suddenly significantly lower (indicating a problem preventing traffic somewhere). You could also benchmark your server to find out at what traffic level things start to slow down and the server becomes too overloaded – this will then act as a good upper limit which you can trigger alerts at too.
Apache monitoring and alerting – server stats
Monitoring Apache stats like requests per second and worker status is useful to keep an eye on Apache itself, but its performance will also be affected by how overloaded the server is. Ideally you will be running Apache on its own dedicated instance so you don’t need to worry about contention with other applications.
Web servers are generally limited by CPU and so your hardware spec should offer the web server as many CPUs and/or cores as possible. As you get more traffic then you will likely see the CPU usage increase, especially as Apache workers take up more CPU time and are distributed across the available CPUs and cores.
CPU % usage itself is not necessarily a useful metric to alert on because the values tend to be per CPU or per core and you may have many cores. It’s more useful to set up monitoring on average CPU utilisation across all CPUs or cores. Using a tool such as Server Density, you can visualise this and configure alerts so you can be notified when the CPU is overloaded – our guide to understanding these metrics and configuring CPU alerts will help.
On Linux this average across all CPUs is abstracted out to another system metric called load average. It is a decimal number rather than a percentage and allows you to understand load from the perspective of the operating system i.e. how long processes are waiting for access to the CPU. The recommended threshold for load average therefore depends on how many CPUs and cores you have – our guide to load average will help you understand this further.
Monitoring the remote status of Apache
All of the above metrics monitor the internal status of Apache and the servers it is running on but it is also important to monitor the experience your users are getting too. This is achieved by using external status and response time tools – you want to know if your Apache instance is serving traffic from different locations around the world (wherever your customers are) and the kind of response time performance. You will then know at what stage you need to add more capacity, either by increasing the capabilities of the Apache server or by adding more into a load balanced cluster.
This is easy to do with a service like Server Density because of our in-built website monitoring. You can check the status of your public URLs and other endpoints from custom locations and get alerts when performance drops or there is an outage.
This is particularly useful when you can build graphs to correlate the Apache and server metrics with remote response time, especially if you are benchmarking your servers and want to know when a certain load average starts to affect end user performance.