Span-based Metrics

[Dhrumil-Sentry]

A few months ago we made the difficult decision to not release our generic Metrics solution which was in Beta. We understand this has been frustrating for many users, but after thorough evaluation, we determined there were strong reasons to take this step:

• Lack of flexibility: Traditional metrics solutions require developers to predefine tags and aggregation rules, which limits their ability to drill down and analyze data retrospectively. This approach hinders effective debugging, as unexpected issues cannot be investigated beyond predefined metrics. We believe that allowing developers to query raw data flexibly is the best way to resolve complex application health issues.
• Low confidence in affordable pricing: Our goal is to offer products at price points that make them accessible to all developers. However, we were not confident in finding a near-term solution that would have achieved this for the generic metrics solution we built.

Our Path Forward

We’re excited to introduce Application Metrics, now available for a limited cohort of customers. It lets you easily aggregate and analyze span data without being restricted by predefined configurations or fixed parameters. Unlike traditional metrics setups, it gives you the flexibility to adjust your queries and groupings as needed.

What Use Cases Can Application Metrics Solve?

Application Metrics supports a variety of use cases, offering improved visibility into application health and making it easier to debug and troubleshoot errors and slowdowns.

1. Track API Latency and Identify Anomalies: Monitor the 95th percentile of time taken for API responses, grouped by customer, to identify if any users are overusing the system.
2. Monitor Payload Sizes in Background Jobs: Track the average payload size in background job processing to prevent slowdowns.
3. Track Token Usage for Third-Party APIs: Ensure that requests to external APIs like OpenAI stay within limits by tracking token usage per request which you slice by your customer segments
4. Monitor LCP (Largest Contentful Paint) for Specific Users or Pages: Monitor LCP for high-value users on the checkout page to identify page load issues that may impact revenue.

How can you use Application Metrics?

Attach attributes/tags to your spans via SDKs

You can add any custom attribute to your spans via our SDKs and use these attributes for filtering and aggregation in our UX. Here’s an example from our React SDK:

const span = Sentry.getActiveSpan();
if (span) {
  span.setAttribute("customerType", "Premium");
  // Or set multiple attributes at once:
  span.setAttributes({
    "payloadSize": 42,
    "cached": true,
  });
}

Use the new Trace Explorer to query and aggregate your spans

To support flexible, real-time queries on application metrics, we’re introducing an upgraded Trace Explorer UX (Go to Explore→Traces) making it easy to:

• Filter and aggregate span data based on attributes like duration, custom fields, and endpoints.
• Visualize high-level metrics or drill down into specific span samples.
• Switch seamlessly between viewing span aggregates and underlying trace details.

Example: You can query the p75 and p90 of LCP for your webpages and aggregate these score by custom attribute customerType

Extrapolating for Sample rates

Since we’re aggregating spans to compute your aggregates, we will automatically extrapolate your aggregations like count, percentiles etc to account for your sampling rates. This will help us show you reasonably accurate aggregates even if you apply client side sample rates

Your feedback is appreciated

We’ve rolled this feature to a limited cohort of customers. Please reach out to [email protected] to get access

We’re actively working on this querying experience so please feel free to share any feedback

• Is the filtering UX easy to use? We want to ensure you quickly find the values to filter by
• Do you need any advance features (equations, multi-queries etc)?

Your input will help us build a better experience, so please drop your comments and questions below. We’re excited to help you unlock the full potential of your span data with Sentry.

[Dhrumil-Sentry]

Hi All - We have released this ability to freely query and aggregate any span based metric to all Early Adopter Customers !! If you want access just go to your Org Settings and turn on the Early Adopter Flag.

Enterprise customers can reach out to their account reps for more details

[Dhrumil-Sentry]

@munkii -That's incorrect. You need to send traces to Sentry. You can then send any custom spans or attach custom attributes

You see this data under Explore->Traces in the side navigation menu

[kadet1090]

So if I understand correctly I won't have metrics about all users, only about sampled traces?

This is a problem because for most cases I want my tracing sample rate to be quite low, but I would love to obtain metrics about non-sampled sessions too.

[Dhrumil-Sentry]

@kadet1090 - Every span in a sampled trace that gets sent to Sentry has a sampling rate attached to it. We use this to extrapolate what the true counts for your query is with reasonable accuracy.

We show such extrapolation subtext in the UX too

If you ever write a query which has less accuracy due to low sampling rates we'll make that clear too. This allows you to compute any metric based on your tracing data with reasonable accuracy and you don't have to pay extra for metrics or cardinality.

Also - if you're on our latest span based pricing plan then you can send a lot more tracing data to Sentry at an economic rate.

[munkii]

@munkii -That's incorrect. You need to send traces to Sentry. You can then send any custom spans or attach custom attributes

I guessed it was incorrect but to be honest it is not all that clear how to send Trace information using the MAUI SDK. I have looked at the Custom Instrumentation page for MAUI.

That talks about

var transaction = SentrySdk.StartTransaction(
  "test-transaction-name",
  "test-transaction-operation"
);

transaction.Finish()

We use that to trace some offline synchronisation work, that is long running and has a start and end so "Transactions" makes sense. However if we take one of our more interesting analaytic events that seems to not make less sense. When a user does a series of medical tests in our app we show them the full list and preselect what we consider to be the best choice. If they choose a different result we log that. Would that be logged as

var transaction = SentrySdk.StartTransaction(
  "CaptureOverride",
  "User overrode recommended capture"
);

transaction.Finish()

[Dhrumil-Sentry]

@munkii -Sorry that our MAUI custom instrumentation docs are not fully up to date, We're fixing that.

But if you take a look at this doc on how to instrument Queue spans in MAUI - You'll see examples for how to create custom spans and attach attributes to them

So in your case you could fetch the existing transaction and create child spans in case a user chose a different test

(@bruno-garcia please correct me if I am wrong, Bruno's our .Net expert 😄 )