2 Giờ Sáng và Server Bạn Đã Chậm Ba Tiếng Trước
Cảnh báo monitoring kích hoạt lúc 11 giờ đêm. Thời gian phản hồi tăng vọt. Người dùng phàn nàn. Đến khi bạn SSH vào, mọi thứ trông ổn hết — CPU idle 90%, load average bình thường. Sự cố qua đi, nhưng bạn chẳng biết nguyên nhân là gì.
Đây chính xác là lúc sysstat cứu bạn. Không như top hay htop, sysstat không chỉ hiển thị những gì đang xảy ra lúc này. Nó liên tục thu thập dữ liệu hiệu năng nền — mức dùng CPU, I/O đĩa, bộ nhớ, mạng — và lưu trữ lại theo lịch sử. Khi sự cố xảy ra lúc 11 giờ đêm và bạn nhìn vào lúc 2 giờ sáng, bạn vẫn có thể quay lại và xem chính xác điều gì đã xảy ra.
Tôi đã bị dính đòn bởi những đợt chậm bất thường trên server Ubuntu 22.04 production 4GB RAM nhiều lần hơn mức tôi muốn thừa nhận. Khi thiết lập sysstat đúng cách, tôi cuối cùng có dữ liệu forensic để xác định nguyên nhân — một cron job đang đập nát I/O đĩa vào các khoảng thời gian cụ thể.
Bối cảnh & Lý do: Sysstat Thực Sự Làm Gì
Sysstat là bộ công cụ giám sát hiệu năng cho Linux. Ba công cụ bạn sẽ dùng nhiều nhất là:
- sar (System Activity Reporter) — công cụ chính. Báo cáo CPU, bộ nhớ, I/O, mạng và nhiều hơn nữa từ các file dữ liệu lịch sử.
- iostat — tập trung vào thống kê CPU và I/O đĩa. Rất hữu ích để xác định thiết bị lưu trữ đang bị thắt cổ chai.
- mpstat — thống kê theo từng CPU. Giúp phát hiện nếu một nhân đang chạy hết công suất trong khi những nhân khác nhàn rỗi (phổ biến với các tiến trình đơn luồng).
Vũ khí bí mật ở đây là sadc (System Activity Data Collector). Nó chạy như một cron job mặc định mỗi 10 phút, ghi các file dữ liệu nhị phân vào /var/log/sysstat/. Các file này là cỗ máy thời gian của bạn — truy vấn bất kỳ khoảng thời gian nào trong 28 ngày qua.
Quy trình chẩn đoán rất đơn giản: cảnh báo kích hoạt, bạn SSH vào, mọi thứ trông ổn. Sau đó bạn kéo sar lên cho đúng khoảng thời gian của sự cố và xem những gì thực sự đang xảy ra. Không cần đoán mò.
Cài đặt
Trên các hệ thống Debian/Ubuntu:
sudo apt update
sudo apt install sysstat -yTrên RHEL/CentOS/AlmaLinux:
sudo dnf install sysstat -yCó một điều cần lưu ý: việc thu thập dữ liệu bị tắt theo mặc định trên hầu hết các bản Debian/Ubuntu sau khi cài. Bạn cần bật lên:
# Trên Debian/Ubuntu — chỉnh sửa cấu hình sysstat
sudo nano /etc/default/sysstatThay ENABLED="false" thành ENABLED="true", rồi lưu lại.
# Khởi động và kích hoạt dịch vụ sysstat
sudo systemctl enable sysstat
sudo systemctl start sysstat
# Kiểm tra xem có đang chạy không
sudo systemctl status sysstatTrên các hệ thống dựa trên RHEL, dịch vụ tự kích hoạt sau khi cài. Xác nhận bằng cách kiểm tra xem cron job có tồn tại không:
ls /etc/cron.d/sysstat
cat /etc/cron.d/sysstatCấu hình
Điều chỉnh chu kỳ thu thập
Khoảng thời gian mặc định 10 phút ổn cho dùng thông thường. Với server production có khối lượng công việc tăng đột biến, giảm xuống 2 phút — bạn có độ phân giải tốt hơn nhiều khi xảy ra sự cố mà không tốn tài nguyên đáng kể.
Chỉnh sửa file cron:
sudo nano /etc/cron.d/sysstatThay entry mặc định từ:
# Chạy công cụ ghi nhận hoạt động hệ thống mỗi 10 phút
*/10 * * * * root command -v debian-sa1 > /dev/null && debian-sa1 1 1Thành:
# Thu thập dữ liệu mỗi 2 phút
*/2 * * * * root command -v debian-sa1 > /dev/null && debian-sa1 1 1Giữ dữ liệu lâu hơn
Mặc định lưu giữ 7 ngày. Với server production, 28 ngày cho bạn một tháng đầy đủ lịch sử — hữu ích để phát hiện các mẫu theo tuần hoặc xem lại sự cố bạn chưa kịp điều tra.
sudo nano /etc/sysstat/sysstatTìm và cập nhật:
HISTORY=28Dữ liệu nào được thu thập
Dữ liệu nằm trong /var/log/sysstat/ dưới dạng file nhị phân hàng ngày tên sa01, sa12, v.v. (ngày trong tháng). Liệt kê bằng:
ls -lh /var/log/sysstat/Dung lượng lưu trữ rất nhỏ. Trên server Ubuntu 4GB RAM của tôi với chu kỳ 2 phút, mỗi file hàng ngày dưới 2MB. Một tháng lịch sử đầy đủ tốn chưa đến 60MB — cái giá nhỏ để có khả năng điều tra bất kỳ sự cố nào trong bốn tuần qua.
Xác minh & Giám sát
Dùng sar để tái hiện sự cố
Tình huống điển hình: có sự cố tối qua và bạn cần biết chuyện gì đã xảy ra. Truy vấn sar với một khoảng thời gian cụ thể:
# Mức dùng CPU hôm nay từ 10 giờ tối đến nửa đêm
sar -u -s 22:00:00 -e 00:00:00
# Kiểm tra ngày cụ thể (ví dụ: ngày 10 trong tháng này)
sar -u -s 22:00:00 -e 00:00:00 -f /var/log/sysstat/sa10Flag -u báo cáo mức sử dụng CPU. Các cột quan trọng cần theo dõi:
%user— mức dùng CPU ở không gian người dùng%system— mức dùng CPU của kernel (giá trị cao cho thấy vấn đề I/O hoặc syscall)%iowait— thời gian chờ I/O (liên tục trên 20% là dấu hiệu đáng lo ngại)%idle— dung lượng CPU còn trống
# Lịch sử sử dụng bộ nhớ
sar -r -s 22:00:00 -e 00:00:00
# Sử dụng swap (quan trọng cho server 4GB RAM)
sar -S -s 22:00:00 -e 00:00:00Dùng iostat để phân tích I/O đĩa
%iowait cao trong sar cho biết có gì đó đang bị chặn bởi đĩa. iostat cho bạn biết thiết bị nào và mức độ nghiêm trọng ra sao:
# Thời gian thực: cập nhật mỗi 2 giây, hiển thị thống kê mở rộng
iostat -x 2 5
# Tập trung vào một thiết bị cụ thể
iostat -x sda 2 5Các cột quan trọng trong output của iostat -x:
await— thời gian trung bình (ms) cho các request I/O. Trên 100ms với HDD hoặc 20ms với SSD là đáng điều tra.%util— mức sử dụng thiết bị. Gần 100% nghĩa là đĩa đang bão hòa.r/svàw/s— số lần đọc và ghi mỗi giây.
Để lấy dữ liệu I/O lịch sử, quay lại sar:
# Lịch sử I/O đĩa
sar -d -s 22:00:00 -e 00:00:00 -f /var/log/sysstat/sa10Dùng mpstat để phân tích từng CPU
CPU tổng thể ở 40% không có nghĩa là mọi thứ đều ổn. Một tiến trình đơn luồng có thể ghim một nhân lên 100% trong khi phần còn lại nhàn rỗi — và server bạn chạy chậm như rùa. mpstat sẽ phát hiện điều này:
# Hiển thị tất cả CPU, cập nhật mỗi 2 giây
mpstat -P ALL 2 5Trên server production của tôi, lệnh này phát hiện một PHP-FPM worker đang ghim CPU0 lên 100% trong giờ cao điểm trong khi CPU1, CPU2 và CPU3 nhàn rỗi. Giải pháp là điều chỉnh số lượng worker PHP-FPM và process affinity. Chỉ dùng top thì tôi không bao giờ tìm ra được.
Để lấy dữ liệu lịch sử từng CPU:
# Dữ liệu CPU lịch sử chia theo từng nhân
sar -P ALL -s 22:00:00 -e 00:00:00 -f /var/log/sysstat/sa10Quy trình điều tra sự cố thực tế
Năm lệnh. Đây là chuỗi lệnh tôi thực sự chạy khi điều tra sự cố hiệu năng trong quá khứ:
# Bước 1: Tìm đỉnh — tổng quan CPU cả ngày
sar -u -f /var/log/sysstat/sa10 | grep -v "^$"
# Bước 2: Thu hẹp khoảng thời gian sau khi thấy đỉnh
sar -u -s 22:30:00 -e 23:30:00 -f /var/log/sysstat/sa10
# Bước 3: Kiểm tra bộ nhớ — RAM có đầy gây swap thrashing không?
sar -r -s 22:30:00 -e 23:30:00 -f /var/log/sysstat/sa10
# Bước 4: Kiểm tra I/O đĩa — có gì đó đang ghi quá nặng không?
sar -d -s 22:30:00 -e 23:30:00 -f /var/log/sysstat/sa10
# Bước 5: Kiểm tra mạng — có đỉnh lưu lượng không?
sar -n DEV -s 22:30:00 -e 23:30:00 -f /var/log/sysstat/sa10Báo cáo tóm tắt nhanh
Cần xem tất cả cùng lúc? sar -A xuất báo cáo đầy đủ trong ngày — CPU, bộ nhớ, swap, I/O, mạng — trong một output có thể cuộn:
# Báo cáo đầy đủ cho file dữ liệu của ngày cụ thể
sar -A -f /var/log/sysstat/sa10 | lessHữu ích để xem xét cuối ngày hoặc khi bàn giao sự cố cho đồng nghiệp không online trong lúc xảy ra.
Một Điều Cuối Về Thu Thập Dữ Liệu
Mới cài xong? Bạn sẽ chưa có dữ liệu lịch sử — cần thời gian để xây dựng kho lưu trữ. Hãy kích hoạt thu thập đầu tiên thủ công để xác nhận mọi thứ đã được kết nối đúng:
# Kích hoạt thu thập dữ liệu ngay lập tức
sudo /usr/lib/sysstat/debian-sa1 1 1
# Xác minh dữ liệu đang được ghi
ls -lh /var/log/sysstat/sa$(date +%d)File có kích thước khác không nghĩa là sysstat đang thu thập dữ liệu đúng cách.
Chạy sar không có flag nào sẽ hiển thị dữ liệu CPU của ngày hiện tại — kiểm tra nhanh trước khi sự cố 2 giờ sáng tiếp theo ập đến.
