-
-
Notifications
You must be signed in to change notification settings - Fork 57
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(generic-metrics): Add support for gauges in dataset and processors #4912
Conversation
This supports the subscriptions to opt into using received_p99 for scheduling instead of the current orig_message_ts Needs getsentry/arroyo#295
This reverts commit c7db591. Co-authored-by: lynnagara <1779792+lynnagara@users.noreply.github.com>
This reverts commit c7db591. Co-authored-by: lynnagara <1779792+lynnagara@users.noreply.github.com>
…ion (#4915) The main motivations for this are: 1. The amount of delay depends on the synchronization timestamp used, and this is defined at the storage level in code. For example if "orig_message_ts" is used, a longer delay will be applied than if "received_p99" is used, since received will be set earlier in the pipeline. 2. The same CLI args get applied in all Sentry deployments, and this makes it easier to keep them in sync 3. Rolling out different values per storage via CLI will probably break some of our templates and require too much rework. There are no functional changes here since we have 60 configured everywhere right now.
* add test for spans profile_id and fix bug where test was dependent on local timezone
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Overall LGTM
snuba/datasets/metrics_messages.py
Outdated
sum = values["sum"] | ||
count = values["count"] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit: You can move this directly to lines 101-102
pytest.param( | ||
{"type": "d", "metric_id": 2, "value": 20}, | ||
False, | ||
id="distribution", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there a reason you added distribution to the gauge metrics processor test? I would imagine we would never want to do this in production.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, I think I mainly added it just to check that the gauges
processor does not process a message with any other type other than g
.
I can remove it if that seems redundant.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM too.
This PR:
Storage + Entity Changes
Processor Changes
Local testing
ingest-performance-metrics
Kafka topic, all the way to the Gauges aggregate table