Giám sát hệ thống trên AWS: CloudWatch, CloudTrail...

1. Amazon CloudWatch Metrics – theo dõi số liệu hiệu năng

Khi vận hành hệ thống trên cloud, bạn cần biết "sức khỏe" của từng thành phần đang như thế nào: CPU có đang quá tải không, dung lượng ổ đĩa còn bao nhiêu, ứng dụng có đang trả lời chậm không... Đó chính là vai trò của Amazon CloudWatch — dịch vụ giám sát trung tâm của AWS, cung cấp số liệu (metric) cho HẦU HẾT các dịch vụ AWS mà bạn đang sử dụng.

Một metric (số liệu/chỉ số) là một biến số mà bạn muốn theo dõi theo thời gian — ví dụ CPUUtilization (mức sử dụng CPU), NetworkIn (lưu lượng mạng đi vào)... Mỗi metric đều có một dấu thời gian (timestamp) gắn liền với từng giá trị đo được, cho phép bạn vẽ biểu đồ biến động của nó theo thời gian.

CloudWatch cho phép bạn tạo dashboard (bảng điều khiển trực quan) để hiển thị nhiều metric cùng lúc trên một màn hình duy nhất — ví dụ một dashboard hiển thị biểu đồ chi phí (billing metric) đang tăng theo thời gian trong tháng.

Một số nhóm metric quan trọng cần nhớ:

• EC2 instance: CPU Utilization (mức sử dụng CPU), Status Checks (kiểm tra tình trạng instance), Network (lưu lượng mạng vào/ra). Lưu ý: CloudWatch KHÔNG tự động theo dõi RAM (bộ nhớ) của EC2 — đây là điểm dễ gây nhầm lẫn. Muốn giám sát RAM, bạn phải tự cài agent và gửi custom metric.
• Tần suất đo mặc định: mỗi 5 phút một lần. Nếu cần độ chi tiết cao hơn, có thể bật Detailed Monitoring (tốn thêm phí — biểu tượng "$$$") để đo mỗi 1 phút một lần.
• EBS volume: Disk Read/Writes (số lượt đọc/ghi đĩa).
• S3 bucket: BucketSizeBytes (dung lượng bucket), NumberOfObjects (số lượng object), AllRequests (tổng số request).
• Billing: Total Estimated Charge (tổng chi phí ước tính) — lưu ý metric này chỉ khả dụng tại Region us-east-1.
• Service Limits: theo dõi mức độ bạn đang sử dụng gần đến ngưỡng giới hạn (quota) của API một dịch vụ nào đó.
• Custom metrics: bạn có thể tự định nghĩa và đẩy (push) số liệu riêng của mình lên CloudWatch — ví dụ số lượng đơn hàng xử lý mỗi phút trong ứng dụng của bạn.

2. Amazon CloudWatch Alarms – cảnh báo tự động

Có metric là chưa đủ — bạn cần một cơ chế để hệ thống TỰ ĐỘNG phản ứng khi có điều gì bất thường xảy ra, mà không cần con người phải ngồi canh màn hình 24/7. Đó là vai trò của CloudWatch Alarms (cảnh báo).

Một Alarm được gắn với một metric cụ thể, và bạn định nghĩa một ngưỡng (threshold) — ví dụ "CPU Utilization vượt quá 80% trong 5 phút liên tục". Khi điều kiện này xảy ra, Alarm sẽ kích hoạt một hành động (action). Các hành động phổ biến gồm:

• Auto Scaling action: tự động tăng hoặc giảm số lượng ("desired count") EC2 instance trong một Auto Scaling Group.
• EC2 action: tự động stop (tắt), terminate (xóa), reboot (khởi động lại), hoặc recover (khôi phục) một EC2 instance.
• SNS notification: gửi thông báo vào một SNS topic — ví dụ để gửi email/SMS cảnh báo cho quản trị viên (đây chính là điểm liên kết trực tiếp với Amazon SNS mà bạn đã học ở chương trước).

Khi cấu hình Alarm, bạn có nhiều lựa chọn về cách tính toán giá trị để so sánh với ngưỡng — ví dụ dùng giá trị trung bình (average), phần trăm (percentage), giá trị lớn nhất (max), nhỏ nhất (min)... và bạn cũng chọn được khoảng thời gian (period) để đánh giá điều kiện của alarm (ví dụ đánh giá mỗi 1 phút, 5 phút...).

