ECK Filebeat Daemonset向远程EKS集群转发日志报Bad Request错误求助

问题根因排查与解决方案 #

核心错误原因 #

你当前的配置存在多处冲突和格式错误，是导致400 Bad Request报错的核心原因：

1. 不必要的cloud配置冲突：cloud.id和cloud.auth是Elastic官方云服务专属配置，你自行托管的ECK集群无需配置，且重复的cloud配置块会覆盖你的显式ES输出配置，导致请求参数错乱。
2. hosts配置格式错误：ES输出的hosts参数需要为数组格式，且未明确指定端口会导致Filebeat默认拼接9200端口，与NLB实际暴露的HTTPS端口（通常为443）不匹配。
3. 代理与请求头逻辑冲突：显式配置proxy_url的同时指定自定义Host头，会导致HTTPS代理的CONNECT请求与业务请求的Host/端口逻辑不一致，Nginx Ingress无法匹配主机路由规则返回400。

可执行修复步骤 #

1. 修正Filebeat配置

删除冗余的cloud配置块，修正ES输出配置，参考调整后的配置片段：

output:
  elasticsearch:
    enabled: true
    # 替换为NLB实际暴露的HTTPS端口，默认Ingress HTTPS为443，如你自定义了9200监听可改为对应端口
    hosts: ["https://elasticsearch.dev.example.com:443"]
    username: '${ELASTICSEARCH_USERNAME}'
    password: '${ELASTICSEARCH_PASSWORD}'
    protocol: https
    ssl:
      verification_mode: "none"
    headers:
      Host: "elasticsearch.dev.example.com"
    # 四层NLB无需显式配置代理，直接删除以下两行配置即可
    # proxy_url: "https://example.elb.eu-west-2.amazonaws.com"
    # proxy_disable: false

同时删除DaemonSet中冗余的ELASTICSEARCH_HOST、ELASTICSEARCH_PORT环境变量，避免配置被环境变量意外覆盖。

2. 验证链路配置

• 确认AWS NLB的监听端口与你在hosts中填写的端口一致，后端目标组指向Nginx Ingress的对应HTTPS端口
• 检查Nginx Ingress的主机路由规则，确认elasticsearch.dev.example.com的路由已正确绑定到ES服务的端口
• 进入Filebeat Pod执行命令验证连通性：

  curl -v -H "Host: elasticsearch.dev.example.com" -u elastic:<你的ES密码> https://<NLB域名>:<端口>
  

  正常应返回ES的版本信息响应。

3. 异常排查辅助

如果修复后仍报错，可在filebeat.yml中添加logging.level: debug开启debug日志，同时查看Nginx Ingress的访问日志，确认400错误的具体触发原因（如请求头缺失、端口不匹配、路径错误等）。

内容的提问来源于stack exchange，提问作者Theo Sweeny