菜单
文档breadcrumb arrow Grafana Alloybreadcrumb arrow 参考breadcrumb arrow 组件breadcrumb arrow otelcolbreadcrumb arrow otelcol.exporter.loadbalancing
开源

otelcol.exporter.loadbalancing

otelcol.exporter.loadbalancing 接受来自其他 otelcol 组件的日志和追踪，并使用 OpenTelemetry 协议 (OTLP) 通过网络写入它们。

注意

otelcol.exporter.loadbalancing 是对上游 OpenTelemetry Collector loadbalancing 导出器的封装。错误报告或功能请求将被重定向到上游存储库（如有必要）。

可以通过为多个 otelcol.exporter.loadbalancing 组件赋予不同的标签来指定它们。

使用哪个后端的决定取决于追踪 ID 或服务名称。后端负载不会影响选择。即使此负载均衡器不会对批次进行轮询负载均衡，但后端之间的负载分布应该非常相似，在当前配置下标准偏差低于 5%。

otelcol.exporter.loadbalancing 对于配置了基于尾部采样的后端特别有用，这些采样器根据完整追踪的视图选择后端。

当后端列表更新时，某些信号将被重新路由到不同的后端。大约 R/N 的“路由”将被重新路由，其中

  • “路由”是将追踪 ID 或服务名称映射到特定后端的路径。
  • “R”是路由总数。
  • “N”是后端总数。

对于大多数情况，这应该足够稳定，并且后端数量越多，它造成的干扰就越小。

用法

alloy 
otelcol.exporter.loadbalancing "LABEL" {
  resolver {
    ...
  }
  protocol {
    otlp {
      client {}
    }
  }
}

参数

otelcol.exporter.loadbalancing 支持以下参数

名称类型描述默认值必需
routing_keystring负载均衡的路由策略。"traceID"否
timeoutduration请求到 otlp > protocol 导出器标记为失败之前等待的时间。"0s"否

routing_key 属性决定了如何在端点之间路由信号。其值可以是以下之一

  • "service"：具有相同 service.name 的 spans、日志和指标将导出到同一后端。这在使用 span 指标等处理器时非常有用，因此每个服务的所有 span 都被发送到一致的 Alloy 实例以进行指标收集。否则，同一服务的指标将被发送到不同的实例，从而导致聚合不准确。
  • "traceID"：属于同一 traceID 的 spans 和日志将导出到同一后端。
  • "resource"：属于同一资源的指标将导出到同一后端。
  • "metric"：具有相同名称的指标将导出到同一后端。
  • "streamID"：具有相同 streamID 的指标将导出到同一后端。

负载均衡器为 routing_key 支持的信号类型配置导出器。

timeout 参数类似于 otelcol.exporter.loadbalancing 本身的顶级 queue 和 retry 块。它有助于将数据重新路由到一组新的健康后端。这对于 Kubernetes 等高度弹性的环境尤其有用，在这些环境中，已解析端点的列表由于部署和扩展事件而频繁更改。

实验性：otelcol.exporter.loadbalancing 中的指标支持是一项 实验性 功能。实验性功能可能会频繁发生重大更改，并且可能会在不提供同等替代品的情况下被删除。必须将 stability.level 标志设置为 experimental 才能使用该功能。

块

在 otelcol.exporter.loadbalancing 的定义中支持以下块

层次结构块描述必需
resolverresolver配置发现要导出的端点。是
resolver > staticstatic要导出的端点的静态列表。否
resolver > dnsdnsDNS 来源的要导出的端点列表。否
resolver > kuberneteskubernetesKubernetes 来源的要导出的端点列表。否
resolver > aws_cloud_mapaws_cloud_mapAWS CloudMap 来源的要导出的端点列表。否
protocolprotocol协议设置。目前仅支持 OTLP。否
protocol > otlpotlp配置 OTLP 导出器。否
protocol > otlp > clientclient配置导出器 gRPC 客户端。否
protocol > otlp > client > tlstls为 gRPC 客户端配置 TLS。否
protocol > otlp > client > keepalivekeepalive为 gRPC 客户端配置 keepalive 设置。否
protocol > otlp > queuequeue配置发送前的数据批处理。否
protocol > otlp > retryretry配置失败请求的重试机制。否
queuequeue配置发送到 otlp > protocol 导出器之前的数据批处理。否
retryretry配置到 otlp > protocol 导出器的失败请求的重试机制。否
debug_metricsdebug_metrics配置此组件生成的用于监控其状态的指标。否

