File log là gì? Đọc log máy chủ để tìm nguyên nhân sự cố

Tóm tắt nhanh: File log là cuốn sổ nhật ký tự động ghi lại mọi hoạt động, sự kiện hoặc cảnh báo trên máy chủ theo trình tự thời gian. Khi hệ thống gặp sự cố, log chính là bằng chứng quan trọng nhất để khoanh vùng nguyên nhân. Việc hiểu file log là gì và biết cách tìm đúng chỗ đọc log sẽ giúp bạn xử lý vấn đề chuẩn xác, thay vì thao tác theo kiểu phỏng đoán. Bài viết này trên cloudmoon.net sẽ hướng dẫn bạn quy trình chẩn đoán sự cố thông qua log máy chủ, giúp bạn làm chủ hệ thống hiệu quả hơn.

1. File log là gì và log giúp chẩn đoán thế nào

File log là gì? Nói một cách đơn giản, file log là tập tin chứa các bản ghi sự kiện (event) do hệ điều hành, dịch vụ nền, ứng dụng phần mềm hoặc luồng truy cập mạng tự động tạo ra. Hầu hết bản ghi log có mốc thời gian, và các dòng thường được nối vào theo thứ tự xảy ra; output ứng dụng hoặc nhiều tiến trình có thể không giữ đủ thứ tự. Hãy hình dung log máy chủ giống như chiếc hộp đen của máy bay hoặc camera an ninh; nó cần mẫn ghi lại những gì đã xảy ra trước, trong và sau khi sự cố xuất hiện.

Cấu trúc tiêu chuẩn của một dòng log thường bao gồm: thời gian xảy ra sự kiện, mức độ nghiêm trọng (thông tin, cảnh báo, lỗi), thành phần gây ra sự kiện và thông báo chi tiết. Sự minh bạch này giúp quản trị viên theo dõi sát sao sức khỏe hệ thống.

Tuy nhiên, bạn cần nhớ một nguyên tắc quan trọng: log là bằng chứng để chẩn đoán, không phải là kết luận tự động về nguyên nhân gốc rễ. Một dòng lỗi hiển thị trong file log thường chỉ là phần ngọn, hoặc là hậu quả của một chuỗi sự cố khác. Ví dụ, log báo không thể lưu file có thể xuất phát từ việc ổ cứng đã đầy, chứ không phải do đoạn mã lưu file bị hỏng. Do đó, chẩn đoán lỗi luôn đòi hỏi sự kết hợp giữa việc đọc log server và kiểm tra trạng thái thực tế của máy chủ.

2. Những loại log thường gặp trên máy chủ

Máy chủ là một môi trường phức tạp với hàng chục phần mềm chạy ngầm cùng lúc. Tùy thuộc vào thiết kế, các loại log thường được phân loại thành ba nhóm chức năng chính:

• Log hệ thống (System log): Ghi lại các sự kiện ở mức độ hệ điều hành. Chúng bao gồm tiến trình khởi động máy, sự giao tiếp giữa phần cứng và hạt nhân, dịch vụ nền bị tắt đột ngột, hoặc thông báo tràn RAM.
• Log ứng dụng (Application log): Mỗi phần mềm cài đặt trên máy chủ thường tự tạo ra khu vực lưu trữ log riêng. Đó có thể là log của web server, cơ sở dữ liệu, hoặc chính đoạn mã nguồn mà bạn lập trình.
• Log bảo mật (Security log): Lưu vết các hành vi liên quan đến quyền và xác thực. Chúng bao gồm nỗ lực đăng nhập thành công hay thất bại, quá trình xác thực, hoặc thao tác thay đổi cấu hình bảo mật.
• Access log: Ghi yêu cầu vào web server, thường có IP, giờ, đường dẫn, mã phản hồi, dung lượng và trình duyệt; thời gian xử lý chỉ có khi cấu hình thêm.
• Audit hoặc log thay đổi: Ghi thao tác quản trị và thay đổi cấu hình để đối chiếu.

3. Quy trình 5 bước đọc log khi có sự cố

