ref: deprecate old sentry handler

[Litarnus]

Adds a deprecation notice to the old Sentry Handler that is used to convert log messages into Sentry errors. The Handler existed in a time where Sentry had no native log support yet we still allowed to capture logs in some way.

Now that we have the LogsHandler, it is becoming increasingly confusing which one to use and what they are really doing, so we want to deprecate it for now and point everyone towards the new logs handler.

[mrtus]

Hi, this just became even more confusing I think. There is no alternative to the "old" Handler is there?

We do not make use of Sentry logs, so how are we supposed to replace a deprecated handler with an alternative that does not support the same behaviour?

Can you elaborate what we need to do?

Thank you.

[Litarnus]

Hi @mrtus. I recommend just vendoring the Handler into your codebase and use it from there.

Do you mind sharing what prevents you from using logs for this scenario?

[mrtus]

Hi @mrtus. I recommend just vendoring the Handler into your codebase and use it from there.

Do you mind sharing what prevents you from using logs for this scenario?

Hi, thank you for coming back on this @Litarnus.

We use Sentry for the error events, we do not make use of anything else Sentry offers, so also not logging.

LogsHandler has a comment that states ... https://github.com/getsentry/sentry-php/blob/master/src/Monolog/LogsHandler.php#L66-L69

// Do not collect logs for exceptions, they should be handled seperately by the `Handler` or `captureException`
if (isset($record['context']['exception']) && $record['context']['exception'] instanceof \Throwable) {
    return false;
}

Hence this if-clause, there is no reason for us to use the proposed LogsHandler... But Handler deprecation note now says we need (or we won't be able to upgrade to ^5.0) to use LogsHandler.

So we (and these statements) are a little bit conflicted on this "deprecation" that simply provides no alternative solution, unless we, ?what you say, copy over this Handler class and maintain it ourselves? Did I understand that correctly?
Where is the advantage then for Sentry to provide an SDK that can't help their consumers easily integrate with Sentry Errors feature?

We need that Handler to hook in into Monolog and process errors, we don't want additional code to integrate our applications with Sentry, that reduces maintainability, especially since we are implementing using Psr standards, so in this case Psr\Log\LoggerInterface.

Maybe I'm undestanding something entirely wrong here?

Do you have enough information to better understand our use-case? Can I do anything else to clarify?

Thank you for your input!

[Litarnus]

Thanks for taking your time to provide details, appreciate it.

I think my previous message came across a bit different that it was meant. If you want to remove the deprecation warning right now, the only way is to really maintain it yourself.

I want to clarify that the main reason we deprecate the Handler is to no longer emit log lines with a certain severity as sentry errors. The exception handling part was not intended to be removed, but rather we will add a new handler that will just send all exceptions from monolog to Sentry.

I apologize for the confusion and for not writing it in the deprecation notice or the PR. I created this issue which you can use to see the progress of it: #2060

[mrtus]

Thanks for taking your time to provide details, appreciate it.

I think my previous message came across a bit different that it was meant. If you want to remove the deprecation warning right now, the only way is to really maintain it yourself.

I want to clarify that the main reason we deprecate the Handler is to no longer emit log lines with a certain severity as sentry errors. The exception handling part was not intended to be removed, but rather we will add a new handler that will just send all exceptions from monolog to Sentry.

I apologize for the confusion and for not writing it in the deprecation notice or the PR. I created this issue which you can use to see the progress of it: #2060

Aha, that's alright, It indeed wasn't clear there would be a replacement coming up (I also like to jump to conclusions 🫣).

Then my only feedback; don't deprecate something without a clear alternative available to allow an in-place replacement at the moment it is deprecated, especially for something that is a core feature and the new implementation has a conflicting statement.

Thank you for your time @Litarnus and appreciate for creating the issue! 👌

[Litarnus]

Thanks for taking your time to provide details, appreciate it.
I think my previous message came across a bit different that it was meant. If you want to remove the deprecation warning right now, the only way is to really maintain it yourself.
I want to clarify that the main reason we deprecate the Handler is to no longer emit log lines with a certain severity as sentry errors. The exception handling part was not intended to be removed, but rather we will add a new handler that will just send all exceptions from monolog to Sentry.
I apologize for the confusion and for not writing it in the deprecation notice or the PR. I created this issue which you can use to see the progress of it: #2060

Aha, that's alright, It indeed wasn't clear there would be a replacement coming up (I also like to jump to conclusions 🫣).

Then my only feedback; don't deprecate something without a clear alternative available to allow an in-place replacement at the moment it is deprecated, especially for something that is a core feature and the new implementation has a conflicting statement.

Thank you for your time @Litarnus and appreciate for creating the issue! 👌

Absolutely fair and thanks for the feedback

[arueckauer]

Hello,

I'd like to join the discussion as we are affected by this change similarly to @mrtus. In our project, we rely on the SDK to capture two main things: 1) Exceptions and 2) Log messages above a certain level (Warning/Error) as Sentry Issues.

Following the deprecation of Sentry\Monolog\Handler, I’d like to clarify the roadmap for the Log-to-Issue workflow.

As I understand it:

1. The new LogsHandler targets the Sentry Logs API, meaning log entries appear in the Logs Explorer but do not create entries in the Issue Stream or trigger traditional Alerts.
2. While there is a plan to handle Exceptions within logs as Issues (#2060), "simple" log messages (e.g., $logger->warning('API response slow')) will likely remain exclusive to the Logs API in future versions.

Our Pain Point

We use Sentry primarily as an error-tracking tool where specific Monolog levels are expected to create actionable Issues. Transitioning to LogsHandler effectively removes these events from our Issue Stream. Having to switch to "Metric Alerts" on Logs to recreate this behavior would add significant configuration overhead for us and moves away from the "out-of-the-box" error tracking we value in Sentry.

Questions

• Since Handler is deprecated, is there a planned "successor" for the Log-to-Issue workflow in v5.0, or is the official stance that log-based Issues are being phased out in favor of the Logs API?
• If the latter, would the maintainers be open to a dedicated IssueHandler (or a similar bridge) to maintain this functionality?

Clarifying this would help us decide whether to stick with the deprecated handler for now or start implementing custom wrappers to maintain our current alerting and monitoring workflows.

Thank you very much!