Top 5 Công cụ Distributed Tracing cho Microservices năm 2026

Phạm Đăng Sa

1830

16-09-2026

Distributed tracing giúp trả lời những câu hỏi mà metrics và logs không thể giải thích đầy đủ: vì sao một request cụ thể mất 847 ms và trả về lỗi 500? Metrics cho biết p99 latency tăng, logs cho biết có lỗi, còn trace cho thấy toàn bộ request path qua các microservices, thời gian xử lý ở từng service/database, operation nào thất bại và context liên quan.

Năm 2026, OpenTelemetry (OTel) đã chuẩn hóa việc thu thập trace. Chỉ cần instrument ứng dụng bằng OTel SDK, dữ liệu trace có thể được thu thập theo định dạng chuẩn và sử dụng với nhiều backend khác nhau. Sự khác biệt giữa các công cụ tracing chủ yếu nằm ở khả năng truy vấn, hiệu quả lưu trữ, khả năng tích hợp logs/metrics và độ phức tạp vận hành ở quy mô lớn.

Bài viết so sánh 5 công cụ tracing phù hợp cho các team microservices, tập trung vào chi phí lưu trữ, khả năng truy vấn, độ phức tạp vận hành và các trường hợp sử dụng phù hợp.

Điều gì tạo nên một Trace hữu ích?

Một trace cần có:

1. Đầy đủ request path: tất cả services được gọi theo đúng thứ tự.

2. Timing chính xác: start time và duration của từng span.

3. Context attributes: xác định service, version và environment tạo ra span.

4. Thông tin lỗi: dữ liệu liên quan khi xảy ra sự cố.

Thiếu một trong các yếu tố trên — như instrumentation không đầy đủ, clock lệch giữa các service hoặc thiếu context propagation — có thể tạo ra trace tưởng như đầy đủ nhưng dẫn đến kết luận sai khi debug production.

Vì vậy, cần kiểm tra tính đầy đủ và chính xác của trace trước khi sử dụng cho production debugging.

#1 Grafana Tempo - Hệ thống tracing dựa trên object storage - lựa chọn tối ưu chi phí cho môi trường production

Grafana Labs - Apache 2.0 - cung cấp

Cài đặt

helm install tempo grafana/tempo — namespace monitoring

Kiến trúc

Tempo lưu trữ dữ liệu trace trực tiếp trên object storage (S3) mà không cần database riêng. Khác với Jaeger (vốn cần Cassandra hoặc Elasticsearch để lưu trữ), chi phí lưu trữ của Tempo thay đổi theo khối lượng dữ liệu với mức giá của object storage thay vì mức giá của database. Đối với các dịch vụ có lưu lượng lớn, giải pháp này rẻ hơn từ 10–50 lần so với việc kết hợp Jaeger và Elasticsearch.

Ngôn ngữ truy vấn

TraceQL: Ngôn ngữ truy vấn trace của Tempo cho phép lọc các span dựa trên thuộc tính. Ví dụ: `{resource.k8s.namespace.name=’production’} && {span.http.route=’/checkout’} && {span.status=error}` sẽ tìm tất cả các span bị lỗi trên route `/checkout` trong môi trường production — một truy vấn cụ thể mà UI của Jaeger không thực hiện được. Câu lệnh TraceQL `duration > 1s || status = error` sẽ trả về các trace có thời gian xử lý chậm hoặc gặp lỗi.

Tích hợp với Grafana

Nguồn dữ liệu (data source) tích hợp sẵn trong Grafana: hỗ trợ chế độ xem dạng thác nước (waterfall view) của trace, biểu đồ dịch vụ (service graph), số liệu span (span metrics - tự động tạo ra các chỉ số Prometheus từ dữ liệu trace) và khả năng liên kết giữa trace và log. Khi nhấp vào ‘View Logs’ trong giao diện xem trace, hệ thống sẽ chuyển hướng đến log của Loki tương ứng với ID trace đó. Khi nhấp vào ‘View Metrics’, hệ thống sẽ hiển thị các chỉ số Prometheus trong khoảng thời gian diễn ra trace.

Span Metrics

Tempo có thể tự động tạo các chỉ số Prometheus theo mô hình RED (Rate - Tốc độ, Errors - Lỗi, Duration - Thời gian xử lý) từ dữ liệu trace mà không yêu cầu ứng dụng phải phát ra các chỉ số riêng biệt. Như vậy một dịch vụ đã được tích hợp OTel để thu thập trace sẽ tự động có được các chỉ số về request rate, error rate và latency percentile trong Prometheus mà không tốn thêm chi phí triển khai đo lường (instrumentation).

Phù hợp với

Người dùng hệ sinh thái Grafana, các kiến trúc microservices có lưu lượng lớn và cần tối ưu chi phí lưu trữ, cũng như các team muốn có khả năng đối chiếu dữ liệu giữa trace, log và metric trên cùng một giao diện (UI).

# Tempo distributed mode (production: S3 backend)

# values.yaml for helm install tempo grafana/tempo-distributed

storage:

trace:

backend: s3

s3:

bucket: your-tempo-traces-bucket

region: us-east-1

# Authentication via IRSA (no stored credentials)

ingester:

replicas: 3

resources:

limits:

cpu: 2000m

memory: 4Gi

querier:

replicas: 2

