Почему SNMP это не очень просто? / Хабр

Описание

Основным устройством является встраиваемый SNMP-адаптер NetAgentII. Он может устанавливаться в отсек для SNMP-адаптера, имеющийся у ИБП производства компании Powercom следующих серий — SmartRT, Smart King, Vanguard. К данному SNMP-адаптеру может подключаться датчик мониторинга состояния окружающей среды, а именно: температуры, влажности воздуха, наличия воды (конденсата).

Производитель заявляет следующие характеристики изделия:

А поподробнее?

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

Для более подробного рассказа мы приглашаем всех хабражителей на вебинар Мониторинг и управление по SNMP, который состоится 26 мая 2021 года в 11:00 по московскому времени. На этом вебинаре мы «вживую» продемонстрируем весь вышеописанный процесс, а также многие другие способы мониторинга сетевого, серверного и нестандартного оборудования при помощи SNMP.

Посмотреть программу, зарегистрироваться на вебинар и добавить в календарик >>

Update — запись вебинара:

В результате

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

При настройке мониторинга не требуется ручное указание названий MIB-ов, ввод OID-ов и других низкоуровневых идентификаторов. Это делает настройку SNMP-мониторинга достаточно быстрой и легкой.

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

Внешний вид

Адаптер NetAgentII представляет собой плату расширения размером 60×130 мм, устанавливаемую в соответствующий отсек ИБП. Пять светодиодов показывают состояние устройства, в том числе — скорость подключения к локальной сети, наличие питания, режим ожидания и ошибку устройства.

Три разъема RJ-45 предназначены для подключения к локальной сети, внешнему модему и датчику состояния окружающей среды NetFeelerII. Под разъемами для подключения модема и датчика находится наклейка, на которой написан MAC-адрес и серийный номер устройства.

Датчик состояния окружающей среды NetFeelerII выполнен в виде белой пластиковой коробочки размером примерно 53×68 мм. С лицевой стороны NetFeelerII находится кнопка сброса, светодиоды индикации наличия питания и срабатывания сигнализации, разъем RJ-45 для подключения к NetAgentII и вход для внешнего питания.

Внутреннее устройство и схемотехника

Адаптер собран на многослойной печатной плате, маркированной как MegaTec 6PCB-013 ver.4.1 12/2007, дата выпуска — май 2009 года. Монтаж элементов двухсторонний, широко используются планарные компоненты, плата покрыта лаком. Управляющий процессор архитектуры ARM, Samsung S3C4510B01-QE80, содержит 32-битный RISC-микропроцессор, контроллер DRAM и Flash, Ethernet- и UART-порты.

В обвязке микропроцессора стоит 8 мегабайт DRAM-памяти и 2 мегабайта флеш-памяти, а также контроллер физического Ethernet-интерфейса, Realtec. Плата оборудована часами реального времени и батарейкой. Для сброса в изначальное состояние используется перемычка.

Датчик NetFeelerII построен на PIC-микроконтроллере и состоит из основной платы и платы радиомодуля. Платы двухслойные, двухсторонние, SMD-компоненты используются, монтаж двухсторонний. Отдельный вход питания позволяет работать автономно. Адаптер питания в комплект поставки не входит.

Возможности web-интерфейса

В этой части обзора мы подробно рассмотрим web-интерфейс адаптера NetAgentII с подключенным датчиком NetFeelerII. За рамками обзора останется работа по протоколу SNMP и Telnet. Из-за отсутствия соответствующего оборудования мы не можем провести тестирование с внешним модемом и беспроводными датчиками.

Меню состоит из 4 разделов — Информация (Information), Конфигурация (Configuration), Логи (Log Information), Помощь (Help). Раздел Информация состоит из семи подразделов. На скриншоте вы видите окно статуса системы (System Status). Доступна информация об установленном адаптере, системном времени, сетевых настройках и настройках ИБП.

Раздел базовой информации (Basic Information) показывает подробную информацию о подключенном ИБП. Доступна информация о производителе и модели ИБП, отображается версия микропрограммы ИБП, тип и количество батарей, а также дата последней замены батарей.

