Slicer logging architecture and flexibility

Hi, in our commercial project we are finding that default Slicer logging is pretty difficult for our users. Our app-specific logs like “Procedure initiated…” get lost amongst all the internal logging. Users struggle to inspect logs which means we have to get them to send us copies, etc, and anyway this sort of logging is normally something users wouldn’t see.

Does Slicer logging architecture strongly couple Slicer to using a single log for everything, or are you using a logger (perhaps a common OSS one) that allows multiple log files to be used in parallel, so we can send different categories of messages to different files?

(I should add our users are doctors, not DICOM experts and definitely not typical Slicer users or software developers at all)

single log for everything, or are you using a logger

A single log file is highly desirable, as it makes most important operations such as rotation (needed for keeping used disk space under control), merging (necessary for analysis), and sharing (for error reporting) much easier.

Intended use:

For developers: Usually viewing with a simple text editor works well, but since log files are structured they can be loaded into a log viewer application, such as Apache Chainsaw, for searching, tagging, and advanced filtering.

For users: It should not be necessary for users to check the application logs. Maybe there are a few places where we wanted to save some software development time, we did not implement propagation of error messages to the user and just display a message like “… error occurred - see logs for details”. For these cases, uses can open the Log window, which displays a simplified, somewhat user-friendly view of events. Events are grouped by timestamp and can be filtered based on log level. Details, such as source code file names and line numbers are not displayed.

Potential improvements:

  • More consistent logging of all user actions and better use of categories or tags - this would help in identifying what a user did exactly and make the logs more useful in general.
  • We can also improve the log viewer window to show more or less information, allow searching, or more advanced filtering.
  • We could also add a “share to web” feature, which could pack up log file and maybe a screenshot and send log to a web service, but there would be a risk of unintentional leaking patient information.
  • Automatic crash reporting (on next startup) might be useful, too (because people may not realize that they have access to logs of previous application sessions). However, crashes happen so rarely that the benefits would be limited.

Overall, I don’t see any serious issues or low-hanging fruits that we should work on, but let us know if you have specific ideas or recommendations.