Day12- GPT 陪我讀 Grafana OpenTelemetry
Day13- GPT 陪我讀 將 OpenTelemetry Collector 連接到 Grafana Cloud 資料庫
Day14- GPT 陪我讀 OpenTelemetry Collector Use Case 1 Fan out
Day15- GPT 陪我讀 OpenTelemetry Collector Use Case 2 Telemetry data normalization

Use Case 4 Load balancing

在一般情況下，當使用標準的 HTTP 協議傳送 OTLP 負載時，一個常規的現成第 4 層負載平衡器對於 OpenTelemetry 是適用的，而當使用 OTLP gRPC 時，gRPC 負載平衡器也可以工作。但在某些情況下，通用的負載平衡策略可能不會奏效，例如在需要尾部採樣的情況下。對於這些情況，OpenTelemetry Collector contrib 發行版本包括了一個負載平衡導出器：它將檢查負載並提取追踪 ID，對於同一追踪 ID 始終選擇相同的後端。在此使用情境中，涉及兩層收集器：負載平衡層和處理層。

第 4 層的負載平衡器可以放在 OpenTelemetry Collector 的負載平衡層前面，以實現高可用性設置。OpenTelemetry Collectors 的處理層可以用作負載平衡層的後端，並將負責進行數據處理以及做出採樣決策，然後再將採樣數據發送到遙測後端。

負載平衡導出器支持兩種後端地址來源：一個是直接作為配置的一部分提供的靜態列表，另一個是不時查詢的 DNS A 記錄。每當後端列表發生變化時，最多有 30% 的跟踪 ID 會分配新的後端。這確保所有後端都有相似的負載。

在使用 DNS A 記錄解析器時，每個負載平衡收集器可能會在不同的時間進行 A 查詢，這會導致集群視圖在實例之間存在差異。效果是同一追踪 ID 的span可能會在一段時間內到達不同的收集器，直到所有負載平衡器最終都具有相同的集群視圖。如果您有一個高度彈性的處理收集器集群，請將 DNS 查詢設置為短間隔。

OpenTelemetry Collector 的負載平衡範例:

receivers:
  otlp:
    protocols:
      grpc:

processors:

exporters:
  loadbalancing:
    protocol:
      otlp:
    resolver:
      dns:
        hostname: my-otelcol.observability.svc.cluster.local

service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: []
      exporters: [loadbalancing]

總結

模式 4 - 負載平衡講述了在 OpenTelemetry 中使用的負載平衡技術。通常，我們可以使用現成的第 4 層負載平衡器進行平衡，但在需要尾部採樣的特殊情況下，我們會使用特定的負載平衡導出器。這個導出器能夠根據追踪 ID 保持一致性來選擇後端。當涉及到負載平衡時，通常有兩個主要的層次：負載平衡層和處理層。此外，該導出器還支持從靜態列表或 DNS A 記錄獲取後端地址。這個模式確保在後端變化時，所有的後端都能獲得平衡的負載。