Логи, метрики, events и системная диагностика

После модуля вы сможете связать logs, metrics, events, inspect и daemon journal в единую временную шкалу и собрать evidence до изменения системы.

• logs объясняют сообщения процесса
• metrics показывают ресурсное поведение
• events фиксируют изменения Engine
• inspect хранит конфигурацию и state
• daemon logs описывают control plane

Docker захватывает stdout/stderr PID 1 и передаёт записи logging driver. docker logs работает только когда driver поддерживает чтение; приложение не должно полагаться на внутренние файлы контейнера как единственный источник.

По умолчанию json-file может расти без rotation. Для обычных Engine-систем Docker рекомендует local driver с ротацией; max-size и max-file ограничивают хранение. Новые daemon defaults применяются только к новым containers.

Структурированная запись содержит timestamp, level, service, request/trace ID и событие. Не пишите passwords, tokens и персональные данные. Ограничивайте cardinality и размер payload.

Container runtime добавляет время и stream, но application timestamp всё равно важен. Синхронизация времени и единый UTC упрощают correlation.

docker stats показывает CPU, memory, network, block I/O и PIDs. Это моментальный operational view, а не долговременная система мониторинга. Для trends нужны scraper, storage, dashboards и alerts.

На Linux CLI вычитает cache из memory usage, тогда как API/cgroup могут показывать total. PIDS включает threads. Наблюдение без limits и baseline затрудняет интерпретацию.

docker events — поток best-effort событий create, start, die, destroy, health и других действий. Фильтры и timeNano помогают связать их с logs и inspect.

Events не являются долговременным audit log: храните нужный поток внешне. Отсутствие старого события не доказывает, что действие не происходило.

Диагностика идёт от scope к evidence: context и время → объект → state → logs → events → resources → daemon/host. Restart и prune до фиксации фактов уничтожают часть картины.

Daemon failures ищут в journalctl -u docker.service, storage capacity/inodes, kernel OOM и network/firewall. Debug logging включают ограниченно: он увеличивает объём и может раскрыть чувствительные metadata.

• Зафиксируйте UTC и Docker context
• Используйте labels как ownership metadata
• Ограничивайте log retention для каждого container
• Не парсите цветной табличный вывод
• Сохраняйте inspect JSON до rm
• Сопоставляйте минимум два независимых сигнала
• Не запускайте prune во время расследования
• Формулируйте гипотезу до изменения state

Создайте шумный процесс с local logging и rotation, затем исследуйте logs и runtime metrics.

docker run --detach --name docker-m12-app --label course.module=12 --memory 64m --cpus 0.5 --log-driver local --log-opt max-size=10k --log-opt max-file=2 alpine:3.21 sh -c 'i=0; while [ "$i" -lt 2000 ]; do i=$((i+1)); printf "ts=%s level=info request_id=req-%04d message=working payload=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx\n" "$(date -u +%FT%TZ)" "$i"; [ $((i%500)) -eq 0 ] && echo "level=warn checkpoint=$i" >&2; done; sleep 300'
docker inspect docker-m12-app --format '{{json .HostConfig.LogConfig}}' | jq
docker inspect docker-m12-app --format 'log_path={{.LogPath}}'
docker logs --tail 10 --timestamps docker-m12-app
docker logs --since 5m --until 0s docker-m12-app 2>&1 | tail -20

docker stats docker-m12-app --no-stream
docker stats docker-m12-app --no-stream --format '{{json .}}' | jq
docker top docker-m12-app
docker inspect docker-m12-app --format '{{json .State}}' | jq '{Status,Pid,StartedAt,OOMKilled,Error}'
docker system df
docker system df --verbose

Запишите lifecycle events отдельного failed container и восстановите timeline.

timeout 10s docker events --since 0s --filter type=container --filter container=docker-m12-event --format '{{json .}}' > /tmp/docker-m12-events.jsonl &
event_pid=$!
sleep 1
docker run --name docker-m12-event alpine:3.21 sh -c 'echo event-demo; exit 42' || true
docker rm docker-m12-event
wait "$event_pid" || true
jq -s 'map({action:.Action,timeNano:.timeNano})' /tmp/docker-m12-events.jsonl

docker run --name docker-m12-failure --log-driver local alpine:3.21 sh -c 'echo "fatal: dependency unavailable" >&2; exit 42' || true
docker ps -a --filter name=docker-m12-failure
docker logs --timestamps docker-m12-failure
docker inspect docker-m12-failure --format '{{json .State}}' | jq
docker events --since 10m --until 0s --filter container=docker-m12-failure

Критерий: logging options подтверждены inspect; stats получены как JSON; exit 42 виден в logs, inspect и events.

Проверьте control plane отдельно от приложения. Команды journal требуют прав на system journal.

docker info --format 'logging={{.LoggingDriver}} cgroup={{.CgroupVersion}} driver={{.Driver}}'
docker version
systemctl --no-pager --full status docker.service | sed -n '1,25p'
journalctl -u docker.service --since '10 minutes ago' --no-pager | tail -50
df -h /var/lib/docker
df -i /var/lib/docker

• client error до API — context/transport
• created, но не started — runtime/mount/security
• exited — State, logs, OOM и events
• daemon unavailable — systemd journal/socket/disk
• рост latency — CPU throttling, memory pressure, I/O и network
• disk full — images, writable layers, volumes и logs

• Что именно читает docker logs?
• Зачем log rotation?
• Почему новые daemon defaults не меняют старые containers?
• Почему stats и cgroup memory различаются?
• Что означает высокий PIDS?
• Являются ли events audit log?
• Какие evidence собрать до rm?
• Когда включать debug?

docker rm --force docker-m12-app docker-m12-failure 2>/dev/null || true
rm -f /tmp/docker-m12-events.jsonl
docker ps -a --filter name=docker-m12
docker system df

Модуль освоен, если вы строите временную шкалу без догадок и локализуете failure до безопасного изменения.