You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
### Description
Logs and metrics were going through a completely separate pipeline
compared to other events.
Conceptually, they're still different from regular events since they're
more lightweight and attribute-based (no data, contexts, etc.,
everything is an attribute) so separate handling makes sense. However,
the pipeline should still conceptually resemble the one we use for other
event types, for consistency.
## Current pipeline for non-log, non-metric events
- The top-level API calls `scope.capture_XXX`. This merges the active
scope stack (global + isolation + current scope) and calls
`client.capture_XXX` with the resulting merged scope.
- `client.capture_XXX` contains virtually all of the logic, most
notably:
- It applies the scope to the event by calling `scope.apply_to_event`,
populating contexts, user data, etc.
- It serializes the event.
- It constructs the final envelope and sends it to the transport.
## This PR
- Instead of the logging/metrics functionality going straight to
`client.capture_XXX`, we call `scope.capture_XXX`, like we do for other
event types, and then call `client.capture_XXX` from there.
- Instead of inlining (and duplicating) all the attribute logic,
`client.capture_XXX` now calls a new `scope.apply_to_telemetry` function
internally (akin to `scope.apply_to_event`, but sets attributes
instead).
- The rest of the pipeline was left as-is for now, so metrics and logs
are directly put into the batcher which itself serializes them. It's
questionable whether making this part of the pipeline more similar to
the event one would be a good idea since in Span First it'll be
beneficial to have unserialized telemetry in the buffer, as is the case
now with logs and metrics.
Additionally:
- Unify attribute-related types
- Move duplicated `format_attribute` to utils
Re: naming: I'm calling the new-style, attribute-based things simply
"telemetry", since not all of them are events (for example, spans v2
which are coming with span streaming).
Note: I might refactor further. I'd like to have proper classes for Logs
and Metrics and give them ownership of how to serialize themselves, how
to call before_send, etc., but need to see whether there's a nice way to
do this without breaking backwards compat (the log/metric needs to be a
dict in before_send_x).
#### Issues
<!--
* resolves: #1234
* resolves: LIN-1234
-->
#### Reminders
- Please add tests to validate your changes, and lint your code using
`tox -e linters`.
- Add GH Issue ID _&_ Linear ID (if applicable)
- PR title should use [conventional
commit](https://develop.sentry.dev/engineering-practices/commit-messages/#type)
style (`feat:`, `fix:`, `ref:`, `meta:`)
- For external contributors:
[CONTRIBUTING.md](https://github.com/getsentry/sentry-python/blob/master/CONTRIBUTING.md),
[Sentry SDK development docs](https://develop.sentry.dev/sdk/), [Discord
community](https://discord.gg/Ww9hbqr)
0 commit comments