Thiết kế hệ thống quan sát tại edge có khả năng phục hồi cao với AWS và Prometheus

Viren Patel đã công bố một hướng dẫn kỹ thuật vào ngày 6 tháng 10 năm 2026, trình bày chi tiết cách xây dựng quy trình quan sát (observability pipeline) cấp độ sản xuất cho các thiết bị edge. Bài viết phác thảo một kiến trúc kết hợp các thành phần serverless của AWS với các chỉ số tương thích Prometheus để giám sát tình trạng hoạt động và sự sống còn của phần cứng phân tán ở quy mô lớn.

Điều gì đã xảy ra

Hướng dẫn này giải quyết thách thức trong việc giám sát hàng nghìn thiết bị edge được triển khai tại nhiều địa điểm khách hàng khác nhau. Các thiết bị này chạy phần mềm cục bộ phụ thuộc vào kết nối mạng, tình trạng sức khỏe phần cứng và cấu hình chính xác. Nếu không có giám sát chủ động, một thiết bị có thể âm thầm ngoại tuyến, mất quyền truy cập mạng cục bộ, sắp hết dung lượng lưu trữ hoặc vi phạm các yêu cầu về hệ điều hành. Giải pháp được đề xuất trả lời hai câu hỏi quan trọng đối với người vận hành: thiết bị có đang hoạt động không, và nó có khỏe mạnh không?

Kiến trúc sử dụng hai đường dẫn thu thập dữ liệu riêng biệt hội tụ vào một backend chuỗi thời gian duy nhất. Đường dẫn đầu tiên liên quan đến heartbeat trực tiếp, nơi mỗi thiết bị edge đẩy một payload nhỏ theo nhịp độ dự đoán được. Đường dẫn thứ hai sử dụng một hàm Lambda theo lịch trình để thăm dò API quản lý thiết bị bên ngoài. Cách tiếp cận pull-based này làm phong phú thêm dữ liệu bằng thông tin đo từ xa về phần cứng và tuân thủ mà các thiết bị không tự đẩy lên, chẳng hạn như nhiệt độ CPU hoặc tình trạng pin. Cả hai luồng đều được chuẩn hóa thành các chỉ số định dạng Prometheus trước khi lưu trữ.

Hệ thống dựa nhiều vào các thành phần serverless của AWS để xử lý quy mô mà không cần quản lý hạ tầng luôn bật. API Gateway và Lambda authorizers xử lý xác thực và định tuyến, đảm bảo rằng số serial của thiết bị được xác minh so với danh tính của người gọi. Simple Queue Service (SQS) đệm các heartbeat đến, bảo vệ hệ thống khỏi các đợt tăng đột biến và cho phép logic thử lại. Hàng đợi chết (dead-letter queue) ghi nhận các thông báo sai định dạng hoặc thất bại để điều tra, ngăn ngừa mất dữ liệu. Cuối cùng, một Lambda dequeue chuyển đổi các payload này thành chỉ số và ghi chúng vào backend.

Chi tiết chính

• Backend Chỉ số: Hệ thống sử dụng VictoriaMetrics thay vì Prometheus tiêu chuẩn vì nó hỗ trợ giao thức remote-write đồng thời cung cấp chi phí thấp hơn và hiệu suất tốt hơn cho dữ liệu có cardinality cao.
• Payload Heartbeat: Các thiết bị gửi payload JSON tối thiểu chứa số serial và một bộ đếm, tùy chọn bao gồm trạng thái kết nối mạng.
• Xác thực Dữ liệu: Schema rất nghiêm ngặt, từ chối các trường không mong muốn để ngăn chặn lỗi âm thầm, và số serial được xác minh so với danh tính đã được xác thực.
• Dấu vết Kiểm toán: Mỗi payload chỉ số đều được sao lưu lên Amazon S3 kèm theo chính sách hết hạn vòng đời, cho phép các nhóm phát lại hoặc kiểm tra dữ liệu thô nếu cần.
• Cảnh báo Kép: Tình trạng sức khỏe thiết bị được giám sát qua cảnh báo Grafana trên dữ liệu VictoriaMetrics, trong khi tình trạng sức khỏe của quy trình thu thập (tuổi hàng đợi, tỷ lệ lỗi) được giám sát qua cảnh báo CloudWatch.
• Chiến lược Đóng gói: Đồng bộ đo từ xa theo lịch trình chia đầu ra thành các batch dưới 1.5MB với backoff theo hàm mũ để nằm trong giới hạn payload trong quá trình cập nhật toàn bộ đội hình thiết bị.

Bối cảnh

Khả năng quan sát trong các hệ thống phân tán thường dựa vào cơ sở dữ liệu chuỗi thời gian, lưu trữ các điểm dữ liệu được lập chỉ mục theo thời gian. Prometheus là một công cụ mã nguồn mở phổ biến cho mục đích này, sử dụng ngôn ngữ truy vấn gọi là PromQL. Tuy nhiên, Prometheus có thể gặp khó khăn với cardinality cao, xảy ra khi các chỉ số có nhiều tổ hợp nhãn độc đáo, chẳng hạn như hàng nghìn số serial thiết bị riêng biệt. VictoriaMetrics là một lựa chọn thay thế tương thích được thiết kế để xử lý quy mô này hiệu quả hơn.

Các kiến trúc serverless, chẳng hạn như những kiến trúc được xây dựng trên AWS Lambda, cho phép mã chạy để phản hồi các sự kiện mà không cần cung cấp máy chủ. Mô hình này lý tưởng cho các quy trình thu thập dữ liệu trải nghiệm lưu lượng biến động, vì hạ tầng tự động mở rộng. Việc sử dụng các hàng đợi như SQS tách biệt việc thu thập dữ liệu khỏi việc xử lý nó, đảm bảo rằng các đợt tăng tạm thời trong báo cáo thiết bị không làm quá tải cơ sở dữ liệu chỉ số.

Tại sao điều này quan trọng

Đối với các nhóm chạy phần mềm riêng, đặc biệt là những nhóm quản lý triển khai IoT hoặc edge, khả năng hiển thị là yếu tố then chốt. Một thiết bị trông như đang trực tuyến nhưng đã mất kết nối mạng cục bộ đại diện cho một chế độ lỗi khác so với một thiết bị hoàn toàn tắt nguồn. Bằng cách tách biệt các kiểm tra sự sống (liveness checks) khỏi đo từ xa sâu, người vận hành có thể chẩn đoán sự cố nhanh hơn. Kiến trúc được mô tả đảm bảo rằng các tín hiệu riêng biệt này được hợp nhất trong một dashboard duy nhất, giảm tải nhận thức cho các kỹ sư hỗ trợ.

Độ tin cậy của chính quy trình giám sát thường bị bỏ qua. Nếu hệ thống thu thập dữ liệu thất bại, các dashboard có thể hiển thị dữ liệu cũ, khiến các nhóm tin rằng thiết bị vẫn khỏe mạnh trong khi thực tế không phải vậy. Bằng cách giám sát các chỉ số sức khỏe nội bộ của quy trình, chẳng hạn như độ sâu hàng đợi và tỷ lệ lỗi Lambda, các nhóm có thể phân biệt giữa sự cố toàn bộ đội hình thiết bị và sự cố giám sát. Sự tách biệt này ngăn ngừa sự tự tin giả tạo và đẩy nhanh tốc độ phản ứng sự cố.

Việc sử dụng xác thực nghiêm ngặt và hàng đợi chết cũng bảo vệ tính toàn vẹn dữ liệu. Trong các đội hình thiết bị lớn, các thiết bị cấu hình sai hoặc tác nhân độc hại có thể cố gắng chèn dữ liệu xấu. Xác minh số serial so với danh tính đã được xác thực và từ chối các trường không rõ ràng đảm bảo rằng các chỉ số vẫn đáng tin cậy. Bản sao lưu S3 cung cấp một lưới an toàn bổ sung, cho phép các nhóm khôi phục từ các lỗi xử lý mà không mất dữ liệu lịch sử.

Bạn có thể làm gì

• Triển khai xác thực schema nghiêm ngặt cho đo từ xa đến để từ chối dữ liệu sai định dạng ngay từ đầu quy trình.
• Sử dụng hàng đợi chết để cô lập các thông báo thất bại nhằm phân tích sau này thay vì loại bỏ chúng một cách âm thầm.
• Tách biệt việc giám sát quy trình thu thập dữ liệu khỏi việc giám sát các thiết bị để phát hiện độc lập các lỗi công cụ.
• Lưu trữ payload thô trong lưu trữ đối tượng như S3 để tạo dấu vết kiểm toán có thể dùng cho gỡ lỗi hoặc phát lại.
• Chuẩn hóa các nguồn dữ liệu khác nhau sang một định dạng chỉ số chung, chẳng hạn như Prometheus gauges, để đơn giản hóa việc truy vấn và cảnh báo.
• Xác minh danh tính thiết bị so với người gọi đã được xác thực để ngăn một thiết bị giả mạo chỉ số của thiết bị khác.