4 ms·

This is so true. Sentry's architecture[1] is insanely complex. It runs some ~30 containers on the instance and all you've to pray is that their tooling[2] for `

This is so true. Sentry's architecture[1] is insanely complex. It runs some ~30 containers on the instance and all you've to pray is that their tooling[2] for `docker-compose` _just works_. [1]: https://develop.sentry.dev/architecture/ https://develop.sentry.dev/architecture/ [2]: https://github.com/getsentry/self-hosted https://github.com/getsentry/self-hosted

the_mitsuhiko 4y ago
Armin from Sentry here: It's definitely something we're battling with. At the scale we're operating, providing all features on an alternative architecture that does not involve as many independent pieces is pretty tricky. I'm somewhat hopeful that we see reduction in the total types of moving pieces over time at least.
- mekster 4y ago
  At least for our small use case, the web interface is snappy enough that it's just about spending more money to host it but I'd definitely like it to reduce its memory usage as I'll have to double the server size just for Sentry.
- mr-karan 4y ago
  Hey Armin. That's very nice to hear that reduction is something on your roadmap. Pre Snuba, the number of external services were fairly limited but I understand as Sentry got more mature and added a bunch of extra services than "just error/crash reports" is when the architecture also sorta started to become complex.
  - the_mitsuhiko 4y ago
    It's not even just that there are extra services, it's that the volume of traffic is just too high for rabbitmq. So we put a bunch of kafka in and with that, the complexity quickly went up as you end up writing more and more consumers. Most of the services still mostly "just do crash and error reports" but they are doing it in more scalable ways now. Snuba is one of the services that largely really requires kafka to function though I think theoretically limited functionality is also available by directly talking HTTP to it.

the_mitsuhiko 4y ago

Armin from Sentry here: It's definitely something we're battling with. At the scale we're operating, providing all features on an alternative architecture that does not involve as many independent pieces is pretty tricky. I'm somewhat hopeful that we see reduction in the total types of moving pieces over time at least.

mekster 4y ago
At least for our small use case, the web interface is snappy enough that it's just about spending more money to host it but I'd definitely like it to reduce its memory usage as I'll have to double the server size just for Sentry.
mr-karan 4y ago
Hey Armin. That's very nice to hear that reduction is something on your roadmap. Pre Snuba, the number of external services were fairly limited but I understand as Sentry got more mature and added a bunch of extra services than "just error/crash reports" is when the architecture also sorta started to become complex.
- the_mitsuhiko 4y ago
  It's not even just that there are extra services, it's that the volume of traffic is just too high for rabbitmq. So we put a bunch of kafka in and with that, the complexity quickly went up as you end up writing more and more consumers. Most of the services still mostly "just do crash and error reports" but they are doing it in more scalable ways now. Snuba is one of the services that largely really requires kafka to function though I think theoretically limited functionality is also available by directly talking HTTP to it.