From 1042e86a63395234bb4958ef3db7783a8bf83570 Mon Sep 17 00:00:00 2001 From: Philipp Hofmann Date: Thu, 19 Feb 2026 15:34:36 +0100 Subject: [PATCH 1/2] docs(sdk): add Hub/Scope steps to metrics SDK behavior The metrics develop docs were missing the Hub/Scope and Client passthrough steps in the SDK Behavior processing pipeline that the logs docs already had. Co-Authored-By: Claude --- develop-docs/sdk/telemetry/metrics.mdx | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/develop-docs/sdk/telemetry/metrics.mdx b/develop-docs/sdk/telemetry/metrics.mdx index 123c3574ca9c9e..e51b7345454683 100644 --- a/develop-docs/sdk/telemetry/metrics.mdx +++ b/develop-docs/sdk/telemetry/metrics.mdx @@ -211,6 +211,8 @@ to="/sdk/telemetry/attributes/#units">units we support. - `attributes` **Object, optional**: A dictionary of attributes (key-value pairs with type information) - `scope` **Scope, optional**: The scope to capture the metric with. +The Hub/Scope MUST offer the same methods as the static API `Sentry.metrics.X`, which is useful for power users who want to use multiple Hubs/Scopes. The Client SHOULD only offer one generic method that accepts the metric object and the Scope, such as `captureMetric(metric, scope)`. + Below are some example SDK implementations to get you started. These are not finalized versions of the API and individual SDK authors should ensure the metrics APIs best fit their platforms. #### JavaScript @@ -352,6 +354,8 @@ In general metric processing should follow this order: 1. Capture metric via [Public APIs](#metrics-module) (e.g. `Sentry.metrics.increment`). 1. Check if metrics are disabled as per `enableMetrics`/`enable_metrics` configuration - if so, skip the rest of the steps. +1. Pass the metric to Hub/Scope, which MUST offer the same methods as the static API `Sentry.metrics.X`. This is useful for power users who want to use multiple Hubs/Scopes. +1. Pass the metric to the Client, via a generic method that accepts the metric object and the `scope`, such as `captureMetric(metric, scope)`. 1. Process captured metric (attach default attributes as per [default attributes](#default-attributes)). 1. Run `beforeSendMetric`/`before_send_metric` to filter or modify the metric. 1. Add metric to buffer/batch processor as detailed in [buffering](#buffering). From f4c617f610e2cac72db5d5c7716060de7c3c1d4c Mon Sep 17 00:00:00 2001 From: Philipp Hofmann Date: Thu, 26 Feb 2026 13:43:51 +0100 Subject: [PATCH 2/2] docs(sdk): use generic captureMetric/captureLog for Hub/Scope Address review feedback: Hub/Scope and Client MUST offer a generic capture method, but MAY (not MUST) offer the full static API surface. Aligns both metrics and logs specs. Co-Authored-By: Claude --- develop-docs/sdk/telemetry/logs.mdx | 8 +++++--- develop-docs/sdk/telemetry/metrics.mdx | 9 ++++++--- 2 files changed, 11 insertions(+), 6 deletions(-) diff --git a/develop-docs/sdk/telemetry/logs.mdx b/develop-docs/sdk/telemetry/logs.mdx index 6bb46e3ef9f721..0a83411c8907f1 100644 --- a/develop-docs/sdk/telemetry/logs.mdx +++ b/develop-docs/sdk/telemetry/logs.mdx @@ -125,7 +125,7 @@ Log processing **MUST** follow this order: 1. Capture log via [Public APIs](#logger-module) (e.g. `Sentry.logger.info`) or via [SDK integrations](#sdk-integrations). 2. Check if logging is enabled via `enableLogs`/`enable_logs` — if not, skip remaining steps. -3. Pass the log to Hub/Scope, which **MUST** offer the same methods as the static API `Sentry.logger.X`. +3. Pass the log to Hub/Scope via a generic method (e.g., `captureLog(log, scope)`). 4. Pass the log to the Client via a generic method (e.g., `captureLog(log, scope)`). 5. Process captured log (attach attributes per [Default Attributes](#default-attributes)). 6. Run `beforeSendLog`/`before_send_log` to filter or modify the log. @@ -461,9 +461,11 @@ SDKs **MUST** expose logging methods in a `logger` module or namespace, with one These methods accept a string template and parameters for structured logging. They **MAY** also accept arbitrary attributes. -The Hub/Scope **MUST** offer the same methods as the static `Sentry.logger.X` API (since 1.10.0). The Client **SHOULD** only offer one generic method (e.g., `captureLog(log, scope)`). +Furthermore: -SDKs **MAY** add additional helpers (e.g., decorators, string template helpers) as appropriate for their platform. +1. The Hub/Scope and Client **MUST** offer a generic method for capturing logs (e.g., `captureLog(log, scope)`). +1. The Hub/Scope **MAY** offer the same methods as the static `Sentry.logger.X` API (since 1.10.0). +1. SDKs **MAY** add additional helpers (e.g., decorators, string template helpers) as appropriate for their platform. diff --git a/develop-docs/sdk/telemetry/metrics.mdx b/develop-docs/sdk/telemetry/metrics.mdx index 1ce64f79cf7af8..e2bec09c32500a 100644 --- a/develop-docs/sdk/telemetry/metrics.mdx +++ b/develop-docs/sdk/telemetry/metrics.mdx @@ -97,8 +97,8 @@ Metric processing **MUST** follow this order: 1. Capture metric via [Public APIs](#metrics-module) (e.g. `Sentry.metrics.count`). 2. Check if metrics are disabled as per `enableMetrics`/`enable_metrics` configuration — if so, skip the rest of the steps. -3. Pass the metric to Hub/Scope, which **MUST** offer the same methods as the static API `Sentry.metrics.X`. This is useful for power users who want to use multiple Hubs/Scopes. -4. Pass the metric to the Client, via a generic method that accepts the metric object and the `scope`, such as `captureMetric(metric, scope)`. +3. Pass the metric to Hub/Scope via a generic method (e.g., `captureMetric(metric, scope)`). +4. Pass the metric to the Client via a generic method (e.g., `captureMetric(metric, scope)`). 5. Process captured metric (attach default attributes as per [Default Attributes](#default-attributes)). 6. Run `beforeSendMetric`/`before_send_metric` to filter or modify the metric. 7. Add metric to buffer/batch processor as detailed in [Buffering](#buffering). @@ -321,7 +321,10 @@ SDKs **MUST** expose metrics methods in a `metrics` module or namespace. At mini - `attributes` **Object, optional** — a dictionary of attributes (key-value pairs with type information). - `scope` **Scope, optional** — the scope to capture the metric with. -The Hub/Scope **MUST** offer the same methods as the static API `Sentry.metrics.X`, which is useful for power users who want to use multiple Hubs/Scopes. The Client **SHOULD** only offer one generic method that accepts the metric object and the Scope, such as `captureMetric(metric, scope)`. +Furthermore: + +1. The Hub/Scope and Client **MUST** offer a generic method for capturing metrics (e.g., `captureMetric(metric, scope)`). +1. The Hub/Scope **MAY** offer the same methods as the static `Sentry.metrics.X` API.