Report client status #45
Comments
|
We should also loop in @sorbaugh and/or a relevant engineer here. :) |
|
collect local problems: writing problems, disk full, critical upload/download errors? |
|
Android collects
@camilasan @allexzander @claucambra @mgallien for Desktop Can you also add your ideas what you want/can send in case of problems to server? |
|
Server creates table under user table such as user_upload_statistics, user_app_events and expects statistic data (e.g UploadResult, Events). Client sends UploadResult to server for related remote calls. Maybe even more when user navigate the media screen we can also send events to server (e.g Events.mediaScreenOpen) Therefore we can track faulty clients and optionally have a good overview about general app usage. This can be useful for some of our clients. @tobiasKaminsky @AndyScherzinger |
|
For privacy reasons we do not want to track/send successful operations, but only faulty states. |
|
@tobiasKaminsky please write the code error near you internal code string (every o.s. use a different system but the same error code) |
|
Is not clear: Send the error for single upload where counter > 1 ? (some errors occur for individual uploads others for each upload, so more information should be sent) or if need only an alarm every upload failure >= 1 time should be transmitted, and one successful upload is enough to cancel everything and transmit nothing (no loop, example disk full). |
|
Hm. For now I would say that we send each error category on its own, o.eg.: They then can be combined on server, if needed. |
|
can you write the errors number so all use the same ? |
|
I will come up with my ideas for desktop client later. For now, I think we must come up with a standardized way of collecting errors on the server, like have an SQL table with columns we must fill for every client app and also some kind of metadata column for platform-specific info. My idea is we need to have a list of error types(it can be long to include most common scenarios and we can add more error types later. Tobias already mentioned this. I would go even further and also include file full path or whatever unique id the file have such that file full path can later be obtained on the server. That way, we can later have some kind of view in the WebUI where we could sort errors by different columns (error type, timestamp with selection for specific time range, filename, folder type (group/normal/external storage), and also have repeating error type for the same file collected such that it is not displayed 1000 times (1000 rows for the same file for the same error) but instead is displayed as one row with a number of occurrences with the ability to open a detailed view with all 1000 rows when needed). For example, we have server logs that can be viewed in Web UI in that fashion. This is something I would target for. Then those errors can be exported in the form of a text file or CSV file or something. UPDATE: As I mentioned in my ideas in corresponding desktop client issue, we may also reduce spam and stop sending the same error for the same file in a given timeframe more then once by keeping track of these errors in the desktop client's local database, but in this case we might lose the ability to have detailed reports on the server. Also, as mentioned in the desktop client's issue ideas, I would consider sending a client log (only the current log file) to the server in case of sync errors, as client logs are being rotated constantly and important log might get lost which will prevent debugging. |
|
@allexzander can you add your categories/problem names here? |
|
DownloadError
UploadError
|
What we agreed on:
Brainstorm together how/what/when we can send status/health information from clients to server.
Scenario: company with IT department, that wants to have an overview over faulty clients
Already available to server:
What client could do
Server: nextcloud/server#40160
@AndyScherzinger @jancborchardt
The text was updated successfully, but these errors were encountered: