Implementation of a monitoring strategy for products based on microservices

Salesforce · 2019 · 2. Tăng trưởng · Độ khó: Trung bình — bài gốc

Bối cảnh

• Một sản phẩm Salesforce sắp GA, ghép từ nhiều microservice do nhiều team sở hữu. Câu hỏi đơn giản "sản phẩm có đang dùng được không?" nằm rải trong các service.
• Hai luồng: truy vấn dữ liệu (đồng bộ, nhanh) và ingest ETL (bất đồng bộ, từ vài giây tới hàng giờ, phát lại được từng phần).

Thay đổi chính

• Từ trên xuống: định nghĩa khả dụng ở mức sản phẩm (khách kết nối được và các chức năng chính chạy), rồi mới suy ra cần đo gì ở service. Đi ngược từ service lên gần như không làm được vì mỗi service một kiểu.
• Luồng đồng bộ: khả dụng khi percentile cao của thời gian phản hồi dưới ngưỡng và còn đủ capacity. Capacity không đo trực tiếp được ở mức sản phẩm; dùng tín hiệu concurrency tăng mà request rate không tăng nghĩa là có service đang thành nút cổ chai.
• Luồng ETL: khả dụng khi khách tạo được job mới, còn chỗ lưu kết quả, và các job giống nhau mất thời gian giống nhau. Metric throughput khó so khi thời gian xử lý tuỳ nội dung bản ghi, và không có tín hiệu khi không có job.
• Synthetic transaction: chạy định kỳ job ETL và truy vấn mẫu có hồ sơ biết trước, khi traffic thật thưa hoặc dồn từng đợt; kiêm luôn kiểm tra kết nối từ nhiều nơi.
• Metric ở service chia ba nhóm: phục vụ chỉ số khả dụng, phục vụ capacity/bão hoà, và trạng thái nội bộ để debug.
• Giám sát ngang: mỗi instance của A tự đo outbound tới B ("B có sẵn sàng cho A không"), mỗi instance B đo inbound; service mesh (gateway thông minh) cho sẵn các metric này.
• Log và trace: số liệu theo từng job ETL (bản ghi xử lý, thêm mới, thời gian) để trong log, vì job ID có cardinality cao, kho metric không hợp. Trace theo request qua chuỗi service và theo bản ghi qua các pha ETL; theo tác giả, metric là thông tin về mọi sự kiện qua một điểm, trace là về một sự kiện qua nhiều điểm.
• Chi phí phối hợp: metric của các team phải theo chuẩn chung để ghép được; tracing chỉ chạy khi mọi team trong chuỗi chuyển tiếp trace ID.

Vì sao

• Microservice cho team độc lập, nhưng khả dụng là thuộc tính của cả sản phẩm; phải có định nghĩa chung từ trên xuống và chuẩn đo chung.

Bài học cho SWE

• Bắt đầu giám sát từ câu hỏi của khách ở mức sản phẩm, rồi mới tới metric từng service (Observability và monitoring).
• Luồng bất đồng bộ và traffic thưa cần synthetic để có tín hiệu liên tục.
• Dữ liệu cardinality cao (theo job, theo request) để trong log/trace, không nhét vào metric.
• Một cái giá ít được nhắc của microservice: chuẩn hoá metric và chuyển tiếp trace ID là việc phải phối hợp mọi team (Monolith và microservices — đi và quay lại).

Liên quan

• Tracing phân tán và log theo request
• Cùng công ty: Salesforce 2017 · Salesforce 2026
• Observability và monitoring · Monolith và microservices — đi và quay lại