Note: Sentry organizes applications into "Sentry Teams". To investigate errors across different applications or environments, our primary teams used are
#gitlab (for the production rails application) and
#gitlab-internal (for non-production environments). By joining said Sentry Team, the application errors should be viewable.
In addition to searching by user ID, you can also use
url: to search by GitLab.com username (case-sensitive) and specific page on GitLab.com, respectively. You can also select filtering values by clicking the "filter" button located directly to the right of the search bar.
At times a search will turn up a Sentry issue that appears to reference the information (user ID, URL, etc…) of another user and not the one that reported the issue. If this happens and you need to create an issue for that specific reporter, simply click the
Events tab as seen below to view a list of all users affected by that issue.
You can then click a specific event to view the Sentry issue for that user.
In most cases errors in Sentry can be found by searching using
user.id:, but this won't always be the case. Sometimes, you may need to search Kibana first to locate the correlation ID that can then be searched for in Sentry.
In the following example, the customer is attempting to change the notification email for one of their groups but receieves a
500 error when selecting the desired address from the dropdown list. Searching Sentry for their
user.id: turns up nothing, so we need to do the following to find the
500 in Kibana to get the correlation ID that we'll then provide to Sentry.
json.usernamewith their GitLab.com username,
Using the left-hand side menu add the
json.correlation_id fields to your search results, which should give you results similar to the following if any errors ocurred within your set time range.
Pick a correlation ID value and move over to Sentry to search for it using
correlation_id:, which should give you a result.