compactor:

replicas: 1

# TraceQL queries (in Grafana Explore > Tempo):

# Find all error traces in payments namespace:

{ resource.k8s.namespace.name=”payments” && status = error }

# Find slow database calls:

{ span.db.system=”postgresql” } | duration > 500ms

# Find all traces touching payments-api:

{ resource.service.name=”payments-api” }

# Multi-service trace with error:

{ resource.service.name=~”checkout.*|payments.*” && status = error }

| select(resource.service.name, span.http.route, duration)

#2 Jaeger — Hệ thống tracing mã nguồn mở, đã được kiểm chứng qua thực tế và phát triển từ team tech của Uber

Cài đặt:

helm install jaeger jaegertracing/jaeger --namespace monitoring

Kiến trúc:

Jaeger v2 (phát hành năm 2024) hỗ trợ OTel/OTLP native bên cạnh Jaeger protocol truyền thống.

Các backend lưu trữ gồm:

• Cassandra: phù hợp với workload có lưu lượng ghi cao.

• Elasticsearch/OpenSearch: hỗ trợ tìm kiếm đầy đủ trên span attributes.

• Badger: kết hợp bộ nhớ và disk, phù hợp với quy mô nhỏ.

Việc lựa chọn storage backend ảnh hưởng đáng kể đến độ phức tạp vận hành và chi phí.

Search UI

Jaeger hỗ trợ tìm trace theo service, operation, tag và khoảng thời gian. Với các truy vấn điều tra nhanh, UI của Jaeger dễ dùng hơn Tempo vì không cần viết TraceQL.

Khi nào Jaeger phù hợp hơn

• Team đang migrate từ Jaeger hiện có

• Cần full-text search trên span attributes với Elasticsearch

• Quy trình on-call ưu tiên UI trực quan hơn query language

Chi phí lưu trữ ở quy mô lớn

Jaeger + Elasticsearch có thể đắt hơn 5–10 lần so với Tempo + S3 với cùng lượng trace. Elasticsearch cần node riêng, lập kế hoạch capacity và vận hành liên tục. Với hệ thống mới, Tempo + S3 thường tiết kiệm hơn.

Đánh giá năm 2026

Jaeger v2 hỗ trợ OTel native, là CNCF Graduated project, được duy trì tích cực và vẫn phổ biến trong các doanh nghiệp đang sử dụng Jaeger.

#3 Zipkin - Tracing đơn giản, nhẹ, phù hợp cho team mới bắt đầu

OpenZipkin — Apache 2.0

Cài đặt

docker run -d -p 9411:9411 openzipkin/zipkin

Khi nào nên dùng Zipkin

• Development và debug local

• Hệ thống nhỏ dưới ~20 microservices

• Team muốn thử distributed tracing trước khi đầu tư production backend

#4 OpenTelemetry Collector - Nền tảng tracing giúp dễ dàng thay đổi backend

# OTel Operator: zero-code auto-instrumentation

# Install the OTel Operator

kubectl apply -f https://github.com/open-telemetry/opentelemetry-operator/releases/latest/download/opentelemetry-operator.yaml

# Create Instrumentation CRD (configure OTel SDK for all pods)

apiVersion: opentelemetry.io/v1alpha1

kind: Instrumentation

metadata:

name: auto-instrumentation

namespace: production

spec:

exporter:

endpoint: http://otel-collector.monitoring:4317

propagators: [tracecontext, baggage, b3]

sampler:

type: parentbased_traceidratio

argument: ‘0.1’ # Sample 10% of requests

python:

env:

- name: OTEL_EXPORTER_OTLP_ENDPOINT

value: http://otel-collector.monitoring:4317

java:

image: ghcr.io/open-telemetry/opentelemetry-operator/autoinstrumentation-java:latest

nodejs:

env:

- name: NODE_PATH

value: /usr/local/lib/node_modules

# Enable auto-instrumentation on a deployment:

# Add ONE annotation to the deployment pod template:

annotations:

instrumentation.opentelemetry.io/inject-python: ‘true’

# OR: inject-java, inject-nodejs, inject-dotnet

# The operator automatically:

# 1. Injects the OTel SDK

# 2. Configures it to export to the Collector

# 3. Sets sampling rate from the Instrumentation CRD

# Zero application code changes required

#5 Grafana Pyroscope - Continuous Profiling: Tín hiệu thứ tư cho Observability

Bảng so sánh các công cụ Distributed Tracing

BỘ CÔNG CỤ ĐƯỢC KHUYẾN NGHỊ

Đối với các triển khai microservices mới trong năm 2026: OTel SDK để thu thập dữ liệu (không phụ thuộc vào backend) + OTel Collector để routing + Grafana Tempo để lưu trữ + Grafana để query. Hãy bổ sung Pyroscope khi việc gỡ lỗi hiệu năng trở thành nhu cầu thường xuyên. Chỉ nên thêm Jaeger nếu đang chuyển đổi từ hệ thống Jaeger hiện có hoặc nếu tính năng full-text search trên các span là yêu cầu bắt buộc. Zipkin chỉ dành cho môi trường dev. Bộ công cụ OTel + Tempo + Grafana mang lại tỷ lệ tối ưu giữa chi phí và khả năng đáp ứng cho hầu hết các team ở mọi quy mô.