Zabbix 1.8.2 перестаёт опрашивать хосты по SNMP и Zabbix_Agent

[dima_dm]

Сталкнулся с такой проблемой на последней стабильной версии Zabbix 1.8.2 (revision 11211). zabbix_server периодически перестаёт опрашивать хосты по SNMP и Zabbix_Agent (либо данные в базу не поступают, на графиках пропуски в момент проблемы, пример в приложении). Происходит раз в 1-2 дня, в основном ночью в интервал с 22:00 до 1:00. Backup базы происходит в 1:00 раз в 3 дня, поэтому у меня нет оснований связывать проблему с degrade производительности базы во время Backup. Лечится перезагрузкой zabbix_server. На закладке Администрирование-> Очереди большие очереди. После рестарта zabbix_server, очереди полностью рассасываются приблизительно за 10 минут.
На предыдущей стабильной версии Zabbix 1.8.1 таких проблем не наблюдалось. В логах ничего криминального нет. Есть подозрение, что это какой-то bug, но с чем он связан из-за большого количества хостов на мониторинге, понять не могу.
У кого-нибудь наблюдаются подобные проблемы?
Есть идеи, что это может быть?

[dima_dm]

Проблема повторилась. Я снял Dump сетевого трафика, опрос устройств по SNMP Zabbix Server ведёт успешно.
Однако данные ни в таблицу history_uint ни в trends_uint не попали. (Для чистоты эксперимента я подождал, пока все накопившиеся очереди обработаются.) В данном случае, проблема наблюдалась с 2010-08-03 11:07:56 по 2010-08-03 11:42:54. Проблема исчезла после рестарта Zabbix Server

select *,from_unixtime(clock)  from history_uint where itemid="108172";
+--------+------------+-------+----------------------+
| itemid | clock      | value | from_unixtime(clock) |
+--------+------------+-------+----------------------+
| 108172 | 1280818674 |    24 | 2010-08-03 10:57:54  |
| 108172 | 1280818974 |     8 | 2010-08-03 11:02:54  |
| 108172 | 1280819276 |     8 | 2010-08-03 11:07:56  |
| 108172 | 1280821374 |     8 | 2010-08-03 11:42:54  |
| 108172 | 1280821674 |     8 | 2010-08-03 11:47:54  |
| 108172 | 1280821974 |     8 | 2010-08-03 11:52:54  |
| 108172 | 1280822274 |     8 | 2010-08-03 11:57:54  |
| 108172 | 1280822574 |     8 | 2010-08-03 12:02:54  |
| 108172 | 1280822875 |     8 | 2010-08-03 12:07:55  |

select *,from_unixtime(clock) from trends_uint where itemid="108172";
+--------+------------+-----+-----------+-----------+-----------+----------------------+
| itemid | clock      | num | value_min | value_avg | value_max | from_unixtime(clock) |
+--------+------------+-----+-----------+-----------+-----------+----------------------+
| 108172 | 1280808000 |  12 |         8 |         8 |        24 | 2010-08-03 08:00:00  |
| 108172 | 1280811600 |  12 |         8 |         8 |         8 | 2010-08-03 09:00:00  |
| 108172 | 1280815200 |  12 |         8 |         9 |        24 | 2010-08-03 10:00:00  |
| 108172 | 1280818800 |   4 |         8 |         8 |         8 | 2010-08-03 11:00:00  |
| 108172 | 1280822400 |  12 |         8 |         8 |         8 | 2010-08-03 12:00:00  |
| 108172 | 1280826000 |  12 |         8 |         8 |        24 | 2010-08-03 13:00:00  |
+--------+------------+-----+-----------+-----------+-----------+----------------------+

В данном примере интересен тот факт, что за период с 11:00-12:00 было собрано 6 значений, однако trend построен только по 4-м из них, т.к. последние 2 значения 2010-08-03 11:52:54 и 2010-08-03 11:57:54 не успели, из-за очередей, записаться в базу к моменту построения trend. Т.е. trend не пересчитывается, если данные придут позже. Это, по моему мнению, неправильно.

Значения собранного в 11:37:54 в базе нет.
11:37:54.598044 IP yyyyyyyy.48392 > DMZ-Q14.snmp: C=XXXXXX GetRequest(31) interfaces.ifTable.ifEntry.ifInOctets.10030
11:37:54.600083 IP DMZ-Q14.snmp > yyyyyyyy.48392: C=XXXXXX GetResponse(35) interfaces.ifTable.ifEntry.ifInOctets.10030=868852 359

Я предполагал, что проблема может быть связана только с Item, в которых значения хранятся как Дельта (скорость в секунду), т.к. для вычисления дельты нужны последовательно два значения переменной. Однако мое предположение не оправдалось, т.к. данные не попали в базу также и по Item, в которых значение хранится “как есть”.
Таким образом, можно сделать вывод, что в момент проблемы данные успешно собираются, но почему-то не попадают в базу данных.

[ugh]

может хаускипинг?

[dima_dm]

А можно подробнее? При чём тут хаускипинг?
Данные свежие, должны храниться, по настройкам Item, 7 дней.

[ugh]