Раздел Текущее состояние (Current Status) показывает подробное состояние ИБП и электропитания. В том числе — параметры входной линии электропитания, напряжение и нагрузку на выходе ИБП, подробную информацию о батареях — температуру, напряжение, уровень заряда, время работы от батарей и оставшееся время работы от батарей. Также показано время последнего и следующего самотестирования ИБП и батарей.

Раздел Удаленное управление (Remote Control) позволяет управлять ИБП через локальную сеть или интернет. Доступно тестирование емкости батареи в различных режимах, а также управление состоянием ИБП.

В разделе Измерения/Графики (Meter/Chart) доступна измерительная приборная панель текущего состояния и график, показывающий изменение шести измеряемых параметров. Контролируется входное и выходное напряжение, мощность нагрузки, частота сети, емкость и температура батарей.

Измерения и графики могут показываться в базовом и расширенном режиме, для последнего требуется интернет-подключение и поддержка Java. В расширенном режиме несколько более красивые приборы, а также есть возможность задавать параметры отображения графиков, кроме того график можно напечатать или сохранить.

Раздел Состояние модема (Modem Status) отображает информацию о модеме и его настройках, если, конечно, модем подключен. В нашем случае информация, как и сам модем, отсутствовала.

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

Далее перейдем к обзору раздела Конфигурация (Configuration), который включает в себя 11 пунктов:

• UPS Configuration
• UPS On/Off Schedule
• Network
• SNMP
• Email
• SMS
• Modem Port
• NetFeelerII
• Web/Telnet
• System Time
• Language

Раздел Конфигурация ИБП (UPS Configuration), позволяет задать основные настройки ИБП, такие как протокол связи SNMP-адаптера с ИБП, тип и количество батарей, дату замены батарей. Кроме того, в этом разделе можно задать периодичность создания записи в логе, периодичность тестирования ИБП и значения граничных параметров, в случае превышения которых отправляется соответствующее уведомление.

Раздел Расписание включения/выключения ИБП (UPS On/Off Schedule) позволяет задать время включения и выключения ИБП. Доступно расписание по дням недели, а также семь триггеров, настраиваемых на конкретную дату. Также возможно задать включение ИБП при появлении в локальной сети устройства с заданным IP-адресом. MAC-адрес устройства определяется автоматически.

Раздел Сеть (Network) позволяет задать сетевые настройки. Все настройки можно ввести вручную или указать их получение по протоколу DHCP или Bootp. Также можно задать тип подключения и отключение связи с ИБП при пропадании локальной сети. Реализована и возможность задать доменное имя для ИБП посредством службы DynDNS. Если провайдер интернета предоставляет доступ посредством PPPoE, то и тут адаптер нас не разочарует.

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

Раздел Email позволяет задать настройки почтового протокола SMTP и адреса, на которые происходит рассылка оповещений при наступлении событий. Адаптер позволяет указать SMTP-сервер (только один), порт для отправки, обычное или SSL-соединение, парольный или беспарольный вход.

Идем далее

Мы научились получать по SNMP значения скалярных переменных. Но, помимо них, в SNMP есть еще и таблицы (например таблица интерфейсов на устройстве). Как они устроены? Посмотрим MIB-browser:

В OID mgmt.interfaces (1.3.6.1.2.1.2) мы видим скалярную переменную ifNumber (1.3.6.1.2.1.2.1), содержащую количество интерфейсов в таблице, а также набор столбцов. Каждый из столбцов имеет собственный OID. Например столбец содержащий числовой индекс ifIndex интерфейса имеет OID = 1.3.6.1.2.1.2.2.1.1.

Для того, чтобы получить значение этой переменной, необходимо добавить к OID-у индекс интерфейса (например для интерфейса с индексом 123 OID = 1.3.6.1.2.1.2.2.1.1.123). Но как нам получить индексы интерфейсов? Они совсем не обязательно идут по порядку! Например, на моей машине, таблица интерфейсов выглядит так:

Именно для этой цели был придуман запрос GETNEXT. Передавая в этот запрос префикс OID-а, мы получаем OID и значение следующей (в лексикографическом порядке) за этим префиксом переменной. Это означает, что передав префиксы OID-ов столбцов таблицы, мы получим OID-ы и значения первой ее строки.

Разумеется, с учетом всего сказанного выше, нам следует минимизировать количество запросов (это также необходимо с учетом того, что в рамках одного запроса, согласно RFC, предоставляются консистентные данные, если мы запросим индекс и имя интерфейса двумя последовательными запросами, они возможно не будут соответствовать друг-другу). В рамках 1-ой версии SNMP, мы должны читать всю строку таблицы одним запросом.

Следует заметить, что довольно удобно то, что OID-ы скалярных переменных также представляют собой префиксы. Например, для переменной sysUpTime OID, на самом деле равен 1.3.6.1.2.1.1.3. Мы можем передать его в GETNEXT запрос и получить OID = 1.3.6.1.2.1.1.3.

Запустив этот код на выполнение, мы получим следующий response:

RESPONSE[requestID=1170688508, errorStatus=Success(0), errorIndex=0, VBS[1.3.6.1.2.1.1.3.0 = 4:50:53.72; 1.3.6.1.2.1.2.2.1.1.1 = 1; 1.3.6.1.2.1.2.2.1.2.1 = 4d:53:20:54:43:50:20:4c:6f:6f:70:62:61:63:6b:20:69:6e:74:65:72:66:61:63:65:00]]

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

С учетом необходимости поддержки возможности асинхронной обработки, это может стать нетривиальной (но вполне решаемой) задачей. К счастью, во 2-ой версии SNMP были добавлены bulk-запросы, автоматизирующие получение табличных данных и минимизирующие количество отсылаемых при этом запросов. Внесем необходимые изменения в код:

Выполнив этот запрос, мы получаем все строки таблицы одним запросом:

Разумеется, если таблица содержит более затребованных 50-ти строк, вновь (как и для 1-ой версии SNMP) потребуется формировать запросы для получения последующих строк, передавая в них OID-ыполученные для последней строки.

Идем на рекорд

Что с этим можно сделать? Если бы мы имели дело с каким либо синхронным протоколом (например telnet), особого выбора бы у нас не было. Для того, чтобы увеличить производительность, нам пришлось бы одновременно выполнять много потоков. Но SNMP асинхронен по своей природе! Не надо насильственно втискивать его в синхронные рамки.

Как перейти к асинхронному варианту? В нашем случае, довольно просто:

7142

Запросы все равно что проваливаются в бездонную бочку! Разумеется, ответы будут приходить с задержкой, но приходить они будут тоже довольно быстро. Но как мы узнаем, что хост не ответил?

Очень просто, по истечении заданного количества попыток и таймаутов, SNMP4J вернет нам event, response в котором будет равен null:

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

9174
283

Мы успеваем сформировать 9174 запросов в секунду, а опрашиваемое устройство успевает обрабатывать запросы со скоростью 283 запроса в секунду. На большую часть запросов оно ответить не успевает (соответственно в логе остаются сообщения «Timeout exceeded»).

Комплектация и гарантия

SNMP-адаптер NetAgentII и датчик NetFeelerII поставляются в небольших картонных коробках размером 185×145×60 мм. Оформление коробок выполнено в общем стиле упаковки компьютерных комплектующих, название устройства и его штрих-код нанесены с помощью наклейки. Информация о продукте на русском языке отсутствует.

Комплект поставки NetAgentII:

• руководство пользователя на английском, китайском, немецком, португальском и испанском языках
• кабель RJ-45↔RS-232 для подключения внешнего модема
• CD с программным обеспечением NetAgent Utility

Комплект поставки NetFeelerII:

• руководство пользователя на английском языке
• кабель RJ-45 для подключения к NetAgentII

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

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

Локализация устройства

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

В разделе Состояние системы, графа Тип соединения — неверная кодировка.

В разделе Лог данных, заголовки колонок данных — неверная кодировка.

В разделе Лог событий, в поле данных События — неверная кодировка. В остальном качество перевода можно оценить как удовлетворительное. Представитель компании Powercom заверил, что работы по устранению ошибок в локализованной версии микропрограммы ведутся. Выход новой версии микропрограммного обеспечения 2.45 запланирован на апрель 2021 года.

О чем я не рассказал?

В этой статье я не рассказал о многом. Я не рассказал о том, как изменять значения некоторых (не всех) переменных SET-запросами. Я не рассказал о том, что такое TRAP-ы и для чего они нужны. Я ни сказал ни слова о том, как разрабатывать SNMP-агенты. И я ни одним словом не обмолвился о 3-ей версии SNMP и привнесенных ей изменениях.

Но даже того о чем я сказал вполне достаточно, чтобы понять, что SNMP — это не просто.

При серьезном подходе к вопросу.

Первые шаги

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

1. Опрос оборудования по SNMP (аккаунтинг, мониторинг)
2. Управление оборудованием по SNMP (активация)

Задачи, связанные с опросом оборудования сводятся к формированию GET (и как будет показано далее GETNEXT) запросов. Управление оборудованием сводится к отсылке SET-запросов, изменяющих состояние соответствующих переменных на оборудовании (например, таким образом, можно отключить какой либо интерфейс).

Задача SNMP-мониторинга выделяется на общем фоне требованием того, что опрашиваемого оборудования много или очень много. Предположим, что именно эту задачу нам и предстоит решать.

Начнем писать код. В тестовом примере мы обратимся по SNMP к собственному хосту и прочитаем значение переменной, заданной OID-ом 1.3.6.1.2.1.1.3.0 и содержащей значение uptime-а хоста:

Предварительно убедившись, что служба SNMP на нашем хосте работает и запустив код на выполнение, получим искомое значение uptime-а (времени безостановочной работы хоста с момента последней загрузки):

1.3.6.1.2.1.1.3.0 = 2:28:55.06

Используя это значение, можно осуществлять мониторинг. Если мы обнаруживаем, что значением уменьшилось — значит хост успел перезагрузиться с момента очередного опроса. Если хост не ответил в течение заданного таймаута (после нескольких автоматически сделанных попыток) это, скорее всего, означает, что хост не работает. Все просто?

Подсчитали — прослезились

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

	private void test() throws IOException {
		Target t = getTarget("udp:127.0.0.1/161");
		Long timestamp = System.currentTimeMillis();
		for (int i = 0; i < 1000; i  ) {
			send(t, "1.3.6.1.2.1.1.3.0");
		}
		System.out.println(1000000L /(System.currentTimeMillis() - timestamp));
	}

И запустим его на выполнение:

2463

Почти две с половиной тысячи запросов в секунду! Неплохо?

Не будем торопиться. Мы отправляем запросы на Loopback интерфейс, а он работает несколько быстрее локальной сети. Посмотрим, сколько запросов в секунду мы успеем выполнить к другому хосту в нашей сети:

182

Не дотягиваем даже до двухсот. Вообще говоря, возможно, этого будет достаточно. Все зависит от задачи. Но мы проводили измерения при условии, что опрашиваемый хост доступен. Что будет если хост не ответит?

Будет несколько попыток доступа (в нашем коде мы задали 3) разделенных таймаутом (1000 мсек). Это означает, что за секунду мы не успеем выполнить ни одного запроса. Поскольку не отвечающий хост является не такой уж большой редкостью, это может стать большой проблемой в реальном проекте.

Установка и подключение

Для тестирования SNMP-адаптера и датчика состояния окружающей среды мы использовали ИБП SKP-1500A производства компании Powercom.

Плата адаптера вставляется на свое место по направляющим. К сожалению, высота направляющих, а возможно и ширина платы, способствовали выпадению платы, так что для ее установки в отсек требуется некоторая сноровка. Адаптер надежно фиксируется в отсеке двумя винтами.

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

Читаем документацию

Для начала я хотел бы остановиться на том, что мне не совсем понятно, почему из всего многообразия SNMP-запросов автор остановился на TRAP-ах? Посмотрим, что пишет по этому поводу

