Re: [tor-bugs] #13362 [Onionoo]: Make Onionoo's logs more useful

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

#13362: Make Onionoo's logs more useful
-----------------------------+----------------------------
     Reporter:  karsten      |      Owner:
         Type:  enhancement  |     Status:  needs_revision
     Priority:  normal       |  Milestone:
    Component:  Onionoo      |    Version:
   Resolution:               |   Keywords:
Actual Points:               |  Parent ID:
       Points:               |
-----------------------------+----------------------------

Comment (by karsten):

 Replying to [comment:6 iwakeh]:
 > task-13362 branch is ok to be merged.

 Great, merged.

 > I think we mostly agree on the logging.
 > Starting from your suggestions I also added what the logging document
 should mention for whom.
 > [...]

 Thanks for starting this!  Would you want to turn these ideas into a
 documentation patch that we can later merge?  I guess the ops part would
 go into INSTALL and the devs part into CONTRIB.md.  New ticket? :)

 Just one concern: we wouldn't want ops to edit logback.xml, right?  In
 theory, ops should be able to just take the jar and war and provide any
 configuration specifics as command-line arguments.  Or is that unrealistic
 as a goal?

 > As for the (future) production environment, you mentioned that the two
 ought to run under different users anyway. So, they should already have
 separate logs?

 Oh.  You're right, I forgot about that.  Should be fine to not provide
 anything at the command line and just log to the current directory by
 default then.

 > >  ... What we might want to do instead is define thresholds for certain
 operations, like reading descriptors of a certain time, and emit a warning
 if that operation takes longer than that.
 >
 > Maybe, these warnings/errors are only relevant for development and
 performance tuning?  Can an operator do something about these warnings?
 Or, do you want these to be reported as a track issue?

 What's a track issue?  I was thinking of pretty high thresholds here,
 which would make the service almost unusable.  There are two important
 time constants: every hour a new cronjob starts, and after six hours the
 front-end considers the back-end data as stale.  If a back-end execution
 takes longer than one hour, that's worth a warning, and if it takes longer
 than a couple of hours, that's worth shouting at the operator to check
 things and possibly inform the developers.

 Anyway, we can discuss this later and just include the statistics log
 lines in the debug/info log for now.  New ticket?

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