Skip to main content

Шаг 4 — Сбор и чтение логов

Уровни логов

УровеньЗначениеЧто делать
ERRORПроизошла ошибка, операция не выполненаИскать причину — читать сообщение и контекст вокруг
WARNINGПодозрительное состояние, система продолжает работатьОценить как подозрение — может быть предвестником ошибки
INFOШтатное событие, контекст происходящегоИспользовать как фон для понимания последовательности
DEBUGДетальные данные для диагностикиВключается вручную — даёт максимум деталей

Как читать запись лога

Каждая строка лога имеет структуру:

[container_name] [timestamp] [LEVEL] [message]

Пример:

printum_worker-default | 2024-01-15 10:23:41,012 ERROR [apps.inv.services.sync:302]: Some snmp data missing for printer 1
  • Контейнер — printum_worker-default: в каком компоненте произошло событие
  • Время — 2024-01-15 10:23:41: когда произошло
  • Уровень — ERROR: насколько критично
  • Сообщение — текст с модулем и строкой кода: что произошло

Ключевые сигналы

  • ERROR → ищите причину: читайте строки до и после, проверяйте traceback
  • WARNING → подозрение: само по себе не критично, но указывает направление поиска
  • traceback (Python) → ошибка уровня разработки, передавать в разработку вместе с логами
  • Частота — одна ошибка или тысячи? Массовые ошибки за короткий период говорят об иной природе проблемы
  • Периодичность — ошибка возникает каждые N минут? Скорее всего связана с планировщиком (Celery scheduler)

Режимы логирования

Два типа логов:

  • Логи работы — описывают процессы и операции в системе в реальном времени
  • Логи установки — фиксируют этапы установки и настройки

Два режима:

  • Стандартный — базовые записи (LOG_LEVEL=WARNING по умолчанию)
  • DEBUG — детальные записи для диагностики, включается вручную

Команды сбора логов

Архивный сбор логов (рекомендуется при обращении в поддержку)

Если установлен Мониторинг и ПринтМенеджер, или только Мониторинг:

bash /opt/printum/logs.sh

Если установлен только ПринтМенеджер:

bash /opt/printmanager/logs.sh

Если файл .env зашифрован:

sudo -E ENV_VAULT_PASSWORD=<password> bash /opt/printum/logs.sh

Архив сохраняется в /opt/.../ALL_LOGS/logs-<YYYY-MM-DD-HH-MM-SS>.tar.gz

Просмотр логов в реальном времени

Все контейнеры сразу:

cd /opt/printum
sudo docker-compose logs -f --tail=1

Или для ПМ:

cd /opt/printmanager
sudo docker-compose logs -f --tail=1

Узнать названия контейнеров:

sudo docker-compose ps --services

Логи конкретного контейнера:

sudo docker-compose logs -f converter_server

Включение режима DEBUG

Перейдите в директорию продукта:

cd /opt/printum/
# или
cd /opt/printmanager/

Откройте файл конфигурации:

sudo nano .env

Измените параметры:

DEBUG=True
LOG_LEVEL=DEBUG

Перезапустите контейнеры:

sudo docker-compose down
sudo docker-compose up -d

После сбора логов обязательно верните параметры в исходное состояние (DEBUG=False, LOG_LEVEL=WARNING) и перезапустите контейнеры, чтобы избежать снижения производительности.

Сетевой агент

Текущий лог:

cat /opt/printum-agent/agent.log

Включение DEBUG для агента:

sudo nano /opt/printum-agent/config.env
# Установите: LOG_LEVEL=DEBUG
sudo systemctl restart printum-agent.service

Архивные логи агента:

/opt/printum-agent/agent-<datetime>.log.gz

Локальный агент Linux

sudo journalctl -u printum-jtm.service

Клиент ПМ для Linux

sudo journalctl -u printum-printmanager-client.service

Файлы логов клиента:

/var/log/printum/printmanager_client.log

Клиент ПМ для Windows и локальный агент Windows

Откройте Просмотр событий: Win+R → eventvwr. В левой панели: «Журналы Windows» → «Приложение». Источник для клиента ПМ: Print Manager Client. Источник для локального агента: ServicePrintum.

Связанные страницы

  • Шаг 3 — Карта системы и где искать проблему
  • Паспорт инцидента
  • Основные процессы системы (стр. 219–222)
Back to top