Configuración del canal de registro y autoconexión

Hey @davidmintz!

(1) The logger config is... complex. It is definitely NOT one of my favorite parts of Symfony. Monolog is great - but the flexibility of how it handles channels and loggers is quite difficult to "express" in YAML. And so, honestly, I get a little lost in the YAML config for monolog also. I would NOT have thought that there would be anything special about "app". If that's true, that is very strange behavior! There is no existing, core handler or channel called "app", so I can't think of why this would cause any conflict. So, big shoulder shrug on this point - but you got it working, so that's good :p

(2) The ConsoleHandler is kind of a weird one :). Its job is simple: when you run a console command, based on the verbosity you're using to run the command (e.g. -vv), it will output log messages to your terminal. The way it does this is a little odd. On a monolog level, it is always active and it should receive all messages. But, unless it detects that a console command is currently executing, it just skips doing anything with the messages. So, during a web request, it receives all log messages, but then does nothing.

Anyways, that wasn't the "meat" of your question :). As I mentioned, the monolog config is tricky. To make it easier, I'll refer to this example config: https://github.com/symfony/recipes/blob/96d11c2e2ed2a33a796740ed47de0d6d25263fe8/symfony/monolog-bundle/3.7/config/packages/monolog.yaml#L40-L61

In theory, EVERY log message should be passed to EVERY handler you have. So in this case, any log message (at any level and at any channel) would be passed to each of those 4 handlers. But, there are several caveats:

A) Each handler has an optional channels config where they can choose to only receive messages for a specific channel... or for all channels except certain channels (e.g. !event which means "not the event channel). Internally, iirc, the result of this is that if you have a channel called foo, then it either will or won't "have" a handler based on the handler's channels config. What I mean is: it's NOT that a handler will receive a message and then skip it due to its channels config. Nope, internally, the channels config is read and then the handler is "applied" to all logger channels that meet the channels criteria.

B) I mentioned that "EVERY log message should be passed to EVERY handler you have". That is true... except for nested handlers. What is a "nested" handler? It is any handler that is referred to by another handler. For example, because the main (type: fingers_crossed) handler refers to the nested handler (via handler: nested), Monolog now knows that the purpose of the nested handler is just to receive messages from this handler. And so, the nested handler will suddenly NOT receive ALL messages: it will only receive messages forwarded to it by the main handler. So, a better statement would be:

EVERY log message will be passed to EVERY handler that is NOT referred to by another handler.

So, to your question:

Anyway, the question is: how do you configure a logger to write to a particular destination exclusively?

You should be able to do this by:

1) Creating a new logger channel (e.g. stuff)
2) Making a new handler with channels: [stuff]
3) Add channels: [!stuff] to any other top-level handlers that should ignore this channel.

So probably step (3) is what you're missing. However, we DO log things like you are describing and we typically skip step 3. Why? Well, on production, by default, only logs from requests with errors are logged. So, suppose I have some info level logs going to some stuff.log file all the time - even for non-error requests. Cool. Now, one page DOES have an error. Do I really care that the stuff channel logs are included in the error logs for that one request? Typically, when you have an error, the more logs the better to help you figure out what was happening on that request.

Let me know if this helps!

Cheers!

Hey @weaverryan! Thank you for the characteristically prompt, detailed and lucid reply. Yes it definitely helps, and after I read it five or six more times slowly it will help even more :-)

Maybe the use of "app" as a name wasn't the source of my woes. I know the golden rule about this: only change one thing at a time, so that when it works you'll know what worked. I didn't think I changed >1 thing, but maybe....

OMG I'm reminded of another question, sorry! That is: suppose you want to name a log file dynamically, e.g.,

$logfile = sprintf('app.%s.log',date('Y-m-d'));

Hey @davidmintz!

$logfile = sprintf('app.%s.log',date('Y-m-d'));

Because the log files are in YAML (and, more technically, because their values are compiled into Symfony's container), the best choice for making something dynamic is to use environment variables... along with a custom "env var processor". But, before we run down that road, if all you really want is "log rotation", check out the rotating_file handler - it's described on this blog post - https://eidson.info/post/rotating-logs-symfony

I haven't used that personally before, but I believe this is its exact use-case.

Cheers!

Hey ahmedbhs!

Hmm. Maybe... it depends on exactly what you're looking for. Messenger itself already sends all of its logs to a channel called "messenger". So that would be all the messages that say that a message is being received, handled, etc. You can easily send all messages from this channel to a special log file doing the same thing we do in this chapter, which is the same thing you can see here: https://symfony.com/doc/current/logging/channels_handlers.html

But technically, when you process a message, a LOT of things in the system might log, and those might log to all kinds of channels. If you wanted to capture all of that, the easiest way may be to actually pass the output of the messenger:consume command itself to some log file - something like php bin/console messenger:consume -vv | tee messenger.log (tee is just a unix utility that will write to a file, but still output to the screen).

Let me know if this helps!

Cheers!

Hey aliemre!

Hmm. I'm not aware of anything that changed, but I could always be wrong ;). I'm curious: after you create the messenger_audit channel in config/packages/monolog.yaml, what do you see when you run this command:

php bin/console debug:autowiring log

You should see one logger mentioned for each channel. You WILL see a logger for the messenger channel (service id monolog.logger.messenger) because that's actually defined by Symfony itself. But you should also see one for our custom logger. Double-check that spot and let me know if you'd like :O.

Thanks for the cool tutorial! PS: I am not able to watch the video. As far as I understand through the script

I'm really happy that the scripts + code have been useful :).

Cheers!