LINUX.ORG.RU

Zabbix 3.2

 ,


5

1

Вышла новая версия мощной мониторинговой системы Zabbix 3.2, ставшая ещё более удобной, гибкой и эффективной в использовании. Zabbix — бесплатная система с открытым исходным кодом для мониторинга IT-инфраструктуры, подходящая как для маленьких компаний, так и для больших корпораций.

Новые возможности релиза:

  • добавление тэгов к триггерам и событиям;
  • использование тэгов для корреляции событий;
  • организация узлов сети во вложенные группы;
  • ручное закрытие проблем;
  • облегченное написание условий для гистерезиса;
  • просмотр элементов, созданных с помощью низкоуровневого обнаружения;
  • приостановка эскалаций на время обслуживания;
  • указание операций восстановления в действиях;
  • экспорт и импорт веб-сценариев;
  • вычисление функций для неподдерживаемых элементов данных;
  • новые опции и элементы данных для быстрорастущих лог-файлов;
  • поддержка регулярных выражений в функции count();
  • применение регулярных выражений к значениям макросов.

>>> Подробности



Проверено: Falcon-peregrinus ()
Последнее исправление: Klymedy (всего исправлений: 4)

Ответ на: комментарий от RiD

но слова «3k хостов и куча метрик» - это фигня.

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

crypt ★★★★★
()
Последнее исправление: crypt (всего исправлений: 1)
Ответ на: комментарий от RiD

А что пишет Zabbix в «required server performance»? Прямо вот так 15000 и пишет? Ну вы там просто звери...

И можно глупый вопрос?

Если у вас там супер-критичные веб-приложения, простой стоит безумно дорого, кошмар-кошмар и всё прочее, то...

Вы не пробовали как-то сподвигнуть самих разработчиков отправлять сообщения об ошибках и проблемах в приложении в единую систему логирования, откуда эта информация могла бы поступать хоть в Zabbix, хоть в Tivoli - куда угодно, лишь бы СМ умела работать в режиме приёма трапов? Можете даже SNMP-трапы генерить, жалко что ли.

Я категорически не понимаю маниакального стремления что-то мониторить «извне», имея в компании штат разработчиков всего того чудо-добра, которое у вас мониторится. Поверьте, при должном радении разработчиков приложение само себя будет мониторить в 10^6 раз лучше любой СМ, которая ничего о приложении по дефолту не знает.

У вас же не происходит 15000 проблемных событий в секунду? Ну так старайтесь работать не в режиме опроса, а в режиме «прерываний», когда само приложение сообщает через систему логирования, что там с ним не так.

Обычно в отечественных компаниях почему-то принято разрабатывать «под себя» софт, не умеющий даже толком логи вести, не то что о проблемах сообщать. И по-моему ни одна СМ с этим маразмом не справится: никто не знает приложение и возможные проблемы с ним лучше самих разработчиков!

DRVTiny ★★★★★
()
Ответ на: комментарий от crypt

Речь не о простое IT компонент. Вот пример. У нас значительный ввод/вывод средств. Иногда случается так, что программисты ошиблись, а пользователи заметили эту ошибку в каком-то экзотическом сценарии. И тут пользователи понимают, что наша ошибка может помочь им хорошенько заработать.) Для отслеживания такой ситуации у нас имеется целый круглосуточный отдел фин. мониторинга. В помощь этому отделу имеется софт, который анализирует кучу параметров и формирует предупреждения. Если такое предупреждение сработало, то дежурный приостанавливает платежки по этой компоненте и проводит проверку - является ли данный всплеск легитимным. Как Вы понимаете, первой итерацией мы попробовали настроить алерты в zabbix, второй итерацией - тянуть с zabbix по api и анализировать в java-коде. Третьей - графит + java. К этому подтолкнул сам заббикс, который, на практике, не может всегда быстро(<1s) отвечать по апи, даже при запросе метрик за короткие интервалы.

RiD
()
Ответ на: комментарий от DRVTiny

