Introduce a new Sentry.logger interface

[solnic]

When config._experiments[:enable_logger] is true, the default Sentry.logger interface should support logging log events.

This is meant to implement the API as described here https://develop.sentry.dev/sdk/telemetry/logs/#public-api

More requirements described here: https://develop.sentry.dev/sdk/telemetry/logs/#implementation

Initial questions:

• Should we separate an internal logger for logging errors/crashes when things don't work in Sentry SDK? It seems like that's what Sentry.logger is used for now?
• Should we support multiple logging handlers, ie logging both to std output and via log events? For example should calling Sentry.logger.info("Hello") support sending a log event AND logging to other destinations?
• How should we set trace_id when it's not provided explicitly?

[sl0thentr0py]

Should we separate an internal logger for logging errors/crashes when things don't work in Sentry SDK? It seems like that's what Sentry.logger is used for now?

The current Sentry.logger should be renamed to internal_logger or sdk_logger or something, that is just debug logging for the SDK and should be completely separate from capturing log events that go over the network.

Should we support multiple logging handlers, ie logging both to std output and via log events? For example should calling Sentry.logger.info("Hello") support sending a log event AND logging to other destinations?

For now not, since we're still iterating. Note that what we're offering is Structured Logging so it is not the same as logging something locally with a string template. Ideally we want people to pass in the template AND the arguments separately that leads to nicer UX in the product.

As an example,

variable = 42
Sentry.capture_log("This is a statement with a #{variable}")

is not what we want ideally, but instead:

Sentry.capture_log('This is a statement with a #{variable}', variable: 42) 

which lets us do server side processing, indexing and so on. Because of this, multiplexing to stdout does not make that much sense.

How should we set trace_id when it's not provided explicitly?

we pull it from the currently active transaction/span/propagation_context, see
https://github.com/getsentry/sentry-python/blob/bbdf789902e3d8ee7940d7b7442934b0d6b8b30d/sentry_sdk/client.py#L917-L923