[LAS-440] Refactor Logging / Monitoring Created: 18/Apr/18  Updated: 08/May/18  Resolved: 08/May/18

Status: Closed
Project: las2peer
Component/s: Core, las2peer Monitoring
Affects Version/s: v0.7.3
Fix Version/s: v0.7.4, v0.8.0

Type: Improvement Priority: Critical
Reporter: Peter de Lange Assignee: Jan Benscheid
Resolution: Fixed Votes: 0
Labels: las2peer
Σ Remaining Estimate: 1 day, 30 minutes Remaining Estimate: Not Specified
Σ Time Spent: 1 hour Time Spent: Not Specified
Σ Original Estimate: 1 day, 1 hour, 30 minutes Original Estimate: Not Specified

Attachments: PNG File image-2018-04-26-10-28-05-620.png    
LAS-443 Suggest usage of new logging in Docum... Sub-task Closed Jan Benscheid  
LAS-444 Log levels for monitoring observer Sub-task Closed Jan Benscheid  
LAS-445 "Trivial logging" API for the monitoring Sub-task Closed Jan Benscheid  
Fix Release Date: 8/May/18


Currently, the new las2peer logger enforces a "use local file-based logging only" approach. This is not good. Logging should be refactored to notify the monitoring as default.

Also the duplicate timestamps and the logging class entry itself could be removed from the files, since they take up a considerable amount of space without adding any information.

Also, service custom messages should maybe be put into a separate local file (additionally to them being also sent to the monitoring node) to allow service developers to quickly check their messages while developing a success model for their service.


All in all, we should put some effort in improving monitoring and logging, and then write a short article about this in our wiki.

Comment by Peter de Lange [ 18/Apr/18 ]

One additional improvement is that service method calls should be logged in general. Currently, this is only done implicit by logging RMI / Service Method invocations.

Comment by Jan Benscheid [ 26/Apr/18 ]

How do would you like this? Pretty similar to what "the big ones" are doing.

Comment by Peter de Lange [ 26/Apr/18 ]

Well it's definitely not bad. But can you do it without breaking the interface? We need to think for backwards compatibility. Or at least have the consequences of interface changes written down before we start implementing something. Could you elaborate a bit more?

Comment by Peter de Lange [ 26/Apr/18 ]

Oh and..we need the name "mobsos" in it. So let's call the monitoring transport "mobsosTransport".

Comment by Jan Benscheid [ 02/May/18 ]

It turned out, that L2pLogger using only the local file was deliberately not meant to send data to MobSOS. The monitoring API wshould be used for that purpose. I'll therefore extend it to be used for a broader logging use case and adjust the documentation accordingly.

Comment by Jan Benscheid [ 03/May/18 ]

"Also, service custom messages should maybe be put into a separate local file"

Any local logging of custom messages could become a privacy breach, as those messages usually contain user data. For production purposes, it should probably be disabled by default.

Comment by Jan Benscheid [ 08/May/18 ]

Remaining: Log levels for monitoring messages. (Temporarily fixed via workaround)

Generated at Mon Oct 14 09:11:53 CEST 2019 using JIRA 7.8.0#78000-sha1:4568b9d484113d74dfb6f152fb925b5fa1be2ef7.