Вы не пробовали как-то сподвигнуть самих разработчиков отправлять сообщения об ошибках и проблемах в приложении в единую систему логирования, откуда эта информация могла бы поступать хоть в Zabbix, хоть в Tivoli - куда угодно, лишь бы СМ умела работать в режиме приёма трапов? Можете даже SNMP-трапы генерить, жалко что ли.

Пробовали. Движемся именно в этом направлении. Мы отправляем в new relic(конечно намного меньше, чем собираем заббиксом с логов/jmx) и через аналогичный релику самописынй плагин в графит.

В целом по комментарию согласен полностью.

RiD
()
Ответ на: комментарий от RiD

А это, конечно, другое дело. Я-то думал у вас хостинг (Zabbix все-таки под это затачивают), а вы его для платежной системы хотите использовать. По сути в таких случаях мы тоже всегда выносили аналитику (процессинг, обработку) из заббикса. Он не для real time, но может служить для хранения агрегированных и проанализированных данных. Хотя опять же snmp трапы никто не отменял. Тут либо покупать специализированную систему (думаю для платежных систем они есть и недешевые), либо писать самим. У вас и API заработает, если вы перестаните прямо все и сразу валить в заббикс, а сделаете где-то предобработку.

crypt ★★★★★
()
Последнее исправление: crypt (всего исправлений: 1)
Ответ на: комментарий от Deleted

Нет способа, парсер там ддеревянный. Но используй макросы, внутри макросов щапятые прокатывают.

anonymous
()
Ответ на: комментарий от Deleted

Нет способа, парсер там ддеревянный. Но используй макросы, внутри макросов щапятые прокатывают.

anonymous
()
Ответ на: комментарий от anonymous

та уже написал скрипт, который выпрямляет запрос. лютота лютая батники писать !

Deleted
()
Ответ на: комментарий от RiD

К этому подтолкнул сам заббикс, который, на практике, не может всегда быстро(<1s) отвечать по апи, даже при запросе метрик за короткие интервалы.

Боюсь, что API только добавляет тормозов, вам быстрее было бы последние данные из базы напрямую грести.

Причём у этого так называемого «API» ещё есть приятная особенность ведь: если запрос в базу длится больше определённого количества времени, в PHP-шный обработчик API вернётся undef/null - и эта зараза покажет потом это в теле запроса прямо как есть. Т.е. длинный запрос в history не только может, но и будет выглядеть как запрос, не вернувший данных при том, что это вообще ни разу не так. Я как-то жестоко погорел на этом, и после этого стараюсь минимизировать общение с API до нетривиальных случаев, когда просто непонятно, как составить запросы в базу или там одним-двумя запросами дело не ограничивается и логика достаточно сложная (например, trigger.get с параметрами expandDescription или expandExpression).

DRVTiny ★★★★★
()

Системы мониторинга чего? Наличия туалетной бумаги в офисе или уровня топлива в баллистической ракете?

Ferroman
()
Ответ на: комментарий от alexvl

Партиционирование решит все эти проблемы.

Не решит. Ибо ваш кривой алгоритм кэширования данных в памяти поражает своим радиусом кривизны. Этож кто додумался принятое значение сначала пихать в базу данных, а только потом из нее выгребать назад в кэш? Да еще и не просто выгребать, а с нечетким условием.

24214 Query     begin
24214 Query     insert into history (itemid,clock,ns,value) values (102225,1467902685,714945790,0.010000),(23265,1467902685,715129549,0.000000)
24214 Query     /*vc_db_read_values_by_time*/ select clock,ns,value from history where itemid=102225 and clock>1467902385 and clock<=1467902685
24214 Query     /*vc_db_read_values_by_time*/ select clock,ns,value from history where itemid=23265 and clock>1467902085 and clock<=1467902685
24214 Query     commit

Молодцы, чё.

Триггер last() засношает SQL запросами, если вдруг последнее значение итема как-то оказалось очень глубоко похоронено в базе.

Большие инсталляции Zabbix начинаются от 5-10K проверок в секунду

О, какое удобное описание процесса - 10K vps. Это же не означает, что это 10K триггеров в секунду? А 10K строчек и bash запишет без напряга в текстовый файлик.

LynxChaus
()
Ответ на: комментарий от crypt

