ref: Rename telemetry buffer pages to processor #15860
Conversation
Rename all the telemetry buffer pages to telemetry processor and clarify that the processor does more than buffering.
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
| The telemetry processor ensures data is delivered efficiently to Sentry. It receives data from the client and forwards it to the transport. Its key responsibilities include buffering, rate limiting, client reporting, priority-based sending, and, on some platforms, offline caching. | ||
|
|
||
|
|
||
| ```mermaid | ||
| flowchart LR | ||
| Client -- send Data --> TelemetryProcessor | ||
| TelemetryProcessor -- sendEnvelope --> Transport | ||
| ``` | ||
|
|
||
| Once an SDK adds the telemetry processor, its client **SHOULD** only forward data to the telemetry processor, and not directly to the transport. The TelemetryProcessor consists of two major components: | ||
|
|
||
| - **TelemetryBuffer**: Focuses on buffering high-volume data, such as spans and logs, into batches to minimize HTTP requests. | ||
| - **TelemetryDispatcher**: Takes buffered data from the TelemetryBuffer and manages prioritized sending, including potential offline caching and sending of client reports. | ||
|
|
||
| Because telemetry workloads and platform constraints vary widely, the requirements differ across environments. For example, backend SDKs need high throughput and backpressure management to handle large data volumes. Mobile SDKs have lower throughput and don't need to worry much about backpressure, but they do need to minimize data loss in the event of abnormal process termination. Browser and GDX SDKs also have different requirements. | ||
|
|
||
| Therefore, we recommend implementing different types of telemetry processors tailored to the platform's needs. As of Dec 18th, 2025, this page is under development, and we're currently refining the requirements for different platforms: |
There was a problem hiding this comment.
I'm sorry the git mv command somehow got messed up here. This is basically the new part. The rest already existed before.
There was a problem hiding this comment.
git mv is basically just sugar around git rm + git add. If the file contents don't change, it's reflected as a rename; but if you add more than a certain percentage, it'll be interpreted as a new different file. (Ie, you did nothing wrong, this is just git's heuristics working as designed, but you can avoid this in the future by having separate commits: one to rename the file, then another to edit it. But that's usually more trouble than it's worth, to be honest.)
| Once an SDK adds the telemetry processor, its client **SHOULD** only forward data to the telemetry processor, and not directly to the transport. The TelemetryProcessor consists of two major components: | ||
|
|
||
| - **TelemetryBuffer**: Focuses on buffering high-volume data, such as spans and logs, into batches to minimize HTTP requests. | ||
| - **TelemetryDispatcher**: Takes buffered data from the TelemetryBuffer and manages prioritized sending, including potential offline caching and sending of client reports. |
There was a problem hiding this comment.
I personally prefer TelemetryScheduler as a name, since for me it more clearly represents what the component actually does. But that's a nit, so leaving it as is, is fine.
There was a problem hiding this comment.
@giortzisg, I don't think that's a nit. It's an important point. I think we can also follow up on this later. The concept is still WIP, and we will get to a close to ideal solution step by step. @isaacs, what is your suggestion for a proper name for the TelemetryDispatcher?
There was a problem hiding this comment.
I would think of a "dispatcher" as the thing that manages the actual sending as well as scheduling. For example, if it had multiple different clients, and was deciding where to send different types of data.
In this case, we have exactly one client (the HTTP client that uploads to Sentry), and this component is just deciding which things get placed in its queue in which order, so I agree Scheduler is probably a slightly better term.
But I also agree with @giortzisg that this is a nit ;) I could easily see how it could grow into a full "dispatcher" if one had multiple endpoints, for example.
isaacs
left a comment
isaacs
left a comment
There was a problem hiding this comment.
This rename seems fine to me, possibly with the scheduler/dispatcher nit resolved.
Rename all the telemetry buffer pages to telemetry processor and clarify that the processor does more than buffering.
This is the first step of migrating the Notion doc concept of the telemetry processor to the develop docs.