Khi một website không truy cập được hoặc hệ thống ngừng phản hồi, việc lao vào mở ngẫu nhiên một file log sẽ làm bạn mất phương hướng. Hãy áp dụng quy trình 5 bước sau:

1. Xác định mốc thời gian: Sự cố xảy ra lúc nào? Trước khi đọc log, bạn phải biết chắc chắn múi giờ (timezone) hiện tại của máy chủ. Máy chủ có thể dùng UTC; ở Việt Nam là UTC+7, nên khách báo lỗi lúc 21:00 thì hãy tìm quanh 14:00 trong log. Dùng timedatectl để xem.
2. Tìm đúng nguồn log: Sự cố đang ảnh hưởng đến thành phần nào? Nếu website báo lỗi 500, hãy ưu tiên kiểm tra log web server. Nếu đăng nhập SSH bị từ chối vì sai mật khẩu hoặc khóa, xem log xác thực. Nếu báo Connection refused, kiểm tra dịch vụ và tường lửa; xem firewall trên VPS.
3. Lọc theo dịch vụ và mức độ: Hãy dùng các công cụ tìm kiếm hoặc bộ lọc để trích xuất các dòng chứa từ khóa báo lỗi trong đúng khung thời gian đã xác định.
4. Đối chiếu với tài nguyên: Kết hợp thông tin đọc được với hệ thống giám sát tài nguyên VPS. Nhiều sự cố phần mềm thực chất xuất phát từ việc CPU hay RAM bị quá tải.
5. Mở rộng khung thời gian: Khi tìm thấy dòng lỗi, đừng vội dừng lại. Hãy đọc lùi về trước đó 5 đến 15 phút. Bạn cần tìm hiểu bối cảnh dẫn đến dòng báo lỗi cuối cùng.

4. Đọc log Linux với journalctl và /var/log

Trên môi trường hệ điều hành Linux, quá trình ghi log thường được xử lý qua hai hệ thống cơ bản, yêu cầu cách tiếp cận khác nhau.

Truy vấn qua lệnh journalctl

Đa số các hệ điều hành Linux hiện đại sử dụng trình quản lý systemd. Systemd thu thập toàn bộ log hệ thống vào một dịch vụ trung tâm tên là journald. Vì journald lưu dữ liệu dưới định dạng nhị phân, bạn không thể dùng lệnh xem văn bản thông thường, mà bắt buộc phải dùng công cụ journalctl.

Sức mạnh của journalctl nằm ở khả năng truy vấn linh hoạt. Bạn có thể dễ dàng yêu cầu máy chủ chỉ hiển thị log của một dịch vụ cụ thể trong khoảng thời gian từ sáng qua đến hôm nay. Việc lọc dữ liệu tinh gọn này giúp quản trị viên tiết kiệm rất nhiều công sức.

Thư mục /var/log truyền thống

Dù journald rất phổ biến, nhiều phần mềm lõi vẫn tiếp tục ghi log trực tiếp ra file văn bản thuần túy. Hầu hết các tập tin này được gom chung về thư mục /var/log. Tại đây, bạn có thể tìm thấy file log xác thực bảo mật hoặc log cập nhật phần mềm.

Tuy nhiên, một quy tắc tối quan trọng là: đường dẫn chính xác và tên tập tin log sẽ thay đổi tùy thuộc vào bản phân phối Linux và cấu hình ban đầu. Sẽ không có một đường dẫn cứng nhắc nào đúng cho mọi máy chủ.

5. Đọc log Windows Server bằng Event Viewer

Nếu hệ thống của bạn chạy trên Windows Server, công cụ quản lý log cốt lõi là Event Viewer. Khác với dòng lệnh trên Linux, Event Viewer cung cấp giao diện đồ họa trực quan, phân chia log theo cấu trúc cây.

Windows phân loại sự kiện thành các nhóm Windows Logs chính: System (hệ thống), Application (ứng dụng), và Security (bảo mật). Mỗi bản ghi trong Event Viewer đều được gắn một mã số gọi là Event ID.