> 符号表示更深层次的嵌套。例如，resolver > static 指的是在 resolver 块内定义的 static 块。

有两种类型的 queue 和 retry 块

  • protocol > otlp 下的 queue 和 retry 块。这对于特定后端的临时问题很有用，例如瞬时网络问题。
  • otelcol.exporter.loadbalancing 的顶级 queue 和 retry 块。这些配置选项提供了将数据重新路由到一组新的健康后端的功能。这对于 Kubernetes 等高度弹性的环境非常有用，在这些环境中，已解析端点的列表由于部署和扩展事件而频繁更改。

resolver 块

resolver 块配置如何检索此导出器将向其发送数据的端点。

在 resolver 块内，应指定 dns 块或 static 块之一。如果同时指定了 dns 和 static，则 dns 优先。

static 块

static 块配置此导出器将数据发送到的端点列表。

支持以下参数

名称类型描述默认值必需
hostnameslist(string)要导出的端点列表。是

dns 块

dns 块定期通过 DNS hostname 属性解析 IP 地址。此 IP 地址和通过 port 属性指定的端口将随后被 gRPC 导出器用作要导出数据的端点。

支持以下参数

名称类型描述默认值必需
hostnamestring要解析的 DNS 主机名。是
intervalduration解析器间隔。"5s"否
timeoutduration解析器超时。"1s"否
portstring要与从 DNS 主机名解析的 IP 地址一起使用的端口。"4317"否

kubernetes 块

您可以使用 kubernetes 块在 Kubernetes 服务的 Pod 之间进行负载均衡。当新的 Pod 添加到服务或从服务中删除时，Kubernetes API 会通知 Alloy。与 dns 解析器相比，kubernetes 解析器具有更快的响应时间，因为它不需要轮询。

支持以下参数

名称类型描述默认值必需
servicestring要解析的 Kubernetes 服务。是
portslist(number)要与从 service 解析的 IP 地址一起使用的端口。[4317]否
timeoutduration解析器超时。"1s"否
return_hostnamesbool返回主机名而不是 IP。false否

如果在 service 中未指定命名空间，则将尝试推断此 Alloy 的命名空间。如果失败，将使用 default 命名空间。

ports 中列出的每个端口将与从 service 解析的每个 IP 一起使用。

必须在 Kubernetes 中授予“get”、“list”和“watch” 角色，解析器才能工作。

return_hostnames 在某些情况下很有用，例如在 sidecar 模式下使用 Istio。要使用此功能，service 参数必须是无头 Service，指向 StatefulSet。此外，service 参数必须是在 StatefulSet 的 .spec.serviceName 下指定的参数。

aws_cloud_map 块

当在 AWS 基础设施中使用 ECS over EKS 时，aws_cloud_map 块允许用户使用 otelcol.exporter.loadbalancing。

支持以下参数

名称类型描述默认值必需
namespacestring服务注册到的 CloudMap 命名空间。是
service_namestring注册实例时指定的服务名称。是
intervalduration解析器间隔。"30s"否
timeoutduration解析器超时。"5s"否
health_statusstring要与从 service 解析的 IP 地址一起使用的端口。"HEALTHY"否
portnumber用于将追踪导出到从 service 解析的地址的端口。null否

health_status 可以设置为以下之一

  • HEALTHY：仅返回健康实例。
  • UNHEALTHY：仅返回不健康实例。
  • ALL：返回所有实例，无论其健康状况如何。
  • HEALTHY_OR_ELSE_ALL：返回健康实例，除非没有实例报告健康状态。在这种情况下，返回所有实例。这也称为故障开放。

如果未设置 port，则将使用 CloudMap 中定义的默认端口。

注意

aws_cloud_map 解析器最多返回 100 个主机。一个 功能请求 旨在涵盖此场景的分页。

protocol 块

protocol 块配置与导出相关的协议设置。目前仅支持 OTLP 协议。

otlp 块

otlp 块配置与导出相关的 OTLP 设置。

client 块

client 块配置组件使用的 gRPC 客户端。客户端块使用的端点是来自 resolver 块的端点

支持以下参数

