Zabbix server перестает запрашивать key:'agent.ping'

[konst.sereda]

Добрый день.
Прошу помочь разобраться со странным поведением Zabbix server.
После перезапуска сервера или добавления нового хоста некоторое время (10-15 мин) agent.ping от хоста стабильный (каждую минуту в соответствии с настройкой item) , далее значения пропадают и поступают нестабильно с большими перерывами (15-20 мин), восстанавливаются и вновь пропадают (явной зависимости не прослеживается). Судя по дебаг логу сервер перестает запрашивать значение - нет строк "In get_value_agent()... key:'agent.ping'". В это же время, в ручном режиме zabbix_get возвращает значение 1 от хоста, т.е. на стороне агента в этот момент все в порядке. Пробовал менять интервал item, кол-во пулеров (очереди нет), удалял/добавлял хост. Проблема касается не всех хостов, а только некоторых. Началась это проблема после какого-то из обновлений сервера. На данный момент сервер версии 3.2.3. Агент passive checks.

[aib]

Проверьте график Zabbix Internal Process busy %
Возможно, что у вас какие-то процессы загружают сервер до 100%, останавливая другие процессы.
Например, Housekeeper страдает таким поведением - при запуске загружает сервер так, что никакие сборщики данных стартовать не могут...

[konst.sereda]

Алексей, спасибо за наводку. Действительно с housekeeper есть проблема. Я для начала провел ревизию показателей и убрал лишние, тем самым уменьшив кол-во items в два раза. Прошло меньше недели, но заметного улучшения не видно. Возможно, что требуется время больше недели, т.к. многие данные хранились как раз 7d. Т.е. я надеюсь, что housekeeper`у придется меньшее данных зачищать и это поможет. Меня больше смущает другое. Почему проблема "рваных графиков" существует не для всех хостов. По некоторым хостам все хорошо и нет никаких разрывов в получаемых данных. С хостами в одной подсети (172.16.0.x) проблем нет, за исключеним одного (возможно что-то локальное). С хостами в подсети 192.168.2.х проблем больше, но опять же не 100% проблемные. Причем, подсети эти локальные и роутинг в пределах одного L3 свича. Я не пойму с чем связана такая избирательность. Почему забикс часть хостов опрашивает исправно в соотв. с настройками items, а у части хостов запрашивает данные с разрывами.
На что еще обратить внимание ?

[konst.sereda]

Некоторый тюнинг MySQL видимо решил проблему (еще наблюдаю).
Стало: housekeeper [deleted 209897 hist/trends, 0 items, 5 events, 0 sessions, 0 alarms, 0 audit items in 11.879903 sec, idle for 1 hour(s)], а было тоже кол-во за 230 - 350 сек.
График теперь не достигает 100% и нормализовались графики данных от агентов.
Еще раз спасибо!

[Aleks.Karavai]

Столкнулся с похожей проблемой, zabbix просто не запрашивает данные. Можно поподробнее рассказать, какие оптимизации для базы были сделаны?

[konst.sereda]

На стороне zabbix-server уменьшил кол-во пулеров StartPollers=3 , StartIPMIPollers=1, StartPollersUnreachable=2, StartPingers=3.
Увеличил Timeout=15 .

На MySQL:

innodb_file_per_table=1
innodb_file_format=barracuda
innodb_strict_mode=1
#innodb_buffer_pool_size=3G (уменьшил, т.к. на машине всего 4)
innodb_buffer_pool_size=2G
innodb_additional_mem_pool_size=200M
innodb_log_file_size=64M (увеличил)
innodb_log_buffer_size=8M (увеличил)

#innodb_flush_method=O_DIRECT (перешел на O_DSYNC)
innodb_flush_method=O_DSYNC
innodb_buffer_pool_instances=4
innodb_flush_log_at_trx_commit=0
innodb_old_blocks_time=1000
tmp_table_size=256
max_heap_table_size=256
table_cache=256

Я не могу точно сказать что именно сработало, но думаю что переход на O_DSYNC и увеличение innodb_log.
Zabbix на ОС Debian.
Number of items (enabled/disabled/not supported) 5021 2243 / 2679 / 99
Number of triggers (enabled/disabled [problem/ok]) 1146 1142 / 4 [11 / 1131]
Required server performance, new values per second 27.81

[Aleks.Karavai]

В моём случае база на rds. Поэтому тюнинг не удастся) Игра с пуллерами результатов не принесла. А вот пересоздание item работает как часы, но всё равно причина не установлена(

[Aleks.Karavai]

Хотя вру, с Amazon RDS можно тоже поменять. Создание ITEMS новых не лучший вариант, но пока рабочий)