Lỗi này là gì
Bạn mở EC2 console và thấy dòng này:
Instance reachability check failed (1/2 status checks failed)
Instance vẫn hiển thị chấm xanh "running". Nhưng SSH bị timeout. Ứng dụng ngừng phản hồi. AWS đang báo rằng instance còn sống nhưng không thể tiếp cận — giống như một máy tính đang bật nguồn nhưng không phản hồi bàn phím.
System status check vẫn pass — phần cứng AWS không có vấn đề. Instance-level check mới là thứ bị lỗi. Và đó là việc bạn phải tự xử lý.
Ý nghĩa của từng Status Check
- System status check (2/2) — Phần cứng, mạng, nguồn điện phía AWS. Nếu lỗi, AWS sẽ tự xử lý.
- Instance status check (1/2 failed) — Hệ điều hành và phần mềm chạy bên trong instance. Bạn phải tự sửa.
Nguyên nhân hầu như luôn nằm bên trong OS: kernel lỗi, filesystem bị hỏng, cấu hình network stack sai, hoặc boot thất bại khiến instance khởi động dở dang.
Nguyên nhân gốc rễ
- Kernel panic hoặc boot thất bại — thường xảy ra sau khi nâng cấp bằng
yum/aptlàm thay đổi kernel - Root filesystem bị hỏng — cấu hình
/etc/fstabsai, đĩa đầy khi tắt máy, hoặc bị force stop giữa chừng khi đang ghi dữ liệu - Network interface cấu hình sai — DHCP bị tắt, MTU sai, thiếu default route
- OOM killer kích hoạt — bộ nhớ cạn kiệt và các tiến trình hệ thống quan trọng bị kill
- SSH daemon bị crash — instance vẫn còn sống nhưng bạn không thể kết nối vào
- Security group hoặc NACL chặn traffic health check (hiếm, nhưng cũng nên kiểm tra)
Bước 1 — Đọc System Log trước tiên
Bắt đầu từ đây, trước khi làm bất cứ điều gì khác. EC2 system log ghi lại đầu ra serial console từ lần boot cuối, và thường cho bạn biết chính xác điều gì đã xảy ra.
Qua console:
EC2 Console → chọn instance → Actions → Monitor and troubleshoot → Get system log
Qua CLI:
aws ec2 get-console-output \
--instance-id i-0abc1234567890def \
--region us-east-1 \
--output text
Tìm những dấu hiệu sau:
Kernel panic - not syncing→ lỗi kernel hoặc initrdUNEXPECTED INCONSISTENCY; RUN fsck MANUALLY→ filesystem bị hỏngERROR: device not foundtrong ngữ cảnh fstab → entry mount bị saiOut of memory: Kill process→ OOM killer đã kích hoạt
Fix 1 — Stop và Start lại Instance (không phải Reboot)
Thao tác stop + start sẽ di chuyển instance sang phần cứng nền tảng khác. Reboot thì vẫn ở trên cùng một host. Thử cách này trước — nó giải quyết các vấn đề phần cứng hoặc hypervisor tạm thời mà không cần can thiệp vào OS.
aws ec2 stop-instances --instance-ids i-0abc1234567890def
aws ec2 wait instance-stopped --instance-ids i-0abc1234567890def
aws ec2 start-instances --instance-ids i-0abc1234567890def
Chờ 2–3 phút, rồi kiểm tra trạng thái:
aws ec2 describe-instance-status \
--instance-ids i-0abc1234567890def \
--query 'InstanceStatuses[0].InstanceStatus.Status'
Trả về ok? Xong. Vẫn lỗi? Chuyển sang fix tiếp theo.
Fix 2 — Sửa qua EC2 Serial Console
SSH không vào được nhưng instance vẫn đang boot? EC2 Serial Console kết nối bạn ở cấp độ kernel — không cần mạng, không cần SSH.
EC2 Console → Instance → Actions → Monitor and troubleshoot → EC2 Serial Console → Connect
Một lưu ý: cách này chỉ hoạt động trên các instance dựa trên Nitro (t3, m5, c5, r5, và hầu hết các loại thế hệ hiện tại). Hãy bật tính năng này cho tài khoản trước:
aws ec2 enable-serial-console-access --region us-east-1
Sau khi kết nối, kiểm tra các nguyên nhân phổ biến:
# Kiểm tra dung lượng đĩa
df -h
# Kiểm tra lỗi filesystem (unmount trước nếu có thể)
sudo fsck -y /dev/xvda1
# Kiểm tra /etc/fstab xem có entry lỗi không
cat /etc/fstab
# Comment out mount đáng ngờ để test boot
sudo nano /etc/fstab
Fix 3 — Detach Root Volume và Sửa từ Instance Khác
Instance hoàn toàn chết và serial console không dùng được? Detach root volume, mount vào một instance đang chạy tốt, rồi sửa từ bên ngoài. Nghe có vẻ phức tạp, nhưng đây là cách đáng tin cậy — và bạn sẽ không mất dữ liệu.
1. Stop instance bị lỗi (không phải terminate).
2. Detach root volume của nó:
aws ec2 detach-volume --volume-id vol-0abc123def456
3. Attach vào rescue instance như một volume phụ (ví dụ: /dev/xvdf):
aws ec2 attach-volume \
--volume-id vol-0abc123def456 \
--instance-id i-0rescue123456 \
--device /dev/xvdf
4. SSH vào rescue instance và mount volume:
sudo mkdir /mnt/recovery
sudo mount /dev/xvdf1 /mnt/recovery
# Sửa /etc/fstab
sudo nano /mnt/recovery/etc/fstab
# Chạy fsck trên partition đã unmount
sudo fsck -y /dev/xvdf1
# Tìm thứ đang chiếm hết dung lượng đĩa
df -h /mnt/recovery
sudo du -sh /mnt/recovery/var/log/* | sort -rh | head -20
5. Unmount, detach, reattach vào instance gốc làm root (/dev/xvda), rồi start lại.
Fix 4 — Entry fstab Sai (Phổ Biến Nhất Sau Khi Thêm Mount)
Đây là bẫy kinh điển. Thêm EFS mount hoặc EBS volume phụ vào /etc/fstab, bỏ qua option nofail, và lần tiếp theo resource đó không có mặt thì instance sẽ treo ở bước boot. Hoàn toàn hỏng — chỉ vì thiếu một flag.
Luôn dùng format sau:
# EBS volume — nofail ngăn treo boot nếu volume bị detach
UUID=xxxx-xxxx /data ext4 defaults,nofail 0 2
# EFS mount — nofail + _netdev (chờ mạng trước khi mount)
fs-12345.efs.us-east-1.amazonaws.com:/ /mnt/efs efs defaults,_netdev,nofail 0 0
Flag _netdev báo cho systemd biết phải chờ mạng sẵn sàng trước khi thử mount. Kết hợp cả hai flag giúp các network mount an toàn khi đưa vào fstab.
Fix 5 — Lỗi OOM / Bộ nhớ
Thấy dòng Out of memory: Kill process 1234 (mysqld) trong log? Kernel đã hết RAM và bắt đầu kill các tiến trình — có thể là những tiến trình quan trọng. Có hai hướng xử lý:
- Nâng cấp lên loại instance lớn hơn (stop → đổi instance type → start)
- Thêm swap để câu giờ, rồi xử lý nguyên nhân gốc rễ đúng cách
# Thêm swap 2GB sau khi recovery
sudo fallocate -l 2G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab
Swap không thay thế được RAM đủ dùng — khi tải cao sẽ làm instance chậm đáng kể. Hãy coi đây là biện pháp tạm thời trong khi bạn lên kế hoạch resize đúng cách.
Kiểm tra lại
Sau khi sửa, xác nhận cả hai check đều pass:
aws ec2 describe-instance-status \
--instance-ids i-0abc1234567890def \
--query 'InstanceStatuses[0].{System:SystemStatus.Status,Instance:InstanceStatus.Status}'
Kết quả mong đợi:
{
"System": "ok",
"Instance": "ok"
}
Sau đó kiểm tra SSH và xác nhận ứng dụng của bạn thực sự đang chạy, không chỉ là instance.
Phòng ngừa
- Đặt
nofailthành quy tắc bắt buộc cho mọi volume không phải root và network mount trong/etc/fstab— không có ngoại lệ - Đặt CloudWatch alarm theo dõi
StatusCheckFailed_Instanceđể bạn biết trước người dùng:
aws cloudwatch put-metric-alarm \
--alarm-name ec2-instance-check-i-0abc123 \
--namespace AWS/EC2 \
--metric-name StatusCheckFailed_Instance \
--dimensions Name=InstanceId,Value=i-0abc1234567890def \
--statistic Maximum \
--period 60 \
--evaluation-periods 2 \
--threshold 1 \
--comparison-operator GreaterThanOrEqualToThreshold \
--alarm-actions arn:aws:sns:us-east-1:123456789012:your-alert-topic
- Bật EC2 Auto Recovery cho các lỗi ở cấp độ system — tính năng này tự động di chuyển instance sang phần cứng lành mạnh khi phần cứng phía AWS gặp sự cố:
aws cloudwatch put-metric-alarm \
--alarm-name ec2-auto-recover-i-0abc123 \
--namespace AWS/EC2 \
--metric-name StatusCheckFailed_System \
--dimensions Name=InstanceId,Value=i-0abc1234567890def \
--statistic Minimum \
--period 60 \
--evaluation-periods 2 \
--threshold 1 \
--comparison-operator GreaterThanOrEqualToThreshold \
--alarm-actions arn:aws:automate:us-east-1:ec2:recover
- Snapshot root EBS volume theo lịch định kỳ — tối thiểu hàng tuần. Một snapshot từ trước khi nâng cấp kernel lỗi có thể rút ngắn thời gian recovery từ vài giờ xuống còn vài phút
- Test nâng cấp kernel trên môi trường staging trước. Phần lớn các lỗi reachability xảy ra trong vài phút sau khi cập nhật package làm thay đổi kernel đang chạy