Я-то думал у вас хостинг (Zabbix все-таки под это затачивают)

Да ладно? Оно же ынтерпрайз-левел мониторинг сыстем.

Он не для real time, но может служить для хранения агрегированных и проанализированных данных.

А нафиг тогда он нужен, если обработку выносить за сарай? Можно и самому сборщик-хранилку написать.

LynxChaus
()
Ответ на: комментарий от LynxChaus

Ибо ваш кривой алгоритм кэширования данных в памяти поражает своим радиусом кривизны.

При всём уважении, нужно всё-таки разбираться в теме прежде чем утверждать подобное.

Это же не означает, что это 10K триггеров в секунду?

Именно это и означает.

alexvl
()
Ответ на: комментарий от ergil

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

Я с удовольствием приеду рассказать о 3.2 и других темах интересных сообществу. Просто нужно договориться о площадке и дате.

Кстати, очень вероятно, что я с коллегами буду на конференции Highload с нашим стендом. Решение о моём выступлении там ещё не принято, жду.

alexvl
()
Ответ на: комментарий от RiD

Не решает партицирование этой проблемы. Я написал, что 10-20 метрик с хоста в секунду, т.е. 1000*15 ~15k проверок в секунду. Но у нас около 2k хостов и проверок без сбора данных тоже имеется достаточно.

Наше железо, полагаю, близко к топовому.

Повторюсь, что при таких цифрах наблюдаемых проблем не должно быть. Хотя, не исключаю, что картина может зависеть от многих факторов, например, сложности триггеров, специфики работы пользователей с интерфейсом, и прочее, да и на железо надо посмотреть.

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

alexvl
()
Ответ на: комментарий от RiD

На заббиксе сделать не смогли(там вообще не так-то просто сделать алерт, который анализирует N других графиков и в зависимости от своей мат. функции формирует предупреждение).

Пробовали использовать агрегированные проверки: https://www.zabbix.com/documentation/3.2/ru/manual/config/items/itemtypes/agg... ?

alexvl
()
Ответ на: комментарий от DRVTiny

А что пишет Zabbix в «required server performance»? Прямо вот так 15000 и пишет? Ну вы там просто звери...

А можно узнать параметры сервера БД который это вывозит?

Кстати, required server performance по прежнему учитывает только то, что заббикс сам собирает (не учитывая данные которые trapper)?

EuGeneus ★★
()
Ответ на: комментарий от DRVTiny

Вы не пробовали как-то сподвигнуть самих разработчиков отправлять сообщения об ошибках и проблемах в приложении в единую систему логирования, откуда эта информация могла бы поступать хоть в Zabbix, хоть в Tivoli - куда угодно, лишь бы СМ умела работать в режиме приёма трапов? Можете даже SNMP-трапы генерить, жалко что ли.

Не согласен в случае мониторинга оборудования сети передачи данных. В нормальных то условиях трапы не всегда долетают. В любом случае придётся, как минимум, пинговать каждый узел. И я говорю про сети 10к+ устройств.

anonymous
()
Ответ на: комментарий от EuGeneus

А что пишет Zabbix в «required server performance»? Прямо вот так 15000 и пишет? Ну вы там просто звери...


А можно узнать параметры сервера БД который это вывозит?

В среднем это будет 24 ядра, ближе к 256GB памяти и очень быстрое хранилище.

Кстати, required server performance по прежнему учитывает только то, что заббикс сам собирает (не учитывая данные которые trapper)?

А это невозможно учитывать. Zabbix ведь не может предположить сколько будет трапов или объём собираемых лог файлов.

alexvl
()
Ответ на: комментарий от alexvl

А это невозможно учитывать. Zabbix ведь не может предположить сколько будет трапов или объём собираемых лог файлов.

Примерно посчитать статистику - можно Я как-то разбирал статистику айтемов по типам источников

Про Базу - извините, я забыл, что сам zabbix-server не сильно тяжёлый

А хранилище да, будет на хороших таких SSD типа 3710

EuGeneus ★★
()
Ответ на: комментарий от alexvl

