From ba75e7157a3d73cad8aa057de6b57edce41e2992 Mon Sep 17 00:00:00 2001 From: Stephanie Anderson Date: Wed, 18 Feb 2026 14:58:20 +0100 Subject: [PATCH] docs(sdk): Move telemetry-processor from telemetry/ to foundations/processing/ Create a new "Processing" section under foundations/ and move the telemetry processor documentation there. Update all internal references and add catch-all redirect for old paths. Co-Authored-By: Claude --- .../processing}/batch-processor.mdx | 6 ++-- .../sdk/foundations/processing/index.mdx | 7 ++++ .../backend-telemetry-processor.mdx | 8 ++--- .../processing}/telemetry-processor/index.mdx | 4 +-- .../mobile-telemetry-processor.mdx | 6 ++-- develop-docs/sdk/telemetry/client-reports.mdx | 2 +- develop-docs/sdk/telemetry/logs.mdx | 4 +-- develop-docs/sdk/telemetry/metrics.mdx | 6 ++-- .../sdk/telemetry/spans/implementation.mdx | 2 +- .../sdk/telemetry/spans/span-buffer.mdx | 2 +- .../browser-telemetry-processor.mdx | 7 ---- .../gdx-telemetry-processor.mdx | 7 ---- redirects.js | 33 +++++++++++++++---- 13 files changed, 52 insertions(+), 42 deletions(-) rename develop-docs/sdk/{telemetry/telemetry-processor => foundations/processing}/batch-processor.mdx (96%) create mode 100644 develop-docs/sdk/foundations/processing/index.mdx rename develop-docs/sdk/{telemetry => foundations/processing}/telemetry-processor/backend-telemetry-processor.mdx (93%) rename develop-docs/sdk/{telemetry => foundations/processing}/telemetry-processor/index.mdx (97%) rename develop-docs/sdk/{telemetry => foundations/processing}/telemetry-processor/mobile-telemetry-processor.mdx (93%) delete mode 100644 develop-docs/sdk/telemetry/telemetry-processor/browser-telemetry-processor.mdx delete mode 100644 develop-docs/sdk/telemetry/telemetry-processor/gdx-telemetry-processor.mdx diff --git a/develop-docs/sdk/telemetry/telemetry-processor/batch-processor.mdx b/develop-docs/sdk/foundations/processing/batch-processor.mdx similarity index 96% rename from develop-docs/sdk/telemetry/telemetry-processor/batch-processor.mdx rename to develop-docs/sdk/foundations/processing/batch-processor.mdx index 4c9a7f9f161ce..67852ea09337a 100644 --- a/develop-docs/sdk/telemetry/telemetry-processor/batch-processor.mdx +++ b/develop-docs/sdk/foundations/processing/batch-processor.mdx @@ -7,7 +7,7 @@ sidebar_order: 10 --- - The BatchProcessor is deprecated. Please use the [Telemetry Processor](/sdk/telemetry/telemetry-processor/) instead. + The BatchProcessor is deprecated. Please use the [Telemetry Processor](/sdk/foundations/processing/telemetry-processor/) instead. @@ -16,7 +16,7 @@ sidebar_order: 10 # BatchProcessor (deprecated) -This section covers the initial specification of the BatchProcessor, which some SDKs use as a reference when implementing logs. This exists only as a reference until we fully spec out the [telemetry processor](/sdk/telemetry/telemetry-processor/) across all platforms. +This section covers the initial specification of the BatchProcessor, which some SDKs use as a reference when implementing logs. This exists only as a reference until we fully spec out the [telemetry processor](/sdk/foundations/processing/telemetry-processor/) across all platforms. ## Overview @@ -38,7 +38,7 @@ The BatchProcessor **MUST** forward all spans and logs in memory to the transpor 2. When the user calls `SentrySDK.close()`, the BatchProcessor **MUST** forward all data in memory to the transport. SDKs **SHOULD** keep their existing closing behavior. 3. When the application shuts down gracefully, the BatchProcessor **SHOULD** forward all data in memory to the transport. The transport **SHOULD** keep its existing behavior, which usually stores the data to disk as an envelope. It is not required to call a transport `flush`. This is mostly relevant for mobile SDKs already subscribed to these hooks, such as [applicationWillTerminate](https://developer.apple.com/documentation/uikit/uiapplicationdelegate/applicationwillterminate(_:)) on iOS. 4. When the application moves to the background, the BatchProcessor **SHOULD** forward all the data in memory to the transport and stop the timer. The transport **SHOULD** keep its existing behavior, which usually stores the data to disk as an envelope. It is not required to call the transport `flush`. This is mostly relevant for mobile SDKs. -5. Mobile SDKs **MUST** minimize data loss when sudden process terminations occur. Refer to the [Mobile Telemetry Processor](/sdk/telemetry/telemetry-processor/mobile-telemetry-processor) section for more details. +5. Mobile SDKs **MUST** minimize data loss when sudden process terminations occur. Refer to the [Mobile Telemetry Processor](/sdk/foundations/processing/telemetry-processor/mobile-telemetry-processor) section for more details. The detailed specification is written in the [Gherkin syntax](https://cucumber.io/docs/gherkin/reference/). The specification uses spans as an example, but the same applies to logs or any other future telemetry data. diff --git a/develop-docs/sdk/foundations/processing/index.mdx b/develop-docs/sdk/foundations/processing/index.mdx new file mode 100644 index 0000000000000..7d374f4247bd9 --- /dev/null +++ b/develop-docs/sdk/foundations/processing/index.mdx @@ -0,0 +1,7 @@ +--- +title: Processing +description: How SDKs buffer, prioritize, and forward telemetry data to the transport layer. +sidebar_order: 15 +--- + + diff --git a/develop-docs/sdk/telemetry/telemetry-processor/backend-telemetry-processor.mdx b/develop-docs/sdk/foundations/processing/telemetry-processor/backend-telemetry-processor.mdx similarity index 93% rename from develop-docs/sdk/telemetry/telemetry-processor/backend-telemetry-processor.mdx rename to develop-docs/sdk/foundations/processing/telemetry-processor/backend-telemetry-processor.mdx index 540811effa2b2..880a336a0f2e9 100644 --- a/develop-docs/sdk/telemetry/telemetry-processor/backend-telemetry-processor.mdx +++ b/develop-docs/sdk/foundations/processing/telemetry-processor/backend-telemetry-processor.mdx @@ -8,7 +8,7 @@ sidebar_order: 1 🚧 This document is work in progress. -For the common specification, refer to the [Telemetry Processor](/sdk/telemetry/telemetry-processor/) page. This page describes the backend-specific implementation. The key difference is that backend SDKs use **weighted round-robin scheduling** to ensure critical telemetry (like errors) gets priority over high-volume data (like logs) when the application is under heavy load. +For the common specification, refer to the [Telemetry Processor](/sdk/foundations/processing/telemetry-processor/) page. This page describes the backend-specific implementation. The key difference is that backend SDKs use **weighted round-robin scheduling** to ensure critical telemetry (like errors) gets priority over high-volume data (like logs) when the application is under heavy load. ## Backend-Specific Design Decisions @@ -77,15 +77,15 @@ Configurable via weights. #### TelemetryBuffer -The telemetry buffer on the backend must follow the common [telemetry buffer requirements](/sdk/telemetry/telemetry-processor/#telemetry-buffer). Here are the additional requirements for the backend-specific implementation: +The telemetry buffer on the backend must follow the common [telemetry buffer requirements](/sdk/foundations/processing/telemetry-processor/#telemetry-buffer). Here are the additional requirements for the backend-specific implementation: 1. The telemetry buffer **SHOULD** drop older items as the overflow policy. It **MAY** also drop newer items to preserve what's already buffered. -On the backend, use the same size limits as the [common requirements](/sdk/telemetry/telemetry-processor/#telemetry-buffer), except for spans, where we recommend **1000** because span volume is higher. +On the backend, use the same size limits as the [common requirements](/sdk/foundations/processing/telemetry-processor/#telemetry-buffer), except for spans, where we recommend **1000** because span volume is higher. ##### Span Buffer -The span buffer must follow the common [telemetry span buffer requirements](/sdk/telemetry/telemetry-processor/#span-buffer). Further requirements for the bucketed-by-trace buffer are: +The span buffer must follow the common [telemetry span buffer requirements](/sdk/foundations/processing/telemetry-processor/#span-buffer). Further requirements for the bucketed-by-trace buffer are: 1. The span buffer **MAY** use FIFO to prioritize forwarding spans: always forward spans from the oldest traceID. FIFO prevents spans from lingering in the buffer. diff --git a/develop-docs/sdk/telemetry/telemetry-processor/index.mdx b/develop-docs/sdk/foundations/processing/telemetry-processor/index.mdx similarity index 97% rename from develop-docs/sdk/telemetry/telemetry-processor/index.mdx rename to develop-docs/sdk/foundations/processing/telemetry-processor/index.mdx index 9553c946a7c61..04cc685080070 100644 --- a/develop-docs/sdk/telemetry/telemetry-processor/index.mdx +++ b/develop-docs/sdk/foundations/processing/telemetry-processor/index.mdx @@ -208,12 +208,10 @@ flowchart LR For the platform specific requirements, please see: * [Backend Telemetry Processor](./backend-telemetry-processor/): Detailed backend design -* [Browser Telemetry Processor](./browser-telemetry-processor/): To be defined -* [GDX Telemetry Processor](./gdx-telemetry-processor/): To be defined * [Mobile Telemetry Processor](./mobile-telemetry-processor/): Spec under validation. ## FAQ ### Where is the Batch Processor? -The batch processor is deprecated, so we moved it to the [batch-processor](/sdk/telemetry/telemetry-processor/batch-processor/) page. The telemetry buffer will include parts of the batch processor functionality. +The batch processor is deprecated, so we moved it to the [batch-processor](/sdk/foundations/processing/batch-processor/) page. The telemetry buffer will include parts of the batch processor functionality. diff --git a/develop-docs/sdk/telemetry/telemetry-processor/mobile-telemetry-processor.mdx b/develop-docs/sdk/foundations/processing/telemetry-processor/mobile-telemetry-processor.mdx similarity index 93% rename from develop-docs/sdk/telemetry/telemetry-processor/mobile-telemetry-processor.mdx rename to develop-docs/sdk/foundations/processing/telemetry-processor/mobile-telemetry-processor.mdx index c8d59525b0b60..fe70aa1fb05dc 100644 --- a/develop-docs/sdk/telemetry/telemetry-processor/mobile-telemetry-processor.mdx +++ b/develop-docs/sdk/foundations/processing/telemetry-processor/mobile-telemetry-processor.mdx @@ -11,9 +11,9 @@ We're still figuring out the spec for the mobile telemetry processor. The teleme 🚧 This concept is approved but not yet implemented in any SDKs, and it's still being validated. If something feels unclear, too complex, or doesn't work as expected, please open an issue or PR and tag @philipphofmann for review. Feedback and improvements are welcome while we confirm the approach makes sense. 🚧 -For the common specification for the telemetry buffer, refer to the [Telemetry Processor](/sdk/telemetry/telemetry-processor/) page. This page describes the mobile-specific implementation of the telemetry buffer. The most important difference is that the mobile telemetry buffer is designed to minimize data loss when sudden process terminations occur, such as crashes or watchdog terminations. +For the common specification for the telemetry buffer, refer to the [Telemetry Processor](/sdk/foundations/processing/telemetry-processor/) page. This page describes the mobile-specific implementation of the telemetry buffer. The most important difference is that the mobile telemetry buffer is designed to minimize data loss when sudden process terminations occur, such as crashes or watchdog terminations. -The common requirements specify [data forwarding scenarios](/sdk/telemetry/telemetry-processor/#data-forwarding-scenarios), which mobile SDKs MUST implement. Additionally, mobile SDKs **MUST** adhere to this extra data forwarding scenario: +The common requirements specify [data forwarding scenarios](/sdk/foundations/processing/telemetry-processor/#data-forwarding-scenarios), which mobile SDKs MUST implement. Additionally, mobile SDKs **MUST** adhere to this extra data forwarding scenario: * When the application moves to the background, the TelemetryBuffer **SHOULD** forward all data in memory to the transport and stop the timer. The transport **SHOULD** keep its existing behavior, which usually stores the data to disk as an envelope. It is not required to call transport `flush`. @@ -21,7 +21,7 @@ Each SDK environment is unique. Therefore, SDKs have three options to choose fro ## 1. Flush All Data -When the SDK detects a sudden process termination, it **MUST** put all remaining items in the telemetry buffer into one envelope and flush it. If your SDK has an offline cache, it **MAY** flush the envelope to disk and skip sending it to Sentry, if it ensures to send the envelope the next time the SDK starts. The telemetry buffer **MUST** keep its existing logic described in the [Telemetry Processor Specification](/sdk/telemetry/telemetry-processor/#specification) page. +When the SDK detects a sudden process termination, it **MUST** put all remaining items in the telemetry buffer into one envelope and flush it. If your SDK has an offline cache, it **MAY** flush the envelope to disk and skip sending it to Sentry, if it ensures to send the envelope the next time the SDK starts. The telemetry buffer **MUST** keep its existing logic described in the [Telemetry Processor Specification](/sdk/foundations/processing/telemetry-processor/#specification) page. Suppose your SDK can't reliably detect sudden process terminations, or it can't reliably flush envelopes to Sentry or disk when a sudden process termination happens. In that case, it **SHOULD** implement the [FileStream Cache](#2-filestream-cache) or the [DoubleRotatingBuffer](#3-doublerotatingbuffer). It's acceptable to start with this option as a best effort interim solution before adding one of the more complex options. diff --git a/develop-docs/sdk/telemetry/client-reports.mdx b/develop-docs/sdk/telemetry/client-reports.mdx index 6cfbfbbf14461..d28580192c252 100644 --- a/develop-docs/sdk/telemetry/client-reports.mdx +++ b/develop-docs/sdk/telemetry/client-reports.mdx @@ -155,7 +155,7 @@ SDKs **SHOULD** minimize unnecessary HTTP requests and **MUST NOT** send an enve 1. For low-frequency apps (mobile/web): Attach discarded events to scheduled envelopes. Fewer client reports are acceptable in such cases. 2. For high-frequency apps (backends): Periodically flush discarded events or attach to scheduled envelopes. -SDKs **MAY** keep track of discarded events in the transport. Once SDKs implement the [telemetry processor](/sdk/telemetry/telemetry-processor/), they **SHOULD** implement client reports tracking outside the transport, since data can be dropped in multiple places throughout the SDK. The [telemetry scheduler](/sdk/telemetry/telemetry-processor/#telemetry-scheduler) is then responsible for passing aggregated client reports to the transport. The telemetry scheduler still **MUST** adhere to the requirements above. +SDKs **MAY** keep track of discarded events in the transport. Once SDKs implement the [telemetry processor](/sdk/foundations/processing/telemetry-processor/), they **SHOULD** implement client reports tracking outside the transport, since data can be dropped in multiple places throughout the SDK. The [telemetry scheduler](/sdk/foundations/processing/telemetry-processor/#telemetry-scheduler) is then responsible for passing aggregated client reports to the transport. The telemetry scheduler still **MUST** adhere to the requirements above. The party that drops an envelope item **MUST** record and report it. SDKs can assume client reports are never rate limited. The server is minimizing the possibility of client reports getting rate limited, but the SDKs shouldn't worry about this edge case as this feature is best-effort. diff --git a/develop-docs/sdk/telemetry/logs.mdx b/develop-docs/sdk/telemetry/logs.mdx index 9665021793afa..88bc9e521f2a6 100644 --- a/develop-docs/sdk/telemetry/logs.mdx +++ b/develop-docs/sdk/telemetry/logs.mdx @@ -398,13 +398,13 @@ A new data category for logs has been added to Relay, `log_item`. Both the `log` ### Buffering -SDKs **MUST** buffer logs before sending them. SDKs should keep a buffer of logs and flush it when specific conditions are met. For initial implementation, a simple strategy is fine, for example: flushing logs if the buffer length exceeds 100 items or if 5 seconds have passed. To prevent data loss, the buffer SHOULD forward logs to the transport in the scenarios outlined in the [telemetry buffer data forwarding scenarios](/sdk/telemetry/telemetry-buffer/#data-forwarding-scenarios). +SDKs **MUST** buffer logs before sending them. SDKs should keep a buffer of logs and flush it when specific conditions are met. For initial implementation, a simple strategy is fine, for example: flushing logs if the buffer length exceeds 100 items or if 5 seconds have passed. To prevent data loss, the buffer SHOULD forward logs to the transport in the scenarios outlined in the [telemetry buffer data forwarding scenarios](/sdk/foundations/processing/telemetry-processor/#data-forwarding-scenarios). Relay is optimized for up to 100 logs per envelope. SDKs **MUST NOT** send more than 100 logs per envelope. To prevent out-of-memory issues in customer applications, SDKs **MUST** enforce a hard limit of 1000 queued log events. Any logs added beyond this limit are dropped. SDKs **MAY** use a lower limit but **MUST NOT** exceed 1000. -We used to recommend following the [BatchProcessor](/sdk/telemetry/telemetry-buffer/#batchprocessor-v0), but this page is currently under development. We currently working on a new [telemetry buffer specification](/sdk/telemetry/telemetry-buffer/) that will replace the BatchProcessor. +We used to recommend following the [BatchProcessor](/sdk/foundations/processing/telemetry-processor/#batchprocessor-v0), but this page is currently under development. We currently working on a new [telemetry buffer specification](/sdk/foundations/processing/telemetry-processor/) that will replace the BatchProcessor. SDKS should NOT release logging capabilities to users if a buffering implementation has not been added to their SDK when adding logging APIs. diff --git a/develop-docs/sdk/telemetry/metrics.mdx b/develop-docs/sdk/telemetry/metrics.mdx index 1e84bf92631cb..123c3574ca9c9 100644 --- a/develop-docs/sdk/telemetry/metrics.mdx +++ b/develop-docs/sdk/telemetry/metrics.mdx @@ -451,12 +451,12 @@ A new data category for metrics has been added to Relay, `trace_metric`. Rate li ### Buffering -SDKs **MUST** buffer metrics before sending them. SDKs should also keep a buffer of metrics and flush it when specific conditions are met. For initial implementation, a simple strategy is fine, for example: flushing metrics if the buffer length exceeds 100 items or if 5 seconds have passed. To prevent data loss, the buffer **SHOULD** forward metrics to the transport in the scenarios outlined in the [telemetry buffer data forwarding scenarios](/sdk/telemetry/telemetry-buffer/#data-forwarding-scenarios). Furthermore: +SDKs **MUST** buffer metrics before sending them. SDKs should also keep a buffer of metrics and flush it when specific conditions are met. For initial implementation, a simple strategy is fine, for example: flushing metrics if the buffer length exceeds 100 items or if 5 seconds have passed. To prevent data loss, the buffer **SHOULD** forward metrics to the transport in the scenarios outlined in the [telemetry buffer data forwarding scenarios](/sdk/foundations/processing/telemetry-processor/#data-forwarding-scenarios). Furthermore: - The aggregation window should be time and size based. - SDKs should implement safeguards to prevent excessive memory usage from metric buffering. -We're currently working on a concept for buffering different types of telemetry data in [telemetry buffer specification](/sdk/telemetry/telemetry-buffer/). +We're currently working on a concept for buffering different types of telemetry data in [telemetry buffer specification](/sdk/foundations/processing/telemetry-processor/). ### Behaviour with other Sentry Telemetry @@ -568,4 +568,4 @@ If `debug` is set to `true` in SDK init, calls to the Sentry metrics API should - [Experimental JS SDK PR #17883 - Metrics API Implementation](https://github.com/getsentry/sentry-javascript/pull/17883/files) - [Experimental Python SDK PR #4898 - Metrics API Implementation](https://github.com/getsentry/sentry-python/pull/4898) -- [Batch Processor Specification](/sdk/telemetry/telemetry-buffer/batch-processor/) +- [Batch Processor Specification](/sdk/foundations/processing/batch-processor/) diff --git a/develop-docs/sdk/telemetry/spans/implementation.mdx b/develop-docs/sdk/telemetry/spans/implementation.mdx index 3e6f569f88f0b..0d71b21378e94 100644 --- a/develop-docs/sdk/telemetry/spans/implementation.mdx +++ b/develop-docs/sdk/telemetry/spans/implementation.mdx @@ -37,7 +37,7 @@ If you're implementing Span-First (as a PoC) in your SDK, take an iterative appr - TBD: Some SDKs already have `startSpan` or similar APIs. The migration path is still TBD but a decision can be made at a later stage. 5. Implement the `captureSpan` [single-span processing pipeline](#single-span-processing-pipeline) - Either reuse existing heuristics (e.g. flush when segment span ends) or build a simple span buffer to flush spans (e.g. similar to the existing buffers for logs or metrics). - - Implementing the more complex [Telemetry Processor](/sdk/telemetry/telemetry-processor/) buffer and scheduler can happen at a later stage. + - Implementing the more complex [Telemetry Processor](/sdk/foundations/processing/telemetry-processor/) buffer and scheduler can happen at a later stage. 6. Achieve data parity with the existing transaction events. - Ensure that the data added by SDK integrations, event processors, etc. to transaction events is also added to the spans (see [Event Processors](#tbd-event-processors)). - Most additional data MUST only be added to the segment span. See [Common Attributes](../span-protocol/#common-attribute-keys) for attributes that MUST be added to every span. diff --git a/develop-docs/sdk/telemetry/spans/span-buffer.mdx b/develop-docs/sdk/telemetry/spans/span-buffer.mdx index e99de2e8a2f42..b72b169f8d4c9 100644 --- a/develop-docs/sdk/telemetry/spans/span-buffer.mdx +++ b/develop-docs/sdk/telemetry/spans/span-buffer.mdx @@ -11,7 +11,7 @@ sidebar_order: 11 The span buffer is responsible for batching spans, constructing span envelopes and forwarding them to the transport. It is used in the [Span Streaming](/sdk/telemetry/spans/implementation/) flow, where spans are captured via `captureSpan` and enqueued into the span buffer instead of being sent as transaction events. -This page specifies requirements for the span buffer. It intentionally does not specify as much as the [Telemetry Processor](/sdk/telemetry/telemetry-processor/) page. SDKs MAY implement and extend the span buffer with platform-specific behaviour, +This page specifies requirements for the span buffer. It intentionally does not specify as much as the [Telemetry Processor](/sdk/foundations/processing/telemetry-processor/) page. SDKs MAY implement and extend the span buffer with platform-specific behaviour, as long as the core requirements adquately are met. ## Span Buffer Requirements diff --git a/develop-docs/sdk/telemetry/telemetry-processor/browser-telemetry-processor.mdx b/develop-docs/sdk/telemetry/telemetry-processor/browser-telemetry-processor.mdx deleted file mode 100644 index 10ab01b73a4f0..0000000000000 --- a/develop-docs/sdk/telemetry/telemetry-processor/browser-telemetry-processor.mdx +++ /dev/null @@ -1,7 +0,0 @@ ---- -title: Browser Telemetry Processor -description: Detailed browser telemetry processor design. -sidebar_order: 2 ---- - -To be defined — full spec lives here. diff --git a/develop-docs/sdk/telemetry/telemetry-processor/gdx-telemetry-processor.mdx b/develop-docs/sdk/telemetry/telemetry-processor/gdx-telemetry-processor.mdx deleted file mode 100644 index 5a37b14996afc..0000000000000 --- a/develop-docs/sdk/telemetry/telemetry-processor/gdx-telemetry-processor.mdx +++ /dev/null @@ -1,7 +0,0 @@ ---- -title: GDX Telemetry Processor -description: Detailed GDX telemetry processor design. -sidebar_order: 3 ---- - -To be defined — full spec lives here. diff --git a/redirects.js b/redirects.js index 9ac7320373978..3cdbb29814e61 100644 --- a/redirects.js +++ b/redirects.js @@ -96,31 +96,50 @@ const developerDocsRedirects = [ }, { source: '/sdk/telemetry/spans/batch-processor/', - destination: '/sdk/telemetry/telemetry-processor/batch-processor/', + destination: '/sdk/foundations/processing/batch-processor/', }, { source: '/sdk/telemetry/telemetry-buffer/', - destination: '/sdk/telemetry/telemetry-processor/', + destination: '/sdk/foundations/processing/telemetry-processor/', }, { source: '/sdk/telemetry/telemetry-buffer/backend-telemetry-buffer/', - destination: '/sdk/telemetry/telemetry-processor/backend-telemetry-processor/', + destination: + '/sdk/foundations/processing/telemetry-processor/backend-telemetry-processor/', }, { source: '/sdk/telemetry/telemetry-buffer/browser-telemetry-buffer/', - destination: '/sdk/telemetry/telemetry-processor/browser-telemetry-processor/', + destination: '/sdk/foundations/processing/telemetry-processor/', }, { source: '/sdk/telemetry/telemetry-buffer/gdx-telemetry-buffer/', - destination: '/sdk/telemetry/telemetry-processor/gdx-telemetry-processor/', + destination: '/sdk/foundations/processing/telemetry-processor/', + }, + { + source: + '/sdk/foundations/processing/telemetry-processor/browser-telemetry-processor/', + destination: '/sdk/foundations/processing/telemetry-processor/', + }, + { + source: '/sdk/foundations/processing/telemetry-processor/gdx-telemetry-processor/', + destination: '/sdk/foundations/processing/telemetry-processor/', }, { source: '/sdk/telemetry/telemetry-buffer/mobile-telemetry-buffer/', - destination: '/sdk/telemetry/telemetry-processor/mobile-telemetry-processor/', + destination: + '/sdk/foundations/processing/telemetry-processor/mobile-telemetry-processor/', }, { source: '/sdk/telemetry/telemetry-buffer/batch-processor/', - destination: '/sdk/telemetry/telemetry-processor/batch-processor/', + destination: '/sdk/foundations/processing/batch-processor/', + }, + { + source: '/sdk/foundations/processing/telemetry-processor/batch-processor/', + destination: '/sdk/foundations/processing/batch-processor/', + }, + { + source: '/sdk/telemetry/telemetry-processor/:path*', + destination: '/sdk/foundations/processing/telemetry-processor/:path*', }, { source: '/sdk/setup-wizards/:path*',