查日志文件大小，通常分三个层次：单个文件有多大、某个日志目录合计占多少磁盘、所在分区还剩多少。对应命令分别是 ls -lh、du -sh 和 df -h；如果机器用 systemd-journald 收日志，还要单独执行 journalctl --disk-usage。这三个数经常对不上，原因不一定是命令写错，更多是统计口径不同：ls 看的是文件表观字节数，du 看的是实际占用的磁盘块，df 看的是整个文件系统。先把这三个数都取到，再判断要不要清理。
适用场景：怀疑日志占满磁盘，或者需要给日志目录定清理阈值。操作动作：先用ls -lhS找出最大的单个日志文件，再用du -sh /var/log取目录合计，最后用df -h看分区已用。验证方式：du的合计应能和df的已用大致对上；对不上时查被删除但仍被进程占用的文件。风险边界：du受硬链接、稀疏文件、挂载点影响，不能只凭一个数字就删除日志，尤其不要直接rm正在写入的日志文件。
查看日志文件大小：先把能核对的事实摆清楚
这一步只记录可核对的现象，不下结论。需要确认的对象有三类：单个日志文件、日志目录合计、日志所在分区。常见位置是 /var/log；systemd 系统上 journal 日志一般在 /var/log/journal，如果该目录不存在，日志可能只落在 /run/log/journal（内存里，重启后消失），这种情况用 du 查 /var/log 是看不到的，必须用 journalctl --disk-usage。
执行前需要确认两点：当前用户对日志目录是否有读权限（很多日志目录是 750 或 700，普通用户执行 du 会报 Permission denied，结果偏小），以及目标路径是否在独立分区上。可以先跑下面几条只读命令，不改动任何文件：
ls -lhS /var/log | head -n 20
du -sh /var/log
df -h /var/log
stat -c '%n %s bytes' /var/log/syslog
journalctl --disk-usage该看到什么：ls -lhS 会按大小倒序列出目录下的文件和子目录，注意子目录显示的是目录项本身的大小，不是里面文件的总和；du -sh 输出一行合计；df -h 输出该分区的大小、已用、可用和挂载点；stat 输出的 %s 是文件表观字节数；journalctl --disk-usage 输出类似 “Archived and active journals take up ...” 的一行。这些都是可以截图留档的事实，先别急着删。
查看日志文件大小最容易搞错的一点
最常见的误解是把 du 的结果当成“磁盘被日志占了多少”的唯一答案。判断分界在这里：如果 df -h 显示分区已用远大于 du -sh 各目录合计，差额通常来自“已被删除但仍被进程打开”的日志文件——日志轮转时如果程序没重新打开文件句柄，文件在目录里消失了，空间却没释放，du 自然统计不到。
能区分这两种情况的检查动作是查链接数为 0 的打开文件：
sudo lsof +L1 2>/dev/null | head -n 20
sudo lsof 2>/dev/null | grep -i deleted | grep -i log如果输出里有 /var/log/xxx.log (deleted) 这样的行，说明空间被持有它的进程占着，删文件没用，需要让对应服务重新加载或重启（例如 systemctl reload nginx、systemctl restart rsyslog），具体服务名以 lsof 输出里的 COMMAND 列为准。反过来，如果 lsof +L1 没有相关输出，而 df 仍然紧张，就要去看是不是别的目录或别的挂载点占用了，不要继续在 /var/log 里找。另一个常见混淆是 du 默认按块统计，稀疏文件或小文件多的目录会显示得比 ls 的字节数偏大，需要表观大小时加 --apparent-size。
查看日志文件大小：一个照着就能做完的做法
下面这条路径从“哪个文件大”走到“总量多少”，每步都注明该看到什么。建议在目标机器上逐条执行，不要合并成一行脚本，方便中途判断。
# 1. 找最大的单个日志文件，确认 File 名和 Size 列
sudo ls -lhS /var/log | head -n 20
# 2. 看目录总量（-s 汇总，-h 人类可读）
sudo du -sh /var/log
# 3. 看一级子目录各占多少，按大小排序
sudo du -h --max-depth=1 /var/log 2>/dev/null | sort -rh | head -n 20
# 4. 列出超过 100M 的日志文件，便于对照轮转配置
sudo find /var/log -type f -size +100M -exec ls -lh {} \; 2>/dev/null
# 5. 看分区余量，确认压力是否真实存在
df -h /var/log
# 6. systemd 系统单独看 journal
journalctl --disk-usage每步的预期：第 1 步应能看到几行普通日志文件和若干 .gz 已轮转文件，注意 .gz 也是占空间的；第 2 步只输出一行，形如 1.2G /var/log；第 3 步输出多行，各行之和应接近第 2 步的合计，差的量级通常在几十 MB 以内，差得多说明有子目录被权限挡住没统计进来，可加 sudo 重跑；第 4 步没有输出说明没有超过阈值的单文件，属于正常；第 5 步关注 Use% 列；第 6 步只有一行，若提示找不到 journal 目录，说明 journal 未持久化，换用 du -sh /run/log/journal 核对。清理时优先用 logrotate 或 journalctl --vacuum-size= 这类按规则收缩的方式，避免直接 rm 正在写入的文件。
查看日志文件大小：怎么验证结果对不对
验证的核心是让两个不同口径的数字互相印证。第一步，把表观大小和块占用对齐：
stat -c '%s' /var/log/syslog
du -b /var/log/syslog
du -sh --apparent-size /var/log正常结果：stat -c '%s' 和 du -b 对同一个文件应输出相同或非常接近的字节数；如果 du -b 明显偏大，可能是文件系统块大小影响，属于预期之内。第二步，验证目录合计是否自洽：
sudo du -sh --total /var/log
sudo du -h --max-depth=1 /var/log 2>/dev/null | sort -rh | head -n 20正常结果：--total 给出的一行合计应与第 3 步各子项相加大致相等，差异能用手上已知的文件解释。第三步，和文件系统层对照：df -h /var/log 的 Used 减去 Reserved（ext4 默认给 root 保留一部分，可用 tune2fs -l 查看 Reserved block count）之后，应能和各挂载点下 du -sh 的结果对上；差额持续存在且 lsof +L1 有输出，就是被删未释放；差额存在而 lsof +L1 干净，就去查同分区下的其他目录，用 du -h --max-depth=1 / 逐层缩小范围。第四步，journal 的验证靠页面上的一条输出对照：journalctl --disk-usage 显示的总量，应与 sudo du -sh /var/log/journal 在同一量级，差别过大时确认是否有 SystemMaxUse= 配置在 /etc/systemd/journald.conf 中限制，该文件的当前内容需要现场查看确认。