【问题标题】:AWS ECS service Tasks getting replaced with (reason Request timed out)AWS ECS 服务任务被替换为(原因请求超时)
【发布时间】:2021-09-29 16:21:51
【问题描述】:

我们将 ECS 作为容器编排层运行了 2 年多。但是有一个问题我们无法找出原因,在我们的少数(node.js)服务中,我们已经开始观察 ECS 事件中的错误,因为

service example-service (instance i-016b0a460d9974567) (port 1047) is unhealthy in target-group example-service due to (reason Request timed out)

这会导致我们的依赖服务开始遇到 504 网关超时,这对它们有很大影响。

  1. 将 Docker 存储驱动程序从 devicemapper 升级到 overlay2

  2. 正如我们在少数容器中看到的那样,我们增加了所有 ECS 实例的资源,包括 CPU、RAM 和 EBS 存储。

  3. 我们将服务的运行状况检查宽限期从 0 秒增加到 240 秒

  4. 将 KeepAliveTimeout 和 SocketTimeout 增加到 180 秒

  5. 在容器而不是标准输出上启用 awslog,但没有异常行为

  6. 在容器中启用 ECSMetaData 并将所有信息流水线化到我们的应用程序日志中。这有助于我们仅查找有问题的容器的所有日志。

  7. 启用容器洞察以更好地进行容器级调试

如果将 devicemapper 升级到 overlay2 存储驱动程序并增加运行状况检查宽限期,这些事情最有帮助。

这两个错误的数量已经惊人地减少了,但我们仍然偶尔会遇到这个问题。

我们已经看到了所有与实例和容器相关的图表,下面是它的日志:

受害容器的 ECS 容器洞察日志:

查询:

fields CpuUtilized, MemoryUtilized, @message
| filter Type = "Container" and EC2InstanceId = "i-016b0a460d9974567" and TaskId = "dac7a872-5536-482f-a2f8-d2234f9db6df"

回答的示例日志:

{
"Version":"0",
"Type":"Container",
"ContainerName":"example-service",
"TaskId":"dac7a872-5536-482f-a2f8-d2234f9db6df",
"TaskDefinitionFamily":"example-service",
"TaskDefinitionRevision":"2048",
"ContainerInstanceId":"74306e00-e32a-4287-a201-72084d3364f6",
"EC2InstanceId":"i-016b0a460d9974567",
"ServiceName":"example-service",
"ClusterName":"example-service-cluster",
"Timestamp":1569227760000,
"CpuUtilized":1024.144923245614,
"CpuReserved":1347.0,
"MemoryUtilized":871,
"MemoryReserved":1857,
"StorageReadBytes":0,
"StorageWriteBytes":577536,
"NetworkRxBytes":14441583,
"NetworkRxDropped":0,
"NetworkRxErrors":0,
"NetworkRxPackets":17324,
"NetworkTxBytes":6136916,
"NetworkTxDropped":0,
"NetworkTxErrors":0,
"NetworkTxPackets":16989
}

没有任何日志的 CPU 和内存使用率高得离谱。

我们在 t1 时停止从受害者容器收到响应,在 t1+2 分钟时我们在依赖服务中遇到错误,并且容器在 t1+3 分钟时被 ECS 带走

我们的健康检查配置如下:

Protocol HTTP
Path  /healthcheck
Port traffic port
Healthy threshold  10
Unhealthy threshold 2
Timeout  5
Interval 10
Success codes 200

如果您需要更多信息,请告诉我,我很乐意提供。我们正在运行的配置是:

docker info
Containers: 11
 Running: 11
 Paused: 0
 Stopped: 0
Images: 6
Server Version: 18.06.1-ce
Storage Driver: overlay2
 Backing Filesystem: xfs
 Supports d_type: true
 Native Overlay Diff: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
 Volume: local
 Network: bridge host macvlan null overlay
 Log: awslogs fluentd gcplogs gelf journald json-file logentries splunk syslog
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Init Binary: docker-init
containerd version: 468a545b9edcd5932818eb9de8e72413e616e86e
runc version: 69663f0bd4b60df09991c08812a60108003fa340
init version: fec3683
Security Options:
 seccomp
  Profile: default
Kernel Version: 4.14.138-89.102.amzn1.x86_64
Operating System: Amazon Linux AMI 2018.03
OSType: linux
Architecture: x86_64
CPUs: 16
Total Memory: 30.41GiB
Name: ip-172-32-6-105
ID: IV65:3LKL:JESM:UFA4:X5RZ:M4NZ:O3BY:IZ2T:UDFW:XCGW:55PW:D7JH
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): false
Registry: https://index.docker.io/v1/
Labels:
Experimental: false
Insecure Registries:
 127.0.0.0/8
Live Restore Enabled: false

应该有一些关于资源争用或服务崩溃或真正的网络故障的迹象来解释这一切。但如前所述,我们所知道的没有任何问题。

【问题讨论】:

标签: amazon-web-services docker timeout amazon-ecs


【解决方案1】:

您从 1 到 7 的步骤几乎与错误无关。

服务示例-服务(实例 i-016b0a460d9974567)(端口 1047)是 由于(原因请求定时),目标组示例服务不健康 出)

错误很明显,负载均衡器健康检查无法访问您的 ECS 服务。

目标群体不健康

遇到这种情况,直接去查看容器SG、Port、应用状态或者健康状态码。

可能的原因

  • 可能是这样,后端服务中没有路由Path /healthcheck
  • 来自/healthcheck 的状态码不是200
  • 可能是目标端口无效,请正确配置,如果应用程序运行在端口8080或3000上应该是30008080
  • 安全组不允许目标组上的流量
  • 应用程序未在容器中运行

这些是健康检查超时的可能原因。

【讨论】:

  • 嗨@adiii,这些都是标准的检查和尝试。我已经明确表示它偶尔会发生一次,这意味着它在 99.9% 的时间内都在工作,这排除了您提到的所有可能原因。我非常了解这些,因此提出了这个问题。 Overlay2 确实在很大程度上解决了问题,因为新容器有时会卡住,因为设备映射器在管理 docker 容器存储时性能不佳。查看github.com/moby/moby/issues/20401了解更多详情。
  • 是的,我同意,但错误来自健康检查。可能是进程崩溃并消耗CPU
  • 你能 ssh 你的 ec2 实例吗?
  • 正如我所说,我已经看到了所有这些,也分享了容器见解,没有什么不寻常的。我看到,我自己的应用程序日志、通过 cloudwatch 上的 awslogs 和容器洞察力的容器日志,它们都没有真正引导我找到任何可以确定问题的东西。这是一种非常不寻常的行为。我的所有应用程序和容器日志都显示所有 API 在容器关闭之前的一小段时间内提供服务。如果 healthchek 是问题,ALB 和 ECS 调度程序不应该让容器运行 30 分钟,您可以从我的运行状况检查设置中检查。
  • 多做一件事Unhealthy threshold 10 实例不健康阈值有时由于负载或其他原因导致应用程序 thorw badegateway,因此应该认真处理这些情况,并降低健康阈值 2
【解决方案2】:

我遇到了同样的问题(原因请求超时)。 我设法通过更新我的安全组入站规则来解决它。 目前 Inbound 规则中没有定义规则,所以我暂时为 ipv4 规则添加通用允许所有流量,因为我当时正在开发中。

【讨论】:

    猜你喜欢
    • 2023-01-03
    • 1970-01-01
    • 2018-12-03
    • 2020-09-06
    • 2018-09-06
    • 1970-01-01
    • 1970-01-01
    • 2019-09-10
    • 1970-01-01
    相关资源
    最近更新 更多