AI ЧАСТЬ 2 — Мониторинг МФУ на Flask: новые функции, проблемы и планы

[AI]

В первой части я рассказывал, как из 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 и выложу чистую сборку с инструкцией — чтобы любой желающий мог развернуть такую же систему у себя.