Feature request: Sentry integration

[dsferruzza]

Hi!

There are some cases where PostgREST can return a HTTP 500 response, for example when a stored procedure raises an exception (on purpose or not). In general (in apps I develop), I tend to deal with these unhandled exceptions by adding an integration to Sentry: it is an open source and SaaS product that ingests exception events (augmented by the integration to provide more context), aggregates them and notifies maintainers. (In my opinion, it is almost inconceivable to operate a real-world production system without this kind of tools; it is so useful 💜.)

Do you think this could be relevant to integrate Sentry in PostgREST, so that, if a Sentry DSN was provided in PostgREST's configuration, any failure (either from PostgreSQL or PostgREST itself) would be sent to Sentry?

---

Additional notes:

1. There seems to be a relatively up-to-date package in Hackage to play with Sentry: https://hackage.haskell.org/package/raven-haskell
2. I believe this could also be achievable in the reverse proxy (for example, with OpenResty + raven-lua) but with a poor access to context (for example, it would be harder to report which user was authenticated)

[steve-chavez]

Hey @dsferruzza.

I see the convenience of the Sentry integration. We've had a similar request on gitter chat and the recommendation was to use a log collector(logstash/fluentd) to send the logs to Sentry from there.

That being said we've just refined our logging(https://github.com/PostgREST/postgrest/pull/1604). We could see how that plays out with raven-haskell.

A PR would be welcomed :). I haven't used raven-haskell and perhaps the change is simple.

[dsferruzza]

Hi!

Using a custom log collector that sends errors to Sentry could indeed work, and provide value. This might be a better approach than doing this in the reverse proxy (even if more complex to setup, I guess) because it would not be on the critical path and might have more detailed error messages.

But from my perspective, the main point of having a native integration is to be able to provide more context in Sentry errors (for example, which user was authenticated, or maybe what queries did PostgREST already send to the database).

For example, a year ago I developed a tiny tool called Sentry Process which allows you to run any CLI process and report to Sentry if it does not exit with code 0. It works, it saved my ass in situations where I had to operate a closed-source binary that did not integrate Sentry natively, but reports are very poor because they can only leverage external outputs whereas internal context is unreachable (no stacktraces, …).

That being said, raven-haskell sure might help (if not, the Sentry protocol does not seem very complex…) but I have no idea how simple or complex it could be in PostgREST to access any context that could help in error reports from the scope where Sentry reports would be sent. In other words, if you could serialize and append these context items in every log output, I would be pretty confident that providing a Sentry integration is actually quite easy 🤞

Does this make sense to you? You know this codebase (I really don't), does this seem achievable?

[evelant]

@dsferruzza I'm interested to know if you ever found a solution for this. I'm using Supabase so I don't have a traditional server between my app and postgres. I landed here searching for a way to add some tracing or error logging since supabase uses postgrest as a primary interface for the db.

[dsferruzza]

@dsferruzza I'm interested to know if you ever found a solution for this. I'm using Supabase so I don't have a traditional server between my app and postgres. I landed here searching for a way to add some tracing or error logging since supabase uses postgrest as a primary interface for the db.

Unfortunately no, I do not have a solution 😐

[jbstewart]

I would also welcome integration with Sentry!