Nhiều người có thói quen chép Event ID lên mạng để tìm cách sửa lỗi. Tuy nhiên, bạn cần hết sức thận trọng: ý nghĩa của Event ID phụ thuộc hoàn toàn vào ngữ cảnh và ứng dụng tạo ra nó. Event ID 1000 của phần mềm kế toán có ý nghĩa hoàn toàn khác biệt so với Event ID 1000 của dịch vụ sao lưu dữ liệu. Do đó, đừng bao giờ áp dụng máy móc một mã lỗi cho mọi trường hợp.

6. Access log và error log của web server

Với các dịch vụ lưu trữ website, máy chủ web là thành phần sống còn. Nếu bạn đang tìm hiểu Nginx là gì, bạn sẽ thấy nó duy trì song song hai tệp log khác nhau để phục vụ các mục đích chuyên biệt.

Access log (Log truy cập)

Đây là tập tin lưu lại mọi yêu cầu từ thiết bị của người dùng gửi đến máy chủ. Một dòng access log thông thường sẽ cung cấp các biến số (variables) như: địa chỉ IP của người truy cập, đường dẫn URI họ yêu cầu, mã trạng thái HTTP trả về, và thời gian xử lý mất bao lâu. Access log rất hữu ích để nhận diện hành vi bất thường hoặc đo lường hiệu suất trang web.

Error log (Log lỗi)

Ngược lại, error log chỉ ghi nhận những sự cố phát sinh từ bên trong. Nếu website hiển thị trang trắng hoặc từ chối khởi động sau khi sửa cấu hình, nguyên nhân gốc rễ luôn nằm ở đây. Error log chỉ ra chính xác dòng cấu hình sai hoặc vấn đề kết nối nội bộ.

7. Ví dụ ghép mốc thời gian với mã lỗi và tài nguyên

Để hiểu rõ giá trị của file log, hãy xem một kịch bản thực tế. Giả sử website của bạn báo lỗi "502 Bad Gateway" với khách hàng vào lúc 14:00.

Đầu tiên, bạn mở error log của web server và thấy báo lỗi không thể kết nối với upstream lúc 14:00:02. Tiếp theo, bạn dùng journalctl truy vấn log hệ thống, phát hiện bộ nhớ cạn khiến hệ điều hành dừng một tiến trình PHP-FPM hoặc ứng dụng phía sau.

Lúc này, bạn kết hợp kiểm tra biểu đồ RAM hoặc chạy free -h và thấy bộ nhớ đã chạm ngưỡng trước đó. Chuỗi thời gian là RAM cạn trước, tiến trình ứng dụng bị dừng, rồi web server báo 502 vì không còn upstream. Hãy xem thêm giám sát tài nguyên VPS trước khi gọi đó là nguyên nhân cuối cùng.

8. Sai lầm, bảo mật và khi nào gửi hỗ trợ

Phân tích log mang lại quyền lực lớn, nhưng cũng tiềm ẩn rủi ro bảo mật nếu bạn bỏ qua các nguyên tắc cơ bản.

Xoay vòng log và phân quyền (Permissions)

Máy chủ hoạt động liên tục, đồng nghĩa file log sẽ không ngừng phình to. Để tránh việc log chiếm cạn ổ cứng, hệ thống sử dụng cơ chế xoay vòng log (rotation). Cơ chế này tự động nén file cũ và tạo file mới. Đồng thời, bạn phải kiểm soát quyền truy cập log thật chặt. Tuyệt đối không cấp quyền đọc file log nhạy cảm cho những tài khoản người dùng phổ thông.

Che giấu dữ liệu nhạy cảm (Redaction)

Bạn phải chủ động cấu hình phần mềm để che khuất (redact) dữ liệu nhạy cảm trước khi ghi ra file log. Các dữ liệu này bao gồm mật khẩu người dùng gõ sai, chuỗi khóa xác thực (token), cookie phiên làm việc, hay khóa bảo mật (private key). Một file log bị lộ có thể cho kẻ xấu biết máy bạn chạy gì, dữ liệu nằm ở đâu, thậm chí lộ token còn hạn. Vì vậy hãy giới hạn người được đọc log và che dữ liệu trước khi gửi đi.

