
Prometheus on Raspberry Pi - discordianfish
http://5pi.de/2015/02/10/prometheus-on-raspberry-pi/
======
laumars
_> "Cross-compiling this for Raspberry Pi is a pain. ARM != ARM, there are
several variants and when I tried to cross-compiling Prometheus with CGO, it
just lead to segfaults or invalid instructions."_

I'm pretty sure I had similar issues on the original model B and found I was
missing specifying which ARM version it was:

    
    
        export GOARCH="arm"
        export GOARM="5"
    

I don't know if the same is required for the Raspberry Pi 2 nor even which ARM
chipset version it is (the same I'm going to assume since Raspbian / Arch /
etc still run) but it might be worth checking you have your GOARM
environmental variable set

~~~
discordianfish
Just for completeness, my answer to the same Q on the blog: \---

his doesn't solve cross compilation CGO. For that, you need the gcc cross
compiler for the raspberry pi. I've tried to build it with CGO enabled like
this:

CC=arm-linux-gnueabihf-gcc GOARCH=arm CGO_ENABLED=1 go build
-ldflags="-extld=$CC"

But the binary still segfaulted on the raspberry pi. I also tried the cc from
[https://github.com/raspberrypi..](https://github.com/raspberrypi..). but with
the same result.

~~~
laumars
Ah ok. Shame.

Thanks for the update though :)

------
kbody
First time I heard about Prometheus (by Soundcloud). I wonder how it compares
to InfluxDB as a time-series DB (ignoring the monitoring things).

~~~
detaro
[https://news.ycombinator.com/item?id=8995696](https://news.ycombinator.com/item?id=8995696)

Previous discussion here, with both Prometheus and InfluxDB developers chiming
in.

Short version from memory: Prometheus is more efficient for datasets were
series have metadata, not so much individual points, since InfluxDB stores
metadata per point, but InfluxDB will optimize this case in the next version.

------
raindrop777
Can someone tell me why someone would want to write a database in
Go/Python/...? Or is Go just a wrapper in this case?

I am looking to store small time series data (only 100 points), but millions
of them. I currently use sqlite. Any other suggestions that I could use?

~~~
ethbro
I suppose for the same argument that can be made for single-language-but-
inefficient configuration systems.

When you're doing a basic process, reliability >> efficiency.

And sometimes more pieces in your stack just decrease reliability of the
entire system. (Admittedly! Rolling your own version of an already well-
implemented stack component is not without its peril as well)

------
rcarmo
I'm intrigued. I collect real-time machine performance data using a UDP
multicast daemon (written in C). It's fallible on some network topologies,
etc., but it's extremely light and efficient.

I wonder if that could be plugged in to Prometheus without the overhead of
HTTP collection...

~~~
bbrazil
HTTP collection doesn't really add a lot of overhead.

You might be interested in the
[https://github.com/prometheus/collectd_exporter](https://github.com/prometheus/collectd_exporter)
as collectd works in a similar way.

For machine monitoring [http://www.boxever.com/monitoring-your-machines-with-
prometh...](http://www.boxever.com/monitoring-your-machines-with-prometheus)
covers how to set it up with Prometheus - it's pretty easy to get working.

~~~
rcarmo
It does in the sense that an HTTP connection (either on the server or the
client side) will expend roughly 20 times the CPU and buffers than generating
or handling a single UDP packet. It all adds up on small systems.

~~~
bbrazil
You'd usually transfer many metrics in a single HTTP request, so the cost is
amortized in most cases.

~~~
rcarmo
I can pack a lot on a UDP packet as well...

~~~
jrv
Not sure if this is what you're comparing it to, but be aware that Prometheus'
approach is fundamentally different from StatsD-like approaches where you send
every event or a subsampling thereof to a monitoring server.

Prometheus is state-based, not event-based. It only stops by your monitored
instances once every couple of seconds and gathers their current state. E.g.
for counting events, clients simply expose cumulative counters over their
lifetime which they can increment locally in memory, and Prometheus comes by
for example every 15 or 30 seconds and stores the current counter state.

The HTTP traffic incurred in this case is not really a problem and you'll
usually run into bottlenecks at other places (like storage sample ingestion)
before you run into network transfer bottlenecks.

