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

121–130 of 134 posts

Re: Grafana releases OnCall open source project

#121

Post by therealdrag0 »

dijit wrote: post #104
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.

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.

At least with OPsGenie it feels like too few features instead of feature bloat hah. But it’s been fine for me as an engineer.

Re: Grafana releases OnCall open source project

#122

Post by yashap »

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…

Agreed. Cost really is the big selling point of Grafana Cloud - it’s far, far cheaper than most competitors, and good enough. Not as good as NewRelic, DataDog, etc., but you get good enough metrics, logs, alerts, distributed tracing, and now incident management, at an excellent price.

Re: Grafana releases OnCall open source project

#123

Post by morelisp »

dijit wrote: post #105
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.

> 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.

Better automation ensuring packages are immutable, fewer humans in the packaging loop.

Re: Grafana releases OnCall open source project

#124

Post by sandstrom »

netingle wrote: post #51
sandstrom wrote: post #28

I think it would be great if it was easier to mix and match Grafana SaaS and self-hosted products. For example, we need to run Loki ourselves, for security / privacy reasons, but wouldn't mind using hosted versions of Tempo, Prometheus and OnCall. Right now it isn't super-easy to link e.g. self-hosted loki search queries with SaaS-Prometheus.

Its very much our aim to make this mix of self-hosted and cloud services as easy as going all-cloud; but I agree we're not quite there yet. Do you mind if I ask what isn't super-easy about linking self-hosted loki search queries with SaaS-Prometheus? You should be e.g. able to add a Prometheus data source to your local Grafana (or securely expose your Loki to the internet and add a Loki data source to your Cloud Graf…

Honestly I haven't tried that much, but didn't find anything in the docs so I assumed it wasn't a prioritized area.

In our particular scenario, we'd probably want to run Loki + Grafana locally, and then hosted Prometheus + hosted Grafana for metrics.

But would be great if we could just tell the two about each other, and under which domains they exist. That way, Prometheus-grafana could construct URLs that linked straight into Loki-grafana (that we host) for e.g. the same interval, or the same label filter (GET params).

But it would only work if I (the end-user) had access to both. That way, we don't have to expose Loki to the internet. But linking would still work.

There are quite a lot of services that does this with Github and commits. You can link from e.g. Bugsnag to Github by only telling Bugsnag your org and repo names. But Bugsnag won't have read access to Github (they also have another integration method which does require access, but that's not the one I'm talking about here).

Those types of "linking into a known URL pattern of another service" integrations are easy to setup and very easy to secure.

Re: Grafana releases OnCall open source project

#127

Post by dijit »

morelisp wrote: post #123
dijit wrote: post #105

Earlier quoted context omitted.

> 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.

Better automation ensuring packages are immutable, fewer humans in the packaging loop.

generally I prefer humans in the loop, someone to actually test things. This is why distros are stable compared to other distros which are more bleeding edge.

Re: Grafana releases OnCall open source project

#128

Post by morelisp »

dijit wrote: post #127
morelisp wrote: post #123

Earlier quoted context omitted.

Better automation ensuring packages are immutable, fewer humans in the packaging loop.

generally I prefer humans in the loop, someone to actually test things. This is why distros are stable compared to other distros which are more bleeding edge.

For SC security, the fewer points of attack between me and the source the better.

For other kinds of quality, I have my own tests which are much more relevant to my use cases than whatever the distro maintainers are doing.

I've been a DD and while distros do work to integrate disparate upstreams as well as possible, they rarely reject packages for being fundamentally low quality or make significant quality judgements qua their role as maintainer (only when they're a maintainer because they're also a direct user). Other distributions do even less than Debian.

Re: Grafana releases OnCall open source project

#129

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…

> None of which affected the usual big distros.

I guess we can argue about "big" but didn't both Arch (https://lists.archlinux.org/pipermail/aur-general/2018-July/...) and Gentoo (https://wiki.gentoo.org/wiki/Project:Infrastructure/Incident... and older, https://bugs.gentoo.org/show_bug.cgi?id=323691) have actual compromised packages? And also not five years ago, but Fedora (https://lists.fedoraproject.org/pipermail/announce/2011-Janu...) and Debian (https://www.debian.org/News/2003/20031202) had compromises but no known package changes.

Re: Grafana releases OnCall open source project

#130

Post by dijit »

morelisp wrote: post #128
dijit wrote: post #127

Earlier quoted context omitted.

generally I prefer humans in the loop, someone to actually test things. This is why distros are stable compared to other distros which are more bleeding edge.

For SC security, the fewer points of attack between me and the source the better. For other kinds of quality, I have my own tests which are much more relevant to my use cases than whatever the distro maintainers are doing. I've been a DD and while distros do work to integrate disparate upstreams as well as possible, they rarely reject packages for being fundamentally low quality or make significant quality judgements…

I have seen scenarios where package maintainers have rejected updating packages because the upstream is compromised though.
Post reply on HN