1. Архитектура и концепции

Архитектура системы, компоненты, конфигурации, сценарии печати

Обзор архитектуры Printum: как читать схему

Зачем инженеру уметь читать архитектурную схему

Инженеру необходимо научиться читать архитектурную схему так, чтобы видеть потоки данных: как задание, атрибуты или событие проходят через компоненты системы.

Понимание потока данных,позволяет:

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

  1. Обзор архитектуры и легенда схемы (эта статья).
  2. Система мониторинга.
  3. ПринтМенеджер в базовой конфигурации: Сингл.
  4. Отказоустойчивость и горизонтальное масштабирование.
  5. Филиальная сеть.

Архитектурная схема Printum

Перед дальнейшим чтением откройте архитектурную схему Printum. В этой статье мы будем ссылаться на её элементы и условные обозначения.

➡ Скачать архитектурную схему Printum

Если абстрагироваться от внутреннего устройства, Printum — комплексное решение из двух веб-приложений и набора вспомогательных программ и сервисов:

Функциональные и нефункциональные требования

Прежде чем разбирать компоненты, полезно разделить требования к системе на два типа — это объясняет, зачем часть архитектуры существует.

Функциональные требования — что система должна делать: печать (прямая и отложенная, с клиентом ПринтМенеджера и без), копирование, сканирование (в почту, в сетевую папку), авторизация пользователя на устройстве, сбор данных о состоянии парка устройств, управление пользователями и правилами.

Нефункциональные требования — какими свойствами система должна обладать при выполнении этих функций: отказоустойчивость (продолжать работать при потере части инфраструктуры), масштабируемость (выдерживать рост числа устройств, пользователей, заданий), производительность, безопасность (не хранить данные в открытом виде, разграничивать доступ и т.п.).

Часть компонентов на схеме существует не ради функций, а ради нефункциональных требований — например, разделение на PostgreSQL и ClickHouse существует ради производительности, а балансировщик HAProxy и Redis Sentinel — ради отказоустойчивости и масштабируемости. Если непонятно, зачем нужен компонент, полезно задать вопрос: он выполняет функцию или обеспечивает нефункциональное требование?

Легенда схемы

Архитектурная схема Printum использует ограниченный набор условных обозначений. Разобравшись с ними один раз, любой блок схемы читается одинаково.

Обозначение Значение
Зелёный цилиндр База данных. Под каждым цилиндром подписан конкретный движок: PostgreSQL, ClickHouse, Redis.
Синий прямоугольник Python-приложение — бэкенд одной из систем (Django, Celery, планировщик).
Синий прямоугольник со скруглёнными краями Обратный прокси / веб-сервер (nginx) или балансировщик (HAProxy). Устанавливает соединения между компонентами, браузером и личным кабинетом.
Пунктирный прямоугольник — архитектурный блок Какие компоненты необходимы для выполнения определённой функции. Отвечает на вопрос «из чего это состоит».
Пунктирный прямоугольник — логический блок Где компоненты физически размещаются в инфраструктуре (на каком сервере, в каком сегменте сети). Отвечает на вопрос «где это стоит».
Прочие значки МФУ, АРМ пользователя, внешние системы (домен, SMTP/IMAP, SIEM) — обозначаются отдельными иконками и подписываются явно.

Различие между архитектурным и логическим блоком важно: один и тот же архитектурный блок (например, «ПринтМенеджер») может быть развёрнут в нескольких логических местах — в филиале А, в филиале Б, — и в каждом из них будет одинаковый набор внутренних компонентов.

Четыре архитектурных блока верхнего уровня

Полная схема Printum состоит из четырёх архитектурных блоков. На практике в конкретном проекте одновременно присутствует блок мониторинга (всегда один) и один или несколько блоков управления печатью — в зависимости от масштаба и требований к отказоустойчивости.

  1. Система мониторинга — единственный экземпляр в инфраструктуре независимо от количества филиалов или ПринтМенеджеров. Подробности — в статье 2.
  2. ПринтМенеджер в базовой конфигурация (Сингл) — типовая установка: один сервер обрабатывает печать/сканирование/копирование для одного офиса или сегмента сети. Подробности — в статье 3.
  3. ПринтМенеджер с горизонтальным масштабированием (Кластер) — несколько ПринтМенеджеров работают как единый кластер через балансировщик HAProxy. Применяется, когда одного сервера не хватает по нагрузке или когда заказчику нужна отказоустойчивость обработки заданий. Подробности — в статье 4.
  4. Филиальная сеть — несколько независимых ПринтМенеджеров в разных географических точках, каждый обслуживает свой филиал и синхронизируется с общим сервером мониторинга. Применяется при значительных сетевых задержках между офисами или в тех случаях, когда простой сервиса печати при обрыве связи с центральным сервером критичен. Подробности — в статье 5.

Блоки 3 и 4 не взаимоисключающие: в одном из филиалов филиальной сети вполне может быть развёрнута схема с балансировкой, если нагрузка именно этого филиала того требует.

Поток данных на верхнем уровне: мысленная модель

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

АРМ пользователя → драйвер виртуального принтера → ПринтМенеджер (обработка атрибутов и образа) → МФУ (авторизация и печать)

Статистика по обработанным заданиям после этого возвращается из ПринтМенеджера в систему мониторинга (по расписанию или мгновенно). Данные же о состоянии самих устройств идут отдельным маршрутом — от МФУ через сетевой агент напрямую в мониторинг, минуя ПринтМенеджер.

Это два разных потока: поток заданий (через ПринтМенеджер) и поток данных о состоянии устройств (через агентов мониторинга). Их не стоит путать при диагностике — если не печатает конкретное задание, проблема всегда в первом потоке; если в личном кабинете не видно актуального состояния принтера (уровень тонера, статус ошибки), проблема — во втором.

Как это связано с диагностикой

Способность назвать компонент по картинке — не цель. Цель — при жалобе «не работает печать» уметь мысленно провести задание по цепочке АРМ → драйвер → ПринтМенеджер → МФУ и определить, на каком звене данные потерялись. Подробно эта методика разобрана в отдельной статье Модель диагностики — она построена именно на знании этой цепочки, которое даёт архитектура.

Как работает RFID-авторизация в Принтум

Описание

Принтум поддерживает авторизацию пользователей через RFID-карты и USB-считыватели. RFID-авторизация используется для:

Поддерживаются:

Как работает авторизация

Шаг 1. Пользователь прикладывает карту Пользователь прикладывает RFID-карту к считывателю. Считыватель: считывает UID карты; преобразует UID в последовательность символов; отправляет данные как HID-клавиатура.

Шаг 2. Считыватель передает UID Большинство считывателей работают как USB HID Keyboard Device. Для операционной системы считыватель выглядит как обычная клавиатура. Пример:

458712991 <ENTER>

Где: 458712991 — UID карты; ENTER — suffix/carriage return.

Шаг 3. Встроенное приложение получает UID Встроенное приложение на МФУ получает UID, отправляет запрос в Принтум и ищет пользователя.

Шаг 4. Принтум выполняет поиск пользователя Принтум ищет: пользователя; связанную карту; разрешения; роли; ограничения.