名称类型描述默认值必需
compressionstring用于请求的压缩机制。"gzip"否
read_buffer_sizestringgRPC 客户端用于读取服务器响应的读取缓冲区大小。否
write_buffer_sizestringgRPC 客户端用于写入请求的写入缓冲区大小。"512KiB"否
wait_for_readyboolean在发送数据之前，等待 gRPC 连接处于 READY 状态。false否
headersmap(string)要随请求发送的其他标头。{}否
balancer_namestring要用于请求的 gRPC 客户端侧负载均衡器。round_robin否
authoritystring覆盖来自 gRPC 客户端的 gRPC 请求中的默认 :authority 标头。否
authcapsule(otelcol.Handler)来自 otelcol.auth 组件的处理程序，用于对请求进行身份验证。否

默认情况下，请求使用 Gzip 压缩。compression 参数控制要使用的压缩机制。支持的字符串是

  • "gzip"
  • "zlib"
  • "deflate"
  • "snappy"
  • "zstd"

如果将 compression 设置为 "none" 或空字符串 ""，则请求不会被压缩。

balancer_name 的支持值在 gRPC 文档的 负载均衡 中列出

  • pick_first：尝试连接到第一个地址，如果连接成功，则将其用于所有 RPC，如果失败，则尝试下一个地址（并持续这样做，直到连接成功）。因此，所有 RPC 都将发送到同一后端。
  • round_robin：连接到它看到的所有地址，并按顺序一次将一个 RPC 发送到每个后端。例如，第一个 RPC 发送到后端 1，第二个 RPC 发送到后端 2，第三个 RPC 发送到后端 1。

gRPC 中的 :authority 标头指定请求发送到的主机。它类似于 HTTP 请求中的 Host 标头。默认情况下，:authority 的值是从用于 gRPC 调用的端点 URL 派生的。当使用 Envoy 等代理路由流量时，覆盖 :authority 可能会很有用，Envoy 根据 :authority 标头的值做出路由决策。

您可以使用以下环境变量配置 HTTP 代理

  • HTTPS_PROXY
  • NO_PROXY

HTTPS_PROXY 环境变量指定用于代理请求的 URL。通过 HTTP CONNECT 方法 建立与代理的连接。

NO_PROXY 环境变量是可选的逗号分隔主机名列表，这些主机名不应使用 HTTPS 代理。每个主机名可以作为 IP 地址 (1.2.3.4)、CIDR 表示法中的 IP 地址 (1.2.3.4/8)、域名 (example.com) 或 * 提供。域名与该域名及其所有子域名匹配。以“.”开头的域名 (.example.com) 仅匹配子域名。仅当设置了 HTTPS_PROXY 时才读取 NO_PROXY。

由于 otelcol.exporter.loadbalancing 使用 gRPC，因此配置的代理服务器必须能够处理和代理 HTTP/2 流量。

tls 块

tls 块配置用于连接到 gRPC 服务器的 TLS 设置。

支持以下参数

名称类型描述默认值必需
ca_filestringCA 文件路径。否
ca_pemstring用于验证服务器的 CA PEM 编码文本。否
cert_filestringTLS 证书路径。否
cert_pemstring用于客户端身份验证的证书 PEM 编码文本。否
insecure_skip_verifyboolean忽略不安全的服务器 TLS 证书。否
include_system_ca_certs_poolboolean是否在证书颁发机构旁边加载系统证书颁发机构池。false否
insecureboolean禁用连接到配置的服务器时的 TLS。否
key_filestringTLS 证书密钥路径。否
key_pemsecret用于客户端身份验证的密钥 PEM 编码文本。否
max_versionstring连接的最大可接受 TLS 版本。"TLS 1.3"否
min_versionstring连接的最小可接受 TLS 版本。"TLS 1.2"否
cipher_suiteslist(string)TLS 传输可以使用的 TLS 密码套件列表。[]否
reload_intervalduration重新加载证书的持续时间。"0s"否
server_namestring设置后，验证服务器证书的主机名。否

如果服务器不支持 TLS，则必须将 insecure 参数设置为 true。

要禁用与服务器连接的 tls，请将 insecure 参数设置为 true。

如果 reload_interval 设置为 "0s"，则证书永远不会重新加载。

以下参数对是互斥的，不能同时设置

  • ca_pem 和 ca_file
  • cert_pem 和 cert_file
  • key_pem 和 key_file

如果 cipher_suites 留空，则使用安全的默认列表。有关支持的密码套件列表，请参阅 Go TLS 文档。

