Fluent Bit 连接 OpenTelemetry Collector 的配置优化实践

问题背景

在 Kubernetes 环境中，日志收集系统 Fluent Bit 与 OpenTelemetry Collector 的集成是一个常见的架构设计。然而，在实际配置过程中，开发者可能会遇到连接问题，特别是当 Fluent Bit 尝试将日志发送到 OpenTelemetry Collector 时出现 DNS 解析错误。

错误现象

典型的错误表现为 Fluent Bit 日志中出现类似以下信息：

[ warn] [net] getaddrinfo(host='http://my-opentelemetry-collector.dis.svc.cluster.local', err=15): Out of memory
[error] [output:opentelemetry:opentelemetry.1] no upstream connections available to http://my-opentelemetry-collector.dis.svc.cluster.local:4318

问题分析

经过深入排查，发现问题的根源在于 Fluent Bit 的 OpenTelemetry 输出插件配置中，Host 参数错误地包含了协议前缀（http://）。Fluent Bit 的 DNS 解析器期望接收的是一个纯粹的 hostname 或 IP 地址，而不是完整的 URL。

解决方案

正确的配置应该是移除 Host 参数中的 http:// 前缀：

[OUTPUT]
    Name                 opentelemetry
    Match                *
    Host                 my-opentelemetry-collector.namespace.svc.cluster.local
    Port                 4318
    Metrics_uri          /v1/metrics
    Logs_uri             /v1/logs
    Traces_uri           /v1/traces
    Log_response_payload True
    Tls                  Off
    Tls.verify           Off

配置要点

1. Host 参数格式：必须仅包含主机名或IP地址，不包含协议前缀
2. 端口指定：通过单独的 Port 参数指定
3. URI路径：通过 Metrics_uri、Logs_uri 和 Traces_uri 分别指定不同数据的接收路径
4. TLS配置：根据实际情况启用或禁用TLS

架构建议

在 Kubernetes 环境中实现 Fluent Bit 到 OpenTelemetry Collector 的日志传输时，建议采用以下架构：

1. 服务发现：使用 Kubernetes 的 DNS 服务发现机制，通过 <service-name>.<namespace>.svc.cluster.local 格式访问服务
2. 协议选择：根据安全需求选择 HTTP 或 gRPC 协议
3. 负载均衡：OpenTelemetry Collector 可以部署为多个副本，Fluent Bit 会自动进行负载均衡

验证方法

配置完成后，可以通过以下方式验证连接是否正常：

1. 检查 Fluent Bit 日志，确认没有连接错误
2. 在 OpenTelemetry Collector 中查看接收到的指标和日志数据
3. 使用 kubectl exec 进入 Fluent Bit 容器，尝试手动解析 Collector 的 DNS 记录

总结

正确配置 Fluent Bit 与 OpenTelemetry Collector 的连接需要注意主机名格式的规范性。通过移除协议前缀并确保 DNS 解析正常，可以建立稳定的日志传输通道。这种集成方式为构建可观测性平台提供了灵活的基础架构，能够支持多种后端系统的数据收集和分析需求。