Snmp client mac os

How do I activate SNMP on macOS to monitor it with PRTG?

I would like to monitor my machine that is running on macOS with the SNMP sensors of PRTG. How do I activate SNMP on macOS so that PRTG can query values for disk free, load average, and others via SNMP?

Last change on Oct 4, 2019 7:46:37 AM by Maike Guba [Paessler Support]

This article applies to PRTG Network Monitor 19 or later

Activate SNMP on macOS and Monitor with PRTG

Current macOS versions include SNMP by default. There is a basic setup assistant that you can use to configure SNMP on your macOS machine.

Step 1: Back Up the snmpd.conf File

On your macOS machine, open the Terminal app, locate the snmpd.conf file under /etc/snmp/snmpd.conf, and save a backup copy. You can use the following command:

Step 2: Adapt the snmpd.conf File

In the Terminal, enter the following command to start the setup assistant:

Follow the setup questions to configure SNMP to your needs.

Note: We recommend that you explicitly configure read-only access for SNMP v1 and SNMP v2c. This is because the default configuration value for the SNMP community string is public and therefore access is not secured.

Step 3: Start the SNMP Daemon

To start the SNMP daemon, use the following command:

Step 4: Create SNMP Sensors

In PRTG, create a new device that represents your macOS machine using the respective IP address or DNS name.

• For this new device, run an auto-discovery to let PRTG automatically create some SNMP sensors.
• You can manually add further SNMP sensors. Not all measurements will be available via SNMP, but you should be able to create the following sensor types:
  • SNMP Traffic sensor to monitor traffic on the network cards
  • SNMP Linux Load Average sensor (this sensor works although it is intended for Linux operating systems)
  • SNMP System Uptime sensor to monitor how long the system has been running
  • SNMP Disk Free sensor to monitor free disk space
  • SNMP CPU Load sensor to monitor the load of each CPU
• The auto-discovery might also find several generic SNMP values such as Internet Control Message Protocol (ICMP) errors or User Datagram Protocol (UDP) datagrams.

Step 5: Add the SNMP Daemon to Automatic Startup

Because you manually started the SNMP daemon in Step 3, the daemon will not run after you restart your macOS system.

Best practice is to automatically start the SNMP daemon at system startup. To add your SNMP daemon to automatic startup, you can edit the file /etc/hostconfig.

In the file, locate the line APPLETALK_HOSTNAME and add the following entry before APPLETALK_HOSTNAME: SNMPSERVER:=-YES-

Источник

MIB Browser — SNMP Monitoring 4+

Aribada Inc.

Снимки экрана

Описание

MIBBrowser is a tool which provides SNMP monitoring information via GUI, so you can browse SNMP information with it.

Main features of MIBBrowser are:

— SNMPWalk (SNMPv1/v2)
— Concurrent fetching and browsing with multi-tab and multi-window
— Filtering by keyword
— Support row-sorted view in case of Table type
— Save result as Text and CSV
— Printing
— Copying selected entries to clipboard
— Launching app with «snmp://» URL scheme
— Managing private MIB files
— Configuring Root OID for SNMPWalk

Что нового

— support for M1-powered Macs
— SNMP server connection setting enhancement
— Native tab UI support
— bug fix

Оценки и отзывы

Very bad!

Это точно не миб браузер! Своих денег не стоит!

работает, не слишком удобна

плюсы: работает, позволяет вставлять свои mib’ы, быстрая.
минусы: не умеет рисовать таблицы как таблицы, не показывает help из mib’a и вообще очень базовая такая.
баги: иногда значения отображаются только в дереве слева, а справа при навигации туда пустота

в общем, визуальный snmpwalk (ну, или нативный tkmib), не без глюков

good: works, fast, supports custom mibs
bad: no tables support (‘by row’/’by column’ is a joke), no MIB help section display
bugs: sometimes fetched values and their count are displayed only in MIB tree at the left w/o details display on the right pane

Конфиденциальность приложения

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

Сбор данных не ведется

Разработчик не ведет сбор данных в этом приложении.

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

Источник

SNMP MIBs и как их готовить

Доброго времени суток, читатель.

Предыстория

Установка MIBs

Стандартные

MIBs обычно распространяются в виде архива с пачкой файлов. Многие из них, составленные в iana и ietf, повторяются в каждом архиве, но передаются для совместимости.
Для работы в системе по умолчанию (конкретно для Debian) они должны лежать примерно в /usr/share/mibs
Для начала установим стандартные mibs в систему.

В файле конфигурации /etc/snmp/snmp.conf включить нужные. Пример:

mibs :ALL включает все, что не совсем хорошо. Рекомендую для каждого оборудования иметь папку с mib’ами, т.к. они могут отличаться из одной прошивки к другой.

Частный случай

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

Программное обеспечение

D-View

Net-SNMP

