# [PATCH] fpm/typo: change some log about dynamic + homogenize log message about pool - Thread: https://externals.io/message/46415 - Original archive: https://news-web.php.net/php.internals/46415 - Started by jerome@loyet.net on 2009-12-14T20:16:53+00:00 - Messages: 9 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #46415 — jerome@loyet.net — 2009-12-14T20:16:53+00:00 URL: https://externals.io/message/46415#46415 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 --- ## #46419 — Antony Dovgal — 2009-12-15T09:14:52+00:00 URL: https://externals.io/message/46415#46419 > > […] > > 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 --- ## #46420 — Jani Taskinen — 2009-12-15T09:30:37+00:00 URL: https://externals.io/message/46415#46420 · In reply to: #46419 > > > […] > > Surely log_level is configurable. > Jerome just changed error level of some error messages to reduce the amount of notices in the log. I replied badly, I meant ALL the points in the mail. Configurable log entries, levels, etc. Not some static `fprintf()` stuff. :) --Jani --- ## #46421 — Antony Dovgal — 2009-12-15T09:37:42+00:00 URL: https://externals.io/message/46415#46421 · In reply to: #46420 > > […] > > I replied badly, I meant ALL the points in the mail. Configurable log > entries, levels, etc. Not some static `fprintf()` stuff. :) Well, now you've lost me completely. > 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 Configurable error messages, huh? > 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) Configurable error level for certain error messages? -- Wbr, Antony Dovgal --- http://pinba.org - realtime statistics for PHP --- ## #46422 — Tjerk Anne Meesters — 2009-12-15T12:19:45+00:00 URL: https://externals.io/message/46415#46422 · In reply to: #46421 The only two things that would come up after reading Jani's email is: 1) Make the log string configurable, such as CustomLog in apache 2) Configure the log level threshold, though I think that should already be there in the first place. > > > […] > > Well, now you've lost me completely. > > > […] > > Configurable error messages, huh? > > > […] > > Configurable error level for certain error messages? > > -- > Wbr, > Antony Dovgal > --- > http://pinba.org - realtime statistics for PHP > > -- > > > > -- -- Tjerk --- ## #46423 — jerome@loyet.net — 2009-12-15T12:24:13+00:00 URL: https://externals.io/message/46415#46423 · In reply to: #46422 2009/12/15 Tjerk Anne Meesters : > The only two things that would come up after reading Jani's email is: so am I > 1) Make the log string configurable, such as CustomLog in apache Yes but CustomLog is for access log, this feature is not present in php-fpm (should it be ?) All the log message (my patch is changing) are error, debug or warning message like: - WARNING: unable to open log file - php-fpm started well - unable to fork ... There is no way to make this configurable ... because it's totally useless > 2) Configure the log level threshold, though I think that should > already be there in the first place. Yes it's already in place > > > > […] > > > -- > -- > Tjerk --- ## #46424 — Antony Dovgal — 2009-12-15T12:25:16+00:00 URL: https://externals.io/message/46415#46424 · In reply to: #46422 > The only two things that would come up after reading Jani's email is: > 1) Make the log string configurable, such as CustomLog in apache CustomLog is needed in Apache because there are so much variables available. Here we have time, pid, function and line. With log_level=debug all of them are printed, in other cases only time gets into the log, which makes perfect sense to me. > 2) Configure the log level threshold, though I think that should > already be there in the first place. -- Wbr, Antony Dovgal --- http://pinba.org - realtime statistics for PHP --- ## #46435 — Michael Shadle — 2009-12-15T22:27:30+00:00 URL: https://externals.io/message/46415#46435 · In reply to: #46424 > Here we have time, pid, function and line. > With log_level=debug all of them are printed, in other cases only time gets into the log, > which makes perfect sense to me. +1 to Antony and Jérôme. Having a log format parameter seems a bit overkill for debug/internal messages. Unless php-fpm's logfile turns into some kind of access log that winds up being parsed, I don't see the need. 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'm thinking of something like APC's apc_cache_info() - returns a structured array of useful info. Then you could build anything you wish around it (although you would have to execute it through the FPM-enabled SAPI most likely) --- ## #46442 — Eddie Drapkin — 2009-12-16T03:29:39+00:00 URL: https://externals.io/message/46415#46442 > > > […] > > 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.