我们在 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
我们发现:
- 重新启动 pod 并不能解决问题。
- 删除并重新应用守护进程集并不能解决问题。
- 重新启动节点未能解决问题。
- 终止节点并允许替换它们确实解决了问题。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 日志记录打开为“调试”,但怀疑这没有任何区别。