Возвращаюсь к тому, с чего начинал пост:
Мы скачали архив с MIBs и будем использовать утилиту snmptranslate из пакета Net-SNMP. Для удобства складываем все mibs в одну директорию, но это все равно не хватает:

Чтобы долго не мучатся скопируем недостающие файлы из mibs коммутатора des-3200 с опцией не перезаписывать существующие. И здесь мы уже получаем положительный результат:

UPD: Можно не копировать файлы, а указывать директории локальную и стандартные из системы -M ./:/usr/share/mibs/ietf:/usr/share/mibs/iana (для удобства можно делать alias в шелле)

О флагах:

• -M Указывает на директорию, где искать mibs (можно перечислять, разделяя символом «:»)
  Таким образом можно было не складывать все MIBS в одну директорию, но тогда нужно с флагом -M указать все каталоги из первоначального архива.
• -m Указывает какой модуль активируем (можно перечислять, разделяя символом «:»)
  Без указания модуля будут использоваться те, которые прописаны в /etc/snmp/snmp.conf
  % snmptranslate -m ./ -Ln 1.3.6.1.4.1.171.11.117.1.3.2.100.1.2.0.1
  RFC1155-SMI::enterprises.171.11.117.1.3.2.100.1.2.0.1
• -Ln Избавляет нас от бесконечной портянки ошибок в иерархии mibs. Точнее -Ln отключает errors в stdout

Теперь, когда трансляция работает, можно вкусить всю прелесть иерархии OIDs. Для этого есть флаги:

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

Можно просканировать все mibs и увидеть, что swL2macNotifyInfo есть и на других коммутаторах

Подводные камни D-Link

Еще есть особенность в mibs для 3200, что в них присутствует Object Name loop_detect. Символ «_» в net-snmp не поддерживается, так что для профилактики делаем: % sed -i ‘s/_/-/’ * в директории с mibs. Ошибку об этом символе можно увидеть, если вернуть вывод ошибок (убрать ключ -Ln):

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

UPD: Можно использовать флаг -P u (-P MIBOPTS Toggle various defaults controlling mib parsing: u: allow the use of underlines in MIB symbols)

Нужно заметить, что я указал конкретный MIB, в котором искать (остальные «подтянутся» из директории ./). В этом случае не возникает ошибок, ну и скорость работы выше.

Если не указать конкретный MIB, то получим ошибки в других mibs

Еще пример

Здесь мы видим тот mib, который ранее использовали в ключе -m DES3200-10-L2MGMT-MIB
SNMPv2-MIB::sysORID.49 = OID: DES3200-10-L2MGMT-MIB::swL2MgmtMIB

Еще бонус в виде команды snmptable

Итого

В данный момент, я перевожу OID SNMP Traps с коммутаторов в понятный для оператора формат. Это послужит основой для системы регистрации событий на оборудовании. Использовать MIBs в приложении мы не собираемся по причине непереносимости и не универсальности. Думаю подавляющее большинство библиотек используют для трансляции OID системные базы MIBs и конфиг /etc/snmp/snmp.conf (их использует Net-SNMP, а библиотека обращется к последнему), а глобально включать эти модули MIBs мы не хотим. Эти данные можно использовать для экспериментов и добиться более универсального варианта по использованию MIBs, но для меня этого достаточно.

UPD:
Полезные ключи:
-TB ищет в MIBs Object Name по regexp
-On выводит Object ID
Примеры:

Источник

SNMP MIBs и как их готовить

Доброго времени суток, читатель.

Предыстория

Установка MIBs

Стандартные

MIBs обычно распространяются в виде архива с пачкой файлов. Многие из них, составленные в iana и ietf, повторяются в каждом архиве, но передаются для совместимости.
Для работы в системе по умолчанию (конкретно для Debian) они должны лежать примерно в /usr/share/mibs
Для начала установим стандартные mibs в систему.

В файле конфигурации /etc/snmp/snmp.conf включить нужные. Пример:

mibs :ALL включает все, что не совсем хорошо. Рекомендую для каждого оборудования иметь папку с mib’ами, т.к. они могут отличаться из одной прошивки к другой.

Частный случай

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

Программное обеспечение

D-View

Net-SNMP

Возвращаюсь к тому, с чего начинал пост:
Мы скачали архив с MIBs и будем использовать утилиту snmptranslate из пакета Net-SNMP. Для удобства складываем все mibs в одну директорию, но это все равно не хватает:

Чтобы долго не мучатся скопируем недостающие файлы из mibs коммутатора des-3200 с опцией не перезаписывать существующие. И здесь мы уже получаем положительный результат:

UPD: Можно не копировать файлы, а указывать директории локальную и стандартные из системы -M ./:/usr/share/mibs/ietf:/usr/share/mibs/iana (для удобства можно делать alias в шелле)

О флагах:

• -M Указывает на директорию, где искать mibs (можно перечислять, разделяя символом «:»)
  Таким образом можно было не складывать все MIBS в одну директорию, но тогда нужно с флагом -M указать все каталоги из первоначального архива.
