Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Grafana releases OnCall open source project

grafana.com

Post reply on HN
Print view View original

61–70 of 134 posts

Re: Grafana releases OnCall open source project

#61

Post by minusf »

pphysch wrote: post #23

A bit disappointed by the architecture -- it's a Django stack with MySQL, Redis, RabbitMQ, and Celery -- for what is effectively AlertManager (a single golang binary) with a nicer web frontend + Grafana integration + etc. I'm curious why/if this architecture was chosen. I get that it started as a standalone product (Amixr), but in the current state it is hard to rationalize deploying this next to Grafana in my curren…

not gonna argue that a single binary is the ultimate deploy solution but running a django app is not that difficult (although i am biased cause i do that for a living).

i love django projects but mysql, celery and rabbitmq -- no thanks.

Re: Grafana releases OnCall open source project

#62

Post by gen220 »

motakuk wrote: post #53
pphysch wrote: post #23

A bit disappointed by the architecture -- it's a Django stack with MySQL, Redis, RabbitMQ, and Celery -- for what is effectively AlertManager (a single golang binary) with a nicer web frontend + Grafana integration + etc. I'm curious why/if this architecture was chosen. I get that it started as a standalone product (Amixr), but in the current state it is hard to rationalize deploying this next to Grafana in my curren…

I agree that multi-component architecture is harder to deploy. We did our best and prepared tooling to make deployment an easy thing. Helm ( https://github.com/grafana/oncall/tree/dev/helm/oncall ), docker-composes for hobby and dev environments. Besides deployment, there are two main priorities for OnCall architecture: 1) It should be as "default" as possible. No fancy tech, no hacking around 2) It should deliver no…

I think your decisions were reasonable, as is the opinion of the person you're responding to.

To be fair, even in its current form, it should be possible to operate this system with sqlite (i.e. no db server) and in-process celery workers (i.e. no rabbit MQ) if configured correctly, assuming they're not using MySQL-specific features in the app.

Using a message bus, a persistent data store behind a SQL interface, and a caching layer are all good design choices. I think the OP's concern is less with your particular implementations, and more with the principle of preventing operators from bringing their own preferred implementation of those interfaces to the table.

They mentioned that it makes sense because you were a standalone product, so stack portability was less of a concern. But as FOSS, you're opening yourself up to different standards on portability.

It requires some work on the maintainer to make the application tolerant to different fulfillments of the same interfaces. But it's good work. It usually results in cleaner separation of concerns between application logic and caching/message bus/persistence logic, for one. It also allows your app to serve a wider audience: for example, those who are locked-in to using Postgres/Kafka/Memcached.

Re: Grafana releases OnCall open source project

#63

Post by Deritio »

I like what grafana labs does with grafana.

Im annoyed by their license choice.

But apparently when you are grafana everything looks like a dashboard UI?

Joke aside I will have a look but I didn't like the screenshots before already. I like the dashboardy thing for dashboards but otherwise it's not a really good UI system for everything else.

Re: Grafana releases OnCall open source project

#64

Post by pphysch »

minusf wrote: post #61
pphysch wrote: post #23

A bit disappointed by the architecture -- it's a Django stack with MySQL, Redis, RabbitMQ, and Celery -- for what is effectively AlertManager (a single golang binary) with a nicer web frontend + Grafana integration + etc. I'm curious why/if this architecture was chosen. I get that it started as a standalone product (Amixr), but in the current state it is hard to rationalize deploying this next to Grafana in my curren…

not gonna argue that a single binary is the ultimate deploy solution but running a django app is not that difficult (although i am biased cause i do that for a living). i love django projects but mysql, celery and rabbitmq -- no thanks.

Don't get me wrong, I love Django and think its a great framework for writing internal tools like this. Redis gets a pass too since Django has native support for it in 4.0+. It's really the (IMHO unnecessary) combo of MySQL+RabbitMQ+Celery that turns me off.

Redis itself has had solid support for building reliable distributed task streaming for nearly 4 years (Redis ConsumerGroups introduced in 2018).

Re: Grafana releases OnCall open source project

#65

Post by danlimerick »

pachico wrote: post #49

I love Grafana, don't get me wrong, but I have the sensation they are now in that position where, companies that got a massive capital injection and, therefore, a massive increase of work power, release too much and too soon. It doesn't have anything to do, of course, with the fact that this morning we suddenly found that all our dashboards stopped working because we were upgraded to Grafana v9, for which there is no…

I apologize for the disruption we caused you when rolling out Grafana 9. We are working on improving our releases to Grafana Cloud and also on making sure that errors due to breaking changes in a major release won't affect customers in the future. As a Grafana Cloud customer, you shouldn't need to read docs about breaking changes when we upgrade your instance.

Re: Grafana releases OnCall open source project

#66

Post by mkl95 »

pphysch wrote: post #23

A bit disappointed by the architecture -- it's a Django stack with MySQL, Redis, RabbitMQ, and Celery -- for what is effectively AlertManager (a single golang binary) with a nicer web frontend + Grafana integration + etc. I'm curious why/if this architecture was chosen. I get that it started as a standalone product (Amixr), but in the current state it is hard to rationalize deploying this next to Grafana in my curren…

> Django stack with MySQL, Redis, RabbitMQ, and Celery

MySQL is a weird if not slightly disturbing choice. Other than that it's a boring, battle-tested stack that is relatively easy to scale. I agree that Go is nicer, but I'm biased by several years of dealing with horrific Flask / Django projects.

Re: Grafana releases OnCall open source project

#67

Post by minusf »

picozeta wrote: post #52
theptip wrote: post #36

Earlier quoted context omitted.

For a simple low-scale app you can often do without Redis and Celery/RMQ if you just push everything into Postgres. Far less scalable, but it is dramatically simpler to deploy. Often gets you surprisingly far though. Would be interesting to know how many monitored integrations could be supported by that flow.

How does a message queue work via Postgres? Many people (including me) use Redis to run background jobs.

https://github.com/procrastinate-org/procrastinate

https://github.com/gavinwahl/django-postgres-queue

Re: Grafana releases OnCall open source project

#68

Post by pphysch »

lazyant wrote: post #31
pphysch wrote: post #23

A bit disappointed by the architecture -- it's a Django stack with MySQL, Redis, RabbitMQ, and Celery -- for what is effectively AlertManager (a single golang binary) with a nicer web frontend + Grafana integration + etc. I'm curious why/if this architecture was chosen. I get that it started as a standalone product (Amixr), but in the current state it is hard to rationalize deploying this next to Grafana in my curren…

Curious as to what architecture you would have preferred or why this pretty standard stack (that can be deployed to k8s) is not giving you.

Any of the following:

Python(Django)+Redis+[SQLite]

Python(Django)+Postgres

[Compiled Go binary]+[SQLite]

SQLite barely even counts as an architectural dependency TBH :)

