Stacktrace includes entries with python's interanals

[WhyNotHugo]

In recent weeks, I've started noticing that many stacktraces contain details of calls inside python's log module (i.e.: all the handling insidelogging/__init__.py):

https://github.com/python/cpython/blob/3.8/Lib/logging/__init__.py#L1463
https://github.com/python/cpython/blob/3.8/Lib/logging/__init__.py#L1577
https://github.com/python/cpython/blob/3.8/Lib/logging/__init__.py#L1587
https://github.com/python/cpython/blob/3.8/Lib/logging/__init__.py#L950

This is very annoying and just makes stacktraces harder to see. This is obviously never shown by Python when emitting logs either.

Example event on sentry.io.

[untitaker]

You want to set https://docs.sentry.io/error-reporting/configuration/?platform=python#in-app-include to a list of module/package names that belong to your application, or inversely you can also use ..exclude to just exclude stdlib logging/celery frames etc

[WhyNotHugo]

I think this should be included by default, rather than me having to configure it.

I can't image any scenario were one might care about the internal calls that logging.error() makes inside the logging module.

These trace lines were not included in the past either.

[untitaker]

Do you have an example of an event where those lines were not included? I would agree about adding better defaults.

[WhyNotHugo]

Here's a few without those lines:

https://sentry.io/organizations/hobarrera/issues/1512741395/?project=124552&query=is%3Aunresolved&statsPeriod=14d

https://sentry.io/organizations/hobarrera/issues/1657959391/?project=124552&query=is%3Aunresolved&statsPeriod=14d

https://sentry.io/organizations/hobarrera/issues/1671976684/?project=124552&query=is%3Aunresolved&statsPeriod=14d

I'm seeing a pattern though: they're al either asserts or raise.

It seems it's always logged for logger.error or warning calls.

[untitaker]

I see, that's to be expected then. In any case it seems like we should have better defaults for in_app_exclude here.

[WhyNotHugo]

I think so too. Merely adding logging to the default should suffice.

[untitaker]

I looked into this a little bit and didn't find a lightweight way to figure out if a module belongs to the stdlib or not. My issue with just hardcoding a bunch of names is that the user can have a logging module that shadows stdlib, in which case not showing those frames would be a regression over the status quo (and worse than showing too many frames)

[RJPercival]

The problem appears to be this line:

sentry-python/sentry_sdk/integrations/logging.py

Line 209 in 3a7943b

"stacktrace": current_stacktrace(

Sentry generates its own stacktrace, ignoring the stacklevel parameter of the logging call. Instead, I suspect it should be using the stack_info attribute of the LogRecord that is provided to it, so long as that is set.

[github-actions]

This issue has gone three weeks without activity. In another week, I will close it.

But! If you comment or otherwise update it, I will reset the clock, and if you label it Status: Backlog or Status: In Progress, I will leave it alone ... forever!

---

"A weed is but an unloved flower." ― Ella Wheeler Wilcox 🥀