WebIF diagnostic log

Black Hole

May contain traces of nut
I have been thinking about how the log could be easier to use. As we know, it sits there accumulating entries by a file append process, which means that anything meaningful to recent events is at the end, and if it has not been cleared recently that will be at the end of a very large file.

Opening the log file via the WebIF editor does not offer any quick way to scroll through to end, although I admit the file can be exported to an easier environment (eg PC).

Proposition: instead of appending to one file, how about starting a new log file every time the date changes - with a file name that reflects the date? Then set an auto-expire option on the log files so they could be binned after a week or a month (who is going to want to look at log entries from more than a month ago?). Then the size of the file will be limited by the number of log entries per day, and the user will have a pretty good idea which file to look in for any particular event.
 
It would be possible to get the end of a log file by getting the Web-If to do a 'tail', in this case to show the last 10 lines of the redring.log
Code:
humax# tail -n 10 /mod/tmp/redring.log
[RR] Sun Feb  2 15:44:27 2014: !> RingBrightness(0x1a) fc
[RR] Sun Feb  2 15:47:28 2014: -> DisplayBrightness(0x19) 78
[RR] Sun Feb  2 15:47:28 2014: +> DisplayBrightness(0x19) 78
[RR] Sun Feb  2 15:47:28 2014: !> DisplayBrightness(0x19) 78
[RR] Sun Feb  2 15:47:28 2014: -> RingBrightness(0x1a) 78
[RR] Sun Feb  2 15:47:28 2014: +> RingBrightness(0x1a) 78
[RR] Sun Feb  2 15:47:28 2014: !> RingBrightness(0x1a) 78
[RR] Sun Feb  2 15:50:29 2014: -> RingBrightness(0x1a) 78
[RR] Sun Feb  2 15:50:29 2014: +> RingBrightness(0x1a) 78
[RR] Sun Feb  2 15:50:29 2014: !> RingBrightness(0x1a) 78
humax#
 
Proposition: instead of appending to one file, how about starting a new log file every time the date changes - with a file name that reflects the date? Then set an auto-expire option on the log files so they could be binned after a week or a month (who is going to want to look at log entries from more than a month ago?). Then the size of the file will be limited by the number of log entries per day, and the user will have a pretty good idea which file to look in for any particular event.
I have been thinking of rewriting the whole log interface to make it easier to manage them. Yes, rotating logs daily would make a lot of sense in this environment too. I will add it to the list : )
 
Back
Top