Distributed monitoring частота синхронизации

[ugh]

казалось бы, нода должна отсылать изменения конфигурации каждые 2 минуты, но на деле:
41125:20100929:141106.082 NODE 9: Sending configuration changes to master node 33 for node 9 datalen 8
41125:20100929:141902.686 NODE 9: Sending configuration changes to master node 33 for node 9 datalen 8
41125:20100929:142151.304 NODE 9: Sending configuration changes to master node 33 for node 9 datalen 8
41125:20100929:142615.872 NODE 9: Sending configuration changes to master node 33 for node 9 datalen 8
41125:20100929:142902.998 NODE 9: Sending configuration changes to master node 33 for node 9 datalen 8
41125:20100929:143211.583 NODE 9: Sending configuration changes to master node 33 for node 9 datalen 8
41125:20100929:143623.718 NODE 9: Sending configuration changes to master node 33 for node 9 datalen 8
41125:20100929:144507.248 NODE 9: Sending configuration changes to master node 33 for node 9 datalen 8

должна отсылать историю каждые 10 сек, но на деле:
41125:20100929:142147.918 NODE 9: Sending history_uint_sync of node 9 to node 33 datalen 10976
41125:20100929:142606.578 NODE 9: Sending history_uint_sync of node 9 to node 33 datalen 17197
41125:20100929:142857.569 NODE 9: Sending history_uint_sync of node 9 to node 33 datalen 11594
41125:20100929:143204.474 NODE 9: Sending history_uint_sync of node 9 to node 33 datalen 11950
41125:20100929:143616.129 NODE 9: Sending history_uint_sync of node 9 to node 33 datalen 16609
41125:20100929:144453.816 NODE 9: Sending history_uint_sync of node 9 to node 33 datalen 34609
41125:20100929:144930.658 NODE 9: Sending history_uint_sync of node 9 to node 33 datalen 18152

все бы ничего, но появления на мастере проблем от чайлдов иногда приходится ожидать 5-10 мин
как так? куда смотреть? чего не хватает?

*Zabbix Server v1.8.3 (revision 13928) (16 August 2010)
*с загруженностью мастера вроде бы все нормально


да, забыл совсем, из доки: Child Node will resend data in case of communication problems. а получаем совсем наоборот:
на мастере лог:
68703:20100929:115738.224 NODE 33: Error while receiving answer from Node [9] error: ZBX_TCP_READ() failed [Interrupted system call]
а на ноде после этого 2 часа тишины:
41125:20100929:114850.867 NODE 9: Sending configuration changes to master node 33 for node 9 datalen 2357
41125:20100929:!!!!!115235!!!!!.852 NODE 9: Sending configuration changes to master node 33 for node 9 datalen 517
41125:20100929:!!!!!135302!!!!!.460 NODE 9: Sending configuration changes to master node 33 for node 9 datalen 998
41125:20100929:135849.732 NODE 9: Sending configuration changes to master node 33 for node 9 datalen 8
41125:20100929:140713.978 NODE 9: Sending configuration changes to master node 33 for node 9 datalen 8
41125:20100929:141106.082 NODE 9: Sending configuration changes to master node 33 for node 9 datalen 8

[ugh]

нет спецов по распределенному мониторингу в русской ветке похоже)
пойду в трабшутинг)

[solo]

А можно ссылку на дискуссию в трабшутинге?

[dima_dm]

А может быть ну их эти Node? Как говорил Alexei Vladishev, разработчики Zabbix планируют вообще отказаться от Node в будущих версиях и оставить только Proxy. Но, конечно, это не истина в последней инстанции, и разработчики всё могут переиграть. :)

[Jimson]

ну в таком случае нужны цепочти проксей, потому что сервер-прокси-хост одназначно не достаточно
к тому же идея именно разспределенного мониторинга сама по себе крута, не у всех сеть ограничивается одной комнатой-этажом-зданием

думаю врядли откажутся :) хотя проблем с dm многовато

[dima_dm]

думаю врядли откажутся :) хотя проблем с dm многовато
Можно и цепочки Proxy сделать. Вполне Proxy может заменить Node http://www.zabbix.com/documentation/ru/1.8/manual/proxies пункт 14.2, конфигурируется проще, восстанавливается элементарно, схема проще, а значит надежнее. Только опции "Локальное администрирование" нет. Напомню, что данную информацию я получил лично от Alexei Vladishev, а он является архитектором Zabbix, т.е. источник очень авторитетный. Кто же может лучше знать всё о будущем Zabbix, как не он?:)

[Jimson]

ну, с точки зрения надежности проекта в целом лучше избавиться от DM на данном этапе, особенно если на повестке дня куча других расширений функционала, которые в случае с DM реализовать на порядок сложнее
но с точки зрения функицонала DM сам по себе является очень и очень весомым плюсом
ставлю на то что функционал в нынешнем его виде останется, возможно это будет нечто среднее между проксей и слейв-сервером

кстати, прокся на первый взгляд (я конечно же не весь код проштудировал а только маленький кусочек) один в один сервер, за той лишь разницей что часть функций выпилина, т.е. у них банально удалено содержимое начисто, например, process_event()
так что по сути что прокся, что нода, разница не так и велика, только в процедуре синхронизации данных, и я пока не могу догадаться в чем там может быть проблема, видимо есть какие то осбенности не позволяющие просто мержить все таблицы (id всех объектов уже разделены)

P.S. в любом случае, пока пытаемся использовать, свою схему я уже обрисовывал: слейв нода на сервере с кучей jail-ов, в каждом jail живет прокся через которую слейв-нода опрашивает внутренности VPN-а в который "смотрит" jail, таких слейв-нод две, притом вторая в новосибирске, никакая другая схема в данном случае не позволит реализовать задуманное

P.P.S. а круто бы выглядело решение с нодами но без явного разделения на мастер-слейв, а с опцией для каждой ноды какие конфигурации соседних нод хранить в своей базе, вышла бы резервируемая система с практически мгновенным востановлением (скрейтили базу и запустили сервер с указанием собственного ID и адреса сервера с которого можно скачать содержимое базы), мечты :)