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

Мониторинг картриджей в сетевых принтерах.

Все возможных систем мониторинга под это предостаточно, как платных так и бесплатных. Но мне хотелось сделать что то свое, небольшое и работающее. на вооружении имеется 8 сетевых принтеров разных моделей (HP, Koycera), все принтеры сетевые и с них нужно собирать информацию по состоянию картриджа и в случае когда порог картриджа доходит 6 % уведомлять меня по почте, что скоро на таком то принтере, закончится такой то картридж.

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

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

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

Вкладка «Настройка SNMP«, здесь мы задаем параметры опроса принтеров на нужные нам значения для последующей обработки их вы использования. В принципе у всех принтеров одинаковые OID значения, поэтому менять их не рекомендую, должно все нормально отрабатывать. Но если все же есть желание поправить OID, то сделать это можно воспользовавшись кнопками управление внизу.

Период опроса принтеров задан 15 минут. И в случае если картридж доходит до отметки в 6% нам приходит уведомление вот такого вида

ПОНРАВИЛАСЬ ИЛИ ОКАЗАЛАСЬ ПОЛЕЗНОЙ СТАТЬЯ, ПОБЛАГОДАРИ АВТОРА

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

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

Форма добавления нового устройства или корректировка уже существующего.

Вкладка «Шаблоны» содержит следующие элементы управления:
— кнопки управления записями шаблонов и объектов (Добавление, Добавление копированием, Изменение, Удаление);
— список шаблонов;
— список объектов шаблонов.

Форма добавления нового шаблона (объекта шаблона) или корректировка уже существующего.
Примечание: при добавлении нового шаблона или его изменении, также можно заполнить поля объекта. Хотя они и имеют неактивную окраску, однако доступны для редактирования.

Вкладка «Настройки», говорящее за себя название, содержит доступные для изменения параметры программы.

В программе предусмотрено несколько ключей командной строки:
-a или -auto используется для автоматического старта мониторинга после запуска программы, при условии, что периодичность опроса больше нуля минут;
-s или -silent используется для скрытого запуска с показом иконки программы в области уведомлений;
Пример: moust_32.exe -a -s позволяет запустить программу без показа главной формы с иконкой в трее и автоматическим стартом мониторинга.

Комплект утилиты состоит из следующих файлов:
— moust_32.exe — приложение 32 бита;
— moust.db — база данных;
модулей OpenSSL:
— libeay32.dll
— ssleay32.dll

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

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

На 04.05.2021 г.
+ добавлена обработка составных объектов на случай отсутствия данных в ответе, по умолчанию минимум: 0, максимум: 100, т.е. если устройство вернёт пустой ответ, будет подставлено значение по умолчанию.
! база данных и модули OpenSSL не модифицировались, достаточно заменить exe-файл из архива.
Текущая версия: 1.0.0.8

На 24.06.2020 г.
+ добавлена настройка «Вид двоичных данных», при помощи которой бинарные данные отображаются как «HEX-строка» (по умолчанию) или как «ASCII-строка»;
! база данных и модули OpenSSL не модифицировались, достаточно заменить exe-файл из архива.
Текущая версия: 1.0.0.7

На 02.12.2019 г.:
— в процессе доработки система автоматического информирования почтовыми и СМС-уведомлениями о событиях мониторинга;
— в процессе доработки система обновления базы данных;
— в процессе доработки управление журналом мониторинга.

Периодически на одном из принт-серверов под управлением Windows Server 2012 R2 замечаем, что некоторые подключенные сетевые принтеры переходят в автономный режим работы, перестают печатать, а в очереди печати начинают накапливаться задания. В этой статье мы рассмотрим, почему сетевой принтер может переключаться в offline режим, и как решить эту проблему без переустановки принтера и перезагрузки сервера печати.

Отройте на принт-сервере консоль управления Print Management, найдите принтер со статусом Queue Status = Offline (Отключен), откройте его очередь печати и убедитесь, что в параметрах принтера отключен опция Use Printer Offline (Работать автономно).