Một alarm luôn ở một trong ba trạng thái (Alarm States):

• OK: giá trị metric đang nằm trong ngưỡng bình thường.
• ALARM: giá trị metric đã vượt ngưỡng đã đặt, cảnh báo đang được kích hoạt.
• INSUFFICIENT_DATA: chưa có đủ dữ liệu để xác định trạng thái (ví dụ metric mới bắt đầu được thu thập).

3. Amazon CloudWatch Logs – thu thập log tập trung

Ngoài các số liệu (metric) và cảnh báo (alarm), CloudWatch còn có một thành phần quan trọng khác: CloudWatch Logs — nơi tập trung lưu trữ log (nhật ký hoạt động) từ nhiều nguồn khác nhau trong hệ thống AWS của bạn, giúp bạn không phải "chạy vào từng server" để xem log riêng lẻ.

CloudWatch Logs có thể thu thập log từ nhiều nguồn, bao gồm:

• Elastic Beanstalk: tự động thu thập log từ ứng dụng được triển khai qua Elastic Beanstalk.
• ECS (Elastic Container Service): thu thập log từ các container đang chạy.
• AWS Lambda: thu thập log từ các function serverless.
• CloudTrail: dựa theo bộ lọc (filter) mà bạn định nghĩa, có thể đưa các sự kiện CloudTrail vào CloudWatch Logs để dễ tìm kiếm và cảnh báo.
• CloudWatch Logs Agent: chạy trên EC2 instance hoặc server on-premises để đẩy log từ máy chủ đó lên CloudWatch.
• Route 53: ghi log các truy vấn DNS (log DNS queries).

CloudWatch Logs cho phép giám sát log theo thời gian thực (real-time monitoring), và bạn có thể điều chỉnh (adjustable) thời gian lưu trữ (retention) của log — ví dụ giữ log 30 ngày, 90 ngày, 1 năm, hoặc vĩnh viễn, tùy theo nhu cầu vận hành và tuân thủ (compliance) của tổ chức.

CloudWatch Logs cho EC2

Một điểm rất quan trọng và thường bị hiểu nhầm: theo mặc định (by default), KHÔNG có bất kỳ log nào từ một EC2 instance được tự động gửi lên CloudWatch Logs. Việc thu thập metric CPU/Network là tự động, nhưng thu thập log file bên trong instance thì KHÔNG tự động.

Để đưa log từ EC2 vào CloudWatch, bạn cần:

• Tự cài đặt và chạy CloudWatch Agent trên EC2 instance đó.
• Cấu hình agent để chỉ định chính xác những file log nào cần được đẩy lên.
• Đảm bảo instance có quyền IAM phù hợp (thường là một IAM Role gắn vào EC2 instance) để agent có thể gửi dữ liệu log lên CloudWatch Logs.

Điều thú vị là CloudWatch Log Agent không chỉ dùng được cho EC2 — nó còn có thể được cài đặt trên các server chạy on-premises (tại trung tâm dữ liệu riêng của doanh nghiệp), giúp bạn tập trung log của cả hệ thống hybrid (vừa cloud vừa on-premises) vào một nơi duy nhất.

4. Amazon EventBridge – phản ứng theo sự kiện và lịch trình

Amazon EventBridge (trước đây gọi là CloudWatch Events) là dịch vụ giúp bạn xây dựng các "luật" (rule) để hệ thống tự động phản ứng khi có một sự kiện nào đó xảy ra, hoặc chạy theo một lịch trình định sẵn. Có hai kiểu kích hoạt (trigger) chính:

• Schedule (Lịch trình): giống như cron job — chạy một script/hành động theo lịch định kỳ, ví dụ "mỗi giờ một lần" hoặc "mỗi 4 giờ".
• Event Pattern (Mẫu sự kiện): định nghĩa luật để phản ứng ngay khi một dịch vụ AWS nào đó thực hiện một hành động cụ thể — ví dụ ngay khi có ai đăng nhập bằng tài khoản Root.

Khi luật được kích hoạt, EventBridge có thể gọi (trigger) một AWS Lambda function, hoặc gửi message vào SQS/SNS để các hệ thống khác xử lý tiếp.

Ví dụ minh họa:

• Sự kiện "IAM Root User Sign in" (tài khoản Root đăng nhập) → EventBridge phát hiện → gửi vào SNS Topic → SNS gửi Email cảnh báo ngay cho quản trị viên bảo mật.
• Lịch trình "Mỗi giờ" → EventBridge tự động kích hoạt một Lambda function chạy một đoạn script định kỳ (ví dụ dọn dẹp dữ liệu cũ).

EventBridge Rules – nguồn và đích

EventBridge có thể lắng nghe sự kiện từ rất nhiều nguồn (source), ví dụ:

• EC2 Instance (ví dụ: instance vừa được khởi động - Start Instance).
• CodeBuild (ví dụ: một lượt build bị lỗi).
• S3 (ví dụ: có object mới được upload).
• Trusted Advisor (ví dụ: có phát hiện/khuyến nghị mới - new Finding).
• CloudTrail (bất kỳ lệnh gọi API nào).
• Schedule/Cron (ví dụ mỗi 4 giờ).

Và có thể gửi đến rất nhiều loại đích (destination) khác nhau, chia theo nhóm:

Các tính năng nâng cao của EventBridge

• Schema Registry: cho phép mô hình hóa (model) cấu trúc (schema) của các sự kiện, giúp lập trình viên biết chính xác định dạng dữ liệu của một event.
• Archive & Replay: có thể lưu trữ (archive) toàn bộ hoặc một phần (theo filter) các sự kiện đã gửi tới một event bus — lưu vô thời hạn hoặc theo một khoảng thời gian nhất định — và sau đó có khả năng "phát lại" (replay) các sự kiện đã lưu trữ, rất hữu ích khi cần debug lại một sự cố đã xảy ra trong quá khứ.
• Các loại Event Bus:
  • Default Event Bus: nhận sự kiện từ các dịch vụ AWS.
  • Partner Event Bus: nhận sự kiện từ các đối tác SaaS của AWS.
  • Custom Event Bus: dành cho các ứng dụng tự viết (custom app) của riêng bạn.

5. AWS CloudTrail – kiểm toán API và hoạt động tài khoản

AWS CloudTrail là dịch vụ cung cấp khả năng quản trị (governance), tuân thủ (compliance) và kiểm toán (audit) cho toàn bộ tài khoản AWS của bạn. Nói một cách đơn giản: CloudTrail giống như một "camera giám sát" ghi lại MỌI hành động đã được thực hiện trong tài khoản AWS — ai đã làm gì, từ đâu, vào lúc nào.

Điểm cực kỳ quan trọng: CloudTrail được bật (enabled) theo mặc định ngay khi bạn tạo tài khoản AWS — bạn không cần phải tự kích hoạt nó.

CloudTrail ghi lại lịch sử của các sự kiện/lệnh gọi API (event/API calls) được thực hiện trong tài khoản AWS của bạn, thông qua bất kỳ phương thức nào:

• AWS Management Console (giao diện web).
• AWS SDK (thư viện lập trình).
• AWS CLI (command line).
• Các dịch vụ AWS khác gọi lẫn nhau.

Bạn có thể đưa log từ CloudTrail vào CloudWatch Logs hoặc lưu trữ vào Amazon S3 để phân tích hoặc lưu trữ lâu dài. Một "trail" (đường mòn ghi log) có thể được áp dụng cho All Regions (mọi vùng — đây là lựa chọn mặc định) hoặc chỉ một Region cụ thể.

Sơ đồ hoạt động tổng quát: các hành động được thực hiện qua SDK/CLI/Console bởi IAM User & IAM Role → được CloudTrail ghi nhận → hiển thị trên CloudTrail Console để bạn kiểm tra (inspect) và kiểm toán (audit) → đồng thời log có thể chảy tiếp vào CloudWatch Logs hoặc lưu vào S3 Bucket.

6. AWS X-Ray – theo dõi và gỡ lỗi ứng dụng phân tán

Hãy nghĩ về cách gỡ lỗi (debug) ứng dụng theo kiểu truyền thống: kiểm thử (test) ở máy local, thêm các dòng log (log statement) rải rác khắp code, rồi triển khai (deploy) lại lên production để xem có sửa được lỗi chưa. Cách này có nhiều vấn đề:

