docs(sdk): Move telemetry-processor to foundations/processing/

develop-docs/sdk/telemetry/telemetry-processor/batch-processor.mdx → develop-docs/sdk/foundations/processing/batch-processor.mdx

@@ -7,7 +7,7 @@ sidebar_order: 10
 ---
 
 <Alert level="warning">
-  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.
 </Alert>
 
 <Alert>
@@ -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.
 

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
+---
+
+<PageGrid />

develop-docs/sdk/telemetry/telemetry-processor/backend-telemetry-processor.mdx → develop-docs/sdk/foundations/processing/telemetry-processor/backend-telemetry-processor.mdx

@@ -8,7 +8,7 @@ sidebar_order: 1
   🚧 This document is work in progress.
 </Alert>
 
-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.
 

develop-docs/sdk/telemetry/telemetry-processor/index.mdx → 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.

develop-docs/sdk/telemetry/telemetry-processor/mobile-telemetry-processor.mdx → develop-docs/sdk/foundations/processing/telemetry-processor/mobile-telemetry-processor.mdx

@@ -11,17 +11,17 @@ 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. 🚧
 </Alert>
 
-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`.
 
 Each SDK environment is unique. Therefore, SDKs have three options to choose from to minimize data loss. As their number increases, the options get more complex. The first option is the simplest, and the last option is the most complicated. SDKs **SHOULD** implement the least complex option that is suitable for their environment.
 
 ## 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.
 

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.
 

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.
 

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/)

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.

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