Как системные администраторы узнают, что какой-то сервер не отвечает? или на нем зависла отдельная служба? греется процессор от неисправной системы отвода тепла? либо он уже второй день обрабатывает запросы от жителей целых ЖК, будучи доступным только по одному провайдеру сети интернет, так как на резервном перегорел SFP трансивер. Они не обновляют страницы состояния инфраструктуры, не читают каждые 10 минут логи и не сидят круглосуточно перед десятками консолей. За них это делает верный и чуткий помощник, мимо которого не проскочит не замеченной ни одна проблема в инфраструктуре. Вашему вниманию протокол SNMP (Simple Network Management Protocol) разработанный еще в 1988 году этот парень остается крутым в своем деле. Если вы только начинаете с ним знакомиться, то в этой статье я постараюсь расписать все, что о нем знаю (в рамках объяснения) сделаем пару практических примеров и составим хороший фундамент, для дальнейшего продвижения в этой большой сфере Мониторинга, обнаружения ошибок в инфраструктуре.
Первое, с чего хочется начать, это структура протокола, он состоит из двух частей:
Менеджер - это система запроса, обработки, хранения и отображения информации, полученной от проверяемых хостов, что и как спрашивать он узнает из специально подготовленной и бесплатно нам предоставленной базы MIB (Management Information Base) мы не будем его открывать и читать, потому что во первых испугаемся, во вторых нам это не нужно, оно само работает без нашего участия;
Агент: - знает все, о хосте и готов ответить на любые "вопросы" заданные менеджером (как в реальной жизни да? отправил агента - получаешь информацию по запросу) вопросы, он получает на особом "языке" OID (Object Identifier) читать их тоже не надо, за нас это сделает агент, они уже готовые и заранее записанные в MIB.
Наверно, вы сейчас подумаете "ну ничего себе симпл, что ты еще там предложишь? объекты да интерфейсы писать и соединять их в систему мониторинга?" нет, со сложностями мы закончили, дальше будем все вышеописанное, обсуждать на понятном языке. Менеджер, уже рассмотренный нами, работает в составе решений мониторинга, самые известные из них: Zabbix, Nagios и даже новомодный Prometheus через свой прокси, но чтобы не нагружать вас сразу всеми существующими технологиями, обойдемся обычными запросами с самого сервера, где и будем смотреть полученную информацию, то есть да, будем отправлять запросы из менеджера вручную, чтобы было понимание как оно работает "под капотом".
Давайте установим сам менеджер SNMP, а также саму базу MIB на тестовый стенд Linux Debian, обновим список доступных для установки пакетов: apt update и выполним саму установку apt install snmp snmp-mibs-downloader, установится пакет SNMP, который уже готов к работе.
Настройка SNMP агента
Если менеджер, это самодостаточная система, то Агент, должен быть настроен, для приема команд, он должен "понимать", как к нему будут обращаться, давайте это тоже сделаем, на примере маршрутизатора Cisco, с другим оборудованием идентично, режим чтения, RO
Настройка проста и сводится к одной простой строке: snmp-server community public RO
snmp-server: это собственно сам модуль, который мы конфигурируем;
community: стоит понимать как пароль;
public: сам пароль;
RO: read only, с этим паролем можем только считывать информацию
Агент настроен, переходим к тестам, сначала научимся получать информацию
Давайте выполним пару простых команд и посмотрим статус работы маршрутизатора Cisco. Для быстрого просмотра и диагностики, на случай если под рукой нет инструментов мониторинга, о которых шла речь выше, можно узнать выполнив команду с самого SNMP менеджера, например, узнаем информацию про наш маршрутизатор: snmpwalk -v2c -c public router sysDescr.0 получим следующий вывод:
видим, что команда вернула бренд, адрес сайта, где можно ознакомиться с продукцией, модель (видно что наш маршрутизатор запущен с с виртуальной машины) и версию прошивки.
Можно посмотреть список интерфейсов выполнив snmpwalk -v2c -c public router ifDescr
snmpwalk - это модуль SNMP менеджера, для выполнения запроса информации у агента;
-v2c - ключ, который говорит агенту, что мы используем вторую версию протокола (чаще всего она и используется);
-c public - тут через ключ -c говорится указывается, что запрос в режиме чтения;
router - имя маршрутизатора, можно и по IP, но я больше сторонник DNS имен;
ifDescr - строковое имя, чтобы не вводить страшный OID, возвращает список интерфейсов
С остальными командами идентично, они легко гуглятся, если вдруг захотите поэкспериментировать.
А теперь поуправляем маршрутизатором через SNMP
Это нечастая на самом деле практика, ведь сетевым оборудованием мы обычно управляем с командной строки, или через WEB интерфейс, но бывают случаи, когда система мониторинга должна иметь возможность вносить изменения, для этого и предоставлена команда snmpset.
Настроим маршрутизатор, чтобы он принимал команды, то есть режим записи, RW, выполним на маршрутизаторе: snmp-server community private RW, комментировать на этот раз не стану, потому что все понятно и так, по объяснению команды snmpwalk
Готово, теперь поработаем с полученной ранее информацией об интерфейсах, допустим, нам понадобилось выключить интерфейс FastEthernet1/1, введем команду: snmpset -v2c -c private router ifAdminStatus.3 i 2
тут все то же самое, кроме:
ifAdminStatus.3 - ifAdminStatus - выбор самого интерфейса, и передача через точку идентификатора, т.е., 3, в нашем примере наверху интерфейс FastEthernet1/1;
i 2 - выключить (кстати i 1 включит интерфейс)
И вот информация с самого маршрутизатора, подтверждающее успешное выполнение команды:
Для ознакомления с протоколом думаю достаточно, в следующем посте приготовлю работу уже готового решения для мониторинга инфраструктуры, например Zabbix.