AutoRemoval for *.gz type of files

[kornicameister]

Disclaimer and apologies: this might either be a feature or bug or a weird case of misconfiguration on my part.

Is your feature request related to a problem? Please describe.

I have following piece of configuration that is basically self-monitoring of logs from cloudwatch agent. Now, I was hoping that with auto_removal turned on old logs, after agent rotates over, will be removed but apparently that was not a case on of the machines where I found 5 gz files from cloudwatch agent. Funny thing is that another machine that has the same configuration applied doesn't show gz files.

Describe the solution you'd like Once application starts writing to new file, old file is removed regardless of extension it gets i.e. log vs txt vs gz.

Describe alternatives you've considered Using logrotate, for example, but I really don't find it required if agent says it should remove old files.

Additional context None

[SaxyPandaBear]

What is creating the gz files? I don't recall the agent creating and rotating gzip compressed log files for itself.

[kornicameister]

Well, I haven't made any changes to agent configuration. It's been installed, configuration changes to agent are delivered via codedeploy and that's it. The company that installed an agent tells me that they haven't configured any external rotation as well.

[SaxyPandaBear]

Circling back to this, the auto_removal flag is very rudimentary, and I don't think it makes sense to use it in your current use case, based on the information I have.

That configuration is best used when the monitored logs follow a chronologic pattern.

For example, let's assume you are publishing a log in /var/foo/, and your logger appends a date suffix to the log file, e.g.: /var/foo/some.log-2022-08-15. Then, on the next day, your logger stops writing to that file and appends to a new file, /var/foo/some.log-2022-08-16. In this scenario, the application completely abandons that first log file in favor of writing logs to the next.

In this case, it makes sense to use the auto_removal flag so that the CloudWatch agent could know that once a newer file is discovered, clean up the old one, a la:

{
  "file_path": "/var/foo/some.log*",
  "other": "stuff",
  "auto_removal": true
}

note the * wildcard used so that the agent knows to scan for files in that directory matching the glob to pick the latest updated file

In your case, you are monitoring the CloudWatch agent's own log file. The agent does not rotate its own log file, and if your environment has something else that is compressing the log file and truncating it, then the agent isn't really going to know about that. This doesn't match up with the example scenario I wrote above, because the CloudWatch agent is always going to be writing to that amazon-cloudwatch-agent.log file, so it doesn't make as much sense to configure auto_removal on it.

Based on what I can tell, I think it makes more sense for you to set up a cron job or something on your host that cleans up files in that/opt/aws/amazon-cloudwatch-agent/logs/ folder where the modified time is > X days.

[kornicameister]

Thanks for the explanation.