Operations Dashboard log
Assignee
Pavel SalamonReporter
Martin SlámaLabels
Sprint
Description
Steps to reproduce
Activity
Martin Sláma October 5, 2020 at 3:53 PM
Build #5.8.0.910 works as expected.
Jiri Trnka October 5, 2020 at 2:01 PMEdited
Teste on 5.8.0.910
monitor.log in place with correct content
rollover of log made first time at 1046kb
there are only two files after second rollover
log is part of support package
its possible to browse log in UI as a new log type
Pavel Salamon October 1, 2020 at 3:09 PMEdited
Done:
Server produces new log file: monitor.log in the usual cloverlogs directory. Example of log content is above.
The log rolls after reaching 1MB in size into another file monitor.log.1. It rolls only to 1 additional file, so in total the new log can only consume 2MB of space.
Log is part of support package.
Log is browsable in UI - Monitoring -> Server Logs
Documentation is tracked separately:
QA: test all points mentioned above
Pavel Salamon September 30, 2020 at 4:14 PMEdited
Current example of complete log after running junit tests:
Martin Sláma September 30, 2020 at 10:37 AM
Proposal of logged messages:
Oprations Dashboard shows current status of all Monitors but it isn't possible to investigate history of the Monitors. With automated 'healing' the Monitor might change state from green to red, then back from red to green while support staff is not watching screens (weekend, night). Once they are back at screens, investigating a past incidents seeing events of Monitor state change (timestamp of event, triggers causing state change) will make their work easier.
Introduce separate log file suitable for auditing history of the Monitors. The log should contain info about change of monitor's health status (ok -> fail, fail -> ok). List of failing triggers should be logged in case of ok -> fail state transition.