Khi server gặp sự cố, bạn làm gì đầu tiên?
Server lỗi lúc 2 giờ sáng. Bạn SSH vào, bắt đầu chạy từng lệnh: journalctl, dmesg, netstat, df -h, top… mỗi cái một cửa sổ terminal, copy paste vào file text, gửi cho đồng nghiệp hoặc team support. Mình đã làm vậy nhiều lần, và lần nào cũng có thứ gì đó bị bỏ sót đúng lúc cần nhất.
Hồi CentOS 8 EOL, mình phải migrate gấp 5 server sang Rocky Linux trong 1 tuần. Một server gặp lỗi networking sau khi reboot — mình mất gần 2 tiếng chạy lệnh thủ công thu thập log trước khi tìm ra nguyên nhân: NetworkManager profile bị corrupt trong quá trình migration. Sau sự cố đó, mình mới học sosreport đúng nghĩa và nhận ra mình đã lãng phí thời gian như thế nào.
Ba cách thu thập thông tin hệ thống — và điểm khác biệt thực sự
Cách 1: Chạy lệnh thủ công từng cái một
Ai cũng bắt đầu từ đây — tự viết script hoặc chạy từng lệnh khi cần.
# Thu thập thủ công — mất thời gian, dễ bỏ sót
journalctl -xe > /tmp/journal.log
dmesg > /tmp/dmesg.log
ip addr show > /tmp/network.log
df -h > /tmp/disk.log
cat /etc/os-release > /tmp/os.log
ss -tlnp > /tmp/ports.log
# ... còn hàng chục lệnh nữa tùy vấn đề
Ưu điểm: Không cần cài thêm gì, linh hoạt chọn đúng thứ cần lấy, output gọn nhẹ.
Nhược điểm: Dễ bỏ sót thứ mình chưa nghĩ tới, mất thời gian khi hệ thống đang có vấn đề, output không chuẩn hóa nên khó chia sẻ với vendor hoặc đội kỹ thuật.
Cách 2: sosreport — công cụ chính thức của Red Hat
sosreport gói gọn cả quy trình vào một lệnh, theo đúng tiêu chuẩn Red Hat:
sudo sos report
Ưu điểm: Thu thập 200+ loại thông tin theo plugin, output chuẩn hóa thành file tarball, Red Hat support chấp nhận trực tiếp, có sẵn plugin riêng cho Apache, Docker, KVM, Kubernetes…
Nhược điểm: Cần quyền root, chạy mất 3–10 phút, file output lớn (thường 50–200MB), không phù hợp để monitor liên tục.
Cách 3: Monitoring stack (Prometheus, Datadog…)
Đây không phải tool debug sự cố — đây là lớp cảnh báo chủ động trước khi mọi thứ đổ vỡ.
Ưu điểm: Dashboard trực quan, cảnh báo tự động, lưu historical data theo thời gian.
Nhược điểm: Không thu thập được log chi tiết hay cấu hình hệ thống, cần thiết lập từ trước, không phải công cụ để gửi đi khi debug sự cố cụ thể.
Phân tích ưu nhược và chọn cách phù hợp
Tùy tình huống, cách phù hợp sẽ khác nhau. Đây là bảng mình hay nhìn lại:
- Debug sự cố đột xuất, gửi cho Red Hat support hoặc vendor: sosreport — đây là tình huống nó được thiết kế cho.
- Chỉ cần 1–2 thông số nhanh: Lệnh thủ công — nhanh hơn, không cần chờ sos chạy.
- Theo dõi hiệu năng theo thời gian thực: Monitoring stack (Prometheus + Grafana).
- Audit hệ thống trước khi thay đổi lớn (migration, kernel update): sosreport — tạo snapshot để so sánh trước/sau.
- Troubleshoot sau khi cập nhật kernel hoặc package quan trọng: sosreport — cần đủ context để tìm regression.
Điểm mạnh thực sự của sosreport: nó thu thập thứ bạn chưa biết là mình cần. Khi debug sự cố networking mình đề cập ở trên, thứ tìm ra nguyên nhân không phải ip addr hay journalctl — mà là file cấu hình trong /etc/NetworkManager/system-connections/ được sosreport copy nguyên vào tarball.
Triển khai sosreport trên CentOS Stream 9
Bước 1: Cài đặt
CentOS Stream 9 thường có sẵn sos trong AppStream repository:
sudo dnf install sos -y
sos --version
# sos version 4.x.x
Bước 2: Chạy sosreport cơ bản
sudo sos report
Trước khi chạy, tool hỏi vài thứ:
Please enter your first initial and last name [root]: hieu
Please enter the case id that you are generating this report for: CASE-2026-001
Nếu không có case ID (tự troubleshoot), nhấn Enter bỏ qua. Sau 3–5 phút, file được tạo tại:
/var/tmp/sosreport-hostname-2026-06-20-xxxxxxx.tar.xz
Bước 3: Tùy chỉnh thu thập đúng thứ cần thiết
Không phải lúc nào cũng cần full report. Một số options thực dụng:
# Xem danh sách plugins có sẵn
sudo sos report --list-plugins
# Chỉ thu thập networking và kernel (nhanh hơn nhiều)
sudo sos report --only-plugins networking,networkmanager,kernel,logs
# Bỏ qua plugin tốn thời gian không cần thiết
sudo sos report --skip-plugins rpm,yum,docker
# Chạy không hỏi interactive — dùng trong script
sudo sos report --batch --label "post-migration-$(hostname)"
# Chỉ định thư mục output
sudo sos report --tmp-dir /data/sos-reports/
# Giới hạn kích thước log files thu thập (MB)
sudo sos report --log-size 20
# Chỉ lấy log từ mốc thời gian nhất định
sudo sos report --since "2026-06-19 00:00:00"
Khi debug vấn đề networking sau migration, mình hay chạy lệnh gọn này — nhanh hơn full report mà vẫn có đủ thứ cần:
sudo sos report \
--only-plugins networking,networkmanager,firewalld,kernel,logs \
--batch \
--label "net-debug-$(hostname)-$(date +%Y%m%d)"
Bước 4: Phân tích output
File tarball khá có cấu trúc — giải nén ra là thấy ngay:
cd /var/tmp/
tar -xJf sosreport-*.tar.xz
ls -la sosreport-*/
Cấu trúc thư mục điển hình:
sosreport-hostname-2026-06-20-xxxxxxx/
├── etc/ # Toàn bộ /etc được copy nguyên
│ ├── systemd/
│ ├── NetworkManager/
│ └── sysconfig/
├── var/log/ # Log files
│ ├── messages
│ └── audit/audit.log
├── proc/ # Snapshot /proc tại thời điểm chạy
├── sos_commands/ # Output của từng lệnh chạy bởi sos
│ ├── networking/
│ │ ├── ip_addr
│ │ ├── ip_route
│ │ └── ss_-tlnp
│ └── kernel/
│ ├── dmesg
│ └── uname
└── sos_logs/ # Log của chính sos khi chạy
Tìm thông tin nhanh sau khi giải nén:
# Trạng thái network tại thời điểm thu thập
cat sosreport-*/sos_commands/networking/ip_addr
# Tìm lỗi trong messages
grep -i "error\|failed\|critical" sosreport-*/var/log/messages | tail -50
# Xem cấu hình NetworkManager connections
ls sosreport-*/etc/NetworkManager/system-connections/
# Tìm OOM killer hoặc kernel panic
grep -r "Out of memory\|Killed process\|kernel panic" sosreport-*/var/log/
# Xem thông tin hardware và kernel
cat sosreport-*/sos_commands/kernel/uname
Bước 5: Thu thập từ nhiều server cùng lúc với sos collect
Quản lý cluster hoặc nhiều server? sos collect giúp thu thập đồng loạt qua SSH:
sudo sos collect \
--nodes web1,web2,web3,db1 \
--ssh-user admin \
--only-plugins networking,logs,kernel
Script tích hợp vào quy trình xử lý sự cố
Script này mình đề nghị team setup từ trước — chạy ngay khi có sự cố nghiêm trọng:
#!/bin/bash
# /usr/local/sbin/emergency-sos.sh
LABEL="incident-$(date +%Y%m%d-%H%M)"
OUTPUT_DIR="/data/sos-reports"
mkdir -p "$OUTPUT_DIR"
echo "[$(date)] Thu thập sosreport cho: $LABEL"
sudo sos report \
--batch \
--label "$LABEL" \
--tmp-dir "$OUTPUT_DIR" \
--log-size 50 \
2>&1 | tee "/var/log/sos-${LABEL}.log"
echo "[$(date)] Hoàn thành:"
ls -lh "$OUTPUT_DIR"/sosreport-*"$LABEL"* 2>/dev/null
Khi migrate CentOS 8 → Rocky Linux, mình chạy script này trước và sau mỗi server để có snapshot so sánh. Thứ cứu mình khỏi mấy tiếng debug không phải công cụ phức tạp — chỉ là có đủ thông tin đúng lúc.
Một số lỗi hay gặp và cách xử lý
sosreport chạy quá lâu hoặc bị treo
Plugin rpm đặc biệt chậm trên server nhiều package — có thể mất 5–10 phút riêng. Bỏ qua nếu không cần:
sudo sos report --skip-plugins rpm,yum
# Debug để biết plugin nào đang chạy
sudo sos report --debug 2>&1 | grep "Running plugin"
File output quá lớn
# Giới hạn log size và dùng only-plugins
sudo sos report --log-size 10 --only-plugins networking,logs,kernel
Thiếu quyền thu thập một số thông tin
# Dùng sudo, không phải su -
sudo sos report # Đúng
su -c "sos report" # Có thể thiếu environment, sudo tốt hơn
Kết luận thực tế
sosreport không thay thế việc phải hiểu Linux — nó giúp bạn thu thập đủ thông tin để bắt đầu hiểu vấn đề. Thay vì chạy 30 lệnh và lo bỏ sót, một lệnh sudo sos report cho bạn mọi thứ cần thiết trong 5 phút.
Bài học mình rút ra: chạy sosreport sớm, đừng chờ đến khi đã restart service rồi mới nghĩ đến. Snapshot khi sự cố còn nguyên mới có giá trị — reboot hay restart sẽ xóa đi nhiều trạng thái lỗi, và bạn sẽ không bao giờ tìm ra nguyên nhân thực sự nữa.