Шаг 5. Создание пользовательской сессии Если карта найдена: создается сессия; открывается пользовательский интерфейс; становятся доступны задания печати. Что такое HID Keyboard Emulation Большинство RFID-считывателей работают как клавиатура. Это означает: драйверы обычно не требуются; считыватель печатает UID в активное поле ввода;

Принтум получает UID как текст. Это один из самых совместимых способов интеграции. Что такое Prefix и Suffix Считыватель может автоматически добавлять prefix и suffix. Пример:

<prefix> 458712991 <suffix>

Чаще всего используется suffix CR (carriage return). Он автоматически подтверждает ввод карты.

Почему нельзя включать все типы карт

Считыватель может одновременно поддерживать авторизацию по нескольким форматам карт: Mifare, ISO14443A, HID, Legic, NFC и др. Но включение всех типов карт увеличивает время отклика, замедляет авторизацию и может вызывать ложные срабатывания. Считыватель последовательно проверяет каждый включённый тип карт — пока не найдёт совпадение или не пройдёт весь список. Чем больше типов включено — тем дольше цикл опроса на каждое прикладывание карты. При всех включённых типах время считывания может вырасти до 2–3 секунд вместо нормальных 0.3–0.5 секунд. Рекомендуем:

Что такое VID и PID

USB-устройства имеют Vendor ID (VID) и Product ID (PID). Параметры используются для идентификации устройства, настройки Встроенного приложения и фильтрации HID-устройств. После настройки считывателя рекомендуется сохранить VID/PID.

Типовые проблемы

Симптом Возможная причина
Карта не читается Неверный тип карты
Медленная авторизация В настройках считывателя включено слишком много типов карт
UID вводится не полностью Неверный suffix
Считыватель не определяется Проблемы драйвера считывателя на МФУ
Пользователь не авторизуется Карта не привязана к пользователю или не считывается устройством

Что проверить при диагностике

Что важно помнить

Система мониторинга: компоненты и поток данных

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

Роль в системе

Мониторинг — ядро Printum. В отличие от ПринтМенеджера, его задача не обработка заданий, а сбор, обработка и хранение данных: об устройствах печати, о пользователях, статистике, событиях в системе. Мониторинг всегда существует в инфраструктуре в единственном экземпляре, даже если ПринтМенеджеров несколько (см. статьи про балансировку и филиальную сеть).

Логические блоки

Архитектурный блок «Система мониторинга» связан со следующими логическими блоками:

Компоненты сервера мониторинга

Компонент Тип Роль
PostgreSQL БД Структурированные обработанные данные: пользователи, настройки системы, статистика (результат интерпретации “сырых” SNMP-данных).
ClickHouse БД Сырые данные, поступившие от сетевого агента (SNMP-опрос МФУ). Выбран вместо PostgreSQL, потому что может быстро сохранять большие объемы данных.
Redis БД (используется как брокер) Не хранит бизнес-данные — используется как брокер сообщений между Django, Celery и планировщиком, а также используется как кэш данных.
Django Python-приложение Бэкенд: принимает запросы через nginx, формирует ответы для личного кабинета и панели администратора, сетевого и локального агентов, кладёт данные в PostgreSQL/ClickHouse.
Celery Python-приложение (фоновые задачи) Обработка операций, которые занимают от 1 секунды: разбор “сырых” SNMP-данных после опроса, синхронизация с доменом, формирование тяжёлых отчётов.
Планировщик (scheduler) Python-приложение (планировка фоновых задач) Планирует периодические задачи: синхронизация с доменом, опрос устройств, отправка отчётов и уведомлений на почту. В нужный момент кладёт задачу в Redis, а тот передаёт её Celery.
nginx Реверс-прокси Маршрутизирует запросы от браузера и других компонентов, направляет их в Django.

Пример потока данных: опрос МФУ → личный кабинет

Это базовый сценарий, на котором стоит тренироваться читать схему.

  1. Сетевой агент получает две периодические задачи: сканирование сети и опрос принтеров.
  2. Агент отправляет SNMP-запрос МФУ (порт 161/UDP) с запросом на нужные OID.
  3. МФУ отвечает сетевому агенту (порт 162/UDP) значениями запрошенных OID.
  4. Сетевой агент передаёт полученные сырые данные через nginx в Django.
  5. Django видит, что пришли сырые данные, и кладёт их в ClickHouse.
  6. Scheduler по расписанию запускает задачу разбора сырых данных, ставя задачу в Redis. Celery забирает задачу из Redis.
  7. Celery забирает сырые данные из ClickHouse, интерпретирует их и кладёт уже структурированные, готовые к отображению данные в PostgreSQL.
  8. Пользователь через браузер запрашивает страницу устройств.
  9. Запрос проходит через nginx в Django; Django идёт в PostgreSQL за данными.
  10. Django готовит ответ, nginx собирает его вместе с шаблоном личного кабинета и отдаёт в браузер.

Если что-то в отчёте выглядит неактуальным или неполным — эта цепочка подсказывает, где искать: не дошли ли сырые данные до ClickHouse, выполнилась ли задача Celery, попали ли обработанные данные в PostgreSQL, или проблема на уровне отображения (nginx/Django).

Локальный агент мониторинга (данные с АРМ)

Отдельный поток — сбор статистики о заданиях печати, отправленных с АРМ на локальный (не сетевой) принтер:

  1. Локальный агент на АРМ фиксирует данные о задании.
  2. Агент отправляет накопленные данные через nginx в Django.
  3. Django обрабатывает данные и кладёт их в PostgreSQL.
  4. Администратор через личный кабинет запрашивает эти данные обратно тем же путём, что и в примере выше.

Внешние системы

Синхронизация с ПринтМенеджером

ПринтМенеджер и мониторинг обмениваются данными в обе стороны.

Каждая из систем выступает инициатором соединения для получения данных, которые нужны именно ей:

ПринтМенеджер: базовая конфигурация - Сингл

Назначение

Эта статья разбирает архитектуру обработки заданий печати, копирования и сканирования.

Роль в системе

ПринтМенеджер нужен для обработки заданий печати, сканирования и копирования, а также для авторизации пользователя на устройстве.

Логические блоки

Общие компоненты (как в мониторинге)

Компоненты, специфичные для ПринтМенеджера

Компонент Роль
Сервер печати CUPS Обрабатывает очереди печати, работает с драйверами принтеров, отправляет задания на физическое устройство.
Файловый сервер CUPS Позволяет эффективно скачивать задания из CUPS.
Локальное хранилище образов документов Директория на диске сервера ПринтМенеджера. Хранит образы документов (PDF/PostScript). В базе данных не рекомендуется хранить документы, поэтому для них выделено отдельное хранилище, а в PostgreSQL хранятся только метаданные (ссылка на задание, атрибуты задания: дуплекс, цветность и т.д.), а образ лежит в хранилище.
Временное объектное хранилище Транзитная зона для МФУ, которые не умеют отправлять данные напрямую в систему и работают только через FTP/SMB/сетевые папки. Celery забирает образ оттуда и передаёт дальше по цепочке в постоянное хранилище.
Конвертер- сервер Нужен для МФУ, которые не поддерживают встроенное приложение и используют внешнее устройство авторизации (например, кардридер). Конвертер формирует авторизационные данные и приводит их к формату, понятному Django.

