DDoS攻击日志持续增长时，如何结合磁盘容量、inode与I/O延迟排查异常

一次请求从访问入口进入防护或负载均衡，再经过网络链路、服务器网卡与内核，最后由应用处理并写入访问日志、错误日志或审计日志。DDoS攻击期间，入口统计、服务器日志和磁盘使用量可能同时变化，但它们并不必然同步：流量可能已在入口被拦截，应用也可能因错误重试或重复记录而持续写日志。单看磁盘告警，无法判断是否遭受攻击；单看请求量，也无法确定磁盘异常的根因。

建议先记录告警主机、发生时间、日志所在挂载点和业务影响，再按“入口与请求变化 → 容量和inode → I/O与文件系统 → 日志文件及进程 → 修复后复测”的顺序排查。这样可以先排除低风险、范围明确的问题，再判断日志增长是否与DDoS流量有关。磁盘指标可以说明日志是否造成资源压力，但不能单独用于计算所需防护值。

先核对入口变化，再判断日志是否由请求驱动

对照磁盘告警的时间，查看入口防护、负载均衡或服务器监控中的请求量、连接数、拒绝数和回源请求变化，并与访问日志、错误日志的增长时间对照。统计口径要尽量一致：入口可能按请求或流量统计，服务器日志按行数统计，二者不能直接一一对应。

常见结果及判断方向：

• 入口请求增加，服务器日志也增加：请求可能到达了应用，也可能是入口和应用分别记录了相关事件。继续核对日志内容、应用错误率和实际写入进程。
• 入口请求增加，服务器日志没有同步增加：部分请求可能在入口处被拦截，或者服务器日志不包含被拦截请求。不能因此认定流量统计异常。
• 入口请求变化不明显，日志仍持续增长：优先检查错误重试、重复记录、日志级别变化、定时任务或进程循环写入。
• 磁盘告警与请求变化时间不一致：先查其他占用目录、临时文件、备份文件，以及已删除但仍被进程打开的文件。

日志只反映其所在环节记录到的事件，并不等同于全链路流量。若要判断两者是否相关，应使用相同时间范围和实例范围，分别核对入口统计、日志增量和应用错误情况；不要仅凭Ping、CPU使用率或一份日志作结论。

按优先级检查容量、inode和挂载点

以下命令适用于常见Linux服务器。先确认目标日志目录实际所在的文件系统，再检查容量与inode：

df -hT
df -ih
findmnt

df -hT显示文件系统类型、容量和剩余空间；df -ih显示inode使用情况；findmnt用于确认目录对应的挂载点。重点检查日志目录所在文件系统，而不是只看根目录：例如/var/log可能单独挂载，也可能与/共用空间。

结果可这样解释：

• 空间接近耗尽，inode仍有余量：优先找大文件、持续增长的日志和其他大目录。
• inode接近耗尽，但空间尚有余量：优先查大量小文件，例如按请求拆分的日志、临时文件或缓存文件。
• 空间和inode都正常：仍需检查I/O延迟、挂载状态、目录权限和应用自身的写入错误。
• df显示已用空间明显高于目录统计总量：可能存在已删除但仍被进程打开的文件，也可能是挂载点或统计范围不同；继续核对，不能仅凭差值认定原因。

定位目录占用时，先限定到可疑路径，避免对整个文件系统递归扫描：

du -xhd1 /var/log 2>/dev/null | sort -h

该命令适用于支持这些参数的GNU版du。-x限制在同一文件系统内，避免跨挂载点统计；其他系统或版本若不支持-h、-d，先用du --help核实参数。目录扫描会产生额外读I/O；若设备延迟已经偏高，应缩小范围，或在业务低峰执行。

怀疑inode耗尽时，可在已知日志目录内统计文件数量：

find /var/log -xdev -type f -printf '%h\n' 2>/dev/null | sort | uniq -c | sort -n

此命令适用于支持GNU find 的系统，会遍历目录；文件数量较多时可能增加系统负载。先检查可疑目录，不要直接对整个文件系统运行。

容量正常时检查I/O延迟与文件系统状态

磁盘还有空间，不代表写入一定正常。日志持续追加、同步写入或多个任务同时读写，都可能导致I/O等待。先查看系统整体线索：

vmstat 1 5

关注wa（I/O等待）是否在故障时段持续偏高，以及是否伴随运行队列变化。vmstat反映的是系统整体情况，不能单独判断是哪块设备或哪个进程造成等待。

若系统已安装sysstat，可进一步检查设备统计：

iostat -xz 1 5

观察读写速率、队列、等待时间和设备利用率，并与该主机相近业务负载下的正常基线比较。不同设备、虚拟化环境和负载模式下，指标含义及可接受范围不同，不宜套用固定阈值。若没有iostat，不要为了排障盲目安装软件；可先对照现有监控、平台磁盘指标和系统日志。

再检查内核或文件系统是否报告错误：

dmesg -T | tail -n 100

若权限不足，使用具备读取内核日志权限的账号。重点关注I/O错误、文件系统变为只读、设备重置等信息。发现文件系统错误时，不要继续进行高强度扫描或写入测试；先确认数据备份、挂载状态和业务影响，再按该文件系统及发行版的维护流程处理。不要在文件系统仍挂载并承载业务时直接执行修复操作。

如果I/O等待偏高但没有明显容量压力，应结合设备统计、故障时间和内核日志判断是否为存储写入路径问题；若设备指标正常而应用仍报写入失败，则继续检查目标路径、服务账号权限和挂载状态。

定位增长最快的日志和实际写入进程

确认文件系统和I/O状况后，再定位具体文件。对已知日志目录查看文件大小与修改时间：

ls -lhtr /var/log

若发现某个日志持续变大，核对其写入进程、日志格式、记录频率和轮转规则。查看内容时应限制输出行数，避免大量输出增加负担或暴露敏感信息：

tail -n 200 /var/log/应用日志文件

将示例路径替换为实际文件。对日志行数、错误类型或来源分布做统计前，先确认该服务的日志字段格式；不同服务的时间、状态码和客户端地址字段位置可能不同，不能直接照搬同一条统计命令。可比较问题前后相同长度时间窗口内的日志增量，再与入口侧请求统计对照。

若df占用明显高于du统计，可检查已删除但仍被进程打开的文件：

lsof +L1

Linux进程打开文件后，即使文件被删除，进程仍可能继续占用其空间，直到文件句柄关闭。若系统没有lsof，应结合进程信息、挂载点和监控继续核实，不要仅凭df与du的差值下结论。

确认有大型已删除日志被进程持有后，先识别进程和服务影响，再采用该应用支持的重新打开日志或平滑重启方式。直接结束进程可能中断业务，不应作为默认处理动作。

修复日志增长问题时先保留证据

确认日志增长造成容量风险后，先记录告警时间、文件路径、文件大小、对应进程及入口侧统计；必要时按运维规范保存受影响的日志样本。不要为了腾空间直接删除正在写入的日志：进程可能继续占用已删除文件，空间不会立即释放，日志也可能无法完整留存。

先检查日志轮转配置和执行情况。常见Linux系统可用以下命令查看规则处理过程：

logrotate -d /etc/logrotate.conf

-d为调试模式，不执行实际轮转。配置文件路径会因发行版和服务安装方式不同而变化；若命令不存在或路径不符，先核实本机服务及配置位置。检查轮转周期、保留数量、压缩策略、目标目录权限，以及应用是否支持重新打开日志文件。

确需调整轮转规则时，先备份原配置，并确认修改只影响目标日志；在测试或维护窗口验证配置语法和应用重开日志能力，保留原文件以便回滚。不要在不了解应用行为时强制轮转、直接清空日志或随意修改权限。权限过宽可能让其他账号读取或写入日志，权限过窄则可能导致服务无法继续记录。

若日志增长由请求异常引起，单纯扩大磁盘或缩短轮转周期只能缓解空间压力，不能替代对入口流量、错误重试和应用记录逻辑的排查。入口统计、服务器日志行数和应用错误率应分别核对；只有时间范围、实例范围和统计口径可比时，才适合判断日志是否随请求变化。

区分DDoS保底防护与弹性防护，防护值不能从磁盘用量反推

“DDoS 保底防护和弹性防护有什么区别？如何评估所需防护值？”需要结合服务约定和实际流量指标判断，不能从日志文件大小、磁盘容量或日志行数直接换算。

通常所说的保底防护，是按约定提供一档基础防护能力；弹性防护则是在符合服务条件时，为超过基础范围的攻击提供额外的动态防护能力。具体能力、启用方式、计量口径、超出范围后的处理和费用规则因服务商及合同而异，应以当前服务说明和合同条款为准，不能仅凭名称推断。

评估所需防护值时，应分别核实以下信息：

1. 确认业务入口与防护覆盖范围：哪些公网地址、域名或业务入口实际受防护，避免把未纳入范围的流量统计也算入。
2. 收集可比的历史数据：按时间窗口整理正常业务峰值与已观测攻击期间的入口流量，并记录测试或监控节点、采集时间、统计环境、方法和样本范围。没有可追溯的攻击样本时，不应虚构峰值。
3. 核对指标维度：带宽、每秒数据包数、连接建立速率和每秒请求数是不同指标。并发连接数表示某一时刻的连接存量，不能替代每秒请求数，也不能单独表示攻击速率。
4. 对照服务能力口径：确认服务给出的防护值对应什么指标、统计方向和时间窗口，并核实超出基础能力后的启用条件、限制及处置方式。
5. 留出业务变化评估空间：根据自身业务峰值变化和可获得的历史数据复核需求；数据不足时先补齐监控和记录，再做容量判断，而不是把某次短时观测当成长期保证。

上述评估的证据边界是：入口监控只能说明采集范围内、采集时段内观察到的流量；服务器日志只能说明应用或系统实际记录到的事件。若监控没有覆盖攻击入口、采样口径不同或样本时间过短，就不能据此断言整体防护需求。防护值最终还需按服务商公布的指标定义和合同范围核验。

修复后按相同口径复测

处理后应使用与故障前相同的挂载点、时间窗口和监控口径检查，避免因采样范围改变造成误判：

1. 复查容量与inode：重新执行df -hT和df -ih，确认目标文件系统不再持续逼近耗尽，并观察是否有其他目录接替增长。
2. 复查I/O表现：在相近业务负载下观察vmstat、iostat或平台监控，与该环境的正常基线比较。
3. 复查日志写入和轮转：比较相同时间窗口内的日志增量，确认轮转生效、服务仍能写入，且需要保留的日志没有意外缺失。
4. 复查业务请求链路：对照入口统计、服务器访问记录和应用错误，确认请求处理恢复。磁盘空间回升本身不能证明业务已恢复。
5. 复查系统事件：确认没有新的只读挂载、I/O错误或写入失败，并覆盖一段能够反映正常业务波动的观察时间。

若容量和inode稳定但I/O等待仍高，应继续沿设备和文件系统方向定位；若I/O恢复而日志仍异常增长，应回到入口统计、错误重试和应用记录逻辑；若磁盘指标已恢复但业务仍报错，则检查应用处理环节。只有在相同环境、时间范围和统计口径下复测，才能判断瓶颈是否真正消除；防护能力是否匹配，则需另按入口流量指标和服务约定核验。