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

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#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 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.)

 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.

 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.

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/7359#comment:5>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs