-
-
Notifications
You must be signed in to change notification settings - Fork 463
fix(logs): use PSR log level when using PSR-3 logger #1907
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
return \Psr\Log\LogLevel::CRITICAL; | ||
case 'info': | ||
default: | ||
return \Psr\Log\LogLevel::INFO; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure what's a good default level here but also this shouldn't really occur
The one existential question I have is what does it mean if Sentry is logging a fatal error successfully? Does that mean Sentry is working normally - i.e. it's not really e.g. critical? :) |
@mfb could you clarify your message above, as it raises some questions we do not fully understand. |
If you look at HttpTransport, it logs at info level when an item is sent (whether debug or fatal); warning if rate limit is hit; error if sending fails. I was referring to how you're using a different philosophical approach with SDK logging for log items, by choosing a level based on the payload rather than how the SDK is functioning. |
// We check if it's a `LogsLogger` to avoid a infinite loop where the logger is logging the logs it's writing | ||
if ($sdkLogger !== null) { | ||
$sdkLogger->log((string) $log->getLevel(), "Logs item: {$log->getBody()}", $log->attributes()->toSimpleArray()); | ||
$sdkLogger->log($log->getPsrLevel(), "Logs item: {$log->getBody()}", $log->attributes()->toSimpleArray()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What (I think) @mfb points out is that we copy the log level from the log item instead of logging always as "DEBUG" or "INFO" and mentioning the log level of the log item in the log message.
This was introduced by me I think, this maybe should be updated to mention the log item level in the log message and set our log level to debug (?).
In addition, the comment above this if
is outdated and incorrect :) The LogsLogger
never made it in but the comment remains 🙈
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
https://develop.sentry.dev/sdk/telemetry/logs/#other this is by design.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In that case I did this very by the book 😎
Then maybe the comment could be updated but no other changes are needed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, great - as long as it's by design :)
It's not 100% clear to me but I guess "appropriate" is saying the Sentry log level should be translated to an appropriate level, e.g. log a "fatal" to the console as "critical". I'd also find it reasonable to just print the "fatal" level as part of an "info" log message - either way works for me.
Fixes an issue where we use a PSR-3 logger in the
LogsAggregator
but pass SentryLogLevel
into it, which might lead to errors in different loggers as they expect PSR-3 levels.Closes #1902