System Monitoring

Yes, I am running dump1090-mutability v1.14.
…Tom

Very happy thank you all, you guys rock…

Here’s my first few hours of data…
…Tom

Thanks, Caius. That’s good to know. My make-graphs.sh was modified by xforce30164 to run with the version of rrdtool on Raspbian.

Beautiful. Glad I could help.

I’m just the messenger. All credit goes to obj, xforce30164 and caius - the brains behind this project! :smiley:

Mine is working as well now. Had a bit of trouble getting the 1h and 6h to display, there were no PNG files. I managed to make them after I made make-graphs.sh executable and ran it with ./ at the start:

sudo chmod +x make-graphs.sh
sudo ./make-graphs.sh 1h
sudo ./make-graphs.sh 6h

I don’t know if that was the best way to do it, I’m new to this stuff. I tweaked the gain at 11.00 and there is already an improvement.

Thanks to jepolch for his help. :slight_smile:

http://i.imgur.com/acLbMFn.jpg

Great looking results! You’re right that you can create graphs manually any time on the command line, but the syntax is 1h or 6h (no “r”).


sudo make-graphs.sh 1h
sudo make-graphs.sh 6h

Take a look in /var/www/collectd and see if you have file names that include both “1h” and “1hr”. /var/www/collectd/index.html should be coded to display images with “1h”, etc., only.

Whenever I make a change to my system - swap an antenna, change the gain value in dump1090-mut, add/remove a filter - I always run a 1h graph manually so I see the results more quickly.

[quote=“jepolch”]

Not that I haven’t typed ‘make-graphs.sh 1hr’ a few times by mistake. :blush: “hr”, I think, is more intuitive, but “h” it is.

Somebody told me it was called “overlearning”. It’s the same thing that causes experienced typists to type “teh” every once in a while and has become quite famous on the internet.

First of all, thanks to all those who put these graphs together. I’ve been at this for just a few weeks, and have found a lot of great info here and at PF. I thought I’d post some modifications I made to the charts:

  • Added a combined CPU utilization and temp graph
  • Added a bandwidth graph
  • Added a memory graph
  • Added a disk space graph
  • Added average and max lines to the range graph
  • Modified script to only display the moving average graph on the 24h page
  • Changed the sizes to line things up

I’ve zipped up my collectd.conf, make-graphs.sh, and index.html, so here is a link to that:
dl.dropboxusercontent.com/u/896372/graphs.zip

Here are some screenshots:
http://i.imgur.com/EScY6bU.png

http://i.imgur.com/tFiH1pB.png

Very impressive! Thanks for sharing your scripts. I’ll definitely be taking a look at them later today when I get back home.

Edit: What OS are you running?

This is on PiAware/Debian wheezy (on a Pi 2).

Interesting. I looked at your make-graphs.sh and when some of us on PlaneFinder tried that we got errors from the MINNAN, MAXNAN definition. Specifically the NAN part. Once that was removed it worked.

Yes, I forgot to add that I am running rrdtool 1.5.3, which I compiled from source. Even the newest Debian distros have a really old version of rrdtool, for some reason. I think the NaN operators started working in 1.4.9.

Got this great tool running tonight! Thanks for all the efforts of everyone involved (here and at PF)!

