Output on STDERR during initialization: is there is a way to not having that?

[micheleorselli]

Hey there,
the dev team I'm part of is using Bref to deploy a Laravel application on Lambda, using the Octane Handler, and things are going pretty smoothly, thank you Bref! 🙇

We do have a custom layer to send json structured logs to our own ELK-like service: we noticed that during the initialization phase, a couple of strings are written directly to STDERR (one, two). This is not great for our setup as it breaks the way we collect logs (in particular, those lines are detected as errors).

Is there a way to avoid that? We tried to override bref-init.php but is difficult to achieve. The best idea we could come up with is to use a composer script to do the override, but feels a bit too hacky.

The most straightforward way to deal with that would be removing those two lines, would it be something that you may consider?

Regardless of the solution, we are willing to work on that 🤗

[mnapoli]

Hi there! Logging to stderr is the default and recommended way to log on Lambda, that's why it is setup that way. That will send the logs automatically to CloudWatch. Moving away from that would be… risky? (not sure what the best wording is)

Bref itself logs a lot of things to stdout/stderr, is that not causing issues for you too? (said another way: I think what would need to be changed would be much bigger than just these two lines, or maybe I'm missing something)

[micheleorselli]

Hi!

Hi there! Logging to stderr is the default and recommended way to log on Lambda, that's why it is setup that way. That will send the logs automatically to CloudWatch. Moving away from that would be… risky? (not sure what the best wording is)

I get what you mean, in our case the main reason for that is reducing costs

Bref itself logs a lot of things to stdout/stderr, is that not causing issues for you too? (said another way: I think what would need to be changed would be much bigger than just these two lines, or maybe I'm missing something)

Maybe we still have to bump into those, as of now the two lines causing the issue are the one mentioned before. A search on the vendor/bref/bref and vendor/bref/laravel-bridge directories shows three places where this happens (one, two, three) but maybe there are more happening in the layers.

To reinstate that, writing to STDERR is fine, but it would be nice to have control on the structure of what is written (json rather than plain strings). I guess reusing the logger configured in the laravel app is not an option right?

[mnapoli]

in our case the main reason for that is reducing costs

Got it, thanks!

I guess reusing the logger configured in the laravel app is not an option right?

It isn't indeed because Laravel isn't booted (in all places).

it would be nice to have control on the structure of what is written (json rather than plain strings)

Right, so if all logs were written as JSON that would solve your problem? (I'm not saying it's what we should do, just trying to understand it all)

BTW how are you forwarding logs to ELK? Via a Lambda extension, or a Laravel logger? If via PHP code (Laravel logger) do you notice extra latency? (I'd imagine sending the logs over the network might add some 🤔)

[micheleorselli]

it would be nice to have control on the structure of what is written (json rather than plain strings)

Right, so if all logs were written as JSON that would solve your problem? (I'm not saying it's what we should do, just trying to understand it all)

Yes, that would solve the problem, on the condition that the json output follows a certain structure

BTW how are you forwarding logs to ELK? Via a Lambda extension, or a Laravel logger? If via PHP code (Laravel logger) do you notice extra latency? (I'd imagine sending the logs over the network might add some 🤔)

We do have a lambda extension, written in rust, that is language agnostic, as long the logs produced adhere to a certain json format.

In case of the PHP app mentioned before, we

• created a custom monolog processor to add contextual information about the current lambda execution
• created a custom monolog formatter to produce the output json with the right structure
• configured the logger to write on STDERR