☰

由于元数据错误，带有 AWS 模块的 ECK 上的 Filebeat 失败

tag-icon • tag-icon kubernetes elasticsearch amazon-eks filebeat
由于元数据错误，带有 AWS 模块的 ECK 上的 Filebeat 失败

我们在 EKS (7.8) 中运行带有 ECK 的 Elastic Stack。我们注意到我们的 filebeat 守护进程集和 AWS 模块未处理来自 S3 和 SQS 队列备份的日志。查看 FileBeat 容器上的日志，我们注意到每个 filebeat pod 中都重复出现以下错误：

ERROR [s3] s3/input.go:206 SQS ReceiveMessageRequest failed: 
EC2RoleRequestError: no EC2 instance role found caused by: 
EC2MetadataError: failed to make Client request

我们发现：

  1. 重新启动 pod 并不能解决问题。
  2. 删除并重新应用守护进程集并不能解决问题。
  3. 重新启动节点未能解决问题。
  4. 终止节点并允许替换它们确实解决了问题。filebeat-pods 开始再次处理数据。

此问题已重复多次，且时间间隔不同。filebeat pod 每次可成功处理数据数周，有时仅处理几天，此错误就会再次发生。

尽管我们有解决方法（更换节点），但我们仍然想调查发生这种情况的原因。通过与 AWS 合作，我们最终找到了我们认为的根本原因的线索。

当 pod 成功启动时，我们似乎会看到如下消息：

{"log":"2021-02-17T17:08:47.378Z\u0009INFO\u0009[add_cloud_metadata]
\u0009add_cloud_metadata/add_cloud_metadata.go:93\u0009add_cloud_metadata: hosting provider
type detected as aws, metadata={\"account\":{\"id\":\"##########\"},\"availability_zone
\":\"#########\",\"image\":{\"id\":\"#############\"},\"instance\":{\"id\":\"i-#########
\"},\"machine\":{\"type\":\"#######\"},\"provider\":\"aws\",\"region\":\"######
\"}\n","stream":"stderr","time":"2021-02-17T17:08:47.379170444Z"}

如果我们重新启动一个 pod 并在“失败”的节点上监控它，我们会看到以下日志消息：

{"log":"2021-02-17T17:08:47.439Z\u0009INFO\u0009[add_cloud_metadata]
\u0009add_cloud_metadata/add_cloud_metadata.go:89\u0009add_cloud_metadata: hosting provider
 type not detected.\n","stream":"stderr","time":"2021-02-17T17:08:47.439427267Z"}

我们还验证了 pod 本身可以通过 curl 成功访问 EC2 元数据端点。

如能提供任何有关如何解决这一反复出现的问题的信息，我们将不胜感激。

Filebeat 配置：

    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: filebeat-config
    data:
      filebeat.yml: |-
        filebeat.config:
          modules:
            path: ${path.config}/modules.d/*.yml
            reload.enabled: true

        processors:
          - add_cloud_metadata: ~
          - add_docker_metadata: ~

        output.elasticsearch:
          workers: 5
          bulk_max_size: 5000
          hosts: ["${ES_HOSTS}"]
          username: "${ES_USER}"
          password: "${ES_PASSWORD}"

答案1

这实际上并不能解释为什么会发生上述情况，但对于遇到此问题的其他任何人，我们将 EC2 节点从 更改为m5.xlarge后r5.xlarge，再也没有看到此问题。这让我相信这可能是某种内存问题。为了完整起见，我们还按照上述建议将 filebeat 日志记录打开为“调试”，但怀疑这没有任何区别。

相关内容