sentry-python: Provide a means for capturing stack trace for messages that are not errors

It would be useful if you could override this on single calls though. The use case I have is to have it enabled by default, because it provides more info (with logging in particular), but would like to avoid it with a custom sentry_sdk.capture_message("Initialized Sentry") (where/when logging is not configured yet, but also there it would not be possible to turn it off for a particular logging message anyway).

As it stands you’re the first one I know who both has a usecase like this and is sufficiently dissatisfied with the UX around it to want additional API surface. So you have to understand that this is not something we want to change right now, especially considering that this thread contains multiple workarounds that are not even fragile or rely on unstable API, instead they are just verbose.

The simplest suggestion with before_send, that I think I didn’t elaborate enough on, would look like this (untested):

import logging, sys

from sentry_sdk.integrations.logging import LoggingIntegration
from sentry_sdk import *

def before_send(event, hint):
    if event.get('level') not in ('debug', 'info', 'warning') or event['extra'].get('sentry_force_send_event'):
        return event

init(DSN, integrations=[LoggingIntegration(event_level=logging.WARN)], before_send=before_send)

#sys.exc_clear()
logging.warn("Hi! I am an event", sentry_force_send_event=True, exc_info=True)

Admittedly I don’t really understand whether you can’t or don’t want to use the logging integration to do this. It seems to me like the above would work perfectly fine regardless of whether you use structlog besides it.

Right, you don’t have a stacktrace attached here, that’s why you also get no locals. We only attach local variables in the context of a stacktrace.

We (or at least I) are trying to move people away from instrumenting our SDK explicitly and instead use logging mechanisms that are native to the platform (in this case Python). In my view there’s potential to make Sentry error reporting through logging a better experience than using capture_* everywhere explicitly. For once because users will get a lot of value out of the box from Sentry (assuming they already use logging to some degree) and also because existing customers would probably apprechiate not tying their codebase to Sentry too much. Of course Raven already had integrations but I think we can go further than that. Perhaps this goal is not achievable in a way that makes it possible to fine-tune behavior where necessary, but it’s worth a try IMO. I hope this somewhat explains why the current API is how it is.

So you say the logging integration is not a good substitute, but I want to try making it one. Given your constraints, perhaps your actual problem is that the integration logger level is not configurable per-logger? We still expose logging handlers that you can explicitly register: https://docs.sentry.io/platforms/python/logging/ So I wonder if in your case it’s appropriate to register those handlers explicitly (with individual handler levels) and disable the logging integration altogether.

The part about threads vs stacktraces is a different topic, I will respond separately to that, but I gtg right now