Re: [PATCH] loglevels final: take2

[Randy Terbush <ra...@zyzzyva.com>]

> Multiline logging is not easily greppable... which is a really bad idea.
> Not to mention that lines from two httpds are easily mixed together.

We currently do it quite a few places in a less organized format, 
IMO. I agree that keeping messages on one line would probably be 
the best deal. syslog makes it quite easy to pull out entries for 
specific processes...

> errno has no meaning in the context of some errors.  It doesn't
> make sense to include it directly at the lowest level of logging.
> A wrapper that deals only with "in routine blat, such and such unix
> call failed: %s" should invoke the lowest level logging function.

We could not enable this other information for certain messages at 
say the APLOG_INFO level. I personally like the idea of supplying 
the ability to turn the level of information up by dropping a 
.htaccess file into an directory for example. By doing it this way, 
we control the format that errno, strerror() is supplied in.  ??

> End users aren't going to care about the file and line number.  Our
> errors should be verbose enough that we can easily derrive it ourselves.
> The line number is meaningless in any event, we almost never work from
> the same code that the users report errors on.

The default LogLevel won't supply line number information. That is 
really only a tool intended mainly for debugging code being worked 
on.


> Consider this warning in perform_idle_server_maintenance:
> 
> 	log_printf (server_conf,
> 		    "server reached MaxClients setting, consider"
> 		    " raising the MaxClients setting");
> 
	aplog_error(APLOG_MARK, APLOG_INFO, r,
		    "server reached MaxClients setting, consider
		     raising the MaxClients setting");
 
Output would be:
Jul 27 19:12:41 sierra httpd[16183]: [info]: server reached MaxClients setting, consider raising the MaxClients setting


> No useful errno, no need for a filename or a line number.  It directly
> tells the user what they should do.  It would be logged at warn level.
> 
> Dean
> 
> On Sun, 27 Jul 1997, Randy Terbush wrote:
> 
> > Below is the latest version incorporating some of the suggested 
> > changes, and my preferred log format. The changes below do not 
> > preserve existing logging format, but do make the output somewhat 
> > more consistant. System info is logged on the first line, supplied 
> > error string on the second. These examples are from syslog, thus 
> > the host, process id, etc. Output levels are tunable by configured  
> > LogLevel.

Re: [PATCH] loglevels final: take2

[Dean Gaudet <dg...@arctic.org>]

Ok sure, rather than hold up the process of rationalizing error logs any
longer I'll just go with the flow.  Go for it. 

I'm moderately concerned that you've got two dimensions of information
controlled by one log level.  One dimension is the relevancy of the log
entry (i.e. debug, warning, info, critical).  The other dimension is the
verbosity of the log entry. 

Dean

On Mon, 28 Jul 1997, Randy Terbush wrote:

> > Multiline logging is not easily greppable... which is a really bad idea.
> > Not to mention that lines from two httpds are easily mixed together.
> 
> We currently do it quite a few places in a less organized format, 
> IMO. I agree that keeping messages on one line would probably be 
> the best deal. syslog makes it quite easy to pull out entries for 
> specific processes...
> 
> > errno has no meaning in the context of some errors.  It doesn't
> > make sense to include it directly at the lowest level of logging.
> > A wrapper that deals only with "in routine blat, such and such unix
> > call failed: %s" should invoke the lowest level logging function.
> 
> We could not enable this other information for certain messages at 
> say the APLOG_INFO level. I personally like the idea of supplying 
> the ability to turn the level of information up by dropping a 
> .htaccess file into an directory for example. By doing it this way, 
> we control the format that errno, strerror() is supplied in.  ??
> 
> > End users aren't going to care about the file and line number.  Our
> > errors should be verbose enough that we can easily derrive it ourselves.
> > The line number is meaningless in any event, we almost never work from
> > the same code that the users report errors on.
> 
> The default LogLevel won't supply line number information. That is 
> really only a tool intended mainly for debugging code being worked 
> on.
> 
> 
> > Consider this warning in perform_idle_server_maintenance:
> > 
> > 	log_printf (server_conf,
> > 		    "server reached MaxClients setting, consider"
> > 		    " raising the MaxClients setting");
> > 
> 	aplog_error(APLOG_MARK, APLOG_INFO, r,
> 		    "server reached MaxClients setting, consider
> 		     raising the MaxClients setting");
>  
> Output would be:
> Jul 27 19:12:41 sierra httpd[16183]: [info]: server reached MaxClients setting, consider raising the MaxClients setting
> 
> 
> > No useful errno, no need for a filename or a line number.  It directly
> > tells the user what they should do.  It would be logged at warn level.
> > 
> > Dean
> > 
> > On Sun, 27 Jul 1997, Randy Terbush wrote:
> > 
> > > Below is the latest version incorporating some of the suggested 
> > > changes, and my preferred log format. The changes below do not 
> > > preserve existing logging format, but do make the output somewhat 
> > > more consistant. System info is logged on the first line, supplied 
> > > error string on the second. These examples are from syslog, thus 
> > > the host, process id, etc. Output levels are tunable by configured  
> > > LogLevel.
> 
> 
>