Skip to main content
Distributed tracing theo dõi một yêu cầu hoặc thao tác khi nó đi qua các dịch vụ đã gắn instrumentation. Một trace gom các span của công việc đó. Mỗi span là một thao tác có đo thời gian, chẳng hạn một yêu cầu HTTP, một lệnh gọi cơ sở dữ liệu, một thao tác hàng đợi hoặc một job chạy nền. Thiếu một span thì một phần đường đi sẽ không rõ. Dùng trace khi log báo lỗi nhưng không cho biết thao tác đã đi qua những đâu. Trace có thể cho thấy:
  • Thao tác nào đã bắt đầu yêu cầu.
  • Yêu cầu tốn thời gian ở đâu.
  • Thao tác con nào trả về lỗi.
  • Log, vấn đề, hành động và chỉ số nào có cùng trace ID.
  • Dịch vụ, môi trường và bản phát hành nào đã gửi từng span.

​
Các trường của trace và span

Span gốc bắt đầu một trace và không có span cha. Các span con có cùng trace ID, có span ID riêng và có parent ID. Chỉ các ID này mới nối các thao tác với nhau. Riêng dấu thời gian thì không nối được. LogBrew chỉ tính một span là span lỗi khi status của nó là error.

​
Một yêu cầu đi qua nhiều dịch vụ

  1. Dịch vụ web bắt đầu một span phía máy chủ cho route checkout.
  2. Client thanh toán tạo một span con cho yêu cầu HTTP gửi ra ngoài của nó.
  3. Dịch vụ thanh toán tiếp tục trace bằng span phía máy chủ của riêng nó.
  4. Một helper cơ sở dữ liệu ghi lại một span con cho thao tác ghi.
  5. Ứng dụng gửi một log lỗi an toàn bên trong span thanh toán đang hoạt động.
Cả 5 bản ghi đều có cùng trace ID. Nếu một dịch vụ không nhận được ngữ cảnh trace, công việc của nó sẽ không thuộc trace đó, kể cả khi thời gian trùng nhau.

​
Truyền ngữ cảnh

Các SDK của LogBrew dùng ngữ cảnh trace W3C. Ví dụ, khi nhận header traceparent hợp lệ, SDK Node.js tiếp tục trace đó bằng một span yêu cầu mới. Nếu header bị thiếu hoặc không hợp lệ, SDK bắt đầu một span gốc mới. Log, vấn đề, hành động và chỉ số được ghi nhận trong phạm vi yêu cầu đó đều mang trace của yêu cầu. Instrumentation cho yêu cầu gửi ra ngoài chỉ ghi header traceparent vào những đích bạn cấu hình, chẳng hạn tracePropagationTargets. Chỉ gửi ngữ cảnh trace đến các dịch vụ tin cậy đã gắn instrumentation. Trace ID dùng để liên kết tương quan giữa các thao tác. Nó không phải là cơ chế xác thực. Message trong hàng đợi cũng có thể mang ngữ cảnh trace. Trong Node.js, gọi createLogBrewQueueTraceHeaders() trong thao tác của producer để thêm header traceparent vào message. Ở phía consumer, truyền header đó vào queueOperationWithLogBrewSpan() dưới dạng traceparent. Xem Trace hàng đợi trong JavaScript. Các tích hợp cho yêu cầu đến và yêu cầu gửi ra ngoài của Node.js và Python không ghi body của yêu cầu hoặc phản hồi, query string, header tùy ý hoặc giá trị traceparent thô vào span. Đặt tên span theo mẫu route, không theo URL cụ thể. Để xem các tích hợp cho runtime của bạn, đọc hướng dẫn Tích hợp SDK.

​
Span ghi nhận

LogBrew lưu mọi log, vấn đề, hành động và chỉ số mới kèm một trace ID. Nếu một tín hiệu không trỏ đến span nào trong cùng lần gửi, LogBrew thêm một span ghi nhận cho tín hiệu đó: Khi đó, span_id của tín hiệu xác định span ghi nhận của nó. Nếu tín hiệu không có ngữ cảnh trace, LogBrew tạo một trace ID mới cho nó. Trace đó cho thấy LogBrew đã lưu tín hiệu. Nó không cho thấy đường đi của một yêu cầu. Đừng coi các span ghi nhận trong cùng một trace là một yêu cầu. Span ghi nhận được tính vào span_count và error_span_count. Vì vậy, một log lỗi có thể khiến --status error chọn một trace mà trong đó không thao tác nào của ứng dụng thất bại. Đọc operation của từng span lỗi trước khi kết luận.

