OpenTelemetry Learning
OpenTelemetry Collector

OpenTelemetry Collector

Lộ trình học cách cấu hình, triển khai và vận hành OpenTelemetry Collector an toàn trong production.

Bắt đầu từ mental model

Collector là một dịch vụ trung gian nhận, xử lý và xuất telemetry. Hãy đọc Tổng quan Collector trước khi chọn component hoặc viết cấu hình production.

Mục lục

Collector giải quyết vấn đề gì

OpenTelemetry Collector là một binary độc lập với backend. Nó cung cấp một nơi chung để nhận, xử lý và chuyển tiếp traces, metrics và logs.

Ví dụ, ứng dụng gửi OTLP đến một Collector gần nó. Collector thêm metadata Kubernetes, gom batch rồi gửi đến backend. Ứng dụng không cần giữ credential của backend hoặc biết API riêng của nhà cung cấp.

Collector không thay thế instrumentation. Nếu ứng dụng không tạo span, metric hoặc log cần thiết, Collector không thể suy ra đầy đủ business context còn thiếu. Xem Kiến trúc OpenTelemetry để phân biệt trách nhiệm của API, SDK, Collector và backend.

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

Nền tảng

  1. Đọc Tổng quan Collector để hiểu agent, gateway, push, pull và ranh giới trách nhiệm.
  2. Đọc Cấu hình Collector để biết cách khai báo component và bật chúng trong service.
  3. Đọc Service pipelines để theo một signal từ đầu vào đến đầu ra.

Luồng dữ liệu

  1. Chọn Receivers để nhận OTLP hoặc scrape một nguồn dữ liệu.
  2. Thêm Processors khi cần batch, giới hạn bộ nhớ, enrich, filter hoặc transform.
  3. Chọn Exporters theo protocol và backend đích.
  4. Dùng Connectors chỉ khi cần nối hai pipeline hoặc tạo signal từ signal khác.

Đóng gói và vận hành

  1. Bật Extensions cho health check, chẩn đoán hoặc xác thực khi phù hợp.
  2. Chọn Collector distribution có đúng component cần dùng. Tạo distribution riêng nếu muốn giảm bề mặt phụ thuộc và kiểm soát supply chain.

Học theo đường đi của dữ liệu

Bắt đầu bằng một pipeline OTLP đơn giản. Xác minh từng chặng trước khi thêm transform, routing hoặc nhiều backend. Cách này giúp khoanh vùng lỗi nhanh hơn.

Bản đồ nội dung

Cách học bằng một pipeline nhỏ

Pipeline tối thiểu sau nhận traces qua OTLP gRPC/HTTP, gom batch và in dữ liệu bằng 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]

Cấu hình một component không có nghĩa là component đó đang chạy. Component phải được tham chiếu trong service.pipelines hoặc service.extensions, tùy loại.

Cấu hình mẫu chưa phải cấu hình production

Mẫu chỉ bind loopback vì không có TLS hoặc authenticator. debug exporter dành cho kiểm tra và có thể tạo nhiều log. Production cần exporter thật, TLS/xác thực, giới hạn tài nguyên, retry/queue phù hợp và cơ chế giám sát Collector.

Cách tự xác minh

Kiểm tra theo thứ tự để biết dữ liệu mất ở đâu:

  1. Xác nhận Collector khởi động thành công và không báo lỗi parse hoặc component không tồn tại.
  2. Gửi một trace có thể nhận diện, ví dụ request với một route thử nghiệm.
  3. Kiểm tra receiver đã nhận dữ liệu qua internal telemetry của Collector.
  4. Kiểm tra processor có drop hoặc từ chối dữ liệu không.
  5. Kiểm tra exporter có lỗi, retry, queue đầy hoặc gửi thất bại không.
  6. Tìm trace tương ứng trong backend bằng trace ID hoặc thuộc tính ổn định.

Tên metric nội bộ có thể thay đổi theo phiên bản và cấu hình mức telemetry. Vì vậy, hãy đối chiếu dashboard và alert với tài liệu của distribution đang triển khai thay vì sao chép tên metric một cách máy móc.

Sai lầm thường gặp

  • Nhầm khai báo với kích hoạt: component có trong YAML nhưng không nằm trong pipeline.
  • Nhầm protocol với endpoint: OTLP/gRPC và OTLP/HTTP dùng transport, port và đường dẫn khác nhau.
  • Đặt processor sai thứ tự: thứ tự trong mảng là thứ tự xử lý; filter trước enrich có thể không thấy thuộc tính cần lọc.
  • Không đặt giới hạn tài nguyên: tải tăng hoặc backend chậm có thể làm queue và bộ nhớ tăng.
  • Dùng một gateway đơn lẻ: gateway tập trung trở thành điểm lỗi duy nhất nếu không có replica, cân bằng tải và capacity planning.
  • Tạo vòng lặp: exporter gửi ngược về receiver của cùng luồng, gây nhân bản dữ liệu và cạn tài nguyên.
  • Bật quá nhiều dữ liệu chẩn đoán: debug verbosity cao trong production có thể tăng CPU, I/O và rò rỉ dữ liệu nhạy cảm vào log.

Nguồn chính thức

On this page