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:
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 to the previously mentioned warnings. In this case, it checks the size of the Squid process; if it exceeds the threshold, you get the warning in cache.log. On some operating systems, the process size can only grow and never shrink. Therefore, you'll constantly get this warning until Squid shuts down.
Process size information comes from either the mallinfo( ), mstats( ), or sbrk( ) functions. If these are unavailable on your operating system, the high_memory_warning warning won't work.
Squid has a number of other hardcoded warnings you may see in cache.log:
This occurs whenever Squid fails to look up the IP address for a cache neighbor. Squid refreshes the neighbor addresses every hour or so. As long as the neighbor's address is unknown, Squid doesn't send any traffic there.
Squid logs this message when it believes it can't communicate with a neighbor cache. This happens, for example, when too many consecutive ICP queries go unacknowledged. See Section 10.3.2 for more information.
This message indicates that a neighbor cache is refusing to answer Squid's queries. It probably means that you are sending queries to the neighbor without their permission. If they are using address-based access controls, and you have recently changed your address, they won't know about the change. Squid refuses to send any more queries to the neighbor after detecting this condition.
This occurs when you have an unauthorized cache client sending you ICP or HTCP queries. The best thing to do in this case is try to find out the person or organization responsible for the given address. Ask why they are querying your cache.
Recall that a forwarding loop occurs when a single request flows through Squid a second time. The request's Via header contains a list of all proxies that have seen the request. If Squid detects its own name in the Via list, it emits the forwarding loop warning and sends the request directly to the origin server. See Section 10.2 for an explanation of forwarding loops.
The client_lifetime directive places an upper limit on the duration for a single HTTP request. Squid warns you when such a request is terminated because it may indicate someone is abusing your cache with very long-lived connections, for example, by downloading infinitely long objects.
As you can see, cache.log provides only notification of abnormal events. For periodic monitoring, you need something else. The cache manager is perhaps the best choice, even though its interface is less than perfect.