Главная/Observability и диагностика/Обзор

Раздел 13. Observability и диагностика

Диагностика в контейнеризованной среде отличается от обычной не сложностью, а тем, что привычные инструменты находятся не там, где ожидается. Процесс виден на host, но с другим PID. Логов в /var/log нет. ping в образе не установлен. Файловая система приложения существует, но её путь неочевиден. Сеть работает, но localhost означает не то, что раньше.

Раздел даёт две вещи: набор инструментов и — важнее — методику. Методика превращает диагностику из перебора гипотез в последовательность проверок, каждая из которых сужает область поиска. Именно она отличает инженера от человека, который «перезапустил, и заработало».

Завершает раздел таблица из более чем двадцати типичных проблем в формате «симптом → возможная причина → проверка → исправление». Эта таблица — рабочий инструмент, к которому возвращаются после курса.

Цели обучения

После раздела учащийся сможет:

объяснить, как Docker собирает и хранит логи container, и настроить logging driver;
читать логи осознанно: фильтрация по времени, хвост, метки времени, поток stderr;
извлекать нужные поля из docker inspect через --format;
использовать docker events для наблюдения за происходящим в реальном времени;
интерпретировать docker stats и docker top и понимать, откуда берутся эти цифры;
диагностировать нехватку ресурсов: OOM killer, exit code 137, 143, throttling CPU;
находить причину restart loop и failing healthcheck;
находить, что заняло дисковое пространство, и безопасно освобождать его;
читать логи Docker daemon через journalctl;
применять nsenter для входа в namespaces container, strace и tcpdump для глубокой диагностики;
переходить от симптома к root cause по воспроизводимой методике.

Предварительные знания

Раздел 04. Containers и lifecycle — состояния, сигналы, exit codes;
Раздел 07. Storage — где лежат данные;
Раздел 08. Networking — сетевая модель;
Раздел 11. Production желательно — resource limits.

Материалы

Логи и logging drivers
Путь лога от stdout процесса до docker logs. Драйверы json-file, local, journald, syslog и их различия. Ротация логов и почему без неё диск заканчивается. Настройка в daemon.json и на уровне container. Ограничения docker logs при разных драйверах. Логи в Compose.
Inspect, events, stats
Полная структура docker inspect и извлечение полей через --format. docker events с фильтрами: наблюдение за стартами, остановками, health-переходами и OOM. docker stats: что означает каждая колонка и почему MEM USAGE отличается от того, что показывает приложение. docker top и соответствие процессам на host.
Нехватка ресурсов
OOM killer: как принимает решение, где оставляет след, как его найти. Exit code 137 и его двойное толкование. Exit code 143. CPU throttling и его диагностика через cgroup-статистику. Исчерпание PID limit и файловых дескрипторов. Диагностика утечки памяти в Python-приложении.
Дисковое пространство и очистка
docker system df и df -v: где именно расходуется место. Образы, слои, контейнеры, volumes, build cache, логи. Безопасная очистка по категориям с предварительным просмотром. Разбор опасных вариантов prune и того, что именно они удаляют безвозвратно. Настройка автоматических ограничений.
Глубокая диагностика
Логи daemon через journalctl -u docker.service. nsenter для входа в namespaces без изменения образа. Диагностика container без shell. strace для анализа системных вызовов, tcpdump для анализа трафика — как дополнительные инструменты с указанием требуемых привилегий. Поиск файловой системы container на host.
Таблица диагностики
Более двадцати типичных проблем в формате «симптом → возможная причина → проверка → исправление». Структурировано по подсистемам: запуск, логи, сеть, storage, ресурсы, сборка. Основной справочный материал раздела.
Практические задания
Лабораторные задания раздела с проверкой результата.

Практические задания

№	Задание	Тип
1	Настроить ротацию логов и проверить, что размер файла ограничен	обяз.
2	Извлечь через `docker inspect --format` пять разных полей одной командой	обяз.
3	Воспроизвести OOM kill, найти след в `docker events` и в логах ядра	обяз.
4	Найти, что занимает больше всего места в Docker data, и освободить его безопасно	обяз.
5	Войти в namespaces работающего container через `nsenter` и выполнить диагностику сети	обяз.
6	Наблюдать за health-переходами через `docker events` во время старта stack	доп.
7	Продиагностировать CPU throttling через cgroup-статистику	доп.
8	Провести диагностику container, в образе которого нет shell	доп.
9	Сервис перезапускается каждые 40 секунд. Найти причину, не изменяя приложение	диаг.
10	Диск заполнен на 95 %, Docker занимает 60 GB. Составить план освобождения с оценкой рисков	★

Полные формулировки — в exercises.md.

Критерии завершения раздела

Раздел пройден, когда учащийся может без подсказок:

Объяснить, почему логи приложения не должны писаться в файл внутри container.
Найти причину exit code 137 и отличить OOM от внешнего SIGKILL.
Определить, что занимает дисковое пространство, и очистить его без потери нужных данных.
Продиагностировать недоступный сервис за пять шагов, не угадывая.
Войти в сетевой namespace container и посмотреть его сокеты, не устанавливая ничего в образ.
Объяснить, почему docker stats показывает объём памяти, отличающийся от метрик приложения.

Проверьте себя: Quiz 13 и debugging challenges.

Что дальше

Мы умеем строить, защищать и чинить. Следующий раздел — о доставке: как образ попадает с машины разработчика туда, где он будет запущен.