• Định dạng log (log format) khác nhau giữa các ứng dụng khác nhau, khiến việc phân tích log rất khó khăn và tốn thời gian.
• Với một ứng dụng nguyên khối (monolith) duy nhất, việc debug còn "dễ" vì mọi thứ nằm trong một chỗ. Nhưng với kiến trúc microservice — hàng chục dịch vụ nhỏ gọi qua lại lẫn nhau — việc debug trở nên RẤT khó, vì lỗi có thể xuất phát từ bất kỳ đâu trong chuỗi các lệnh gọi.
• Bạn không có một "cái nhìn tổng thể" (common view) về toàn bộ kiến trúc và luồng xử lý của một request khi nó đi qua nhiều dịch vụ khác nhau.

AWS X-Ray ra đời để giải quyết chính xác vấn đề này — nó cung cấp khả năng phân tích trực quan (visual analysis) cho ứng dụng của bạn, vẽ ra sơ đồ (map) thể hiện một request đã "đi qua" những dịch vụ nào, mất bao lâu ở mỗi bước, và ở đâu xảy ra lỗi.

Các lợi ích cụ thể mà X-Ray mang lại:

• Tìm ra các điểm nghẽn hiệu năng (troubleshooting performance bottlenecks).
• Hiểu rõ các mối quan hệ phụ thuộc (dependencies) giữa các service trong kiến trúc microservice.
• Xác định chính xác dịch vụ nào đang gặp vấn đề (pinpoint service issues).
• Xem lại hành vi của từng request cụ thể (review request behavior).
• Tìm ra lỗi (error) và ngoại lệ (exception) trong hệ thống.
• Kiểm tra xem hệ thống có đang đáp ứng đúng SLA (Service Level Agreement) về thời gian phản hồi hay không.
• Phát hiện những nơi request bị giới hạn tốc độ (throttled).
• Xác định những người dùng cụ thể nào đang bị ảnh hưởng bởi sự cố.

7. Amazon CodeGuru – rà soát code và tối ưu hiệu năng bằng ML

Amazon CodeGuru là dịch vụ sử dụng Machine Learning (ML) để tự động rà soát code (automated code reviews) và đưa ra khuyến nghị về hiệu năng ứng dụng (application performance recommendations). CodeGuru có hai thành phần chính, phục vụ hai giai đoạn khác nhau trong vòng đời phát triển phần mềm:

Luồng làm việc tổng quát: Coding (viết code) → Build & Test (CodeGuru Reviewer tham gia rà soát code, đưa ra khuyến nghị ngay tại bước này) → Deploy (triển khai) → Measure (CodeGuru Profiler tham gia đo lường, tìm cơ hội cải thiện hiệu năng và chi phí khi ứng dụng đã chạy thật trong production).

CodeGuru Reviewer

Giúp phát hiện các vấn đề nghiêm trọng trong code như: lỗ hổng bảo mật (security vulnerabilities), các lỗi khó phát hiện (hard-to-find bugs). Ví dụ các loại vấn đề nó có thể tìm ra: không tuân thủ các "coding best practices" phổ biến, rò rỉ tài nguyên (resource leaks — ví dụ quên đóng kết nối database), các lỗ hổng an ninh, thiếu kiểm tra đầu vào (input validation).

CodeGuru Reviewer sử dụng Machine Learning và automated reasoning (suy luận tự động), được huấn luyện dựa trên hàng triệu lượt rà soát code thực tế từ hàng nghìn repository mã nguồn mở và các repository nội bộ của Amazon — tức là nó mang theo "kinh nghiệm" tích lũy được từ rất nhiều dự án thực tế. Hiện tại CodeGuru Reviewer hỗ trợ ngôn ngữ Java và Python, và có thể tích hợp trực tiếp với GitHub, Bitbucket, và AWS CodeCommit.

CodeGuru Profiler

Giúp bạn hiểu hành vi thực tế (runtime behavior) của ứng dụng khi nó đang chạy trong môi trường thật. Ví dụ, CodeGuru Profiler có thể phát hiện ra rằng ứng dụng của bạn đang tiêu tốn CPU một cách bất thường chỉ vì một đoạn code ghi log (logging routine) không hiệu quả.