Кстати, посмотрел я на фичи 3.2 - очень заманчиво всё

Единственно, народ пугает изменением логики/структуры базы, но это наживное

EuGeneus ★★
()
Ответ на: комментарий от DRVTiny

вам быстрее было бы последние данные из базы напрямую грести

угу, тоже так делали

crypt ★★★★★
()
Ответ на: комментарий от EuGeneus

Народ пугает кривым скриптом обновления базы, который нужно руками править, чтобы он не вываливался на частичном обновлении. Zabbix такой Zabbix :)

DRVTiny ★★★★★
()
Последнее исправление: DRVTiny (всего исправлений: 1)
Ответ на: комментарий от alexvl

например, сложности триггеров, специфики работы пользователей с интерфейсом

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

Оказалось, что SQL-запросы фронтенда отрабатывают так: 98% времени тратится на проверку прав доступа пользователя, 2% времени - на выполнение относительно сложного запроса по сработавшим триггерам. Наши DBA-шники допилили эти SQL-запросы и стало: 95% времени на сам запрос данных и 5% - проверка прав доступа.

Это было... неожиданно. И не очень приятно, поскольку таких, мягко говоря неоптимальных SQL-запросов даже в коде сервера было наковыряно нами весьма немало.

DRVTiny ★★★★★
()
Ответ на: комментарий от DRVTiny

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

Не надо пугаться. Со скриптом обновления проблем нет. Похоже, что что-то в связке пакетов с systemd. Тут подробности:

https://support.zabbix.com/browse/ZBX-11203

alexvl
()
Ответ на: комментарий от alexvl

странно. сегодня обновил свой zabbix. БД ковертил довольно долго, но справился. вроде ничего критичного не отпало.

llirik
()
Ответ на: комментарий от DRVTiny

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

Меня pgpool2 + memcache выручает. 72-79% запросов отдаются из кеша. Но всё равно, нагрузка от юзеров это 70-80% на базу

https://image-store.slidesharecdn.com/3200ec48-7aff-405c-9050-2f0d753dcc02-la...

EuGeneus ★★
()
Ответ на: комментарий от DRVTiny

может, вы под определенную базу затачивали, а они делают сразу на несколько? старые проблемы с ids были этим обусловлены.

crypt ★★★★★
()
Последнее исправление: crypt (всего исправлений: 1)

жалко, что все в этом треде игнорят вопрос с фейловером.

crypt ★★★★★
()
Ответ на: комментарий от LynxChaus

Можно и самому сборщик-хранилку написать.

ну так напиши:) мы тут просто все его используем, потому что не придумали варианта лучше для наших задач. а ты такой крутой кулхацкер, так пиши и осчастливь других.:)

crypt ★★★★★
()
Ответ на: комментарий от alexvl

При всём уважении, нужно всё-таки разбираться в теме прежде чем утверждать подобное.

При всём уважении, я выражаю своё мнение. А оно таково - этот кусок удивительно крив. Пытаться убедиться, что значение попало в базу посредине незакоммиченой транзакции - нафиг не нужно, это забота SQL. Я бы понял, если бы можно было в одну базу натравить 2 сервера - так этого нельзя, они её в кашу размешают.

Как прочем и остальной код - местами лапшевидное месиво из #ifdef'ов и прочих самопальных оберток над стандартными функциями, изобилующий варнингами всех мастей.

Именно это и означает.

Та щито фи говорите?

Как может вот этот запрос

SELECT SUM(CAST(1.0/i.delay AS DECIMAL(20,10))) AS qps FROM items i,hosts h WHERE i.status=0 AND i.hostid=h.hostid AND h.status=0 AND i.delay<>0 AND i.flags<>2;
отражать действительность? Оно же считает тупо количество итемов вместе с дисковреи-рулями, а не триггеры. Так что ваши 10K vps - это может быть 9.9K тупо данных (с history = 0) и 100 триггеров. Зато цифирь - огого!

LynxChaus
()
Ответ на: комментарий от crypt

мы тут просто все его используем, потому что не придумали варианта лучше для наших задач.

Я его тоже использую - так что я знаю о чем говорю.

