Zabbix 3.2

ну что? пошлешь им патч?:)

Суть не в том, чтобы прислать им патч (напрмер, для фронтенда мы переписали запросы конкретно под MySQL, так что это далеко не универсальное решение), суть в том, что по самой больной проблеме Zabbix'а - проблеме хранения истории, разработчики не предлагают никакой разумной концепции.

Патч должен выглядеть примерно как: «а давайте решим, что метрика, которая не собиралась N периодов обновления - неактуальна, и триггеры на её основе считать нельзя». И можно даже теоретическую базу под это подвести: «Вы знаете, а триггер, посчитанный по метрике месячной давности, может слегка не соответствовать действительности».

Ну и добавить ещё: «А давайте всё-таки историю хранить связанным списком, давайте подумаем как сделать так, чтобы в текущем значении итема была ещё и ссылка на предыдущее значение, чтобы не искать это значение тупым перебором миллиардов строк в базе».

Если это реализовать собственными силами - то получится наверное немного другой Zabbix, очередной мега-форк.

Чтобы что-то делать в рамках общего проекта - нужно сначала подумать, как это должно быть, а потом сделать. Вы где-нибудь видели, чтобы в проекте Zabbix разработчики не из соотв. латвийской компании усленно думали над судьбой дальнейшей разработки?

напрмер, для фронтенда мы переписали запросы конкретно под MySQL

Я так сразу и предположил выше.

Чтобы что-то делать в рамках общего проекта - нужно сначала подумать, как это должно быть, а потом сделать. Вы где-нибудь видели, чтобы в проекте Zabbix разработчики не из соотв. латвийской компании усленно думали над судьбой дальнейшей разработки?

Ха, и как это должно выглядеть? Они составляют релиз цикл после обсуждения со спецами из твоей компании? А может, вы возьмете на себя часть усилий по реализации этих исправлений на уровне концепции? И их релиз план будет зависеть от плана отпусков DRVTiny и от приоритетов на его основной работе?

Т.е. по сути в начале треда ты им выкатил претензию, что запросы у них тормозные и их можно в разы оптимизировать. В это я как раз верю. Видел я фронтенд под нагрузкой. Но вот все остальное не реалистично. Было бы больше пользы, если бы ты патчи для фронтэнда на гитхаб сложил. Тем более, если это патчи для LTS выпуска. Я еще подозреваю, если ты попробуешь это сделать, то тебе еще и по НДА настучат.

И отдельный «бе» за MySQL. Посмотри-послушай, как на HL++ его разносят за двойное ведение лога. Вроде бы тоже отвечаешь за большой проект, а выбор базы вызывает сомнение. Соринка в одном глазу, бревно в другом.

MySQL - это выбор конторы. На нынешнем месте работы заведено так, что базами должны заниматься специалисты-DBA. А они у нас повально MySQL'щики с искуственно привитым сакральным знанием Tibero (если мне маразм не изменяет, Tibero - творение узкоглазых из Huawei).

Я бы поставил на PostgreSQL. Что на HL++ думают о постгресе?

Ха, и как это должно выглядеть?

Как открытое OpenSource-сообщество, в котором направление развития обсуждается коллегиально, а не как закрытый коллектив во главе с Алексеем Владышевым, с высоты посматривающий на простых смертных, изволящих подносить к ограде с колючей проволокой свои мерзкие патчики.

Вообще разве может в современном OpenSource-проекте даже речь идти о каких-то патчах? Изменения должны приниматься через систему контроля версий, а не файликами с diff'ами!

Вот как раз хвалят.

ну тогда у них релиз цикл будет, как у дебиана.:)))