Skip to content

docs(dotnet): Add metrics documentation for .NET#16054

Open
Flash0ver wants to merge 7 commits intomasterfrom
docs/dotnet-metrics
Open

docs(dotnet): Add metrics documentation for .NET#16054
Flash0ver wants to merge 7 commits intomasterfrom
docs/dotnet-metrics

Conversation

@Flash0ver
Copy link
Member

@Flash0ver Flash0ver commented Jan 16, 2026

DESCRIBE YOUR PR

Add initial metrics documentation for the .NET SDK.
Based on the user docs for Python and JavaScript.

IS YOUR CHANGE URGENT?

Help us prioritize incoming PRs by letting us know when the change needs to go live.

SLA

  • Teamwork makes the dream work, so please add a reviewer to your PRs.
  • Please give the docs team up to 1 week to review your PR unless you've added an urgent due date to it.
    Thanks in advance for your help!

PRE-MERGE CHECKLIST

Make sure you've checked the following before merging your changes:

  • Checked Vercel preview for correctness, including links
  • PR was reviewed and approved by any necessary SMEs (subject matter experts)
  • PR was reviewed and approved by a member of the Sentry docs team

Add comprehensive metrics documentation for .NET SDK including:
- Main metrics page with overview and beta notice
- Requirements section with SDK version and installation
- Usage examples for Counter, Gauge, and Distribution metrics
- Configuration options (EnableMetrics, SetBeforeSendMetric)
- Default attributes documentation

Based on Python and JavaScript metrics documentation structure.

Co-Authored-By: Claude <[email protected]>
@Flash0ver Flash0ver self-assigned this Jan 16, 2026
@vercel
Copy link

vercel bot commented Jan 16, 2026

The latest updates on your projects. Learn more about Vercel for GitHub.

Project Deployment Actions Updated (UTC)
sentry-docs Ready Ready Preview, Comment Feb 4, 2026 6:52pm
1 Skipped Deployment
Project Deployment Actions Updated (UTC)
develop-docs Ignored Ignored Preview Feb 4, 2026 6:52pm

Request Review


#### SetBeforeSendMetric<T>

To filter metrics, or update them before they are sent to Sentry, you can use the `SetBeforeSendMetric<T>(Func<SentryMetric<T>, SentryMetric<T>?>)` option. If the callback returns `null`, the metric is not emitted. Attributes can also be updated in the callback delegate.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Need to decide what the API will look like before we can do the docs:


## Options

<PlatformContent includePath="metrics/options" />
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Flash0ver this include is not rendering. There might be something wrong with the formatting of the file itself? I can't quite tell. Can you take another look?

This might be the culprit: MDX is treating as JSX

  • Use SetBeforeSendMetric<T> (already in backticks but the heading line may not be)
  • Or escape: SetBeforeSendMetric<T>

Copy link
Member Author

@Flash0ver Flash0ver Feb 4, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the review, @sfanahata.

We just implicitly fixed the issue:

-#### SetBeforeSendMetric<T>
+#### SetBeforeSendMetric

As we've slightly overhauled the public API shape for a release this week,
we changed this method to be no longer generic.

Now all < and > characters are within code fences.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed via 8279c73

Copy link
Contributor

@sfanahata sfanahata left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Need to fix the bug failing /options/ from rendering in the index.


The metric object of type `SentryMetric` has the following members:

| Member | Type | Description |
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Flash0ver - I updated this section to be a table. It was too hard to read in the other version. Can you take a quick look and make sure it's properly representing the intent?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

splendid ... this is so much better ... thanks!

Copy link

@cursor cursor bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Cursor Bugbot has reviewed your changes and found 1 potential issue.

Bugbot Autofix is OFF. To automatically fix reported issues with Cloud Agents, enable Autofix in the Cursor dashboard.

| `SetAttribute<TAttribute>(string key, TAttribute value)` | Method | Sets a key-value pair of data attached to the metric. Supported types are `string`, `bool`, integers up to a size of 64-bit signed, and floating-point numbers up to a size of 64-bit. |

The numeric value of `SentryMetric` has the same numeric type that the metric was emitted with.
The supported numeric types are `byte`, `short`, `int`, `long`, `float`, and `double`.
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Duplicated numeric types text across two files

Low Severity

The exact text "The supported numeric types are byte, short, int, long, float, and double." appears verbatim in both usage/dotnet.mdx (line 6) and options/dotnet.mdx (lines 43-44). This duplication creates a maintenance burden if the supported types ever change.

Fix in Cursor Fix in Web

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

True ... but to be fair, there is two parts of the API:

  • the "production" part via Emit, whose methods are all generic, dictating the type of the numeric value
  • the "consumption" part via BeforeSendMetric, which is a callback receiving/returning an instance of SentryMetric, which does not expose the Value directly, but through a "Try-Get-Value" method

We are not 100 % convinced that this is the best API shape, yet.
We are about to release this in v6.1.0 as an Experimental feature ... so we might be tweaking the API, and with that the documentation.
But for now, I'd like to be quite explicit ... and potentially duplicating.

And also ... I am quite sure that you will create a comment if future edits only update one part ... won't you 😉 ... and yes ... I am talking to a machine here right now ... it is getting late.

@@ -0,0 +1,42 @@
Metrics are enabled by default. Once you initialize the SDK, you can send metrics using the `SentrySdk.Experimental.Metrics` APIs.

The `SentryMetricEmitter` type exposes three method groups that you can use to capture different types of metric information: `Counter`, `Gauge`, and `Distribution`.
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Bug: The documentation refers to the SentryMetricEmitter type, but code examples use SentrySdk.Experimental.Metrics, which is confusing and inconsistent with other SDKs.
Severity: MEDIUM

Suggested Fix

Update the documentation to align the description with the code examples. Either state that metrics are sent via SentrySdk.Experimental.Metrics or clarify the relationship between SentrySdk.Experimental.Metrics and SentryMetricEmitter.

Prompt for AI Agent
Review the code at the location below. A potential bug has been identified by an AI
agent.
Verify if this is a real issue. If it is, propose a fix; if not, explain why it's not
valid.

Location: platform-includes/metrics/usage/dotnet.mdx#L3

Potential issue: The documentation states that "The `SentryMetricEmitter` type exposes
three method groups," but the code examples show calls to
`SentrySdk.Experimental.Metrics.EmitCounter(...)`. This discrepancy is misleading
because the type `SentryMetricEmitter` never appears in the example code. A developer
following the text might search for `SentryMetricEmitter` and be unable to find it, or
try to instantiate it, leading to confusion. This is inconsistent with other Sentry SDKs
where the documented component name matches the code path used in examples.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But it is consistent with Logs for .NET:

Once the feature is enabled on the SDK and the SDK is initialized, you can send logs using the `SentrySdk.Logger` APIs.
The `SentryStructuredLogger` type exposes six method groups that you can use to log messages at different log levels: `Trace`, `Debug`, `Info`, `Warning`, `Error`, and `Fatal`.

And the type name is indeed SentryMetricEmitter.
And the SDK-API (SentrySdk.Experimental.Metrics) is mentioned just the line above.

Copy link
Contributor

@sfanahata sfanahata left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looking good!

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.

3 participants