Series CloudWatch #4: CloudWatch Events (EventBridge) – Tự động hóa phản ứng khi có sự cố

Chào anh em đã quay lại với trạm dừng chân thứ 4 của series CloudWatch!

Ở 3 bài trước, chúng ta đã biến hệ thống từ chỗ "mù thông tin" sang một hệ thống có đầy đủ "mắt thần" (Metrics), "còi báo động" (Alarms) và "kính lúp" (Logs Insights).

Nhưng hãy nhìn lại một chút: Khi có cảnh báo hệ thống sập, điện thoại réo, anh em vẫn phải là người lóc cóc mở máy tính lên, tra cứu log, rồi tự tay gõ lệnh khởi động lại server hoặc rollback (quay xe) code. Con người chậm chạp, dễ buồn ngủ và dễ gõ nhầm. Một quy trình DevOps đỉnh cao không thể phụ thuộc vào sức người như vậy được.

Đó là lúc chúng ta cần đưa hệ thống lên một tầm cao mới: Tự động hóa phản ứng (Auto-remediation). Và chìa khóa cho quyền năng này chính là CloudWatch Events (hiện nay AWS đã nâng cấp và đổi tên thành Amazon EventBridge).

1. EventBridge (CloudWatch Events) là gì?

Nếu Metrics là nhịp tim, Logs là bệnh án, thì EventBridge chính là Hệ thần kinh phản xạ của hệ thống AWS.

Anh em cứ tưởng tượng cơ thể mình: Khi ngón tay vô tình chạm vào ấm nước sôi (Sự kiện - Event), hệ thần kinh trung ương (EventBridge) lập tức nhận được tín hiệu và tự động ra lệnh cho cơ bắp rụt tay lại (Hành động - Target) trước cả khi não bộ anh em kịp nhận thức được sự đau đớn.

Trong thế giới đám mây, mọi thứ xảy ra đều được coi là một "Sự kiện":

• Một con Server EC2 đột ngột bị tắt.
• Một file ảnh vừa được người dùng tải lên bucket S3.
• Một tiến trình CI/CD CodePipeline vừa chạy thất bại.

EventBridge đứng ở giữa, lắng nghe toàn bộ những tiếng động này và quyết định xem phải điều hướng xử lý đi đâu.

2. Cấu trúc 3 thành phần của một Phản xạ

Để cấu hình một luồng tự động hóa, anh em chỉ cần ghép nối 3 khối Lego sau:

A. Event Source (Nguồn phát sinh)

Là nơi tạo ra sự kiện. Nó có thể là các dịch vụ của AWS (EC2, S3, RDS), hoặc từ ứng dụng của chính anh em bắn lên, hoặc thậm chí là từ các nền tảng bên thứ 3 (như Zendesk, Datadog).

B. Rules (Quy tắc lọc - Anh bảo vệ)

Hàng giây có cả vạn sự kiện xảy ra trên AWS. Chúng ta không thể phản ứng với tất cả. Rule giống như một anh bảo vệ cầm danh sách khách mời. Anh em phải viết một đoạn JSON ngắn (gọi là Event Pattern) để bảo vệ biết chỉ cho sự kiện nào đi qua.

Ví dụ, anh em chỉ muốn bắt sự kiện "Server Backend bị Stop":

{
  "source": ["aws.ec2"],
  "detail-type": ["EC2 Instance State-change Notification"],
  "detail": {
    "state": ["stopped"]
  }
}

C. Targets (Đích đến xử lý)

Khi sự kiện lọt qua được cửa bảo vệ, nó sẽ được chuyển tới Target để hành động. EventBridge hỗ trợ hàng chục Target khác nhau, mạnh nhất là:

1. AWS Lambda: Chạy một đoạn code (Node.js/Python/Go) để tự động sửa lỗi (VD: Dọn rác ổ cứng, đổi DNS, clear cache).
2. SNS (Simple Notification Service): Bắn thẳng thông báo khẩn cấp dạng thẻ đỏ vào Slack của team.
3. SSM Run Command: Tự động SSH ngầm vào server để chạy một đoạn script khởi động lại ứng dụng.

