Lộ trình
Google CloudAssociateTuần 4: Tối ưu & vận hànhBài 23 / 30

Ngày 23: Cloud Monitoring & Logging

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

Thiết kế observability GCP bằng metrics, logs, traces, alerting và incident evidence; tránh alert noise, cardinality và log cost không kiểm soát.

đọ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 GCP bằng metrics, logs, traces, alerting và incident evidence; tránh alert noise, cardinality và log cost không kiểm soát.

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

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

  • Tìm hiểu Cloud Monitoring, thiết lập alerting policy
  • Thực hành xem log bằng Cloud Logging
Instructor walkthrough

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

Scenario xuyên suốt

Một service có nhiều log nhưng không ai biết request đang lỗi ở đâu; alert dựa trên CPU không bắt được 5xx, còn log sink ingest cả payload nhạy cảm khiến cost tăng. Bài học nối signal với user impact, runbook và retention.

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 xu hướng/SLO; logs chứa event detail; traces nối request path; mỗi signal có latency, cost và query model khác nhau.
  • Alert condition cần symptom/threshold/window, notification owner, deduplication, severity và actionable runbook; alert không có action chỉ tạo noise.
  • Cloud Logging filter/structured logs/labels giúp query nhưng high-cardinality và payload nhạy cảm gây cost/risk.
  • Monitoring scope, service account IAM, log bucket/retention/sink và cross-project aggregation là các boundary khác nhau.

Từ signal đến action

Observability tốt bắt đầu từ user impact/SLO: availability, latency, error rate, saturation và dependency. Metric trả lời “bao nhiêu/bao lâu”; log trả lời “event nào”; trace trả lời “request đi qua đâu”. Audit log trả lời “ai thay đổi gì”. Chọn signal theo câu hỏi, không theo số lượng dashboard.

Alert và incident evidence

Alert cần condition, window, severity, owner, notification và runbook. Log structured giúp query nhưng phải loại secret/PII, giới hạn cardinality và đặt retention/sink theo cost. Trong incident ghi timeline, change correlation, evidence, mitigation, rollback và follow-up.

Bài tập

Tạo signal map và drill năm failure scenarios. Inspect policy/log metadata read-only, viết alert/runbook và checklist cleanup. Pass khi người khác có thể dùng evidence để nhận biết impact và hành động mà không cần đoán.

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
gcloud monitoring policies list --project=LAB_PROJECT_ID --format="table(displayName,enabled,conditions.displayName)"
gcloud logging buckets list --project=LAB_PROJECT_ID --format="table(name,location,retentionDays)"
gcloud logging sinks list --project=LAB_PROJECT_ID --format="table(name,destination,filter,disabled)"
gcloud logging read "resource.type=cloud_run_revision AND severity>=ERROR" --project=LAB_PROJECT_ID --limit=20 --format="table(timestamp,severity,logName,textPayload)"
Hands-on lab

Thực hành theo scenario

  1. Lập signal map cho API/GKE/VM: availability, latency, error rate, saturation, dependency và audit; mỗi signal ghi source, threshold, owner, runbook và false-positive risk.
  2. Inspect alert policies, notification channels, log buckets/sinks và recent logs read-only; redact payload, không tạo channel gửi email cá nhân vào repo.
  3. Tạo incident drill design hoặc lab nhỏ: 5xx spike, latency, disk full, IAM deny và dependency failure; thu evidence trước/sau mitigation.
  4. Cleanup test alert/channel/sink/log volume theo policy; kiểm tra retention và cost/cardinality assumptions.
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:

  • Signal map nối user impact với metric/log/trace.
  • Alert có threshold/window/owner/action/runbook.
  • Log security, retention và cardinality được kiểm soát.
  • Incident timeline có evidence và rollback/mitigation.
  • Cleanup monitoring resources và cost review rõ.
Transfer to exam / production

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

ACE phân biệt Cloud Monitoring, Cloud Logging, Error Reporting, Trace và Audit Logs theo câu hỏi cần trả lời. Đừng dùng CPU làm proxy cho mọi lỗi ứng dụng hoặc log mọi payload.

Checkpoint · 3 phút

Kiểm tra nhanh

Câu hỏi: API trả 5xx tăng nhưng CPU bình thường. Signal và hành động nào phù hợp nhất?

Kết thúc bài

Checklist trước khi sang Ngày 2