> Hello Amos, squid gurus and mortals, this is in part in reference to a > message from lorenor. I don't want to top-post lorenor so that being said > I would just like to say the absolute best way for a lot of folks to > <debug> their squid-cache issues is to turn on the debug_options. The > squid-cache debug_options default makes sense for beginning the use of > squid-cache but sorely needs attention if the user plans to make > productive use of the squid-cache. In light of the previous sentence I > have come up with a so-called optimal debug_options list for my instance > of squid. The term: optimal means to leave or reduce the debug_options > categories that are not needed or have no interest for the target squid > user. The chances of a universal optimal debug_options is not possible as > this needs to change for each user's instance of squid. I have listed my > debug_options below and I have a few questions for such a list: > > 1. What or how does tuning the debug_options affect squid reporting tools > such as: SARG? AFAIK, it does not affect SARG and most tools, which only process the access.log. Some tools which process the cache.log and warn admin about problems might require certain levels for certain warnings. I'm not aware of any such tools being publicly available, if people know of one, please speak up. > 2. What or which sections have been left out? see doc/debug-sections.txt for a list of the existing sections. > 3. Which sections have the wrong debug level? <some section>,1-9? There is no consistent use of debug levels: <section>,2+ at present its up to the code author and later bug fixers to select any given message and what level it has. > 4. Why was section 24 skipped? As you can probably see by looking at the list of sections the number selection has long since lost any pattern it may once have had for section:meaning maps. When a new section is needed, the code author selects one they want, makes a request and its reservation goes up for discussion with the main developers. > > ************************************** > debug_options 0,2 1,3 3,3 4,2 9,1 11,3 12,3 14,3 16,3 17,3 18,3 20,2 22,3 > 23,3 25,3 27,2 28,3 30,2 31,3 33,3 34,2 35,3 37,3 38,2 39,2 40,3 41,2 42,2 > 43,2 45,2 46,3 48,3 50,2 51,2 52,3 54,2 55,3 56,3 57,3 58,3 61,3 62,2 64,3 > 65,3 66,3 67,2 68,2 69,2 70,2 71,2 73,3 74,3 75,2 76,2 78,2 79,2 81,2 84,2 > 85,3 87,3 88,3 89,2 90,3 92,2 93,4 > The list depends entirely on what you mean by 'optimal'. There are several groups of users with different needs regarding cache.log. level 0 - critical messages with absolute minimal logging traffic to slow squid down. For very high performance people. level 1 - important messages and warnings. For most people who can afford the very minor extra disk logging time and space. Or people upgrading squid might find the new warnings useful. level 2-6 most other informative things. The output here is mostly section specific. Recommended to be set only on the required sections when trying to trace actual code paths through squid towards a bug, or something weird thats happening. Some few sections (IO types and garbage collection) produce a LOT of data here. level 7-9 mostly used for full data dumps of requests (headers, object content, buffer content, the lot). sections which use these levels definitely produce a LOT of data here. Every now and again we have an argument amongst the developers about formalizing the levels and how they are used. The last round got level 0-1 assigned a fixed meaning as I mention above. If you can come up with a good idea about how the rest of the levels might be used in squid submit the proposal to squid-dev. Amos
