Hey! I’m writing this just after publishing my first package on the AUR,
sway-borders-git. Over the past week, I’ve done some important work to improve sway-borders1 and get it ready for packaging. As promised in my original PR to upstream, different classes of border textures are now supported for different container states (
urgent). While cleaning up the rendering code, I’ve also fixed a long-standing bug with floating containers having only one border drawn. While certainly a little stressful, I’m happy to contribute to the AUR and hope to continue doing so in the future. Go try it out:
git clone https://aur.archlinux.org/sway-borders-git.git
Continuing with a little more Sway, I’ve gotten my graphics tablet working and decided to try my hand at a little bit of digital art. Here are my attempts at some crystals which I drew with the help of a few tutorials.23
My first attempt, which got inadvertently mirrored.
A much better second attempt, great for a profile picture.4
I think I overdid it with the white highlights, but otherwise it’s quite nice.
Moving on, I’ve thought quite a bit about what place Snitch (and, by relation, Sentry) has in my planned logging infrastructure and what direction I want to take it in. Initially, as I stated in my original post,5 I wanted it to be a centralized place for all my errors. However, this has some flaws:
- It’s too much: I’m an individual, not a large, or even small, team
- My email inbox is a great centralized place for alerts
- Django, the web framework I’ve used for most of my running projects, natively supports email alerting for errors
Alright, a little disheartening, but the solution seems super easy, just switch to emails! Well…
- If many errors occur, I’ll get spammed: not the greatest
- Two places of configuration: Alertmanager6 & Django
- Some extra processing on errors to add more context or other helpful information is something I’m interested in7
- Temporarily ignoring and grouping the same kinds of errors is also quite handy
Now some of these are definitely a stretch, I don’t need extra processing or grouping. The first point is really the only hard requirement I have, and it could be quickly solved with a custom logging handler. However, there’s another tool that I’m already going to be using which handles everything I need: Prometheus’s Alertmanager. It takes alerts, groups them, inhibits them, and sends them through whatever communication channel is configured. That only leaves #3, alongside the connection between my application and Alertmanager.
And so, the new direction that *Py-*Snitch takes will be to add meaningful context to Python exceptions and pass them on to Alertmanager’s HTTP API. Eventually, I plan on doing this with other languages I use, and I think that a centralized service that sits between the integration and Alertmanager might eventually prove useful (read: won’t happen), for example to combine errors from multiple applications, so I’ll leave the name Snitch open for that.
That’s it for this month, see you next time :D
…..well this blog post turned out to be a bit longer than I thought it would, back to coding-
wink wink, nudge nudge - please don’t use it yourself though. ↩︎
I will be using Alertmanager to notify me of important changes detected through Prometheus metrics. ↩︎
Such as adding relevant, nearby source code snippets or Django request properties. ↩︎