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

101–110 of 134 posts

Re: Grafana releases OnCall open source project

#101

Post by morelisp »

eeZah7Ux wrote: post #100
morelisp wrote: post #78

Earlier quoted context omitted.

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 cha…

No, Go modules implement a global TOFU checksum database. Obviously a compromised upstream at initial pull would not be affected, but distros (other than the well-scoped commercial ones) don’t do anything close to security audits of every module they package either. Real-world untargeted SCAs come from compromised upstreams, not long-term bad faith actors. Go modules protects against that (as well as other forms of upstream incompetence that break immutable artifacts / deterministic builds).

MVS also prevents unexpected upgrades just because someone deleted a lockfile.

Re: Grafana releases OnCall open source project

#102

Post by heavyset_go »

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 a tried and true stack, and a very good one for maintaining sane levels of reliability, consistency, durability etc. Resource wise, at least with Celery, RabbitMQ and Django, they're also pretty lean.

It even ships in containers along with Docker Compose files and Helm charts, which would suit the deployment use cases of 99% of users. I understand that you're not using containers, but I don't think that's a limitation that many are inflicting upon themselves as of late, and if pressed, installing Docker Compose takes about 5 minutes and you don't have to think about it again.

Re: Grafana releases OnCall open source project

#104

Post by dijit »

CSMastermind wrote: post #24
juliennakache wrote: post #5

Looking forward to trying this out. I've always felt that PagerDuty was absurdly expensive for the feature set they were offering. It costs something at least $250 per user for organization larger than 5 person - even if you're not an engineer who is ever directly on call. At my previous company, IT had to regularly send surveys to employees to assess if they really needed to have a PagerDuty account. Alerts are a ke…

> I've always felt that PagerDuty was absurdly expensive for the feature set they were offering For anyone out there in the same spot, I'll say that I switched my last company to Atlassian's OpsGenie and it was a 10x cost savings for the same feature set.

I really can’t find myself to ever recommend atlassian products though.

If cost is the only measure: I understand. But time lost in various areas of the software package (performance alone! Before we get into weird UX paradigms and esoteric query languages, shoddy search systems etc;) surely has an impact on cost. Having your employees spending a lot of time navigating janky software has a cost too.

Re: Grafana releases OnCall open source project

#105

Post by dijit »

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.

> At this point I trust the Go modules supply chain considerably more than any free distro's packaging

What has happened in the package ecosystem to make you believe this? Is it velocity of updates or actual trust?

I haven’t heard of any malicious package maintainers.

Re: Grafana releases OnCall open source project

#106

Post by heavyset_go »

lazyant wrote: post #97
gjulianm wrote: post #50

Earlier quoted context omitted.

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

Yes, there is nothing Kubernetes specific here, and this can be deployed using whatever container orchestration system you want.

Re: Grafana releases OnCall open source project

#107

Post by gjulianm »

lazyant wrote: post #97
gjulianm wrote: post #50

Earlier quoted context omitted.

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

The problem still stands of adding dependencies, extra complexity and configuration. I’m usually happy about Grafana/Prometheus deployments because the base installation is fairly simple and self-contained, but this looks like a bit of a mess.

Re: Grafana releases OnCall open source project

#109

Post by jthrowsitaway »

arccy wrote: post #47
CSMastermind wrote: post #24

Earlier quoted context omitted.

> I've always felt that PagerDuty was absurdly expensive for the feature set they were offering For anyone out there in the same spot, I'll say that I switched my last company to Atlassian's OpsGenie and it was a 10x cost savings for the same feature set.

the opsgenie api is really bad though if you want to manage it as code/declaratively

We evaluated a bunch of solutions and came to that conclusion as well. Everything we do is in code (Terraform) and will gladly pay for something that has friendly APIs and an already existing Terraform module. Conversely, we'll not engage with or throw away anything that doesn't have friendly APIs.

Re: Grafana releases OnCall open source project

#110

Post by pm90 »

juliennakache wrote: post #5

Looking forward to trying this out. I've always felt that PagerDuty was absurdly expensive for the feature set they were offering. It costs something at least $250 per user for organization larger than 5 person - even if you're not an engineer who is ever directly on call. At my previous company, IT had to regularly send surveys to employees to assess if they really needed to have a PagerDuty account. Alerts are a ke…

I knew Pagerduty was going down the toilet when their sales folks started aggressively pitching BS products nobody really needed before their IPO. They couldn’t even release a proper incident management tool.

I really hope this project gets good enough to ditch PD. PD should literally lay off most of its staff and just maintain the existing product, cut costs and focus mostly on integrations. There is no way they have any other future.

Post reply on HN