Skip to content

feat: Use Snuba events in group model #13905

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

Closed
wants to merge 8 commits into from
Closed

Conversation

lynnagara
Copy link
Member

@lynnagara lynnagara commented Jul 5, 2019

Refactor group model to always use events from Snuba instead of Postgres.
Rewrite a bunch of tests to use store_event instead of create_event as
this writes the events into Snuba.

Refactor group model to always use events from Snuba instead of
Postgres
@lynnagara lynnagara added the WIP label Jul 5, 2019
@@ -99,7 +116,7 @@ def test_simple_get_create(self):
'required': True,
}, {
'default': ('Sentry Issue: [%s](%s)\n\n```\n'
'Stacktrace (most recent call last):\n\n '
'Stacktrace (most recent call first):\n\n '
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why does this change?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not actually sure, @tkaemming - do you know?

Copy link
Contributor

@tkaemming tkaemming Jul 9, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hm... seems like that comes from here. Seems like the changes from create_group/create_event maybe triggered something like the platform to be saved differently? (I don't know if that's the case, I didn't follow the fixture creation down to the source.)

@@ -419,22 +391,6 @@ def get_latest_event_for_environments(self, environments=()):
issue_id=self.id,
project_id=self.project_id)

def get_oldest_event(self):
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could plugins in sentry-plugins or other plugin repos be using this?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point. I checked the whole Sentry org on github and there doesn't seem to be any other usages of this

@fpacifici fpacifici requested a review from tkaemming July 8, 2019 18:11
# Look up event_id in both Event and EventMapping,
# and bail when it matches one of them, prioritizing
# Event since it contains more history.
for model in Event, EventMapping:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think we can remove the EventMapping check yet.
EventMapping is saved if the event is sampled (see

if is_sample:
try:
with transaction.atomic(using=router.db_for_write(EventMapping)):
EventMapping.objects.create(project=project, group=group, event_id=event_id)
except IntegrityError:
logger.info(
'duplicate.found',
exc_info=True,
extra={
'event_uuid': event_id,
'project_id': project.id,
'group_id': group.id if group else None,
'model': EventMapping.__name__,
}
)
)

Even after removing events from postgres, eventmapping is going to stay.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same as below, won't all the events be in Snuba?

break
except IndexError:
pass
event = SnubaEvent.objects.from_event_id(event_id, project.id)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Before merging this, could you please check who is using the method and ensure we won't increase the load on snuba too much. Which means ensure this does not happen in the ingestion flow.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This one seems fine

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you please provide some details about the research you have done ? What did you look into ?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah sorry, this function seems to be just used in these 3 places, none of them are related to ingestion

src/sentry/web/frontend/error_page_embed.py:                    report.group = Group.objects.from_event_id(report.project, report.event_id)
src/sentry/api/endpoints/project_group_index.py:                    matching_group = Group.objects.from_event_id(project, event_id)
src/sentry/api/endpoints/project_user_reports.py:                report.group = Group.objects.from_event_id(project, report.event_id)

@@ -186,18 +173,20 @@ def from_event_id(self, project, event_id):
return Group.objects.get(id=group_id)

def filter_by_event_id(self, project_ids, event_id):
from sentry.models import EventMapping, Event
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same issue, I think the check on EventMapping is still valid because it is the only way to fetch sampled events.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was under the impression that events are not sampled in Snuba (unlike Postgres) so we would not need to additionally check EventMapping.. is that not correct?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good quesiton. @tkaemming ?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is correct, to my knowledge.

I guess if we're going to be introducing a hard dependency on Snuba for events we should probably just go ahead and get rid of all vestiges of sampling (incl. EventMapping.)

'event_id': [event_id],
'project_id': project_ids,
},
limit=1000,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Any reason for this limit specifically. And same question as before. Please ensure we do not go through this code during event ingestion.

Copy link
Member Author

@lynnagara lynnagara Jul 9, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's just some arbitrarily large number

@@ -390,21 +374,7 @@ def get_score(self):
return type(self).calculate_score(self.times_seen, self.last_seen)

def get_latest_event(self):
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This may be a little tricker to remove.
I saw it is used in the plugin code:

src/sentry/plugins/base/v1.py: event = group.get_latest_event() or Event()
src/sentry/plugins/bases/issue.py: event = group.get_latest_event()
src/sentry/plugins/bases/issue2.py: event = group.get_latest_event()
src/sentry/plugins/bases/issue2.py: event = group.get_latest_event()
src/sentry/tasks/email.py: event = group.get_latest_event()

I can think about two possible issues:

  1. load on snuba
  2. the event may have not been stored in snuba while it would already been in postgres. postgres write happens before we execute plugins in post_process.py while at that point the event has just been produced in kafka. so it may or may not have been consumed yet. This should be verified.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Re 2: We might get away with this since these all seem to be view related functions - the event object is passed to any post process plugin code so we don't need to do .get_latest_event() there

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, this might come up in slack unfurls

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually post_process is synchronized on clickhouse storage. So it should be fine https://github.com/getsentry/sentry/blob/master/src/sentry/eventstream/kafka/consumer.py#L119-L145

@@ -390,21 +374,7 @@ def get_score(self):
return type(self).calculate_score(self.times_seen, self.last_seen)

def get_latest_event(self):
from sentry.models import Event

if not hasattr(self, '_latest_event'):
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We dropped this local cache here. Is this intentional ?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, I think this was an oversight, will bring this back

@lynnagara lynnagara removed the WIP label Jul 9, 2019
@lynnagara lynnagara requested a review from fpacifici July 15, 2019 20:24
Copy link
Contributor

@fpacifici fpacifici left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd suggest to split this PR to reduce the risk and make it easier to review considering the number of possible side effects this code can have.
You could take one method on the Group class per PR so you can focus on a reduced set of possible issues when monitoring production. Also this would make a revert easier in case something goes wrong.

break
except IndexError:
pass
event = SnubaEvent.objects.from_event_id(event_id, project.id)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you please provide some details about the research you have done ? What did you look into ?

@@ -186,18 +173,20 @@ def from_event_id(self, project, event_id):
return Group.objects.get(id=group_id)

def filter_by_event_id(self, project_ids, event_id):
from sentry.models import EventMapping, Event
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good quesiton. @tkaemming ?

@@ -390,21 +374,7 @@ def get_score(self):
return type(self).calculate_score(self.times_seen, self.last_seen)

def get_latest_event(self):
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually post_process is synchronized on clickhouse storage. So it should be fine https://github.com/getsentry/sentry/blob/master/src/sentry/eventstream/kafka/consumer.py#L119-L145

lynnagara added a commit that referenced this pull request Jul 16, 2019
This is the first part of #13905,
which updates the group model to use events from Snuba instead of
Postgres. This PR just updates the from_event_id function.
lynnagara added a commit that referenced this pull request Jul 16, 2019
This is the second part of
#13905, which updates
the group model to use events from Snuba instead of Postgres.
This PR updates the filter_by_event_id function.
@lynnagara lynnagara added the Do Not Merge Don't merge label Jul 16, 2019
@lynnagara
Copy link
Member Author

lynnagara commented Jul 16, 2019

lynnagara added a commit that referenced this pull request Jul 16, 2019
lynnagara added a commit that referenced this pull request Jul 16, 2019
Removes the "snuba.events-queries.enabled" option and legacy code paths
that were not being used in production. Also removes the unused
Group.get_oldest_event method. Part 4 of #13905
lynnagara added a commit that referenced this pull request Jul 16, 2019
This is the fifth (and final) part of #13905
Group model now uses Snuba Event instead of Postgres Event everywhere.
@fpacifici
Copy link
Contributor

thanks for splitting it

lynnagara added a commit that referenced this pull request Jul 17, 2019
This is the first part of #13905,
which updates the group model to use events from Snuba instead of
Postgres. This PR just updates the from_event_id function.
lynnagara added a commit that referenced this pull request Jul 17, 2019
lynnagara added a commit that referenced this pull request Jul 17, 2019
lynnagara added a commit that referenced this pull request Jul 17, 2019
This is the second part of
#13905, which updates
the group model to use events from Snuba instead of Postgres.
This PR updates the filter_by_event_id function.
lynnagara added a commit that referenced this pull request Jul 17, 2019
This is the fifth (and final) part of #13905
Group model now uses Snuba Event instead of Postgres Event everywhere.
lynnagara added a commit that referenced this pull request Jul 17, 2019
Removes the "snuba.events-queries.enabled" option and legacy code paths
that were not being used in production. Also removes the unused
Group.get_oldest_event method. Part 4 of #13905
lynnagara added a commit that referenced this pull request Jul 18, 2019
…14038)

Removes the "snuba.events-queries.enabled" option and legacy code paths
that were not being used in production. Also removes the unused
Group.get_oldest_event method. Part 4 of #13905
lynnagara added a commit that referenced this pull request Jul 18, 2019
This is the fifth (and final) part of #13905
Group model now uses Snuba Event instead of Postgres Event everywhere.
lynnagara added a commit that referenced this pull request Jul 19, 2019
This is the second part of
#13905, which updates
the group model to use events from Snuba instead of Postgres.
This PR updates the filter_by_event_id function.
@lynnagara lynnagara closed this Jul 22, 2019
@lynnagara lynnagara deleted the ref/group-model branch July 22, 2019 18:42
lynnagara added a commit that referenced this pull request Jul 22, 2019
This is the fifth (and final) part of #13905
Group model now uses Snuba Event instead of Postgres Event everywhere.
@github-actions github-actions bot locked and limited conversation to collaborators Dec 20, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Do Not Merge Don't merge
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants