Quay lại bộ đề
Question #193 Topic 1
Your car factory is pushing machine measurements as messages into a Pub/Sub topic in your Google Cloud project. A Dataflow streaming job, that you wrote with the Apache Beam SDK, reads these messages, sends acknowledgment to Pub/Sub, applies some custom business logic in a DoFn instance, and writes the result to BigQuery. You want to ensure that if your business logic fails on a message, the message will be sent to a Pub/Sub topic that you want to monitor for alerting purposes. What should you do?
Nhà máy sản xuất ô tô của bạn đang gửi các phép đo lường của máy móc dưới dạng tin nhắn vào một chủ đề (topic) Pub/Sub trong dự án Google Cloud của bạn. Một tác vụ truyền phát Dataflow, được bạn viết bằng Apache Beam SDK, đọc các tin nhắn này, gửi xác nhận (acknowledgment) đến Pub/Sub, áp dụng một số logic nghiệp vụ tùy chỉnh trong một thực thể DoFn, và ghi kết quả vào BigQuery. Bạn muốn đảm bảo rằng nếu logic nghiệp vụ của bạn thất bại trên một tin nhắn, tin nhắn đó sẽ được gửi tới một topic Pub/Sub khác để bạn giám sát nhằm mục đích cảnh báo. Bạn nên làm gì?
A
Enable retaining of acknowledged messages in your Pub/Sub pull subscription. Use Cloud Monitoring to monitor the subscription/num_retained_acked_messages metric on this subscription.
Kích hoạt tính năng giữ lại các tin nhắn đã xác nhận trong subscription pull của Pub/Sub. Sử dụng Cloud Monitoring để giám sát chỉ số subscription/num_retained_acked_messages trên subscription này.
B
Use an exception handling block in your Dataflow’s DoFn code to push the messages that failed to be transformed through a side output and to a new Pub/Sub topic. Use Cloud Monitoring to monitor the topic/num_unacked_messages_by_region metric on this new topic.
Sử dụng một khối xử lý ngoại lệ (exception handling block) trong mã DoFn của Dataflow để đẩy các tin nhắn không chuyển đổi được thông qua một đầu ra phụ (side output/additional output) và gửi tới một topic Pub/Sub mới. Sử dụng Cloud Monitoring để giám sát chỉ số topic/num_unacked_messages_by_region trên topic mới này.
C
Enable dead lettering in your Pub/Sub pull subscription, and specify a new Pub/Sub topic as the dead letter topic. Use Cloud Monitoring to monitor the subscription/dead_letter_message_count metric on your pull subscription.
Kích hoạt tính năng dead lettering trong subscription pull của Pub/Sub và chỉ định một topic Pub/Sub mới làm dead letter topic. Sử dụng Cloud Monitoring để giám sát chỉ số subscription/dead_letter_message_count trên subscription pull của bạn.
D
Create a snapshot of your Pub/Sub pull subscription. Use Cloud Monitoring to monitor the snapshot/num_messages metric on this snapshot.
Tạo một snapshot cho subscription pull của Pub/Sub. Sử dụng Cloud Monitoring để giám sát chỉ số snapshot/num_messages trên snapshot này.
Giải thích & Tài liệu tham khảo
Khi một tin nhắn gặp lỗi xử lý bên trong logic nghiệp vụ ở Dataflow (DoFn):
- B. Sử dụng một khối xử lý ngoại lệ trong mã DoFn của Dataflow để đẩy các tin nhắn lỗi qua một side output... là giải pháp chuẩn xác của Apache Beam để xử lý các bản ghi lỗi (còn gọi là Dead Letter Queue pattern ở mức xử lý dữ liệu). Khi khối
try-catchphát hiện lỗi trong quá trình xử lý củaDoFn, nó sẽ bắt ngoại lệ và định tuyến dữ liệu lỗi sang mộtPCollectionphụ bằng phương thứcoutput(tag, element). PCollection này sau đó sẽ được ghi thẳng vào một Pub/Sub topic chuyên dụng để giám sát/cảnh báo. - C. Sử dụng tính năng dead lettering của Pub/Sub chỉ hoạt động khi một tin nhắn bị từ chối xác nhận (nacked) hoặc hết hạn ack (ack deadline expired) nhiều lần từ phía consumer. Tuy nhiên, trong mô hình Dataflow hiện tại, Dataflow tự động xác nhận (acknowledge) tin nhắn ngay khi đọc thành công và quản lý trạng thái của nó. Do đó, lỗi logic nghiệp vụ xảy ra bên trong DoFn không kích hoạt cơ chế dead letter gốc của Pub/Sub một cách tự nhiên mà không làm sập toàn bộ pipeline.
(Đáp án được gợi ý bởi AI)