As part of the packaging GOB into a single binary (see discussion at https://gitlab.com/gitlab-org/opstrace/opstrace/-/issues/2955#note_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: 1) 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. 2) 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: https://gitlab.com/groups/gitlab-org/opstrace/-/epics/66+. cc @nicholasklick @mappelman @lfarina8