Протокол SNMP существует с 1988 года. Он пережил сотни новых протоколов, несколько технологических революций, но не перестал быть стандартом для мониторинга сетевого оборудования. Причина проста: он простой и стабильно работает. В этой статье разберем, что из себя представляет протокол SNMP, как он устроен изнутри и как с его помощью выстроить мониторинг сети.
Разобраться в теме помогает Дмитрий Унтила, CPO «Пульта» и «Графини» в «Лаборатории Числитель», более 10 лет работающий с системами мониторинга.
Разобраться в теме помогает Дмитрий Унтила, CPO «Пульта» и «Графини» в «Лаборатории Числитель», более 10 лет работающий с системами мониторинга.
Протокол SNMP: что это такое и откуда он взялся
Немного истории
SNMP расшифровывается Simple Network Management Protocol, что дословно переводится как «простой сетевой протокол управления». Он появился в 1988 году и изначально создавался для сетевого оборудования: маршрутизаторов и коммутаторов.
Название не обманывает: SNMP действительно простой. В этом его главная сила и, одновременно, основное ограничение. Он не перегружен функциями и не требует сложной настройки, именно поэтому он стал единым стандартом для оборудования сотен производителей по всему миру. По сути, протокол SNMP для чайников можно объяснить так: это универсальный язык, на котором любое сетевое устройство может с нами взаимодействовать и рассказывать о своем состоянии.
Название не обманывает: SNMP действительно простой. В этом его главная сила и, одновременно, основное ограничение. Он не перегружен функциями и не требует сложной настройки, именно поэтому он стал единым стандартом для оборудования сотен производителей по всему миру. По сути, протокол SNMP для чайников можно объяснить так: это универсальный язык, на котором любое сетевое устройство может с нами взаимодействовать и рассказывать о своем состоянии.
Зачем нужен SNMP: задачи мониторинга и управления
SNMP решает две задачи: мониторинг и управление сетевым оборудованием. Мониторинг — это сбор данных о состоянии устройств: загрузка интерфейсов, ошибки, доступность, трафик. Управление — возможность что-то изменить на оборудовании удаленно. На практике для мониторинга через SNMP используют только чтение; запись применяется редко и только в специфических сценариях.
Для системных администраторов, сетевых-инженеров и всех, кто отвечает за ИТ-инфраструктуру, SNMP-мониторинг — это способ видеть, что происходит с оборудованием в реальном времени, не заходя на каждое устройство вручную.
Для системных администраторов, сетевых-инженеров и всех, кто отвечает за ИТ-инфраструктуру, SNMP-мониторинг — это способ видеть, что происходит с оборудованием в реальном времени, не заходя на каждое устройство вручную.
Как устроен SNMP изнутри: архитектура и ключевые компоненты
SNMP-менеджер и SNMP-агент
Любой SNMP-обмен происходит между двумя сторонами.
SNMP-агент — это программа, которая работает прямо на оборудовании: маршрутизаторе, коммутаторе, сервере или любом другом сетевом устройстве. Агент собирает данные о состоянии своего «хозяина» и готов отвечать на запросы.
SNMP-менеджер — это система мониторинга. Она опрашивает агентов, получает данные и анализирует их. Именно менеджер инициирует обмен, потому что агент сам по себе ничего не отправляет, только отвечает. Исключение — SNMP trap, о котором поговорим ниже.
Простая аналогия: агент — это сотрудник на месте, который знает, что происходит вокруг. Менеджер — это руководитель в офисе, который периодически звонит и спрашивает: «Как дела?». Сотрудник отвечает, но, если что-то случилось, он сам звонит, не дожидаясь вопроса.
SNMP-агент — это программа, которая работает прямо на оборудовании: маршрутизаторе, коммутаторе, сервере или любом другом сетевом устройстве. Агент собирает данные о состоянии своего «хозяина» и готов отвечать на запросы.
SNMP-менеджер — это система мониторинга. Она опрашивает агентов, получает данные и анализирует их. Именно менеджер инициирует обмен, потому что агент сам по себе ничего не отправляет, только отвечает. Исключение — SNMP trap, о котором поговорим ниже.
Простая аналогия: агент — это сотрудник на месте, который знает, что происходит вокруг. Менеджер — это руководитель в офисе, который периодически звонит и спрашивает: «Как дела?». Сотрудник отвечает, но, если что-то случилось, он сам звонит, не дожидаясь вопроса.
MIB и OID: как оборудование описывает само себя
Оборудование изначально оперирует не человекочитаемыми именами, а числовыми идентификаторами — OID (Object Identifier). OID — это уникальный набор цифр, разделенных точками. Например: 1.3.6.1.2.1.1.1. Каждая такая строка — конкретная метрика на конкретном оборудовании. Если сделать запрос напрямую без расшифровки, в ответ придет «портянка» из таких цифр с непонятными значениями справа.
Именно здесь в игру вступает MIB (Management Information Base) — справочник, который переводит эти цифры на человеческий язык. MIB объясняет: OID 1.3.6.1.2.1.2.2.1.8 — это ifOperStatus, то есть оперативное состояние интерфейса. Каждый производитель должен выпускать MIB-файл для своего оборудования. Есть универсальные OID, которые не привязаны к производителю и присутствуют на любом сетевом устройстве. А есть Enterprise MIB — фирменный справочник производителя, который описывает уникальные метрики конкретной железки.
На практике ситуация не всегда идеальная: MIB-файл иногда приходится искать в открытых репозиториях, так называемых MIB-браузерах. Бывает, что нужный файл там есть, но не совпадает с прошивкой устройства. Случается, что его нет вообще. Как отмечает Дмитрий Унтила: «Смотришь описание, все пишут „поддерживаем SNMP“, заходишь — в итоге метрики никакие не отдаются, MIB-файлов нет, и не знаешь, куда смотреть. Это всегда процесс исследования». Хороший производитель заботится о клиентах и позволяет скачать MIB прямо с веб-консоли устройства.
Именно здесь в игру вступает MIB (Management Information Base) — справочник, который переводит эти цифры на человеческий язык. MIB объясняет: OID 1.3.6.1.2.1.2.2.1.8 — это ifOperStatus, то есть оперативное состояние интерфейса. Каждый производитель должен выпускать MIB-файл для своего оборудования. Есть универсальные OID, которые не привязаны к производителю и присутствуют на любом сетевом устройстве. А есть Enterprise MIB — фирменный справочник производителя, который описывает уникальные метрики конкретной железки.
На практике ситуация не всегда идеальная: MIB-файл иногда приходится искать в открытых репозиториях, так называемых MIB-браузерах. Бывает, что нужный файл там есть, но не совпадает с прошивкой устройства. Случается, что его нет вообще. Как отмечает Дмитрий Унтила: «Смотришь описание, все пишут „поддерживаем SNMP“, заходишь — в итоге метрики никакие не отдаются, MIB-файлов нет, и не знаешь, куда смотреть. Это всегда процесс исследования». Хороший производитель заботится о клиентах и позволяет скачать MIB прямо с веб-консоли устройства.
SNMP trap: когда оборудование бьет тревогу
Стандартный режим SNMP — это polling (опрос): менеджер спрашивает, агент отвечает. Но есть второй метод — мониторинг с помощью SNMP trap. Ловушка, если переводить буквально.
Принцип работы trap обратный: не менеджер спрашивает агента, а агент сам отправляет сообщение менеджеру, когда на устройстве что-то происходит. Упал интерфейс, перегрелся процессор, изменилась конфигурация — агент сам инициирует уведомление. При этом у trap есть важная особенность: он работает по протоколу UDP. Это значит, что сообщение отправляется только один раз: никакого подтверждения доставки, никакого повторения. Если в момент отправки пакет потерялся на сети, никто не узнает об инциденте. Еще одна ловушка trap: если на устройстве сбились настройки или поменялся IP-адрес системы мониторинга, сообщения будут уходить в никуда. Никто об этом не узнает до первого реального инцидента.
Именно поэтому на практике большинство инженеров предпочитают опрос (polling), а не trap. Метод polling самодиагностируется: если данные не приходят — система мониторинга это видит и сигнализирует.
Именно поэтому на практике большинство инженеров предпочитают опрос (polling), а не trap. Метод polling самодиагностируется: если данные не приходят — система мониторинга это видит и сигнализирует.
Community string: «пароль», который не совсем пароль
Для доступа к SNMP-агенту нужно знать community string — это своеобразный пароль. Он очень простой: не логин и пароль, а просто слово. Существует community string для чтения (read) и для записи (write).
Стандартные значения по умолчанию — «public» для чтения и «private» для записи. Практика показывает, что большинство компаний так их и оставляют. Почему это проблема, расскажем в разделе о безопасности. А пока важно запомнить: community string — это минимальная защита SNMPv1 и SNMPv2c. В SNMPv3 от этой концепции ушли в сторону полноценной аутентификации и шифрования.
Стандартные значения по умолчанию — «public» для чтения и «private» для записи. Практика показывает, что большинство компаний так их и оставляют. Почему это проблема, расскажем в разделе о безопасности. А пока важно запомнить: community string — это минимальная защита SNMPv1 и SNMPv2c. В SNMPv3 от этой концепции ушли в сторону полноценной аутентификации и шифрования.
Версии протокола SNMP: в чем разница между v1, v2c и v3
SNMPv1 и SNMPv2c: простота с оговорками
SNMPv1 — самая первая версия протокола, созданная в 1988 году. Базовая функциональность, только community string в качестве защиты, нет шифрования. Сейчас используется крайне редко.
SNMPv2c — самая распространенная версия на сегодняшний день. Имеет поддержку bulk-запросов (много метрик), улучшенную обработку ошибок. Но security-модель осталась той же: community string, без шифрования. Зато ее поддерживает все оборудование без исключений — и в этом ее главная ценность. Важный момент про bulk-запросы: это режим, при котором система мониторинга за один запрос забирает сразу много метрик. Альтернатива — опрашивать каждую метрику по отдельности. Не все оборудование одинаково хорошо работает с обоими режимами, и при неправильно выбранном типе запроса можно получить заметную нагрузку на сам маршрутизатор или коммутатор.
SNMPv2c — самая распространенная версия на сегодняшний день. Имеет поддержку bulk-запросов (много метрик), улучшенную обработку ошибок. Но security-модель осталась той же: community string, без шифрования. Зато ее поддерживает все оборудование без исключений — и в этом ее главная ценность. Важный момент про bulk-запросы: это режим, при котором система мониторинга за один запрос забирает сразу много метрик. Альтернатива — опрашивать каждую метрику по отдельности. Не все оборудование одинаково хорошо работает с обоими режимами, и при неправильно выбранном типе запроса можно получить заметную нагрузку на сам маршрутизатор или коммутатор.
SNMPv3: безопасность есть, популярности нет
SNMPv3 появилась как ответ на критику безопасности предыдущих версий. Здесь есть полноценная аутентификация (логин + пароль), шифрование трафика, контроль доступа — все, что нужно для серьезной инфраструктуры. Но на практике третья версия протокола так и не стала стандартом. Причин несколько.
Во-первых, поддержка SNMPv3 есть далеко не на всем оборудовании. По оценкам из практики: примерно 20% устройств ее поддерживают, 80% — нет. Если перевести всю инфраструктуру на v3 невозможно технически, то смысл в единообразии теряется, а уровень защиты в итоге все равно снижается.
Во-вторых, SNMPv3 создает нагрузку на само оборудование. Каждый запрос требует шифрования и расшифровки, а на некоторых железках это заметно нагружает процессор. Мониторинг начинает влиять на работу того, что контролирует.
В-третьих, часть производителей заявляет поддержку SNMPv3, но реализует ее с ошибками. На практике он может работать нестабильно или некорректно.
В результате, если инфраструктура позволяет, лучше использовать SNMPv3. Если нет, можно SNMPv2c с грамотно настроенным community string и ограничением по IP-адресам.
Во-первых, поддержка SNMPv3 есть далеко не на всем оборудовании. По оценкам из практики: примерно 20% устройств ее поддерживают, 80% — нет. Если перевести всю инфраструктуру на v3 невозможно технически, то смысл в единообразии теряется, а уровень защиты в итоге все равно снижается.
Во-вторых, SNMPv3 создает нагрузку на само оборудование. Каждый запрос требует шифрования и расшифровки, а на некоторых железках это заметно нагружает процессор. Мониторинг начинает влиять на работу того, что контролирует.
В-третьих, часть производителей заявляет поддержку SNMPv3, но реализует ее с ошибками. На практике он может работать нестабильно или некорректно.
В результате, если инфраструктура позволяет, лучше использовать SNMPv3. Если нет, можно SNMPv2c с грамотно настроенным community string и ограничением по IP-адресам.
Какое оборудование поддерживает SNMP-мониторинг
SNMP поддерживается практически любым сетевым оборудованием: маршрутизаторы и коммутаторы (Cisco, Huawei, Juniper, MikroTik и другие), серверы и системы хранения данных (СХД), принтеры, ИБП, системы контроля доступа, виртуальные окружения и гипервизоры, устройства промышленной автоматики и IoT.
Зачастую SNMP — это не лучший выбор, а единственный. Альтернативы вроде HTTP-based-мониторинга прекрасно работают в мире современных приложений и микросервисов, но старое сетевое оборудование на это просто не способно. SNMP для них — единственный способ рассказать о своем состоянии.
Однако оборудование может заявлять поддержку SNMP, но по факту отдавать данные только одним из двух способов: либо через polling, либо через trap. Например, некоторые системы хранения данных формально поддерживают SNMP, но работают только с trap-уведомлениями и опрос по polling для них недоступен. Перед внедрением мониторинга стоит это уточнять, чтобы не столкнуться с неожиданностями на этапе настройки.
Зачастую SNMP — это не лучший выбор, а единственный. Альтернативы вроде HTTP-based-мониторинга прекрасно работают в мире современных приложений и микросервисов, но старое сетевое оборудование на это просто не способно. SNMP для них — единственный способ рассказать о своем состоянии.
Однако оборудование может заявлять поддержку SNMP, но по факту отдавать данные только одним из двух способов: либо через polling, либо через trap. Например, некоторые системы хранения данных формально поддерживают SNMP, но работают только с trap-уведомлениями и опрос по polling для них недоступен. Перед внедрением мониторинга стоит это уточнять, чтобы не столкнуться с неожиданностями на этапе настройки.
Безопасность SNMP: риски и минимальный набор мер
SNMP часто называют небезопасным протоколом, и это отчасти справедливо для версий v1 и v2c. Трафик не шифруется, аутентификация сводится к одному слову. Что можно сделать, если переход на SNMPv3 невозможен?
— Сменить community string с дефолтного «public» на что-то уникальное. Это уже серьезно снизит риск случайного или намеренного доступа.
— Ограничить список IP-адресов, с которых разрешен доступ к агенту. Не «откуда угодно», а только с конкретных адресов системы мониторинга.
— Закрыть порт 161 UDP на firewall для всего, кроме системы мониторинга.
— Использовать SNMPv2c только на чтение — community string для записи не должен быть активен без необходимости.
Если инфраструктура позволяет, лучше перейти на SNMPv3 там, где это работает. Шифрование и нормальная аутентификация радикально меняют картину безопасности.
— Сменить community string с дефолтного «public» на что-то уникальное. Это уже серьезно снизит риск случайного или намеренного доступа.
— Ограничить список IP-адресов, с которых разрешен доступ к агенту. Не «откуда угодно», а только с конкретных адресов системы мониторинга.
— Закрыть порт 161 UDP на firewall для всего, кроме системы мониторинга.
— Использовать SNMPv2c только на чтение — community string для записи не должен быть активен без необходимости.
Если инфраструктура позволяет, лучше перейти на SNMPv3 там, где это работает. Шифрование и нормальная аутентификация радикально меняют картину безопасности.
Сильные стороны и ограничения протокола SNMP
Почему SNMP продолжают использовать:
— Повсеместность. Поддерживается буквально на любом сетевом оборудовании.
— Простота. Минимальные требования к настройке, особенно в v2c.
— Стандартизированность. Один протокол для оборудования сотен производителей.
— Зрелость. Протокол существует десятилетиями, все edge cases давно известны.
Что нужно учитывать:
— Безопасность v1/v2c. Отсутствие шифрования и слабая аутентификация при неправильной настройке.
— Ненадежность trap. UDP-транспорт без подтверждения доставки, потерянное сообщение не вернешь.
— Нагрузка при частом опросе. Высокочастотный polling или неподходящий тип запросов может грузить само оборудование.
— Зависимость от MIB. Без правильного MIB-файла работа с производительностью сети и нестандартными метриками превращается в «угадайку».
— Повсеместность. Поддерживается буквально на любом сетевом оборудовании.
— Простота. Минимальные требования к настройке, особенно в v2c.
— Стандартизированность. Один протокол для оборудования сотен производителей.
— Зрелость. Протокол существует десятилетиями, все edge cases давно известны.
Что нужно учитывать:
— Безопасность v1/v2c. Отсутствие шифрования и слабая аутентификация при неправильной настройке.
— Ненадежность trap. UDP-транспорт без подтверждения доставки, потерянное сообщение не вернешь.
— Нагрузка при частом опросе. Высокочастотный polling или неподходящий тип запросов может грузить само оборудование.
— Зависимость от MIB. Без правильного MIB-файла работа с производительностью сети и нестандартными метриками превращается в «угадайку».
Как настроить SNMP-мониторинг: общий алгоритм
Шаг 1. Включить SNMP-агент на устройстве
На каждом устройстве нужно активировать агент и задать community string. На сетевом оборудовании это обычно две команды в консоли: включить SNMP-агент и прописать community. Для одного устройства настройка протокола SNMP не представляет проблемы, но, когда их 100 или 1000, это становится серьезной задачей.
Из практики: на одном из проектов Дмитрий Унтила работал с инфраструктурой из 5000+ объектов — настройка каждого вручную в таких масштабах просто невозможна. Чтобы этого избежать, следует использовать инструменты оркестрации или автоматизации.
Важно учитывать настройку SNMP-мониторинга с точки зрения безопасности: поменять community string с дефолтного «public» на что-то уникальное, а при работе с SNMPv2c — ограничить список IP-адресов, с которых разрешен доступ.
Из практики: на одном из проектов Дмитрий Унтила работал с инфраструктурой из 5000+ объектов — настройка каждого вручную в таких масштабах просто невозможна. Чтобы этого избежать, следует использовать инструменты оркестрации или автоматизации.
Важно учитывать настройку SNMP-мониторинга с точки зрения безопасности: поменять community string с дефолтного «public» на что-то уникальное, а при работе с SNMPv2c — ограничить список IP-адресов, с которых разрешен доступ.
Шаг 2. Настроить систему мониторинга
В системе мониторинга SNMP нужно добавить устройства, указав их IP-адрес, community string и версию протокола. Если у производителя есть MIB-файл — загрузить его. Он позволит системе понять, какие OID за что отвечают, и даст человекочитаемые названия метрикам вместо цифровых кодов.
Зрелые системы мониторинга имеют готовые шаблоны для популярного оборудования. Это экономит десятки часов: не нужно вручную разбираться, какие OID нужны для мониторинга конкретного коммутатора Cisco или маршрутизатора Huawei.
Зрелые системы мониторинга имеют готовые шаблоны для популярного оборудования. Это экономит десятки часов: не нужно вручную разбираться, какие OID нужны для мониторинга конкретного коммутатора Cisco или маршрутизатора Huawei.
Шаг 3. Проверить доступность и настроить алерты
Настройка SNMP-мониторинга не заканчивается на подключении устройств. Нужно проверить связку из двух протоколов: SNMP и ICMP (ping). Вот пошаговая логика диагностики:
- Если устройство не отвечает по ICMP — скорее всего, оно физически недоступно: выключено, оборван кабель, нет питания. Тут SNMP тоже работать не будет.
- Если ICMP работает (устройство «пингуется»), а SNMP нет — проблема в настройках или в firewall. Очень частая ситуация: инженер все настроил на устройстве, но порт 161 UDP закрыт на межсетевом экране между системой мониторинга и оборудованием. Уведомления об инцидентах для trap приходят на порт 162 UDP. Важно убедиться, что оба порта открыты.
- После проверки доступности — настройка алертов: какой уровень загрузки интерфейса считать критическим, при каком статусе линка отправлять уведомление. Без алертов мониторинг — не более чем красивые графики.
Что реально мониторят с помощью SNMP: метрики из практики
Если спросить любого сетевого инженера, что он мониторит по SNMP, то ответ будет одинаковый: интерфейсы. Это самое важное для сетевиков.
ifOperStatus — оперативный статус интерфейса. Возвращает два состояния: «up» или «down». Перерезали кабель, выпал патчкорд, отвалился линк — эта метрика немедленно сигнализирует, что важно для предотвращения простоев.
Утилизация интерфейсов. Насколько загружены линки? Если канал уперся в 90%, то пора думать об апгрейде или балансировке трафика.
ifError и ifDiscard. Ошибки на интерфейсах и потери пакетов. Сеть может «работать», но, если там идут тихие потери, то производительность деградирует незаметно для пользователей, но очень ощутимо для бизнеса.
Помимо сетевых метрик, через SNMP доступны: загрузка CPU и оперативной памяти устройств, температура, статус блоков питания и вентиляторов — все, что производитель решил «открыть» через свой MIB.
ifOperStatus — оперативный статус интерфейса. Возвращает два состояния: «up» или «down». Перерезали кабель, выпал патчкорд, отвалился линк — эта метрика немедленно сигнализирует, что важно для предотвращения простоев.
Утилизация интерфейсов. Насколько загружены линки? Если канал уперся в 90%, то пора думать об апгрейде или балансировке трафика.
ifError и ifDiscard. Ошибки на интерфейсах и потери пакетов. Сеть может «работать», но, если там идут тихие потери, то производительность деградирует незаметно для пользователей, но очень ощутимо для бизнеса.
Помимо сетевых метрик, через SNMP доступны: загрузка CPU и оперативной памяти устройств, температура, статус блоков питания и вентиляторов — все, что производитель решил «открыть» через свой MIB.
На что обратить внимание при выборе системы мониторинга SNMP
Поддержка SNMP есть во многих системах мониторинга, но между «галочкой в списке функций» и зрелой реализацией — большая разница. Выделим несколько критериев, которые отличают рабочее решение.
- Библиотека готовых шаблонов. Настройка мониторинга с нуля — это долго и сложно. Наличие заготовленных правил для популярного отечественного и зарубежного оборудования необходимо для любой серьезной системы.
- Поддержка всех версий и методов. Система должна работать с SNMPv1, v2c и v3, а также поддерживать оба метода: polling (опрос) и прием trap-уведомлений. Без этого вы не сможете покрыть всю инфраструктуру.
- Горизонтальное масштабирование. Когда устройств не двадцать, а пятьсот или пять тысяч, система мониторинга должна масштабироваться. Важно, чтобы можно было наращивать мощности опроса без перестройки всей архитектуры.
- Массовое изменение параметров. Если политика безопасности потребует сменить community string на всем оборудовании, редактировать каждое устройство вручную — это неудобно и трудоемко. Зрелая система позволяет менять параметры подключения массово.
- Автоматическое обнаружение устройств (discovery). Возможность сканировать подсети и автоматически ставить на мониторинг новое оборудование, как только оно ответило на SNMP-запрос. Это в разы снижает нагрузку на администраторов в крупных инфраструктурах.
Управление и мониторинг SNMP в «Пульте»
«Пульт» — российская система мониторинга ИТ-инфраструктуры от «Лаборатории Числитель», которая отвечает всем перечисленным критериям. Поддерживаются все три версии протокола SNMP и оба метода работы: polling и прием trap.
В «Пульте» есть библиотека готовых шаблонов для популярного оборудования, возможность массового изменения параметров подключения и автоматическое обнаружение устройств в сети. Для масштабирования опроса выделяются отдельные SNMP-поллеры — их количество можно увеличивать по мере роста инфраструктуры.
В «Пульте» есть библиотека готовых шаблонов для популярного оборудования, возможность массового изменения параметров подключения и автоматическое обнаружение устройств в сети. Для масштабирования опроса выделяются отдельные SNMP-поллеры — их количество можно увеличивать по мере роста инфраструктуры.
Итоги
SNMP — это не пережиток прошлого, а живой и актуальный стандарт. Он родился в 1988 году, и никакой конкурент так и не смог его вытеснить из мира сетевого оборудования. Причина проста: часто это единственный способ мониторинга сетевого оборудования.
Понимание того, как работает протокол SNMP: как взаимодействуют менеджер и агент, что такое MIB и OID, чем polling отличается от trap, в чем разница между версиями протокола, позволяет выстроить надежный мониторинг через SNMP и избежать типичных ошибок. Надеемся, что эта статья стала для вас понятным объяснением SNMP-протокола, как для чайников, так и профессионалов.
Понимание того, как работает протокол SNMP: как взаимодействуют менеджер и агент, что такое MIB и OID, чем polling отличается от trap, в чем разница между версиями протокола, позволяет выстроить надежный мониторинг через SNMP и избежать типичных ошибок. Надеемся, что эта статья стала для вас понятным объяснением SNMP-протокола, как для чайников, так и профессионалов.