Сценарий 1: печать через Клиент ПМ

На АРМ пользователя установлен Клиент ПМ — компонент, работающий с очередью печати рабочей станции, управляющий принтерами на АРМ и отвечающий за применение экономии тонера. Путь задания при печати через клиента ПМ:

  1. Пользователь отправляет документ на печать. Задание попадает в локальную очередь печати рабочей станции.
  2. Клиент ПМ забирает задание из локальной очереди, конвертирует его в PDF — основной формат для дальнейшей обработки в Printum — и извлекает атрибуты (формат, дуплекс, количество страниц, цветность, ориентация, разбор по копиям).
  3. Клиент ПМ добавляет задание в серверную очередь печати ПринтМенеджера. На сервере Django создаёт внутреннее задание и кладёт метаданные в PostgreSQL; ПринтМенеджер проверяет и применяет к заданию правила печати.
  4. Клиент ПМ запрашивает у ПринтМенеджера настройки оптимизации печати (например, параметры экономии тонера), применяет их и отправляет обработанный образ документа на сервер в локальное хранилище образов.
  5. Дальнейший путь зависит от типа печати:
    • Прямая печать — задание уходит в сервер печати CUPS, CUPS отправляет его на МФУ.
    • Отложенная печать — задание остаётся в очереди ПринтМенеджера. Пользователь авторизуется во встроенном приложении на МФУ (PIN-код или карта), приложение запрашивает список заданий; после выбора пользователем и нажатия «Печать» задание уходит в CUPS, CUPS — на МФУ.
  6. После отправки на печать ПринтМенеджер переводит задание в архив, обновляет статистику, которая потом подгружается мониторингом.

Сценарий 2: бесклиентская печать

Настраивается через виртуальный принтер со ссылкой напрямую на CUPS ПринтМенеджера, без установки Клиента ПМ на АРМ. К виртуальному принтеру подключается один из универсальных PostScript-драйверов: Xerox Global Print Driver PostScript, Konica Minolta Universal PS, HP Universal Printing PS.

Путь задания при печати без клиента ПМ:

  1. Универсальный драйвер формирует PostScript-задание и отправляет его напрямую в CUPS ПринтМенеджера, минуя Django на этом шаге.
  2. Django периодически опрашивает CUPS; обнаружив новое задание, создаёт собственное внутреннее задание и заполняет его атрибутами, разобрав пришедший PostScript-файл.
  3. Дальнейшая обработка зависит от настройки USE_PS_PRINTING: если она выключена — задание конвертируется в PDF; если включена, но для задания действуют правила по количеству страниц, цветности или автоудалению после печати — задание всё равно конвертируется в PDF; если таких правил нет — конвертация не выполняется, и задание остаётся в PostScript.
  4. ПринтМенеджер применяет правила печати к заданию; метаданные сохраняются в PostgreSQL, образ — в хранилище образов (локальное или внешнее).
  5. Исходное PostScript-задание удаляется из CUPS — дальше система работает только со своей внутренней копией задания.
  6. Дальнейший путь зависит от типа печати:
    • Прямая печать — сформированное задание отправляется в CUPS, CUPS передаёт его на МФУ.
    • Отложенная печать — задание остаётся в очереди ПринтМенеджера до авторизации пользователя во встроенном приложении на МФУ, дальше — как в сценарии с Клиентом ПМ.
  7. После печати — архивирование задания, обновление статистики и синхронизация с мониторингом как обычно.

Печать через почту (IMAP)

Помимо клиентской/бесклиентской печати с АРМ, есть сценарий отправки задания на специальный почтовый ящик. Периодическая задача Celery проверяет этот ящик по протоколу IMAP; обнаружив новое письмо с вложением, система забирает его и обрабатывает как обычное задание печати — метаданные в PostgreSQL, образ в локальное хранилище, дальнейшая авторизация и печать не отличаются от прочих сценариев.

Прочие внешние компоненты базовой конфигурации

Важно: ПринтМенеджеров может быть несколько

Базовая конфигурация (Сингл) — это один сервер. Если в инфраструктуре несколько ПринтМенеджеров, это происходит по одной из двух причин: нужна отказоустойчивость/производительность или несколько географически разнесённых филиалов.

Связанные статьи

Ролевая модель и управление ролями пользователей

Назначение

Ролевая модель определяет, какие функции системы доступны пользователю и с какими объектами он может работать.

В Printum роль задает не только набор доступных функций, но и уровень доступа к данным пользователей, локациям и административным разделам системы.

Базовые роли и их функции

При установке системы создаются базовые роли с разным набором функций.

Роль «Пользователь» назначается всем пользователям по умолчанию при импорте из домена и имеет минимально необходимый доступ в Личный кабинет.

В таблице ниже указаны функции ролевой модели и наличие\отсутствие доступов к ним у ролей по умолчанию, где:

Функции / Роли Пользователь Оператор Инженер Администратор Сотрудник СБ
Просмотр и редактирование профиля + + + + +
Доступ к странице Устройства - + + + -
Изменение и сохранение отчетов в ЛК - + + + -
Доступ к странице Склад - + + + -
Доступ к странице Журнал - + + + -
Доступ к странице Задания + + + + +
Доступ к архиву на странице "Задания" - - - - +
Доступ к странице Журнал ИБ - - - - +
Управление импортом экспортом справочников - - + + -
Ручная фиксация замен - - + + -
Доступ к системным настройкам Мониторинга - - - + -
Управление локациями - - - + -
Управление настройками почты в Мониторинге - - - + -
Управление сетевыми агентами мониторинга - - - + -
Управление локальными агентами мониторинга - - - + -
Управление системными настройками ПМ - - - + -
Управление импортом пользователей - - - + -
Управление принтерами - - - + -
Управление интеграциями - - - + -
Управление правилами печати - - - + -
Управление группами принтеров в ПМ - - - + -
Управление пользователями - - - + -
Управление запчастями и параметрами - - + + -

Как назначить роль пользователю

  1. В панели администратора Мониторинга перейдите в раздел Настройка → Пользователи.
  2. Раскройте карточку настроек нужного пользователя.
  3. Найдите параметр «Роли пользователей:» и выберите роль из списка.
  4. Сохраните настройки.

После сохранения пользователю перейдут все права новой роли.

Собственные роли

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

  1. В панели администратора Мониторинга перейдите в раздел Настройка → Роли пользователей.
  2. Нажмите Добавить роль пользователя.
  3. При необходимости назначьте Ролью по умолчанию (роль будет присваиваться всем новым пользователям).
  4. Укажите нужные настройки и нажмите «Сохранить».

Модель диагностики Принтум

Описание

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

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

Четыре шага модели

Шаг Вопрос Результат
Шаг 1. Локализация Система или инфраструктура? Понимаем, стоит ли вообще смотреть в Printum
Шаг 2. Сценарий и условия Что именно происходит, у кого, при каких условиях? Паспорт инцидента: сценарий, масштаб, воспроизводимость
Шаг 3. Карта системы Какие компоненты участвуют в этом сценарии? Конкретный контейнер или служба, которую нужно проверить
Шаг 4. Логи Что написано в логах целевого компонента? Причина проблемы или следующая гипотеза