Затем убедитесь, что принтер включен и доступен по сети (проверьте доступность принтера через ping по IP, проверьте, открывается ли веб интерфейс управления принтером).

Как Windows определяет доступность принтера? В ОС Windows 7 и выше по-умолчанию для опроса состояния принтера используется протокол SNMP (Simple Network Management Protocol). Сервер печати отправляет принтеру SNMP запрос и ждет ответа. Если SNMP от принтера ответ не получен, такой принтер считается недоступным и переводится на принт-сервере в автономный режим работы. Рассмотрим, особенности настройки протокола SNMP для сетевых принтеров на сервере печати Windows.

В первую очередь нужно убедиться, что ваш принтер поддерживает протокол SNMP. Откройте веб интерфейс управления сетевым принтером, и проверьте, что в настройках принтера включен протокол SNMP и для него используется имя сообщества (community name) public.

Если ваш принтер не поддерживает протокол SNMP, вы должны отключить этот протокол в настройках порта печати этого принтера. В результате Windows перестанет слать SNMP пакеты для опроса состояния устройства.

Проверьте, что состояние принтера изменилось на Ready/Готов.

Вы можете найти все принтера на принт-сервере, на которых отключен протокол SNMP с помощью следующего командлета PowerShell (используется встроенный модуль PrintManagement):

Следующая команда PowerShell поможет найти порты сетевых принтеров, у которых имя SNMP сообщества отличается от Public:

Если проверка настроек SNMP не помогла вывести принтер из автономного режима, следует проверить следующие параметры.

• Проверьте, что в настройках порта печати указан правильный IP адрес принтера;
• Проверьте, что для порта печати используется тип “Standard TCP/IP Port”, а не “WSD Port”;
• Убедитесь, что ваши файерволы не блокирует SNMP трафик (порты 161/UDP и 162/UDP);
• Полностью удалите и пересоздайте принтер и порт печати. Переустановите драйвера принтера;
• Перезапустите службу spooler;

Simple Network Management Protocol (SNMP) — это протокол прикладного уровня, он делает возможным обмен данными между сетевыми устройствами.

SNMP — это не продукт, а свод правил. Он определен Советом по архитектуре Интернета и является частью пакета TCP/IP. SNMP управляется и поддерживается Инженерной группой Интернета (IETF).

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

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

Компоненты, составляющие архитектуру SNMP:

• сетевая станция управления, включающая в себя сетевого менеджера;
• агенты;
• мастер-агенты;
• управляемые компоненты.

Сетевая станция управления — NMS

Network Management Station (NMS) удаленно мониторит управляемые устройства, получает данные, собранные мастер-агентами, отслеживает производительность и представляет полученную информацию в графическом виде. Встроенный менеджер NMS отвечает за связь с агентами.

Агенты

Это программа, связывающая сетевых менеджеров и субагентов. Мастер-агент анализирует запросы сетевого менеджера NMS и пересылает их субагентам, собирает и формирует ответы субагентов и отправляет их менеджеру. Мастер-агент уведомляет менеджера, если запрос некорректен или запрошенная информация недоступна.

Субагент

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

Управляемый компонент

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

База управляющей информации — MIB

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

Идентификатор объекта — OID

Каждый объект в MIB имеет свой уникальный ID — OID, который представлен в числовом формате и имеет иерархическую структуру. OID — это числовой эквивалент пути к файлу. Он присваивает значения каждой таблице в MIB, каждому столбцу в таблице и каждому значению в столбце.

Например, OID 1.3.6.1.4.868.2.4.1.1.1.3.3562.3. означает iso.org.dod.internet.private.transition.products.chassis.card.slotCps.cpsSlotSummary.cpsModuleTable.cpsModuleEntry.cpsModuleModel.3562.3.

Используя первые 6 цифр этого OID, можно пройти по дереву на схеме.

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

