Ví dụ thực tế: /var/log chiếm 5.7GB dung lượng


1. Vấn đề thực tế gặp phải

Trên một VPS Ubuntu chạy nginx + mysql, khi kiểm tra dung lượng ổ đĩa, ta thấy thư mục /var/log phình to bất thường:

5.7G  /var/log
4.1G  /var/log/journal
1.5G  /var/log/nginx
8.7M  /var/log/mysql
5.4M  /var/log/letsencrypt
92K   /var/log/apt
72K   /var/log/unattended-upgrades

👉 Nguyên nhân chính:

  • systemd journal không bị giới hạn dung lượng
  • nginx access/error log ghi quá nhiều (bot, crawler, request 404…)

Đây không phải lỗi, mà là do chưa cấu hình log rotation / log limit.


2. Phân tích từng thư mục log

2.1 /var/log/journal – Thủ phạm lớn nhất (4.1GB)

  • Do systemd-journald quản lý
  • Mặc định không giới hạn dung lượng
  • Server chạy càng lâu → log càng phình

Kiểm tra dung lượng journal:

journalctl --disk-usage

2.2 /var/log/nginx – Access & Error log (1.5GB)

Thường bao gồm:

  • access.log
  • error.log
  • access.log.1, error.log.1
  • *.gz

Nguyên nhân:

  • Website tin tức / nhiều bot
  • Không tắt log cho file tĩnh
  • Logrotate không chạy hoặc cấu hình kém

2.3 Các log khác

Thư mụcDung lượngĐánh giá
mysql8.7MBBình thường
letsencrypt5.4MBBình thường
apt / unattended<100KBKhông cần xử lý

3. Dọn dẹp journal log (AN TOÀN – KHUYẾN NGHỊ)

3.1 Dọn ngay lập tức

Giữ lại log 7 ngày:

sudo journalctl --vacuum-time=7d

Hoặc giới hạn 500MB:

sudo journalctl --vacuum-size=500M

✔ Không làm sập server
✔ Không cần reboot


3.2 Giới hạn vĩnh viễn journal

Mở file cấu hình:

sudo nano /etc/systemd/journald.conf

Thêm / sửa:

SystemMaxUse=500M
SystemKeepFree=200M
MaxRetentionSec=7day

Áp dụng:

sudo systemctl restart systemd-journald

👉 Từ nay journal không bao giờ vượt quá 500MB


4. Xử lý log nginx (1.5GB)

4.1 Kiểm tra file lớn

ls -lh /var/log/nginx

4.2 Xóa log cũ đã rotate

sudo rm -f /var/log/nginx/*.gz
sudo rm -f /var/log/nginx/*.[0-9]

4.3 Cắt log đang chạy (CHUẨN – KHÔNG rm)

sudo truncate -s 0 /var/log/nginx/access.log
sudo truncate -s 0 /var/log/nginx/error.log

👉 Không dùng rm access.log vì nginx đang giữ file descriptor

Reload nginx:

sudo systemctl reload nginx

5. Kiểm tra & sửa logrotate (rất quan trọng)

Mở cấu hình nginx logrotate:

cat /etc/logrotate.d/nginx

Cấu hình chuẩn nên có:

/var/log/nginx/*.log {
    daily
    rotate 7
    compress
    missingok
    notifempty
    create 0640 www-data adm
    sharedscripts
    postrotate
        systemctl reload nginx > /dev/null
    endscript
}

Chạy test logrotate:

sudo logrotate -f /etc/logrotate.conf

6. Tối ưu nginx để log không phình nhanh

6.1 Tắt access log cho file tĩnh

location ~* \.(jpg|jpeg|png|gif|css|js|ico|webp)$ {
    access_log off;
}

6.2 (Tuỳ chọn) Giảm log cho bot

  • Bot Google, Bing → không cần access log chi tiết
  • Site tin tức / crawl nhiều → rất hiệu quả

7. Checklist xử lý nhanh (thực chiến)

# Dọn journal
journalctl --vacuum-time=7d
# Dọn nginx log
rm -f /var/log/nginx/*.gz
rm -f /var/log/nginx/*.[0-9]
truncate -s 0 /var/log/nginx/access.log
truncate -s 0 /var/log/nginx/error.log
systemctl reload nginx
# Kiểm tra lại
du -sh /var/log/*

8. Kết luận

  • /var/log lớn không phải lỗi
  • Chủ yếu do journal + nginx log
  • Chỉ cần cấu hình đúng → ổn định lâu dài

👉 Sau khi xử lý, /var/log thường chỉ còn < 1GB và không tăng vô hạn nữa.


9. Gợi ý nâng cao

  • Cron auto-clean log
  • Phân tích IP/bot gây log nhiều
  • Tách access log theo domain

Bài viết dựa trên dữ liệu thực tế hệ thống:

5.7G /var/log
4.1G journal
1.5G nginx

Phù hợp cho VPS Ubuntu, nginx, website tin tức, crawler nhiều.