# running container의 live stream
docker stats api worker

# 현재 값 한 번만 기록
docker stats --no-stream --format \
  'table {{.Name}}\t{{.CPUPerc}}\t{{.MemUsage}}\t{{.NetIO}}\t{{.PIDs}}'

# memory limit 및 OOM 종료 이력과 함께 확인
docker inspect --format '{{.State.OOMKilled}} {{.HostConfig.Memory}}' api

수치 읽기

docker stats는 기본적으로 실행 중인 container만 stream합니다. --all은 중지된 container도 목록에 포함하려 하지만, 중지된 container는 stats data를 반환하지 않습니다. 종료된 job의 과거 CPU·memory 사용량을 보관하는 명령이 아닙니다.

limit와 함께 보기

memory가 limit에 근접했다고 바로 leak으로 판단하지 않습니다. startup cache, batch 처리, traffic spike일 수 있습니다. 반대로 memory graph가 낮아도 다른 process가 kill됐거나 host 전체가 압박을 받을 수 있으므로, container 종료 뒤에는 OOMKilled, exit code, kernel·daemon log, application log를 같이 봅니다.

docker stats api --no-stream
docker inspect --format \
  'oom={{.State.OOMKilled}} exit={{.State.ExitCode}} memory={{.HostConfig.Memory}}' api
docker logs --tail 100 api

Linux Docker CLI의 memory usage 표시는 cache를 뺀 값을 사용하지만, Docker API는 total usage와 cache를 별도로 제공합니다. API·cAdvisor·Prometheus 숫자와 CLI 수치가 다를 수 있으므로, dashboard를 바꿨다고 memory behavior가 달라졌다고 판단하지 않습니다.

CPU가 높고 I/O가 낮으면 연산·busy loop를, block I/O 증가와 latency를 함께 보면 file·DB·logging 병목을 의심할 수 있습니다. 이는 조사 시작점일 뿐 profiler, DB slow query, tracing 없이 원인을 확정하는 근거는 아닙니다.

관찰 범위

Docker Desktop에서 docker stats는 Linux VM 안에서 실행되는 container 사용량입니다. native host의 memory pressure, VM resource limit, 다른 application의 CPU·disk I/O는 Desktop resource settings와 OS monitoring도 함께 봐야 합니다. container limit을 정하는 기준은 CPU와 메모리 제한 기본 카드에서 다룹니다.

장기 추세·alert·장애 후 분석이 필요하면 docker stats --no-stream을 임시 기록에만 쓰고, Prometheus·cAdvisor·cloud monitoring·application metrics처럼 timestamped storage를 사용합니다. scrape interval, label cardinality, retention, alert threshold는 서비스의 traffic pattern에 맞춰 별도로 설계합니다.