Skip to content
VDS · Docker và container

Log container và cách không làm mất chúng

Log Docker được lưu ở đâu, cách giới hạn kích thước để chúng không làm đầy đĩa, và phải làm gì để bản ghi tồn tại qua việc tạo lại container.

Cập nhật 23 tháng 8, 2026

Khi một dịch vụ gặp sự cố, log là nguồn thông tin duy nhất đáng tin cậy. Mặc định Docker ghi log vào một tệp bên cạnh container và không giới hạn kích thước: một ứng dụng ghi log liên tục có thể làm đầy toàn bộ ổ đĩa trong một tuần.

Cách đọc

docker logs -f --tail 100 <container>
docker compose logs -f app
docker compose logs --since 30m --timestamps app
docker logs <container> 2>&1 | grep -i error | tail -50

Điều đáng nhớ: Docker hiển thị những gì ứng dụng ghi ra standard output và standard error. Nếu ứng dụng ghi vào tệp riêng bên trong container, docker logs sẽ không hiển thị gì — bạn phải tìm log bên trong hoặc chuyển hướng đầu ra.

docker compose exec app ls -la /var/log

Giới hạn kích thước ngay bây giờ

Cấu hình toàn cục cho tất cả container là /etc/docker/daemon.json:

{
  "log-driver": "json-file",
  "log-opts": { "max-size": "20m", "max-file": "3" }
}
sudo systemctl restart docker

Cấu hình này áp dụng cho các container được tạo sau khi khởi động lại. Các container đang chạy phải được tạo lại. Với một dịch vụ riêng lẻ, cấu hình tương tự cũng được đặt trong Compose:

services:
  app:
    logging:
      driver: json-file
      options:
        max-size: "20m"
        max-file: "3"

Kết quả: không quá 60 MB cho mỗi dịch vụ thay vì tăng trưởng không giới hạn.

Kiểm tra kích thước hiện tại trước khi nó khiến bạn bất ngờ: sudo du -sh /var/lib/docker/containers/*/*-json.log | sort -h | tail. Bạn không thể cắt bớt một tệp đang được sử dụng bằng rm — dung lượng không được giải phóng khi Docker vẫn giữ descriptor. Cách đúng: tạo lại container hoặc sudo truncate -s 0 <file>.

Giữ log tồn tại qua container

Tệp log bị xóa cùng với container. Nếu lịch sử quan trọng, hãy chuyển nó cho system journal:

logging:
  driver: journald
  options:
    tag: "myapp"
journalctl -t myapp -n 200 --since today
journalctl -t myapp -p err --since "2 days ago"

journald tự động xoay vòng bản ghi và bị giới hạn bởi cấu hình SystemMaxUse trong /etc/systemd/journald.conf. Để kiểm tra dung lượng nó chiếm: journalctl --disk-usage.

Với nhiều dịch vụ cùng lúc, việc thu thập mọi thứ vào một nơi sẽ tiện hơn — ví dụ, dùng một container collector chuyên dụng lưu bản ghi theo ngày. Nhưng hãy bắt đầu với journald: nó đã có sẵn và không tốn gì.

Những gì cần tìm khi gỡ lỗi sự cố ngừng hoạt động

  1. 200 dòng cuối trước khi crash: docker logs --tail 200 <container>.
  2. Mã thoát: docker inspect -f '{{.State.ExitCode}} {{.State.OOMKilled}}' <container>. Mã 137 và true trong OOMKilled nghĩa là kernel đã kill tiến trình vì hết bộ nhớ — xem giới hạn tài nguyên.
  3. Log hệ thống của máy: sudo dmesg -T | tail -50 sẽ hiển thị các lần kill do hết bộ nhớ và lỗi ổ đĩa.

Lỗi thường gặp

  • Ổ đĩa đầy vì log và mọi dịch vụ đều ngừng hoạt động. Giới hạn kích thước là việc bắt buộc ngay sau khi cài đặt Docker.
  • Xem log của một container đã bị xóa. Sau docker compose down nó không còn nữa. Hãy thu thập bản ghi vào journald trước.
  • Thông tin bí mật trong log. Ứng dụng rất thích in ra chuỗi kết nối kèm mật khẩu. Bất kỳ ai có quyền truy cập máy đều có thể đọc log.
  • Tìm lỗi trong bảng điều khiển văn bản. Nó luôn chỉ 80×24 và các dòng dài bị cắt. Để đọc log, SSH hoặc bảng điều khiển “Screen” sẽ tiện hơn.