Шаг 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= 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-.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 . Связанные страницы Шаг 3 — Карта системы и где искать проблему Паспорт инцидента