Древовидная иерархия MIB и OID в SNMP выглядит несколько запутанной, но у нее есть свои преимущества. Это простая и гибкая система организации сетевых устройств, она работает вне зависимости от размера сети.

Теория и логика работы протокола SNMP

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

PDU

Менеджеры и агенты обмениваются данными через протокол UDP. Вместо него также может использоваться TCP, IPX или протокол MAC-уровня. Обмен данными основан на Protocol Data Unit (PDU).

Всего в SNMP семь PDU:

• GET — запрос менеджера NMS на получение данных c устройства.
• GETNEXT — запрос, аналогичный GET. Отличие лишь в том, что менеджер запрашивает данные, находящиеся на следующем уровне иерархии OID, в MIB.
• SET — с помощью этого запроса менеджер изменяет или присваивает устройству новые данные.
• RESPONSE — сообщение от агента, высылаемое в ответ на запрос данных.
• TRAP — уведомление о произошедшем событии или ошибке. Агент отправляет его сразу после наступления события, не дожидаясь запроса менеджера. Менеджер никак не подтверждает получение сообщения, что может стать проблемой.
• GETBULK — запрос агенту на извлечение с устройства массива данных. Это улучшенный вариант запроса GETNEXT.
• INFORM — сообщение, аналогичное TRAP, но с подтверждением получения. Агент будет отправлять уведомление, пока менеджер не подтвердит, что оно дошло.

INFORM, GETBULK — есть только во второй и третьей версиях протокола SNMP.

Схема PDU

Статусы ошибок и их описание.

• 0 — noError — Процесс завершен успешно.
• 1 — tooBig — Объект слишком большой и не помещается в сообщение Response.
• 2 — noSuchName — Для запросов GET и SET: запрошенная переменная не существует в базе MIB. Для запросов GETNEXT: переменная не имеет приемника в дереве MIB.
• 3 — badValue — Для запросов SET: сделана ошибка в синтаксисе или задано недопустимое значение.
• 4 — readOnly — Ошибка не определена.
• 5 — genErr — Прочие ошибки, например, попытка присвоить значение, превышающее пределы реализации.

Сетевые порты SNMP

По умолчанию SNMP использует UDP-порты 161 и 162. Менеджер отправляет запросы на порт 161 агента. С порта 161 агент отправляет ответ менеджеру. При отправке запроса менеджер добавляет к нему ID, а агент вставляет этот ID в ответ, чтобы менеджер мог связать свой запрос с ответом агента.

Ловушки агент высылает на порт 162 менеджера. Если используется DLTS или TLS, то агент высылает сообщения на порт 10162, а менеджер — на порт 10161. Администратор может изменить порты SNMP, используемые по умолчанию, на любые другие.

Ловушки

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

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

• 0 — coldStart — Холодный запуск устройства.
• 1 — warmStart — Горячий запуск устройства.
• 2 — linkDown — Интерфейс отключился.
• 3 — linkUp — Интерфейс включился.
• 4 — authenticationFailure — Менеджер выслал сообщение с неверной строкой сообщества.
• 5 — egpNeighborLoss — Агент потерял связь с хостом по протоколу Exterior Gateway Protocol (EGP).
• 6 — entrpriseSpecific — Произошло событие, характерное для производителя данного устройства.

В SNMP есть два типа ловушек: Trap и Inform. Отличия между ними в том, что после получения Inform менеджер подтверждает получение ловушки. В противном случае агент будет отправлять Inform, пока не получит подтверждения. А вот после получения Trap менеджер не отправляет подтверждение. Если сообщение не дошло до менеджера, агент об этом не узнает.

Версии протокола SNMP

Первая версия протокола создана в 80-х годах XX века. Легка в настройке — требуется только строка community. Версия широко используется до сих пор.

SNMPv2с

Вторая версия протокола SNMP появилась в 1993 году. Разработчики добавили в нее новый запрос GetBulk и ловушку Inform, а также усовершенствовали безопасность.

