Sentry.io support to monitor errors

[21h]

At startup check SENTRY_DSN env variable to activate sentry errors logging. Useful for investigation of bugs.

[codecov-io]

Codecov Report

Merging #7667 into master will increase coverage by <.01%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master    #7667      +/-   ##
==========================================
+ Coverage   41.41%   41.41%   +<.01%     
==========================================
  Files         474      474              
  Lines       63876    63876              
==========================================
+ Hits        26453    26455       +2     
+ Misses      33978    33975       -3     
- Partials     3445     3446       +1

Impacted Files	Coverage Δ
models/unit.go	67.56% <0%> (+5.4%)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update cde95f9...d8772f2. Read the comment docs.

[zeripath]

Sentry requires that you actually tell it about errors - it's not magic.

So you would have to next either add multiple specific sentry reporting blocks everywhere that an error is found or, better, just create a sentry logger provider to get it to report an errors.

To then make it really useful requires adding context - this is where the real problems start - you're going to have to place sentry calls almost everywhere to give it context. This might be possible with a macaron.Handler at an appropriate level I guess(?) but it might require changing the macaron router code to actually properly handle breadcrumbs, and the login process etc.

But all of this, placing code at key points in our system, is to provide logging to a proprietary (Edit:) another logging system.

Now... I agree we can do logging better. I agree with Sentry's idea about context - and have been thinking about it quietly for some time (albeit from a python twisted view). However I do not believe that tightly integrating a proprietary system like this in to an open source project like Gitea is necessarily appropriate. (Edit) Tightly integrating another logging system might not necessarily be the correct thing to do - although I'm not fundamentally against this I think we need to be careful about what we integrate.

Now if we can do this in such a way to improve logging in general - then great let's go for it.

---

My initial reading of the Sentry documentation made me think that you could not host a DSN yourself and that you had to pass data up to their services. I was incorrect.

[lafriks]

@zeripath I have not used it but imho sentry is open source

Offtopic: I for one would like to see Elastic APM integrated

[zeripath]

@lafriks - ah sorry I missed that you could host a DSN yourself. A quick scan through the documentation implied that you had to pass stuff to their DSN.

[lunny]

We still need repanic: true ?

[21h]

sentry is a nice choice to get events, it really helps to find problems with code or server itself.

[stale]

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs during the next 2 months. Thank you for your contributions.

[stale]

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs during the next 2 months. Thank you for your contributions.

[alexanderadam]

To then make it really useful requires adding context

I just want to add that, besides error tracking, Sentry is also able to track releases* (I would also love to have a gitea webhook for that) and deploys.
So I guess it would be nice as well to see when a certain gitea version was deployed if there is suddenly unwanted behaviour.

And yes, as you correctly pointed out, Sentry is open source and you can simply host it on your own with the official Docker images for example. Similar to gitea.

*I'm not quite sure whether sentry-go is able to track releases?