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

71–80 of 134 posts

Re: Grafana releases OnCall open source project

#71

Post by theptip »

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.

Here's the option I'm familiar with (siblings have others too):

https://github.com/malthe/pq

Doesn't have all the plumbing you'd want, there is a wrapper (https://github.com/bretth/django-pq/) that seems to give you an entrypoint command more like `celery worker ...` but I've not investigated it closely.

Re: Grafana releases OnCall open source project

#72

Post by dividedbyzero »

ketralnis wrote: post #29
nojito wrote: post #15

Earlier quoted context omitted.

GPL and its variants are a no go where I work.

To distribute I understand, but even just to use? Almost any desktop OS you run has GPL code somewhere in it

Almost any desktop OS? I may be wrong but I don't think Windows and macOS contain any GPL code.

Re: Grafana releases OnCall open source project

#73

Post by goodpoint »

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…

That's very bad. 99% of organizations don't have a volume of alerts that justifies any of MySQL, Redis and RabbitMQ.

Complexity comes at a steep price when something critical (e.g. OnCall) breaks and you have to debug it in a hurry.

Shoving everything in a container and closing the lid does not help.

Re: Grafana releases OnCall open source project

#74

Post by matsemann »

Volundr wrote: post #70
matsemann wrote: post #46

Earlier quoted context omitted.

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?

For deploying your own stuff, most people do as before, yes. But even then, it's at least still only a single jar file, containing all dependencies. Not like a typical python project where they ask you to run some command to fetch dependencies and you have to pray it will work on your system.

But using jlink for java, one can package everything to a smaller runtime distributed together with the application. So then I feel it will be not much different than a Go executable.

> The generated JRE with your sample application does not have any other dependencies...

> You can distribute your application bundled with the custom runtime in custom-runtime. It includes your application.

From the guide here https://access.redhat.com/documentation/en-us/openjdk/11/htm...

Re: Grafana releases OnCall open source project

#75

Post by eeZah7Ux »

MarquesMa wrote: post #43
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…

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.

Hell no, I want stuff like OnCall packaged into Linux distribution. I need something stable and reliable and that receive security fixes.

Maintaining tenths of binaries pulled from random github projects over the years is a nightmare.

(Not to mention all the issues around supply chain management, licensing issues, homecalling and so on)

Re: Grafana releases OnCall open source project

#76

Post by slotrans »

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…

You don't need Rabbit, Celery, or Redis. You should be able to replace MySQL with SQLite. Then it would be radically easier to deploy.

Re: Grafana releases OnCall open source project

#77

Post by throwaway892238 »

slotrans wrote: post #76
motakuk wrote: post #53

Earlier quoted context omitted.

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…

You don't need Rabbit, Celery, or Redis. You should be able to replace MySQL with SQLite. Then it would be radically easier to deploy.

A MySQL database cluster, and a local copy of a SQL database on a single file on a single filesystem, are not close to the same thing. Except they both have "SQL" in the name.

One of them allows a thousand different nodes on different networks to share a single dataset with high availability. The other can't share data with any other application, doesn't have high availability, is constrained by the resources of the executing application node, has obvious performance limits, limited functionality, no commercial support, etc etc.

And we're talking about a product that's intended for dealing with on-call alerts. The entire point is to alert when things are crashing, so you would want it to be highly available. As in, running on more than one node.

I know the HN hipsters are all gung-ho for SQLite, but let's try to reign in the hype train.

Re: Grafana releases OnCall open source project

#78

Post by morelisp »

eeZah7Ux wrote: post #75
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.

Hell no, I want stuff like OnCall packaged into Linux distribution. I need something stable and reliable and that receive security fixes. Maintaining tenths of binaries pulled from random github projects over the years is a nightmare. (Not to mention all the issues around supply chain management, licensing issues, homecalling and so on)

At this point I trust the Go modules supply chain considerably more than any free distro's packaging, which is ultimately pulling from GitHub anyway.

Re: Grafana releases OnCall open source project

#79

Post by slotrans »

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.

This is a very confused question. The data store you keep your queued items in is completely orthogonal to what a message queue actually is.

A simple way to use an RDBMS as a message queue, that has been in use since before most HN readers were born, is roughly:

  - enqueue an item by inserting a row into a table with a status of QUEUED
  - use a SELECT FOR UPDATE, or UPDATE...LIMIT 1, or similar, to atomically claim and return the first status=QUEUED item, while setting its status to RUNNING (setting a timestamp is also recommended)
  - when the work is complete, update the status to DONE
There are more details to it obviously but that's the outline.

The first software company I worked for was using this basic approach to queue outbound emails (and phone and fax... it was 2005!), millions per day, on an Oracle DB that also ran the entire rest of the business. It's not hard.

Re: Grafana releases OnCall open source project

#80

Post by slotrans »

throwaway892238 wrote: post #77
slotrans wrote: post #76

Earlier quoted context omitted.

You don't need Rabbit, Celery, or Redis. You should be able to replace MySQL with SQLite. Then it would be radically easier to deploy.

A MySQL database cluster, and a local copy of a SQL database on a single file on a single filesystem, are not close to the same thing. Except they both have "SQL" in the name. One of them allows a thousand different nodes on different networks to share a single dataset with high availability. The other can't share data with any other application, doesn't have high availability, is constrained by the resources of the…

I don't need any of that stuff, and nor does anyone who would use this. People who need clustered high-availability stuff are paying for PagerDuty or VictorOps.

This is for tiny shops with 4 servers. And tiny shops with 4 servers don't have time to spin up a horrendous stack like this. I was excited to see this announcement until I saw all the moving pieces. No thanks!

Post reply on HN