У этой версии есть два способа коммуницировать с устройствами, поддерживающими SNMPv1: двуязычная система сетевого управления и прокси-агенты. Прокси-агенты выполняют роль мастер-агентов, а в двуязычной системе управления менеджер определяет, какую версию SNMP поддерживает агент, и связывается с ним через SNMPv1 или SNMPv2c.

SNMPv3

Третья версия вышла в 1998 году. Разработчики добавили в SNMP криптографическую защиту, облегчили удаленную настройку и администрирование объектов. Этого удалось достичь за счет определения набора стандартизованных объектов управления, называемых объектами MIB удаленного сетевого мониторинга, — RMON MIB.

Безопасность

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

В работе над второй версией протокола разработчики предложили несколько вариантов решения. Распространение получил вариант SNMPv2c — не самый надежный, но простой в использовании.

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

Модели безопасности протоколов SNMP по версиям

Community-based Security — модель безопасности на основе строки сообщества. Фактически это идентификатор пользователя или пароль, который отправляется вместе с запросом. Если строка сообщества неверна, агент игнорирует запрос.

Строка сообщества зависит от вендора устройства. Часто вендоры по умолчанию выбирают «PUBLIC» в качестве пароля, поэтому первым делом на новых устройствах нужно изменить строку сообщества для защиты сети от злоумышленников.

Строки сообщества бывают трех видов:

• только для чтения — позволяет получать данные с устройства;
• чтение/запись — позволяет получать данные и изменять конфигурацию устройства;
• строка сообщества SNMP Trap — позволяет получать ловушки.

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

Party-based Security Model — модель на основе так называемых «сторон». Для коммуникации между менеджером и агентов выбирается логическая сущность, называемая стороной. Она устанавливает протоколы аутентификации и шифрования, а отправитель и получатель соглашаются со способом шифрования и дешифровки данных. Сложность использования модели помешала ее распространению среди пользователей.

Лучше всего безопасность проработана в третьей версии SNMP за счет USM и VACM. Упрощенно VACM (View-based Access Control Model) можно описать как модель с разными уровнями доступа для групп менеджеров. При получении запроса агент решает, разрешен ли определенной группе менеджеров доступ к чтению, записи и получению уведомлений.

Типичные проблемы безопасности

• Периметр сети может быть небезопасен, если запросы SNMP разрешены межсетевыми экранами и пакетными фильтрами.
• При активации функций SNMP на некоторых устройствах имя строки сообщества по умолчанию PUBLIC. Хакер начнет поиск именно с этого.
• Прекращение отправки ловушек. Изменив запись в команде snmpEnableAuthenTraps, злоумышленник может прекратить отправку ловушек. В случае неудачной аутентификации он может не беспокоиться о том, что его безуспешные попытки взлома привлекут внимание администратора сети.
• Удаленный пакетный перехват при помощи снифферов — программ анализа сетевого трафика.
• Слабый контроль доступа к строке сообщества чтение-запись. Она дает всем пользователям возможность изменять конфигурацию устройств сети SNMP. Администратор должен внимательно следить за этим, иначе бесконтрольное изменение конфигураций поможет злоумышленнику нанести вред системе.

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

Практическое применение протокола

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

Возможности SNMP-протокола

Благодаря протоколу администратор может:

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

При помощи стороннего ПО можно также:

• управлять облачными сервисами;
• добавлять данные через кастомные OID.

SNMP и переход с IPv4 на IPv6

Протокол по умолчанию должен работать с IPv4 или IPv6. На практике IPv6 создает определенные проблемы для работы SNMP. Эти проблемы связаны объектами MIB, содержащими сетевые адреса. OID в MIB хранят информацию для нескольких уровней TCP/IP, и различия между IPv4 и IPv6 будут отражены в OID.

Отсутствие поддержки IPv6 в существующих объектах MIB проявляется двумя способами:

Эти проблемы решаются также двумя способами:

• созданием новых баз MIB с поддержкой только IPv6 или независимых от версий протокола Protocol-version independent (PVI);
• модификацией MIB для добавления новых или обновления существующих OID с поддержкой IPv6.

