Hi!
I finally deployed Munin across our exit nodes. The graphs are currently public, and I don't see an obvious reason for not doing that. Any objections?
https://www.torservers.net/munin/
On Tue, 29 Jan 2013 16:54:58 +0100 Moritz Bartl moritz@torservers.net wrote:
I finally deployed Munin across our exit nodes. The graphs are currently public, and I don't see an obvious reason for not doing that. Any objections?
For what it's worth, we do this too, https://munin.torproject.org. Right now it has a tor-guest account on it to avoid cgi exploits, but otherwise it has been fine for the past few years.
If someone does exploit a cgi script, they'll get an empty webserver with copies of munin data. Not the end of the world for us.
Thanks for putting that up Moritz. Others can learn what it takes to run busy exit relays.
Moritz Bartl moritz@torservers.net wrote Tue, 29 Jan 2013 16:54:58 +0100:
| I finally deployed Munin across our exit nodes. The graphs are currently | public, and I don't see an obvious reason for not doing that. Any | objections? | | https://www.torservers.net/munin/
Thanks, that's interesting data.
FWIW, DFRI publish 5 minute average stats per site, for sites where we have exit relays [0][1]. There is a one hour delay in publishing the data. We might switch to per-relay data when our sites with Tor in them push more than 0.1% non Tor traffic or so.
On a side note, comparing our graphs with Torservers.net's made us wonder why our relays don't max out at the same time while Torserver.net's apparently do that. Or are we reading the graphs in the wrong way? It looks like the 10 graphs in https://www.torservers.net/munin/torservers.net/aggregates/index.html follow each other very closely while the DFRI graphs show, f.ex., max traffic yesterday in sto0 between 19:00 and 21:30 (CET) but 12:30 to 22:30 (CET) in sto2.
It might of course be the case that one or more of our relays have trouble keeping up with the pace. Some of them do complain about not keeping up and others about both failing DNS servers and "Address mismatch on received DNS packet" (eventdns). Log printouts don't seem to correlate with changes in the graphs though so I doubt that this is the reason.
[0] https://dfri.se/__trafstats__/em1.100.html [1] https://dfri.se/__trafstats__/em1.3021.html
tor-relays@lists.torproject.org
-
Andrew Lewman -
Linus Nordberg -
Moritz Bartl