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 для 2 различных программ, Zabbix и Cacti.

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

Zabbixкактусы

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Источник

2 ответа

Решение

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

Вероятность того, что один или другой компьютер отстают, увеличивается с увеличением рабочей нагрузки. Если у вас много SNMP-агентов, запрашивающих конкретный хост, он может не обслуживать ответы так же своевременно, как ожидают некоторые агенты (и эти агенты будут отображаться пустыми). пятна на графиках или сообщать о других ошибках).
И наоборот, если у вас есть один агент, запрашивающий группу хостов - больше, чем он может обработать за интервал опроса - машины, которые не будут опрошены в течение интервала опроса, будут иметь пробел в своих графиках. (Эта проблема была особенно распространена в PHP-опросчике Cacti и привела к cactid (сейчас spine), which I strongly encourage you to use if you're not already using it).

My general advice on fixing this:

  1. Poll every 5 minutes, if possible.
    Most environments don't need 1/5/15/30/60/90/120 second polling intervals.
    If five-minute granularity is good enough for you, stick with it. It's less work for your servers, less work for your SNMP monitoring agents, and less data to store (or a longer period of time at "full granularity")

  2. Increase the SNMP timeout on your agents.
    Give the server more time to get around to your request. SNMP daemons are the lazy teenager of processes - you ask them to clean their room (or give you a tree's worth of data) on Monday, and on Wednesday or Thursday they might have picked up a few socks.

  3. Limit how much you're demanding from the server with each poll.
    If you just need one counter don't ask for the whole interfaces MIB -- it (usually) takes a longer time to walk the tree and generate full output than it does to just give you one OID.

  4. Limit how many agents are asking for data.
    If you can consolidate your monitoring to one box (Zabbix or Cacti) you'll be putting fewer demands on your server, and it's less likely to not respond in a timely manner.

If you're still having trouble after trying the above there is the ultimate debugging step: Hunt through your logs and Sniff the SNMP traffic. Make sure requests and responses are going back and forth in a timely manner and not being lost/rejected as malformed for some reason. Often looking at the data on the wire will give you a good indication of what's wrong and how to fix it.

Источник

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

Источник
Другие вопросы по тегам