Инсталляция

Она подробно описана в документации Microsoft.

Настройка данных агента SNMP

• В дереве консоли надо развернуть узел «Службы и приложения» и выбрать пункт «Службы».
• В области справа дважды щелкнуть элемент «Служба SNMP».
• Затем открыть вкладку «Агент».
• В разделе «Служба» надо установить флажки рядом со службами, предоставляемыми компьютером и нажать «OK».

Настройка сообщества и ловушек SNMP

• В дереве консоли надо развернуть узел «Службы и приложения» и выбрать пункт «Службы».
• В области справа дважды щелкнуть элемент «Служба SNMP».
• Открыть вкладку «Треппинг».
• В поле «Имя сообщества» ввести имя сообщества и нажать кнопку «Добавить в список».
• В разделе «Адресаты ловушек» нажать кнопку «Добавить».
• Нажать «ОК».

Настройка безопасности SNMP

• В дереве консоли нужно развернуть узел «Службы и приложения» и выбрать пункт «Службы».
• В области справа дважды щелкнуть элемент «Служба SNMP».
• Открыть вкладку «Безопасность».
• Установить флажок «Пересылка ловушек проверки подлинности», если необходимо, чтобы агент отправлял ловушку при сбое проверки подлинности.
• В разделе «Приемлемые имена сообществ» надо нажать кнопку «Добавить».
• В поле «Права сообщества» выбрать разрешения, чтобы указать, как узел будет обрабатывать запросы SNMP от выбранного сообщества.
• В поле «Имя сообщества» ввести нужное имя сообщества с учетом регистра, а затем нажать кнопку «Добавить».
• Затем, чтобы принимать запросы SNMP от любого узла в сети, независимо от их удостоверения, надо выбрать вариант «Принимать пакеты SNMP с любого узла».

Настройка SNMP в Linux

Сначала нужно установить последние обновления при помощи yum/dnf:

затем установить SNMP:

yum install net-snmp net-snmp-utils

и создать копию конфигурационного файла:

mv /etc/snmp/snmpd.conf /etc/snmp/snmpd.conf.orig

теперь нужно отредактировать настройки агента

и добавить строки:

Локацию и email лучше указать реальные.

Пора добавить сервис в автозагрузку и перезапустить его:

systemctl enable snmpd.service
systemctl start snmpd

Как проверить, что сервис запущен:

systemctl status snmpd

Опрос агента с помощью утилиты snmpwalk:

snmpwalk -v 2c -c public -O e 127.0.0.1

Опрос сервера локально командой:

snmpwalk -v2c -c public localhost system

Настройка SNMP в Debian 10

Сначала нужно установить демона, клиента и файлы:

apt install snmpd snmp libsnmp-dev

После установки переходим к настройке SNMP в Debian.

Файлом настройки SNMP-агента по умолчанию является /etc/snmp/snmpd.conf. Агент SNMP может быть запущен с настройками по умолчанию. Однако для включения удаленного мониторинга нужно сделать несколько изменений. Для этого создайте резервную копию файла:

cp /etc/snmp/snmpd.conf /etc/snmp/snmpd.conf.orig

vim /etc/snmp/snmpd.conf
###############################################################################
#
# AGENT BEHAVIOUR
#

# Listen for connections from the local system only
agentAddress udp:127.0.0.1:161,udp:192.168.43.62:161

Для настройки аутентификации:

rocommunity предоставляет доступ только на чтение, а rwcommunity дает доступ к чтению/записи. В Access Control section нужно поместить строку

rocommunity S3CUrE 192.168.43.100

Кроме того, можно включить запрос с локального хоста rocommunity S3CUrE localhost:

Затем нужно перезапустить SNMP:

systemctl restart snmpd

Чтобы добавить сервис в автозагрузку, введите:

Итог

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

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

Мониторинг принтеров — дело благородное