keepalive 块

keepalive 块配置 gRPC 客户端连接的 keepalive 设置。

支持以下参数

名称类型描述默认值必需
ping_waitduration在没有活动后多久 ping 服务器。否
ping_response_timeoutduration如果服务器未响应 ping，则在关闭非活动连接之前等待的时间。否
ping_without_streamboolean即使没有活动的流请求也发送 ping。否

queue 块

queue 块配置在将数据发送到 gRPC 服务器之前的数据批次的内存缓冲区。

支持以下参数

名称类型描述默认值必需
enabledboolean在将数据发送到客户端之前启用内存缓冲区。true否
num_consumersnumber并行发送写入队列的批次的读取器数量。10否
queue_sizenumber队列中同时允许的最大未写入批次数量。1000否

当 enabled 为 true 时，数据首先写入内存缓冲区，然后再发送到配置的服务器。只要未发送批次的数量不超过配置的 queue_size，发送到组件的 input 导出字段的批次就会添加到缓冲区中。

queue_size 决定了端点中断的容忍时间。假设每秒 100 个请求，默认队列大小 1000 提供大约 10 秒的中断容忍度。要计算 queue_size 的正确值，请将每秒的平均传出请求数乘以容忍中断的秒数。非常高的值可能会导致内存不足 (OOM) 终止。

num_consumers 参数控制有多少读取器从缓冲区读取并并行发送数据。num_consumers 的值越大，数据发送速度越快，但网络流量也会增加。

retry 块

retry 块配置如何重试到 gRPC 服务器的失败请求。

支持以下参数

名称类型描述默认值必需
enabledboolean启用重试失败的请求。true否
initial_intervalduration重试失败请求之前要等待的初始时间。"5s"否
max_elapsed_timeduration丢弃失败批次之前等待的最长时间。"5m"否
max_intervalduration重试之间等待的最长时间。"30s"否
multipliernumber增加重试前等待时间的因子。1.5否
randomization_factornumber随机化重试前等待时间的因子。0.5否

当 enabled 为 true 时，失败的批次将在给定的间隔后重试。initial_interval 参数指定第一次重试尝试之前要等待多长时间。如果请求继续失败，则重试前等待的时间将按 multiplier 参数指定的因子增加，该因子必须大于 1.0。max_interval 参数指定重试之间等待时间上限。

randomization_factor 参数对于在重试 Alloy 实例之间添加抖动很有用。如果 randomization_factor 大于 0，则重试前的等待时间乘以范围 [ I - randomization_factor * I, I + randomization_factor * I] 中的随机因子，其中 I 是当前间隔。

如果批次未成功发送，则在 max_elapsed_time 指定的时间过后，该批次将被丢弃。如果 max_elapsed_time 设置为 "0s"，则失败的请求将永远重试，直到成功为止。

debug_metrics 块

debug_metrics 块配置此组件生成的用于监控其状态的指标。

支持以下参数

名称类型描述默认值必需
disable_high_cardinality_metricsboolean是否禁用某些高基数指标。true否
levelstring控制包装的收集器发出的指标的详细程度。"detailed"否

disable_high_cardinality_metrics 是 Grafana Alloy 等效于 OpenTelemetry Collector 中的 telemetry.disableHighCardinalityMetrics 功能门。它删除可能导致高基数指标的属性。例如，关于 HTTP 和 gRPC 连接的指标中具有 IP 地址和端口号的属性将被删除。

注意

如果配置了，disable_high_cardinality_metrics 仅适用于 otelcol.exporter.* 和 otelcol.receiver.* 组件。

level 是 Alloy 等效于 OpenTelemetry Collector 中的 telemetry.metrics.level 功能门。可能的值为 "none"、"basic"、"normal" 和 "detailed"。

导出的字段

以下字段已导出，并且可以被其他组件引用

名称类型描述
inputotelcol.Consumer其他组件可用于向其发送遥测数据的值。

input 接受 otelcol.Consumer OTLP 格式的数据，用于以下类型的遥测信号

  • 日志
  • 追踪

选择负载均衡策略

不同的 Alloy 组件需要不同的负载均衡策略。otelcol.exporter.loadbalancing 的使用仅对于 有状态组件 是必要的。

otelcol.processor.tail_sampling