Почему именно в таком порядке

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

Если инженер умеет читать поток данных, он сможет диагностировать систему в любом проекте — в самом лёгком и в самом сложном.

Шаг 1 — Локализация

Цель шага

Понять: проблема находится внутри системы Printum или вне её — в инфраструктуре, сети, настройке принтера, драйвере.

Если проблема вне системы — дальнейшая диагностика Printum не нужна.

Методы проверки

1. Печать в обход системы

Отправьте задание печати напрямую на принтер, минуя Printum: установите принтер как обычный сетевой принтер Windows/Linux и распечатайте тестовую страницу.

2. Другой принтер

Воспроизведите то же действие на другом устройстве того же типа или в другом подразделении.

3. Другой пользователь

Попросите другого сотрудника воспроизвести проблему под своей учётной записью.

4. Сетевая доступность

Выполните опрос устройства по порту для печати, чтобы проверить доступность и ответ принтера.

# Для socket
telnet <IP_принтера> 9100
# Для ipp
telnet <IP_принтера> 80
# Для ipps
telnet <IP_принтера> 443

CUPS системы ПринтМенеджера устанавливает соединение с устройством по стандартным протоколам печати. Если устройство недоступно, то и печать не будет выполнена.

Результат шага

После проверки становится ясно:

Шаг 2 — Сценарий и условия

Цель шага

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

Сценарий

Определите, какой именно процесс не работает, например:

Категория Варианты
Печать прямая / отложенная; с клиентом ПринтМенеджер / без клиента (бесклиентская)
Авторизация PIN / карта / внешняя авторизация
Отчёты веб / файл (Excel) / почта
Синхронизация ручная / по расписанию (домен, М→ПМ)
Сканирование / Копирование через встроенное приложение
Копирование с сохранением образа / без сохранения образа
Мониторинг принтеров поиск устройств / опрос устройств

Сценарий определяет, какие компоненты участвуют в процессе и где искать разрыв.

Условия

Зафиксируйте технические характеристики окружения, например:

Масштаб

Сколько объектов затронуто — это ключ к поиску общего знаменателя, например.

Объект Варианты Что искать при группе
Устройства одно / группа / все локация, вендор, модель, подсеть
Пользователи один / группа / все подразделение, OU, тип авторизации, роль
Документы один / группа / все формат, размер, программа-источник

Если проблема у группы — ищите что объединяет эту группу: одна локация, один вендор устройств, одна OU в домене.

Воспроизводимость

Результат шага

Заполненный паспорт инцидента с описанием сценария, условий, масштаба и воспроизводимости. На основе этих данных строим карту системы.

Шаг 3 — Карта системы

Ключевая мысль

Проблема всегда находится в конкретном звене цепочки. После локализации и заполнения паспорта инцидента — определите цепочку компонентов для своего сценария, выберите предполагаемое звено и смотрите соответствующие логи.

Если инженер умеет читать поток данных, он сможет понять, где именно у нас в этом месте в потоке данных сломалась передача.

Для ориентирования в компонентах и процессах обработки данных опирайтесь на карту системы Printum.

Пример 1: Задание не печатается

Элемент Описание
Сценарий Прямая или отложенная печать с клиентом ПринтМенеджер
Цепочка компонентов АРМ → Клиент ПМ → Nginx (порт 8080) → Django (printmanager-app) → CUPS (printmanager-cups) → МФУ (порт 631)
Где искать Проверьте: дошло ли задание до сервера ПМ; принял ли его CUPS; передал ли CUPS на МФУ
Какие логи printmanager-app , printmanager-cups , printmanager-celery-print-queue

Пример 2: Нет данных по принтеру (не отображается в системе)

Элемент Описание
Сценарий Мониторинг — устройство не появляется в личном кабинете
Цепочка компонентов МФУ → Сетевой агент (SNMP, порты 161/162) → Nginx → Django → ClickHouse → Celery (printum_worker) → PostgreSQL → Личный кабинет
Где искать 1) Устройство отвечает по SNMP? (snmpwalk) 2) Агент передал данные на сервер? 3) Данные попали в ClickHouse? 4) Celery обработал и записал в PostgreSQL?

Пример 3: Пользователь не авторизуется

Элемент Описание
Сценарий Авторизация на МФУ по карте или PIN через встроенное приложение
Цепочка компонентов (карта) Карта → Картридер → Django (printmanager-app) → PostgreSQL (поиск пользователя)
Цепочка компонентов (PIN / внешняя) МФУ → Встроенное приложение → Nginx → Django (printmanager-app) → PostgreSQL
Где искать Пользователь существует в системе? Карта сопоставлена? Данные синхронизированы из домена?
Какие логи printmanager-app , printmanager-converter-server

Как читать цепочку

Каждая стрелочка — это передача данных. Если пользователь не видит результат, значит разрыв произошёл где-то между звеньями в цепочке. Метод диагностики: двигайтесь по цепочке от начала до конца (или в обратном порядке) и проверяйте каждое звено по его логам.

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

Модель пользователей в Принтум

Назначение

Printum использует собственную модель пользователей, которая позволяет применять роли, квоты, правила печати и собирать статистику независимо от количества доменных учётных записей сотрудника.

Пользователь Printum и доменная учётная запись

Пользователь в Printum (Printum ID) и доменная учётная запись — разные сущности.

Доменная учётная запись существует в Active Directory или другом LDAP-каталоге и используется для аутентификации пользователя.

Printum импортирует доменные учётные записи и создает на их основе пользователей системы.

Один человек — один Printum ID

Printum рассматривает пользователя как реального человека, а не как логин в домене.

Поэтому один пользователь может иметь несколько доменных учётных записей, связанных с одним Printum ID. Такой сценарий часто используется в организациях с несколькими доменами или контурами безопасности.

Правила и квоты назначаются пользователю

Роли, квоты, ограничения и правила печати назначаются пользователю Printum, а не отдельной доменной учётной записи.

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

Жизненный цикл пользователя

  1. Пользователь создаётся в службе каталогов организации.
  2. Во время синхронизации Printum импортирует доменную учётную запись и её атрибуты.
  3. В системе создаётся новый пользователь Printum или обновляется существующий.
  4. Пользователю назначаются роли, правила и квоты.
  5. Пользователь начинает работать с системой.

Пользователи могут создаваться автоматически при синхронизации с доменом или вручную.

Поддерживаемые сценарии печати

Назначение

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

Прямая и отложенная печать

Прямая печать

При прямой печати задание отправляется на выбранное устройство сразу после обработки системой. Дополнительное подтверждение пользователя не требуется.

Пользователю может быть доступно несколько устройств прямой печати, между которыми он выбирает при отправке документа.

Отложенная печать

При отложенной печати задание помещается в персональную очередь пользователя и печатается только после авторизации на устройстве. Для авторизации может использоваться карта доступа или PIN-код.

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

Совместное использование

Один и тот же пользователь может одновременно использовать оба сценария.

Например:

Подробности работы отложенной печати описаны в статье «Как работает отложенная печать».

Печать через Клиент ПМ и бесклиентская печать

Печать через Клиент ПМ

На рабочей станции пользователя устанавливается Клиент ПМ.

Клиент ПМ:

Когда использовать

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

Подробности описаны в статье «Путь задания при печати через Клиент ПМ».

Бесклиентская печать

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

Когда использовать

Данный сценарий подходит для:

Подробности описаны в статье «Путь задания при бесклиентской печати».

Печать через почту и гостевая печать

Печать через почту

Пользователь может отправить письмо с вложением на специальный почтовый адрес, настроенный в системе. После обработки письма вложение добавляется в очередь печати пользователя.

Когда использовать

Подходит для мобильной печати и печати без подключения к корпоративной сети.

Гостевая печать

Гостевая печать позволяет печатать пользователям, отсутствующим в домене или базе пользователей организации.

После получения письма система:

После авторизации на устройстве пользователь получает доступ к своим заданиям и может их распечатать.

Подробности описаны в статье «Как работает гостевая печать через Email».

Форматы заданий печати

PDF

PDF является основным форматом печатных заданий в Printum.

Этот режим используется по умолчанию и обеспечивает корректную работу всех функций системы:

PostScript

Для отдельных сценариев система может использовать формат PostScript (PS).

Использование PostScript позволяет снизить нагрузку на сервер и ускорить обработку заданий печати.

Выбор сценария печати

Сценарии могут использоваться одновременно в рамках одной инфраструктуры.

Например:

Выбор конкретного сценария зависит от требований к безопасности, удобству эксплуатации и особенностей инфраструктуры организации.

Связанные статьи

Путь задания при бесклиентской печати

Описание

Бесклиентская печать используется, когда на рабочую станцию пользователя нельзя установить клиент ПМ, например, по причине политики запрета ИБ об установке стороннего ПО. Пользователь печатает на через драйвер виртуального принтера, настроенного на сервер ПринтМенеджера. Универсальный драйвер формирует PostScript-задание и отправляет его в CUPS ПринтМенеджера. Дальше задание обрабатывается ПринтМенеджером.

Поддерживаемые универсальные драйверы

Участники процесса

Компонент Действия
Приложение пользователя Создаёт задание печати.
Универсальный драйвер Формирует PostScript-задание.
CUPS ПринтМенеджера Принимает задание с рабочей станции.
ПринтМенеджер Создаёт внутреннее задание, парсит атрибуты, применяет правила печати.
Встроенное приложение Используется для печати заданий на МФУ.
МФУ Печатает документ

Пошаговый путь задания

Особенности PostScript-режима

PostScript может ускорить обработку задания, но имеет ограничения. Если в системе используются правила по количеству страниц, цветности или автоматическому удалению после печати, ПринтМенеджер конвертирует задание в PDF даже при включённом USE_PS_PRINTING .

Локализация причины проблемы

Симптом Возможная область для диагностики
Задание не попало в ПринтМенеджер Драйвер виртуального принтера на АРМ пользователя, CUPS ПринтМенеджера.
Задание появилось, но не печатается ПринтМенеджер, CUPS, протокол подключения принтера в CUPS, драйвер устройства.
Правила печати с условиями по страницам/цветности не работают Формат задания и настройка USE_PS_PRINTING.
Пользователь не видит задание на МФУ Очередь пользователя в ПринтМенеджере, встроенное приложение.

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

Как работает синхронизация пользователей с доменом

Назначение

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

Как происходит синхронизация

Синхронизация выполняется в два этапа:

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

Схема движения данных: AD/LDAP → Мониторинг → ПринтМенеджер

Поддерживаемые службы каталогов

Printum поддерживает синхронизацию с:

Выгружаемые атрибуты

Во время синхронизации из службы каталогов импортируется набор атрибутов пользователя, например:

Перечень поддерживаемых атрибутов фиксирован.

Доменный пароль не импортируется и не хранится в Printum.

Настройка соответствия атрибутов

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

Принцип настройки аналогичен определению параметров устройств в модуле Мониторинг: каждому параметру системы сопоставляется источник данных во внешней системе.

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

Организационная структура и группы

При настройке синхронизации можно импортировать:

В большинстве инфраструктур подразделения представлены в виде OU, а группы используются для управления доступами.

Однако встречаются организации, где подразделения реализованы через группы безопасности. Printum поддерживает оба подхода.

Фильтрация пользователей

Необязательно импортировать всех пользователей службы каталогов.

С помощью стандартных LDAP-фильтров можно ограничить синхронизацию, например:

Это удобно при выполнении пилотных проектов и поэтапном внедрении системы.

Расписание синхронизации

Синхронизация выполняется автоматически по расписанию.

Минимальный интервал между синхронизациями составляет 4 часа. Для большинства внедрений нескольких синхронизаций в сутки достаточно для поддержания данных в актуальном состоянии.

Отказоустойчивость и горизонтальное масштабирование ПринтМенеджера

Назначение

Эта статья разбирает отказоустойчивую и масштабируемую архитектуру обработки заданий печати, копирования и сканирования.

Когда нужна эта схема

Базовой конфигурации из одного ПринтМенеджера достаточно, пока хватает производительности одного сервера и нет требований по отказоустойчивости. Горизонтальное масштабирование и балансировка нагрузки решают задачи:

Расположение компонентов

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

Что меняется относительно базовой конфигурации

Компонент базовой конфигурации Что происходит в кластере
Nginx как точка входа Точкой входа становится балансировщик HAProxy. Это реверс-прокси, но умеющий распределять запросы между несколькими активными ПринтМенеджерами по определенным правилам. Сам nginx не пропадает, но перестает быть точкой входа.
Redis (брокер) Улучшается до master-slave кластера с поддержкой Redis Sentinel, который обеспечивает отказоустойчивость кластера Redis.
PostgreSQL Становится общей базой данных на весь кластер — логически один компонент, к которому обращаются все узлы. Внутри эта база данных должна быть физически или логически реплицирована.
Локальное хранилище образов документов CUPS Меняется на общее NFS-хранилище — папка которая доступна на чтение и запись каждому приложению, т.е. задание может быть создано на одном узле, а прочитано на другом. По одному CUPS на каждый из узлов, каждый из CUPS содержит одинаковое количество принтеров. Поскольку CUPS становится больше, то нагрузка на каждый из них становится меньше, а значит возможна печать большего количества документов одновременно без перегрузки.
Celery (один экземпляр) По одному Celery на каждом узле — обрабатывают различные задачи; именно это даёт прирост производительности.
Django По одному Django на каждом узле. Поскольку Django становится больше, они независимо обрабатывают разные запросы извне
Планировщик Становится распределённым: экземпляр существует на каждом узле, но согласовывает запуск периодических задач через Redis Sentinel, чтобы одна и та же задача не запускалась одновременно на всех узлах.
Конвертер-сервер Не меняет своих функций, но иным способом обрабатывает TCP запросы полученные от сокета HAProxy, чтобы правильно определять адрес физического ковертера.

Несмотря на появление HAProxy, Redis Sentinel и общего NFS-хранилища, архитектура обработки самого задания принципиально не меняется. Все изменения направлены на одно: чтобы несколько экземпляров ПринтМенеджера могли совместно обрабатывать задания, используя общие данные и не мешая друг другу.

Как обрабатывается запрос

В базовой конфигурации клиент отправляет запрос напрямую на единственный сервер: nginx → Django → Celery → CUPS.

