Khi làm việc với Linux, đặc biệt là quản lý máy chủ (server), chắc chắn bạn sẽ gặp phải những sự cố “khó nhằn”. Một dịch vụ không chạy, ứng dụng bỗng dưng dừng lại, hay cả hệ thống trở nên ì ạch không rõ nguyên nhân. Khi mọi thứ không như ý, điều đầu tiên chúng ta cần làm là tìm hiểu “tại sao”. Và lúc đó, các công cụ ghi log mạnh mẽ như journalctl và dmesg sẽ phát huy tác dụng.
Trong bài viết này, tôi sẽ chia sẻ cách sử dụng hiệu quả hai công cụ này để gỡ lỗi trên môi trường Linux. Mục tiêu là giúp các bạn, đặc biệt là những người mới học IT, có một phương pháp tiếp cận hệ thống khi đối mặt với các vấn đề trên server.
So sánh các phương pháp đọc log: Truyền thống, journalctl và dmesg
Trước khi đi sâu vào từng công cụ, hãy cùng xem lại cách các file log được quản lý trên Linux, và lý do journalctl cùng dmesg ra đời.
Phương pháp đọc log truyền thống (/var/log)
Ngày mới tập tành Linux, mỗi khi có lỗi, tôi thường cd /var/log rồi dùng grep tìm kiếm trong các file như syslog, auth.log, kern.log, messages… Đây là cách cơ bản, nhưng vẫn hữu ích trong nhiều trường hợp. Các file log này thường do rsyslog hoặc syslog-ng quản lý, là các file văn bản thuần túy dễ đọc bằng cat, less, tail và grep.
cat /var/log/syslog | grep "error"
tail -f /var/log/nginx/access.log
Ưu điểm: Đơn giản, dễ hiểu, dễ làm việc với các công cụ xử lý văn bản có sẵn.
Nhược điểm: Log phân tán (mỗi dịch vụ/loại log có thể nằm ở một file riêng), không có cấu trúc thống nhất. Điều này gây khó khăn khi lọc và tìm kiếm hiệu quả, đặc biệt trên các hệ thống bận rộn với lượng log khổng lồ.
journalctl: Nhật ký hệ thống tập trung của Systemd
Với sự xuất hiện của Systemd – một hệ thống khởi tạo (init system) và quản lý dịch vụ hiện đại – cách quản lý log đã thay đổi đáng kể. journalctl là công cụ để đọc và quản lý Systemd Journal, một hệ thống log tập trung. Thay vì ghi ra nhiều file riêng lẻ, Systemd thu thập log từ kernel, các dịch vụ, ứng dụng, rồi ghi vào một cơ sở dữ liệu nhị phân.
Ưu điểm:
- Tập trung: Mọi log từ nhiều nguồn đều được gom về một nơi duy nhất.
- Có cấu trúc: Log được lưu trữ dạng có cấu trúc, giúp việc lọc và tìm kiếm cực kỳ mạnh mẽ và nhanh chóng.
- Giữ nguyên ngữ cảnh: Log của một dịch vụ luôn đi kèm thông tin đầy đủ về dịch vụ đó (PID, Unit name, v.v.).
- Hỗ trợ boot-specific: Dễ dàng xem log của các lần khởi động (boot) trước đó.
- Persistence: Có thể cấu hình để log được lưu trữ vĩnh viễn qua các lần khởi động.
Nhược điểm:
- Log lưu dưới dạng nhị phân, không thể đọc trực tiếp bằng
cathaygrepmà phải dùngjournalctl. - Với người mới, cú pháp
journalctlcó thể hơi “rắc rối” với nhiều tùy chọn.
dmesg: Thông điệp từ Kernel Ring Buffer
dmesg (display message) là công cụ hiển thị các thông điệp từ Kernel Ring Buffer. Đây là nơi kernel hệ điều hành ghi lại các sự kiện liên quan đến quá trình khởi động, nhận diện phần cứng, lỗi driver, hoặc các thông báo quan trọng khác từ kernel. Log của dmesg thường là những thông tin đầu tiên bạn cần kiểm tra khi gặp sự cố phần cứng, driver, hoặc những lỗi xảy ra rất sớm trong quá trình khởi động hệ thống.
Ưu điểm:
- Trực tiếp từ kernel: Cung cấp thông tin quan trọng về phần cứng, driver và các lỗi ở cấp độ kernel.
- Có sẵn ngay cả khi hệ thống gặp sự cố nghiêm trọng: Thông tin từ kernel ring buffer thường vẫn truy cập được ngay cả khi các dịch vụ khác chưa hoạt động ổn định hoặc bị lỗi.
Nhược điểm:
- Chỉ hiển thị log từ kernel, không bao gồm log từ các ứng dụng hay dịch vụ người dùng.
- Không có tính năng lưu trữ lịch sử log dài hạn theo mặc định (nội dung ring buffer bị ghi đè khi đầy).
- Đầu ra có thể khó đọc nếu không được lọc hoặc định dạng lại.
Chọn công cụ phù hợp: Khi nào dùng journalctl, khi nào dùng dmesg?
Việc lựa chọn đúng công cụ sẽ giúp bạn tiết kiệm rất nhiều thời gian khi gỡ lỗi. Tôi thường áp dụng quy tắc sau:
- Bắt đầu với
journalctl: Đối với phần lớn các vấn đề liên quan đến dịch vụ (như web server Nginx, cơ sở dữ liệu PostgreSQL, SSH), ứng dụng, hoặc các lỗi hệ thống chung chung, hãy bắt đầu tìm kiếm trongjournalctl. Đây là nguồn log tập trung và phong phú nhất. - Chuyển sang
dmesgkhi cần: Nếujournalctlhiển thị các lỗi liên quan đến kernel, phần cứng (ví dụ: lỗi ổ cứng, card mạng, RAM), driver, hoặc nếu hệ thống gặp sự cố ngay từ lúc khởi động màjournalctlkhông cung cấp đủ thông tin, thì đó là lúcdmesgsẽ phát huy tác dụng.
Hướng dẫn triển khai: Gỡ lỗi với journalctl và dmesg
Bây giờ, chúng ta sẽ đi sâu vào cách sử dụng từng công cụ với các ví dụ thực tế.
Gỡ lỗi với journalctl
journalctl là một công cụ cực kỳ linh hoạt. Dưới đây là những lệnh cơ bản và nâng cao tôi thường sử dụng:
1. Xem toàn bộ nhật ký hệ thống
Lệnh đơn giản nhất để xem tất cả các log đã được Systemd Journal thu thập:
journalctl
Kết quả sẽ hiển thị trong một trình xem văn bản (pager) như less, cho phép bạn cuộn lên xuống thoải mái.
2. Xem nhật ký mới nhất và theo dõi thời gian thực
Để xem các log mới nhất và tiếp tục theo dõi log đến trong thời gian thực (tương tự như tail -f):
journalctl -f
Lệnh này cực kỳ hữu ích khi bạn muốn kiểm tra ngay lập tức tác động của một thay đổi cấu hình hoặc sau khi khởi động lại một dịch vụ.
3. Xem nhật ký của một dịch vụ cụ thể
Khi một dịch vụ không hoạt động như mong đợi, bạn cần xem log riêng của nó. Ví dụ, để xem log của Nginx:
journalctl -u nginx.service
Hoặc của dịch vụ SSH:
journalctl -u ssh.service
Bạn có thể kết hợp với -f để theo dõi log của dịch vụ đó theo thời gian thực: journalctl -u nginx.service -f.
4. Lọc nhật ký theo thời gian
Đây là một trong những tính năng mạnh nhất của journalctl. Bạn có thể lọc log theo thời gian bắt đầu (--since hoặc -S) và thời gian kết thúc (--until hoặc -U).
Để xem log từ 1 giờ trước:
journalctl -S "1 hour ago"
Để xem log từ đầu ngày hôm nay:
journalctl -S "today"
Để xem log giữa một khoảng thời gian cụ thể:
journalctl -S "2026-03-24 10:00:00" -U "2026-03-24 10:30:00"
5. Xem nhật ký của các lần khởi động trước
Khi gặp sự cố sau khi khởi động lại server, bạn có thể muốn xem log của lần khởi động trước đó.
Xem danh sách các lần khởi động:
journalctl --list-boots
Xem log của lần khởi động trước (-1 là lần gần nhất, -2 là lần trước đó nữa):
journalctl -b -1
Kinh nghiệm cá nhân: Trên server production Ubuntu 22.04 với 4GB RAM mà tôi đang quản lý, việc sử dụng journalctl -b -1 -u myapp.service -S "20 minutes ago" khi debug một lỗi service sau khi reboot đã giúp tôi giảm đáng kể thời gian xử lý sự cố. Thay vì đọc qua hàng trăm, thậm chí hàng ngàn dòng log không liên quan, tôi có thể tập trung ngay vào những thông tin cần thiết của dịch vụ đó trong khoảng thời gian cụ thể.
6. Lọc theo mức độ ưu tiên (priority)
Bạn có thể lọc log theo mức độ ưu tiên, từ gỡ lỗi (debug) đến cảnh báo khẩn cấp (emergency).
Chỉ hiển thị các lỗi (error):
journalctl -p err
Chỉ hiển thị các cảnh báo (warning) và lỗi:
journalctl -p warning..err
Các mức độ ưu tiên theo thứ tự từ nghiêm trọng nhất đến ít nghiêm trọng nhất: 0 (emerg), 1 (alert), 2 (crit), 3 (err), 4 (warning), 5 (notice), 6 (info), 7 (debug).
7. Đảm bảo nhật ký lưu trữ vĩnh viễn (Persistent Logging)
Mặc định, trên một số bản phân phối Linux (như Ubuntu), Systemd Journal chỉ lưu log tạm thời trong RAM (volatile). Điều này có nghĩa là log sẽ bị mất sau khi khởi động lại. Để log được lưu trữ vĩnh viễn, bạn cần tạo thư mục:
sudo mkdir -p /var/log/journal
sudo systemctl restart systemd-journald
Sau khi tạo thư mục này, Systemd Journal sẽ tự động lưu log vào /var/log/journal, đảm bảo bạn có thể xem lại log của các lần khởi động trước mà không bị mất dữ liệu.
Gỡ lỗi với dmesg
dmesg có cú pháp đơn giản hơn journalctl, nhưng thông tin nó cung cấp lại rất độc đáo và chuyên biệt.
1. Xem toàn bộ thông điệp kernel
Lệnh cơ bản để xem toàn bộ nội dung của kernel ring buffer:
dmesg
Vì đầu ra thường rất dài, bạn nên kết hợp nó với less hoặc grep để dễ đọc hơn:
dmesg | less
dmesg | grep -i "error"
dmesg | grep -i "usb"
2. Định dạng dễ đọc hơn với -H
Tùy chọn -H (human-readable) giúp định dạng đầu ra của dmesg rõ ràng hơn, có màu sắc và hiển thị thời gian tương đối dễ hiểu. Đây là tùy chọn tôi thường dùng nhất.
dmesg -H
Khi kết hợp với less, bạn sẽ có trải nghiệm đọc log kernel tốt hơn rất nhiều:
dmesg -H | less
3. Xem các thông điệp mới nhất
Để xem các thông điệp kernel mới nhất, bạn có thể dùng lệnh sau:
dmesg --follow
Lệnh này sẽ hiển thị liên tục các thông điệp mới khi chúng được ghi vào kernel ring buffer, rất tiện lợi để theo dõi sự kiện trực tiếp.
4. Kiểm tra sự kiện phần cứng
Khi gặp vấn đề với ổ cứng, card mạng, hoặc các thiết bị USB, dmesg là nơi đầu tiên bạn nên kiểm tra. Ví dụ, để xem các thông điệp liên quan đến ổ cứng SATA:
dmesg | grep -i "ata"
Hoặc về các thiết bị USB:
dmesg | grep -i "usb"
Kết luận
Việc thành thạo journalctl và dmesg là một bước tiến quan trọng trong hành trình trở thành một kỹ sư hệ thống hay DevOps chuyên nghiệp. Hai công cụ này, dù có mục đích và cách hoạt động khác nhau, nhưng lại bổ trợ rất tốt cho nhau trong việc chẩn đoán và khắc phục sự cố trên Linux. journalctl cung cấp cái nhìn tổng thể, chi tiết về hoạt động của các dịch vụ và ứng dụng, trong khi dmesg là “tai mắt” của bạn ở cấp độ kernel, giúp phát hiện các vấn đề phần cứng tiềm ẩn.
Hãy thực hành thường xuyên với các lệnh đã được tôi giới thiệu. Bạn sẽ thấy việc gỡ lỗi trên Linux không còn là một thử thách đáng sợ nữa, mà trở thành một kỹ năng quan trọng, giúp bạn quản lý server một cách tự tin và hiệu quả hơn. Chúc các bạn thành công!