Used a slightly different setup: Since my Pi running dump1090 is quite busy decoding, all monitoring related processes (collectd, dump1090.py, rrdtool and lighttpd) run on a second Pi. So data is not from localhost but from dump1090 IP.
collectd.conf needed to be changed (replace with the IP address of the box running dump1090-mutability v.1.14



....
Hostname "<dump1090 IP>"
...
<Plugin python>
        ModulePath "/home/pi/dump-tools/collectd"
        LogTraces true
        Import "dump1090"
        <Module dump1090>
                <Instance rpi>
                        URL "http://<dump1090 IP>/dump1090"
                </Instance>
        </Module>
</Plugin>


and at the bottom of make-graphs.sh:


receiver_graphs "<dump1090 IP>" rpi "RPi ADS-B" "$period" "$step"


EDIT: Don’t use this way. use network plugin instead
/paul

An alternative to doing that is to run collectd with the network plugin on two machines - configure the pi running dump1090 to send its data to the other machine instead of writing out to rrd. That way you can also collect other system data not included in the dump1090 stats such as disk/network usage. Collectd doesn’t use much in the way of resources to gather the data, but writing it out and generating graphs can be quite intensive.

Just installed and it’s working. Thanks for posting this.

Thanks for pointing. From the collectd wiki this looks like an easy job and way better solution. Might even add monitoring some other devices at home! This collectd newbie will try that tonight. :mrgreen:

EDIT: Got it working!

dump1090 Pi:

  • install collectd
  • edit collectd.conf
    remove

LoadPlugin rrdtool
<Plugin rrdtool>
        DataDir "/var/lib/collectd/rrd"
</Plugin>


add: (with x.x.x.x the IP address of the PI which does the graphing)


#Start collectd network client
LoadPlugin "network"
<Plugin "network">
        Server "x.x.x.x"   
</Plugin>


Graphing PI:

  • Install everything (collectd, rrdtool, make-graph, crontab)
  • Edit collectd.conf
    remove

# Ensure that the base Python plugin is loaded:
<LoadPlugin python>
        Globals true
</LoadPlugin>

..and...

# Configure the dump1090 python module.
# Each Instance block collects statistics from a separate named dump1090.
# The URL should be the base URL of the webmap, i.e. in the examples below,
# statistics will be loaded from http://localhost/dump1090/data/stats.json etc.

<Plugin python>
        ModulePath "/home/pi/dump-tools/collectd"
        LogTraces true
        Import "dump1090"
        <Module dump1090>
                <Instance rpi>
                        URL "http://localhost/dump1090"
                </Instance>
        </Module>
</Plugin>

LoadPlugin "table"
<Plugin table>
  <Table "/sys/class/thermal/thermal_zone0/temp">
    Instance rpi
    Separator " "
    <Result>
      Type gauge
      InstancePrefix "cpu_temp"
      ValuesFrom 0
    </Result>
  </Table>
</Plugin>


...but be sure to leave this: (took me a while to figure that out)

# Load the dump1090 types and the regular types just to be sure:
TypesDB "/home/pi/dump-tools/collectd/dump1090.db" "/usr/share/collectd/types.db"


and add with the same IP address as used above



LoadPlugin "network"
<Plugin "network">
        Listen "x.x.x.x"
</Plugin>


restart collectd.conf on both Pi’s

Data traffic is just a single UDP data packet per minute.
If it doesn’t seem to be working you can verify the dataflow at either end by installing tcpdump

sudo apt-get install tcpdump

and monitor the traffic (wait patiently for at least one minute)

sudo tcpdump -i eth0 -p -n -s 1500 -Avv ‘udp port 25826’

or if you’re on wifi:

sudo tcpdump -i wlan0 -p -n -s 1500 -Avv ‘udp port 25826’

Enjoy!
/paul

OK, since I got collectd up and running I’ve been testing different antennas and other settings. Today, May 26th at about 1700, I swapped in an antenna. I knew from previous testing that the antenna worked very well for long range. But what I don’t understand is the TRACKS graph. Can someone explain what this stat is and why it fell when Message Rate, Aircraft Seen and Range all rose at the same time.

Much thanks in advance, Tom

The tracks statistic is the number of unique aircraft tracks seen over time. That is, dump1090 increases a counter whenever it sees a message from an aircraft that it is not currently tracking. Some time later after no messages are heard for a while it will stop tracking it. The graph shows the rate at which that counter is increasing.

The red part is the number of tracks where, when dump1090 stopped tracking it, there had only been 1 message seen in total. Those tracks are usually bad data producing a phantom aircraft; dump1090 already filters them by only forwarding data after 2 messages have been seen. You should usually ignore the red area (might be useful to subtract it out entirely in the graphs)

Your new antenna looks less noisy so you’re seeing fewer phantom tracks. It still looks like there is a drop in the green area (“good” tracks). Possibly what’s happening is that your old antenna coverage would consistently lose aircraft in some area then reacquire them later - which would end up counting as two tracks. But with better coverage it wouldn’t lose the aircraft and would only count it as one track.