а ты такой крутой кулхацкер, так пиши и осчастливь других.:)

Так они и счастливы, как только понимают что за энное количество хрустящих бумажек - случается счастье, которое от «официального производителя» можно ждать годами. Официальные расценки на всякие «улучшения» можно посмотреть тут: http://www.zabbix.com/development_services.php

Особливо радует 18K евро за сборку агента и прокси под android/arm. Побежишь вносить? Могу за 1/3 суммы поделиться собранным под RPi/BanaPi.

LynxChaus
()
Ответ на: комментарий от DRVTiny

У нас, если я не ошибаюсь, отдельный заббикс реагирует на алерты, сработки триггеров уезжают в спланк. В этом заббиксе много айтемов, но практически нет истории, а статистика по месту/сети/ресурсам хранится в отдельном инстансе. Там мало айтемов, но история длинная.

Туда-сюда действительно никто ничего не переливает.

Hoodoo ★★★★★
()
Ответ на: комментарий от alexvl

Алексей, а есть уже понимание того, что делать с SNMP-трапами?

Хотелось бы видеть список событий на хосте. Метрики и триггеры в данном случае немного совсем не ложатся на логику SNMP-трапов.

Почему? Да очень просто! Я не обязан знать все возможные события на оборудовании и матчить их регекспами - каждое в свою метрику, чтобы всё-таки алармы были тоже индивидуальны. Почему не обязан? А потому что в любом приличном MIB'е этих трапов может быть под несколько сотен штук.

Хотелось бы так: в разделе «SNMP»-проверок хоста задаёшь одно регулярное выражение для матчинга «возникновения проблемы», а другое - для матчинга «завершения проблемы». При этом, например, группировка $1 в регулярном выражении должна совпасть в тексте события-проблемы и события-клиринга, чтобы «проблема» очистилась с хоста.

Тогда на фронтенде может быть список: Monitoring->SNMP->Traps, где будут появляться и очищаться проблемы.

Можно это всё сделать и по аналогии с веб-проверками - тогда просто будут автоматом генерироваться метрики и триггеры к ним.

Вопрос только в том, зачем в принципе трапы матчить на метрики: складывать куски текста из трапов в базу - очень странное занятие, ведь по сути это просто мусор (zabbix - не спланк всё же).

Триггерное решение, предлагаемое сейчас разработчиками в офдокументации - это просто несерьёзно (особенно использование nodata для опускания триггера). По сути это просто намёк на то, что всё нужно делать самому через zabbix-trap'ы и встраивание своего Perl-скрипта в snmptrapd или snmptt - тогда можно будет создавать метрики динамически по мере поступления трапов нового типа.

DRVTiny ★★★★★
()
Последнее исправление: DRVTiny (всего исправлений: 1)
Ответ на: комментарий от alexvl

При обновлении(на тестовом стенде) на Ubuntu 16.04.1(то есть системе с systemd) сначала как-то странно вылезли сообщения про несоответствие версий базы, но перезапуском zabbix-server и mysql все полечилось(перезапуском только zabbix-server не вышло). Что это было за шаманство и почему так не знаю.

ergil ★★★
()
Ответ на: комментарий от LynxChaus

Я его тоже использую - так что я знаю о чем говорю.

[пожимая плечами] Какая разница, если в плане конструктива от тебя толку ноль? Что-то ты, может быть, и знаешь, но со своим брызганьем слюной и ломаным языком производишь впечатление неадеквата. Кому ты нужен?

Могу за 1/3 суммы поделиться собранным под RPi/BanaPi.

Да вроде я не просил... Ты сам сказал, что ты такой кулхацкер и все можешь сам написать. Я выше про фейловер спрашивал. Сможешь за эти деньги сделать синхронизацию кеша на двух zabbix server'ах плюс свести данные в одну базу с нагрузкой хотя бы 2000nvps?:) Скорее всего нет.

crypt ★★★★★
()
Ответ на: комментарий от DRVTiny

Хотелось бы видеть список событий на хосте.