В этом посте расскажем о нашем опыте мониторинга принтеров в Zabbix, ведение реестра по ним в CMDB (iTop) и визуализации статусов в Grafana. Со всеми тремя продуктами мы успешно работаем и имеем опыт внедрения в малых и средних организациях.

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

Наш стандартный подход — использование конгломерата из трёх решений: Zabbix, iTop и Grafana.

Принтеры обычно рассредоточены по офисам, этажам и кабинетам. После разработки (или доработки) шаблонов по каждому устройству, для каждой такой локации мы создаём группы в Zabbix и добавляем туда заведённые в мониторинг устройства. Система позволяет создавать квазивложенные группы с устройствами, поэтому мы можем создавать группы по следующим форматам:

Подобная группировка упорядочивает устройства и создаёт агрегирующие статусы для групп устройств. Агрегирующие статусы нужны для визуализации каждой локации в Grafana.

Обычный способ сбора метрик — это SNMP, но в некоторых случаях приходится собирать syslog. Для сбора syslog можем использовать Elasticsearch. Если принтер подключён к рабочей станции или серверу напрямую, данные по нему можно забирать из счётчиков производительности (Performance Counters) Windows. Zabbix позволяет выполнять низкоуровневое обнаружение (Low-level Discovery или LLD) таких счетчиков производительности, поэтому, если вдруг кто-то из пользователей решит подключить принтер к своему устройству, он через некоторое время автоматически появится в Zabbix.

Визуализация

Для визуализации, аналогичную структуру вложенности создаём в Grafana. Вот, к примеру, на скриншоте ниже, 4 этажа, которые мы описали в группах Zabbix. Таким образом, каждой плитке, по каждому этажу, присваивается агрегированный статус объектов, которые находятся в нём. Кликнув на плитке мы переходим на уровень ниже.

После клика на плитку «Этаж 25» переходим на уровень ниже и видим три принтера на этаже. На одном из них («Принтер 2») какая-то проблема. Под самими принтерами представление с событиями по ним. Перейдём ещё на уровень ниже, кликнув на «Принтер 2».

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

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

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

Вы получите поддержку экспертного уровня: в нашем штате работают инженеры с сертификатами уровня Zabbix Certified Specialist и Zabbix Certified Professional по актуальной версии Zabbix 5.0.

Читайте статьи в нашем корпоративном блоге на Хабре:

Мониторинг принтеров HP, Kyocera, Brother через snmp в zabbix

Расскажу о простом и эффективном способе наблюдения за сетевыми принтерами в организации. Речь пойдет о настройке мониторинга за состоянием принтеров HP, Kyocera, Brother через snmp с помощью Zabbix. Собирать буду значения напечатанных страниц за все время, состояние тонера, название картриджа и серийный номер принтера.

• 1 Введение
• 2 Поиск необходимых OID
• 3 Настройка мониторинга принтеров по snmp
• 4 Заключение

Введение

Казалось бы актуальный запрос, но в сети я не нашел готового решения по этой теме. Есть всякие обсуждения, просьбы о помощи с настройкой, решения проблем. Но вот так, чтобы все было в одном месте мне не попалось. Постараюсь восполнить этот пробел. Самая большая проблема здесь — найти актуальные MIB и OID для собираемых значений. Если выполнить сбор всех доступных метрик по snmp, к примеру, с принтера HP, вы получите более 1000 различных метрик! Найти в этом то, что вам действительно нужно непростая задача. Я расскажу о тех метриках, что интересовали меня. Значения этих OID я узнал.

Я буду собирать следующие метрики:

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

Если у вас еще нет своего сервера для мониторинга, то рекомендую материалы на эту тему. Для тех, кто предпочитает систему CentOS:

Установка и настройка zabbix сервера.

То же самое на Debian 9, если предпочитаете его:

Установка и настройка zabbix на debian.

Приступаем к настройке.

Поиск необходимых OID

