先找到真正增长的日志来源
服务器磁盘持续增长时，应用终端输出、代理访问日志、数据库日志和部署记录可能分散在不同位置。先查看文件系统用量，再按受控目录定位增长对象，记录文件路径、所属进程和写入方式。不能看到一个日志目录很大，就把里面全部文件删除。正在处理故障时，最近一段日志可能是唯一能够解释问题的证据，应先保存必要范围再执行维护。
应用由 systemd 管理时，标准输出通常交给日志系统；代理访问日志则可以写文件，也可以使用标准输出。两者可能采用不同保留机制。先明确每条日志从哪里产生、写到哪里、谁负责轮转，再设置预算。如果应用还自行写文件，就要核对是否同时记录了相同事件，避免以为只有一份日志却实际重复存储。
为容量与保留时间分别设规则
容量上限限制磁盘占用，时间规则决定故障回查范围，两者需要同时考虑。只有保留天数，在高请求量下仍可能占满磁盘；只有容量上限，突然增多的日志又可能把重要历史挤掉。依据服务器空间、诊断需求和数据保留要求设置预算，并定期观察真实增长。示例数值只能用于演示语法，不应被描述为适合所有站点的标准配置。
多个站点共用磁盘时，单个日志的上限不等于整机上限。应用、代理、数据库、备份和发布目录需要共同预算。记录当前文件和历史文件的关系，并给磁盘留出运行余量。保留策略触发时可能按某些事件清理旧文件，不一定在配置到期的瞬间立即回收，因此还应验证实际执行行为，不能仅根据理论上限判断系统已经受到保护。
journald 需要区分持久与运行时存储
日志系统可以写持久目录，也可以使用运行时存储，两者的容量选项不同。先检查当前存储模式和实际日志位置，再使用对应的大小及保留规则。仅修改持久日志选项，未必影响采用运行时存储的环境。查看官方配置文档时还要核对发行版所安装的版本，较新的选项不一定被旧版本识别，不能只依赖网络上最新示例。
采用配置片段可以让项目设置与系统默认分开，但需要检查合并后的配置及优先级。调整后按维护要求重启相关日志服务，并检查错误信息。查询磁盘使用量和指定服务的日志，确认应用仍持续写入。日志配置修改本身也应留记录，尤其是缩短保留期的变化，因为它会改变以后能够调查的历史范围。
清理历史日志要理解活动文件
日志系统提供的历史清理入口通常针对归档文件，当前活动文件可能仍然占据空间。执行清理后用相同工具重新查看用量，理解为什么空间没有完全降到设置值。必要时按照官方机制先进行轮转，再处理历史，不能直接从日志内部目录随意删除文件。手工删除会绕过系统管理，并可能破坏读取或保留约定。
清理前确认需要保存的故障时段已经导出到受保护位置，并检查导出内容不含认证信息。导出也要有保留策略，否则只是把日志从一个目录搬到另一个无限增长的目录。对生产机器，维护动作应按明确时间窗口和目标范围执行，先查看拟清理的历史规模，再处理。不要为了测试规则而清除当前正在调查的证据。
Caddy 文件日志采用自身轮转
Caddy 访问日志的文件输出提供大小、数量和保留时间控制，使用前查看当前版本对应文档。数量与时间共同决定历史文件保留，不能只增加保留天数就推定能保存所有日期。压缩可以减少历史体积，但日志增长速度仍需观察。访问日志与代理自身运行日志是不同类别，站点里的访问日志配置不自动管理所有运行输出。
同一个输出文件的参数变化需要注意生效方式。官方文档说明相关变更可能需要服务器重启，普通配置重载未必应用新的文件输出选项；采用新文件名则具有不同处理路径。调整前校验完整站点配置，并安排合适窗口验证。不能仅因为重载命令成功退出，就宣布新轮转预算已经生效，还要观察新的文件和保留行为。
不要让两个轮转器同时管理一个文件
如果应用或代理已经自行轮转，再配置外部工具对同一文件改名、截断，可能产生竞争和遗漏。先选择一个负责者，并了解写入进程如何重新打开文件。某些程序一直持有原文件句柄，外部改名后仍向旧文件写入，看起来新文件没有增长。轮转策略必须与写入程序的文件处理机制匹配，不能只照搬另一服务的配置。
复制后截断的方式也存在时间差，在复制与截断之间写入的内容可能处理不完整。是否能够接受这种边界应由日志用途决定。需要审计连续性的日志，适合采用程序支持的重新打开或专用日志设施。本文重点是容量与诊断保留，不保证任意外部轮转方案都能提供无损审计，选择工具前应验证其实际行为。
删除文件后占用不降要查句柄
文件被删除但进程仍持有打开句柄时，磁盘空间可能要等句柄关闭后才能释放。此时继续搜索目录会找不到原文件，却仍能看到磁盘被占用。应通过系统工具检查已删除但仍打开的对象，并确认持有进程。不要直接结束所有进程来回收空间，先判断能否让目标服务安全重新打开日志，或在维护窗口重启它。
重启之前保存必要状态，确认服务恢复方式和健康检查。对于数据库或其他关键服务，还应遵循其自身维护流程。文件长度、目录统计与文件系统空闲量采用不同口径，比较时注明来源。空间回收后检查日志仍在写入，并验证应用请求正常，避免维护虽然释放了空间，却让诊断链路永久停止。
日志内容也需要最小化
登录凭据、会话标识、验证码和受保护配置不应进入日志。代理默认遮盖部分敏感头，并不代表应用自己打印的请求体也受到相同保护。URL 查询参数可能包含秘密，应从业务设计上避免，并在日志过滤中处理必要字段。排查上传错误时，记录阶段和错误类别即可，不需要把用户上传的原始内容或完整路径公开保存。
访问地址、账号标识和管理行为具有不同隐私及审计用途，应分别限定访问权限与保留时间。日志文件不应放在站点能够直接提供的静态目录里。历史压缩文件同样需要保护，并核对备份中是否再次复制了它们。删除在线历史日志不一定消除备份中的副本，整个生命周期需要由明确规则管理。
验证轮转前后都能继续诊断
在隔离环境使用小型样例产生有限日志，观察活动文件、历史文件、压缩和保留数量，再让应用继续写入。不要在生产上发送大量请求来强行触发轮转，制造额外负载和业务记录。验收还应检查日志格式、时间标记和请求关联标识是否保持可读。只看历史文件出现，不足以证明轮转后诊断能力完整。
随后模拟一次受控错误，确认能沿代理访问记录与应用日志找到对应事件。检查低权限服务是否能够创建新日志文件，历史文件权限是否一致。服务器重启后再次验证持久规则，防止配置只在当前进程中有效。对容量清理记录实际结果，但不要凭单次样例宣称未来磁盘永远不会满，监控与告警仍需持续工作。
将日志预算与部署记录关联
部署时保存版本标识、健康检查结果和发布任务摘要，便于把错误时段与某个更新对应。长期调试模式应有明确结束时间，不能在一次故障之后一直开启高详细度输出。保留必要摘要与失败原因，比永久保存所有内部细节更实用。调整轮转预算后更新运维文档，说明最新能够回查的范围以及紧急导出方法。
定时发布器的每次执行结果也属于诊断证据，应能够查看最近运行、退出状态和发布数量，但认证凭据只保存在受保护配置中。查看命令不应把凭据文件打印出来。服务器出现磁盘压力时，按既定目录预算定位来源，先处理可再生成的临时对象，再依据规则清理日志历史，不要临时拼接无边界的删除命令。
将配置示例分开保存和验证
下面示例分别展示日志系统配置片段和代理站点文件的写法，它们属于不同文件，不能直接粘贴到同一个配置中。数字只是示例预算。应用日志与访问日志采用独立规则后，还要检查数据库及备份是否有自己的容量上限。配置校验、实际写入和保留行为都通过，才能说明这次维护完成了预定目标。
对于 Caddy，先建立可写且不可公开访问的日志目录，再校验完整配置并按版本要求应用。对日志系统，确认所用选项与安装版本匹配。维护后保留用量记录与一次业务请求的诊断路径，形成可重复检查的方法。这样下一次磁盘增长时能够找到具体来源，而不必再次从删除所有日志开始尝试。
实现片段
# /etc/systemd/journald.conf.d/60-example-budget.conf
[Journal]
SystemMaxUse=200M
SystemKeepFree=500M
RuntimeMaxUse=100M
MaxRetentionSec=14day
# /etc/caddy/sites-enabled/blog.caddy（另一文件）
blog.example.com {
log {
output file /var/log/caddy/example-access.log {
roll_size 10MiB
roll_keep 7
roll_keep_for 168h
mode 0640
}
format json
}
reverse_proxy 127.0.0.1:3100
}
# 检查：journalctl --disk-usage
# 校验：caddy validate --config /etc/caddy/Caddyfile --adapter caddyfile
评论 · 0