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

Prometheus reaches 1.0

prometheus.io

Post reply on HN
Print view View original

51–60 of 60 posts

Re: Prometheus reaches 1.0

#51

Post by jrv »

rektide wrote: post #48
andmarios wrote: post #11

Congrats! Prometheus + grafana are a killer duet! Easy to setup and use. Same goes for node_exporter. I only wish more JVM apps included a configuration file for the jmx_exporter and an easier to setup nginx_exporter. :) Incidentally yesterday I created a simple exporter for (linux) coretemp, hddtemp and NUT's upsc: https://github.com/andmarios/sensor_exporter

I really hope upstream node_exporter is happy adding new exports! Still slowly hacking on my homelab Prometheus bringup, but I've already got a start developing a battery level/power supply exporter. By far the most important Node information I want metrics and alarms on in my developer life! https://github.com/rektide/node_exporter/tree/export-battery Almost went with a standalone Node exporter, but I decided I'd tr…

If the interface you're getting the metrics from is generic and standardized enough to work on most Linux systems, it has a good chance of making it in. "/sys/class/power_supply/..." probably fits that requirement, but bbrazil (same name on GitHub) would be the best to give a final judgement on that kind of thing.

Re: Prometheus reaches 1.0

#52

Post by woodcut »

We've been using Prometheus in production for a while now and found it to be rock solid, it's never an issue, never requires much of an after thought other than extending the current use of it. All of which says a lot. Our only "feature request" is that it stays stable and the project doesn't lose focus. Cheers!

Re: Prometheus reaches 1.0

#53

Post by jrv »

vegabook wrote: post #49
jrv wrote: post #2

Prometheus cofounder here - we're happy to take any questions. Huge congrats to everyone who made this release possible and for all the excellent work over the years that lead up to this!

Could you elaborate on what seems to be your focus on logging only. Would Prometheus be relevant, for say, high frequency financial markets data? I note that Prometheus "has knowledge about what the world should look like" and "actively tries to find faults" [1]. Isn't this something which is applicable to other fields than simply monitoring? I spend a lot of my time watching and managing "bad data" coming through in…

Our focus is not logging only, it's the opposite: we don't support storing logs of individual events. What Prometheus does is store dimensional numerical time series. See the data model: https://prometheus.io/docs/concepts/data_model/

So it's a question of whether you can squeeze your data into that model and whether you need per-event details or whether aggregated time series are ok.

Re: Prometheus reaches 1.0

#56

Post by gophernaught »

andmarios wrote: post #35
gophernaught wrote: post #32

Earlier quoted context omitted.

Funny coincidence, yesterday I did almost the same thing, though mine's based on lm-sensors and hddtemp: https://github.com/ncabatoff/sensor-exporter

Nice! I didn't knew about gosensors library. I started with the same path, using github.com/prometheus/client_golang/prometheus, but it exported too many application metrics (an order of magnitude more than the sensors I exported :p), so I went to a more custom approach.

Metrics are pretty cheap, unless you have a ton of exporters I wouldn't worry too much about that. Plus it can come in handy: the ZFS exporter I wrote uses a CGO library that had a memory leak, which I discovered thanks to those app metrics. And they made it easy to infer that the leak was in the C heap rather than in Go.

Re: Prometheus reaches 1.0

#57

Post by grobie »

andmarios wrote: post #35
gophernaught wrote: post #32

Earlier quoted context omitted.

Funny coincidence, yesterday I did almost the same thing, though mine's based on lm-sensors and hddtemp: https://github.com/ncabatoff/sensor-exporter

Nice! I didn't knew about gosensors library. I started with the same path, using github.com/prometheus/client_golang/prometheus, but it exported too many application metrics (an order of magnitude more than the sensors I exported :p), so I went to a more custom approach.

You can disable the default metrics by using the uninstrumented handler https://godoc.org/github.com/prometheus/client_golang/promet...

It's a best practice to export all available metrics though, you'll likely run into situations where you'll need them. It's not that many time series exported by default which shouldn't cause any problems.

Re: Prometheus reaches 1.0

#58

Post by otterley »

daniel_levine wrote: post #5

Is there a company offering a SaaS version of Prometheus?

Datadog and SignalFX are both far more scalable, easier to use, and have more features than Prometheus and are SaaS offerings. Prometheus is about 5 years behind them in terms of engineering effort, I believe.

Re: Prometheus reaches 1.0

#59

Post by jrv »

jrv wrote: post #51
rektide wrote: post #48

Earlier quoted context omitted.

I really hope upstream node_exporter is happy adding new exports! Still slowly hacking on my homelab Prometheus bringup, but I've already got a start developing a battery level/power supply exporter. By far the most important Node information I want metrics and alarms on in my developer life! https://github.com/rektide/node_exporter/tree/export-battery Almost went with a standalone Node exporter, but I decided I'd tr…

If the interface you're getting the metrics from is generic and standardized enough to work on most Linux systems, it has a good chance of making it in. "/sys/class/power_supply/..." probably fits that requirement, but bbrazil (same name on GitHub) would be the best to give a final judgement on that kind of thing.

Ah sorry, he is "brian-brazil" on GitHub.

Re: Prometheus reaches 1.0

#60

Post by atombender »

jrv wrote: post #2

Prometheus cofounder here - we're happy to take any questions. Huge congrats to everyone who made this release possible and for all the excellent work over the years that lead up to this!

Any plans on more native support for Kubernetes? The relabeling spaghetti config you end up with is very confusing and unreadable.

Granted, you don't need to touch this confirmation very often, but anyone who's going to operate the cluster will need to understand it thoroughly.

The fact that it's ad-hoc (prometheus.io/probe etc. aren't built in) means everyone's config is probably going to be unique and not portable. For example, we found the current config example to be insufficient, since blackbox-exporter needs information about whether its endpoint is HTTP or HTTPS.

Kubernetes' template system, combined with variable expansion, seems like it would be a better model for what you're currently trying to do with service discovery.

Also: I'm setting this up right now, but it seems there's no exporter for the Kubernetes API proper, just Kubelet?

Post reply on HN