Назад | Перейти на главную страницу

Счетчики интерфейса обновления snmpd медленно или что-то вроде этого

Я обновляю один из моих пакетов freebsd до 9-stable (совершенно новая установка) и устанавливаю net-snmp для мониторинга.

uname -r 
9.1-PRERELEASE

pkg_info net-snmp-5.7.1_7 
Information for net-snmp-5.7.1_7:

Comment:
An extendable SNMP implementation
....


cat /var/db/ports/net-snmp/options 
# This file is auto-generated by 'make config'.
# Options for net-snmp-5.7.1_7
_OPTIONS_READ=net-snmp-5.7.1_7
_FILE_COMPLETE_OPTIONS_LIST= IPV6 MFD_REWRITES PERL PERL_EMBEDDED PYTHON DUMMY TKMIB DMALLOC MYSQL AX_SOCKONLY UNPRIVILEGED
OPTIONS_FILE_UNSET+=IPV6
OPTIONS_FILE_UNSET+=MFD_REWRITES
OPTIONS_FILE_SET+=PERL
OPTIONS_FILE_SET+=PERL_EMBEDDED
OPTIONS_FILE_UNSET+=PYTHON
OPTIONS_FILE_SET+=DUMMY
OPTIONS_FILE_UNSET+=TKMIB
OPTIONS_FILE_SET+=DMALLOC
OPTIONS_FILE_UNSET+=MYSQL
OPTIONS_FILE_UNSET+=AX_SOCKONLY
OPTIONS_FILE_UNSET+=UNPRIVILEGED

У меня около 500 vlan на этой машине, и я собираю информацию об интерфейсе через snmpd для двух разных программ, zabbix и cacti.

И оба строят графики с пустыми полями.

Я попытался изменить время опроса в zabbix с 15 секунд до 30,60,90,120,10. И вообще у меня пустые поля.

snmpd.conf пуст - только контроль доступа.

Эта конфигурация отлично работала на freebsd 8.

В чем моя вина? Как исправить эти графики?

UPD: Изменение времени объединения, выключение одного из агентов не помогает. Я смотрю журнал zabbix (данные получены от snmpd) и вижу, что: извините за русский язык, просто посмотрите на числа:

и это неправда, так как моя скорость показа «iftop» была около 90 Мбит, но snmpd вернул 2 Мбит.

Я понимаю, что snmpd не возвращает скорость, а возвращает только счетчик. Но как это возможно? почему 2Мбит / с?

Я пробовал перекомпилировать snmpd с 64-битными счетчиками и без него. В обоих вариантах это пустое поле присутствует.

Поэтому я думаю, что моя ОС (freebsd) плохо обновляет счетчики интерфейса.

Я до сих пор собираю tcpdump, чтобы найти этот запрос / ответ. Но есть проблемы с этим, слишком много мусора.

UPD2: Я расшифровываю файл tcpdump-ed и публикую его как документ google по адресу gdocfile

Timediff выглядит странно .. Типа zabbix иногда "забывает" сделать запрос, а затем выполнить дважды подряд, ага

UPD3: Я разбираю журнал с помощью команды "while true; do netstat -bin -I vlan4008 >> / var / log / netstat; sleep 300; done" и загружаю как документы Google, и добавляю формулу для скорости: ссылка на сайт

Похоже, в ОС все счетчики хорошие. Теперь я думаю, что проблема в: 1. zabbix получает запрос дважды в строке (и как насчет cacti) 2. snmpd использует counter32

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

Вероятность отставания одной или другой машины увеличивается с увеличением рабочей нагрузки - если у вас много агентов SNMP, запрашивающих конкретный хост, он может не обслуживать ответы так своевременно, как ожидают некоторые из агентов (и эти агенты будут отображаться пустыми. пятна на графиках или сообщить о других ошибках).
И наоборот, если у вас есть один агент, запрашивающий группу хостов - больше, чем он может обработать за ваш интервал опроса - машины, которые не запрашиваются во время интервала опроса, будут иметь пробелы в своих графиках. (Эта проблема была особенно распространена с PHP-поллером Cacti и привела к разработке cactid (сейчас spine), который я настоятельно рекомендую вам использовать, если вы еще не используете его).

Мой общий совет по исправлению этого:

  1. По возможности опрашивайте каждые 5 минут.
    В большинстве сред не требуются интервалы опроса 1/5/15/30/60/90/120 секунд.
    Если вам достаточно пятиминутной детализации, придерживайтесь ее. Это меньше работы для ваших серверов, меньше работы для ваших агентов мониторинга SNMP и меньше данных для хранения (или более длительный период времени при "полной детализации")

  2. Увеличьте тайм-аут SNMP на ваших агентах.
    Дайте серверу больше времени, чтобы обработать ваш запрос. Демоны SNMP - это ленивые подростки процессов: вы просите их убрать свою комнату (или дать вам целое дерево данных) в понедельник, а в среду или четверг они могли бы подобрать несколько носков.

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

  4. Ограничьте количество агентов, запрашивающих данные.
    Если вы можете объединить свой мониторинг в одном окне (Zabbix или Cacti), вы будете предъявлять меньше требований к своему серверу, и вероятность того, что вы не отреагируете вовремя, будет меньше.

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

Какую версию протокола SNMP вы используете? SNMP v1 не поддерживает 64-битные счетчики. Это старая проблема с Cacti, просто переключитесь на «Версию 2» на соответствующем «Устройстве».