Gitlab Integrated Error tracking in self-managed environments
As part of the packaging GOB into a single binary (see discussion at #2955 (comment 2121348972)), there are a few open questions with respect to integrated Error tracking as it has been developed differently than OTEL compatible signals such as Logs or Traces.
Integrated error tracking (ET henceforth) is currently available in General Availability for all 3 tiers on Gitlab.com as per the docs: https://docs.gitlab.com/ee/operations/integrated_error_tracking.html.
Making ET available for self-managed requires attention to two things, while keeping our assumption of customers bringing their own ClickHouse:
- Authentication on write path
- Current authentication relies on gitlab.com API validating client keys being presented to our ingress. While this in principle can be done transparently by a self-managed gitlab instance, assumptions around connecting to gitlab API needs to validated.
- Authentication of read path
- Current method relies on a shared token between GOB and our .com instance being presented by the internal rails API that queries GOB. With self-managed instance, this perhaps may not be the best way to authenticate and also requires validation.
There is also a concern that adjusting our existing ET authentication methods for self-managed would also mean there are essentially 3 different auth approaches for a single binary.
There is also a broader question of whether we continue to support integrated error tracking in the same form (a drop-in replacement of sentry) or we see errors as a first class citizen on our observability features and cover the same features.
There is also a previous discussion here on the same lines: Proposal : Integrate Error Tracking within Trac... (&66 - closed).