[PATCH] fpm/typo: change some log about dynamic + homogenize log message about pool View as Markdown

Hi tony,

There is several things in this patch:

1- makes log message about pool concistent. I set it to "[pool %s]
message". Before there where different variants:
pool %s,
foo (pool %s) bar
[pool %s]
[%s]

2- corrects some log messages which were not very meaningful for end users

3- Some log level have been switched from NOTICE to DEBUG, so that the
log_file in normal operation would not be a nightmare to read (with a
lot of anoying and useless messages for end users)

Hope it helps
++ Jerome

3- Some log level have been switched from NOTICE to DEBUG, so that the
log_file in normal operation would not be a nightmare to read (with a
lot of anoying and useless messages for end users)

Wouldn't it make more sense to make this configurable? And thus allow
people to log how they prefer..

Surely log_level is configurable.
Jerome just changed error level of some error messages to reduce the amount of notices in the log.

--
Wbr,
Antony Dovgal

http://pinba.org - realtime statistics for PHP

However if people have ideas on how this will help or be useful (i.e.
you -are- planning on running logfiles or logwatch or something) then
it might be smart to bring it back to the table again. Jérôme and I
were talking about some way to grab statistics in real-time (as close
as they can be, obviously the connection counts can change rapidly)
and I thought it might make sense to have a PHP function which can
access that information. Originally he had mentioned a /url-prefix but
that seems a bit complex, having to configure it in the webserver and
such.

I don't use FPM, but I certainly am a heavy user of PostgreSQL's 'log_line_prefix'
configuration setting. For those who aren't familiar with it, check out the table
at http://www.postgresql.org/docs/8.4/static/runtime-config-logging.html for some
ideas on the kinds of information you can add (or exclude) from logfile lines. In
production enviroments, I don't use many of these, as any analysis done on them
will likely come hours (if not days) after the issue occurred; however, in a
development or staging environment, knowing something like the PID can be very
useful. It strikes me that these kind of rules might also apply in the FPM case -
but, again, I'm not actually using FPM, so maybe I'm wrong.

--

I can see this sort of thing being incredibly useful. I am using
FPM in production (dozens of sites, some share pools, some don't) and
if that level of logging was supported, a lot of application-level
logging that I'm doing would be rendered obsolete. It would be nice
to have a more granular approach to logging what went wrong (knowing
what worker, for instance, which I think is currently unavailable) and
enough information to re-create the problem. Because of the
operational model of FPM, I think that this idea would greatly improve
the SAPI, especially as part of a development idea.

Definitely a +1 to that idea.