Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat(telemetry): include span fields in breadcrumb messages #7379

Merged
merged 2 commits into from
Nov 19, 2024

Conversation

thomaseizinger
Copy link
Member

This switches our sentry-tracing dependency to a fork that includes getsentry/sentry-rust#708. Recording our span fields with breadcrumbs is important to provide accurate context of the message. Without the span fields, the messages give us a lot less information.

Since the last release, the open issue on flush having a flipped return value got fixed as well.

Copy link

vercel bot commented Nov 19, 2024

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name Status Preview Comments Updated (UTC)
firezone ✅ Ready (Inspect) Visit Preview 💬 Add feedback Nov 19, 2024 5:31am

@thomaseizinger thomaseizinger added this pull request to the merge queue Nov 19, 2024
Merged via the queue into main with commit b4ab569 Nov 19, 2024
108 checks passed
@thomaseizinger thomaseizinger deleted the chore/sentry-add-breadcrumbs-spans branch November 19, 2024 18:54
github-merge-queue bot pushed a commit that referenced this pull request Nov 21, 2024
Reverts #7379.

Unfortunately, this doesn't actually work because those fields are only
recorded as part of spans that get sampled, see
getsentry/sentry-rust#617 (comment).
If we were to start recording all spans, we'd have a massive overhead
and send lots of spans to Sentry.
github-merge-queue bot pushed a commit that referenced this pull request Nov 22, 2024
One of Rust's promises is "if it compiles, it works". However, there are
certain situations in which this isn't true. In particular, when using
dynamic typing patterns where trait objects are downcast to concrete
types, having two versions of the same dependency can silently break
things.

This happened in #7379 where I forgot to patch a certain Sentry
dependency. A similar problem exists with our `tracing-stackdriver`
dependency (see #7241).

Lastly, duplicate dependencies increase the compile-times of a project,
so we should aim for having as few duplicate versions of a particular
dependency as possible in our dependency graph.

This PR introduces `cargo deny`, a linter for Rust dependencies. In
addition to linting for duplicate dependencies, it also enforces that
all dependencies are compatible with an allow-list of licenses and it
warns when a dependency is referred to from multiple crates without
introducing a workspace dependency. Thanks to existing tooling
(https://github.com/mainmatter/cargo-autoinherit), transitioning all
dependencies to workspace dependencies was quite easy.

Resolves: #7241.
github-merge-queue bot pushed a commit that referenced this pull request Dec 2, 2024
This is another attempt at fixing #7386. Previous PR was #7379. The
difference is, this time it works! In the following screenshot,
`handle_input` is a currently active span.


![image](https://github.com/user-attachments/assets/0845d566-8ca7-4ba2-8786-9c5819cdfd48)

I had to make some patches to Sentry, most notably:

- getsentry/sentry-rust#708
- getsentry/sentry-rust#712

The way we configure Sentry is quite tricky:

First and foremost, we need to understand that the `tracing` adapter for
Sentry has a `span_filter` configuration. When a span gets filtered out
there, the rest of `sentry-tracing` never sees the data in that span.
Thus, in order to capture variables from spans, we need to have a fairly
generous span filter. In this PR, we change this span filter to include
all spans except those on TRACE level.

Secondly, by default, the Sentry SDK doesn't send any spans to the
backend, i.e. the sampling rate is 0. Previously, we set the sampling
rate to 1.0 because the `span_filter` was already filtering out all
non-telemetry spans. A telemetry span is a concept that we invented. It
is a span that gets sampled at _creation_ time with a probability of 1%.
This is useful because creating a lot of spans is also expensive, so we
don't want to do it e.g. on a per-packet basis. With just these
configuration options, we now have a problem: We don't want to submit
all spans to Sentry but we need the `span_filter` to allow all spans
otherwise we can't capture the contextual fields from the span in
breadcrumbs. Luckily, the Sentry SDK has another configuration option:
`traces_sampler`.

The `traces_sampler` gets to compute a sampling rate for each individual
span. This allows us to discard all spans from being sent to Sentry
unless they are `telemetry` spans.

Resolves: #7386.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants