OpenTelemetry Collector trong Kubernetes: Kiến trúc có thể mở rộng, Lấy mẫu & Xuất ra ClickHouse

Hướng dẫn này trình bày chi tiết các cân nhắc về kiến trúc, cấu hình và chiến lược triển khai OpenTelemetry Collector trong môi trường Kubernetes, tập trung vào khả năng mở rộng, lấy mẫu nâng cao và xuất trực tiếp sang ClickHouse. Mục tiêu là cung cấp một đường ống quan sát mạnh mẽ, sẵn sàng cho sản xuất với đảm bảo không mất dữ liệu.

1. Kiến trúc OpenTelemetry Collector trong Kubernetes

Triển khai OpenTelemetry Collector trong Kubernetes đòi hỏi một chiến lược kiến trúc rõ ràng. Các mô hình chính là Agent (DaemonSet), Gateway (Deployment) hoặc phương pháp Hybrid. Mỗi mô hình trình bày những đánh đổi riêng biệt về việc sử dụng tài nguyên, độ trễ và khả năng xử lý.

1.1 Kiến trúc Agent (DaemonSet)

Kiến trúc Agent triển khai một phiên bản OpenTelemetry Collector trên mỗi node Kubernetes. Điều này thường đạt được bằng cách sử dụng DaemonSet, đảm bảo một pod collector chạy trên mỗi node. Các Agent chủ yếu chịu trách nhiệm thu thập dữ liệu cục bộ và xử lý ban đầu.

Đặc điểm:

• Mô hình triển khai: Kubernetes DaemonSet.
• Thu thập dữ liệu: Thu thập dữ liệu telemetry trực tiếp từ các ứng dụng chạy trên cùng một node, thường thông qua việc quét cấp host hoặc dưới dạng sidecar.
• Xử lý: Thực hiện xử lý nhẹ, cục bộ trên node (ví dụ: làm giàu thuộc tính tài nguyên, lọc cơ bản, lấy mẫu dựa trên đầu).
• Xuất: Thường chuyển tiếp dữ liệu đến một Gateway Collector tập trung hoặc trực tiếp đến một backend.

Ưu điểm:

• Độ trễ thấp: Dữ liệu di chuyển một đường dẫn tối thiểu từ ứng dụng đến collector.
• Khả năng phục hồi: Cách ly cấp node; lỗi ở một agent không ảnh hưởng đến các node khác.
• Cách ly tài nguyên: Tài nguyên được phân phối trên các node, ngăn chặn một điểm tranh chấp duy nhất.
• Hiệu quả mạng: Giảm lưu lượng mạng giữa các node cho việc thu thập ban đầu.

Nhược điểm:

• Chi phí tài nguyên: Mỗi node phải chịu chi phí của một phiên bản collector.
• Ngữ cảnh toàn cầu hạn chế: Không hiệu quả cho việc xử lý nâng cao yêu cầu chế độ xem toàn cầu, chẳng hạn như lấy mẫu dựa trên đuôi.
• Độ phức tạp quản lý: Thay đổi cấu hình yêu cầu cập nhật cuốn chiếu trên tất cả các node.

Trường hợp sử dụng:

• Thu thập các chỉ số và nhật ký của host.
• Thu thập các dấu vết ứng dụng với lấy mẫu dựa trên đầu.
• Làm giàu dữ liệu ban đầu (ví dụ: thêm siêu dữ liệu Kubernetes).

Ví dụ: OpenTelemetry Collector Agent DaemonSet

Ví dụ này trình bày một DaemonSet cơ bản cho OTel Collector Agent, được cấu hình để nhận OTLP và các chỉ số Prometheus, và chuyển tiếp chúng.

apiVersion: opentelemetry.io/v1alpha1
kind: OpenTelemetryCollector
metadata:
  name: otel-agent
  namespace: observability
spec:
  mode: daemonset
  image: otel/opentelemetry-collector-contrib:0.90.1
  hostNetwork: true # Required for host-level scraping
  serviceAccount: otel-collector
  resources:
    requests:
      memory: "128Mi"
      cpu: "100m"
    limits:
      memory: "256Mi"
      cpu: "200m"
  config: |
    receivers:
      otlp:
        protocols:
          grpc:
          http:
      prometheus:
        config:
          scrape_configs:
            - job_name: 'kubernetes-nodes'
              static_configs:
                - targets: ['localhost:9100'] # Node Exporter
            - job_name: 'kubernetes-pods'
              kubernetes_sd_configs:
                - role: pod
              relabel_configs:
                - source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_scrape]
                  action: keep
                  regex: true
                - source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_path]
                  action: replace
                  target_label: __metrics_path__
                  regex: (.+)
                - source_labels: [__address__, __meta_kubernetes_pod_annotation_prometheus_io_port]
                  action: replace
                  regex: ([^:]+)(?::\d+)?;(\d+)
                  replacement: $1:$2
                  target_label: __address__
    processors:
      batch:
        send_batch_size: 10000
        timeout: 10s
      memory_limiter:
        limit_mib: 150
        spike_limit_mib: 50
        check_interval: 1s
      resourcedetection:
        detectors: [env, system, kubernetes]
        timeout: 2s
        override: true
    exporters:
      otlp:
        endpoint: "otel-gateway.observability.svc.cluster.local:4317" # Forward to Gateway
        tls:
          insecure: true
    service:
      pipelines:
        traces:
          receivers: [otlp]
          processors: [resourcedetection, batch, memory_limiter]
          exporters: [otlp]
        metrics:
          receivers: [otlp, prometheus]
          processors: [resourcedetection, batch, memory_limiter]
          exporters: [otlp]

1.2 Kiến trúc Gateway (Deployment)

Kiến trúc Gateway sử dụng một triển khai OpenTelemetry Collector tập trung, thường là một Kubernetes Deployment, được mở rộng theo chiều ngang. Các collector này nhận dữ liệu từ các Agent hoặc trực tiếp từ các ứng dụng, thực hiện xử lý nâng cao và xuất sang các backend khác nhau.

Đặc điểm:

• Mô hình triển khai: Kubernetes Deployment, thường được hiển thị qua một Service.
• Thu thập dữ liệu: Nhận dữ liệu tổng hợp từ các Agent hoặc trực tiếp từ các ứng dụng.
• Xử lý: Thực hiện các hoạt động phức tạp, tốn nhiều tài nguyên (ví dụ: lấy mẫu dựa trên đuôi, thao tác thuộc tính, tổng hợp, phân phối).
• Xuất: Xuất dữ liệu đã xử lý sang bộ nhớ dài hạn hoặc các nền tảng phân tích (ví dụ: ClickHouse, Prometheus, Jaeger, Loki).

Ưu điểm:

• Xử lý tập trung: Lý tưởng cho các hoạt động yêu cầu chế độ xem toàn cầu, như lấy mẫu dựa trên đuôi.
• Hiệu quả tài nguyên: Chia sẻ tài nguyên trên nhiều luồng dữ liệu, có khả năng giảm tổng mức sử dụng tài nguyên so với các agent trên mỗi node cho việc xử lý phức tạp.
• Quản lý đơn giản hóa: Ít phiên bản hơn để quản lý cho logic xử lý cốt lõi.
• Khả năng mở rộng: Dễ dàng mở rộng theo chiều ngang bằng cách tăng số lượng bản sao.

Nhược điểm:

• Độ trễ tăng: Dữ liệu phải đi qua mạng hai lần (ứng dụng -> agent -> gateway -> backend).
• Điểm lỗi duy nhất (nếu không được mở rộng): Lỗi một phiên bản gateway có thể làm gián đoạn toàn bộ đường ống.
• Chi phí mạng: Tất cả dữ liệu telemetry đều chảy qua gateway, có khả năng làm bão hòa các liên kết mạng.

Trường hợp sử dụng:

• Lấy mẫu dựa trên đuôi cho các dấu vết.
• Tổng hợp các chỉ số từ nhiều nguồn.
• Chuyển đổi và lọc dữ liệu phức tạp.
• Xuất sang nhiều hệ thống backend.

Ví dụ: OpenTelemetry Collector Gateway Deployment

Ví dụ này cho thấy một Deployment cho OTel Collector Gateway, được cấu hình để nhận OTLP, xử lý và xuất.

apiVersion: opentelemetry.io/v1alpha1
kind: OpenTelemetryCollector
metadata:
  name: otel-gateway
  namespace: observability
spec:
  mode: deployment
  image: otel/opentelemetry-collector-contrib:0.90.1
  replicas: 3 # Scaled for high availability and throughput
  serviceAccount: otel-collector
  ports:
    - name: otlp-grpc
      port: 4317
      targetPort: 4317
      protocol: TCP
    - name: otlp-http
      port: 4318
      targetPort: 4318
      protocol: TCP
    - name: metrics
      port: 8888
      targetPort: 8888
      protocol: TCP
  resources:
    requests:
      memory: "1Gi"
      cpu: "500m"
    limits:
      memory: "2Gi"
      cpu: "1000m"
  config: |
    receivers:
      otlp:
        protocols:
          grpc:
          http:
    processors:
      batch:
        send_batch_size: 10000
        timeout: 10s
      memory_limiter:
        limit_mib: 1500
        spike_limit_mib: 500
        check_interval: 1s
      # Tail sampling configuration will be added here later
    exporters:
      # ClickHouse exporter will be added here later
      logging:
        verbosity: detailed
    service:
      pipelines:
        traces:
          receivers: [otlp]
          processors: [batch, memory_limiter] # Tail sampling will be inserted here
          exporters: [logging] # ClickHouse exporter will replace/augment this
        metrics:
          receivers: [otlp]
          processors: [batch, memory_limiter]
          exporters: [logging] # ClickHouse exporter will replace/augment this

1.3 Kiến trúc Hybrid (Được khuyến nghị)

Kiến trúc Hybrid kết hợp sức mạnh của cả mô hình Agent và Gateway. Các Agent thu thập dữ liệu cục bộ và chuyển tiếp đến các Gateway, sau đó thực hiện xử lý nâng cao và xuất. Đây là phương pháp được khuyến nghị cho hầu hết các môi trường sản xuất.

Đặc điểm:

• Agent (DaemonSet): Thu thập dữ liệu, thực hiện xử lý tối thiểu (ví dụ: làm giàu tài nguyên) và chuyển tiếp đến các Gateway.
• Gateway (Deployment): Nhận dữ liệu từ các Agent, thực hiện xử lý nâng cao (ví dụ: lấy mẫu dựa trên đuôi, tổng hợp) và xuất sang các backend.

Ưu điểm:

• Hiệu suất tối ưu: Độ trễ thấp cho việc thu thập ban đầu, xử lý mạnh mẽ tập trung.
• Tính sẵn sàng cao: Các Agent cung cấp khả năng phục hồi cục bộ; các Gateway có thể được mở rộng để có tính sẵn sàng cao.
• Khả năng mở rộng: Cả hai lớp có thể được mở rộng độc lập.
• Tính linh hoạt: Cho phép các logic xử lý khác nhau ở mỗi giai đoạn.

Nhược điểm:

• Độ phức tạp tăng: Yêu cầu quản lý hai triển khai collector riêng biệt và sự tương tác của chúng.
• Chi phí tài nguyên cao hơn: Tổng mức tiêu thụ tài nguyên cao hơn so với mô hình Gateway thuần túy do các agent trên mỗi node.

Ví dụ: Agent chuyển tiếp đến Gateway (đoạn cấu hình Agent)

Cấu hình Agent từ Mục 1.1 đã trình bày việc chuyển tiếp đến một Gateway:

    exporters:
      otlp:
        endpoint: "otel-gateway.observability.svc.cluster.local:4317" # Forward to Gateway
        tls:
          insecure: true

1.4 Bảng so sánh kiến trúc

2. Các yếu tố cần thiết trong cấu hình OpenTelemetry Collector

Hoạt động hiệu quả của OpenTelemetry Collector dựa vào một cấu hình được cấu trúc tốt. Phần này bao gồm các bộ xử lý và bộ xuất cơ bản rất quan trọng cho việc triển khai sản xuất.

2.1 Các thành phần cốt lõi: Receivers, Processors, Exporters, Service

Cấu hình OpenTelemetry Collector là khai báo và được cấu trúc xung quanh bốn thành phần chính:

• Receivers: Cách dữ liệu đi vào collector (ví dụ: OTLP, Prometheus, Jaeger, Zipkin).
• Processors: Cách dữ liệu được chuyển đổi, lọc hoặc làm giàu trong collector (ví dụ: batch, memory_limiter, tail_sampling, resourcedetection).
• Exporters: Cách dữ liệu rời khỏi collector đến các backend khác nhau (ví dụ: OTLP, ClickHouse, Prometheus, Loki, Jaeger).
• Service: Định nghĩa các đường ống, kết nối receivers với processors và sau đó đến exporters cho các loại telemetry cụ thể (dấu vết, chỉ số, nhật ký).

2.2 Phân lô để tăng hiệu quả

Bộ xử lý batch rất quan trọng để tối ưu hóa việc sử dụng mạng và giảm tải cho các hệ thống backend. Nó tổng hợp dữ liệu telemetry thành các lô lớn hơn trước khi xuất.

Lợi ích:

• Giảm số lần gọi mạng: Ít yêu cầu lớn hơn thay vì nhiều yêu cầu nhỏ.
• Cải thiện thông lượng: Các backend có thể xử lý các khối dữ liệu lớn hơn hiệu quả hơn.
• Sử dụng CPU thấp hơn: Ít chi phí hơn trên mỗi mục cho việc tuần tự hóa và I/O mạng.

Tham số cấu hình:

• send_batch_size: Số lượng mục telemetry tối đa (spans, điểm dữ liệu chỉ số, bản ghi nhật ký) để gửi trong một lô duy nhất.
• timeout: Thời gian tối đa để chờ trước khi gửi một lô, ngay cả khi chưa đạt đến send_batch_size.
• send_batch_max_size: Kích thước tối đa tuyệt đối của một lô, ghi đè send_batch_size nếu cần để ngăn các lô quá lớn.

Ví dụ: Cấu hình bộ xử lý batch

    processors:
      batch:
        send_batch_size: 10000 # Max items per batch
        timeout: 10s         # Max wait time before sending
        send_batch_max_size: 12000 # Absolute max items, useful for high-volume bursts

2.3 Giới hạn bộ nhớ để ổn định

Bộ xử lý memory_limiter rất cần thiết để ngăn OpenTelemetry Collector tiêu thụ quá nhiều bộ nhớ và bị Kubernetes OOMKilled. Nó giám sát việc sử dụng bộ nhớ và, nếu giới hạn bị vượt quá, sẽ loại bỏ dữ liệu để ngăn chặn sự cố.

Lợi ích:

• Ngăn chặn OOMKills: Đảm bảo sự ổn định của collector dưới tải cao hoặc cấu hình sai.
• Giảm cấp độ linh hoạt: Ưu tiên thời gian hoạt động của collector hơn tính đầy đủ của dữ liệu trong điều kiện áp lực bộ nhớ.

Tham số cấu hình:

• limit_mib: Lượng bộ nhớ tối đa (tính bằng MiB) mà collector được phép sử dụng. Khi đạt đến giới hạn này, dữ liệu sẽ bị loại bỏ. Điều này phải nhỏ hơn giới hạn bộ nhớ Kubernetes của container.
• spike_limit_mib: Lượng bộ nhớ tối đa (tính bằng MiB) mà collector có thể tạm thời vượt quá limit_mib. Điều này giúp xử lý các đợt tăng đột biến mà không bị loại bỏ dữ liệu ngay lập tức.
• check_interval: Tần suất (thời lượng) kiểm tra việc sử dụng bộ nhớ.

Ví dụ: Cấu hình bộ xử lý memory_limiter

    processors:
      memory_limiter:
        limit_mib: 1500 # Max memory in MiB before dropping data
        spike_limit_mib: 500 # Allowed spike above limit_mib
        check_interval: 1s # How often to check memory usage

Lưu ý: limit_mib luôn phải được đặt thấp hơn limits.memory của container Kubernetes để cho phép collector phản ứng trước khi Kubernetes OOMKills nó. Một quy tắc chung là limit_mib = limits.memory * 0.75.

2.4 Cân bằng tải dấu vết đến các Gateway

Khi sử dụng kiến trúc Hybrid, các Agent cần phân phối dấu vết trên nhiều phiên bản Gateway để có tính sẵn sàng cao và phân phối tải. Bộ xuất loadbalancing tạo điều kiện cho việc này.

Lợi ích:

• Tính sẵn sàng cao: Nếu một Gateway bị lỗi, các agent sẽ tự động định tuyến đến các Gateway khỏe mạnh.
• Phân phối tải: Phân phối việc thu nhận dấu vết trên nhiều phiên bản Gateway.
• Khả năng mở rộng: Cho phép mở rộng Gateway theo chiều ngang mà không cần cấu hình lại các agent.

Tham số cấu hình:

• protocol: Giao thức OTLP để sử dụng (grpc hoặc http).
• resolver: Định nghĩa cách các điểm cuối đích được phát hiện.
  • dns: Sử dụng bản ghi DNS SRV hoặc bản ghi A để phát hiện các điểm cuối. Được khuyến nghị cho các dịch vụ Kubernetes.
  • static: Một danh sách cố định các điểm cuối. Ít động hơn.
• routing_key: Xác định cách các dấu vết được định tuyến. traceID là mặc định và được khuyến nghị để đảm bảo tất cả các span của một dấu vết duy nhất đi đến cùng một Gateway để xử lý đúng cách (ví dụ: lấy mẫu đuôi).

Ví dụ: Cấu hình bộ xuất loadbalancing của Agent

    exporters:
      otlp/loadbalancer:
        endpoint: "otel-gateway.observability.svc.cluster.local:4317" # Kubernetes Service DNS
        tls:
          insecure: true
        loadbalancing:
          resolver:
            dns:
              hostname: otel-gateway.observability.svc.cluster.local # Service DNS name
              port: 4317
          routing_key: traceID # Ensures all spans of a trace go to the same gateway
    service:
      pipelines:
        traces:
          receivers: [otlp]
          processors: [resourcedetection, batch, memory_limiter]
          exporters: [otlp/loadbalancer] # Use the loadbalancing exporter

3. Các chiến lược lấy mẫu nâng cao: Lấy mẫu dựa trên đuôi

Lấy mẫu rất quan trọng để quản lý khối lượng dữ liệu telemetry, đặc biệt là các dấu vết. Mặc dù lấy mẫu dựa trên đầu (quyết định ở đầu dấu vết) rất đơn giản, nhưng nó thường loại bỏ ngữ cảnh có giá trị. Lấy mẫu dựa trên đuôi giải quyết vấn đề này bằng cách đưa ra quyết định lấy mẫu sau khi một dấu vết đã hoàn thành.

3.1 Tại sao lại là lấy mẫu dựa trên đuôi?

Lấy mẫu dựa trên đuôi cho phép đưa ra các quyết định lấy mẫu thông minh dựa trên toàn bộ ngữ cảnh dấu vết. Điều này có nghĩa là bạn có thể đáng tin cậy nắm bắt:

• Dấu vết lỗi: Tất cả các dấu vết chứa lỗi.
• Dấu vết chậm: Tất cả các dấu vết vượt quá ngưỡng độ trễ nhất định.
• Các hoạt động cụ thể: Các dấu vết liên quan đến các hoạt động kinh doanh quan trọng.

Lợi ích:

• Tính đầy đủ theo ngữ cảnh: Đảm bảo các dấu vết đầy đủ được thu thập để phân tích.
• Thu thập dữ liệu có mục tiêu: Tập trung vào các dấu vết phù hợp nhất để khắc phục sự cố.

Đánh đổi:

• Xử lý tập trung: Yêu cầu một Gateway Collector để giữ các dấu vết trong bộ nhớ cho đến khi hoàn thành, làm tăng yêu cầu bộ nhớ và CPU trên Gateway.
• Độ trễ tăng: Quyết định bị trì hoãn cho đến khi dấu vết hoàn thành, điều này có thể thêm một độ trễ nhỏ trước khi dấu vết được xuất.

3.2 Cấu hình bộ xử lý tail_sampling

Bộ xử lý tail_sampling được cấu hình trong Gateway Collector. Nó giữ các dấu vết trong một khoảng thời gian xác định (decision_wait) để thu thập tất cả các span trước khi áp dụng các chính sách lấy mẫu.

Các tham số chính:

• decision_wait: Thời gian tối đa để chờ tất cả các span của một dấu vết đến trước khi đưa ra quyết định lấy mẫu. Điều này rất quan trọng để đảm bảo tính đầy đủ của dấu vết.
• num_traces: Số lượng dấu vết tối đa để giữ trong bộ nhớ đồng thời. Điều này ảnh hưởng trực tiếp đến việc sử dụng bộ nhớ.
• expected_new_traces_per_sec: Ước tính tốc độ dấu vết đến, được sử dụng để định cỡ nội bộ.

Các loại chính sách: Bộ xử lý tail_sampling hỗ trợ nhiều chính sách khác nhau, có thể được kết hợp bằng cách sử dụng các chính sách tổng hợp and hoặc or:

• always_sample: Luôn lấy mẫu dấu vết.
• drop_new: Loại bỏ các dấu vết mới nếu vượt quá num_traces.
• probabilistic: Lấy mẫu dấu vết dựa trên xác suất đã cấu hình.
• rate_limiting: Lấy mẫu dấu vết ở tốc độ tối đa mỗi giây.
• status_code: Lấy mẫu dấu vết dựa trên mã trạng thái HTTP (ví dụ: ERROR, UNSET).
• latency: Lấy mẫu dấu vết vượt quá ngưỡng độ trễ đã chỉ định.
• attribute: Lấy mẫu dấu vết dựa trên các thuộc tính span hoặc tài nguyên cụ thể.
• composite: Kết hợp nhiều chính sách bằng cách sử dụng logic and hoặc or.

Ví dụ: Bộ xử lý tail_sampling với chính sách composite

Cấu hình này lấy mẫu tất cả các dấu vết có chứa lỗi HOẶC có độ trễ lớn hơn 500ms.

    processors:
      # ... other processors like batch, memory_limiter
      tail_sampling:
        decision_wait: 10s # Wait up to 10 seconds for all spans of a trace
        num_traces: 100000 # Max traces to hold in memory
        expected_new_traces_per_sec: 1000 # Expected incoming rate
        policies:
          - name: error-or-slow-trace
            type: composite
            composite:
              or_policies:
                - name: error-policy
                  type: status_code
                  status_code:
                    status_codes: [ERROR]
                - name: slow-trace-policy
                  type: latency
                  latency:
                    threshold_ms: 500 # Sample traces > 500ms
              on_failure: always_sample # If composite policy fails, always sample

Tích hợp vào đường ống Gateway:

    service:
      pipelines:
        traces:
          receivers: [otlp]
          processors: [batch, memory_limiter, tail_sampling] # Insert tail_sampling here
          exporters: [logging] # Exporters will follow

4. Xuất sang ClickHouse với không mất dữ liệu

ClickHouse là một cơ sở dữ liệu phân tích được tối ưu hóa cho việc thu nhận thông lượng cao và thực thi truy vấn nhanh, làm cho nó trở thành một lựa chọn tuyệt vời để lưu trữ các dấu vết và chỉ số OpenTelemetry. Bộ xuất clickhouse cho phép tích hợp trực tiếp.

