[tor-bugs] #7359 [Tor]: Design/implement method for collecting/reporting statistics

Tor Bug Tracker & Wiki blackhole at torproject.org
Tue Nov 20 19:06:19 UTC 2012


#7359: Design/implement method for collecting/reporting statistics
------------------------------------------------------------------------+---
 Reporter:  robgjansen                                                  |          Owner:                  
     Type:  enhancement                                                 |         Status:  new             
 Priority:  normal                                                      |      Milestone:  Tor: unspecified
Component:  Tor                                                         |        Version:                  
 Keywords:  performance, simulation, statistics, tor-relay, tor-client  |         Parent:  #7357           
   Points:                                                              |   Actualpoints:                  
------------------------------------------------------------------------+---

Comment(by robgjansen):

 Replying to [comment:5 karsten]:
 > Replying to [comment:2 robgjansen]:
 > > Should we be taking the approach of sending events to the ControlPort
 and letting an external process turn them into statistics for anything
 that we're not sending up to daddy? Or are we OK with doing the stats
 inside of Tor itself. I'm personally in favor of the latter as it
 minimizes effort required to get useful stats and requires less
 duplication of code in the long run.
 >
 > Letting Tor do it sounds convenient, but only up to the point where we
 want to change something.  Turning observations into statistics may depend
 on what we want to do with the statistics.  If we change our mind there,
 we'll have to fix that in Tor.  It's probably quite inconvenient for
 simulations if older Tor versions report different statistics than newer
 versions.  I'd rather favor a variant where control port events contain
 the raw data and where it's up to the application, here Shadow, how to
 aggregate these data points to get something useful.  I bet there's good
 support for processing control port events in stem that we can use here.
 (That's just my 2 cents.)
 >

 I've thought about this and reviewed the Tor controller spec. I agree.
 Thanks for your insight!

 > In general, having a common stats module that either prepares control
 port events, or aggregates data for being sent to the directory
 authorities, or both, makes sense.  This is a major refactoring effort, so
 I'd be careful mixing that with adding new stats.
 >

 Yeah, good point. I'll focus on minimizing changes and only adding the
 desired event types to collect the new stats.

 > In #7358, I asked you for which statistics you were planning to emit
 asynchronous control port events whenever there's a change, or to emit
 events periodically.  You asked me to move that question here.  So, for
 example, the CIRC, STREAM, ORCONN, BUILDTIMEOUT_SET, and CIRC_MINOR events
 (Sections 4.1.1, .2, .3, .16, and .19) are emitted whenever there's a
 change, whereas BW and STREAM_BW (Sections 4.1.4 and .13) are emitted
 every second.  In fact, the mentioned events already cover some of the
 statistics you were looking for.  We'll probably want to design the
 remaining control port events similar to these.

 I see. More soon on this...

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/7359#comment:6>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online


More information about the tor-bugs mailing list