Zabbix позволяет легко и удобно настроить мониторинг большого количества разных счетчиков со множества устройств. Он был открыт под GPL в 2001г, и за последние 15 лет в нем безусловно было сделано множество улучшений, позволяющих еще лучше собирать еще больше данных.
Но почему же все улучшения обошли стороной навигацию по такому большому количеству собранных графиков и их отображение?
Что есть сейчас
Основная задача для которой Zabbix используется в нашей компании – это оценка трендов, а не текущие алерты и триггеры. Т.е. в основном нам необходимо быстро открыть все графики по одному серверу, или один и тот же график по группе серверов.
Что нам предлагает стандартный zabbix-frontend-php для этого?
Ничегошеньки! Позволено выбрать группу, потом выбрать хост из нее, потом выбрать график для этого хоста. Каждый выбор сопровождается полной перезагрузкой страницы, и хотя и присутствует выбор all – все равно выведен будет только один график.
Вы скажете, что решение этой проблемы – Screens, которые надо создать заранее с графиками типа Dynamic item. К сожалению, такое решение только добавляет проблем, когда необходимо просто открыть нужный Screen из списка over 9000 in plain list.
Пробовали ли вы быстро открыть Screen, созданный на хосте через шаблон? Потом переключиться на соседний хост?
Server-side graphs
Проблема признана пользователями, и фича-реквесты по отображению графиков находятся в топе JIRA разработчиков. И пользователи не только просят, но и колхозят. Так в ZBXNEXT-75 был найден патч (уходящий корнями в 2006г) который добавляет кажущуюся очевидной вещь:
Если в графиках мы выберем группу, потом сервер из нее, а график оставим all — то будут выведены все графики для этого хоста на одной странице. То же самое и для выбора конкретного графика, но указания имени сервера all — будет выведен заданный график для всех серверов группы.
Казалось бы это настолько логично – что просто должно присутствовать «из коробки»!
Cristian added a comment — 2013 Dec 04 18:44Патч был установлен, и на какое-то время позволил легче дышать. А так же сразу и выяснилась причина почему данный функционал не реализован официально – производительность генерирования картинки на стороне сервера оставляет желать лучшего. Это терпимо, когда картинка на странице одна, но когда их уже 20 – это становится заметно.
Btw, I simply don't understand why this patch is not included into Zabbix source. The code is quite simple and these (very useful) patches are quite easy to add.
Client-side graphs
На минутку вспомним, что сейчас 2016 год и модно-молодежные системы типа Graphite, Grafana, Chronograf рендерят графики на стороне клиента. Более того для Grafana даже есть data-source плагин для Zabbix:
Это отличная возможность пощупать что-то новое на уже собранных родных данных, посмотреть на них под другим углом. И в связи с относительной простотой, я всем рекомендую сделать это. Хорошее сравнение оригинальных возможностей и Grafana вы можете посмотреть в wiki
Но нам к сожалению плагин не подошел по нескольким причинам:
— Очень медленная работа связанная с возможностями API Zabbix. Когда мы пробовали Grafana, получение истории вообще было патчем ZBXNEXT-1193. Но и сейчас в API нет даунсемплинга. Если вы смотрите график за месяц и счетчик собирается раз в минуту, готовьтесь что браузер загрузит json со всеми данными и будет пытаться их отрисовать. Не говоря уже о том что размер данных будет больше, чем весила бы картинка.
— Доступны только счетчики и их история значений. Все графики, созданные с ними в Zabbix, надо опять создавать в Grafana как темплейты. С помощью написания запросов можно нарисовать что угодно, но это не помогает когда хочется быстро окинуть взглядом уже созданный набор графиков.
Т.е. хотелось бы чего-то более интегрированного в Zabbix, т.к. его система наследования шаблонов довольно удобна. Очень жаль что инициатива 2013г по переводу рендеринга на D3.js погибла. Да, zabbix-d3 работает, но упирается в те же архитектурные ограничения API. Остается надеяться, что то множество ZBXNEXT которые были созданы для поддержки D3 когда-нибудь будут реализованы. Это так же улучшит работу Grafana, и возможных ее конкурентов в будущем. (Разработчики, не упускайте свой шанс развязаться с почти совершеннолетним PHP кодом!)
Server-side graphs #2
Разные компании по разному решали проблему графиков в Zabbix, так Ring Central помимо прочего сделал отдельную ферму для рендеринга графиков.
С отдельным веб-интерфейсом для их навигации и просмотра:
(Скриншот в хорошем качестве предоставлен автором TPAKTOP_666, который отозвался после опубликования статьи) Немного информации по туле доступно в презентации на slideshare, немного — в выступлении на ZabbixConf. Больше ничего я в открытом доступе не нашел, но понятно, что инструмент позволяет сделать график из любых счетчиков, даже не объединенных одним графиком ранее. Так же интересной выглядит возможность послать ссылку на сформированный набор графиков.
Идея выноса рендеринга картинок на ферму серверов показалась простым решением в лоб, и была опробована. Что в купе с кешированием в nginx и переходом на php7 дало кое-какой выигрыш в производительности. Достаточный чтобы опять посмотреть на улучшение в навигации текущего веб интерфейса.
Основной проблемой патча ZBXNEXT-75, упомянутого выше, было то, что при каждом изменении фильтра страница перезагружалась полностью. Да, можно было бы переписать его на js, и приходить за всеми нужными данными в Zabbix API на лету – но для использования API нужна авторизация и токен. Глупо было бы просить пользователя вводить пароль дважды, один раз для PHP, второй — для js.
Последним щелчком, который расставил все по местам был чудесный скрипт от Toshiyuki-сана zabbix-graph-viewer:
При работе он не спрашивал аутентификации, и сделано это было всего одной строкой (ага, меньше 30 ;) на js:
auth: $cookies.zbx_sessionid,
Т.е. пресловутый токен для zabbix API является всего лишь SSID, и уже лежит в куки. После этого стало довольно просто переписать идею ZBXNEXT-75 на js. Засучаем рукава и появляется zabbixGrapher:
Помимо возможности просмотра произвольных уже созданных графиков по хостам, удалось так же реализовать возможность создавать графики для любых счетчиков на лету. При этом используется html5 history который меняет URL при изменении состояния страницы — это позволяет поделиться ссылкой на вашу подборку графиков.
LLD
Возможность генерировать графики на лету так же в некоем роде стала решением для ZBXNEXT-927 (в топе JIRA под номером 2). Вкратце проблема в следующем:
— У вас есть LLD, например для определения всех дисков на сервере. Он успешно создает счетчик, например
Free disk space, % для каждого диска— В LLD вы можете создать только отдельный график для каждого найденного диска. Вы не можете создать один график для отображения свободного места на всех дисках:
Такой график можно создать вручную, на хосте, из обнаруженных счетчиков. Через некоторое время диск заменят, или добавят новый, и ваш график перестанет полноценно отражать реальность.
Да, для автоматизации создания и обновления таких графиков с 2012г существуют скрипты. Но основная их проблема в том что вам надо о них помнить. Например при создании нового шаблона с хостами не забыть и обновить конфиг такого скрипта. Было бы неплохо править конфиг в том же веб-интерфейсе. Let's go, it's fun! Так появился gLLD:
Который всего лишь позволяет удобно редактировать задачи, которые уже будет исполнять скрипт ходящий по крону. При написании этой простой формочки пришлось поразбираться с веб-интерфейсом Zabbix поглубже чем публичный API, и к сожалению особой радости увиденное не принесло. (Not fun at all) Зато понятно почему ответ разработчиков в ZBXNEXT-927 был ссылкой на Development services. Минимальная цена текущих проектов на этой странице стартует с €8,000.00
The End
На этом все, будет интересно почитать ваши комментарии. Надеюсь эта подборка кому-то поможет (например осознать что пора мигрировать с Zabbix ;)
PS
Да, плагинов не существует, вам надо патчить исходный код. Но они скоро появятся — ZBXNEXT-1099
Комментарии (25)
RicoX
08.08.2016 09:30+5Мне кажется разработчики zabbix несколько по другому понимают концепцию мониторинга и я с ними согласен. Задача мониторинга оповестить об аномалиях в наблюдаемом оборудовании, для этого в zabbix есть просто огромное количество возможностей настройки триггеров, автоматический поиск новых устройств с определением типа и добавлением и многое другое, с этой задачей он справляется на 5+. Графики, карты сетей, комплексные экраны и прочие визуальные рюшечки вторичны, по-этому уже много лет разработчики кладут на них прибор и продолжают наращивать автоматизацию, то же появление LLD вывело систему на качественно новый уровень. В вашем примере с дисками, если появляется новый, на него автоматом вешается шаблон с алярмами о различном процентном заполнении и прочими параметрами жизнедеятельности плюс триггеры по расчету планируемого заполнения — это в основном то, что необходимо знать, смотреть же на графики очень вторично. Например, у меня под наблюдением почти 9К устройств в zabbix и я бы очешуел вручную постоянно рассматривать графики каждого в поиске каких-либо отклонений, сработала алярма — лезем смотреть конкретный график, глючит устройство, но нет алярмы — изучаем все параметры (включая изучение графиков) находим аномалии и делаем новую алярму на найденный тип проблем. Концепция заббикса — массовый комплексный мониторинг, для отдельного сервера-двух это не лучший выбор и можно найти кучу решений с красивыми рюшечками для небольшого количества устройств, вот там и будет много графиков и нескучные обои ну или прикрутить один из предлагаемых костылей на форуме, улучшающих графическое восприятие фронтенда. ИМХО.
landergate
08.08.2016 10:17+1например осознать что пора мигрировать с Zabbix
Какое бы другое решение ни было выбрано вместо Zabbix, экраны, листинги всех серверов на одной странице и смежные данные на одном графике всё-равно предстоит точечно настраивать под конкретный проект и требования. И чем гибче система, тем комплекснее будет протекать этот процесс.
Вы описали интересный маршрут решения. Согласен, что даунсемплить данные стоило бы в самом API (так и не нашёл реквеста фичи в их трекере), но требования ко скорости выгрузки данных за большие интервалы по всем серверам на одной странице достаточно специфичны.
Универсальных+оптимальных решений не существует. Согласитесь, всё зависит от проекта и от задачи, которая ставится перед мониторингом, поэтому описанная частная проблема — скорее проблема выбора инструментов под свой проект, чем повод для всех срочно мигрировать с Заббикса. Заббикс отлично выполняет основной пласт задач в своей нише. Когда у проекта появляются повышенные требования к отдельным аспектам мониторинга, это предмет для точечного тюнинга (чем вы и занимались в статье) или смены инструмента под решение конкретного вопроса.
Также мне не совсем ясно, зачем в качестве КДПВ был использован какой-то очень старый баннер с их сайта. Хотелось отразить возраст решения?
sepich
08.08.2016 11:43Спасибо за ваш коментарий — это в каком-то виде поддержка.
Не собирался делать статью пессимистичной, это наверно отпечаток настоящей нашей проблемы — масштабируемость бд.
И здесь прометеусы и графиты предлагают архитектурно лучшее решение. (Которое так же сводит на нет и проблему даунскейлинга — он происходит при записи, как в rrd).
Для заббикса известно было только об одной попытке перехода на MongoDB в Ring Central и это не было реализовано. Теперь они используют грфит рядом с заббиксом, что говорит о многом.
Возможно заббикс — действительно просто не наш инструмент.
По поводу КДПВ — действительно я искал, но не смог найти, скриншот просмотра графиков для версии 1.4 (с которой я начинал). С тех пор этот экран не изменился.
Hubbitus
09.08.2016 01:08Вопрос в том что настраивать конкретный проект в заббиксе тоже не очень-то удобно. Вы пробовали конфигурацию перенести? Экспортировать всё в XML и потом загрузить? Хорошо если половина у вас загрузится, а остальное опять напильником. Почему-то в Grafana достаточно JSON скопировать. А ещё можно делиться плагинами и дашбордами. Но это совсем пол беды. Вы пробовали это автоматизировать? Скажем с помощью Ansible настроить и сервер и клиентов автоматически? Ну положим с сервером самим всё просто. Хотя и нет в доке, но сформировать надо по сути один php конфиг и всё заработает. Ну а дальше? API также, Автоматизирует это на половину. Ни одной официально поддерживаемой имплементации или тулзы нет (скажем в составе, что-то вроде zabbix_cli). Можно на удачу попробовать использовать скжем какой-нибудь zabbix_api на питоне…
Скажите на милость, почему кастомные метрики надо до сих пор добавлять с двух сторон? На сервере Item с кучей настроек, а на клиенте ещё conf.d описывать команды как их посылать. По какой из причин это нельзя было сделать с одной стороны? Ну как Influxdb чтобы начать писать данные — нужно просто начать их писать. Любым инструментом, от агента, до REST запросов простых. И никаких обязательных агентов (хотя и имеется с пяток разных на выбор). А анализировать их, алармы делать или графики строить другие инструменты имеются. Что сложно в конфиге указать пару дополнительных параметров, каким это будет итемом на сервере и сколько я времени его там хочу хранить? Ну или в обратную сторону, уж если на сервере настроили всё, а агент всё равно постоянно ломится и имеет сетевое соединение, почему ещё требуется конфигурирование кастомных команд на клиенте, он не может это тоже получить с сервера как получает многие стандартные метрики?
И да, конечно многое побороть можно, и сами живём, кое-что доделываем. Вопрос больше стоит ли? На Highload в прошлом году опять общался с ребятами, и снова спрашивал, когда будет множественный пуш элементов, хаускипинг на партициях, JMX нормальный, не отваливающийся java gateway… Это всё вопросы которым много лет, а ответов так и нет. Также как постоянно обещаемый новый интерфейс.
В общем, если честно сам всё больше и больше смотрю на возможность перехода на что-то более простое, гибкое и современное типа Influxdb + Grafana. Останавливает прежде всего перенос того настроенного уже и любовно сформированного такими усилиями в заббиксе исторического скарба…RicoX
09.08.2016 09:31Попробую ответить некоторые вопросы.
Скажите на милость, почему кастомные метрики надо до сих пор добавлять с двух сторон?
Можете добавлять с одной стороны сервера, кто вам не дает, заббикс умеет ssh агентов и отдельный ставить вообще нет необходимости, это же к использованию Ansible, как и в обязательных агентах, для большинства железа есть SNMP, именно агенты тот еще костыль, соглашусь, но это не значит что им обязательно пользоваться.
хаускипинг на партициях
Есть и описано в доке уже лет 10 как: раз, два, три
гибкое и современное типа Influxdb + Grafana
Чем оно современное, кроме ужасной графики и тормозов? Аналога того-же LLD нет, находить новые узлы автоматом не умеет, все только ручками, IPMI не умеет, чуть какая кастомизация — лезь правь код. Добавьте в него хотя-бы 500+ узлов и оно ляжет, нет может я конечно не умею это чудо готовить, но тут сравнение несравнимого. У zabbix конечно много проблем, но сравнивать промышленный инструмент с детской поделкой, я даже не знаю.Hubbitus
09.08.2016 14:45Не, в случае с любой Timeseries database (не обязательно Influxdb), вам не надо LLD или любого другого дискавери. Вы просто в любой момент начинаете писать данные и она их сохраняет. Ведь анализ от сбора всегда разнесён и во времени и в инструментах.
А про партиции я и говорю — велосипедов много и все вокруг.landergate
09.08.2016 15:01+1вам не надо LLD
Это Вам его не надо. =)
А есть проекты, где мониторятся не только метрики, посылаемые своим приложением.
landergate
09.08.2016 14:59+1Hubbitus
В качестве предисловия, скажу, что я понимаю Вашу боль.
Я не могу согласиться с тем, что это проблема Заббикса или его некая «неисправимая слабая сторона». Скорее, проблема выбора подходящего инструмента под свою архитектуру.
Вы пробовали конфигурацию перенести? Экспортировать всё в XML и потом загрузить?
Перенести какую конфигурацию и куда?
Шаблоны переносятся достаточно просто.
Хорошо если половина у вас загрузится, а остальное опять напильником.
Не приходилось сталкиваться с таким. Разве что только при переносе старых шаблонов на новые версии Заббикса, но это бич почти любой системы, у которой между версиями есть разница в added/deprecated features/syntax/API.
Но если Вы уточните, какую конфигурацию и куда Вы переносили, можем рассмотреть подробнее. Не исключено, что есть какие-то нетривиальные сценарии, где это может протекать сложнее, чем хотелось бы.
Почему-то в Grafana достаточно JSON скопировать.
Немного странно сравнивать эту область с Графаной.
Графана это визуализация графиков. That's all.
В Заббиксе отдельные элементы тоже экспортятся досаточно просто.
Вы пробовали это автоматизировать? Скажем с помощью Ansible настроить и сервер и клиентов автоматически?
Подключение агентов к серверу? Запросто, любым CM.
Подключение шаблонов к агенту? Запросто, любым CM.
Подключение шаблонов к Hosts на сервере? Можно через Discovery/Auto registration Rules, критериев для обнаружения достаточно. Можно через API, он это умеет.
почему кастомные метрики надо до сих пор добавлять с двух сторон?
Потому, что не на всех проектах допустимо неконтроллируемо срать в мониторинг любые метрики в любом количестве.
У обоих подходов есть свои преимущества и свои недостатки, они оба применяются в разных средах.
Есть сценарии, когда возможен agentless забор метрик. RicoX как раз описывает несколько из них.
На сервере Item с кучей настроек
Цена гибкости. По сути нужно указать лишь имя айтема и тип. Всё остальное только по требованию. Если ваша архитектура мониторинга предполагает пулл заббиксом с хоста, то ещё и интервал пуллов.
а на клиенте ещё conf.d описывать команды как их посылать
Это и так делается, независимо от того, где. Всегда есть какая-то логика забора метрики.
Деплой скриптов автоматизируется через CM.
Мониторят разное. Не только метрики, отдаваемые вашим разрабатываемым приложением.
Для отправки метрик от приложения есть тип айтема «Trapper». Он тоже работае по принципу «просто шлёшь в мониторинг». conf.d ему для этого не нужен.
А анализировать их, алармы делать или графики строить другие инструменты имеются.
В Заббиксе всё это прямо из коробки, и работает в общем случае неплохо, работать можно. Специфические потребности тюнятся или заменяются другими утилитами.
если на сервере настроили всё, а агент всё равно постоянно ломится и имеет сетевое соединение, почему ещё требуется конфигурирование кастомных команд на клиенте, он не может это тоже получить с сервера как получает многие стандартные метрики?
Агент никуда не ломится и не держит никакое соединение.
Если проверка пассивна, сервер открывает соединение с агентом, получает метрику, закрывает.
Если проверка активна, агент сам открывает соединение с сервером, даёт метрику, закрывает.
В некоторых сценариях возможен agentless забор метрик.
Настройка кастомных команд на клиенте нужна только в том случае, если 1) забор метрики предполагает какую-то логику, которой нет в агенте; 2) нет возможности самому отправлять метрику в айтем типа Trapper.
Чудес не бывает. Любая система мониторинга должна откуда-то получить нужную Вам метрику. Можете рассматривать user_parameter-файлы, как интерфейс плагинов, подобно Nagios и т.п. системам.
когда будет множественный пуш элементов
Он есть и сейчас своими скриптами. Настраиваются трапперы, и метрики пушатся в них с хоста.
постоянно обещаемый новый интерфейс
Он и так накануне обновлялся. Многие вещи AJAXнулись, повысилась отзывчивость.
Конкретные пожелания к интерфейсу принимаются в трекере и на митапах/конференциях. Если модификация критичная для вашего бизнеса, но небольшая, её можно сделать и самому, это несложно.
настраивать конкретный проект в заббиксе тоже не очень-то удобно
Да, только это Ваш субъективный опыт.
У каждого проекта разная модель, разные критические требования к мониторингу.
Для Вашего конкретного проекта, возможно, эта архитектура не подошла, но это недостаточный аргумент для ратования за его выброс на помойку и остальным, у кого схема с ним прижилась и отлично работает. На определённых проектах Заббикс удобен.
Вопрос больше стоит ли?
Зависит от проекта, от наиболее критичных ожиданий к мониторингу.
Если Заббикс архитектурно перестаёт Вам в нём подходить, то почему бы не посмотреть на другие инструменты? Их достаточно, и у каждого свой подход, свои ограничения.
Ниша Заббикса от этого не исчезнет. Он продолжает быть удобным в определённых ситуациях.Hubbitus
09.08.2016 15:21Деплоить автоматически агенты и их конфиги не проблема, развернуть сервер тоже сделано. Но вот если вы мне покажете в любой CM автоматическое полное конфигурирование в заббиксе хоста, включая добавление хоста, включение его в группы (помимо простых discovery rule), назначение шаблонов, создание графиков, скринов для него, добавление его в другие существующие скрины и графики… Буду очень благодарен. Предпочтение конечно ansible. В его galaxy я не нашёл рецептов. Мы пока так и не дошли до полного конфигурирования без веб-интерфейса. Остановились на том что некоторая реализация API всё же потребуется, а упаковать в rpm и добавить в EPEL тот же zabbyx_py я пока вписал в todo на будущее…
landergate, я думаю мы очень сильно уклонились от темы публикации. Если вы не возражаете, в остальном я не буду продолжать дискуссию и отвечать по пунктам, хотя не совсем согласен. Хочу лишь сказать что sepich затронул интересную тему и провёл интересный обзор решений по визуализации данных для Заббикса, и мне тоже не удобно то что имеется в этом плане из коробки, хотя и использую и признаю что в общем можно использовать до какой-то степени. Немного огорчает вывод что пока нет даунсемплинга и нужно хакать сам заббикс, то и внешние решения нормальные использовать не так радужно…RicoX
09.08.2016 23:07Но вот если вы мне покажете в любой CM автоматическое полное конфигурирование в заббиксе хоста, включая добавление хоста, включение его в группы (помимо простых discovery rule), назначение шаблонов, создание графиков, скринов для него, добавление его в другие существующие скрины и графики… Буду очень благодарен.
Я вам готов показать это даже без использования CM вообще, сам заббикс это умеет из коробки:
Обнаружение автоматом
Авторегистрация агентов
Действия при обнаруженииHubbitus
09.08.2016 23:31Да нет же. Простые действия может конечно, я же изначально упомянул про них и правила обнаружения. Как с помощью них скажем с хоста, добавляемого в мониторинг, сказать типа «я сервер реплики Постгрес, приложения А», мне нужно применить шаблоны pg_monz, A, B, custom_stat_queries, и D. А в screen c именем «Количество сессий за 15 минут» добавить с этого хоста график C1 из шаблона custom_stat_queries?
На сколько я понимаю без API никак уже. Я не прав?RicoX
09.08.2016 23:53Делается, я использую правила обнаружения с SNMP, но можно в лоб использовать Zabbix agent с system.uname
Пример:
Правило обнаружения заббикс агента вернуло системное имя Rep_pg_A
В действиях на обнаружение делаем правило, если хост активен более 5 минут и имеет в обнаружении pg цепляем к нему шаблон pg_monz (ну и другие нужные на остальные части system.uname), добавить в группу такую-то, для группы у нас есть связанный screen с кол-вом сессий, так-же с группой связан и необходимый шаблон. Ниже скрин-пример с реального проекта
SNMP вариант более гибкий, так-как мы можем задавать свои любые произвольные OID и использовать их в правилах обнаружения как идентификатор причастности хоста к определенной группе, но это требует предварительной настройки SNMPD, что прекрасно перекладывается на любой CM.
Заббикс не удобно настраивать если у вас несколько абсолютно разных серверов с разными критериями мониторинга, т.к. каждый придется натыкивать вручную, но очень удобно когда у вас сотни однотипных серверов или любых других железяк, шаблоны прекрасно автоматизируются в таком случае.Hubbitus
10.08.2016 00:07Ну так конечно у меня разные серверы в проекте. Балансеры, аппы, БД (мастеры, слэйвы), хранилища… Каждого типа разное количество… Вы не против, если я к вам лично постучусь и вы поделитесь опытом как это полностью автоматизировать?
RicoX
10.08.2016 09:35Да стучитесь не вопрос. А так в общих чертах разбиваем сервера для себя сначала по типам, потом по общим признакам, на каждый тип и признак делаем шаблон и для каждого типа и признака в обнаружении должен быть критерий, по которому zabbix может его идентифицировать.
AlexanderZN
09.08.2016 23:07В Ansible есть несколько модулей для конфигурирования Zabbix, например, zabbix_host. Графики и скрины добавлять не умеет, но может добавить в группу и привязать шаблон.
RicoX
09.08.2016 23:10Добавлю, что в шаблоне уже будут графики и если нужно LLD, так что полный цикл автоматического добавления хоста.
snvtr
08.08.2016 10:17Если бы данные в БД хранились в легкочитаемом виде, то построение графиков и вообще любая аналитика не была бы проблемой.
RicoX
08.08.2016 11:55Так они и хранятся в БД, таблицы trends_uint, history_uint, history, trends… — основной объем данных. Или вы что-то другое имеете в виду?
snvtr
08.08.2016 11:58Просто не помню как это выглядит, смотрел очень-очень давно и не показалось «интуитивно понятным».
RicoX
08.08.2016 12:05+2Все данные хранятся как раз в базе, причем логика базы неплохая, можно разобраться что за что отвечает и откуда берется даже без документации, другое дело что некоторые выборки строятся достаточно долго, ну если мы говорим а построй ка нам несколько сотен графиков сразу на одном экране за часовые данные, то селекты выполняются не очень быстро, но с каждой версией эта часть системы оптимизируется, ну и тюнинг базы с кешами спасает, но такие выборки нужны при траблшутинге и используются не так часто и только в ручном режиме, что общей производительности проблем не создает. У любого решения есть сильные и слабые стороны, надо выбирать инструмент под конкретную задачу, zabbix заточен под автоматизацию, а не визуализацию.
AlexanderZN
09.08.2016 22:57Да, к сожалению, производительность Zabbix API оставляет желать лучшего. Подумаваю даже о написании отдельной реализации для работы с метриками. Что-то вроде Zabbix Metrics API, с server-side аггрегациями как в графите. Боюсь только, что это усложнит использования плагина для Grafana, да и времени займет не мало.
POS_troi
Использую «графану» как фронтэнд для вывода на монитор, но за подробностями всёравно лажу в родной интерфейс. Графана просто марафет для показа неискушенным пользователям :)
Уже сколько лет ведуться дискусии по «апгрейду» интерфейса и предлагается куча полезных идей и готовых решений, даже в последнем релизе нам презентовали «новый интерфейс» который по факту стал просто менее квадратным.
С другой стороны заббикс вполне выполняет свою работу даже в том виде как сейчас есть, к остальному привыкаешь быстро.