​
Đọc trace

Dùng trace ID chính xác lấy từ log, vấn đề hoặc danh sách trace:
--status error chọn các trace có ít nhất một span lỗi. --status ok chọn các trace không có span lỗi nào. --min-duration-ms 500 chọn các trace chạy từ 500 mili giây trở lên. Đọc thời lượng của span gốc trước. Sau đó xem các span con dài nhất và các trạng thái lỗi. Luôn để ý dự án, dịch vụ, môi trường và bản phát hành, để một trace từ staging không trở thành bằng chứng về production. Một trace chỉ cho thấy một lần thực thi, không phải mốc hiệu năng. Trước khi đề xuất thay đổi về hiệu năng, so sánh nhiều trace với xu hướng của chỉ số liên quan.

​
Tóm tắt trace

GET /api/telemetry/traces/{trace_id}/summary trả về bản tóm tắt không kèm thuộc tính của span: Nếu root_span.parent_span_id có giá trị, span gốc thật không nằm trong trace. Đừng coi root_span là điểm bắt đầu của yêu cầu.

​
Giải thích trace

logbrew explain trace trả về kết quả điều tra một trace:
analysis.causality là evidence_only. Phân tích này không chứng minh nguyên nhân gốc. CLI yêu cầu phản hồi phiên bản 3, trong đó mỗi vấn đề, hành động và chỉ số liên quan cũng có span_id chính xác của nó. Để xem một span cùng span cha, các span con và ranh giới dịch vụ của nó, chạy:
topology.parent_chain_status cho biết chuỗi span cha có đầy đủ hay không:

​
Thiếu ngữ cảnh trace

Không phải sự kiện nào cũng có trace của yêu cầu tạo ra nó. Đọc trạng thái trace: not_linked không phải là lỗi. Một trace available cũng có thể cho thấy sự kiện không có ngữ cảnh yêu cầu. Nếu span ghi nhận của sự kiện không có parent_span_id, nghĩa là không có span nào đang hoạt động khi ứng dụng ghi nhận sự kiện. Công việc chạy nền bên ngoài phạm vi yêu cầu thường cho kết quả này. Để tìm liên kết bị thiếu:
  1. Đọc dự án, dịch vụ, môi trường, bản phát hành và thời điểm của sự kiện.
  2. Kiểm tra công việc có chạy bên trong một yêu cầu hoặc thao tác đã gắn instrumentation hay không.
  3. Kiểm tra các tích hợp phía client và phía máy chủ có truyền ngữ cảnh qua ranh giới đó hay không.
  4. Sau khi sửa instrumentation, ghi nhận một sự kiện mới và đọc nó.
Phiên bản SDK mới không thêm ngữ cảnh trace vào các sự kiện đã gửi trước đó. Đừng liên kết một sự kiện với trace dựa vào dấu thời gian, route, nội dung thông điệp hoặc bản phát hành.

​
Lên kế hoạch trace cho một dự án

Bắt đầu với một yêu cầu hoặc job quan trọng, chẳng hạn checkout. Gắn instrumentation cho từng ranh giới một:
  1. Tạo một span cho yêu cầu đến hoặc thao tác chạy nền.
  2. Thêm span con cho các lệnh gọi ra ngoài quan trọng.
  3. Tiếp tục ngữ cảnh trace W3C qua các ranh giới dịch vụ tin cậy.
  4. Gửi một log an toàn bên trong span đang hoạt động.
  5. Đọc log đó, mở trace ID của nó, rồi kiểm tra span gốc, các span con, dịch vụ, môi trường, bản phát hành, trạng thái và thời lượng.
Chỉ thêm ranh giới tiếp theo khi bước kiểm tra này đạt. Dùng chung một trace chỉ cho thấy tương quan. Nó không chứng minh rằng một span đã gây ra vấn đề. Để kiểm tra tên span, chạy logbrew traces --project "<project_id>" --pagination cursor --json. Đối tượng naming_quality đếm các trace trên trang kết quả đó có tên span gốc chung chung (generic_name_traces) hoặc có route không khớp (unmatched_route_traces). Nếu cách đặt tên cần xem lại, naming_quality.next_action.code là improve_trace_naming.