AWS ECS 服務任務被替換為（請求超時的原因）

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 網關超時，這對它們產生了很大的影響。

1. 將 Docker 存儲驅動從 devicemapper 升級到 overlay2

2. 正如我們在少數容器中看到的那樣，我們增加了所有 ECS 實例的資源，包括 CPU、RAM 和 EBS 存儲。

3. 我們將服務的健康檢查寬限期從 0 秒增加到 240 秒

4. 將 KeepAliveTimeout 和 SocketTimeout 增加到 180 秒

5. 在容器上啟用 awslogs 而不是 stdout，但沒有異常行為

6. 在容器中啟用 ECSMetaData 並在我們的應用程序日志中傳輸所有信息。 這有助於我們僅在所有日志中查找有問題的容器。

7. 啟用容器洞察力以實現更好的容器級調試

如果將 devicemapper 升級到 overlay2 存儲驅動程序並增加 healthcheck 寬限期，這其中幫助最大的事情。

這兩個錯誤的數量驚人地減少了，但我們仍然偶爾會遇到這個問題。

我們已經看到了所有與實例和容器相關的圖表，下面是它的日志：

受害容器的 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 和 Memory 利用率高得離譜。

我們在 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

應該有一些關於資源爭用或服務崩潰或 genuine.network 失敗的跡象來解釋這一切。 但正如所提到的，我們所知道的並沒有導致任何問題。

Answer 1

您從 1 到 7 的步驟幾乎與錯誤無關。

服務示例服務（實例 i-016b0a460d9974567）（端口 1047）由於（原因請求超時）在目標組示例服務中不正常

錯誤很明顯，您的 ECS 服務無法訪問負載均衡器健康檢查。

目標群體不健康

出現這種情況時，go 直接檢查容器的SG、Port、應用程序狀態或健康狀態碼。

可能的原因

• 可能有這種情況，后端服務中沒有路由Path /healthcheck
• /healthcheck的狀態碼不是200
• 可能是目標端口無效，請正確配置，如果應用程序在端口 8080 或 3000 上運行，則應為3000或8080
• 安全組不允許目標組上的流量
• 應用程序未在容器中運行

這些是健康檢查超時的可能原因。

Answer 2

我遇到了同樣的問題（ Reason request timeout ）。 我設法通過更新我的安全組入站規則來解決它。 目前，入站規則中沒有定義規則，所以我暫時為 ipv4 規則添加了一般允許所有流量，因為我當時正在開發中。