Đọc log VPS với journalctl: tìm lỗi và giữ bằng chứng
Log giúp xác định dịch vụ lỗi ở thời điểm nào và sự kiện nào xảy ra trước đó. Với VPS dùng systemd, journalctl là công cụ hữu ích, nhưng vẫn có ứng dụng ghi file riêng hoặc log trong container. Cần biết nguồn log thay vì mặc định mọi thứ nằm trong journal.

Log giúp xác định dịch vụ lỗi ở thời điểm nào và sự kiện nào xảy ra trước đó. Với VPS dùng systemd, journalctl là công cụ hữu ích, nhưng vẫn có ứng dụng ghi file riêng hoặc log trong container. Cần biết nguồn log thay vì mặc định mọi thứ nằm trong journal.
Bắt đầu bằng mốc thời gian
timedatectl status
journalctl --list-boots
sudo journalctl -b -n 100 --no-pagerGhi múi giờ khi đối chiếu client, proxy và database. -b trong ví dụ xem boot hiện tại; khả năng xem boot cũ phụ thuộc log có được lưu bền vững hay không. Log trống của một lần boot trước không tự chứng minh lần đó không có sự kiện.
Lọc theo khoảng xảy ra lỗi
sudo journalctl --since "2026-10-06 08:00:00" --until "2026-10-06 08:30:00" --no-pagerNgày giờ là minh họa; thay bằng khoảng thực tế theo múi giờ hệ thống. Bắt đầu khoảng hẹp để tránh output quá lớn, sau đó mở rộng trước/sau lỗi. Giữ timestamp đầy đủ khi xuất log cho nhóm xử lý.
Lọc theo service và kernel
systemctl --failed
sudo journalctl -u nginx.service --since '1 hour ago' --no-pager
sudo journalctl -k -b --no-pagerThay nginx.service bằng unit có thật. SSH có thể dùng tên unit khác giữa distro; kiểm tra trước. journalctl -k giúp xem thông điệp kernel như lỗi thiết bị hoặc OOM khi chúng được ghi; cần đối chiếu thêm log ứng dụng.
| Triệu chứng | Nguồn cần xem |
|---|---|
| Không đăng nhập được | SSH, xác thực, firewall và console |
| Ứng dụng restart | Service manager, app và giới hạn tài nguyên |
| 502/504 | Nginx/proxy cùng upstream |
| OOM hoặc disk lỗi | Kernel, container và metric host |
| Database chậm | Database log, query/lock và pool |
| Backup thất bại | Job, storage, quyền và network |
Theo dõi live trong lúc thử
sudo journalctl -u nginx.service -fThoát theo dõi bằng Ctrl+C. Tránh để nhiều phiên xuất log vô hạn khi sự cố tạo lượng lớn sự kiện. Với Nginx, access/error log có thể nằm ở file cấu hình riêng; service journal không thay toàn bộ log request.
Đối chiếu, không kết luận từ một dòng
Một lỗi timeout có thể là hậu quả của database, không phải nguyên nhân ở proxy. Lập timeline: tải tăng, queue, restart, truy vấn lỗi và response client. Ghép request ID khi ứng dụng có hỗ trợ, nhưng che thông tin định danh không cần thiết khi chia sẻ.
Đăng nhập lỗi có thể là quét tự động; đăng nhập thành công từ IP lạ cần điều tra nhưng IP không đủ xác định người dùng. Xem tài khoản, phương thức xác thực và hoạt động tiếp theo trước khi kết luận bị xâm nhập.
Retention và dung lượng
journalctl --disk-usage
df -hCấu hình retention theo nhu cầu vận hành và dung lượng. Không vacuum/xóa log lúc đang điều tra chỉ để giảm disk usage mà chưa giữ bản cần thiết. Log tập trung ngoài host giúp giảm phụ thuộc máy bị mất hoặc bị chỉnh log.
Quyền đọc log có thể cho thấy dữ liệu người dùng, token hoặc nội dung request. Chỉ cấp cho người cần, kiểm soát thời gian lưu và sửa ứng dụng nếu nó ghi secret. Bản log đã lọt ra ngoài cần xử lý secret liên quan.
Checklist gửi hỗ trợ
- Mô tả thời điểm, múi giờ và ảnh hưởng.
- Gửi phiên bản/service liên quan.
- Trích khoảng log cần thiết trước và sau lỗi.
- Che token, password, session và dữ liệu riêng.
- Ghi các thay đổi đã thực hiện.
- Giữ bản gốc trong nơi có quyền kiểm soát.
Khi thuê VPS, log guest OS là dữ liệu bổ trợ cho việc kiểm tra host/network. Hỏi rõ phạm vi hỗ trợ và không gửi toàn bộ dump nếu chỉ cần một khoảng log.
Journal có lưu qua reboot không?
Tùy cấu hình và nơi lưu. Kiểm tra boot có sẵn và cấu hình journald; không mặc định luôn persistent.
Không thấy lỗi journal nghĩa ứng dụng bình thường?
Không. Ứng dụng có thể ghi file/container hoặc không ghi đủ; cần kiểm tra metric và chức năng.
Cần máy chủ cho workload này?
NOC thuemaychu.vn hỗ trợ chọn CPU, GPU và băng thông. PoC trong 24 giờ.
Bài viết liên quan
Bảo mậtChống DDoS cho máy chủ dedicated: lớp L3/L4/L7 thực tế
Phân biệt chống nghẽn đường truyền và chống quá tải ứng dụng; xác định trách nhiệm nhà cung cấp và đội vận hành.
Cloud VPSDedicated Server hay VPS: khi nào nên thuê máy chủ riêng?
Chọn VPS hay dedicated dựa trên tải, giới hạn dịch vụ, ngân sách và yêu cầu kiểm soát; không mặc định mọi doanh nghiệp cần máy vật lý.
Cloud VPSVPS chậm: chẩn đoán CPU, RAM, disk và network
VPS chậm không luôn do gói cấu hình quá nhỏ. Truy vấn database, thiếu RAM, chờ storage, giới hạn CPU hoặc mạng bên ngoài đều có thể tạo cùng triệu chứng. Hãy đo ở đúng thời điểm lỗi trước khi restart hoặc nâng cấp.