On Tue, Dec 15, 2009 at 9:59 PM, Joey Smith <j...@joeysmith.com> wrote: > On Tue, Dec 15, 2009 at 02:27:30PM -0800, Michael Shadle wrote: >> 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. > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
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. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
