В первой части я рассказывал, как из Flask + SNMP за пару вечеров собрать простую страницу со статусами принтеров.
С тех пор проект вырос — появилась база для склада, журнал изменений, страница «парк устройств», улучшенный SNMP‑сервис и UI.
В этой части — что конкретно изменилось, с какими проблемами я столкнулся и что планирую делать дальше.
Что изменилось — новые функции
Склад картриджей
Учёт типов картриджей и их остатков.
На главной странице «Мониторинг» у каждого устройства отображается текущий запас по соответствующему типу картриджа.
Журнал изменений (кто / когда / почему добавил или списал картридж).
UI: просмотр, фильтр «только используемые картриджи», быстрые кнопки «−1» (списать со склада), модалки для редактирования и создания типов.
Кнопка «+1» тоже есть, но по факту ей почти не пользуемся — жизнь показала, что большинство операций идёт через модалку с комментарием.
Как выглядит склад картриджей
Небольшой скриншот текущего интерфейса:
Парк устройств
Раньше список принтеров брался только из CSV. Сейчас есть отдельная страница «Парк устройств», а SNMP‑опрос уже опирается на парк, а не на сырой CSV.
Таблица парка: серийный номер, модель, IP, здание, кабинет, инв.№, статус (в работе / склад / ремонт / списан).
Можно добавлять / редактировать / удалять устройства через веб‑интерфейс.
Есть импорт / синхронизация с «старым» списком.
В записи устройства хранятся метаданные:
display_name,building,room,ip— это всё дальше используется в мониторинге и отчётах.
Как выглядит парк устройств
Небольшой скриншот текущего интерфейса:
Как выглядит главная страница мониторинга
Небольшой скриншот текущего интерфейса:
ТО / журнал ремонтов
Фиксация выполненных ТО и ремонтов с сохранением «снимка» на момент операции: имя принтера, здание, кабинет, серийный.
Отдельная страница с фильтрами (период, здание, тип записи) и экспортом в Excel.
На главной странице есть кнопка «ТО» — можно быстро зафиксировать, что техработа по конкретному принтеру выполнена.
Мониторинг по SNMP (улучшения)
SNMP‑опрос теперь работает в фоне и складывает данные в кеш. Интерфейс читает этот кеш и не ждёт каждого запроса.
Есть поддержка множественных каналов (BK/Y/C/M) и старых OID’ов (legacy).
При опросе делается попытка распознать модель и привязать её к справочнику
models_map.json, чтобы понять, какие картриджи реально стоят в аппарате.
Экспорт в Excel
Выгрузки: остатки склада, сколько было использовано за период, журнал изменений склада, парк устройств (разные режимы), журнал ТО.
Генерация xlsx на сервере — получаются готовые таблицы, которые можно отдать менеджерам или прикрепить к письму.
Управление пользователями и роли
Пользователи и роли хранятся в
config.json, управляются через веб‑страницу.Роли: просмотр склада, изменение склада, редактирование принтеров, экспорт, доступ к настройкам, админ.
Таким образом можно разделить: кому только смотреть, а кому разрешено что‑то менять.
Проблемы, с которыми столкнулся (и что пришлось делать)
1. Цветные МФУ: как привязать цвет к «нашему» картриджу на складе
Задача: для цветного аппарата нужно понять не только «тонер 10%», но и:
какой картридж стоит в BK/Y/C/M;
к какому типу на складе это всё относится.
Что всплыло на практике:
Одна и та же модель цветного МФУ на разных прошивках может:
на одной прошивке отдавать 4 отдельных значения (BK/Y/C/M);
на другой — только один общий счётчик;
иногда — значения, которые вообще не похожи на проценты (max = 65535 и т.п.).
Строки с типом картриджа в SNMP выглядят по‑разному:
TK‑1170,Canon C‑EXV54 Y,Black: CB436A,плюс свои локализации и «украшения».
Что сделал в итоге:
Ввёл свой справочник моделей (
models_map.json), где для каждой модели руками описал:какие цвета есть (BK/Y/C/M);
какой «человеческий» тип картриджа соответствует каждому цвету.
При опросе:
пытаюсь вытащить модель из SNMP (sysDescr, hrDeviceDescr);
ищу её в справочнике;
если нашёл — понимаю, какой цвет к какому типу картриджа привязать на складе.
Если модель не найдена или SNMP отдаёт ерунду — такие устройства отдельно смотрю и дописываю в справочник вручную.
2. Одинаковая модель, разное поведение SNMP
На одних аппаратах условной «Kyocera XYZ» нужные OID читаются без проблем, на других — те же OID либо не работают, либо возвращают другой набор значений.
Вывод:
Универсальной схемы вида «всегда берём вот эти OID» не существует.
Пришлось сделать ступенчатую логику:
сначала пробуем один набор OID (новый формат),
если не сработало — откатываемся на старый (legacy),
если и там нет нормальных данных — устройство попадает в список «под разбор».
Дальше уже смотрю руками, что оно там на самом деле отдаёт.
3. Параллельные правки и CSV
Изначально остатки и журнал жили в CSV‑файлах. При параллельной работе получалось классическое:
один человек что‑то меняет,
второй в это же время нажимает «списать −1»,
в итоге файл перезаписывается поверх, часть изменений теряется.
Что сделал:
Перешёл на SQLite (
data.db) для склада, расходников и журнала ТО.Любое изменение остатков:
пишет новые значения в таблицу,
тут же добавляет строку в журнал, всё в рамках одной транзакции.
Планы — что хочу доделать
1. Настройки для конкретных устройств (отдельные OID и правила)
Проблема: часть принтеров «говорит» по‑своему: нужные OID другие, формат значений отличается, стандартная схема не работает.
Что хочу сделать:
В таблицу
printers_parkдобавить поле с настройками для конкретного устройства (JSON с набором OID, форматом значений, таймаутом и числом попыток).В SNMP‑слое:
при опросе сначала смотреть, есть ли у устройства свои настройки;
если есть — использовать их;
если нет — работать по текущей общей схеме.
В UI (
/park):в карточке устройства сделать раздел «Расширенные настройки»:
режим «по умолчанию» / «свои OID»;
поля для OID и параметров опроса;
кнопку «Сбросить на значения по умолчанию».
Идея в том, чтобы один раз «докрутить» проблемные МФУ и далее не трогать их в коде.
2. Автоматическое списание картриджей со склада
Сейчас списание делается руками: нажимаем «−1» на складе или в нужном месте интерфейса. Хочется убрать часть рутины.
Идея: автоматическое списание картриджа при выполнении набора условий, с возможностью включать эту опцию отдельно для каждого МФУ.
Пример условий:
уровень тонера у конкретного принтера упал ниже порога (например, ≤ 5%);
видно, что картридж был заменён (например, по скачку счётчика страниц или смене серийника картриджа — если удастся это надёжно определять);
на складе есть хотя бы 1 штука соответствующего типа.
Как это может выглядеть:
В настройках устройства:
флажок «Автоматически списывать картридж при замене»;
выбор, по какому событию считать картридж заменённым.
В логике:
при очередном опросе, если условия выполняются и опция включена:
уменьшать остаток на складе на 1 для нужного типа;
добавлять запись в журнал склада с пометкой, что списание произошло автоматически.
По умолчанию опция будет выключена, чтобы ничего не списалось неожиданно.
3. Автоматическая синхронизация списка устройств с print‑server / AD
Сейчас схема такая:
один раз собрал список принтеров через скрипт, положил его в CSV/базу, а новые устройства добавляю уже руками через веб‑страницу. Работает, но это чистый ручной режим.
Что хотелось бы в идеале:
периодически получать список принтеров:
напрямую с print‑server (через скрипт/API),
либо из AD (список опубликованных принтеров);
сравнивать его с текущим парком:
новые устройства показывать как «кандидаты на добавление»;
те, что пропали с сервера, — как «кандидаты на списание/склад».
Технически это может быть:
фоновая задача, которая раз в N часов:
опрашивает print‑server или AD,
складывает результат во временную таблицу,
строит «дифф» с
printers_park.
Страница «Синхронизация», где:
блок «найдены новые устройства» с кнопкой «Добавить в парк»;
блок «в парке есть устройства, которых больше нет на print‑server» — с возможностью сменить им статус (например, «списан» или «на складе»).
Когда будет на это время доделаю, пока что устраивает текущий функционал.
Зачем всё это и где проект уместнее всего
Сейчас это просто рабочий инструмент для эксплуатации парка принтеров:
показывает статусы и уровень тонера;
знает, что лежит на складе и кто что списал;
помнит, когда и по какому принтеру делали ТО;
даёт готовые Excel‑отчёты.
Цель — закрыть типовые задачи небольших и средних парков без тяжёлых внедрений и подписок.
Если сравнивать с тем, что обычно используют:
SaaS (PaperCut, PrinterLogic и т.п.)
Там много аналитики, учёта отпечатков, интеграций и коммерческой поддержки. Но за всё это платите подпиской и обычно тянете данные куда‑то наружу.
Здесь всё локально, разворачивается за вечер и решает именно задачи эксплуатации: мониторинг, склад, ТО, отчёты.Классический мониторинг (Zabbix, Nagios + шаблоны)
Zabbix и подобные системы сильнее в алертинге и масштабе, но требуют настройки SNMP‑шаблонов и времени на тюнинг.
При этом склада картриджей, журнала ТО и «одним кликом в Excel» там нет — это придётся городить отдельно.
В таком окружении этот проект хорошо закрывает повседневные вещи:
быстро увидеть, у кого кончается тонер и есть ли запас на складе;
понять, когда последний раз что‑то делали с конкретным МФУ;
выгрузить в один файл картриджи, парк или журнал ТО и отдать тем, кто «жить в системе» не собирается.
Если парк небольшой или средний и нужна прозрачность без лишних движений, текущей функциональности уже достаточно, чтобы каждый день экономить время.
Если же нужна глубокая интеграция со всем ИТ‑ландшафтом и глобальный мониторинг, это задача для других инструментов, а этот проект вполне может остаться лёгким локальным помощником рядом.
Когда все эти доработки будут реализованы и протестированы, я уберу свой мусор из репозитория, приведу README и выложу чистую сборку с инструкцией — чтобы любой желающий мог развернуть такую же систему у себя.