The strategy implicit in the SNMP is that the monitoring of network state at any significant level of detail is accomplished primarily by polling for appropriate information on the part of the monitoring center(s). A limited number of unsolicited messages (traps) guide the timing and focus of the polling. Limiting the number of unsolicited messages is consistent with the goal of simplicity and
minimizing the amount of traffic generated by the network management function.

Для тех, у кого сложности с английским языком, имеется

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

Из этих цитат, вполне понятно, что запросы с типами TRAP и INFORM это не наиболее часто используемая часть SNMP. Статью для начинающих было бы более уместно иллюстрировать примерами использования гораздо более ходовых GET-запросов.

Вообще я настоятельно рекомендую ознакомиться со всеми RFC, связанными с SNMP перед началом работы. Некоторые аспекты SNMP не очевидны и имеет смысл получить о них представление из первоисточника. Начать ознакомление с материалом можно с wiki.

Шаг 1: добавляем mib-файлы

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

Модуль SNMP нашей системы AggreGate Network Manager при старте загружает все MIB-файлы, находящиеся в специальной папке сервера, после чего позволяет добавлять новые при помощи простого диалога:

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

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

Шаг 2: подключаем snmp-устройство

В случае построения классической системы мониторинга этот шаг обычно не требуется, так как все устройства добавляются в систему автоматически во время периодического обнаружения устройств (network discovery). Тем не менее, во время добавления обнаруженных сканированием сети устройств выполняются примерно те же шаги:

1. Выбор типа устройства. В нашем случае подходит либо SNMP, либо Network Host, которые поддерживает Ping, SNMP, WMI, и другие типовые протоколы мониторинга ИТ.
2. Указание адреса и настроек коммуникаций. Имеется в виду версия протокола, SNMP Communities, таймауты и количество повторов, настройки SNMP v3 и т.п.
3. Выбор активов, то есть MIB-файлов. Network Manager автоматически обнаруживает, какие MIB-ы поддерживаются устройством, о чем мы писали в отдельной статье. Остается только выбрать, по каким MIB-ам будет идти опрос, причем MIB-ы по которым имеется «коробочная» аналитика и визуализация уже выбраны по-умолчанию.

Шаг 3: изучаем снимок устройства

После завершения этапа подключения устройства системе требуется от нескольких секунд до нескольких минут на завершение опроса устройства в рамках выбранных MIB-ов. Когда пиктограмма устройства становится зеленой, можно открывать и изучать так называемый «снимок устройства»:

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

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

Чтобы посмотреть подробное описание любой метрики или таблицы, содержащееся в MIB-файле, достаточно навести мышкой на описание или значение метрики. Во всплывающей подсказке также виден тип данных SNMP и полный OID:

Если метрика может принимать одно из нескольких числовых значений, описанных в MIB-файле текстовыми константами, в снимке устройства сразу показывается соответствующая текущему значению константа. Полный список констант и их числовых значений доступен через контекстное меню:

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

Но наибольшую пользу наш метод работы с данными SNMP приносит при обработке таблиц. Каждая SNMP-таблица показывается в снимке устройств как отдельная метрика табличного типа:

Шаг 4: настраиваем периоды опроса и сроки хранения

AggreGate Network Manager является

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

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

В диалоге настроек хранения показывается только срок хранения «сырых» данных в обычной базе данных (реляционной или NoSQL, в зависимости от настроек сервера). В большинстве случаев данные SNMP хранятся в кольцевой базе данных (Round-Robin Database, RRD), которая встроена в платформу AggreGate.

Шаг 5: переходим к обработке и визуализации данных

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

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

Вывод

SNMP-адаптер NetAgentII является хорошим дополнением к соответствующим ИБП компании Powercom и не только. Благодаря поддержке большого количества интерфейсов, адаптер может быть установлен в практически любой ИБП, имеющий отсек для установки SNMP-адаптера.

Датчик состояния окружающей среды NetFeelerII является устройством, расширяющим возможности адаптера NetAgentII по мониторингу окружающей среды, а в ряде случаев способен заменить отдельную пожарно-охранную систему. Точность датчика не позволяет использовать его как лабораторный измерительный прибор, но она вполне сравнима с бытовым электронным термометром и гигрометром.

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