Skip to content

Error Tracking, like Sentry backend but inside GitLab

This page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.

Release notes

Like Sentry backend but inside GitLab

Key points:

  1. Error tracking will work out of the box. No need for Sentry self-hosted instance. The necessary API will be inside GitLab
  2. Errors will be stored in GitLab database. No need to query Sentry backend api for data.
  3. GitLab error tracking API will be compatible with sentry-sdk. So users can switch between Sentry backend and GitLab backend without adjustments to code.

Re-using existing functionality

We already have models and UI for rendering Sentry errors in GitLab UI. We should reuse that code for presenting and rendering errors in UI.

Limitations and expectations

Sentry is a big and well developed product. The goal here is to provide an easy, out-of-the-box experience for users who are not interested in running a separate Sentry instance.

TODO:

For minimal product we need the following steps:

Core functionality
Important improvements
  • Cleanup app/validators/json_schemas/error_tracking_event_payload.json
  • Add integrated setting check in collector => !67756 (merged)
  • Add index on error_tracking_errors.status column, => !68777 (merged)
  • Refactor error tracking API: move under namespace => !70939 (merged)
  • Generate DSN based on client key => !68487 (merged)
  • last seen at is not updated on error tracking list UI => !68952 (merged)
  • Expose sentry_dsn via API => !68767 (merged)
  • Fix error mulpliying when object id used in error description. Ex: ProjectControllerx0fd432 => !68952 (merged)
  • Make Event#actor more flexible. Ex. in sentry-clj the payload does not have such value. => b79a4e9b
  • Add support for /store collector endpoint => !69660 (merged)
  • Show first seen and last seen info on error details => !71405 (merged)
  • Add gzip compression support to /store method (needed for python and php support) => !71949 (merged)
  • Fix 500 errors on invalid payload => !73557 (merged)
  • Support major Sentry SDK => #340178 (closed)
  • Remove unused data from event payload.
  • Optimise stacktrace storing (maybe keep N last stacktraces per error)
Good to have improvements
  • Create fixtures files from different SDK and add them to spec
  • Add ability to create and delete error tracking client keys via UI
  • Save release info into event !69378 (closed)
  • Refactor project error tracking settings. Move everyting related to sentry_client into separate class
  • Email notification on new errors would be great
  • Rename SentryRequestParser to SentryEnvelopeParser !73744 (closed)
  • Add 24h stats to error
  • UI search does not work yet
  • Refactor collector service for better error handling #344789 (closed)
  • Add support for sentry message. See capture_message from https://docs.sentry.io/platforms/ruby/usage/
  • Allow download raw payload
  • Show more data in UI like level, environment etc

End result

After this issue is finished, user should be able to:

  1. Enable integrated error tracking in GitLab UI
  2. Receive a DSN from GitLab to use with Sentry SDK
  3. Have Gitlab receive and save errors from Sentry SDK
  4. Browse saved errors at project /error_tracking page

Timeline

  • 14.3 Error tracking for Ruby SDK. Feature enabled by API
  • 14.4 Error tracking for Ruby SDK. Feature can be enabled in UI. GitLab backend is default.
  • 14.5 More SDK support => #340178 (closed)
  • 14.6 Enabled by default for new projects
Edited by Dmytro Zaporozhets (DZ)