Khi gửi yêu cầu hỗ trợ (Ticket)

Nếu bạn chưa rõ SSH là gì, không thể tự kết nối và cần gửi ticket hỗ trợ, hãy cung cấp ngữ cảnh rõ ràng. Bạn chỉ nên trích xuất đúng 10 đến 20 dòng log liên quan cùng với mốc thời gian báo lỗi.

Tuyệt đối tránh hai sai lầm sau: Không dán toàn bộ file log khổng lồ vào ô nội dung ticket. Và không bao giờ gửi nguyên vẹn đoạn log có chứa mật khẩu, token hay cookie bảo mật cho bộ phận hỗ trợ kỹ thuật.

9. Câu hỏi thường gặp

Thao tác nhanh khi cần đọc log

Các lệnh dưới đây chạy sau khi bạn vào máy chủ qua SSH. systemd là bộ quản lý dịch vụ, còn journald lưu nhật ký dạng nhị phân nên phải đọc bằng journalctl:

sudo journalctl -u ssh --since "2026-09-19 13:45" --until "2026-09-19 14:15"
sudo journalctl -p err -b
sudo journalctl -p err -b -1
sudo journalctl -f

-u lọc theo dịch vụ (họ Red Hat thường dùng sshd), -p err lấy lỗi và mức nặng hơn, còn -b chỉ lần khởi động hiện tại; -b -1 xem lần trước nếu journal được lưu bền. Nhấn Ctrl+C để thoát -f. Dùng timedatectl xem múi giờ; máy chủ UTC và người ở Việt Nam UTC+7 nghĩa là 21:00 giờ Việt Nam tương ứng khoảng 14:00 trong log.

Với file văn bản, tìm Ubuntu/Debian ở /var/log/syslog, /var/log/auth.log; AlmaLinux/Rocky ở /var/log/messages, /var/log/secure; Nginx ở /var/log/nginx/access.log, error.log. Không thấy tệp thì dùng journalctl.

sudo tail -n 50 <tệp>
sudo tail -f <tệp>
sudo grep " 502 " <access.log>
journalctl --since "2026-09-19 13:45" --until "2026-09-19 14:15"

Ví dụ minh họa, access log có IP, giờ và mã 502; error log ghi lỗi upstream:

203.0.113.10 - - [19/Sep/2026:14:00:02 +0700] "GET /checkout HTTP/1.1" 502 182 "-" "ExampleBrowser/1.0"
2026/09/19 14:00:02 [error] connect() failed while connecting to upstream

Nếu dùng hosting không có quyền root, xem access/error log trong control panel như cPanel hoặc CyberPanel, hoặc nhờ nhà cung cấp trích xuất theo khung giờ. Khi gửi hỗ trợ, ghi giờ UTC+7, dịch vụ, hiện tượng, thao tác đã thử và đoạn log đã che token. Nên gửi ticket khi không vào được máy chủ, có dấu hiệu lỗi phần cứng/ổ đĩa, sự cố lặp lại sau reboot hoặc nghi bị xâm nhập; đừng xóa log lúc đó.

Lời kết

Đọc file log là kỹ năng nền tảng để vận hành máy chủ bền vững. Từ việc hiểu file log là gì, nắm rõ công dụng của từng loại log, cho đến việc sử dụng thành thạo journalctl và Event Viewer, bạn đã có đủ cơ sở để đi thẳng vào gốc rễ sự cố. Không còn khởi động lại máy chủ một cách cảm tính. Nếu bạn đang chọn máy chủ, xem Cloud VPS trên cloudmoon.net và tính trước ngay từ đầu: ai được đọc log, log lưu ở đâu, giữ trong bao lâu.

Nguồn tham khảo

• Red Hat: Troubleshooting with log files
• Nginx: HTTP log module
• Microsoft Learn: Quản lý và giám sát nhật ký sự kiện Windows Server