4 ms·

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 fo

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 https://github.com/andmarios/sensor_exporter

gophernaught 10y ago
Funny coincidence, yesterday I did almost the same thing, though mine's based on lm-sensors and hddtemp: https://github.com/ncabatoff/sensor-exporter https://github.com/ncabatoff/sensor-exporter
- andmarios 10y ago
  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.
  - gophernaught 10y ago
    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.
  - grobie 10y ago
    You can disable the default metrics by using the uninstrumented handler https://godoc.org/github.com/prometheus/client_golang/prometheus#UninstrumentedHandler 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.
rektide 10y ago
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 https://github.com/rektide/node_exporter/tree/export-battery Almost went with a standalone Node exporter, but I decided I'd try some Go, and tour some of the Prometheus codebase. MustNewConstMetric is a very confusing thing to me, but hopefully I'm on the right track! Feeling double-inspired to get my homelab Prometheus up and going right now, between renewed excitement for these exporters and the 1.0! So close!
- jrv 10y ago
  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.
  - jrv 10y ago
    Ah sorry, he is "brian-brazil" on GitHub.

gophernaught 10y ago

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

andmarios 10y ago
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.
- gophernaught 10y ago
  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.
- grobie 10y ago
  You can disable the default metrics by using the uninstrumented handler https://godoc.org/github.com/prometheus/client_golang/prometheus#UninstrumentedHandler 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.

rektide 10y ago

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 https://github.com/rektide/node_exporter/tree/export-battery Almost went with a standalone Node exporter, but I decided I'd try some Go, and tour some of the Prometheus codebase. MustNewConstMetric is a very confusing thing to me, but hopefully I'm on the right track! Feeling double-inspired to get my homelab Prometheus up and going right now, between renewed excitement for these exporters and the 1.0! So close!

jrv 10y ago
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.
- jrv 10y ago
  Ah sorry, he is "brian-brazil" on GitHub.