Python Leiden meetup: Handling crash reports with Bugsink - Klaas van Schelven¶

Tags: pun, python, django

(One of my summaries of the fourth Python meetup in Leiden, NL).

Bugsink is a tool/website for collecting error messages from (for instance) your websites. You get an email or other notification and you can visit the error page. You’ll see the exact error and a traceback and the environment variables and the library versions.

But… isn’t that just like sentry? Yes. Mostly.

But… why bugsink? It is self-hostable. Originally, 20 years ago, sentry was also self-hostable, but it isn’t anymore.

There’s a bit of workflow, too. You can mark issues as “fixed in the next release”. Bugsink will then ignore new occurrences of the error until it notices you made a release.

It is not just in the same market as sentry, it is even sentry-compatible. If you already have sentry set up, moving to bugsink only means changing the SENTRY_DSN setting. The API is the same.

Self-hosting? You can run a docker. He showed that pip install bugsink also works. It is just a plain regular django site with migrate and runserver. A single instance can easily handle 1.5 million errors per day.

Some generic tricks (whether sentry or bugsink):

• Just use your error tracker in development, too! The nice thing is that it preserves history. When you notice an unrelated error while working on some feature, you can continue working on your feature and go back to the error later.

  Using a local bugsink instance for this can help prevent filling up your production

• Do a pip install dsnrun. (See github). Run a failing python script with dsnrun and any traceback will be posted to your error tracker.

While building bugsink, he made a couple of surprising architectural decisions:

• Some tasks need to be run outside the main loop. With django, you often use celery. But that means installing and running a second program, which was a bit at odds with his aim of making bugsink easily self-hostable.

  So… he wrote his own library for that: snappea.

• Sqlite is the default database. Though often said to be only for small use cases, others say it can handle much bigger tasks. He uses sqlite and it can handle 1.5 million issues per day just fine.

Some answers/questions afterwards:

• License and business model? The license is https://polyformproject.org/licenses/shield/1.0.0/ , so it isn’t Stallman-compatible open source, but quite open.

• How did you make the frontend? Mostly plain html generated by django templates. He’s one developer competing with 150 sentry devs and didn’t have the bandwidth to build a fully javascript frontend. And… it isn’t needed. And it is much easier on self-hosters as they also don’t have to upgrade a big ball of javascript.

  He looked at htmx, but didn’t need it yet.