Create Debug & Problem Reporting Functionality

[neilt]

Description

This discussion is about improving LSMB functionality by allowing users to easily send statistics, bug reports, logs, etc. from a production LSMB instance back to the developers in a standardized form.

Suggested Usage Requirements

1. Any data sent to the LSMB developers must be opt-in or one-time initiated by an LSMB installation super-user or regular user with a newly defined "debug" role. The purpose is to limit the data received by LSMB developers to only relevant information sent by the person in charge of the installation. There will be NO automatic "phone home" functionality.
2. Any data sent to the LSMB developers must be fully visible to and editable by the user. It must be sent in a plain text email to a non-public LSMB email address. It would be nice if this text was in JSON format, but that might confuse the user. Maybe there is another format that is not so confusing but still allows automated receipt and processing by the LSMB developers.
3. No personally identifiable information will be included other than the submitters email address. The submitters email address does not have to be known to the LSMB developers. For example, the email address could be a free email created for only this purpose ([email protected]).
4. To initiate the debug email, the authorized user would click a button and the required information would be gathered into an editable text report. The user can then edit the report to remove any information they deem "not appropriate", then click the send key.
5. It might be valuable to have selectors for Bug Report, Usage Report, or both and customize the data sent accordingly.

Suggested Data Requirements

1. Unique Installations. During the LSMB installation or upgrade process an LSMB instance UUID will be created. This UUID will be included in all emails. This allows the developers to anonymously track which installation are submitting reports.
2. Usage Patterns. With limited resources the LSMB developers would like to know which functionality is most used and which is not used at all. Spending resources for unused functionality is wasteful. To accomplish this a new local database table would be created to track the timestamp of each menu item (UI Endpoint) when used. UI pass along data would NOT be tracked. This data would be tracked in the database, by default, for 13 months then auto deleted. This tracking range would be settable in the LSMB configuration. The sent data would include every UI endpoint used with the monthly average usage count.
3. System Data. The system data as currently shown in setup.pl-> system info would be included, plus the host system info. For example, uname -a or something similar. Generally, this includes LSMB version information, check consistency results, host information, and row counts for important tables. This it the data that will aid troubleshooting.
4. Problem Description. Allow the user to optionally describe a problem.
5. Logs. Include database, web server, docker, and application logs truncated by default, to the last 50 lines. Limit settable in the LSMB configuration.
6. Screen grabs. Screen grabs can be manually added by the user.

Future Enhancements

1. If the user is authorized, put the debug button on each view. Then when clicked automatically do a screen grab to be included in the sent data.

Implementation Thoughts

1. Build the table and tracking for Usage Patters early. This data collection can be started even if the "click to send" functionality is missing.
2. It is important to not slow down the UI so the Usage Pattern tracking should not wait for the database. UI responsiveness is more important than lost data.