Lộ trình
Amazon Web ServicesAssociateTuần 4: Tối ưu & vận hànhBài 24 / 30

Ngày 24: Monitoring & observability

Thời lượng: 45 phút
Mục tiêu: 2 nhiệm vụ chính
Tiến độ lộ trình
aws-saa-c03ngày 24
hoàn thành24 / 30 bài
Bối cảnh bài học

Thiết kế observability bằng metrics, logs, traces, alarms, dashboards và audit events theo câu hỏi vận hành.

đọc hiểuthực hànhcheckpoint
Bài giảng hôm nay

Học hiểu, rồi mới thực hành

Thiết kế observability bằng metrics, logs, traces, alarms, dashboards và audit events theo câu hỏi vận hành.

Bắt đầu đọc bài giảng

Nhiệm vụ bài học hôm nay

  • Tìm hiểu CloudWatch Logs, Metrics, X-Ray
  • Thực hành tạo dashboard CloudWatch cơ bản
Instructor walkthrough

Bài giảng chi tiết: từ bài toán đến bằng chứng

Scenario xuyên suốt

Team có rất nhiều log nhưng không trả lời được latency, error rate, API change hay root cause. Bài học bắt đầu từ câu hỏi và signal, không bật mọi log vô hạn.

01Đọc bài toán

Xác định actor, workload, constraint và trạng thái cuối cần đạt.

02Vẽ luồng / boundary

Chỉ ra request, dependency, identity và failure domain trước khi chọn công cụ.

03Chọn và thực hành

Thay đổi nhỏ nhất trong lab cô lập; command nào cũng phải nói rõ nó kiểm tra điều gì.

04Kiểm chứng / recovery

Đối chiếu trạng thái thực tế, tạo một failure variant và ghi cách hoàn tác.

Cách nối lý thuyết với thực tế
  • Metrics phù hợp trend/threshold; logs phù hợp event/detail; traces theo request path; alarms tạo action.
  • CloudWatch quan sát workload; CloudTrail audit API identity; X-Ray/OpenTelemetry hỗ trợ trace tùy stack.
  • SLO/SLI, alert threshold, retention, sampling và cardinality ảnh hưởng noise/cost.
  • Observability cần runbook, owner và test alert, không chỉ dashboard.

Observability theo câu hỏi

Hãy phân biệt metric, log, trace và audit event. Một dashboard không tự trả lời root cause; một log không tự tạo alert.

Bài tập

Tạo signal map cho latency/error/API change/dependency/deploy regression. Với mỗi signal ghi threshold, retention, owner, action và runbook. Sau đó loại bỏ một signal noisy để luyện cost/signal quality.

Bài giảng chuyên sâu

Observability phải trả lời câu hỏi vận hành

Metrics cho trend/threshold, logs cho event/detail, traces cho request path, CloudTrail cho API identity/audit. Alarm cần threshold, window, owner, action và runbook; dashboard không tự tạo response. Giới hạn retention, sampling và cardinality để tránh noise/cost.

Bài tập: tạo signal map cho latency, error, API change, dependency timeout, deploy regression và user impact. Failure drill: alarm không gửi, metric thiếu dimension và log chứa secret; ghi expected evidence, remediation và retention.

Terminal reference

Command list và cách dùng

Chạy từng lệnh theo đúng thứ tự. Trước các lệnh có thể tạo hoặc thay đổi tài nguyên, hãy kiểm tra profile, account và region.

Commands · read-only checkpoints
aws cloudwatch list-metrics --profile study --max-items 10 --output table
aws cloudtrail describe-trails --profile study --output table
Hands-on lab

Thực hành theo scenario

Viết 6 operational questions: CPU/latency/error, API change, dependency timeout, deployment regression và user impact. Ghép signal, metric/log/trace/audit, alarm, dashboard và runbook. Dùng describe/list read-only nếu có account.

Evidence checkpoint

Kiểm chứng kết quả

Không coi lệnh chạy thành công là đủ. Hãy đối chiếu output với trạng thái mong đợi:

  • Chọn đúng signal cho từng câu hỏi.
  • Phân biệt CloudWatch với CloudTrail và trace.
  • Mỗi alarm có owner, threshold và action.
  • Nêu retention/cardinality/cost trade-off.
Transfer to exam / production

Bẫy thường gặp và trade-off

“Ai đã gọi API?” là audit; “request chậm qua service nào?” là trace; “CPU vượt ngưỡng?” là metric/alarm. Đọc câu hỏi trước khi chọn monitoring service.

Checkpoint · 3 phút

Kiểm tra nhanh

Câu hỏi: Cần biết request đi qua service nào gây latency cao. Signal nào phù hợp nhất?

Kết thúc bài

Checklist trước khi sang Ngày 2