opentelemetry kubernetes docker observability

Bảo Đảm Dữ Liệu Đo Lường Không Mất Một Mẩu: Hướng Dẫn Cấu Hình HA cho OpenTelemetry Collector

Lê Lân

27/07/2025

Hướng Dẫn Cấu Hình High Availability Cho OpenTelemetry Collector: Giữ Cho Telemetry Luôn Ổn Định

Mở Đầu

Bạn còn nhớ khi con người từng viết những hướng dẫn từng bước để cấu hình các hệ thống quan sát hiệu quả chưa? Hôm nay, chúng ta sẽ cùng nhau tái hiện lại điều đó với chủ đề cấu hình High Availability (HA) cho OpenTelemetry Collector, đảm bảo không mất mát dữ liệu telemetry dù có sự cố xảy ra.

Trong thế giới quan sát hệ thống hiện đại, việc đảm bảo thu thập và xử lý telemetry liên tục là vô cùng quan trọng. Bài viết này sẽ cung cấp chi tiết các bước cấu hình HA cho OpenTelemetry Collector, áp dụng cho cả môi trường Docker và Kubernetes. Bạn sẽ được hướng dẫn qua các ví dụ thực tế, từ việc thiết lập nhiều instance collector, load balancer đến chia sẻ lưu trữ nhằm tạo nên hệ thống thu thập dữ liệu đáng tin cậy và có khả năng mở rộng.

Định Nghĩa High Availability (HA) Với OpenTelemetry Collector

Tại Sao Cần HA?

Việc cấu hình HA cho OpenTelemetry Collector giúp hệ thống:

Tránh mất dữ liệu khi backend quan sát không phản hồi.

Đảm bảo liên tục nhận và xử lý telemetry dù có sự cố nâng cấp hoặc lỗi hạ tầng.

Mở rộng quy mô ngang để cân bằng tải với khối lượng dấu vết (traces), nhật ký (logs) và số liệu (metrics) lớn.

Mô Hình Triển Khai Agent-Gateway

Để đạt được HA, mô hình triển khai được khuyến nghị là Agent-Gateway, bao gồm hai lớp:

Agent Collectors: Chạy trên từng host, container hoặc node, gần với workload.

Gateway Collectors: Dịch vụ trung tâm có thể mở rộng, nhận dữ liệu từ nhiều Agent Collector.

Mỗi lớp có thể được mở rộng độc lập, đảm bảo độ ổn định và hiệu năng xử lý.

Phân Biệt Agent Collector và Gateway Collector

Điểm khác biệt	Agent Collector	Gateway Collector
Vị trí chạy	Gần workload (sidecar/k8s deployment)	Trung tâm (namespace cụ thể hoặc cluster)
Chủ sở hữu	Đội phát triển	Đội nền tảng
Chức năng chính	Thu thập, đệm, chuyển tiếp telemetry	Chịu trách nhiệm lọc, sampling, xử lý

Cấu Hình High Availability Với Docker

Kiến Trúc Cơ Bản

Ba Gateway Collectors chạy song song.

Một Nginx làm load balancer phân phối dữ liệu OTLP.

Một Agent Collector tạo dữ liệu telemetery giả lập.

Thiết Lập Docker Compose

version: '3.8'
volumes:
  gw1-storage:  # dung lượng > 60 GiB cho queue Gateway-1
  gw2-storage:  # tương tự Gateway-2
  gw3-storage:  # tương tự Gateway-3
  telgen-storage:  # queue cho telemetry generator
  external-gw-storage:  # queue cho external gateway

services:
  gw1:
    image: ghcr.io/observiq/bindplane-agent:1.79.2
    container_name: gw1
    hostname: gw1
    command: ["--config=/etc/otel/config/config.yaml"]
    volumes:
      - ./config:/etc/otel/config
      - gw1-storage:/etc/otel/storage
    environment:
      OPAMP_ENDPOINT: "wss://app.bindplane.com/v1/opamp"
      OPAMP_SECRET_KEY: "<secret>"
      OPAMP_LABELS: ephemeral=true
      MANAGER_YAML_PATH: /etc/otel/config/gw1-manager.yaml
      CONFIG_YAML_PATH: /etc/otel/config/config.yaml
      LOGGING_YAML_PATH: /etc/otel/config/logging.yaml

  # Định nghĩa tương tự cho gw2, gw3, otlp-lb (Nginx), telgen và external-gw

Mỗi Gateway Collector cần một volume riêng biệt để lưu trữ dữ liệu đệm, tránh trùng lặp và đảm bảo tính nhất quán khi có sự cố.

Cấu Hình Load Balancer Nginx

worker_processes auto;

events {
  worker_connections 1024;
}

stream {
  upstream otlp_grpc {
    server gw1:4317 max_fails=3 fail_timeout=15s;
    server gw2:4317 max_fails=3 fail_timeout=15s;
    server gw3:4317 max_fails=3 fail_timeout=15s;
  }
  server {
    listen 4317;
    proxy_pass otlp_grpc;
    proxy_connect_timeout 1s;
    proxy_timeout 30s;
  }
}

http {
  upstream otlp_http {
    server gw1:4318 max_fails=3 fail_timeout=15s;
    server gw2:4318 max_fails=3 fail_timeout=15s;
    server gw3:4318 max_fails=3 fail_timeout=15s;
  }
  server {
    listen 4318;
    location / {
      proxy_pass http://otlp_http;
      proxy_next_upstream error timeout http_502 http_503 http_504;
    }
  }
}

Tùy Chọn Load Balancer Bằng Load Balancing Exporter

Ưu Điểm

Giảm cấu hình riêng biệt, không cần thêm Nginx.

Đảm bảo các dấu vết (trace spans) cùng xuất hiện trên cùng collector backend.

Tiện lợi cho nhóm triển khai tập trung vào việc cấu hình collector.

Cách Thay Thế Trong Docker Compose

Thay thế dịch vụ otlp-lb với một collector sử dụng load balancing exporter.

lb:
  image: ghcr.io/observiq/bindplane-agent:1.79.2
  container_name: lb
  hostname: lb
  command: ["--config=/etc/otel/config/lb-config.yaml"]
  volumes:
    - ./config:/etc/otel/config
    - lb-storage:/etc/otel/storage
  ports:
    - "4317:4317"
    - "4318:4318"
  environment:
    OPAMP_ENDPOINT: "wss://app.bindplane.com/v1/opamp"
    OPAMP_SECRET_KEY: "<secret>"
    OPAMP_LABELS: ephemeral=true
    MANAGER_YAML_PATH: /etc/otel/config/lb-manager.yaml
    CONFIG_YAML_PATH: /etc/otel/config/lb-config.yaml
    LOGGING_YAML_PATH: /etc/otel/config/logging.yaml
  depends_on: [gw1, gw2, gw3]

Ví Dụ Cấu Hình Load Balancing Exporter

exporters:
  loadbalancing:
    protocol:
      otlp:
        tls:
          insecure: true
        timeout: 30s
        retry_on_failure:
          enabled: true
          initial_interval: 5s
          max_elapsed_time: 300s
          max_interval: 30s
        sending_queue:
          enabled: true
          num_consumers: 10
          queue_size: 5000
    resolver:
      static:
        hostnames:
          - gw1:4317
          - gw2:4317
          - gw3:4317

Xây Dựng Resilience Cho Collector

Các Tính Năng Quan Trọng

Batching: Gom nhóm tín hiệu telemetry để tăng hiệu quả gửi.

Retry: Tự động gửi lại khi gửi dữ liệu thất bại.

Persistent Queue: Lưu trữ đệm trên đĩa để bảo vệ dữ liệu khi Collector bị crash hay khởi động lại.