имеется ввиду что чистка хаускипингом табличек с хистори может помешать заноситься втуда новым данным
если проблема регулярна - отключите полностью хаускипинг и проверьте (если помогло - http://www.zabbix.com/forum/showpost...1&postcount=10)
ps. у меня просто тоже данные переставали поступать в базу в свое время

[dima_dm]

Раньше проблема проявлялась регулярно, сейчас очень редко, с 21-05-2010 раза 4-5.
Настройки у меня такие
### Option: HousekeepingFrequency
# How often Zabbix will perform housekeeping procedure (in hours).
# Housekeeping is removing unnecessary information from history, alert, and alarms tables.
# If PostgreSQL is used, suggested value is 24, as it performs VACUUM.
#
# Mandatory: no
# Range: 1-24
# Default:
HousekeepingFrequency=24

Параметр MaxHousekeeperDelete у меня не определен в /etc/zabbix/zabbix_server.conf
Под MySQL у меня отдельный сервер HP DL360G5 с 4-х ядерным CPU E5430 @ 2.66GHz и 8Gb Memory, 64 –х разрядная OS Red Hat Enterprise Linux 5, и загрузка CPU у него не высокая, в среднем 92% idle и памяти ему хватает, не Swap-ирует ничего.

Мне кажется, что проблема в механизме хранения данных (очереди) zabbix_server перед помещением данных в базу. Кто-нибудь разбирался, как zabbix_server это делает? Где хранит данные? Реализация блокировок при работе нескольких процессов с общей очередью?
Добавил мониторинг zabbix[queue], буду собирать статистику.

[ugh]

эммм... ну как?

[dima_dm]

Пока проблема не проявлялась, ждем. Уже скоро выйдет стабильный Zabbix 1.8.3, и я буду исследовать проблему на нём, если она проявится. Сейчас я работаю над списком проверок, которые буду выполнять в момент проблемы, чтобы получить как можно более полную картину происходящего и собрать информацию для размышления. Если у кого-то есть идеи, Welcome.

[dima_dm]

Пока придумал следующие проверки.
1) Dump сетевого трафика на всех интерфейсах (за интервал 10 минут)
2) Сохранить MySQL bin log ( по нему я увижу, заносятся ли вообще данные в MySQL и по delete, работает ли в это время Housekeeping)
3) Загрузка памяти, процессора процессами
4) Протрассировать процессы zabbix_server утилитой strace и ltrace, остается непонятным как определить PID-ы процессов zabbix_server, которые работает с очередью, видимо придётся трассировать все процессы zabbix_server, которые подключаются к MySQL.

[lentyai]

Пока придумал следующие проверки.

Кроме этого проверь iowait, Device util %, Device await, Device avgqu для диска, на котором хранится БД.
Может быть, вся проблема кроется в том, что не достаточно быстрый RAID.
Если в качестве хранилища используется NAS, то проблема может быть как в том, что этот NAS во время проблем используется еще кем-то, либо в настройках ISCSI или сети. И с таким сталкивался.

Еще может быть все банальнее, добавь количество поллеров в конфиге сервера. Если их там по 5-10 этого может сильно не хватать.

У меня было, что при росте очереди до 12000 шла сильнейшая деградация производительности. Заббикс затыкался. Мотиторить было ничего не возможно.

Но это было на 4-х ядерной системе с 4 Гб памяти.

С тех пор мы перевезли заббикс сервер на кластер из двух серверов.

[dima_dm]

C производительностью дисковой подсистемы там всё хорошо, загрузка примерно одинаковая, не растёт скачками. Статистику снимаю с Smart Array P400i контроллера. Используется RAID 1+0 на 4-х SAS дисках. График за 3 месяца в Attach.

По поводу Pollers, у меня запущено
StartPollers=20
Но как показал эксперимент, проблем со сбором данных нет, есть проблемы с загрузкой их в базу.

[ruswold]

C производительностью дисковой подсистемы там всё хорошо, загрузка примерно одинаковая, не растёт скачками. Статистику снимаю с Smart Array P400i контроллера. Используется RAID 1+0 на 4-х SAS дисках. График за 3 месяца в Attach.

По поводу Pollers, у меня запущено
StartPollers=20
Но как показал эксперимент, проблем со сбором данных нет, есть проблемы с загрузкой их в базу.

У меня такое бывает, когда возникает ошибка или записи или транзакции в mysql, и mysql откатывает базу обратно, используя журнал. При этом в логах заббикса пишет cannot connect to mysql socket.

А иногда аналогичная ситуация. Часть данных есть, например пинг, а другая часть отсутствует по всем хостам.
Сейчас сижу на версии 1.8.3.rc3 и вроде как все нормально с этим.

[dima_dm]

Забыл отписать, что нашёл причину возникновения этой проблемы.
Причиной всему были сбои в работе блока питания MySQL сервера. Соответственно, когда сервер базы данных перегружался, мониторинг переставал работать и никаких проблем в этот момент Я не видел :-) Добавил полезный триггер в шаблон Template_Linux, чтобы отслеживать перезагрузку серверов.

{Template_Linux:system.uptime.last(0)}<1800

Кстати, почему-то Администрирование-> Общие -> Прочие параметры ->Сообщение для группы пользователей при недоступности базы данных
не сработало ни разу.