빠른 흐름

docker events
docker events --since 10m
docker events --filter "type=container"
docker events --filter "container=app" --filter "event=die"
docker events --format "{{.Time}} {{.Type}} {{.Action}} {{json .Actor.Attributes}}"

추적 흐름

events는 daemon이 본 객체 변화를 시간순으로 보여준다

docker events는 컨테이너 안의 애플리케이션 로그가 아니라 Docker daemon이 관찰한 객체 이벤트를 보여줍니다. 컨테이너 생성, 시작, 종료, 제거, 네트워크 연결, 볼륨 생성 같은 lifecycle 변화가 시간순으로 흐릅니다. "앱이 무슨 메시지를 남겼는가"는 docker logs가 먼저이고, "Docker 관점에서 언제 죽었는가"는 docker events가 먼저입니다.

container create
container start
network connect
container die
container stop
container destroy

갑자기 컨테이너가 사라졌을 때 logs만 보면 마지막 앱 출력만 남습니다. events를 같이 보면 kill, die, stop, destroy 중 어느 단계가 있었는지 분리해서 볼 수 있습니다.

--since와 --until은 장애 시간대를 좁힐 때 쓴다

이벤트 스트림은 기본적으로 실행 시점 이후를 계속 따라갑니다. 이미 지나간 장애를 확인하려면 --since로 시작 시간을 지정하고, 필요한 경우 --until로 끝 시간을 제한합니다.

# 최근 10분 이벤트
docker events --since 10m

# 특정 시간 구간
docker events \
  --since "2026-05-23T14:00:00" \
  --until "2026-05-23T14:10:00"

운영 장애 대응에서는 로그 수집 시스템의 시간대와 Docker host의 시간대가 맞는지도 같이 확인해야 합니다. 애플리케이션 로그의 시각과 daemon 이벤트 시각이 다르면 원인 순서를 잘못 판단할 수 있습니다.

filter는 대상 객체와 이벤트 종류를 좁힌다

전체 이벤트를 그대로 보면 unrelated container, network, image 이벤트가 섞입니다. --filter로 container 이름, type, event를 좁히면 필요한 lifecycle만 남길 수 있습니다.

# 특정 컨테이너의 이벤트만
docker events --filter "container=app"

# 컨테이너 종료 이벤트만
docker events --filter "type=container" --filter "event=die"

# 볼륨 생성/삭제 흐름 확인
docker events --filter "type=volume"

여러 filter를 같이 쓰면 조건을 더 좁힐 수 있습니다. 예를 들어 특정 컨테이너의 die 이벤트만 보면 종료 시각과 exit 관련 속성을 빠르게 확인할 수 있습니다.

format은 자동 수집과 비교를 편하게 만든다

기본 출력은 사람이 읽기 좋지만, CI 로그나 장애 메모에 붙이려면 필요한 필드만 남기는 편이 낫습니다. --format으로 시간, 객체 타입, 액션, 속성을 고정하면 여러 호스트의 결과를 비교하기 쉽습니다.

docker events \
  --since 30m \
  --filter "type=container" \
  --format "{{.Time}} {{.Type}} {{.Action}} {{.Actor.Attributes.name}}"

events는 장기 보관용 감사 로그가 아닙니다. 장기간 추적이 필요하면 Docker events를 외부 로깅 시스템이나 모니터링 파이프라인에 전달하는 별도 구성이 필요합니다.

체크포인트

주의할 점

컨테이너가 restart policy로 반복 재시작되는 상황에서는 start, die, restart 이벤트가 짧은 간격으로 이어질 수 있습니다. 이때는 events로 재시작 패턴을 확인하고, docker inspect의 restart count와 logging driver의 보존·회전 설정을 함께 점검해야 합니다.