Distributed tracing at Pinterest with new open source tools

Pinterest · 2017 · 3. Quy mô lớn · Độ khó: Trung bình — bài gốc

Bối cảnh

• Backend Pinterest (2017): hàng trăm microservice trên hàng chục nghìn máy; một request home feed có thể gọi mạng hàng trăm lần tới hàng chục service. Metric (OpenTSDB) và log (ELK) cho biết request chậm, không cho biết vì sao.

Thay đổi chính

• Pintrace: pipeline tracing gồm hai nửa: instrumentation trong code và backend xử lý trace.
• Instrumentation là phần lớn công sức. Nó phải (a) truyền trace ID theo mọi request, (b) sinh span cho mỗi thao tác logic, (c) gửi span đi. Backend có service Thrift viết bằng Python, Java, Go, Node, C++; mỗi ngôn ngữ có một framework chung nên chỉ cần làm cho Python và Java, nơi có phần lớn service quan trọng.
  • Python: ngapi là monolith HTTP đứng trước các service Java, framework tự viết trên gevent. Tự viết tracer theo OpenTracing, sinh span cho mọi lời gọi Thrift, Memcache, HTTP. Vì là monorepo + deploy một khối, bật tracing chỉ một lần deploy.
  • Java: "service framework" bọc Finagle, vốn có tracer Zipkin; chỉ thêm logger gửi span qua Singer. Phần khó nhất là đổi cấu hình chung rồi cập nhật và deploy hàng trăm app khắp tổ chức.
• Sampling: instrumentation thêm ít latency nhưng tốn CPU hai chữ số phần trăm khi ghi span, và lưu trace tốn tiền. Chỉ trace 0–1% request (thường 0,3%), chỉnh động qua hệ cấu hình; máy dev thì trace 100%.
• Backend: span ghi ra file cục bộ, daemon Singer đọc và đẩy lên Kafka. OpenZipkin backend chuẩn không đủ: cần sửa hoặc bỏ span lỗi của instrumentation hỏng, và lấy mẫu thêm lúc ingest để chỉ giữ trace giá trị cao. Họ viết Pintrace collector bằng Spark Streaming: kiểm chất lượng span → lọc → gộp theo trace ID hoặc theo cửa sổ thời gian → lưu Elasticsearch, xem bằng Zipkin UI. Mở mã nguồn vào OpenZipkin (zipkin-sparkstreaming).

Vì sao

• Framework dùng chung theo ngôn ngữ là đòn bẩy: tracing chỉ phủ được nhanh ở chỗ có framework chung (Tracing phân tán và log theo request).

Bài học cho SWE

• Ngân sách của tracing là CPU lúc ghi span và chi phí lưu; lấy mẫu ở đầu (head) và lọc thêm lúc ingest.
• Monolith được lợi khi bật một tính năng xuyên suốt (một lần deploy); microservice phải đi qua hàng trăm lần deploy, nên cần cấu hình toàn cục trong framework.
• Instrumentation sẽ có lỗi; backend phải có bước kiểm chất lượng span.

Liên quan

• LinkedIn 2015 · Discord 2026 · Pinterest 2014
• Tracing phân tán và log theo request