mirror of
https://github.com/outbackdingo/firezone.git
synced 2026-01-27 18:18:55 +00:00
8bc1277c24
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.  I had to make some patches to Sentry, most notably: - https://github.com/getsentry/sentry-rust/pull/708 - https://github.com/getsentry/sentry-rust/pull/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.