Agent Collector cần được cấu hình các tính năng trên để giảm thiểu rủi ro mất dữ liệu ngay từ lớp gần workload nhất.

Ví Dụ Cấu Hình Retry & Persistent Queue

exporters:
  otlp/lb:
    compression: gzip
    endpoint: gw:4317
    retry_on_failure:
      enabled: true
      initial_interval: 5s
      max_elapsed_time: 300s
      max_interval: 30s
    sending_queue:
      enabled: true
      num_consumers: 10
      queue_size: 5000
      storage: file_storage/lb
    timeout: 30s
    tls:
      insecure: true

Batching Telemetry

Batching giúp gom nhiều tín hiệu trong một lần gửi, nâng cao hiệu quả xử lý.

Thiết Lập Batching Processor

processors:
  batch/lb-0__processor0:
    send_batch_max_size: 0
    send_batch_size: 8192
    timeout: 200ms

Gửi batch sau mỗi 200ms hoặc khi đủ 8192 tín hiệu.

Kích hoạt trên Agent Collector trước khi gửi lên Gateway.

Cân Bằng Tải Native Trong Kubernetes

Kiến Trúc Đề Xuất

Một Agent Collector chạy dạng DaemonSet trên từng node.

Gateway Collector dưới dạng Deployment, có thể auto scale từ 2 đến 10 pod.

Gateway Collector chạy trên một cluster Kubernetes riêng biệt (external), đóng vai trò backend thu thập cuối cùng.

Thiết Lập DaemonSet Agent Collector

RBAC phù hợp với quyền truy cập Kubernetes.

Volume lưu trữ persistent queue.

Sử dụng OpAMP để nhận cấu hình từ Bindplane.

Thiết Lập Deployment Gateway Collector

HorizontalPodAutoscaler (HPA) quản lý số lượng pod từ 2 đến 10 theo CPU utilization 60%.

Config batch, retry và persistent queue tương tự Docker.

Cấu hình service ClusterIP để nhận traffic OTLP.

Triển Khai Và Quản Lý Cấu Hình

Sử Dụng Bindplane

Bindplane cung cấp giao diện dễ dàng để tạo và quản lý các cấu hình collector.

Hỗ trợ tạo manifest, cấu hình nguồn và điểm đến telemetry.

Cho phép áp dụng cấu hình đồng bộ cho nhiều môi trường khác nhau.

Việc tích hợp Bindplane giúp giảm thiểu công sức cấu hình thủ công, đồng thời nâng cao hiệu quả vận hành trong hệ thống thu thập telemetry phân tán.

Kết Luận

Việc cấu hình High Availability cho OpenTelemetry Collector không chỉ giúp bạn đảm bảo giữ được dữ liệu telemetry khi hạ tầng gặp sự cố mà còn mở rộng khả năng xử lý theo nhu cầu. Sử dụng mô hình Agent-Gateway kết hợp với các kỹ thuật batch, retry và persistent queue chính là chìa khóa giúp xây dựng pipeline telemetry đáng tin cậy.

Bạn đọc nên bắt đầu từ cấu hình đơn giản nhất rồi tiến dần đến các mô hình phức tạp và áp dụng các công cụ như Bindplane để quản lý cấu hình hiệu quả. Hệ thống của bạn sẽ luôn sẵn sàng, giảm thiểu mất tín hiệu và tăng khả năng quan sát toàn diện.

Hãy bắt tay vào thiết lập ngay hôm nay và tận hưởng sự an tâm khi pipeline telemetry vận hành trơn tru không gián đoạn! Đừng quên dùng thử Bindplane Cloud để hỗ trợ quản lý và triển khai OpenTelemetry Collector dễ dàng hơn.

Tham Khảo

OpenTelemetry Documentation - Gateway Deployment

observIQ – High Availability Agent-Gateway Guide

Bindplane Official Site

StackOverflow: Gateway vs Agent OpenTelemetry Collector

Kubernetes Kind Project: https://kind.sigs.k8s.io/