Для начала возьмем какой-нибудь принтер и посмотрим, что он нам будет отдавать по snmp. Я для примера возьму принтер HP LaserJet Pro MFP M426fdn (ip адрес 192.168.88.20). По-умолчанию у принтеров HP разрешен просмотр параметров по snmp.

Идем в консоль linux и посмотрим с помощью snmpwalk метрики принтера по snmp. Для этого установим необходимый пакет.

Теперь посмотрим метрики принтера:

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

Я вас томить не буду, а сразу укажу на строки, которые нас интересуют:

Возможно, вас еще заинтересует параметр mib-2.43.5.1.1.16.1 — название принтера. Мне лично это не нужно, но если все выводить в сводную таблицу, то может пригодиться. Так же обращаю внимание на параметр mib-2.43.11.1.1.8.1.1. Обычно он показывает максимальное число страниц, которые можно напечатать с текущего картриджа.

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

• Уровень тонера выводится сразу в % в 2.43.11.1.1.9.1.1. Параметр максимального числа страниц с текущего картриджа указан как 100% в 2.43.11.1.1.8.1.1.
• Уровень тонера в 2.43.11.1.1.9.1.1 показывает количество напечатанных страниц с текущего картриджа. Второй параметр 2.43.11.1.1.8.1.1 показывает максимальное количество страниц, которое может быть напечатано текущим картриджем. Тогда уровень тонера в % нужно считать по формуле 100-100*(mib-2.43.11.1.1.9.1.1)/(mib-2.43.11.1.1.8.1.1).

Первая ситуация мне попалась в принтерах HP, вторая в Kyocera и Brother. Из-за этого пришлось сделать 3 разных шаблона под каждого производителя принтеров. Все остальные параметры у них совпали.

В принтерах Brother mib об уровне тонера были немного другие, такие же как у HP и Kyocera, но отличались на последнюю цифру — 2.43.11.1.1.8.1.2 и 2.43.11.1.1.9.1.2 соответственно. Я не знаю, с чем это связано, но видел подобную ситуацию у других людей. Кто-то из-за этого создавал правила автообнаружения, чтобы точно вычислить последнюю цифру. Мне не пришлось этого делать. Достаточно было создать разные шаблоны для каждого производителя. Все принтеры попали в эти шаблоны на 100%.

Отдельная история с цветными принтерами. Там несколько картриджей и надо внимательно смотреть на их номера. Но тоже не сложно, просто смещение будет на одну единицу, все картриджи будут идти по порядку.

Настройка мониторинга принтеров по snmp

На самом сервере мониторинга настраивать особо нечего. Вам достаточно будет взять мои готовые шаблоны, убедиться что MIB и OID совпадают с вашими принтерами и добавить сами принтеры в мониторинг, не забыв указать у них snmp интерфейс.

Printer_HP.xml Printer_Kyocera.xml Printer_Brother.xml

Вот пример одного элемента для шаблона принтеров HP.

А вот пример вычисляемого значения уровня тонера для шаблона Kyocera.

Пример триггера, который присутствует во всех шаблонах.

Всю информацию о принтерах можно вывести на Dashboard примерно в таком виде:

Интервалы опроса итемов в шаблонах:

• Всего напечатано страниц – 1 час
• Напечатано на текущем тонере – 10 мин
• Объем тонера – 10 мин
• Уровень тонера – 10 мин
• Название картриджа – 1 день
• Серийный номер – 1 день

На момент отладки рекомендую поставить эти значения 1 минута.

Для элемента данных «Уровень тонера» указан тип данных «Числовой», чтобы работал триггер и сравнивал значение. Если у вас какие-то ошибки с тонером, например из-за того, что не новый использовали, а заправляли старый, то значение будет приходить -2 или -3 с типом «Строка». Итем станет неактивным с ошибкой:

С этим уже ничего не поделать. Можете сделать для таких принтеров отдельный шаблон и изменить тип итема с числового на строковый. Так вы хотя бы будете получать значение -2, а не ошибку итема.

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

Заключение

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