Các tính năng chính của CodeGuru Profiler:

• Xác định và loại bỏ các điểm code kém hiệu quả (code inefficiencies).
• Cải thiện hiệu năng ứng dụng (ví dụ giảm mức sử dụng CPU).
• Giảm chi phí tính toán (decrease compute costs).
• Cung cấp bản tổng hợp heap (heap summary) để xác định object nào đang chiếm nhiều bộ nhớ nhất.
• Có khả năng phát hiện bất thường (Anomaly Detection).
• Hỗ trợ cả ứng dụng chạy trên AWS và chạy on-premises.
• Gây rất ít ảnh hưởng (minimal overhead) đến hiệu năng của ứng dụng đang giám sát.

8. AWS Health Dashboard – tình trạng dịch vụ AWS

AWS Health Dashboard thực chất gồm hai trang/khái niệm khác nhau, dễ gây nhầm lẫn nếu không phân biệt rõ:

AWS Health Dashboard – Service History (trước đây gọi là AWS Service Health Dashboard)

Đây là trang hiển thị tình trạng hoạt động (health) của TẤT CẢ các dịch vụ AWS, ở TẤT CẢ các Region — tức là một cái nhìn tổng quan chung cho toàn bộ nền tảng AWS, không riêng cho tài khoản của bạn. Trang này:

• Hiển thị thông tin lịch sử (historical information) cho từng ngày.
• Có sẵn một RSS feed mà bạn có thể đăng ký theo dõi để nhận thông báo khi có sự cố dịch vụ.

AWS Health Dashboard – Your Account (trước đây gọi là AWS Personal Health Dashboard - PHD)

Trong khi Service Health Dashboard cho biết tình trạng chung của cả nền tảng AWS, Account Health Dashboard lại cung cấp góc nhìn CÁ NHÂN HÓA (personalized view) — nó cho bạn biết chính xác các tài nguyên (resources) trong tài khoản CỦA BẠN đang bị ảnh hưởng như thế nào bởi các sự cố/sự kiện của AWS.

Các đặc điểm của Account Health Dashboard:

• Cung cấp cảnh báo (alerts) và hướng dẫn khắc phục (remediation guidance) khi AWS đang gặp sự cố có thể ảnh hưởng đến bạn.
• Hiển thị thông tin liên quan và kịp thời (relevant/timely info) để giúp bạn quản lý các sự cố đang diễn ra.
• Cung cấp thông báo chủ động (proactive notification) cho các hoạt động đã được lên lịch (scheduled activities) — ví dụ AWS thông báo trước về việc bảo trì (maintenance) sắp diễn ra ảnh hưởng đến một EC2 instance của bạn.
• Có thể tổng hợp (aggregate) dữ liệu từ toàn bộ một AWS Organization (nhiều tài khoản AWS được quản lý tập trung).
• Đây là một dịch vụ toàn cục (global service).

9. Phân biệt CloudWatch, CloudTrail và X-Ray

Đây là một trong những nhóm câu hỏi dễ gây nhầm lẫn nhất trong đề thi CLF-C02, vì cả ba dịch vụ đều liên quan đến "giám sát" nhưng lại trả lời ba câu hỏi hoàn toàn khác nhau. Hãy dùng phép ví von sau để nhớ: nếu hệ thống AWS của bạn là một cơ thể sống, thì:

• CloudWatch giống như máy đo huyết áp, nhịp tim, nhiệt độ — nó trả lời câu hỏi "Hệ thống đang hoạt động (performance) như thế nào?" (CPU bao nhiêu %, có bao nhiêu request/giây, log ứng dụng ghi gì...).
• CloudTrail giống như sổ ghi chép mọi hành động của từng người trong nhà — nó trả lời câu hỏi "AI đã làm gì, khi nào?" (ai gọi API nào, xóa cái gì, sửa cấu hình gì).
• X-Ray giống như máy chụp X-quang theo dõi đường đi của một viên thuốc trong cơ thể — nó trả lời câu hỏi "MỘT request cụ thể đã đi qua đường nào, mất bao lâu ở mỗi trạm?" trong một kiến trúc nhiều service.