对于给定的跟踪 ID，所有 Span 必须发送到相同的尾部采样 Alloy 实例。

  • 这可以通过配置 otelcol.exporter.loadbalancing 并设置 routing_key = "traceID" 来完成。
  • 如果您不配置 routing_key = "traceID"，采样决策可能不正确。尾部采样器在做出采样决策时必须具有跟踪的完整视图。例如，如果同一跟踪的 Span 分布在多个 Alloy 实例上，则 rate_limiting 尾部采样策略可能会错误地传递比预期更多的 Span。

otelcol.connector.spanmetrics

对于给定的 service.name，所有 Span 必须发送到相同的 spanmetrics Alloy。

  • 这可以通过配置 otelcol.exporter.loadbalancing 并设置 routing_key = "service" 来完成。
  • 如果您不配置 routing_key = "service"，则从 Span 生成的指标可能不正确。例如，如果相同 service.name 的相似 Span 最终分布在不同的 Alloy 实例上，则两个 Alloy 将具有相同的指标序列，用于计算 Span 延迟、错误和请求数。当两个 Alloy 实例都尝试将指标写入 Mimir 等数据库时，这些序列可能会相互冲突。最好的情况是，这将导致 Alloy 中出现错误，并拒绝写入指标数据库。最坏的情况是，由于指标序列的样本重叠，可能导致数据不准确。

然而，有一些方法可以扩展 otelcol.connector.spanmetrics，而无需负载均衡器。

  1. 每个 Alloy 都可以添加一个属性，例如 collector.id，以使其序列唯一。然后，例如，您可以使用 sum by PromQL 查询来聚合来自不同 Alloy 的指标。不幸的是，额外的 collector.id 属性有一个缺点，即存储在数据库中的指标将具有更高的 cardinality （基数）。
  2. Spanmetrics 可以在后端数据库中生成，而不是在 Alloy 中生成。例如，Span 指标可以在 Grafana Cloud 中由 Tempo 跟踪数据库 生成。

otelcol.connector.servicegraph

在多个 Alloy 实例上扩展 otelcol.connector.servicegraph 具有挑战性。为了使 otelcol.connector.servicegraph 正常工作，每个“客户端”Span 必须与一个“服务器”Span 配对，以计算 Span 持续时间等指标。如果一个“客户端”Span 发送到一个 Alloy，而一个“服务器”Span 发送到另一个 Alloy，那么没有一个 Alloy 能够配对这些 Span，并且不会生成指标。

如果 otelcol.exporter.loadbalancing 配置了 routing_key = "traceID"，则可以部分解决此问题。然后，每个 Alloy 将能够计算跟踪中每个“客户端”/“服务器”对的服务图。在不同的跟踪中，可能会有具有相似“服务器”/“客户端”值的 Span，由另一个 Alloy 处理。如果两个不同的 Alloy 实例处理相似的“服务器”/“客户端”Span，它们将生成相同的服务图指标序列。如果来自两个 Alloy 的序列相同，则在将它们写入后端数据库时会导致问题。您可以通过添加诸如 "collector.id" 之类的属性来区分序列。来自不同 Alloy 的序列可以使用 PromQL 查询在后端指标数据库上进行聚合。如果指标存储在 Grafana Mimir 中，则可以使用 自适应指标 解决由 "collector.id" 标签引起的基数问题。

一种更简单、更可扩展的替代方案是在 Alloy 中生成服务图指标，是在后端数据库中完全生成它们。例如，服务图可以在 Grafana Cloud 中由 Tempo 跟踪数据库 生成。

混合使用有状态组件

不同的 Alloy 组件可能需要不同的 otelcol.exporter.loadbalancing 的 routing_key。例如，otelcol.processor.tail_sampling 需要 routing_key = "traceID"，而 otelcol.connector.spanmetrics 需要 routing_key = "service"。为了负载均衡这两种类型的组件，必须设置两组不同的负载均衡器。

  • 一组 otelcol.exporter.loadbalancing 配置 routing_key = "traceID"，将 Span 发送到执行尾部采样且不执行 spanmetrics 的 Alloy。
  • 另一组 otelcol.exporter.loadbalancing 配置 routing_key = "service"，将 Span 发送到执行 spanmetrics 且不执行服务图的 Alloy。

不幸的是，这也可能导致副作用。例如，如果 otelcol.connector.spanmetrics 配置为生成 exemplars，则尾部采样 Alloy 可能会丢弃 exemplar 指向的跟踪。尾部采样 Alloy 和 spanmetrics Alloy 之间没有协调，以确保保留 exemplars 的跟踪 ID。

