MAATRIX / Блог / Логи и мониторинг контейнеров

Логи и мониторинг контейнеров

Блог MAATRIX · 2026-07-07

Контейнер, за которым не следят, однажды молча упадёт или сожрёт весь диск логами. Настраиваем чтение логов, ротацию и мониторинг ресурсов — без тяжёлых стеков.

Чтение логов

['Базовый инструмент — docker logs. Смотрим последние строки и следим в реальном времени:', '
docker logs --tail 100 -f app
', 'Часто нужен диапазон по времени — например, что было за последний час:', '
docker logs --since 1h --timestamps app
', 'Если контейнеров много, удобнее compose — он покажет логи всего стека сразу, с цветной разбивкой по сервисам:', '
docker compose logs -f --tail 50
']

Нужен сервер под эту задачу?

Разверните VPS MAATRIX за пару минут: NVMe, AMD EPYC, root-доступ, локации UK и США. Оплата картой РФ и по СБП.

Арендовать VPS для Docker

Ротация логов

['По умолчанию Docker пишет логи в JSON-файлы, которые растут бесконечно. Болтливый контейнер способен забить весь диск за сутки. Лечится ротацией в /etc/docker/daemon.json:', '
{\n  "log-driver": "json-file",\n  "log-opts": {\n    "max-size": "10m",\n    "max-file": "3"\n  }\n}
', 'После правки перезапустите демон:', '
systemctl restart docker
', 'Теперь каждый контейнер хранит максимум 3 файла по 10 МБ. Проверить, где физически лежат логи и сколько весят:', '
du -sh /var/lib/docker/containers/*/*-json.log
', 'На NVMe-дисках MAATRIX запись логов не создаёт I/O-затыков, но дисциплина ротации всё равно обязательна — место не резиновое.']

Мониторинг ресурсов

['Живая картина потребления CPU, памяти, сети и диска по каждому контейнеру:', '
docker stats
', 'Для скриптов и алертов удобен разовый снимок в нужном формате:', '
docker stats --no-stream \\\n  --format "table {{.Name}}\\t{{.CPUPerc}}\\t{{.MemUsage}}"
', 'Проверить состояние и код выхода упавшего контейнера:', "
docker inspect --format '{{.State.Status}} {{.State.ExitCode}}' app
"]

Healthcheck

['Мониторинг ресурсов не скажет, что приложение внутри зависло, а процесс жив. Для этого — healthcheck. Docker сам будет проверять сервис и помечать контейнер как unhealthy:', '
services:\n  app:\n    image: myapp:1.0\n    healthcheck:\n      test: ["CMD", "curl", "-f", "http://localhost:8080/health"]\n      interval: 30s\n      timeout: 5s\n      retries: 3
', 'Статус проверок виден в docker ps в колонке STATUS — например, Up 2 hours (healthy). На это можно повесить автоперезапуск или алерт.']

Лёгкий мониторинг: Dozzle

['Не хотите тянуть тяжёлый стек Prometheus + Grafana ради одного VPS? Dozzle даёт веб-интерфейс логов всех контейнеров в реальном времени, весит копейки:', '
docker run -d --name dozzle \\\n  --restart unless-stopped \\\n  -v /var/run/docker.sock:/var/run/docker.sock \\\n  -p 127.0.0.1:8888:8080 \\\n  amir20/dozzle
', 'Пробросьте порт через nginx с basic-auth — и у вас удобный дашборд логов без базы данных и настройки экспортеров.']

Частые ошибки

['
  • Логи не ротируются — диск заполнен на 100%, контейнеры падают. Всегда настраивайте max-size и max-file.
  • Приложение пишет логи в файл внутри контейнера, а не в stdout — тогда docker logs пуст. Приучите сервис писать в stdout/stderr.
  • Нет healthcheck — контейнер «жив», но не отвечает, и вы узнаёте об этом от пользователей.
  • Следите за диском: df -h. Ежедневные бэкапы MAATRIX спасут данные, но переполненный диск всё равно уронит сервис.
']

Нужен сервер под эту задачу?

Разверните VPS MAATRIX за пару минут: NVMe, AMD EPYC, root-доступ, локации UK и США. Оплата картой РФ и по СБП.

Арендовать VPS для Docker

Частые вопросы

Почему docker logs ничего не показывает?

Скорее всего, приложение пишет логи в файл внутри контейнера, а не в stdout/stderr. Docker собирает только стандартные потоки. Настройте вывод приложения в stdout.

Как не дать логам забить диск?

Настройте ротацию в /etc/docker/daemon.json через log-opts max-size и max-file, затем перезапустите демон. Так каждый контейнер ограничен по объёму логов.

Нужен ли Prometheus для маленького VPS?

Не обязательно. Для одного-двух серверов хватит docker stats, healthcheck и лёгкого Dozzle. Тяжёлый стек мониторинга оправдан, когда серверов много.