Re: [tor-bugs] #13802 [Tor]: Add instrumentation to tor (was: Add LTTng instrumentation to tor)

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

#13802: Add instrumentation to tor
--------------------------+------------------------------------------------
     Reporter:  dgoulet   |      Owner:
         Type:            |     Status:  assigned
  enhancement             |  Milestone:  Tor: 0.2.7.x-final
     Priority:  normal    |    Version:
    Component:  Tor       |   Keywords:  SponsorR, 027-triaged-1-deferrable
   Resolution:            |  Parent ID:  #13792
Actual Points:            |
       Points:            |
--------------------------+------------------------------------------------
Changes (by dgoulet):

 * cc: rob.g.jansen@â (removed)
 * cc: robgjansen (added)


Old description:

> Relevant to #13792, we (nickm and I) discussed what would be the way to
> collect and gather those statistics and measurements in a private network
> for performance analysis and debugging.
>
> Using LTTng (https://lttng.org) to gather events of the different
> subsystems of tor (in userspace of course) seems like a good solution.
> This would be completely deactivated at compile time meaning tracepoints
> would be NOP. You would have to explicitly enable that feature during the
> configure process.
>
> We think the best way to go with that, in terms of code, is to go in a
> header with something that could look like this:
>
> {{{
> #ifdef TOR_USE_LTTNG
> tracepoint_aname(arg1, arg2, [...]) tracepoint(aname, arg1, arg2, ...)
> #else
> tracepoint_aname(arg1, arg2, [...])
> #endif
> }}}
>
> The really good thing about this approach is that 1) everything is
> centralized in one place, 2) you NOP the call if not configured thus no
> performance issue, 3) We can support other tool like DTrace or SystemTap
> and possibly Windows tools. It provides a simple way to hook any other
> tool in the trace event facility of the code.

New description:

 Relevant to #13792, we (nickm and I) discussed what would be the way to
 collect and gather those statistics and measurements in a private network
 for performance analysis and debugging.

 This would be completely deactivated at compile time meaning tracepoints
 would be NOP. You would have to explicitly enable that feature during the
 configure process.

 We think the best way to go with that, in terms of code, is to go in a
 header with something that could look like this:

 {{{
 #ifdef TOR_USE_LTTNG
 tracepoint_aname(arg1, arg2, [...]) tracepoint(aname, arg1, arg2, ...)
 #else
 tracepoint_aname(arg1, arg2, [...])
 #endif
 }}}

 The really good thing about this approach is that 1) everything is
 centralized in one place, 2) you NOP the call if not configured thus no
 performance issue, 3) We can support lots of different tracers as well as
 shadow. It provides a simple way to hook any other tool in the trace event
 facility of the code.

--

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/13802#comment:9>
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