Форма сообщение snmp. Пытаемся сделать мониторинг по SNMP действительно простым. Пакет SNMP от Castle Rock Computing

Расшифровать аббревиатуру SNMP можно как Simple Network Management Protocol, то есть «простой протокол сетевого управления». Этот стандарт является одним из самых часто встречающихся при управлении устройствами в сети. В большинстве случаев этот протокол может быть использован в случаях, когда требуется контролировать исполнение на устройствах подключенных к сети заданных администратором требований. Данные, которые входят в обмен в рамках SNMP представляются в виде переменных . Благодаря им появляется возможность описания настройки управляемого объекта. Благодаря управляющим приложениям могут подаваться запросы, а в некоторых случаях и указываться переменные.

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

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

Основные составляющие SNMP

Самые распространенные составляющие:

• подчиненный объект – объект, на который отправляются разнообразные команды;
• MIB database;
• управляющая программа;
• подчиненная программа (агент);
• система, которая обеспечивает взаимодействия в сети.

Информация из объекта будет отправляться на управляющую программу, которая будет интерпретировать ее по заданным алгоритмам. На подчиненном устройстве существует программа агент, предназначенная для организации сбора информации по определенному устройству. Если нужно – программа (ПО) может транслировать эту информацию в формате, адаптированном к особенностям SNMP.

Сама система обеспечения взаимодействия между объектами в сети позволяет администратору работать сразу со многими управляющими программами. Это дает возможность полностью контролировать функционирование инфраструктуры. В сетях могут быть установлены сразу несколько типов такого ПО.

Самым важным элементом считается база управляющих сведений “MIB”. Этот элемент нужен для того, чтобы описать структуру базы данных (БД), что необходимо при обмене информацией в ходе администрирования девайсов. Такая БД дает возможность сохранить данные о компонентах, которые активируются на устройстве для управления им.

Главной составляющей базы являются идентификаторы типа OID, которые позволяют задавать переменные, определяемые и считываемые благодаря SMNP.

Возможности управляющих программ

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

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

Существуют подобные программы, которые адаптированы к использованию на ОС Windows и Solaris. Рассмотрим некоторые из них.

Пакет SNMP от Castle Rock Computing

Это безопасная система сетевого управления, обеспечивающая постоянное наблюдение для всей сети.

Основные характеристики продукта :

• мониторинг устройств, WAN-соединений, серверов и приложений;
• поддержка интернет-протокола версии 6 (IPv6);
• поддержка SNMP v1, v2c и защищенной версии v3;
• масштабируемая и распределяемая архитектура;
• поддержка интеграции с сетевыми отчетами SNMPc OnLine;
• основные/резервные серверы с автоматической отказоустойчивостью;
• регистрация событий в Syslog;
• удаленная консоль Windows;
• автоматическое обнаружение сети;
• среда для программирования и написания скриптов.

Интерфейс программы:

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

Характеристики:

Утилита для исследования и мониторинга предназначенная для агентских систем. Она предоставлена в стиле проводника в MIB, который открыт на агенте. Имеет самый простой интерфейс из всех представленных, но также и самая сложная в использовании.

Программа позволяет:

Особенности работы базы данных MIB

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

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

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

Что такое OID

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

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

Что такое ловушка SNMP

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

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

В службах Windows также существует служба с названием “Служба ловушек SNMP”, выполняющая те же функции. На компьютерах, которые не подключены к локальной сети она не используется, но обычно включена. Для ее отключения необходимо зайти в “Пуск – Панель Управления – Администрирование – Службы” и в открывшемся списке найти указанную службу. Кликнуть по ней правой кнопкой мыши (ПКМ), далее “Свойства ”, затем сменить “Тип запуска” на “Отключена”.

Инсталляция и конфигурирование SNMP

Инсталляция службы

Необходимо сделать следующее:

1. Перейти по пути «Пуск» – «Панель управления »;
2. Далее «Установка и удаление программ»;
3. Найти в левой части окна пункт: «Установка компонентов Windows » и выбрать его;
4. Далее, пункт «Средства управления и наблюдения» , выбрать его и нажать “Состав”;
5. Выбрать «Протокол SNMP»;
6. Нажатиями по кнопкам «ОК» и «Далее» закончить инсталляцию.

Затем перейти к службам Windows и проделать следующее:

• включить “Служба SNMP ”, это нужно для включения агента;
• запустить “Служба ловушек SNMP ” для получения сообщений.

Конфигурация агента

Для настройки агента в Windows:

