我们已经将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秒
在容器上启用了awslogs而不是stdout，但没有异常行为
在容器中启用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+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
应该有一些指示来说明资源竞争、服务崩溃或真正的网络故障，以解释所有这些问题。但是，如上所述，我们并没有知道任何引起问题的原因。
