Мы эксплуатируем 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 с устройства отображения на оверлей2
Мы увеличили ресурсы длявсе экземпляры ECS, включая ЦП, ОЗУ и хранилище EBS, как мы видели в нескольких контейнерах.
Мы увеличиваем льготный период проверки работоспособности для сервиса с 0 до 240 сек
Увеличены KeepAliveTimeout и SocketTimeout до 180 секунд
Включены awslogs для контейнеров вместо stdout, но не было необычного поведения
ВключеноECSMetaData в контейнере и конвейерную всю информацию в журналах нашего приложения.Это помогло нам просмотреть все журналы только для проблемных контейнеров.
Включены возможности анализа контейнеров для лучшей отладки на уровне контейнеров
Из этих вещей, которыеПомогло больше всего, если обновить devicemapper до оверлейного драйвера хранилища и увеличить льготный период проверки работоспособности.
Количество ошибок поразительно сократилось с этими двумя, но мы все еще получаем эту проблему время от времени.
Мы видели, что все графики, относящиеся к экземпляру и контейнеру, которые представлены ниже, представляют собой журналы для него:
Журналы аналитики контейнера 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
}
Ни в одном журнале не было смехотворно высокой загрузки ЦП и памяти.
Мы перестали получать ответы от контейнера жертвы, скажем, в t1, мы получили ошибки взависимые услуги в t1 + 2 минуты и контейнер был забран ECS в t1 + 3 минуты
Наши конфигурации проверки работоспособностиниже:
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
Должны быть некоторые указания на конфликт ресурсов или сбой службы или подлинный сбой сети, чтобы объяснить все это.Но, как уже упоминалось, мы ничего не знали, что могло вызвать какие-либо проблемы.