Opened 3 years ago

Last modified 3 years ago

#2162 open enhancement

Add service-specific logging options to tunnel manager

Reported by: Reportage Owned by:
Priority: minor Milestone: undecided
Component: apps/i2ptunnel Version: 0.9.33
Keywords: tunnelmanager, logging, usabilty, UX Cc:
Parent Tickets: Sensitive: no


Currently, to add a logging option to the logs, /configlogging is the place to go. For the experienced user, this shouldn't present much of a barrier, although the huge dropdown makes identifying the specific logging option required less than optimal. Not particularly user-friendly, though a useful service nonetheless in aggregating all possible logging options in one place.

For easier targetted logging of a specific service that may be causing problems, or which the user may be interested in learning more information (eg. webserver access), adding only the logging options unique to the service in question on the tunnel manager edit page would ease the pain of choosing logging options. Dropdowns as per /configlogging for service subset + category.

Small considerations such as this lower the barrier for new users, and provide time-saving features for all users.


Change History (2)

comment:1 Changed 3 years ago by zzz

Status: newopen

That's not usually the way these things go. If somebody is having trouble, and either files a ticket or inquires on IRC, we'll look at the log evidence as filed or pasted somewhere.

If the logs are insufficient, a developer would research what log classes and levels would be necessary to get the additional information required.

Enabling some broad set of classes for logging, without being a developer or knowing what you're looking for, will useless, as there's far too much output.

Any log output that's not at the ERROR level (or logged regardless of level with logAlways()) isn't intended for non-developers. It's almost impossible to know what you want without reviewing the source code first. And for non-developers, even the concepts of classes, packages, and subsystems may not be understood. OP's goal to make these facilities and concepts useful for "new users and all users" may not be achievable. Some of this may be useful to be added to the new developers document http://i2p-projekt.i2p/en/get-involved/guides/new-developers or http://i2p-projekt.i2p/en/get-involved/guides/dev-guidelines

What has been on my list for years, is to write a document that provides an overview of the source code and its major subsystems, and possible entry points into doing experiments. Maybe logging would be a part of it.

So I'm inclined to close this wontfix for the reasons stated above, but will leave open for additional discussion for now.

comment:2 Changed 3 years ago by Reportage

Adding service specific logging options to the tunnel edit page, plus the option of generating logs that are specific to the service in question, on /logs and as a separate log file, could make logging more useful. Currently the log display on /logs truncates entries, which means for more verbose logging options details may get lost in the flood of data. Optional per-service logs on the logs page + separate files would make analysis of a given subsystem less onerous.

Note: See TracTickets for help on using tickets.