Protocols và backends

Một hệ thống quan sát được không kết thúc khi ứng dụng tạo ra span, metric hoặc log. Dữ liệu còn phải được mã hóa, vận chuyển, xử lý, lưu trữ và truy vấn. Nhóm bài này giải thích các ranh giới đó để bạn chọn protocol và backend mà không gắn instrumentation vào một sản phẩm cụ thể.

Mục lục

• Mental model bốn lớp
• Bản đồ luồng telemetry
• Điều kiện tiên quyết
• Kết quả học tập
• Bản đồ nội dung
• Lộ trình đọc đề xuất
• Bài thực hành từ ứng dụng đến Collector
  • Mục tiêu và cấu hình
  • Chạy và xác minh
  • Thay debug bằng backend
• Checklist hiểu toàn nhóm
• Sai lầm thường gặp
• Nguồn chính thức
• Bài liên quan

Mental model bốn lớp

Bốn khái niệm sau thường xuất hiện cạnh nhau nhưng không đồng nghĩa.

Protocol là hợp đồng trao đổi. OTLP, viết tắt của OpenTelemetry Protocol, định nghĩa schema Protobuf cùng cơ chế export request/response cho telemetry.

Transport là phương tiện chở hợp đồng đó. Cùng OTLP có thể chạy qua gRPC hoặc HTTP. Vì vậy, OTLP/gRPC và OTLP/HTTP dùng chung data model nhưng khác endpoint, port mặc định, framing và cách biểu diễn lỗi.

Collector là proxy telemetry độc lập với vendor. Nó có thể nhận OTLP, scrape metrics kiểu Prometheus, xử lý dữ liệu rồi fan-out — gửi một đầu vào đến nhiều đích. Collector không bắt buộc trong mọi pipeline, nhưng tạo một ranh giới hữu ích để ứng dụng không giữ credential hoặc API riêng của backend.

Backend chịu trách nhiệm ingest, storage và trải nghiệm phân tích. Một backend có thể nhận OTLP trực tiếp hoặc chỉ nhận qua adapter/exporter. Việc nhận được OTLP không chứng minh backend bảo toàn mọi signal, field, temporality, exemplar hoặc quan hệ correlation.

Bản đồ luồng telemetry

Sơ đồ sau tách data plane — đường dữ liệu chạy — khỏi nơi con người truy vấn:

Đường phổ biến là SDK → OTLP → Collector → OTLP → backend. Đây không phải luật bắt buộc. Prometheus thường dùng mô hình pull, nghĩa là hệ thống thu thập chủ động scrape endpoint metrics. Jaeger và Zipkin vừa là tên hệ sinh thái/backend, vừa gắn với các protocol tracing lịch sử. Hãy xác định rõ bạn đang nói về định dạng ingest hay sản phẩm backend.

Một request thành công ở từng hop chỉ xác nhận hop đó đã chấp nhận request. Theo OTLP, bảo đảm giao nhận end-to-end qua nhiều hop nằm ngoài phạm vi protocol. Queue, retry, sampling, filtering, outage và retention vẫn có thể làm dữ liệu thiếu ở backend.

Điều kiện tiên quyết

Bạn nên hoàn thành hoặc nắm được các nội dung sau:

• Kiến trúc OpenTelemetry: trách nhiệm của API, SDK, Collector và backend.
• Tổng quan signals: traces, metrics và logs trả lời các loại câu hỏi khác nhau.
• Telemetry pipeline: đường đi từ instrumentation tới export.
• Tổng quan Collector: receiver, processor, exporter và topology agent/gateway.
• Kiến thức cơ bản về DNS, HTTP, TLS và container hoặc process local.

Bạn không cần cài một backend thương mại để bắt đầu. debug exporter của Collector đủ để kiểm chứng ranh giới protocol và transport trong bài thực hành bên dưới.

Kết quả học tập

Sau khi hoàn thành nhóm bài, bạn có thể:

• phân biệt protocol, transport, Collector và backend trong một sơ đồ triển khai;
• giải thích vì sao OTLP thường là ranh giới ingest ưu tiên cho telemetry mới;
• chọn OTLP/gRPC hoặc OTLP/HTTP theo môi trường mạng thay vì theo cảm tính;
• nhận diện khi Prometheus, Jaeger hoặc Zipkin là protocol tương thích, backend, hoặc cả một hệ sinh thái;
• kiểm tra một signal có được bảo toàn qua chuyển đổi protocol hay không;
• xác minh traces, metrics và logs riêng biệt ở từng hop;
• đánh giá backend bằng bằng chứng PoC thay vì danh sách tính năng marketing;
• lập kế hoạch chuyển đổi backend mà không giả định query, dashboard và alert tự động portable.

Bản đồ nội dung

Thứ tự dưới đây khớp với meta.json và sidebar của nhóm.

Lộ trình đọc đề xuất

Lượt một — xây nền tảng: đọc trang này, OTLP và OTLP gRPC và OTLP HTTP. Sau lượt này, bạn phải giải thích được cùng một OTLP payload đi qua hai transport khác nhau như thế nào.

Lượt hai — hiểu tương thích: đọc Prometheus, Jaeger và Zipkin. Mỗi bài nên được đọc với một câu hỏi: chuyển đổi này có giữ nguyên data model và ngữ nghĩa signal hay chỉ làm dữ liệu “đến được” đích?

