Quick Flow
# 특정 container의 최근 lifecycle만 확인
docker events --since 10m \
--filter type=container \
--filter container=app
# 모든 container lifecycle을 JSON Lines로 기록
docker events --filter type=container --format '{{json .}}'
# exit state와 application output을 같은 시점으로 대조
docker inspect --format 'exit={{.State.ExitCode}} oom={{.State.OOMKilled}}' app
docker logs --tail 100 appdocker events는 Docker daemon이 본 object lifecycle을 실시간으로 보여 줍니다. process의 exception이나 request log는 포함하지 않으므로, 종료 원인은 events·inspect·application log를 함께 봅니다.
event 읽기
container에서는 create, start, die, stop, kill, restart, oom, health_status, destroy 같은 action이 나옵니다. die event의 attribute에는 exit code가 포함될 수 있고, kill과 stop은 signal·종료 경로를 구분하는 단서가 됩니다.
create -> start -> die -> stop -> destroy위 흐름은 가능한 한 예일 뿐 모든 종료가 같은 event를 내거나 같은 순서로 보인다는 보장은 아닙니다. restart policy가 있으면 die, restart, start가 반복될 수 있고, healthcheck는 health_status event를 별도로 남깁니다.
docker events --filter type=container --filter event=die
docker events --filter type=container --filter event=oom
docker events --filter type=container --filter event=health_status시간과 filter
--since와 --until은 Unix timestamp, RFC3339 시각, 10m·1h30m 같은 duration을 받습니다. duration은 client machine의 시간을 기준으로 계산되고, timezone offset이 없는 timestamp는 client local timezone으로 해석됩니다. incident timeline에는 Z 또는 offset을 붙여 다른 system과 기준을 맞춥니다.
docker events \
--since '2026-08-10T10:00:00Z' \
--until '2026-08-10T10:15:00Z' \
--filter type=container \
--filter container=app동일 filter를 여러 번 쓰면 OR로, 다른 종류의 filter를 함께 쓰면 AND로 해석합니다. 예를 들어 --filter container=api --filter container=worker는 둘 중 하나를, 여기에 --filter event=die를 추가하면 두 container 중 종료 event만 보여 줍니다.
보존 한계
Docker daemon은 최근 event 256개만 반환합니다. docker events --since 24h를 실행해도 그보다 앞선 event가 자동으로 복원되는 것은 아닙니다. local-scoped event는 해당 node에서만 보이며, Swarm-scoped event는 manager에서 보입니다.
장애 조사에는 terminal을 열어 live stream을 보거나, JSON Lines를 external collector로 즉시 전달합니다. durable audit trail, 장기 retention, alerting은 docker events 자체가 아니라 logging·monitoring system에서 설계합니다.
docker events --format '{{json .}}' >> docker-events.jsonl이 예시는 terminal session이 계속 살아 있고 file system 용량이 관리된다는 전제의 임시 기록입니다. production에서는 log rotation, collector restart, central storage와 event loss 대응을 포함한 별도 pipeline을 사용합니다.
docker events의 256개 history는 감사 로그가 아닙니다. 장애가 지난 뒤 events에 없다는 사실만으로 container가 죽지 않았다고 판단하지 말고, application log·host log·monitoring trace를 함께 확인하십시오.
참고 링크
1 sources