• -m Указывает какой модуль активируем (можно перечислять, разделяя символом «:»)
  Без указания модуля будут использоваться те, которые прописаны в /etc/snmp/snmp.conf
  % snmptranslate -m ./ -Ln 1.3.6.1.4.1.171.11.117.1.3.2.100.1.2.0.1
  RFC1155-SMI::enterprises.171.11.117.1.3.2.100.1.2.0.1
• -Ln Избавляет нас от бесконечной портянки ошибок в иерархии mibs. Точнее -Ln отключает errors в stdout

Теперь, когда трансляция работает, можно вкусить всю прелесть иерархии OIDs. Для этого есть флаги:

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

Можно просканировать все mibs и увидеть, что swL2macNotifyInfo есть и на других коммутаторах

Подводные камни D-Link

Еще есть особенность в mibs для 3200, что в них присутствует Object Name loop_detect. Символ «_» в net-snmp не поддерживается, так что для профилактики делаем: % sed -i ‘s/_/-/’ * в директории с mibs. Ошибку об этом символе можно увидеть, если вернуть вывод ошибок (убрать ключ -Ln):

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

UPD: Можно использовать флаг -P u (-P MIBOPTS Toggle various defaults controlling mib parsing: u: allow the use of underlines in MIB symbols)

Нужно заметить, что я указал конкретный MIB, в котором искать (остальные «подтянутся» из директории ./). В этом случае не возникает ошибок, ну и скорость работы выше.

Если не указать конкретный MIB, то получим ошибки в других mibs

Еще пример

Здесь мы видим тот mib, который ранее использовали в ключе -m DES3200-10-L2MGMT-MIB
SNMPv2-MIB::sysORID.49 = OID: DES3200-10-L2MGMT-MIB::swL2MgmtMIB

Еще бонус в виде команды snmptable

Итого

В данный момент, я перевожу OID SNMP Traps с коммутаторов в понятный для оператора формат. Это послужит основой для системы регистрации событий на оборудовании. Использовать MIBs в приложении мы не собираемся по причине непереносимости и не универсальности. Думаю подавляющее большинство библиотек используют для трансляции OID системные базы MIBs и конфиг /etc/snmp/snmp.conf (их использует Net-SNMP, а библиотека обращется к последнему), а глобально включать эти модули MIBs мы не хотим. Эти данные можно использовать для экспериментов и добиться более универсального варианта по использованию MIBs, но для меня этого достаточно.

UPD:
Полезные ключи:
-TB ищет в MIBs Object Name по regexp
-On выводит Object ID
Примеры:

Источник

Пытаемся сделать мониторинг по SNMP действительно простым

Уже немало написано о том, что в названии Simple Network Management Protocol слово Simple можно смело писать в кавычках. Протокол SNMP является достаточно простым с точки зрения создания SNMP-агентов, однако на стороне управляющего ПО (SNMP manager) грамотная обработка сложных по структуре данных обычно является нетривиальной задачей.

Мы попытались упростить процесс настройки сбора данных и событий SNMP и позволить пользователям во время этого процесса:

• Никогда не заглядывать внутрь MIB-файлов
• Не знать, что такое OID-ы и никогда не оперировать с ними
• Не пользоваться отдельной SNMP-утилитой для предварительного просмотра данных во время настройки

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

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

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

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

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

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

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

Выбор активов, то есть MIB-файлов. Network Manager автоматически обнаруживает, какие MIB-ы поддерживаются устройством, о чем мы писали в отдельной статье. Остается только выбрать, по каким MIB-ам будет идти опрос, причем MIB-ы по которым имеется «коробочная» аналитика и визуализация уже выбраны по-умолчанию.

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

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

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

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

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

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

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

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

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

При наведении на заголовок столбца во всплывающей подсказке видно описание поля, полученное из MIB-файла, а также его тип и OID:

Если имеется несколько связанных друг с другом таблиц, например использующих внешние индексы или расширение (augmentation), система автоматически обрабатывает все внутренние связи и сводит данные связанных таблиц в одно целое. В большинстве случаев пользователи даже не подозревают о существовании таких сложностей. Вот, например, как выглядит таблица hrSWRunPerfTable:

На уровне MIB файла эта таблица представляет из себя два столбца (hrSWRunPerfCPU и hrSWRunPerfMem), расширяющие таблицу hrSWRunTable. В снимке устройства эти таблицы уже объединены, что облегчает анализ данных, построение отчетности и диаграмм, настройку хранения и т.д.

Поскольку единая модель данных платформы AggreGate ориентирована на работу с таблицами, таблицы данных SNMP являются идеальным кандидатом на обработку встроенными средствами. При помощи них реализуется построение топологии L2/L3, анализ данных MPLS TE и MPLS VPN, мониторинг и создание тестов IP SLA, а также сотни более простых задач.

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

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

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

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

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

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

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

В результате

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

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

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

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

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

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

Источник