Enhance Tunnel Manager Message Log (followup to \#2107)
Opened 3 years ago
#2114newenhancement
Enhance Tunnel Manager Message Log (followup to #2107)
Reported by:ReportageOwned by: Priority: minor Milestone: undecided Component: apps/i2ptunnel Version: 0.9.32 Keywords: i2ptunnel, screenlog Cc:
Parent Tickets:
Sensitive: no
Description
Now that we have log persistence, is it worth considering logging additional tunnel-related events? If so, an option to log events to file might be considered. The following events might be considered for inclusion, and might make a case for inclusion of time stamps:
-
Tunnel failure: when a tunnel pool fails and needs to be rebuilt, a notification in the logs might be useful for troubleshooting etc
-
Tunnel creation on detection of activity when a server tunnel is configured to delay opening tunnels until connect
-
Tunnel pool reduction after period of inactivity
-
Tunnel pool close after period of inactivity
-
Throttling events for the http server tunnel - with the destination of the offending client
-
Attempts to access the http server tunnel that result in a block (inproxy/useragent/referrer) - with dest of offending client
-
Attempts to access an encrypted service without the correct key - with dest of offending client
The events appear from top to bottom, with the newest event at the bottom, when most console logs and snark logs have the latest events at the top. When an event is registered in the screenlog, the log scroll position is at the top, so perhaps it makes more sense to publish events to the log in reverse chronological order ie. the later events appearing before the earlier events?
References to tunnels and servers could be clearer, with server/client events referencing the tunnel name e.g. "Stopping tunnels for server at 127…" could be clearer with something like: "Stopping server tunnels for 'I2P Webserver' [127.0.0.1:4444]" etc. Some event logs are also unhelpful, specifically client tunnel references e.g. "Unable to build tunnels for the client, retrying in 20 seconds" which would also benefit from inclusion of the tunnel name. e.g. "Unable to build client tunnels for 'I2P HTTP Proxy', retrying..". References to "Standard Client" and "Client ready" would also benefit from more clarity.
Some log events appear to replicate information, and could be probably be streamlined/deduped? eg. "Tunnels ready for client: HTTP Proxy on 127.0.0.1:4444" and "Client ready, listening on 127.0.0.1:4444".