Open JanTvrdik opened 6 years ago
I've had a similar approach. I've separate some useful methods from logger (https://github.com/contributte/logging/blob/master/src/Utils/Utils.php) into Utils, same as you. I've also implemented some loggers, for example ComposedLogger[logger1, ...., loggerN], which accept a multiple loggers and call log()
for each of them. There's some case I would like to send API call to sentry and also save the file if sentry is not responding. There could be some basic implementation of Loggers in Tracy, don't you think guys? I mean StreamLogger (save bluescreen to file), MailLogger (send bluescreen to email), Stdout/StderrLogger (for docker) and so one.
Personally, I would prefer to merge the simplest solution that will enable logging into the stderr (solution A) to the v2.4 than big refactoring of loggers which is a much more complex task and requires a lot of hacks.
New logger scheme without hacks would be great for Tracy 3.
@dg How about https://github.com/nette/tracy/pull/283?
@dg Agree.
@JanTvrdik @f3l1x Do you want to deal with this?
The plan is to release version 3.0, where logging can be solved in a completely different way even with BC breaks.
Do you want to release 3.0 and after that rewrite logging?
No. What I'm trying to say is that now is the time.
I've prepared PR (https://github.com/nette/tracy/pull/556).
Description
To make Tracy work well with Docker, it needs to log to stdout or stderr. This is currently possible, but not easy to do. In this issue I'd like to discuss how we can make this common use-case easier.
The logger needs to be configured before or during
Tracy::enable()
call, otherwise errors which occur afterTracy::enable()
and beforeTracy::setLogger()
will not be logged to stdout/stderr. Logging of error which occur beforeTracy::enable()
is handled by PHP itself (by configuringerror_log
andlog_errors
php.ini options).Current solution may look like this
This is solution is ugly (we don't use most of Tracy\Logger, only the
formatMessage
method) and way to long to write.Proposed Solution A
Proposed Solution B (my preferred choice)
Note that in both cases, generating bluescreens will be disabled. This is not a problem for me, because after DI container is successfully compiled and initialized, a smarter (and more complex) logger will be used instead which handles this. But maybe other people have different requirements and use-cases so that should be probably considered as well.