• нажать «Пуск» – «Выполнить» – ввести «services.msc » и нажать кнопку «Enter» на клавиатуре. В результате откроется консоль управления службами;
• в правой части выбрать «Служба SNMP» кликнуть по нему ПКМ, затем «Свойства»;
• перейти к пункту «Агент SNMP». Ввести название и расположение сервера, а также выбрать события, о которых нужно сообщать серверу (если нужно);
• перейти в «Ловушки» и ввести название группы и имена получателей сообщений-ловушек (если нужно);
• в «Безопасность » выбрать нужный уровень безопасности для серверов;
• нажать на кнопку «Применить» и далее «ОК»;
• щелкнуть правой кнопкой мыши по службе и выбрать пункт «Перезапустить » для применения изменений.

Процесс настройки завершен.

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

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

Первые шаги

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

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

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

Одиночный GET-запрос

package com.acme.ae.tests.snmp; import java.io.IOException; import org.snmp4j.CommunityTarget; import org.snmp4j.PDU; import org.snmp4j.Snmp; import org.snmp4j.Target; import org.snmp4j.TransportMapping; import org.snmp4j.event.ResponseEvent; import org.snmp4j.mp.SnmpConstants; import org.snmp4j.smi.Address; import org.snmp4j.smi.GenericAddress; import org.snmp4j.smi.OID; import org.snmp4j.smi.OctetString; import org.snmp4j.smi.VariableBinding; import org.snmp4j.transport.DefaultUdpTransportMapping; public class Test { private final static String SNMP_COMMUNITY = "public"; private final static int SNMP_RETRIES = 3; private final static long SNMP_TIMEOUT = 1000L; private Snmp snmp = null; private TransportMapping transport = null; private void test() throws IOException { Target t = getTarget("udp:127.0.0.1/161"); String r = send(t, "1.3.6.1.2.1.1.3.0"); System.out.println(r); } private String send(Target target, String oid) throws IOException { PDU pdu = new PDU(); pdu.add(new VariableBinding(new OID(oid))); pdu.setType(PDU.GET); ResponseEvent event = snmp.send(pdu, target, null); if (event != null) { return event.getResponse().get(0).toString(); } else { return "Timeout exceeded"; } } private Target getTarget(String address) { Address targetAddress = GenericAddress.parse(address); CommunityTarget target = new CommunityTarget(); target.setCommunity(new OctetString(SNMP_COMMUNITY)); target.setAddress(targetAddress); target.setRetries(SNMP_RETRIES); target.setTimeout(SNMP_TIMEOUT); target.setVersion(SnmpConstants.version1); return target; } private void start() throws IOException { transport = new DefaultUdpTransportMapping(); snmp = new Snmp(transport); transport.listen(); } private void stop() throws IOException { try { if (transport != null) { transport.close(); transport = null; } } finally { if (snmp != null) { snmp.close(); snmp = null; } } } public static void main(String args) { Test t = new Test(); try { try { t.start(); t.test(); } finally { t.stop(); } } catch (IOException e) { System.out.println(e.toString()); } } }

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 мсек). Это означает, что за секунду мы не успеем выполнить ни одного запроса. Поскольку не отвечающий хост является не такой уж большой редкостью, это может стать большой проблемой в реальном проекте.

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

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

Асинхронные запросы

package com.acme.ae.tests.snmp; import java.io.IOException; import org.snmp4j.CommunityTarget; import org.snmp4j.PDU; import org.snmp4j.Snmp; import org.snmp4j.Target; import org.snmp4j.TransportMapping; import org.snmp4j.event.ResponseEvent; import org.snmp4j.event.ResponseListener; import org.snmp4j.mp.SnmpConstants; import org.snmp4j.smi.Address; import org.snmp4j.smi.GenericAddress; import org.snmp4j.smi.OID; import org.snmp4j.smi.OctetString; import org.snmp4j.smi.VariableBinding; import org.snmp4j.transport.DefaultUdpTransportMapping; public class Test implements ResponseListener { private final static String SNMP_COMMUNITY = "public"; private final static int SNMP_RETRIES = 3; private final static long SNMP_TIMEOUT = 1000L; private Snmp snmp = null; private TransportMapping transport = null; public void onResponse(ResponseEvent event) { PDU response = event.getResponse(); if (response != null) { System.out.println(response.get(0).toString()); return; } } private void test() throws IOException { Target t = getTarget("udp:192.168.131.253/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)); } private void send(Target target, String oid) throws IOException { PDU pdu = new PDU(); pdu.add(new VariableBinding(new OID(oid))); pdu.setType(PDU.GET); snmp.send(pdu, target, null, this); } private Target getTarget(String address) { Address targetAddress = GenericAddress.parse(address); CommunityTarget target = new CommunityTarget(); target.setCommunity(new OctetString(SNMP_COMMUNITY)); target.setAddress(targetAddress); target.setRetries(SNMP_RETRIES); target.setTimeout(SNMP_TIMEOUT); target.setVersion(SnmpConstants.version1); return target; } private void start() throws IOException { transport = new DefaultUdpTransportMapping(); snmp = new Snmp(transport); transport.listen(); } private void stop() throws IOException { try { if (transport != null) { transport.close(); transport = null; } } finally { if (snmp != null) { snmp.close(); snmp = null; } } } public static void main(String args) { Test t = new Test(); try { try { t.start(); t.test(); } finally { t.stop(); } } catch (IOException e) { System.out.println(e.toString()); } } }

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

Исправленный вариант

requests = new HashSet(); private Long firstTimestamp = null; private long lastTimestamp; public void onResponse(ResponseEvent event) { Integer32 requestId = event.getRequest().getRequestID(); PDU response = event.getResponse(); if (response != null) { lastTimestamp = System.currentTimeMillis(); if (firstTimestamp == null) { firstTimestamp = lastTimestamp; } return; } else { synchronized (requests) { if (requests.contains(requestId)) { System.out.println("Timeout exceeded"); } } } synchronized (requests) { requests.remove(requestId); } } private void test() throws IOException { Target t = getTarget("udp:192.168.131.253/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)); while (!requests.isEmpty()) { try { Thread.sleep(1000L); } catch (InterruptedException e) { e.printStackTrace(); } } if (firstTimestamp != null) { System.out.println(1000000L /(lastTimestamp - firstTimestamp)); } } private void send(Target target, String oid) throws IOException { PDU pdu = new PDU(); pdu.add(new VariableBinding(new OID(oid))); pdu.setType(PDU.GET); snmp.send(pdu, target, null, this); synchronized (requests) { requests.add(pdu.getRequestID()); } } private Target getTarget(String address) { Address targetAddress = GenericAddress.parse(address); CommunityTarget target = new CommunityTarget(); target.setCommunity(new OctetString(SNMP_COMMUNITY)); target.setAddress(targetAddress); target.setRetries(SNMP_RETRIES); target.setTimeout(SNMP_TIMEOUT); target.setVersion(SnmpConstants.version1); return target; } private void start() throws IOException { transport = new DefaultUdpTransportMapping(); snmp = new Snmp(transport); transport.listen(); } private void stop() throws IOException { try { if (transport != null) { transport.close(); transport = null; } } finally { if (snmp != null) { snmp.close(); snmp = null; } } } public static void main(String args) { Test t = new Test(); try { try { t.start(); t.test(); } finally { t.stop(); } } catch (IOException e) { System.out.println(e.toString()); } } }

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

Идем далее

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

Просмотр первой строки таблицы

package com.acme.ae.tests.snmp; import java.io.IOException; import java.util.HashSet; import java.util.Set; import org.snmp4j.CommunityTarget; import org.snmp4j.PDU; import org.snmp4j.Snmp; import org.snmp4j.Target; import org.snmp4j.TransportMapping; import org.snmp4j.event.ResponseEvent; import org.snmp4j.event.ResponseListener; import org.snmp4j.mp.SnmpConstants; import org.snmp4j.smi.Address; import org.snmp4j.smi.GenericAddress; import org.snmp4j.smi.Integer32; import org.snmp4j.smi.OID; import org.snmp4j.smi.OctetString; import org.snmp4j.smi.VariableBinding; import org.snmp4j.transport.DefaultUdpTransportMapping; public class Test implements ResponseListener { private final static String SNMP_COMMUNITY = "public"; private final static int SNMP_RETRIES = 3; private final static long SNMP_TIMEOUT = 1000L; private Snmp snmp = null; private TransportMapping transport = null; private Set requests = new HashSet(); public void onResponse(ResponseEvent event) { Integer32 requestId = event.getRequest().getRequestID(); PDU response = event.getResponse(); if (response != null) { System.out.println(response.toString()); return; } else { synchronized (requests) { if (requests.contains(requestId)) { System.out.println("Timeout exceeded"); } } } synchronized (requests) { requests.remove(requestId); } } private void test() throws IOException { Target t = getTarget("udp:127.0.0.1/161"); send(t, new String {"1.3.6.1.2.1.1.3", "1.3.6.1.2.1.2.2.1.1", "1.3.6.1.2.1.2.2.1.2"}); } private void send(Target target, String oids) throws IOException { PDU pdu = new PDU(); for (String oid: oids) { pdu.add(new VariableBinding(new OID(oid))); } pdu.setType(PDU.GETNEXT); ResponseEvent event = snmp.send(pdu, target, null); synchronized (requests) { requests.add(pdu.getRequestID()); } onResponse(event); } private Target getTarget(String address) { Address targetAddress = GenericAddress.parse(address); CommunityTarget target = new CommunityTarget(); target.setCommunity(new OctetString(SNMP_COMMUNITY)); target.setAddress(targetAddress); target.setRetries(SNMP_RETRIES); target.setTimeout(SNMP_TIMEOUT); target.setVersion(SnmpConstants.version1); return target; } private void start() throws IOException { transport = new DefaultUdpTransportMapping(); snmp = new Snmp(transport); transport.listen(); } private void stop() throws IOException { try { if (transport != null) { transport.close(); transport = null; } } finally { if (snmp != null) { snmp.close(); snmp = null; } } } public static void main(String args) { Test t = new Test(); try { try { t.start(); t.test(); } finally { t.stop(); } } catch (IOException e) { System.out.println(e.toString()); } } }

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

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

BULK-запрос

package com.acme.ae.tests.snmp; import java.io.IOException; import java.util.HashSet; import java.util.Set; import org.snmp4j.CommunityTarget; import org.snmp4j.PDU; import org.snmp4j.Snmp; import org.snmp4j.Target; import org.snmp4j.TransportMapping; import org.snmp4j.event.ResponseEvent; import org.snmp4j.event.ResponseListener; import org.snmp4j.mp.SnmpConstants; import org.snmp4j.smi.Address; import org.snmp4j.smi.GenericAddress; import org.snmp4j.smi.Integer32; import org.snmp4j.smi.OID; import org.snmp4j.smi.OctetString; import org.snmp4j.smi.VariableBinding; import org.snmp4j.transport.DefaultUdpTransportMapping; public class Test implements ResponseListener { private final static String SNMP_COMMUNITY = "public"; private final static int SNMP_RETRIES = 3; private final static long SNMP_TIMEOUT = 1000L; private final static int BULK_SIZE = 50; private Snmp snmp = null; private TransportMapping transport = null; private Set requests = new HashSet(); public void onResponse(ResponseEvent event) { Integer32 requestId = event.getRequest().getRequestID(); PDU response = event.getResponse(); if (response != null) { System.out.println(response.toString()); return; } else { synchronized (requests) { if (requests.contains(requestId)) { System.out.println("Timeout exceeded"); } } } synchronized (requests) { requests.remove(requestId); } } private void test() throws IOException { Target t = getTarget("udp:127.0.0.1/161"); send(t, new String {"1.3.6.1.2.1.1.3", "1.3.6.1.2.1.2.2.1.1", "1.3.6.1.2.1.2.2.1.2"}); } private void send(Target target, String oids) throws IOException { PDU pdu = new PDU(); for (String oid: oids) { pdu.add(new VariableBinding(new OID(oid))); } pdu.setType(PDU.GETBULK); pdu.setMaxRepetitions(BULK_SIZE); pdu.setNonRepeaters(1); ResponseEvent event = snmp.send(pdu, target, null); synchronized (requests) { requests.add(pdu.getRequestID()); } onResponse(event); } private Target getTarget(String address) { Address targetAddress = GenericAddress.parse(address); CommunityTarget target = new CommunityTarget(); target.setCommunity(new OctetString(SNMP_COMMUNITY)); target.setAddress(targetAddress); target.setRetries(SNMP_RETRIES); target.setTimeout(SNMP_TIMEOUT); target.setVersion(SnmpConstants.version2c); return target; } private void start() throws IOException { transport = new DefaultUdpTransportMapping(); snmp = new Snmp(transport); transport.listen(); } private void stop() throws IOException { try { if (transport != null) { transport.close(); transport = null; } } finally { if (snmp != null) { snmp.close(); snmp = null; } } } public static void main(String args) { Test t = new Test(); try { try { t.start(); t.test(); } finally { t.stop(); } } catch (IOException e) { System.out.println(e.toString()); } } }

Много данных

RESPONSE]

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

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

Иваненко С.

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

Подобным языком стал SNMP - Simple Network Management Protocol. Разработанный для систем, ориентированных под операционную систему UNIX, он стал фактически общепринятым стандартом сетевых систем управления и поддерживается подавляющим большинством производителей сетевого оборудования в своих продуктах. В силу своего названия - Простой Протокол Сетевого Управления - основной задачей при его разработке было добиться максимальной простоты его реализации. В результате возник протокол, включающий минимальный набор команд, однако позволяющий выполнять практически весь спектр задач управления сетевыми устройствами - от получения информации о местонахождении конкретного устройства, до возможности производить его тестирование.

Основной концепцией протокола является то, что вся необходимая для управления устройством информация хранится на самом устройстве - будь то сервер, модем или маршрутизатор - в так называемой Административной Базе Данных (MIB - Management Information Base). MIB представляет из себя набор переменных, характеризующих состояние объекта управления. Эти переменные могут отражать такие параметры, как количество пакетов, обработанных устройством, состояние его интерфейсов, время функционирования устройства и т.п. Каждый производитель сетевого оборудования, помимо стандартных переменных, включает в MIB какие-либо параметры, специфичные для данного устройства. Однако, при этом не нарушается принцип представления и доступа к административной информации - все они будут переменными в MIB. Поэтому SNMP как непосредственно сетевой протокол предоставляет только набор команд для работы с переменными MIB. Этот набор включает следующие операции:

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

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

Как происходит адресация в MIB к некоторой ее переменной? По своей структуре MIB представляет из себя дерево, изображенное на рисунке 1.

Каждому элементу соответствует численный и символьный идентификатор. В имя переменной включается полный путь до нее от корневого элемента root. Например, время работы устройства с момента перезагрузки хранится в переменной, находящейся в разделе system под номером 3 и называется sysUpTime. Соответственно, имя переменной будет включать весь путь: iso(1).org(3).dod(6).internet(1).mgmt(2).mib-2(1).system(1).sysUpTime(3); или на языке чисел: 1.3.6.1.2.1.1.3. Следует заметить, что при этом узлы дерева разделяются точками. Существует стандартная ветвь MIB, относящаяся к разделу управления mgmt, которую обычно поддерживают все сетевые устройства.

Наряду с этим каждый производитель или организация может разработать свой собственный набор переменных и "подвесить" их к дереву MIB. Однако, это делается только в строго определенном ее месте. Если организация разрабатывает свою базу MIB, то на стадии экспериментов переменные могут помещаться в раздел experimental. Однако для официальной регистрации структуры данных некоторой организации ей необходимо получить собственный номер в разделе private-enterprises. Все переменные, адресуемые вниз по ветви данной организации, относятся к продуктам только данного производителя.

Как уже было сказано, каждое сетевое устройство содержит в себе информацию, необходимую для управления им. Эта информация некоторым образом размещена в регистрах устройства. Как же обеспечивается доступ к этой информации некоторой сетевой рабочей станции, выполняющей задачу управления сетью? Для обработки запросов управляющей станции, приходящих в виде SNMP пакетов, служит специальный модуль, называемый Агентом Управления. Агент принимает SNMP пакеты и выполняет соответствующие им действия, т.е. посылает значение запрашиваемой переменной, устанавливает значение переменных, выполняет периодическое обновление информации MIB, выполняет в ответ на установку соответствующих переменных некоторые операции. В роли Управляющей Станции может выступать рабочая станция администратора сети, если на ней запустить какой-либо пакет управления, поддерживающий протокол SNMP. Он позволяет администратору получать конкретную информацию о какой либо стороне функционирования элементов сети, например на уровне карты Ethernet, либо протокола EGP. Примерами таких программ можно назвать Sun NetManager фирмы Sun Microsystems, ориентированный на операционную систему Solaris, и пакет SNMPc фирмы Castle Rock Computing, разработанный для системы Windows. Оба пакета позволяют строить карту сети и работать непосредственно с MIB какого-либо ее узла. Имея подобное мощное средство, администратору сети достаточно открыть документацию по MIB конкретного устройства, например маршрутизатора cisco, и изучить возможности управления, заложенные в нее разработчиками. Так, например, чтобы управлять маршрутизатором cisco, можно войти на него (сделать login пользователем root) и получить on-line доступ к его командам управления. А можно сконфигурировать на данном маршрутизаторе SNMP агента и выполнять все те же команды и получать те же результаты путем работы с переменными его MIB. Как пример такой операции можно просто перегрузить маршрутизатор путем изменения одной переменной его MIB. При этом существуют отдельные команды для загрузки системы из flash-памяти, NVRAM, или TFTP файла.

При помощи SNMP можно выполнять различные тесты функциональных возможностей сетевых устройств, определенные опять же на самих устройствах. Это бывает полезно, поскольку просто наблюдение статистики зачастую не дает полной картины происходящего. Так, например, для раздела, относящегося к интерфейсам Ethernet, определен тест TDR (Time-domain reflectometry), позволяющий определять приблизительное расстояние до повреждения в коаксиальном кабеле. Для того, чтобы запустить TDR тест необходимо установить значение переменной ifExtnsTestTypе (1.3.6.1.2.1.12.2.1.4), содержащей тип выполняемого теста, так, чтобы она содержала идентификатор теста TDR в MIB: 1.3.6.1.2.1.10.7.6.1. Результатом теста будет, во-первых, значение переменной ifExtnsTestResult (1.3.6.1.2.1.12.2.1.5), характеризующей исход теста:

отсутствие результата

выполняется

не поддерживается

невозможно запустить

прекращен

неудачное завершение

И во-вторых, значение переменной ifExtnsTestCode (1.3.6.1.2.1.12.2.1.6) будет содержать идентификатор переменной MIB, содержащей результат теста. Результат теста определен как временной интервал в 100-наносекундных единицах между началом передачи тестового пакета и обнаружением коллизий в несущей. В принципе, на основании данного значения можно определить требуемое расстояние. Как уже было сказано, такого рода тесты поддерживаются различными производителями для своих продуктов и находят отражение в соответствующих переменных MIB.

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

Протокол SNMP (Simple Network Management Protocol, Простой протокол сетевого управления) - это протокол уровня 7 модели OSI, используемый для удаленного контроля и настройки сетевых устройств. SNMP позволяет станциям сетевого управления просматривать и изменять настройки шлюзов, маршрутизаторов, коммутаторов и других сетевых устройств. SNMP может быть использован для выполнения многих тех функций, которые выполнялись через непосредственно подключенную консоль, или может быть использован в рамках интегрированного программного обеспечения сетевого управления, такого как DView.
SNMP выполняет следующие функции:

Отправка и прием пакетов SNMP через протокол IP.

Сбор информации о статусе и текущей конфигурации сетевых устройств.

Изменение конфигурации сетевых устройств.

SNMP Версий 1,2 и 3
DES-3226S поддерживает SNMP версии 3, также как и версии 1 и 2. Главное отличие SNMP v.3 от SNMP v.1 и SNMP v.2 в том, что SNMP v.3 предоставляет в значительной степени более высокий уровень безопасности, чем предыдущие версии.
В SNMP v.1 и SNMP v.2 авторизация пользователя выполняется посредством "строки сообщества" - Community String, которая действуют как пароль. Удаленная пользовательская программа SNMP и агент SNMP должны использовать одни и те же Community Strings. Пакеты SNMP от любой станции, которая не была авторизована, игнорируются (отбрасываются).
SNMP v.3 используют более сложный процесс авторизации, который разделяется на две части. Первая часть используется для поддержания списка пользователей и их атрибутов, которым разрешено управлять по протоколу SNMP. Вторая часть описывает, что каждый пользователь из данного списка может делать при управлении по SNMP.
Коммутатор позволяет указывать и настраивать группы пользователей в данном списке с одинаковым набором привилегий. Для указанных групп может быть установлена версия SNMP. Таким образом, можно создать группу SNMP, которой разрешено просматривать информацию, предназначенную только для чтения, или получать сообщения traps, используя SNMP v.1, в то время как другой группе назначен более высокий уровень безопасности, предоставляющий привилегии чтения/записи, посредством SNMP v.3.
Используя SNMP v.3 можно позволить или запретить индивидуальным пользователям или группам SNMP-менеджеров выполнять конкретные функции SNMP-управления. Разрешенные или запрещенные функции определяются с помощью идентификатора объекта Object Identifier (OID), ассоциированного с конкретной MIB.
Кроме того, в SNMP v.3 доступен уровень безопасности, в котором SNMP-сообщения могут быть зашифрованы (при использовании уровней авторизации HMAC-SHA-96 или HMAC-MDA-96).

Traps
Traps - это сообщения, которые предупреждают о произошедших событиях при работе коммутатора. События могут быть как серьезными типа перезагрузки (кто-то случайно отключил питание коммутатора), так и менее серьезными типа изменения состояния порта. Коммутатор генерирует traps и посылает их станции сетевого управления.
Администраторами traps являются особые пользователи локальной сети, которым представляются некоторые права и доступ к просмотру и поддержке сети. Администраторы получают отправленные коммутатором traps и должны предпринять некоторые действия для предотвращения сбоев в будущем или отключения сети.
Вы можете определить станции управления, которые могут получать traps от коммутатора. Это можно сделать путем ввода списка IP-адресов авторизованных станций сетевого управления. Вы также можете указать версию SNMP, используемую для авторизации. Можно ввести до четырех IP-адресов администраторов traps и четыре соответствующих SNMP Сommunity strings.
Ниже приводятся типы сообщений traps, которые могут получать администраторы:

• Cold Start Данное сообщение означает, что коммутатор был включен и инициализирован так, что все программные настройки были восстановлены, а аппаратные компоненты были перезагружены. "Холодный" старт отличается сброса коммутатора к заводским установкам тем, что настройки сохраняются в энергонезависимой памяти, используемой для восстановления конфигурации коммутатора.
• Warm Start Данное сообщение означает, что коммутатор был перезагружен (только программно), но тест по самодиагностике при включении питания (Power-On Self-Test - POST) был пропущен.
• Authentication Failure Данное сообщение означает, что кто-то пытается подключиться к коммутатору, используя неверную "строку сообщества" SNMP - Community string. Коммутатор автоматически запоминает IP-адрес неавторизированного пользователя.
• Topology Change Сообщение Topology Change (изменение топологии) посылается коммутатором, когда любой из его сконфигурированных портов переходит из состояния Learning в Forwarding, или из состояния Forwarding в Blocking. Данный trap не генерируется, если при том же изменении состояния порта был послан new root trap.
• Link Change Event Данное сообщение посылается каждый раз, когда состояние порта меняется с link up на link down или с link down на link up.
• Port Partition Данное сообщение посылается каждый раз, когда состояние порта изменяется на partition (порт блокируется) в результате возникновения более чем 32 коллизий на нем при работе на скорости 10 МБит/с или более чем 64 коллизий при работе на скорости 100 МБит/с.
• Broadcast\Multicast Storm Данное сообщение посылается каждый раз, когда на порту преодолевается пороговое значение пакетов широковещательной/групповой рассылки. (количество пакетов в секунду), установленное глобально для коммутатора. На каждом порту поддерживаются раздельные счетчики для широковещательных пакетов и для пакетов групповой рассылки. Пороговое значение по умолчанию равно 128 тысяч пакетов/с как для широковещательной рассылки, и так и для групповой рассылки.

MIB
Управляющая информация и параметры коммутатора хранятся в информационной базе управления (Management Information Base -MIB). Коммутатор использует стандартный модуль информационной базы управления MIB-II. Следовательно, значения входящих в MIB объектов могут быть получены с помощью любых средств сетевого управления, основанных на SNMP. Кроме стандарта MIB-II, коммутатор также поддерживает собственную MIB в виде расширенной информационной базы управления. Объекты этой MIB также могут быть получены путем указания менеджером OID MIB (Object Identifier, идентификатор объекта MIB). Значения объектов MIB могут быть как открытыми только для чтения (read-only), так и для чтения и для записи (read-write).
Объекты read-only MIB могут быть константами, которые запрограммированы в коммутаторе, или переменными, которые изменяются в процессе работы коммутатора. Примерами констант read-only являются количество портов и их типы. Примерами переменных read-only являются статистические значения, такие как количество произошедших ошибок, или сколько Кбайт данных было получено и передано через порт.
Объекты read-write MIB обычно связаны с настройками, осуществляемыми пользователем. Например, ими являются IP-адрес коммутатора, параметры Spanning Tree Algorithm, состояние порта.
Если для управления коммутатором используется система управления SNMP третьих поставщиков, то по запросу можно получить дискету, содержащую MIB коммутатора. Если эта система предоставляет функции просмотра или модификации MIB, то можно получать параметры MIB и изменять их (если атрибуты MIB допустят операцию записи). Тем не менее, процесс получения объектов MIB может быть только последовательным, поскольку нужно знать OID MIB и получать объекты один за другим.

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

Шаг 1. (Обязательно) Настройте строку сообщества и уровень доступа («только чтение» или «чтение и запись») с помощью команды snmp-server community string ro | rw .

Шаг 2. (Дополнительно) Документально зафиксируйте местоположение устройства с помощью команды snmp-server location text .

Шаг 3. (Дополнительно) Документально зафиксируйте системный контакт с помощью команды snmp-server contact text .

Шаг 4. (Дополнительно) Ограничьте доступ по SNMP, разрешив его только узлам NMS (диспетчерам SNMP), которые разрешены списком контроля доступа: определите список контроля доступа, затем укажите ссылку на этот список контроля доступа с помощью команды snmp-server community string access-list-number-or-name . Эту команду можно использовать как для определения строки сообщества, так и для ограничения доступа SNMP с помощью списков контроля доступа. При желании шаги 1 и 4 можно объединить в один; сетевое устройство Cisco объединяет две команды в одну, если они вводятся по отдельности.

Шаг 5. (Дополнительно) Укажите получателя операций ловушки SNMP с помощью команды snmp-server host host-id [ version { 1 | 2c | 3 [ auth | noauth | priv ]}] community-string . По умолчанию диспетчеры ловушек не определены.

Шаг 6. (Дополнительно) Включите ловушки на агенте SNMP с помощью команды snmp-server enable traps notification-types . Если в этой команде не определены типы уведомлений-ловушек, отправляются все типы ловушек. Если требуется применить конкретные типы ловушек, необходимо повторное использование этой команды.

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

Проверка настройки SNMP

Существует несколько программных решений для просмотра выходных данных SNMP. В рамках нашего курса сервер Syslog Kiwi отображает сообщения SNMP, связанные с ловушками SNMP.

ПК 1 и R1 настроены для отображения выходных данных, связанных с ловушками SNMP, в диспетчере SNMP.

Как показано на рисунке 1, компьютеру ПК 1 назначен IP-адрес 192.168.1.3/24. Сервер Syslog Kiwi установлен на ПК 1.

После настройки маршрутизатора R1 при возникновении события, подходящего под определение ловушки, на диспетчер SNMP отправляются ловушки SNMP. Например, если состояние интерфейса меняется на активное, на сервер отправляется ловушка. Изменения настройки на маршрутизаторе также вызывают отправку ловушек SNMP диспетчеру SNMP. Список из более чем 60 типов уведомлений-ловушек можно увидеть с помощью команды snmp-server enable traps?. В настройке R1 в команде snmp-server enable traps notification-types не указаны типы уведомлений-ловушек, поэтому отправляются все ловушки.

На рисунке 2 в меню Setup (Настройка) установлен флажок. Это означает, что администратору сети нужно, чтобы программное обеспечение диспетчера SNMP принимало ловушки SNMP через порт UDP 162.

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

Для проверки настройки SNMP используйте любые варианты командыshow snmp в привилегированном режиме. Самой полезной является просто команда show snmp , так как она отображает информацию, которая обычно представляет интерес при проверке настройки SNMP. Если речь идёт о настройке SNMPv3, при использовании большинства других параметров команды отображаются только отдельные части выходных данных команды show snmp . На рисунке 4 представлен пример выходных данных show snmp .

В выходных данных команды show snmp не отображаются сведения, касающиеся строки сообщества SNMP или связанного списка контроля доступа, если таковой существует. На рисунке 5 представлена строка сообщества SNMP и данные списка контроля доступа, выведенные с помощью команды show snmp community .

Хотя протокол SNMP полезен для мониторинга и отладки (как показано на рисунке), он может привести к возникновению уязвимостей с точки зрения безопасности. По этой причине перед внедрением SNMP изучите лучшие практические рекомендации по обеспечению безопасности.

В SNMPv1 и SNMPv2c используются строки сообщества SNMP в незашифрованном виде для аутентификации доступа к объектам MIB. Строки сообщества, как и любой другой пароль, следует тщательно выбирать, чтобы их было непросто взломать. Кроме того, строки доступа необходимо регулярно менять в соответствии с политиками безопасности сети. Например, строки изменяются, если сетевой администратор меняет роли или уходит из компании. Если протокол SNMP используется только для наблюдения за устройствами, используйте сообщества только для чтения.

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

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

• Команда snmp-server group groupname { v1 | v2c | v3 { auth | noauth | priv }} создаёт новую группу SNMP на устройстве.

• Команда snmp-server user username groupname v3 [ encrypted ] [ auth { md5 | sha } auth-password ] [ priv { des | 3des | aes { 128 | 192 | 256 }} priv-password ] используется для добавления нового пользователя в группу SNMP, определённую в команде snmp-server group groupname .

Примечание . Настройка SNMPv3 выходит за рамки учебных программ CCNA.

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

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

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

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

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

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

Редактор MIB-ов

Таблица MIB-ов

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

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

В этом снимке сосредоточена практически вся суть нашего подхода к работе с данными 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: настраиваем периоды опроса и сроки хранения

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

Настройки опроса и хранения

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

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

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

В результате

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

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

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

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