限制全局日志体积不能直接防范CC攻击，但可防止其引发的日志暴增→磁盘写满→容器崩溃→服务中断的连带故障；需配置Docker daemon.json的max-size与max-file参数，并配合Nginx日志裁剪、logrotate及监控告警。
限制全局日志体积本身不能直接防范CC攻击，但它能防止CC攻击引发的**连带性故障**——即日志暴增导致磁盘写满、容器崩溃、服务中断。当大量恶意请求涌入，Nginx或应用容器会高频记录访问日志（尤其是403/429/503等防御响应），若日志无管控，单个容器几天就能吃光几十GB磁盘空间。
为什么CC攻击会让日志“爆炸”
CC攻击虽不直接打日志系统，但防御动作会显著放大日志量：
- 限流触发后，Nginx频繁返回
503 Service Temporarily Unavailable，每条都记入access.log； - Fail2ban自动封禁IP时，会在系统日志（/var/log/auth.log、/var/log/messages）中密集写入封禁记录；
- 应用层自定义拦截（如Spring Boot过滤器）若开启DEBUG级日志，每个可疑请求都可能输出多行堆栈或参数详情；
- 多个容器并行运行时，日志叠加效应更明显——10个API容器各占150MB上限，就已占用1.5GB。
配置Docker全局日志轮转（关键一步）
在所有容器启动前统一设限，避免逐个修改。编辑/etc/docker/daemon.json，加入以下内容：
{
"log-driver": "json-file",
"log-opts": {
"max-size": "50m",
"max-file": "3"
}
}
说明：
-
max-size: "50m"：单个日志文件最大50MB（注意单位是m，不是MB）； -
max-file: "3"：最多保留3个历史文件（含当前），即单容器上限150MB； - 该配置对新启动容器生效，旧容器需重启才能加载；
- 务必用
$ sudo systemctl restart docker重载配置。
配合Nginx日志裁剪与分离
Docker只管容器stdout/stderr，而Nginx的access.log和error.log默认写入宿主机文件系统，需单独处理：
- 在Nginx配置中关闭不必要的日志：对已启用限流的location，可加
access_log off;减少冗余记录； - 将日志路径指向Docker管理的卷（如
/var/log/nginx挂载为tmpfs内存盘），避免落盘； - 使用logrotate按小时切分+压缩，例如配置
/etc/logrotate.d/nginx，设置daily、rotate 7、compress； - 对高危路径（如
/login、/api/search）单独配置日志文件，并启用buffer和flush参数降低I/O压力。
监控与告警联动（防患未然）
仅设限不够，需主动感知异常增长：
- 用
df -h /var/lib/docker监控Docker根分区使用率，>85%即触发告警； - 定时统计各容器日志大小：
docker ps -q | xargs -r docker inspect --format='{{.Name}} {{.LogPath}}' | xargs -r -n2 sh -c 'echo $1 $(du -h $2 | cut -f1)'； - 将日志体积突增（如1小时内增长超200MB）作为CC攻击辅助判断指标，与QPS、5xx错误率一起纳入Prometheus告警规则；
- 结合Fail2ban日志，若发现同一IP在
journalctl -u fail2ban中高频出现，且对应容器日志同步激增，基本可确认为有效攻击。