4.1 Tổng quan về bộ xuất ClickHouse

Bộ xuất clickhouse gửi các dấu vết, chỉ số và nhật ký trực tiếp đến các bảng ClickHouse. Nó hỗ trợ nhiều cấu hình khác nhau cho lược đồ bảng, TTL và nén.

4.2 Cấu hình cho dấu vết

Các dấu vết thường được lưu trữ trong một bảng được thiết kế để truy vấn hiệu quả theo trace_id, service_name, operation_name và các phạm vi thời gian.

Các cân nhắc về lược đồ cho dấu vết ClickHouse: Một lược đồ phổ biến cho các dấu vết OpenTelemetry trong ClickHouse bao gồm:

• trace_id (FixedString(16))
• span_id (FixedString(8))
• parent_span_id (FixedString(8))
• service_name (String)
• operation_name (String)
• start_time_unix_nano (UInt64)
• duration_nano (Int64)
• kind (Int8)
• status_code (Int8)
• status_message (String)
• attributes (Map(String, String)) - cho các thuộc tính span
• resource_attributes (Map(String, String)) - cho các thuộc tính tài nguyên
• events.timestamp_unix_nano (Array(UInt64))
• events.name (Array(String))
• events.attributes (Array(Map(String, String)))
• links.trace_id (Array(FixedString(16)))
• links.span_id (Array(FixedString(8)))
• links.attributes (Array(Map(String, String)))

Ví dụ: Cấu hình bộ xuất ClickHouse cho dấu vết

    exporters:
      clickhouse/traces:
        dsn: "tcp://clickhouse-cluster.observability.svc.cluster.local:9000?database=otel"
        database: otel
        traces_table: otel_traces
        ttl: 7d # Data retention for 7 days
        compression: lz4 # Use LZ4 compression
        # Optional: Define specific schema mappings if default is not sufficient
        # trace_id_field: trace_id
        # span_id_field: span_id
        # ...

DDL ClickHouse cho bảng otel_traces:

CREATE TABLE otel_traces (
    Timestamp DateTime64(9) CODEC(Delta, ZSTD(1)),
    TraceId FixedString(16) CODEC(ZSTD(1)),
    SpanId FixedString(8) CODEC(ZSTD(1)),
    ParentSpanId FixedString(8) CODEC(ZSTD(1)),
    TraceState String CODEC(ZSTD(1)),
    SpanName String CODEC(ZSTD(1)),
    SpanKind Int8 CODEC(ZSTD(1)),
    ServiceName LowCardinality(String) CODEC(ZSTD(1)),
    ResourceSchemaUrl String CODEC(ZSTD(1)),
    ResourceAttributes Map(LowCardinality(String), String) CODEC(ZSTD(1)),
    ScopeSchemaUrl String CODEC(ZSTD(1)),
    ScopeName String CODEC(ZSTD(1)),
    ScopeVersion String CODEC(ZSTD(1)),
    SpanAttributes Map(LowCardinality(String), String) CODEC(ZSTD(1)),
    DurationNanos UInt64 CODEC(ZSTD(1)),
    StatusCode Int8 CODEC(ZSTD(1)),
    StatusMessage String CODEC(ZSTD(1)),
    Events Nested (
        Timestamp DateTime64(9),
        Name String,
        Attributes Map(LowCardinality(String), String)
    ) CODEC(ZSTD(1)),
    Links Nested (
        TraceId FixedString(16),
        SpanId FixedString(8),
        TraceState String,
        Attributes Map(LowCardinality(String), String)
    ) CODEC(ZSTD(1))
) ENGINE = MergeTree()
PARTITION BY toYYYYMMDD(Timestamp)
ORDER BY (ServiceName, SpanName, Timestamp, TraceId)
TTL Timestamp + INTERVAL 7 DAY
SETTINGS index_granularity = 8192, ttl_only_drop_parts = 1;

4.3 Cấu hình cho chỉ số

Các chỉ số thường được lưu trữ trong một bảng được tối ưu hóa cho chuỗi thời gian