by James Beswick | on 10 NOV 2023 | in Amazon CloudWatch, Amazon EventBridge, Serverless | Permalink | Share
This post is written by Vaibhav Shah, Sr. Solutions Architect.
Customers dùng event-driven architectures để tổ chức và tự động dòng events từ producer tới customer. Amazon EventBridge hoạt động giống như một bộ định tuyến serverless cho các targets khác nhau dựa trên quy tắc event. Nó giảm thiểu producers và customers, cho phép customers để dựng kiến trúc bất đồng bộ
EventBridge cung cấp metrics để giúp bạn có thể giám sát sự kiện của mình. Một vài metrics bao gồm: giám sát số lượng sự kiện đối tác được nạp, số lần gọi thất bại vĩnh viễn, và số lần một target được gọi bởi một quy tắc để đáp lại một sự kiện hoặc số lượng sự kiện phù hợp với bất kì quy tắc
Để đáp ứng yêu cầu từ khách hàng, EventBridge có thêm vào vài metrics chúng cho phép customers giám sát events của họ và cung cấp thêm những hiển thị bổ sung. Blog này giải thích vài khả năng mới này.
What’s new?
EventBridge có những metric chủ yếu xoay quanh API, events, và gọi metrics. Những metrics đó cho bạn cái nhìn rõ ràng hơn về số lượng events công khai, event thành công công bố, event công bố thành công, event thất bại, số lượng events hợp với rule bất kỳ hoặc cụ thể, event bị từ chối vì giảm khả năng xử lý, trễ và các metrics dựa trên lệnh gọi.
Điều này cho phép bạn điều tra toàn bộ dòng event bên trong EventBridge và nhanh chóng nhận dạng và giải quyết vấn đề khi chúng xuất hiện
Giờ đây EventBridge có những metrics dưới đây
| Metric | Mô tả | Kích thước và đơn vị |
| PutEventsLatency | The time taken per PutEvents API operation | NoneUnits: Milliseconds |
| PutEventsRequestSize | Kích thước của PutEvents API request bằng byte | NoneUnits: Bytes |
| MatchedEvents | Số lượng events giống với bất kỳ rule hoặc rule cụ thể | NoneRuleName,EventBusName,EventSourceNameUnits: Count |
| ThrottledRules | Số lần rule thực thi bị giảm khả năng xử lý | None, RuleNameUnit: Count |
| PutEventsApproximateCallCount | Số lượng lệnh gọi gần đúng trong lệnh gọi API PutEvents | NoneUnits: Count |
| PutEventsApproximateThrottledCount | Số lượng yêu cầu được điều chỉnh gần đúng trong lệnh gọi API.PutEvents API | NoneUnits: Count |
| PutEventsApproximateFailedCount | số lượng xấp xỉ thất bại PutEvents API calls. | NoneUnits: Count |
| PutEventsApproximateSuccessCount | số lượng thành côngl PutEvents API calls. | NoneUnits: Count |
| PutEventsEntriesCount | Lượng event ban đầu trong một PutEvents request. | NoneUnits: Count |
| PutEventsFailedEntriesCount | Lượng event ban đầu trong một PutEvents request răng thất bại khi được nhập. | NoneUnits: Count |
| PutPartnerEventsApproximateCallCount | Số lượng xấp xỉ của những lần gọi PutPartnerEvents API calls. (có thể nhìn với tài khoản partner) | NoneUnits: Count |
| PutPartnerEventsApproximateThrottledCount | số lượng request bị giảm công suất(throttled) PutPartnerEvents API calls. (có thể nhìn với tài khoản partner) | NoneUnits: Count |
| PutPartnerEventsApproximateFailedCount | Số lượng PutPartnerEvents API calls thất bại. (có thể nhìn với tài khoản partnet) | NoneUnits: Count |
| PutPartnerEventsApproximateSuccessCount | số lượng PutPartnerEvents API calls thành côngl . (có thể nhìn với tài khoản partne) | NoneUnits: Count |
| PutPartnerEventsEntriesCount | Số lượng event có trong một PutPartnerEvents request. | NoneUnits: Count |
| PutPartnerEventsFailedEntriesCount | Số lượng event có trong một PutPartnerEvents request rằng thất bại khi được nhập (ingested) | NoneUnits: Count |
| PutPartnerEventsLatency | Thời gian cho mỗi PutPartnerEvents API operation (có thể nhìn với tài khoản partne) | NoneUnits: Milliseconds |
| InvocationsCreated | Số lần một mục tiêu bị gọi bởi một rule trong phản hồi tới một event . Một lần gọi thử đại diện cho một số lượng của metric này | NoneUnits: Count |
| InvocationAttempts | .Số lần EventBridge thử gọi tới một target | NoneUnits: Count |
| SuccessfulInvocationAttempts | Số lần target được gọi thành công | NoneUnits: Count |
| RetryInvocationAttempts | Số lần một target được gọi lại | NoneUnits: Count |
| IngestiontoInvocationStartLatency | Thời gian xử lý events được tính từ khi một event được nhập bởi EventBridge tới lần gội target đầu tiên | None,RuleName,EventBusNameUnits: Milliseconds |
| IngestiontoInvocationCompleteLatency | Thời gian từ lúc nhập event để hoàn thành lần gọi thành công đầu tiên | None,RuleName,EventBusNameUnits: Milliseconds |
Trường hợp sử dụng cho metrics
Có vài metrics mới giúp bạn cải thiện khả năng quan sát và vận hành ứng dụng của mình. Bạn có thể chủ động vận hành metrics để giúp hiểu hơn về dòng event, invocations, độ trễ và tận dụng service. Bạn cũng có thể đặt cảnh báo chỉ thị cụ thể tới metrics và thực thi hành động, Chúng giúp cải thiện hiệu năng ứng dụng, chủ động quản lý quotas và cải thiện tính bền bỉ.
Giám sát sử dụng service dựa trên giới hạn service
PutEventsApproximateCallCount metrics trong một nhóm events giúp bạn nhận dạng số lượng xấp xỉ các sự kiện được xuất trên event bus bằng cách sử dụng PutEvents API action. The PutEventsApproximateSuccessfulCount metric chỉ ra số lượng xấp xỉ các sự kiện được xuất thành công trên event bus
Thông thường, bạn có thể giám sát các event throttled và event thất bại tính với PutEventsApproximateThrottledCount và PutEventsApproximateFailedCount tương ứng. Bạn có thể sủ dụng một CloudWatch alarm và cài đặt một ngưỡng gần với quotas của tài khoản bạn. Nếu nó bị kích đoạt, gửi thông báo bằng cách sử dụng CloudWatch alarm tới nhóm vận hành. Họ có thể làm việc để tăng Quotas dịch vụ.
Bạn có thể cài một cảnh báo trên PutEvents throttle limit in transactions per second dịch vụ quota.
- Điều hướng tới Service Quotas console. Bên trái màn hình chọn AWS services, tìm kiếm EventBridge, và chọn Amazon EventBridge( CloudWatch Events)
- Ở mục Monitoring, bạn có thể quan sát % sử dụng của PutEvents throttle limit trong một transactions cho mỗi giây
- ĐI tới Alarms tab, và chọn Create Alarm . Trong Alarm threshold, chọn 80% của applied quota value từ dữ liệu đổ xuống, Đặt Alarm name là PutEventsThrottleAlarm và chọn Create
- Để được thông báo khi tới ngưỡng, điều hướng tới Amazon CloudWatch Alarms console và chọn PutEventsThrottleAlarm.
- Chọn Actions từ dữ liệu đổ xuống từ phần góc trên bên phải, và chọn Edit
- Trên Specify metric and conditions page, dưới Conditions, chắc chắn rằng Threshold type đã được chọn là Static và % Utilization được chọn là Greater/Equal hơn 80. Chọn Next.
- Configure actions để gửi thông báo tới một Amazon SNS và chọn Next
- Alarm name nên được set là PutEventsThrottleAlarm. Chọn Next, rồi sau đó chọn Update alarm.
Điều này giúp bạn được thông báo khi % sử dụng của PutEvents giới hạn throttle trong transactions cho mỗi giây tiến tới gần ngưỡng mà mình đã đặt. Bạn có thể sau đó yêu cầu Service Quota tăng nếu cần
Thông thường, bạn cũng có thể tạo ClouWatch alarm trên % sử dụng của Invocations throttle limit in transactions per second trước service quota
Nâng cao khả năng quan sát
PutEventsLatency metric chỉ ra thời gian cho mỗi PutEvents APi vận hành. Có 2 metric bổ sung là IngestiontoInvocationStartLatency metric and IngestiontoInvocationCompleteLatency metric. Metric đầu tiên chỉ ra thời gian xử lý đo lường từ khi events được nhập(ingested) đầu tiên bởi EventBridge tới lần gọi đầu tiên (first invocation) của một target. Metrics thứ 2 chỉ ra thời gian từ khi nhập event đến khi hoàn thành lần thử gọi thành công đầu tiên
Điều này giúp nhận dạng vấn đề liên quan đến trễ từ thời gian nhập cho đến khi nó tới target dựa vào RuleName. Nếu độ trễ cao, có 2 metrics cho bạn khả năng nhìn rõ vấn đề, cho phép bạn thực thi những hành động tương thích với trạng thái
Bạn có thể đặt ngưỡng quanh vài metric, và nếu ngưỡng được kích hoạt, hành động được định nghĩa có thể giúp phục hồi sau những thất bại tiềm ẩn. Một trong những hành động được xác định tại đây có thể là gửi event các sự kiện được tạo sau này tới EventBridge trong Region thứ 2 bằng cách sử dụng EventBridge global endpoints.
Thi thoảng, event không được gửi tới target được chỉ đinh trong rule. Điều này có thể là vì target resource là không có sẵn, bạn không có quyền để gọi tới target, hoặc vài vấn đề network. Trong vài kịch bản, EventBridge cố để gửi vài events tới target trong vòng 24 tiếng và tới 185 lần, gồm cả 2 đều có thể cấu hình được.
Event mới là RetryInvocationAttempts metrics chỉ ra số lần EventBridge được thử để gọi tới target. Những lần thử sẽ hoàn thành khi requests được throttled, target service có vấn đề về tính khả dụng, vấn đề network, và dịch vụ thất bại. Điều này cung cấp bổ sung khả năng quan sát tới customers và có thể được dùng để trigger một CloudWatch alarm để thông báo tới teams nếu ngưỡng mong muốn bị vượt quá. Nếu lần thử lại bị quá tải, lưu events thất bại trong Amazon SQS dead-letter queues to process failed events cho lần sau
Bổ sung thêm, EventBridge hỗ trợ thêm khía cạnh như là DetailType, Source, and RuleName to MatchedEvents metrics. Điều này giúp bạn quan sát số lần matched events tới từ những nguồn khác.
- Điều hướng tới Amazon CloudWatch. Ở bên trái của thanh công cụ, chọn Metrics và all metrics
- Trong Browse section, chọn Events và Source.
- Từ Graphed metrics tab, bạn có thể quan sát matched events đến từ nguồn khác
Event chuyển đổi dự phòng sang Region phụ
PutEventsFailedEntriesCount metric chỉ ra số lượng events thất bị trong quá tình nhâp(ingestion). Quan sát metric và đặt một CloudWatch alarm. Nếu nó qua ngưỡng mình đã đặt, để sau đó ban có thể có các hành động tương ứng
Đặt một alarm trên PutEventsApproximateThrottledCount metric, chúng chỉ ra số lượng events bị từ chối vì throttling constraints. Cho vài event thất bại khi nhập, client phải gửi lại event thất bại tới event bus thêm lần nữa, cho phép bạn thực hiện mỗi event quan trọng cho ứng dụng của mình.
Một cách khác, gửi event tới EventBridge trong Region thứ hai bằng cách sử dụng Amazon EventBridge global endpoints để cải thiện tính nhất quán của ứng dụng event-drivent
Kết luận
Blog này chỉ ra làm thế nào để sử dụng những metric mới để cải thiện khả năng quan sát của dòng event trong ứng dụng event-drivent. Nó giúp bạn quan sát events một cách hiệu quả, từ gọi tới truyền tải đến target. Điều này cải thiện khả năng quan sát bởi chủ động cảnh báo trên metric quan trọng
Tìm hiểu thêm về serverless learning resources, đến Serverless Land.
TAGS: contributed, serverless
AWS Study Group 