Skip to content

feat(client-reports): Protocol support for client reports#1081

Merged
mitsuhiko merged 7 commits into
masterfrom
feature/client-reports
Sep 10, 2021
Merged

feat(client-reports): Protocol support for client reports#1081
mitsuhiko merged 7 commits into
masterfrom
feature/client-reports

Conversation

@mitsuhiko

@mitsuhiko mitsuhiko commented Sep 9, 2021

Copy link
Copy Markdown
Contributor

Second attempt of #1074.

This adds support for client reports from the SDKs. This feature is primarily
used to allow client SDKs to emit outcomes.

The way this is currently implemented is that we add a new envelope item
type called client_report which contains these outcomes. The envelope item
type is intentionally kept flexible for future expansion as we already discussed
emitting other internal debug information upstream which is unrelated to
outcomes (eg: number of breadcrumbs discarded and configuration errors).

Because of how SDKs are currently implemented we now reserve internal
as data category for such metric items. Relay however will never emit
such a data category as we do not want to communicate actual rate limits
for such envelope items.

From the relay perspective any outcome reason that an SDK emits is
acceptable and upstreamed. It's up to the snuba consumer to whitelist
these outcomes to avoid writing bad data into the kafka topic. This
way SDKs can send more outcomes even if relays have not been updated.

The emitting of client outcomes can be disabled with the emit_client_outcomes
flag which is also honored on processing relay stop the flow of data to the
kafka topic.

untitaker and others added 2 commits September 9, 2021 13:52
This adds support for client reports from the SDKs. This feature is primarily
used to allow client SDKs to emit outcomes.

The way this is currently implemented is that we add a new envelope item
type called client_report which contains these outcomes. The envelope item
type is intentionally kept flexible for future expansion as we already discussed
emitting other internal debug information upstream which is unrelated to
outcomes (eg: number of breadcrumbs discarded and configuration errors).

Because of how SDKs are currently implemented we now reserve internal
as data category for such metric items. Relay however will never emit
such a data category as we do not want to communicate actual rate limits
for such envelope items.

From the relay perspective any outcome reason that an SDK emits is
acceptable and upstreamed. It's up to the snuba consumer to whitelist
these outcomes to avoid writing bad data into the kafka topic. This
way SDKs can send more outcomes even if relays have not been updated.
@mitsuhiko mitsuhiko requested a review from a team September 9, 2021 11:58
@mitsuhiko mitsuhiko requested a review from untitaker September 10, 2021 07:54
@mitsuhiko mitsuhiko merged commit 430227f into master Sep 10, 2021
@mitsuhiko mitsuhiko deleted the feature/client-reports branch September 10, 2021 19:55
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.

2 participants