Re: Grafana releases OnCall open source project

#69

Post by pachico »

danlimerick wrote: post #65
pachico wrote: post #49

I love Grafana, don't get me wrong, but I have the sensation they are now in that position where, companies that got a massive capital injection and, therefore, a massive increase of work power, release too much and too soon. It doesn't have anything to do, of course, with the fact that this morning we suddenly found that all our dashboards stopped working because we were upgraded to Grafana v9, for which there is no…

I apologize for the disruption we caused you when rolling out Grafana 9. We are working on improving our releases to Grafana Cloud and also on making sure that errors due to breaking changes in a major release won't affect customers in the future. As a Grafana Cloud customer, you shouldn't need to read docs about breaking changes when we upgrade your instance.

Dude, I hope you also read when I say that I love what you do and your reply just confirms I'm putting my money in the right hands.

I just wouldn't mind to be the last to upgrade to a newer version :)

Re: Grafana releases OnCall open source project

#70

Post by Volundr »

matsemann wrote: post #46
MarquesMa wrote: post #43

Earlier quoted context omitted.

This. I find open source projects written in Go or Rust are usually more pleasant to work with than Java, Django or Rails, etc. They have less clunky dependencies, are less resource-hungry, and can ship with single executables which make people's life much easier. Just think about Gitea vs GitLab.

Not sure why you include java in that, as you mostly get a standalone file. No such thing as a jre in modern java deployment. As for python, at least getting a dockerfile helps a lot. Otherwise it's a huge mess to get running, yes. Python is still a hassle anyways, since the lack of true multithreading means that you often need multiple deployments, which the Celery usage here for instance shows.

> Not sure why you include java in that, as you mostly get a standalone file. No such thing as a jre in modern java deployment.

Maybe I'm behind the times, but I can't figure out what you mean here. As far as I know 'java -jar' or servlets are still the most common ways of running a Java app. Are you talking graal and native image?

Post reply on HN