Шаг 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» → «Приложение». Источник для клиента ПМ: ПринтМенеджер Client. Источник для локального агента: ServicePrintum.