Skip to content

Rename `Gitlab::Sentry` to be Sentry-agnostic

The following discussion from !17819 (merged) should be addressed:

  • @fabiopitino started a discussion: (+3 comments)

    I'm wondering whether we should go one step forward and rename Gitlab::Sentry to Gitlab::ErrorTracking to be Sentry agnostic.

    If we use Gitlab::Sentry.log_exception(e) a dev may be tempted to check Sentry if anything shows up there while instead we should check Kibana.


    Side note

    In this retrospective issue I found that a critical background worker (ClearSharedRunnersMinutesWorker) had failed. I say it's critical because handling shared Runners minutes now means handling customers money. The exception was correctly sent to Sentry but it didn't cause any alarming bells because, being a background worker, it didn't have a User associated to it. So Users count was 0.

    I think we have some critical parts of the application that we would benefit from sending an alert, e.g. email or slack alert. To do that we could plug this feature into this class if it's named more generically Gitlab::ErrorTracking. E.g. Gitlab::ErrorTracking.track_and_alert_exception(e).

    What do you think?

Edited by Aleksei Lipniagov