Comments 3
Так, к примеру, работает утилита MIB Walk в составе Engineer's Toolset от SolarWinds, которая ту же «киску» с моего компьютера опрашивает 3,5 – 4 минуты
Из своего опыта разработчика систем мониторинга чую SNMPv1.
SNMPv1 появился в 1988 году, SNMPv2 в 1993. Устройств без SNMPv2/3 еще надо поискать.
Начиная с v2 появился GetBulkRequest(замена GetNext), с которым snmpbulkwalk работает на порядок быстрее snmpwalk.
В принципе, да — BULK-запросы ускоряют опрос раза в 2 – 3. Но проблему это полностью не снимает. Да и v1 в наших проектах используется на удивление часто — по информации от наших отделов внедрения и техподдержки. Я затрудняюсь объяснить это. Говорят что-то про пользователей, которые предпочитают не искать лишних проблем и работать с тем, что «точно работает» :) А может быть и устройств, не очень совместимых с v2 чуть больше, чем кажется.
BULK-и очень ненадежно работают с «кастомными» (плохо отлаженными) агентами — там могут генерироваться ошибки «на любой чих», и в случае с BULK-ом это приводит к потере сразу больших кусков данных (потерю которых иногда даже не сразу замечают). То же самое случается при высокой загруженности сети — пакеты теряются, данные пропадают большими кусками.
Кстати, в упомянутой утилите даже нет выбора v1 или v2 — только v3 (для безопасности).
BULK-и очень ненадежно работают с «кастомными» (плохо отлаженными) агентами — там могут генерироваться ошибки «на любой чих», и в случае с BULK-ом это приводит к потере сразу больших кусков данных (потерю которых иногда даже не сразу замечают). То же самое случается при высокой загруженности сети — пакеты теряются, данные пропадают большими кусками.
Кстати, в упомянутой утилите даже нет выбора v1 или v2 — только v3 (для безопасности).
Почему бы не спросить у самого устройства? Многие поддерживают SNMPv2-MIB::SysORTable
Sign up to leave a comment.
Быстрое обнаружение поддерживаемых SNMP-устройством MIB-модулей