1) There is the possibility that the missing information
could be crucial. Clients are settling bets based on these
processes. If things go tits up on a major event (think
Football World Cup and the like) a lot of money could be at
stake and if it is not our problem but we cannot prove it then
we could take a financial and reputational hit. Besides not
knowing what happened when it went wrong makes fixing it hard
2) We used to use the rotation feature that was built into the
Logger package but we found in the past that when summer time
happened the logger died because the new file already existed
(not sure what was happening but moving the logfile with that
days timestamp elsewhere fixed it). It was in our support
calendar to check for this specifically until we had migrated
everything to use the standard logrotate. This was years ago and
this may be fixed now but testing it is not convenient when
summer time changes happen only twice a year :)
3) syslog does look like the next thing to look at. I had a
feeling that the most reliable alternative would be this. I
will have to dig into it further
I have considered logging to a queue and have a reader
create the actual log file but syslog will probably be the
simpler solution
Thanks for you input