В кластере тот же путь проходит через дополнительную точку координации:

  1. Клиент отправляет запрос не на конкретный сервер, а на балансировщик.
  2. Балансировщик направляет его на один из активных узлов.
  3. На выбранном узле запрос обрабатывается как обычно: nginx → Django.
  4. Django передаёт задачу через Redis — кластер координирует, чтобы её взял в работу ровно один свободный Celery, независимо от того, на каком узле он находится.
  5. Метаданные задания кладутся в общую PostgreSQL, образ документа — в общее NFS-хранилище.
  6. Печать выполняет тот узел, куда Celery отправитзадачу.

Поскольку Celery и Django на каждом узле работает независимо и асинхронно друг относительно друга, то с ростом числа узлов растёт и пропускная способность по заданиям — это и есть причина увеличивать число узлов ради производительности, отдельно от вопроса отказоустойчивости.

Принцип отказоустойчивости

Основа отказоустойчивости – это возможности системы перераспредлять запросы и задачи с узлов, которые отказали, на работающие узлы.

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

Redis Sentinel кластеру для работы необходим кворум — большинство узлов Redis должно оставаться активным: активных узлов должно быть строго больше, чем неактивных. Если это условие нарушается, Redis Sentinel не могут договориться, кто из оставшихся узлов должен взять на себя роль мастера, и кластер теряет работоспособность целиком.

Узлов в кластере Можно потерять одновременно
3 1
5 2
7 3

Классический пример — 3 узла (1 мастер + 2 слейва): такая конфигурация переживает потерю любого одного узла, но не двух сразу.

Объединение доменных учётных записей одного пользователя

Назначение

Printum позволяет связывать несколько доменных учётных записей с одним пользователем системы (Printum ID). Это необходимо для организаций, где один сотрудник работает в нескольких доменах или контурах безопасности.

Как это работает

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

Если у нескольких доменных учётных записей совпадает значение выбранного атрибута, Printum рассматривает их как одного пользователя и связывает с одним Printum ID.

В качестве атрибута объединения обычно используются:

Для каждой интеграции с доменом атрибут объединения настраивается отдельно.

При этом сами доменные учётные записи остаются независимыми — объединяется только представление пользователя внутри Printum.

Приоритет доменов

После объединения Printum должен определить, из какого домена использовать основные сведения о пользователе (например, ФИО, адрес электронной почты или подразделение).

Для этого каждой интеграции с доменом назначается порядковый номер. Чем меньше номер, тем выше приоритет домена.

Если сведения о пользователе отличаются в разных доменах, Printum использует данные из домена с наивысшим приоритетом.

При изменении приоритетов доменов источником основных данных автоматически становится домен с новым минимальным порядковым номером.

Пример

Сотрудник имеет две доменные учётные записи:

Домен A

Домен B

Поскольку табельные номера совпадают, Printum объединит обе учётные записи в одного пользователя.

Основными будут считаться данные из домена A, так как он имеет более высокий приоритет.

Что это дает

После объединения:

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

Филиальная сеть

Когда нужна эта схема

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

Решение — развернуть в филиале со значительной сетевой задержкой свой собственный ПринтМенеджер (в базовой конфигурации или со схемой балансировк, в зависимости от ожидаемой нагрузки).

Архитектура

Архитектура

Таким образом, филиальная сеть не создаёт новых типов компонентов — она размножает уже знакомый архитектурный блок «ПринтМенеджер» по числу филиалов и оставляет мониторинг центральной точкой сбора статистики и распространения данных о пользователях и устройствах.

Устойчивость к обрыву связи

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

Если канал связи между филиалом и сервером мониторинга падает:

  1. ПринтМенеджер продолжает обрабатывать задания локально и накапливает статистику у себя — печать, копирование и сканирование не останавливаются.
  2. Он также продолжает работать с той версией данных о пользователях и устройствах, которая была получена из мониторинга до разрыва связи: новые сотрудники, изменения в домене или в парке устройств не попадут в филиал, пока связь не восстановится.
  3. После восстановления связи обмен происходит в обе стороны: накопленная статистика уходит в мониторинг, актуальные данные о пользователях и устройствах приходят обратно в ПринтМенеджер.
  4. Ни одно задание и ни одна запись статистики не теряются из-за временной недоступности сети — теряется только оперативность обмена данными в обе стороны, а не сами данные.

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

Комбинация с балансировкой нагрузки

Филиальная сеть и горизонтальное масштабирование — независимые архитектурные решения, которые можно комбинировать. Если один из филиалов сам по себе достаточно велик (много устройств, высокая нагрузка на печать) или требует отказоустойчивости, именно в этом филиале можно развернуть не единственный ПринтМенеджер в базовой конфигурации, а кластер, разобранный в предыдущей статье. Для остальных, менее нагруженных филиалов, при этом можно оставить базовую конфигурацию из одного сервера.

Связанные статьи

Управление доступом к функциям через группы домена

Назначение

Printum позволяет автоматически назначать пользователям роли, правила печати, доступ к функциям системы и МФУ для прямой печати на основе членства в группах домена. Благодаря этому администратор управляет доступом к печати так же, как и доступом к другим корпоративным ресурсам — через контроллер домена.

Как это работает

Во время синхронизации Printum импортирует не только пользователей, но и организационную структуру (OU) и группы безопасности.

Для каждой группы можно настроить параметры, которые должны автоматически применяться ко всем ее участникам.

После очередной синхронизации изменения, выполненные в контроллере домена, автоматически применяются в Printum.

Назначение ролей

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

Например, если в домене существует группа «Администраторы», ей можно сопоставить роль «Администратор» в Printum.

При добавлении нового сотрудника в эту группу он автоматически получит соответствующую роль после очередной синхронизации. Дополнительная настройка в Printum не потребуется.

Назначение правил

Аналогичным образом через группы можно автоматически применять правила печати.

Например:

Чтобы изменить права пользователя, администратору достаточно добавить или удалить его из соответствующей группы в контроллере домена.

Назначение МФУ для прямой печати

Если используется схема с Клиентом ПМ, через группы или подразделения можно автоматически назначать пользователям МФУ для прямой печати.

Например, при добавлении нового сотрудника в подразделение «Бухгалтерия» на его рабочей станции автоматически появится принтер, предназначенный для прямой печати сотрудников этого отдела.

Управление доступом к функциями МФУ

Тот же механизм может использоваться и для управления функциями МФУ.

Принадлежность пользователя к определенной группе может автоматически предоставить или ограничить доступ к отдельным функциям МФУ: авторизации, печати, копированию, сканированию в почту или сканированию в сетевую папку.

Преимущества такого подхода

Администратору не требуется выполнять одинаковые настройки одновременно в контроллере домена и в Printum.

Все изменения выполняются в привычном инструменте управления пользователями, а Printum автоматически применяет их при синхронизации.

Это упрощает сопровождение системы, снижает вероятность ошибок и делает управление доступом единообразным для всех корпоративных сервисов.

Развитие интеграции

Printum продолжает развивать интеграцию с системами управления инфраструктурой. Одно из направлений — перенос части функций администрирования непосредственно в контроллер домена.

Это позволит управлять отдельными возможностями Printum из привычного интерфейса администратора, сохраняя единый процесс управления пользователями и доступами.

Подробнее: Printum и «Ред АДМ» создают единый контур управления безопасной печатью

Как Printum получает данные об устройствах

Назначение

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

Получение данных

После обнаружения устройства система начинает его регулярный опрос по протоколу SNMP.

В ответ устройство возвращает набор параметров, каждый из которых представляет собой пару OID (Object Identifier) → значение. Например, различные OID могут содержать модель устройства, серийный номер, счетчики отпечатков, состояние расходных материалов, сообщения об ошибках и другие сведения.

На этом этапе система еще не знает, какие из полученных значений соответствуют тем или иным параметрам устройства. Полученные данные представляют собой набор необработанных SNMP-параметров (сырых данных) и сохраняются в базе данных ClickHouse.

Определение параметров мониторинга

Для преобразования сырых SNMP-данных в понятные параметры Printum использует настройки определения параметров. Для каждого параметра (например, модели устройства, серийного номера или общего счетчика отпечатков) в настройках указывается, из какого OID необходимо получить его значение.

Настройки могут быть заданы на трех уровнях:

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

Результат обработки

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

Именно эти параметры используются системой для отображения информации в личном кабинете, формирования событий и построения отчетов.

Как Printum определяет состояние деталей устройства

Назначение

Статья описывает, каким образом Printum определяет состояние расходных материалов и ресурсных деталей устройства, в том числе в случаях, когда устройство не передает эту информацию по SNMP.

Определение состояния деталей

Большинство систем мониторинга отображает только те сведения о расходных материалах и деталях, которые устройство передает по протоколу SNMP.

Printum использует комбинированный подход. Система анализирует данные, полученные от устройства, и дополняет их сведениями из собственной базы данных.

Благодаря этому Printum может отображать состояние не только расходных материалов, а всех ресурсных деталей устройства, даже если само устройство не предоставляет информацию об их оставшемся ресурсе.

Источники данных

Для определения состояния деталей Printum использует два источника информации:

Если устройство передает информацию о детали и ее ресурсе, эти данные имеют приоритет.

Если устройство не предоставляет такую информацию, Printum определяет деталь по модели устройства и рассчитывает ее состояние на основе данных справочника и счетчиков устройства.

Альтернативные детали

Для одной модели устройства могут существовать несколько вариантов одной и той же детали. Например, стартовый, стандартный или картридж повышенной емкости.

Такие варианты называются альтернативными деталями.

Printum определяет, какая из альтернативных деталей установлена в устройстве, и отображает только ее.

Синонимы

Не все устройства передают артикул установленной детали.

В некоторых случаях устройство сообщает только ее название, например Toner, Waste Toner Box, Fuser или Roller.

Для сопоставления таких названий со справочником используются синонимы. Они позволяют сопоставить данные по ресурсу деталей, полученные по SNMP, с перечнем запчастей в базе.

Если деталь отсутствует в базе

Если для обнаруженной детали отсутствует информация в базе Printum, система отображает сведения, полученные непосредственно от устройства.

Такая деталь отображается с типом «Другое».

После добавления информации в базу Printum автоматически начинает использовать ее.

Как Printum рассчитывает ресурс деталей

Назначение

Статья описывает, каким образом Printum определяет оставшийся ресурс расходных материалов и ресурсных деталей устройства.

Источник данных о ресурсе

Все современные устройства передают по SNMP информацию об оставшемся ресурсе расходных материалов (например, картриджей).

Информация о ресурсных деталях зависит от модели устройства. Чем шире возможности устройства, тем больше сведений о состоянии деталей оно передает.

Если устройство предоставляет информацию об оставшемся ресурсе детали, Printum использует именно эти данные.

Если такие данные отсутствуют, система рассчитывает ресурс самостоятельно.

Как выполняется расчет

Для каждой детали в базе Printum хранится:

Для разных деталей могут использоваться разные счетчики. Например:

Во время работы Printum анализирует показания соответствующего счетчика и рассчитывает оставшийся ресурс детали.

Первый расчет после подключения устройства

При первом подключении устройства Printum не знает историю замены деталей.

Поэтому система делает единственно возможное предположение: все детали ранее заменялись после полного исчерпания их максимального ресурса.

Например, если ресурс детали составляет 100 000 отпечатков, а общий счетчик устройства равен 358 000, система предполагает, что деталь заменялась при достижении 100 000, 200 000 и 300 000 отпечатков.

В этом случае текущий ресурс детали будет рассчитан как 42%.

После регистрации замены

После регистрации замены детали Printum запоминает текущее значение счетчика устройства.

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

Это позволяет получать более точную оценку состояния деталей по мере эксплуатации системы.

Как взаимодействуют Мониторинг и ПринтМенеджер

Назначение

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

Роли компонентов

Мониторинг является центральным компонентом системы и основным источником данных для ПринтМенеджера.

Именно в Мониторинге хранятся сведения об устройствах, пользователях, организационной структуре и других объектах системы.

ПринтМенеджер использует эти данные для управления печатью и передает обратно информацию о выполненных заданиях.

Какие данные передаются

Во время синхронизации Мониторинг передает в ПринтМенеджер:

При этом пользователи передаются автоматически, а список устройств определяется настройками синхронизации.

В обратном направлении ПринтМенеджер передает в Мониторинг:

Схема движения данных

Мониторинг → ПринтМенеджер: пользователи, устройства, атрибуты пользователей

ПринтМенеджер → Мониторинг: статистика печати, номера карт авторизации

Синхронизация пользователей и устройств

Все пользователи автоматически синхронизируются со всеми подключенными ПринтМенеджерами.

Принтеры и МФУ, напротив, передаются выборочно. Для каждого ПринтМенеджера администратор определяет, какие устройства должны быть к нему подключены.

Такой подход позволяет использовать несколько ПринтМенеджеров в одной системе, распределяя между ними устройства по филиалам, локациям или другим критериям.

Источник данных

Мониторинг является мастер-системой для пользователей.

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

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

Как работают правила печати

Назначение

Правила печати позволяют автоматически управлять обработкой заданий и доступом пользователей к функциям МФУ при выполнении заданных условий.

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

Из чего состоит правило

Каждое правило состоит из двух частей:

В общем виде правило можно представить так:

Если выполняется условие → выполнить действие.

Например:

Условия

Условия определяют, к каким заданиям должно применяться правило.

В качестве условий могут использоваться, например:

Если условие не задано, правило применяется ко всем заданиям пользователя.

Действия

При выполнении условия Printum может автоматически выполнить одно или несколько действий.

Например:

Кому применяются правила

Правила не работают сами по себе — они должны быть назначены пользователям.

Правило можно назначить:

Когда изменения вступают в силу

После создания или изменения правила его необходимо синхронизировать с ПринтМенеджером.

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

Примеры использования

Правила позволяют решать широкий круг практических задач. Например:

Методы авторизации

Назначение

Printum поддерживает несколько способов авторизации пользователей в зависимости от используемого компонента системы и требований организации.

Различные методы могут использоваться одновременно. Например, пользователь может входить в веб-интерфейс по доменной учётной записи, а на МФУ авторизовываться по карте или PIN-коду.

Авторизация в веб-интерфейсе

Для входа в веб-интерфейс пользователь указывает свой логин и пароль.

Проверка пароля может выполняться двумя способами:

При использовании доменной авторизации пользователь использует те же учётные данные, что и для входа в домен. Это позволяет централизованно управлять паролями и, при соответствующей настройке инфраструктуры, реализовать единый вход (SSO).

Для доменной авторизации Printum поддерживает два механизма:

Выбор механизма зависит от инфраструктуры организации. Одновременно может использоваться только один из них.

Авторизация на МФУ

Printum поддерживает два варианта организации авторизации пользователей на принтерах и МФУ:

Встроенное приложение

При использовании встроенного приложения пользователь может авторизоваться:

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

Внешнее средство авторизации

Пользователь авторизуется по бесконтактной карте. После успешной авторизации система отправляет на устройство задания из его отложенной очереди.

Можно настроить один из трех режимов выпуска:

При выборе режима First или Last остальные задания остаются в очереди и могут быть распечатаны при следующей авторизации либо удалены в соответствии с настроенными правилами.

Авторизация по карте

В большинстве случаев основным способом авторизации пользователей на МФУ является авторизация по карте.

Данные карты могут быть добавлены несколькими способами:

Картридеры и поддерживаемые карты

Тип картридера выбирается исходя из типа карт, используемых в организации. Printum может использоваться с различными технологиями бесконтактных карт, применяемыми в корпоративных системах контроля и управления доступом (СКУД), при условии использования совместимого картридера.

Картридер должен одновременно:

Поскольку совместимость определяется производителями оборудования, перед внедрением рекомендуется проверить выбранную комбинацию «тип карты — картридер — МФУ» на оборудовании заказчика.

Авторизация по PIN-коду

Авторизация по PIN-коду доступна только при использовании встроенного приложения Printum и обычно применяется как альтернативный способ авторизации или как временная замена бесконтактной карты.

При запуске системы возможна массовая генерация PIN-кодов для пользователей. В дальнейшем PIN-коды могут автоматически создаваться для новых сотрудников или перевыпускаться администратором.

После генерации PIN-код автоматически отправляется пользователю по электронной почте.

В целях безопасности PIN-код не отображается в интерфейсе Printum. Администратор может инициировать создание или перевыпуск PIN-кода, но не может просмотреть его действующее значение.

Совместимость встроенных приложений

Назначение

Встроенные приложения Printum разрабатываются под программные платформы производителей печатающих устройств, а не под отдельные модели принтеров и МФУ.

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

Как определяется совместимость

Каждый производитель использует собственную платформу для разработки встроенных приложений.

Printum поддерживает работу с определёнными платформами и версиями этих платформ. Для некоторых производителей также могут действовать дополнительные требования.

Производитель Платформа Поддерживаемая версия Особенности
HP OXPd Устройство должно поддерживать все необходимые сервисы платформы OXPd. Для некоторых моделей OfficeJet Pro требуется OXPd 1.7 и сервер OPS.
Xerox EIP 2.5 и выше Для авторизации по картам устройство должно поддерживать подключение USB-картридера. На некоторых моделях может потребоваться обновление прошивки.
Konica Minolta Open API 5.0 и выше
Kyocera HyPAS 2.1.3 и выше Для работы со считывателями карт требуется Kyocera Card Authentication Kit. На старых версиях платформы может быть доступна только часть функционала.
Pantum PEDK 1.00.012 и выше —
Ricoh SmartSDK 2.5 и выше Требуется панель управления Smart Operation Panel (SOP) G2/G2.5.
Canon MEAP 5.7 и выше На сертификации. Будет доступно после прохождения сертификации. Срок неизвестен.
Avision / Гравитон SDK 1.3 и выше —
Sharp OSA Уточняется Требуется установка дополнительных модулей MX-AMX2 и MX-AMX3.
Lexmark / Fplus LeSF 5.0 и выше —
Brother —
Epson —
Sindoh Open API 5.0 и выше Перед установкой приложения требуется установка прошивки Konica Minolta.

Полный перечень протестированных моделей приведён в документе «Список поддерживаемых устройств».

Почему список моделей не является исчерпывающим

В документе приведены модели, для которых производителем заявлена поддержка нужной платформы или совместимость которых подтверждена при внедрении и тестировании.

При этом список не является исчерпывающим.

Если устройство работает на поддерживаемой версии платформы и соответствует дополнительным требованиям, встроенное приложение, как правило, может быть установлено и на него, даже если конкретная модель отсутствует в перечне.

Поэтому отсутствие модели в перечне не означает автоматически, что устройство не поддерживается. В таком случае необходимо уточнить платформу и её версию.

Как проводится тестирование

Printum тестирует встроенные приложения на референсных устройствах соответствующих платформ.

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

Что проверить перед внедрением

Перед установкой встроенного приложения рекомендуется проверить:

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

Что такое встроенное приложение Printum

Назначение

Встроенное приложение Printum — это приложение, устанавливаемое непосредственно на принтер или МФУ. Оно превращает устройство в терминал Printum, обеспечивая безопасную авторизацию пользователей, применение политик безопасности и доступ к функциям системы непосредственно с панели управления устройства.

Как это работает

Производители печатающих устройств предоставляют программную платформу для разработки и установки пользовательских приложений. Printum использует эту возможность для установки собственного встроенного приложения.

Установка приложения является штатной возможностью, предусмотренной производителем оборудования. При этом Printum:

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

Что происходит после установки

После установки встроенное приложение заменяет стандартный экран готовности устройства экраном авторизации Printum.

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

Для сервисных инженеров предусмотрена возможность перехода в сервисное меню устройства без использования встроенного приложения.

Возможности встроенного приложения

Встроенное приложение позволяет:

Совместимость

Printum разрабатывает встроенные приложения под программные платформы производителей, а не под отдельные модели устройств.

Подробнее о поддерживаемых платформах, версиях и требованиях к оборудованию см. в статье «Совместимость встроенных приложений».

Что такое внешнее средство авторизации

Назначение

Внешнее средство авторизации — это программно-аппаратный комплекс, позволяющий организовать безопасную печать на принтерах и МФУ, которые не поддерживают установку встроенного приложения Printum.

Внешнее средство авторизации обеспечивает идентификацию пользователя по бесконтактной карте и автоматический выпуск заданий отложенной печати.

Как это работает

Внешнее средство авторизации состоит из двух компонентов:

Когда пользователь прикладывает карту к картридеру, внешний модуль передает идентификатор карты в Printum. Система определяет пользователя и, если авторизация успешна, отправляет задания из его очереди печати на устройство.

При этом на самом принтере или МФУ не требуется установка какого-либо программного обеспечения.

Когда используется

Внешнее средство авторизации применяется в случаях, когда:

Такой подход позволяет реализовать безопасную печать на любых сетевых принтерах и МФУ независимо от производителя.

Режимы выпуска заданий

После успешной авторизации Printum может автоматически выпускать задания одним из трех способов:

При использовании режимов First и Last остальные задания остаются в очереди и могут быть распечатаны при следующей авторизации. При этом невостребованные задания могут автоматически удаляться правилами через указанный промежуток времени.

Совместимость

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

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