[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
moniTor -- a console-based monitoring tool for Tor relays
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi all,
as discussed yesterday with ioerror on #tor, these are my first thoughts
on a console-based monitoring tool for Tor relays. They are the result
of a spontaneous brainstorming session today, so there might be a lot
more possibilities and some ideas will probably turn out to be either
useless or unimplementable.
The purpose of moniTor (working title only) is to monitor a local Tor
relay via its control port and include useful system information of the
underlying machine. When running this tool, it dynamically updates its
content like top does for Linux processes. moniTor is meant to run in a
console without the need for a graphical interface. For the sake of
simplicity, users won't be able to provide any input after starting
moniTor. The primary application will be for admins who have recently
set up their Tor relay and want to check if everything looks fine or to
look in every now and then to look if the relay is still operating.
The tool is not designed to be used with Tor clients, but only with
relays; therefore it does not contain useful client information. It will
also not change any configuration of Tor or send any signals to it, but
only monitor what's going on. The tool is neither meant to record and
present historical data; it is only running when explicitly started by
the user, not as a daemon process. Further, there will be no
notifications created by this tool and sent to the user, e.g. via
e-mail. Although these might be useful features, too, they will not be
covered by this tool.
The user interface will contain three areas: (1) static info area, (2)
dynamic info are, and (3) event/log area:
(1) The static info area will contain information that does not change
while running Tor. Examples are the Tor version, location of Tor's
config file, IP address, a short summary of the exit policy (any exit
connection allowed or none at all), OR and Dir port configuration, the
node's nickname and fingerprint, etc. The implementation would use
GETINFO and GETCONF to find out these values. Although all static info
would also be available elsewhere, it might be a nice confirmation for
(unexperienced) Tor admins that their specified configurations are in use.
(2) The dynamic info area will contain steadily (once per second?)
updated fields for Tor-related and system-wide information:
- - System resource usage of Tor process: What share of CPU time and
memory is Tor using as compared to the rest of the system (other
processes, idle CPU/free space)? In an implementation this would
probably require calls to the underlying system, rather than requests to
Tor's control port.
- - Connections: How many open connections are there at the moment? This
could be split up into the number of connections to the OR port, to the
Dir port, etc.
- - Bandwidth: What does Tor report about the used bandwidth? This could
be presented and updated for the current second, but also as averages
for the last 60 seconds. Again, this does not include any history
exceeding the time of running the tool.
(3) The event/log area contains a comprehensive view on the last N
events. N would probably best be determined by the remaining display
space in a console. Useful events might be log statements on WARN and
ERR level (this level could be changed with a command-line argument to
moniTor), DESCCHANGED, and STATUS_SERVER. Every event would be condensed
to a single line by leaving out less important data like the current
date (only display time) and truncate descriptions after a certain
length. In addition, the complete events are written to a local file to
enable reconstruction of errors later on.
A typical output of moniTor could look like this (with some fake data
for the purpose of this example):
~ Name/ID: gabelmoo 6833 3D07 61BC F397 A587 A0C0 B963 E4A9 E99E C4D3
~ Version: 0.2.0.15-alpha-dev (r13077) on Linux x86_64
~ Config: /home/tor/gabelmoo/torrc, Exit policy: no exit allowed
~ IP address: 88.198.7.215, OR port: 443, Dir port: 80
~ CPU: 9.0% this tor, 3.4% other processes, 87.6% idle
~ Mem: 49.9% this tor, 2.0% other processes, 48.1% free
~ Connections: 1090 OR conns, 320 Dir conns
~ Bandwidth: 1.2 MB/s current, 1.3 MB/s avg
~ Recent events (see also /home/tor/gabelmoo/monitor.log):
~ 14:30:01 [warn] Consensus does not include configured authority 'moria
~ 14:30:01 [warn] Consensus does not include configured authority 'ides'
~ 14:30:01 [warn] 0 unknown, 0 missing key, 2 good, 0 bad, 1 no signatur
~ 14:30:01 [warn] Not enough info to publish pending consensus
These are my first ideas. Please feel free to add comments! Plus, if
there is already a tool with similar purpose that could be
used/extended, please let me and ioerror know!
- --Karsten
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHhNOT0M+WPffBEmURAsWcAJ92bm9gQdi4i3KNzGR3llmH++rBOgCeNC5v
y/Y2+9xvZYz5voyE3T0wAxo=
=2yka
-----END PGP SIGNATURE-----