组件健康状况

仅当给定无效配置时，otelcol.exporter.loadbalancing 才会被报告为不健康。

调试信息

otelcol.exporter.loadbalancing 不公开任何组件特定的调试信息。

示例

静态解析器

此示例通过 gRPC 接收 OTLP 日志和跟踪。然后，它以负载均衡的方式将它们发送到 “localhost:55690” 或 “localhost:55700”。

alloy 
otelcol.receiver.otlp "default" {
    grpc {}
    output {
        traces  = [otelcol.exporter.loadbalancing.default.input]
        logs    = [otelcol.exporter.loadbalancing.default.input]
    }
}

otelcol.exporter.loadbalancing "default" {
    resolver {
        static {
            hostnames = ["localhost:55690", "localhost:55700"]
        }
    }
    protocol {
        otlp {
            client {}
        }
    }
}

DNS 解析器

当配置了 dns 解析器时，otelcol.exporter.loadbalancing 将定期执行 DNS 查询。Span 将导出到 DNS 查询返回的地址。

alloy 
otelcol.exporter.loadbalancing "default" {
    resolver {
        dns {
            hostname = "alloy-traces-sampling.grafana-cloud-monitoring.svc.cluster.local"
            port     = "34621"
            interval = "5s"
            timeout  = "1s"
        }
    }
    protocol {
        otlp {
            client {}
        }
    }
}

以下示例显示了一个 Kubernetes 配置，该配置配置了两组 Alloy

  • 一组负载均衡器 Alloy
    • Span 通过 otelcol.receiver.otlp 从已检测的应用接收。
    • Span 通过 otelcol.exporter.loadbalancing 导出。
  • 一组采样 Alloy
    • 采样 Alloy 在 headless service 后运行，以使负载均衡器 Alloy 能够发现它们。
    • Span 通过 otelcol.receiver.otlp 从负载均衡器 Alloy 接收。
    • 跟踪通过 otelcol.processor.tail_sampling 采样。
    • 跟踪通过 otelcol.exporter.otlp 导出到 OTLP 兼容的数据库，例如 Tempo。

在运行示例之前，您必须填写正确的 OTLP 凭据。您可以使用 k3d 启动示例

bash 
k3d cluster create alloy-lb-test
kubectl apply -f kubernetes_config.yaml

要删除集群，请运行

bash 
k3d cluster delete alloy-lb-test

Kubernetes 解析器

当您使用 kubernetes 解析器配置 otelcol.exporter.loadbalancing 时，每当 Kubernetes API 从服务中添加或删除新的 Pod 时，Kubernetes API 都会通知 Alloy。Span 将导出到来自 Kubernetes API 的地址，并结合所有可能的 ports。

alloy 
otelcol.exporter.loadbalancing "default" {
    resolver {
        kubernetes {
            service = "alloy-traces-headless"
            ports   = [ 34621 ]
        }
    }
    protocol {
        otlp {
            client {}
        }
    }
}

以下示例显示了一个 Kubernetes 配置，该配置设置了两组 Alloy

  • 一组负载均衡器 Alloy
    • Span 通过 otelcol.receiver.otlp 从已检测的应用接收。
    • Span 通过 otelcol.exporter.loadbalancing 导出。
    • 负载均衡器 Alloy 将在 Kubernetes API 每次从采样 Alloy 池中添加或删除 Pod 时收到通知。
  • 一组采样 Alloy
    • 采样 Alloy 不需要在 headless service 后运行。
    • Span 通过 otelcol.receiver.otlp 从负载均衡器 Alloy 接收。
    • 跟踪通过 otelcol.processor.tail_sampling 采样。
    • 跟踪通过 otelcol.exporter.otlp 导出到 OTLP 兼容的数据库，例如 Tempo。

在运行示例之前，您必须填写正确的 OTLP 凭据。您可以使用 k3d 启动示例

bash 
k3d cluster create alloy-lb-test
kubectl apply -f kubernetes_config.yaml

要删除集群，请运行

bash 
k3d cluster delete alloy-lb-test

兼容组件

otelcol.exporter.loadbalancing 具有可以被以下组件使用的导出：

注意

连接某些组件可能不合理，或者组件可能需要进一步配置才能使连接正常工作。有关更多详细信息，请参阅链接的文档。