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

91–100 of 134 posts

Re: Grafana releases OnCall open source project

#91

Post by throwaway892238 »

slotrans wrote: post #80
throwaway892238 wrote: post #77

Earlier quoted context omitted.

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!

If you only have 4 servers, make a GitHub Action (or, hell, since we're assuming one node with SQLite, a cron job on one of your 4 servers) that curls your servers every 5 minutes and sends you a text when they're down. You don't need a Lamborghini to get groceries.

Re: Grafana releases OnCall open source project

#92

Post by alex_dev »

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…

One of the most frustrating aspects of being a software engineer is dealing with others that love to over-engineer. Unfortunately, they make enough noise that complex solutions are necessary that it gets managers scared about taking any easier, simpler solutions.

Re: Grafana releases OnCall open source project

#93

Post by [deleted] »

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…

[deleted]

Re: Grafana releases OnCall open source project

#95

Post by raffraffraff »

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…

Nothing wrong with that. I managed 7+ Sensu "clusters" at a previous job, and it's stack was a ruby server, Redis and RabbitMQ. But I completely ditched RabbitMQ and used Redis for the queue and data. Simpler, more performant and more reliable (even if the feature was marked experimental). Our alerts were really spammy, and we had ~8k servers (each running a bunch of containers) per cluster, so these things were busy. Each cluster was 3x small nodes (6gb memory, 2CPU) Memory usage was miniscule, typically I get why you would add a relational DB to the mix. Personally, I'd like a Rabbit-free option.

Re: Grafana releases OnCall open source project

#96

Post by ezrast »

greatgib wrote: post #82

I would give a huge marketing bullshit award for the following sentence: > They tried to ensure that you use their SaaS offering because they care more about your own good than yourself. So humanist...

The point isn't that their infrastructure is more reliable than yours, but that it's decoupled from yours. If you run your monitoring on the same infra as production, it's liable to go down when production does, i.e. just when you need it most. This is a real reason to outsource monitoring to a SaaS, just like there are real reasons to self-host.

I mean, obviously they chose to address the segment of the market they could get more money out of first; I'm not contesting that. But the bit you quoted is low-grade bullshit at best. Hardly award-winning.

Re: Grafana releases OnCall open source project

#97

Post by lazyant »

gjulianm wrote: post #50
lazyant wrote: post #31

Earlier quoted context omitted.

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.

Installation in a regular system without Kubernetes? Right now I can install Grafana, Prometheus and Alertmanager in a regular Linux system using distribution packages, and just worry about those programs themselves. If I want to install OnCall, I need not only OnCall plus four other non-trivial dependencies that will still need configuration, management and troubleshooting. All for something that is going to deal wi…

you can install this stack without kubernetes no? I don't see anything k8s-specific

Re: Grafana releases OnCall open source project

#99

Post by lazyant »

chrisandchris wrote: post #34
lazyant wrote: post #31

Earlier quoted context omitted.

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.

Not OP, but one may interpret your response as "I don't understand why you prefer a single binary over this architecture that requires 6 different services and prefers k8s". IMHO, OP just stated that one could solve this with less dependencies and have the same (if not a better) result.

I missed that interpretation :(

IMHO a fat binary written from scratch would have been a way worse choice than to use a standard stack, both in terms of bugs and time, let alone Open Source contributions or any scalability.

In terms of number of services, what do you get rid of that produce a better result? maybe RMQ and use a worse queue?, celery and write your own task manager or use another dependency?

Re: Grafana releases OnCall open source project

#100

Post by eeZah7Ux »

morelisp wrote: post #78
eeZah7Ux wrote: post #75

Earlier quoted context omitted.

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.

This is plain false. Most production-grade distribution do extensive vetting of the packages, both in terms of code and legal.

Additionally, distribution packages are tested by a significant number of users before the release.

Nothing of this sort happens around any language-specific package manager. You just get whatever happens to be around all software forges.

Unsurprisingly, there has been many serious supply chain attacks in the last 5 years. None of which affected the usual big distros.

Post reply on HN