Question

我们将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网关超时，这会对它们产生很大的影响。

将Docker存储驱动程序从devicemapper升级到overlay2
我们增加了所有ECS实例的资源，包括在几个容器中看到的CPU，RAM和EBS存储。
我们将服务的健康检查宽限期从0秒增加到240秒
KeepAliveTimeout和SocketTimeout增加到180秒
在容器而不是stdout上启用了awslogs，但是没有异常行为
在容器上启用ECSMetaData并以管道方式传递应用程序日志中的所有信息。这有助于我们仅在有问题的容器中查找所有日志。
启用了容器见解以进行更好的容器级调试

如果将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 + 2mins时我们在依赖服务中出错，并且在t1 + 3mins时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

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

Answer 1

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

服务示例服务（实例i-016b0a460d9974567）（端口1047）是由于（原因请求已计时），目标组示例服务中的服务不健康出）

错误非常清楚，您的ECS服务无法通过负载均衡器运行状况检查。

目标群体不健康

在这种情况下，请直接检查容器SG，端口，应用程序状态或运行状况状态代码。

可能的原因

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

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

AWS ECS服务任务被替换（原因请求超时）

1 个答案: