Observability & Monitoring: Làm chủ Trạng thái Hệ thống

Trả lời:

• Monitoring báo cho bạn biết hệ thống có lỗi (Cái gì lỗi?).
• Observability giúp bạn tìm ra nguyên nhân gốc rễ của lỗi (Tại sao lỗi?).

Trả lời: Logs (Nhật ký), Metrics (Chỉ số), và Traces (Dấu vết).

Trả lời: Là việc ghi lại các sự kiện cụ thể xảy ra trong ứng dụng (ví dụ: “User A vừa đăng nhập”, “Lỗi kết nối DB”).

Trả lời: Là các dữ liệu định lượng đo lường theo thời gian. Ví dụ: Tỷ lệ CPU sử dụng, Số lượng request mỗi giây, Dung lượng RAM còn trống.

Trả lời: Cơ chế tự động thông báo (qua Email, Slack, Telegram) khi một chỉ số vượt ngưỡng an toàn (ví dụ: Error rate > 5%).

Trả lời: Mức độ quan trọng của log: DEBUG, INFO, NOTICE, WARNING, ERROR, CRITICAL, ALERT, EMERGENCY.

Trả lời: Làm tốn dung lượng ổ cứng, làm chậm ứng dụng do I/O, và gây khó khăn khi tìm kiếm thông tin quan trọng trong “biển” log rác.

Trả lời: Giao diện trực quan hóa các Metrics và Logs bằng biểu đồ, giúp con người nhanh chóng nắm bắt trạng thái hệ thống.

Trả lời: Một endpoint (ví dụ /health) để Load Balancer hoặc công cụ giám sát kiểm tra xem service còn sống và hoạt động bình thường không.

Trả lời: Thời gian hệ thống hoạt động liên tục mà không bị sập, thường tính theo tỷ lệ phần trăm (ví dụ: 99.9% uptime).

Trả lời: Log dưới dạng JSON hoặc Key-Value. Giúp các công cụ tìm kiếm (như Elasticsearch) dễ dàng phân tích, lọc và thống kê dữ liệu.

Trả lời: Theo dõi một request duy nhất khi nó đi xuyên qua nhiều microservices khác nhau, giúp xác định xem bước nào bị chậm hoặc gây lỗi.

Trả lời:

• Pull (Prometheus): Server giám sát chủ động gọi vào app để lấy dữ liệu.
• Push (CloudWatch, Datadog): App chủ động gửi dữ liệu về server giám sát.

Trả lời: Công cụ giám sát chuyên sâu hiệu năng ứng dụng: thời gian chạy code, query DB chậm, lỗi runtime (ví dụ: New Relic, Dynatrace, Elastic APM).

Trả lời: Khi có hàng chục server, việc vào từng máy rất mất thời gian. Cần đẩy log về một nơi tập trung (ELK Stack, Graylog) để tìm kiếm và phân tích toàn cục.

Trả lời:

• p50 (Median): 50% request nhanh hơn mức này.
• p99: Chỉ 1% request chậm hơn mức này. Đo p99 giúp phát hiện các vấn đề ảnh hưởng đến nhóm người dùng kém may mắn nhất.

Trả lời: Thay vì ghi trực tiếp vào file/network trong request, đẩy log vào một buffer hoặc queue (như Redis) để một process riêng xử lý ghi sau đó.

Trả lời: Tự động nén và xóa các file log cũ theo thời gian hoặc dung lượng để tránh làm đầy ổ cứng server.

Trả lời: Một ID duy nhất được gán cho mỗi request. Mọi log liên quan đến request đó (từ lúc vào đến lúc ra, qua nhiều hàm/service) đều đính kèm ID này để dễ truy vết.

Trả lời:

• Counter: Chỉ tăng (số request).
• Gauge: Tăng hoặc giảm (lượng RAM).
• Histogram: Phân bổ dữ liệu (thời gian phản hồi).

Trả lời: Logstash thu thập và biến đổi log -> Elasticsearch lưu trữ và đánh index -> Kibana cung cấp giao diện trực quan hóa và tìm kiếm.

Trả lời: Là một chuẩn chung (Open standard) cho việc thu thập Logs, Metrics, Traces. Giúp bạn chuyển đổi giữa các nhà cung cấp (như từ Datadog sang New Relic) mà không cần sửa code.

Trả lời: Dùng Metrics để theo dõi các hành vi bất thường (ví dụ: số đơn hàng thành công giảm đột ngột dù không có log lỗi).

Trả lời: Log tập trung vào ý nghĩa nghiệp vụ thay vì thông tin kỹ thuật (ví dụ: UserPurchasedProduct thay vì InsertIntoOrderTable).

Trả lời: Chỉ cảnh báo cho những lỗi cần can thiệp ngay (Actionable). Phân loại mức độ: P1 (gọi điện), P2 (Slack), P3 (chỉ ghi log). Dùng cơ chế Deduplication để không bắn 1000 tin cho cùng 1 lỗi.

Trả lời:

• Black-box: Kiểm tra từ bên ngoài (như user thấy): ping, check HTTP status.
• White-box: Kiểm tra từ bên trong app: log, metrics nội bộ, trạng thái queue.

Trả lời: Dùng cơ chế Masking hoặc Redaction để tự động ẩn mật khẩu, số thẻ tín dụng, email… trước khi ghi vào log.

Trả lời: Chỉ lưu trữ vết của một phần nhỏ request (ví dụ 1% hoặc 10%) để tiết kiệm chi phí lưu trữ và băng thông mà vẫn đảm bảo tính thống kê.

Trả lời: Giảm độ phân giải của dữ liệu cũ (ví dụ: dữ liệu 1 năm trước chỉ giữ lại trung bình theo giờ thay vì theo phút).

Trả lời: Wrap các cuộc gọi API bằng các công cụ đo lường thời gian và tỷ lệ lỗi. Dùng cơ chế Circuit Breaker để tự động ngắt khi API bên ngoài sập.

Trả lời: Sử dụng OpenTelemetry collector làm agent trung gian. Triển khai Distributed Tracing (Jaeger/Zipkin). Centralized Logging qua cụm ELK/Loki. Dashboard tổng quát qua Grafana.

Trả lời: Chi phí lưu trữ và phân tích log có thể vượt quá chi phí chạy ứng dụng. Architect cần xác định: Cái gì CẦN log vĩnh viễn, cái gì chỉ cần Metrics, và cái gì có thể xóa sau 7 ngày.

Trả lời:

• SLI: Chỉ số đo được (Uptime).
• SLO: Mục tiêu hướng tới (99.9% uptime).
• SLA: Cam kết với khách hàng (Nếu không đạt 99.9% sẽ bồi thường). Triển khai bằng cách tạo Dashboard theo dõi “Error Budget”.

Trả lời: Khi Metrics báo quá tải hoặc lỗi liên tục -> Kích hoạt Automation script (ví dụ: tự động restart container, tự động scale thêm server, hoặc tự động switch sang Region dự phòng).

Trả lời: Sử dụng máy học để tự động phát hiện hành vi bất thường (Anomaly detection) mà con người không thể định nghĩa bằng các luật tĩnh (static rules).

Xử lý: 1. Kiểm tra log INFO/DEBUG của request đó để xem luồng đi. 2. Kiểm tra log của các service liên quan (Payment Gateway). 3. Kiểm tra Metrics để xem có sụt giảm tỷ lệ success không.

Xử lý: 1. Khẩn cấp: Xóa file log cũ (.log.1, .gz). 2. Lâu dài: Cấu hình logrotate, đẩy log về server trung tâm, và kiểm tra lại Log Level.