Squid_ The Definitive Guide - Duane Wessels [130]
How does an "access denied" response appear in the access.log?
Does store.log have the same number of, more, or fewer, entries than access.log?
Take a file number from store.log and find the corresponding file in the disk cache. Examine the file and make sure you've found the correct response.
Develop and implement a policy for archiving old cache log files. Consider where and how they will be stored, for how long, and who has permission to access them.
Chapter 14. Monitoring Squid
How can you tell if Squid is performing well? Does Squid have enough memory, bandwidth, and disk space? When the Internet seems slow, is it Squid's fault or a problem somewhere else? Is the operating system giving enough resources to Squid? Is someone trying to abuse or hack into my proxy? You can find the answers to these, and many more, questions in this chapter. Squid provides information about itself in three different ways: cache.log messages, the cache manager, and an SNMP MIB.
Squid writes various messages to cache.log as it runs. Most of these are abnormal events of one sort or another. Unfortunately, Squid isn't always smart enough to differentiate serious problems from those that can be safely ignored. Even so, cache.log is a good place to start when investigating a Squid problem.
The cache manager and SNMP interfaces allow you to query Squid for a variety of data. The cache manager, which has its own shortcomings, probably provides the most information in current versions of Squid. It has a TCP socket-based interface and tries to generate output suitable for both human and computer processing. The bulk of this chapter is devoted to explaining all the information available from the cache manager.
Squid supports SNMP as well. Unfortunately, the data available through SNMP is only a subset of the cache-manager information. Additionally, the Squid MIB has not evolved much over the years; it's essentially unchanged since its first incarnation. I'll explain how to make Squid process SNMP queries and describe all objects in the current MIB.
cache.log Warnings
This is one of the first places you should look whenever you perceive a problem with Squid. During normal operation, you'll find various warnings and informational messages that may or may not indicate a problem. I covered the mechanics of cache.log back in Section 13.1. Here, I'll go over a few of the warning messages you might see in your log file.
The high_response_time_warning directive makes Squid print a warning whenever the median response time exceeds a threshold. The value is in milliseconds and is disabled by default. If you add this line to squid.conf:
high_response_time_warning 1500
Squid will print the following warning if the median response time, measured over a 1-minute interval, exceeds 1.5 seconds:
2003/09/29 03:17:31| WARNING: Median response time is 2309 milliseconds
Before setting this directive, you should have a good idea of Squid's normal response time levels. If you set it too low, you'll get false alarms. In this particular example, it means that half of your user's requests take more than 2.3 second to complete. High response times may be caused by local problems, such as running out of file descriptors, or by remote problems, such as a severely congested Internet link.
The high_page_fault_warning directive is similar. It causes Squid to emit a warning if the number of page faults per minute exceeds a given value. A high page-fault rate usually indicates that the Squid process can't fit entirely in memory and must be swapped out to disk. This swapping severely impacts Squid's performance, so you should remedy the situation as soon as possible, as I'll discuss in Section 16.1.8.
Squid uses the Unix getrusage( ) function to get page fault counts. On some operating systems (e.g., Solaris), the page fault counter represents something besides swapping. Therefore, the high_page_fault_warning may cause false alarms on those systems.
The high_memory_warning directive is also similar