GlitchTip: An open source, Sentry API compatible error tracking platform | Hacker News Reader

GlitchTip: An open source, Sentry API compatible error tracking platform

gitlab.com

107 pointsbenatkin18 comments

I use GlitchTip — it works well! A bit hard to deploy (many moving parts) but that’s more a problem with F/OSS Sentry.

It’s been nice being able to use the sentry reporting ecosystem with it (including newer reporters for stuff like Svelte)

> A bit hard to deploy (many moving parts)

How does this compare to Self Hosted Sentry? It looks like GlitchTip only requires 4 components (backend, workers, Redis, and postgresql). Self Hosted Sentry requires many more (at least a dozen, including clickhouse, zookeeper, Kafka, Redis, multiple backends, etc). Self Hosted Sentry seems pretty stable once deployed but it is a lot to deal with.

Ah the comparison wasn't to self-hosted Sentry, it was to other self-hosted software in general. Django and Rails project tend to take just a bit more to get deployed.

Also stability on GlitchTip has been great for me -- haven't had to worry about it or babysit it too much.

Very small scale but still quite promising.

Also note that there's a GlitchTip cloud[0] for people who don't want to worry about it!

[0]: https://glitchtip.com/pricing

I'd love to know more about what makes Django harder to deploy. Is there an example you're comparing it to? Is there a solution that you can imagine that would make it easier?

Ideal for deploy-ability is a single binary/container and database (for most small single machine projects you can even get away with SQLite).

Django is not that, by default.

Self-hosted Sentry (on k8s) was a nightmare for me. Babysitting Kafka and Clickhouse at the same time is not for the faint of heart. For better or worse you're running their full saas product, but you can't get paid support for it. They want to push you towards cloud.

That’s fair, I think. In contrary to many others, they at least provide the code for their saas product - I wouldn’t expect them to try and make it even easier to not use their paid offering.

Hey Glitchtip! Been a happy user for going on a year or so. Super easy to self-host, and because it uses the existing sentry libs it's really reliable. One of the most set and forget services I've had the pleasure of using.

Bold claim but given the choice I would take Sentry+Glitchtip over Rollbar for Sentry libs alone.

How come? What do the sentry libs provide?

Oh hey! I built a huge chunk of the frontend. Not working with them anymore but I’m proud to have been a part of it. Just a nice, clean product.

> Sentry's open source codebase before it went proprietary

What do you mean? Sentry is still open source and you can self host it.

From Sentry’s site:

> All these lead us to use the Business Source License, which we describe as eventually open source. Although this license is not among the OSI-approved licenses and does not fit the strict OSI definition of open source, it gives you all the freedoms provided you are not offering a commercial version of Sentry.

https://open.sentry.io/licensing/

So, I noticed this past week that u-block is blocking browser error reporting on their hosted product. I tested a custom subdomain using their relay container, as well as just a sub-path on primary domain and both were also blocked. This seems like an Achilles heel for sentry.

Any thoughts on how to get info on front end problems for people with ad-blockers which would appear to be in use by ~40% of users? I almost feel like we need some web framework level error reporting that isn't as obvious that it get's picked up by ad-blockers.

I think the recommend approach is to use the tunnel option. [1] You will also want to host the javascript SDK yourself, or bundle the package directly into your release build.

[1] https://docs.sentry.io/platforms/javascript/troubleshooting/...

Sentry is great but I’ve noticed that it significantly increases the request response time which makes it unusable for high traffic web apps. This happens with both the hosted and self-hosted instances. I’m not sure if it’s due to bad configuration or PHP. I’ll give this a try and see…

This is due to how PHP and Sentry for PHP works. It sends out the data after every request to Sentry backend via HTTP. Depending on your network path to their servers, I have seen this take 10-100ms. This is different on how other APMs work for PHP, for example Tideways that I work on, or DataDog/NewRelic/Blackfire. They have a local agent running that accepts the data over socket/tcpip before sending it to the backend for processing.

The workaround in case of Sentry is to deploy the Sentry Relay in your network and send all data there.

Depending on PHP Sentry client version,

Sentry client v1 (Raven_Client) you can configure the client in different send modes (curl_method), sync (default), async (curl_multi), exec (fork)

https://docs.sentry.io/clients/php/config/

For Sentry client v2 I think you need to configure the Transport layer to use async

https://docs.sentry.io/platforms/php/configuration/transport...

The homepage shows what the product looks like for those who were wondering: https://glitchtip.com/

Reply on news.ycombinator.com