1 個回答
- 最新
- 最多得票
- 最多評論
2
Hi THere
Instead of clearing the log file with the echo command, id recommend implementing something like logrotate or one of the supported methods below:
From https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AgentReference.html#agent-faq
The following file rotation mechanisms are supported:
- Renaming existing log files with a numerical suffix, then re-creating the original empty log file. For example, /var/log/syslog.log is renamed /var/log/syslog.log.1. If /var/log/syslog.log.1 already exists from a previous rotation, it is renamed /var/log/syslog.log.2. (logrotate will do this for you)
- Truncating the original log file in place after creating a copy. For example, /var/log/syslog.log is copied to /var/log/syslog.log.1 and /var/log/syslog.log is truncated. There might be data loss for this case, so be careful about using this file rotation mechanism.
- Creating a new file with a common pattern as the old one. For example, /var/log/syslog.log.2014-01-01 remains and /var/log/syslog.log.2014-01-02 is created.
You might also find the exact reason that the logs stop streaming by examining the CloudWatch agent log file. See https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/troubleshooting-CloudWatch-Agent.html#CloudWatch-Agent-troubleshooting-loginfo But I would still try and stick with one of the supported rotation mechanisms to ensure you do not lose data.
相關內容
- 已提問 1 年前
AWS 官方已更新 1 年前- AWS 官方已更新 1 年前
Thanks for your help. The solution was to use logrotate instead of directly writing a cron. Delete or move the catalina.out file wasn't possible as would break the tomcat logs, even if we created a new empty file after. That's why I used cron to follow the 2nd point you've raised here. Don't know why logrotate made it work and not cron, but at least it's working!