Мониторинг Docker-контейнеров: метрики и логи

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

Короткий ответ

Сначала зафиксируйте исходное состояние, затем проверьте конфигурацию штатным инструментом, примените изменение и подтвердите результат независимой проверкой. Для темы «Мониторинг Docker-контейнеров: метрики и логи» минимальный рабочий набор выглядит так:

docker stats --no-stream
docker ps --format 'table {{.Names}}\t{{.Status}}'
docker inspect --format '{{json .State.Health}}' app

Команды приведены как ориентир: имена интерфейсов, служб, пользователей, доменов и путей замените на значения своей системы. Если работа выполняется удалённо, оставьте открытой текущую административную сессию, пока новый способ доступа не проверен.

Что проверить до начала

• Текущие версии ОС и пакетов, имя узла, время и часовой пояс.
• Достаточный объём диска и памяти, отсутствие уже упавших системных служб.
• Наличие консольного или другого аварийного доступа для сетевых и защитных изменений.
• Точные имена объектов из команд: устройство, service unit, база, сайт, контейнер или домен.
• Ожидаемый результат и простой способ его измерить до и после изменения.

В автоматизированной инфраструктуре важны повторяемость и наблюдаемость. Действие, выполненное вручную один раз, должно быть зафиксировано в конфигурации или playbook, а результат — проверяться машинно. Это снижает расхождения между узлами и превращает восстановление из импровизации в понятную процедуру.

Пошаговая настройка

1. Соберите исходные данные

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

docker stats --no-stream
docker ps --format 'table {{.Names}}\t{{.Status}}'
docker inspect --format '{{json .State.Health}}' app

2. Подготовьте конфигурацию

Используйте отдельный файл конфигурации или drop-in, если инструмент это поддерживает. Такой подход не смешивает локальные изменения с файлом пакета и уменьшает конфликты при обновлении. Права на файл должны соответствовать чувствительности данных: конфигурация с паролем или ключом не должна читаться обычными пользователями.

services:
  app:
    image: example/app:1.4
    logging:
      driver: json-file
      options:
        max-size: "20m"
        max-file: "5"
    deploy:
      resources:
        limits:
          memory: 512M

3. Проверьте синтаксис и примените изменение

До перезапуска найдите команду проверки синтаксиса или режима dry-run. Если она возвращает ошибку, не пытайтесь «продавить» изменение перезагрузкой. Исправьте первую содержательную ошибку, повторите проверку и лишь затем выполняйте reload. Полный restart нужен только там, где reload не перечитывает нужный параметр.

4. Подтвердите результат с точки зрения клиента

Статус «running» говорит только о процессе. Проверяйте реальную функцию: TCP-соединение, HTTP-код, DNS-ответ, вход под нужной учётной записью, чтение из восстановленной базы или запуск контейнера. Желательно выполнить проверку с другого узла и сравнить её с контрольным значением, записанным до работ.

Проверка результата

docker events --since 1h
docker compose logs --since 30m
docker system df
journalctl -u docker --since today

Успешная проверка должна быть воспроизводимой. Сохраните короткий набор команд в журнале эксплуатации или monitoring check. Если система обслуживает пользователей, добавьте проверку прикладного уровня: главной страницы, API health endpoint, тестового запроса к базе либо типовой операции клиента.

Версии образов, модулей и инструментов фиксируйте явно, но планово обновляйте. Неизменяемая версия делает развёртывание воспроизводимым, а регулярное обновление не даёт накапливать уязвимости. Перед production полезны dry-run, тестовое окружение и короткая автоматическая проверка здоровья сервиса.

Типичные ошибки и способы найти причину

• Ошибка: алерт строят только по CPU. Сначала подтвердите состояние диагностической командой и только потом меняйте конфигурацию.
• Ошибка: логи растут без ротации. Сначала подтвердите состояние диагностической командой и только потом меняйте конфигурацию.
• Ошибка: healthcheck проверяет процесс, но не реальную готовность сервиса. Сначала подтвердите состояние диагностической командой и только потом меняйте конфигурацию.

При диагностике не меняйте несколько независимых параметров одновременно. Иначе даже успешный результат не покажет, какое действие помогло. Сопоставляйте время ошибки в клиенте, системном журнале и журнале приложения. Если время отличается, сначала исправьте синхронизацию часов и повторите тест.

Эксплуатация в рабочей среде

После успешного теста документируйте не только итоговый файл, но и причину выбора параметров, способ проверки и процедуру возврата. Добавьте контроль свободного места, срока сертификата, состояния сервиса или результата задания — тот показатель, который раньше всего сообщит о деградации.

Не выводите секреты в командную строку, скриншоты и журналы CI. Для токенов, ключей и паролей используйте защищённый файл, переменную окружения с ограниченным доступом или менеджер секретов. Разделяйте учётные данные тестовой и рабочей среды и планируйте ротацию до инцидента.

Повторите проверку после планового обновления и перезагрузки. Конфигурация, которая работает только до следующего старта, ещё не завершена. Для критичной службы полезны автоматический healthcheck, уведомление об отказе и короткая инструкция дежурному.

Контрольный список

1. Исходное состояние и версии записаны.
2. Демонстрационные адреса и имена заменены.
3. Синтаксис проверен штатной командой.
4. Изменение применено без потери административного доступа.
5. Функция проверена со стороны клиента.
6. Журналы не содержат новых ошибок.
7. Мониторинг и процедура возврата обновлены.

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

Можно ли выполнить настройку сразу на production?

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

Почему команда из инструкции отличается в моей системе?

Пути, названия пакетов и unit-файлов зависят от дистрибутива и версии. Сверьте официальную документацию, вывод справки и фактически установленные пакеты. Не заменяйте различия случайным советом из старого обсуждения.

Как понять, что работа закончена?

Есть четыре признака: синтаксис валиден, сервис выполняет функцию, клиентский тест проходит, а после перезагрузки состояние сохраняется. Для данных дополнительно нужен тест чтения или восстановления, для безопасности — проверка запрещённого сценария.

Официальная документация: первоисточник по теме. Перед применением уточните поведение для своей версии продукта.