Docker events: мониторинг событий контейнеров в реальном времени

Что показывает docker system events и чего он не заменяет

`docker system events` выводит события объектов Docker Engine, а без временного диапазона обычно продолжает ждать новые события. Для контейнерной диагностики лучше сразу ограничить поток `--filter type=container`, иначе в него попадут сети, volumes, images и другие типы объектов. События показывают факты жизненного цикла, но не содержимое stdout/stderr приложения, поэтому `docker events` дополняет, а не заменяет `docker logs`. Хорошая связка для сбоя — сначала увидеть последовательность `kill`/`die`/`restart`/`start`, затем посмотреть логи приложения около того же времени и `docker inspect` для exit code и restart policy. Так легче отделить падение процесса от ручного stop или внешнего перезапуска. В актуальной документации Docker отдельно указано, что при запросе прошлых событий возвращаются только последние 256 записей журнала событий, поэтому `docker events` нельзя считать долговременным архивом.

Важно: Для постоянной истории отправляйте события во внешнюю систему журналирования: встроенный журнал событий Docker ограничен и не заменяет архив.

Как наблюдать только нужный контейнер

1. 1: Откройте отдельный терминал и запустите `docker events --filter type=container`. Убедитесь, что при старте или остановке тестового контейнера появляются события.
2. 2: Сузьте поток до одного объекта: `docker events --filter container=myapp`. Фильтр принимает имя или идентификатор контейнера, поэтому удобнее использовать стабильное имя.
3. 3: Если нужен конкретный тип события, добавьте ещё один фильтр, например `--filter event=stop` или `--filter event=die`. Это снижает шум при расследовании повторяющихся остановок.
4. 4: Для ретроспективы задайте `--since 30m` либо точный timestamp. При необходимости ограничьте конец интервала `--until`, чтобы получить конечный набор событий.
5. 5: Сопоставьте время события с `docker logs --since ..`, системными логами хоста и политикой restart. Не делайте вывод о причине только по одному слову `die`: оно фиксирует завершение, но не объясняет первопричину.

Важно: Для короткого сбоя сохраните вывод в файл или используйте форматирование, иначе нужная последовательность быстро уйдёт с экрана.

Какие события полезны при расследовании

• start. контейнер запущен. кто или что инициировал запуск
• stop. запрошена штатная остановка. оператор, deploy, automation
• kill. контейнеру отправлен сигнал. тип сигнала и контекст
• die. основной процесс завершился. exit code, logs, OOM
• destroy. контейнер удалён. cleanup, compose down, ручная команда
• restart. движок перезапускает контейнер. restart policy и причину выхода

Предупреждение: Последовательность событий важнее одного события: `kill → die → stop` и `die → restart → start` описывают разные сценарии.

Фильтры: одинаковые ключи и разные ключи

Фильтр задаётся как `--filter key=value`, причём Docker позволяет передавать флаг несколько раз. В документации показано, что несколько значений одного ключа, например два `container=..`, трактуются как альтернативы: событие подходит для первого или второго контейнера. Комбинация разных критериев позволяет сузить поток, например `container=myapp` вместе с `event=stop`. Для обзора всех контейнерных событий используйте `type=container`; для сетей или volumes тип меняется. Такая схема лучше, чем постфильтрация `grep`, потому что лишние события не попадают в исходный поток. При сложном условии сначала проверьте его на тестовом контейнере, чтобы не пропустить нужный класс событий.

Как читать --since и --until без путаницы со временем

Docker поддерживает абсолютные timestamps и относительные интервалы вроде `10m` для `--since` и `--until`. Если в строке времени не указан часовой пояс, интерпретация зависит от локального времени клиента, поэтому для расследования между несколькими хостами лучше использовать явный offset или UTC. Относительный интервал удобен сразу после инцидента: например, запрос за последние 30 минут даёт небольшой набор событий, который легко сопоставить с логами. Для отчёта или воспроизводимого анализа лучше фиксировать абсолютные границы. Если команда без `--until` продолжает работать, это нормально: events предназначен и для live-наблюдения.

Мини-чеклист расследования самопроизвольного рестарта

• Зафиксировать точное имя или ID контейнера.
• Снять events за интервал до и после сбоя.
• Проверить порядок die, kill, stop, restart, start.
• Посмотреть exit code и restart policy через inspect.
• Сопоставить timestamp с docker logs и журналом хоста.
• Проверить OOM, deploy hooks, health automation и внешние watchdog-процессы.
• Не считать `die` самостоятельным диагнозом.

Важно: Если контейнер критичен, сохраняйте события централизованно: ручной терминал полезен для диагностики, но не является долговременным аудит-логом.

Как отличить рестарт по политике от ручного вмешательства

При рестарте полезно смотреть не только на само событие `start`, а на несколько строк до него. Если перед новым `start` есть `die`, а контейнер настроен на автоматический restart, это согласуется со сценарием повторного запуска после завершения процесса. Если видны `stop` или `kill`, стоит проверить deploy-скрипты, действия оператора и сервисы управления контейнерами. Exit code добавляет контекст, но его тоже нельзя читать изолированно: одинаковый код может возникать по разным причинам. Сопоставьте события с логами приложения и временем изменений на хосте. Так `docker events` превращается из «ленты фактов» в временную ось расследования, не подменяя собой диагностику приложения. Для воспроизводимого расследования сохраните команду наблюдения вместе с фильтрами и часовым интервалом: одинаковый запрос проще повторить после следующего инцидента и сопоставить с журналом приложения. Если поток слишком шумный, сначала ограничьте `type=container`, затем добавьте `container=<name>` и только после этого события по имени.

Как сохранить события для разборов после инцидента

`docker events` удобен как live-поток, но при ручном просмотре важная последовательность легко исчезает из терминала. Для расследования запускайте команду с ограниченным `--since`, нужными фильтрами и машинно читаемым `--format json`, затем перенаправляйте вывод в файл или систему журналирования. Это позволяет сопоставить `die`, `restart`, `start`, изменения сети и другие события по времени с логами приложения и метриками хоста. Учитывайте, что события Docker Engine не заменяют полноценный аудит: они показывают действия и состояния объектов Docker, но не всегда объясняют, кто инициировал команду и почему приложение завершилось. Причину подтверждайте через `docker inspect`, `docker logs` и журналы ОС.

Что учитывать

Условия меняются. Страница отражает состояние на 2026-09-20; при расхождении с официальной документацией приоритет у первоисточника.

Источники и проверка

Фактическая часть сверена по первичным источникам (в т.ч. docker system events). Пример и формулировки — редакция N1RO на 2026-09-20.

• docker system events