3. Sức mạnh khác: Lên lịch hẹn giờ (Cron Jobs)

Không chỉ phản ứng với các sự kiện "bất thình lình", EventBridge còn là công cụ lên lịch (Scheduler) xịn xò nhất trên AWS. Anh em có thể vứt bỏ hoàn toàn khái niệm cấu hình crontab trên Linux.

Thay vì bắt sự kiện, anh em có thể tạo một Rule theo dạng Schedule:

• Rate: rate(5 minutes) -> Cứ 5 phút chạy 1 lần.
• Cron: cron(0 18 ? * MON-FRI *) -> Chạy vào lúc 18:00 các ngày từ thứ 2 đến thứ 6.

Ứng dụng thực tế: Cứ 2 giờ sáng mỗi ngày, EventBridge sẽ tự động gõ cửa dịch vụ Lambda, Lambda chạy script backup Database và đẩy bản sao lưu lên kho lưu trữ S3, sau đó gửi một tin nhắn báo cáo về Telegram. Đẹp và nhàn hạ vô cùng!

4. Thực hành: Tự động khởi động lại Server "lì lợm"

Hãy set up một kịch bản kinh điển: Anh em có một con EC2 chạy môi trường Dev cực kỳ quan trọng, nhưng thi thoảng bị một bạn thực tập sinh nào đó táy máy bấm "Stop". Thay vì phải vào mắng mỏ rồi tự bật lại, ta để máy móc lo.

Bước 1: Tạo Rule lắng nghe sự kiện

1. Vào AWS Console > tìm Amazon EventBridge > Chọn Rules > Create rule.
2. Đặt tên: Auto-Start-Dev-Server.
3. Rule type: Chọn Rule with an event pattern > Next.
4. Ở phần Event pattern, chọn AWS events > AWS service là EC2 > Event type là EC2 Instance State-change Notification.
5. Chọn Specific state(s) là Stopped. Chọn Specific instance ID(s) và điền ID của con server Dev vào. > Next.

Bước 2: Gắn Target xử lý

1. Màn hình Select target(s) hiện ra.
2. Target type: Chọn AWS service.
3. Bấm vào dropdown và tìm SSM Automation.
4. Chọn Document là AWS-StartEC2Instance. (Đây là kịch bản có sẵn của AWS để bật máy).
5. Ở phần InstanceId, truyền vào chính ID của con server đó. > Next.
6. Bấm Create rule.

Bước 3: Tận hưởng sự thảnh thơi

Bây giờ, anh em hãy thử vào EC2 và bấm tắt con server Dev đó. Chỉ khoảng 3-5 giây sau, trạng thái của nó sẽ chuyển thành Stopped. Ngay giây tiếp theo, EventBridge bắt được tín hiệu, tự động gọi Systems Manager (SSM) và con server sẽ chuyển sang trạng thái Pending rồi Running trở lại. Tất cả diễn ra tự động hoàn toàn!

Tổng kết Bài 4

Qua bài học này, anh em đã làm chủ được mảnh ghép cuối cùng của bức tranh vận hành tự động: EventBridge.

Chúng ta đã chuyển đổi mô hình từ "Phát hiện -> Con người can thiệp" sang mô hình kiến trúc hiện đại Event-Driven (Hướng sự kiện): "Hệ thống phát hiện -> Hệ thống tự chữa lành".

Bây giờ, anh em đã có trong tay tất cả các công cụ đơn lẻ. Ở bài học cuối cùng, Bài 5: Thực chiến - Giám sát toàn diện một hệ thống Microservices, chúng ta sẽ gom tất cả Metrics, Logs, Alarms và Events vào một bảng điều khiển (Dashboard) duy nhất, rèn luyện tư duy quan sát toàn cảnh để anh em chính thức tốt nghiệp series này một cách rực rỡ.