"Library Log File" Grows With No Limit

[eitansanvean]

We're logging to CloudWatch in an application which sometimes runs without a network connection. This generates many errors and aws-logger-errors.txt can explode. These seems to be no way to control the size of this file.

We have a workaround which is to set LibraryLogFileName to null which stops all error logging.

[sattpat]

Hey, thanks for raising this issue. We certainly dont want to be logging every single issue. We would instead like to capture exceptions that are unique. Meaning that if you get exceptions as a result of network connection, we only log that once and we skip the repeats.
The other thing I wanted to raise here is that the logging library has a capacity and so if you are going offline, if the buffer has no additional capacity, the new logs would be lost. In the end the logs you will end up seeing on CW logs once you come online, will be the old logs. I am wondering if this is beneficial to you

[sattpat]

Closing this issue due to lack of activity. Feel free to reopen if additional follow up is needed

[LewisHamill]

We have just been in a position were the log file grew to over 20Gb in 4 days due to a permission related error with AWS it would seem. Still investigating the cause but this was a problem for us and I will now be disabling this log file seeing as there is no fix currently.

[kazim-Arshad]

Facing the same issue. Log file aws-logger-errors.txt size increases very rapidly to GBs when ever there is some connectivity issue to cloudwatch. A repetitive message gets logged to the file which increases file size.

[winzig]

Just ran into the same issue today on an EC2 instance that recently had some new logging code enabled.

[winzig]

@ashishdhingra Can this issue be re-opened/addressed?

[ashishdhingra]

@winzig Looks like this issue was reported more than 2 years back and has a workaround available to disable logging by setting LibraryLogFileName to null. You may also control logging level by various configuration options when using specific logging library (NLog/Serilog/etc.). In case something else is required, since this issue is closed, request you to open a new issue (mentioning about this issue) along with the details in the issue/feature-request template.

[winzig]

OK, well those things don't solve the problem. As sattpat mentioned in his initial reply, the real solution would be:

We certainly dont want to be logging every single issue. We would instead like to capture exceptions that are unique. Meaning that if you get exceptions as a result of network connection, we only log that once and we skip the repeats.