はじめに
dockerコンテナを動かしていると、何らかの原因で起動シェルが止まってしまうことがある。今回はその調査方法の一つ、ECS用にAWSからオフィシャルのログ収集ツール ECSログコレクター が提供されているので、今回はそれを紹介。
インストール方法
AWS公式サイトにある通り、ツールを取得する
$ curl -O https://raw.githubusercontent.com/awslabs/ecs-logs-collector/master/ecs-logs-collector.sh
その後、sudoをつけてシェルを実行する
$ sudo bash ./ecs-logs-collector.sh
しばらくすると、諸々ログが取れる
$ sudo bash ./ecs-logs-collector.sh Trying to check if the script is running as root ... ok Trying to resolve instance-id ... ok Trying to collect system information ... ok Trying to check disk space usage ... ok Trying to collect common operating system logs ... ok Trying to collect kernel logs ... ok Trying to get mount points and volume information ... ok Trying to check SELinux status ... ok Trying to get iptables list ... ok Trying to detect installed packages ... ok Trying to detect active system services list ... ok Trying to gather Docker daemon information ... ok Trying to inspect all Docker containers ... ok Trying to collect Docker daemon logs ... ok Trying to collect Amazon ECS Container Agent logs ... ok Trying to collect Amazon ECS Container Agent state and config ... ok Trying to collect Amazon ECS Container Agent engine data ... ok Trying to archive gathered log information ... ok
無事完了すると、correctというディレクトリが作られ、ログが集約される。
$ ls -ltr 合計 236 -rw-rw-r-- 1 ec2-user ec2-user 14181 7月 19 14:25 ecs-logs-collector.sh drwxr-xr-x 3 root root 4096 7月 19 14:25 collect -rw-r--r-- 1 root root 219653 7月 19 14:26 collect-i-0051ca9951de8e82a.tgz
dockerの状態を確認するには、correct、インスタンスid、配下のdockerディレクトリにログとして出力される。
/collect/i-xxxxxxxxx/docker
ざっと見てみると、
[
{
"Id": "xxxxxxx",
"Created": "2019-07-19T12:36:48.665852002Z",
"Path": "sh",
"Args": [
"/root/bin/execute.sh"
],
"State": {
"Status": "exited",
"Running": false,
"Paused": false,
"Restarting": false,
"OOMKilled": true,
"Dead": false,
"Pid": 0,
"ExitCode": 137,
"Error": "",
"StartedAt": "2019-07-19T12:36:49.47823385Z",
"FinishedAt": "2019-07-19T13:12:07.097787961Z"
},
終了したときの状態がわかる。
OOMKilledがtrueになっており、このコンテナはメモリを使い果たし、OOMKillerが発動、コンテナがkillされたのではと推測が立つ。
linuxのimageをbaseに使っていると、当然メモリーを使い切った際にはOOM killerなどは発生する。その際の原因調査をする上では、サーバレスのfargateよりは、まだホストにログインできるECSの方が原因調査はやりやすい。
それ以外にも非常に細かい状態を確認することができる。
"DnsOptions": null,
"DnsSearch": null,
"ExtraHosts": null,
"GroupAdd": null,
"IpcMode": "shareable",
"Cgroup": "",
"Links": null,
"OomScoreAdj": 0,
"PidMode": "",
"Privileged": false,
"PublishAllPorts": false,
"ReadonlyRootfs": false,
"SecurityOpt": null,
"UTSMode": "",
"UsernsMode": "",
"ShmSize": 67108864,
"Runtime": "runc",
"ConsoleSize": [
0,
0
],
"Isolation": "",
"CpuShares": 2,
"Memory": 2147483648,
"NanoCpus": 0,
"CgroupParent": "/ecs/ad627055-dc5b-4903-96ed-be9e0f25cf33",
"BlkioWeight": 0,
"BlkioWeightDevice": null,
"BlkioDeviceReadBps": null,
"BlkioDeviceWriteBps": null,
"BlkioDeviceReadIOps": null,
"BlkioDeviceWriteIOps": null,
"CpuPeriod": 0,
"CpuQuota": 0,
"CpuRealtimePeriod": 0,
"CpuRealtimeRuntime": 0,
"CpusetCpus": "",
"CpusetMems": "",
"Devices": null,
"DeviceCgroupRules": null,
"DiskQuota": 0,
"KernelMemory": 0,
"MemoryReservation": 1073741824,
"MemorySwap": 4294967296,
"MemorySwappiness": null,
"OomKillDisable": false,
"PidsLimit": 0,
"Ulimits": [
{
"Name": "cpu",
"Hard": 0,
"Soft": 0
},
{
"Name": "nofile",
"Hard": 4096,
"Soft": 1024
}
],
"CpuCount": 0,
"CpuPercent": 0,
"IOMaximumIOps": 0,
"IOMaximumBandwidth": 0,
"MaskedPaths": [
"/proc/acpi",
"/proc/kcore",
"/proc/keys",
"/proc/latency_stats",
"/proc/timer_list",
"/proc/timer_stats",
"/proc/sched_debug",
"/proc/scsi",
"/sys/firmware"
],
詳細はこちら。
https://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/ecs-logs-collector.html
では、今日はこの辺で。
