Почему графики с провалами (нет данных)?
1949
1950
в логах что нибудь есть по этому поводу? у меня такое бывает, когда устройство по таймауту не отвечает заббикс_серверу
в логах что нибудь есть по этому поводу? у меня такое бывает, когда устройство по таймауту не отвечает заббикс_серверу
На DebugLevel=3 никаких записей о интерфейсе ifInOctets.2 нет.
Cacti строит графики на этот интерфейс нормально, без провалов.
По команде "snmpget -v2c -c secret ip ifInOctets.2" всегда возвращается значение.
Есть другое оборудование с аналогичными провалами на некоторых интерфейсах.
Наблюдаю этот итем застрявший в очереди заббикс сервера:
05.11.2009 18:02:00 Krasnoyarsk Router Cisco2801-UU2 EQ.903 ifInOctets2
Почему итем застрял в очереди? Как его протолкнуть?
надо тюнить sql, у меня при 24 хостах и 2500 итемах, при дефолтовых параметрах, начала копиться очередь, и стали провалы в графиках появляться.
рекомендую mysqltuner.pl, а дальше плясать от результатов
Nikolaicheg
14-05-2009, 10:00
каковы параметры сервера? Железо? ось? версия заббикса? тип БД?
fredushka
20-05-2009, 10:08
Я тоже столкнулся с этой проблемой.
При таком количестве наблюдаемых объектов
Number of hosts (monitored/not monitored/templates) 484 479 / 0 / 5
Number of items (monitored/disabled/not supported) 4056 3760 / 129 / 167
вначале изредка, пару раз в неделю, потом и по несколько раз в день стала зависать очередь. Причем, как правило, время элементов в очереди очень близкое, наводящее на мысль, что в это время была высокая нагрузка на mysql.
Плохо, что при зависании в очереди, item-ы остаются там вплоть до перезагрузки zabbix-а и никаких штатных средств нет, чтобы толкнуть очередь.
Само собой, все элементы очереди живы здоровы, пингуются и snmp-уются :)
Проблема, конечно, в mysql (его тюнинге, производительности железа и пр.). Я практически выяснил, что зависания очереди (в моем случае) происходят при работе hosekeeper-а - база может пуржиться длительное время, за которое стремительно растет количество желающих сделать insert в таблицы history*.*. Некоторые из них так и не дожидаются своей очереди и вот здесь уже zabbix, похоже не знает что с ними делать. Похоже, что ситуация возникает из за отсутствия обработки в zabbixe такой ситуации.
Это, конечно, не снимает ответственности с юзера за мощность сервера и тюнинг mysql, но хотелось бы, чтобы и zabbix адекватно реагировал на такую ситуацию. Не смогли задвинуть в базу очередные данные - фиг с ними - пусть теряются, пишем в лог о неудаче и убираем элемент из очереди до следующего опроса.
Я пока для себя снял проблему подстройкой mysql и запуском housekeeper-а раз в 10 минут - теперь он вместо 40-80 секунд работает 4-5 секунд и очередь insert-ов не успевает особо разрастись.
Еще в голове бродит мысль, для себя в исходниках заменить все insert-ы в "тяжелые таблицы" на insert delayed - и посмотреть улучшит ли это ситуацию. Мне кажется, это позволит "размазать" по времени возникающие высокие нагрузки.
2008-05-27
Вышеуказанные меры не помогли.
Копаю дальше :)