Уверен, авторы заббикса такие пожелания получают пачками во время митапов и проблем с интересными идеями у них нет. Не думаю, что они вот так, дернут идею с форума и поставят ее в план разработки.:) Тут даже не тред платной поддержки. Скорее всего просто смотрят, нет ли 5 однотипных сообщений: «новая версия споткнулась о ...».

crypt ★★★★★
()
Ответ на: комментарий от DRVTiny

предельная глубина просмотра history при подсчёте функций (триггеры, вычисляемые метрики) - нигде не регулируется.

в SQL запросе нет ограничения по timestamp?

crypt ★★★★★
()
Ответ на: комментарий от crypt

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

DRVTiny ★★★★★
()
Ответ на: комментарий от crypt

Оно и понятно. Речь не об этом, а о том, что SNMP-trap'ы в Zabbix реализованы чисто формально по остаточному принципу «ну нельзя же, чтобы система мониторинга не умела работать с трапами». А по существу она и не умеет, поскольку степень автоматизации работы с ними в Zabbix близка к нулю.

То, как это сделать правильно - я думаю, разработчики прекрасно и сами понимают. Мессейдж скорее к тем, кто хочет мониторить Zabbix'ом хитроумное сетевое железо: пробовали уже, SNMP-поллинг в Zabbix создаёт дикий оверхед на саму систему мониторинга и на оборудование, а SNMP-трапинг в лучшем случае приводит к тому, что либо нужно заниматься кропотливым handjob'ом, либо писать самому код, объёмом и сложностью превышающий код обработки трапов в самом Zabbix многократно. И так здесь очень со многими вещами дело обстоит: я не знаю крупных компаний, которые бы работали с Zabbix и в определённый момент не начинали залезать к нему глубоко в кишки, либо писать к нему внешние громоздкие обвязки. Это что из разряда «Zabbix-бесплатная система мониторинга? ОК, но где вы найдёте к ней бесплатных программистов?»

DRVTiny ★★★★★
()
Ответ на: комментарий от DRVTiny

я не знаю крупных компаний, которые бы работали с Zabbix и в определённый момент не начинали залезать к нему глубоко в кишки, либо писать к нему внешние громоздкие обвязки.

Сама возможность расширения готового продукта с помощью своих программистов является огромным преимуществом! У пользователей закрытых и очень дорогих продуктов от HP, IBM, разных SaaS - просто нет такой возможности.

На остальное не смогу ответить.

alexvl
()
Ответ на: комментарий от alexvl

Не надо пугаться. Со скриптом обновления проблем нет. Похоже, что что-то в связке пакетов с systemd.

и до сих пор никакого решения...

anonymous
()
Ответ на: комментарий от crypt

сделать синхронизацию кеша на двух zabbix server'ах плюс свести данные в одну базу с нагрузкой хотя бы 2000nvps

Это будет далеко не 18 килоевро стоить, а больше. Ибо придется переписать половину всего заббикса.

Скорее всего нет.

У меня таких потребностей - нет. Да и сама идея - синхронизация кэшей на 2х серверах - не ясна. Хочется получать из 2х мест алерты от триггеров и иметь кашу из таблицы event?

LynxChaus
()
Ответ на: комментарий от alexvl

В смысле у hp нет? Есть. Под SCOM можно написать вообще что угодно почти

wozap
()
Ответ на: комментарий от DRVTiny

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

crypt ★★★★★
()
Ответ на: комментарий от crypt

Это констатация того, что разработка Zabbix ведётся узкой командой, которая принимает патчи крайне неохотно. Даже от таких в общем известных людей как ALTLinux.

DRVTiny ★★★★★
()
Ответ на: комментарий от DRVTiny

Наши DBA-шники допилили эти SQL-запросы

Дайте ссылку на тикет ZBX с вашем патчем. Тогда это будет конструктивный разговор.

Это констатация того, что разработка Zabbix ведётся узкой командой, которая принимает патчи крайне неохотно. Даже от таких в общем известных людей как ALTLinux.

Если обратите внимание на ChangeLog, то сможете заметить множество исправлений и слов спасибо авторам патчей.

Решение по включению патча зависит прежде всего от его качества, а не от степени важности того или иного человека.

alexvl
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.