Output on STDERR during initialization: is there is a way to not having that? about laravel-bridge HOT 4 OPEN

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)

from laravel-bridge.

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?

from laravel-bridge.

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 🤔)

from laravel-bridge.

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

from laravel-bridge.