Bài 46: Observability: Logs, Metrics và Traces
Bài này chi tiết hóa Observability theo hướng vận hành bền vững: có mẫu kiểm tra, tình huống thực tế, checklist và bài tập.
Sau bài này anh sẽ biết:
- Observability giúp hệ thống vận hành bền vững như thế nào.
- Các lệnh, tài liệu hoặc cấu hình nên kiểm tra.
- Cách phản ứng khi có sự cố thực tế.
- Cách biến kinh nghiệm vận hành thành checklist/runbook.
1. Bối cảnh thực tế
Observability thuộc nhóm kỹ năng giúp hệ thống không chỉ “chạy được”, mà còn dễ quan sát, dễ bảo vệ, dễ khôi phục và dễ học từ sự cố. Đây là phần quan trọng để vận hành lâu dài.
2. Khái niệm cần nắm
- Visibility: phải nhìn thấy log, metric, trạng thái và thay đổi.
- Actionable alert: cảnh báo phải dẫn tới hành động rõ ràng.
- Recovery: có kế hoạch khôi phục trước khi thảm họa xảy ra.
- Continuous improvement: sau sự cố phải có bài học và action item.
3. Lab thực hành / mẫu kiểm tra
Mục tiêu: xây thói quen kiểm tra, ghi nhận và phản ứng có quy trình.
journalctl -u nginx --since "1 hour ago" curl http://localhost:9100/metrics 2>/dev/null | head curl -fsS https://example.com/health # trace thường qua OpenTelemetry/Jaeger/Tempo # cần request id/correlation id để nối log và trace
4. Tình huống thực tế
API chậm nhưng CPU bình thường. Metric cho thấy latency tăng, log cho thấy timeout database, trace cho thấy request chậm ở bước query.
5. Quy trình áp dụng
- Xác định mục tiêu: quan sát, bảo vệ, khôi phục hay cải thiện.
- Thu thập trạng thái hiện tại: log, metric, config, tài liệu.
- Thiết kế checklist hoặc rule đơn giản trước.
- Test trong lab/staging nếu có.
- Áp dụng production theo từng bước nhỏ.
- Theo dõi sau thay đổi và ghi lại kết quả.
- Cập nhật tài liệu/runbook để lần sau xử lý nhanh hơn.
6. Lỗi thường gặp
- Có dashboard nhưng không có alert.
- Có alert nhưng không có runbook.
- Có backup nhưng chưa từng restore.
- Có chính sách bảo mật nhưng không audit định kỳ.
- Sau incident chỉ sửa tạm, không rút kinh nghiệm.
Lưu ý production: Vận hành bền vững cần tài liệu và kiểm tra định kỳ. Đừng đợi đến lúc sự cố mới đi tìm log, backup, owner hoặc quyền truy cập.
7. Checklist
- Có log/metric đủ để điều tra.
- Có cảnh báo có ý nghĩa hành động.
- Có runbook cho alert quan trọng.
- Có backup/restore/DR được test.
- Có audit quyền truy cập và secret.
- Có postmortem sau incident lớn.
8. Bài tập
- Chọn một hệ thống nhỏ và viết checklist vận hành.
- Tạo một alert giả định kèm runbook xử lý.
- Viết kế hoạch backup/restore/DR ngắn.
- Viết mẫu postmortem cho một sự cố giả định.
Bài tiếp theo: Centralized logging với ELK/Loki cơ bản
