排查EC2实例上的周期性运行进程问题

一、周期性CPU使用率峰值的其他可能原因 #

除了用户级crontab，还有以下几类常见场景会导致这类周期性负载：

• 系统级定时任务集合：检查/etc/cron.d/目录下的配置文件，以及/etc/cron.hourly/、/etc/cron.daily/、/etc/cron.weekly/、/etc/cron.monthly/这些系统默认的定时脚本目录——日志轮转、系统包自动更新等维护任务通常放在这里，不会出现在普通用户的crontab中。
• Anacron补跑任务：针对可能频繁启停的实例，Anacron会自动补跑错过的定时任务，配置文件在/etc/anacrontab，对应的执行脚本也多在/etc/cron.daily/等目录，即使实例不是持续运行，也可能在开机后触发固定时段的负载。
• 应用内置定时逻辑：如果实例上运行了业务应用，比如Java的Quartz、Python的APScheduler、Django的Celery Beat等，这类任务由应用自身调度，完全不依赖系统crontab，需要检查应用的配置文件或运行日志来确认。
• AWS远程触发任务：比如EventBridge（原CloudWatch Events）配置了定时触发SSM Run Command，远程在实例上执行命令；或者第三方工具通过API调用实例对外暴露的接口，外部定时请求也会拉高CPU负载。
• 非crontab调度的备份/同步任务：实例上可能存在用systemd timer、at命令或其他工具触发的自定义备份、数据同步脚本（比如同步到S3、EFS），这类任务不会出现在crontab里，可通过/var/log/syslog或/var/log/messages日志排查执行记录。
• 系统工具周期性运行：比如updatedb（更新文件索引数据库）、fsck（定期文件系统检查）这类系统工具，默认会在固定时段运行，可能带来短暂的CPU占用。

二、自身监控是否会导致峰值？ #

AWS默认的CloudWatch基础监控（5分钟采集一次）对CPU的消耗极低，几乎不会引发可观测的信用消耗峰值（尤其是t系列实例的CPU信用机制，需要持续的CPU占用才会消耗信用）。即使启用了详细监控（1分钟采集），资源消耗也可以忽略不计。

只有当你在实例上部署了自定义的监控脚本（比如每分钟采集大量系统指标并上传，或执行复杂的监控分析逻辑），才可能导致周期性CPU负载，但这属于自定义任务范畴，并非AWS自带监控服务导致。因此你观察到的峰值大概率不是来自实例自身的监控。

内容的提问来源于stack exchange，提问作者Marley