Squid: The Definitive Guide
| < Day Day Up > |
| You already know from Section 13.1 that cache.log contains various operational messages Squid thinks are important enough to tell you about. We also refer to these as debugging messages. You can use the debug_options directive to control the verbosity of messages that appear in cache.log . By increasing the debugging levels, you'll see more detailed messages that may help you understand what Squid is doing. For example: debug_options ALL,1 11,3 20,3 Every debugging message in the Squid source code has two numeric attributes: a section and a level . Sections range from 0 to 100, and levels range from 0 to 10. In general, section numbers correspond to particular components of the source code. In other words, all the messages within a single source file have the same section number. In some cases, multiple files use the same debugging section. This tends to happen when a source file becomes too large and is split into smaller chunks . The top of each source file has line that mentions the debugging section. It looks like this: * DEBUG: section 9 File Transfer Protocol (FTP) I don't expect you to look at the source files to find the section numbers. The same information appears here in Table 16-1. Table 16-1. Debugging section numbers for the debug_options directive
Debugging levels are assigned such that more important messages have smaller values and less important messages have higher values. Level is for very important messages, while level 10 is for those that are relatively unimportant. Other than that, there are no strict guidelines or requirements. Developers are generally free to choose which debugging levels are appropriate. The debug_options directive determines which messages appear in cache.log . Its syntax is: debug_options section , level section , level ... The default setting is ALL,1 such that Squid prints any debugging message with level 0 or 1. If you want to make even less output appear in cache.log , you can set debug_options to ALL,0 . If you want to see additional debugging for a particular component, simply add the appropriate section and level to the end of the debug_options list. For example, this line adds level 5 debugging for the FTP server-side code: debug_options ALL,1 9,5 As with other configuration directives, you can change debug_options , then send Squid the reconfigure signal: % squid -k reconfigure Note that the debug_options parameters are processed sequentially, and a later value can override an earlier one. This is of particular concern if you use the ALL keyword. Consider this example: debug_options 9,5 20,9 4,2 ALL,1 In this case, the final value overwrites all of the preceding settings because ALL,1 sets the debugging level to 1 for all sections. Selecting appropriate debugging sections and levels is sometimes quite difficult, especially for novice Squid users. Many of the more detailed debugging messages are meaningful only to developers and those familiar with the source code. Inexperienced Squid users are likely to find many of the debugging messages meaningless and overwhelming. Furthermore, you may have difficulty isolating the debugging for a particular request or event if Squid is relatively busy. The higher debugging levels are often more useful if you can test Squid with one request at a time. You must also be particularly careful about running Squid with high debugging levels for a long amount of time. If Squid is busy, the cache.log file grows very quickly and may eventually consume all free space on its partition. If this happens, Squid exits with a fatal message. Another concern is that performance may degrade significantly. Due to the high number of debugging messages, Squid devotes a lot of CPU resources to formatting and printing strings. It also consumes a lot of disk bandwidth writing them all to cache.log . |
| < Day Day Up > |