Lượt ba — ghép và chọn hệ thống: đọc Grafana stack để thấy một kiến trúc nhiều thành phần, rồi đọc Elastic Stack (ELK) nếu hệ thống dùng Elastic, sau đó dùng Vendor backends để lập scorecard, PoC và exit plan.

Bài thực hành từ ứng dụng đến Collector

Mục tiêu và cấu hình

Bài lab ngắn này chứng minh ứng dụng có thể tạo telemetry, gửi qua OTLP và được Collector nhận mà chưa cần backend. Collector bind loopback vì mẫu không cấu hình TLS hoặc xác thực.

Lưu cấu hình sau thành otelcol.yaml. Distribution phải có otlp receiver, batch processor và debug exporter.

receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 127.0.0.1:4317
      http:
        endpoint: 127.0.0.1:4318

processors:
  batch: {}

exporters:
  debug:
    verbosity: basic

service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [batch]
      exporters: [debug]
    metrics:
      receivers: [otlp]
      processors: [batch]
      exporters: [debug]
    logs:
      receivers: [otlp]
      processors: [batch]
      exporters: [debug]

Validate bằng đúng binary sẽ chạy:

otelcol validate --config=file:otelcol.yaml
otelcol --config=file:otelcol.yaml

Nếu distribution dùng tên binary khác, chẳng hạn otelcol-contrib, hãy thay tên lệnh tương ứng. validate chỉ kiểm tra cấu hình tĩnh; nó không tạo telemetry hoặc chứng minh data path hoạt động.

Chạy và xác minh

Dùng ứng dụng đã instrument ở First trace hoặc một ứng dụng lab hiện có. Nếu SDK của ngôn ngữ hỗ trợ các biến môi trường chuẩn, cấu hình OTLP/HTTP như sau:

export OTEL_SERVICE_NAME=protocols-lab
export OTEL_EXPORTER_OTLP_ENDPOINT=http://127.0.0.1:4318
export OTEL_EXPORTER_OTLP_PROTOCOL=http/protobuf

Tạo một request có thể nhận diện, ví dụ GET /protocol-lab?case=canary. Sau đó xác minh:

1. Ứng dụng không báo lỗi export hoặc endpoint.
2. Collector có request đi vào otlp receiver.
3. debug exporter in ra signal dự kiến với service.name=protocols-lab.
4. Trace chứa route hoặc operation dễ nhận diện; metric và log được kiểm tra riêng nếu ứng dụng có phát hai signal đó.
5. Không coi log “export thành công” của SDK là bằng chứng cuối cùng; evidence ở phía Collector mới xác nhận hop đầu đã hoàn tất.

Để thử OTLP/gRPC, đổi endpoint sang http://127.0.0.1:4317 và protocol sang grpc nếu SDK hỗ trợ. Giữ nguyên canary để so sánh. Nếu một transport thành công và transport kia thất bại, hãy kiểm tra port, proxy, HTTP/2 và TLS trước khi nghi ngờ instrumentation.

Thay debug bằng backend

Khi chọn backend, thay nhánh debug bằng exporter phù hợp. Ưu tiên OTLP nếu đích hỗ trợ đúng signal và transport cần dùng. Giữ các bước xác minh theo từng hop:

canary tại ứng dụng
  → receiver accepted
  → processor không drop
  → exporter không retry hoặc reject
  → backend ingest đúng tenant
  → query thấy đúng field và correlation

Đừng xóa debug rồi kết luận từ dashboard trống. Trong staging, có thể fan-out tạm thời tới debug và backend để so payload; sau khi xác minh phải gỡ nhánh debug nhằm tránh chi phí I/O và lộ dữ liệu.

Checklist hiểu toàn nhóm

• Tôi chỉ ra được protocol và transport ở cả hai phía Collector.
• Tôi biết port 4317 thường dành cho OTLP/gRPC và 4318 cho OTLP/HTTP, nhưng vẫn kiểm tra endpoint cấu hình thực tế.
• Tôi không gọi Collector là database hoặc backend.
• Tôi xác minh traces, metrics và logs độc lập thay vì suy luận từ một signal.
• Tôi biết HTTP 200 hoặc gRPC success có thể chứa OTLP partial success và không đồng nghĩa toàn bộ dữ liệu đã được lưu để query.
• Tôi phân biệt Prometheus scrape với push/export metrics.
• Tôi kiểm tra phần dữ liệu mất khi chuyển qua Jaeger hoặc Zipkin compatibility.
• Tôi dùng Resource và semantic conventions nhất quán để giữ khả năng tương quan.
• Tôi coi ingest portability và query portability là hai bài toán khác nhau.
• Tôi có canary, tiêu chí chấp nhận và đường thoát trước khi chọn backend.

Sai lầm thường gặp

Nguồn chính thức

• OpenTelemetry là gì — phạm vi của OpenTelemetry và ranh giới với backend.
• OTLP Specification — encoding, transport, response, retry và giới hạn giao nhận nhiều hop.
• Collector configuration — receivers, processors, exporters, connectors và service pipelines.
• OpenTelemetry semantic conventions — tên và ý nghĩa chung giúp dữ liệu dễ tương quan và tiêu thụ hơn.
• W3C Trace Context — chuẩn truyền trace context qua ranh giới dịch vụ.

Bài liên quan