Комментарии 25
Использую «графану» как фронтэнд для вывода на монитор, но за подробностями всёравно лажу в родной интерфейс. Графана просто марафет для показа неискушенным пользователям :)
Уже сколько лет ведуться дискусии по «апгрейду» интерфейса и предлагается куча полезных идей и готовых решений, даже в последнем релизе нам презентовали «новый интерфейс» который по факту стал просто менее квадратным.
С другой стороны заббикс вполне выполняет свою работу даже в том виде как сейчас есть, к остальному привыкаешь быстро.
Уже сколько лет ведуться дискусии по «апгрейду» интерфейса и предлагается куча полезных идей и готовых решений, даже в последнем релизе нам презентовали «новый интерфейс» который по факту стал просто менее квадратным.
С другой стороны заббикс вполне выполняет свою работу даже в том виде как сейчас есть, к остальному привыкаешь быстро.
Мне кажется разработчики zabbix несколько по другому понимают концепцию мониторинга и я с ними согласен. Задача мониторинга оповестить об аномалиях в наблюдаемом оборудовании, для этого в zabbix есть просто огромное количество возможностей настройки триггеров, автоматический поиск новых устройств с определением типа и добавлением и многое другое, с этой задачей он справляется на 5+. Графики, карты сетей, комплексные экраны и прочие визуальные рюшечки вторичны, по-этому уже много лет разработчики кладут на них прибор и продолжают наращивать автоматизацию, то же появление LLD вывело систему на качественно новый уровень. В вашем примере с дисками, если появляется новый, на него автоматом вешается шаблон с алярмами о различном процентном заполнении и прочими параметрами жизнедеятельности плюс триггеры по расчету планируемого заполнения — это в основном то, что необходимо знать, смотреть же на графики очень вторично. Например, у меня под наблюдением почти 9К устройств в zabbix и я бы очешуел вручную постоянно рассматривать графики каждого в поиске каких-либо отклонений, сработала алярма — лезем смотреть конкретный график, глючит устройство, но нет алярмы — изучаем все параметры (включая изучение графиков) находим аномалии и делаем новую алярму на найденный тип проблем. Концепция заббикса — массовый комплексный мониторинг, для отдельного сервера-двух это не лучший выбор и можно найти кучу решений с красивыми рюшечками для небольшого количества устройств, вот там и будет много графиков и нескучные обои ну или прикрутить один из предлагаемых костылей на форуме, улучшающих графическое восприятие фронтенда. ИМХО.
например осознать что пора мигрировать с Zabbix
Какое бы другое решение ни было выбрано вместо Zabbix, экраны, листинги всех серверов на одной странице и смежные данные на одном графике всё-равно предстоит точечно настраивать под конкретный проект и требования. И чем гибче система, тем комплекснее будет протекать этот процесс.
Вы описали интересный маршрут решения. Согласен, что даунсемплить данные стоило бы в самом API (так и не нашёл реквеста фичи в их трекере), но требования ко скорости выгрузки данных за большие интервалы по всем серверам на одной странице достаточно специфичны.
Универсальных+оптимальных решений не существует. Согласитесь, всё зависит от проекта и от задачи, которая ставится перед мониторингом, поэтому описанная частная проблема — скорее проблема выбора инструментов под свой проект, чем повод для всех срочно мигрировать с Заббикса. Заббикс отлично выполняет основной пласт задач в своей нише. Когда у проекта появляются повышенные требования к отдельным аспектам мониторинга, это предмет для точечного тюнинга (чем вы и занимались в статье) или смены инструмента под решение конкретного вопроса.
Также мне не совсем ясно, зачем в качестве КДПВ был использован какой-то очень старый баннер с их сайта. Хотелось отразить возраст решения?
Спасибо за ваш коментарий — это в каком-то виде поддержка.
Не собирался делать статью пессимистичной, это наверно отпечаток настоящей нашей проблемы — масштабируемость бд.
И здесь прометеусы и графиты предлагают архитектурно лучшее решение. (Которое так же сводит на нет и проблему даунскейлинга — он происходит при записи, как в rrd).
Для заббикса известно было только об одной попытке перехода на MongoDB в Ring Central и это не было реализовано. Теперь они используют грфит рядом с заббиксом, что говорит о многом.
Возможно заббикс — действительно просто не наш инструмент.
По поводу КДПВ — действительно я искал, но не смог найти, скриншот просмотра графиков для версии 1.4 (с которой я начинал). С тех пор этот экран не изменился.
Не собирался делать статью пессимистичной, это наверно отпечаток настоящей нашей проблемы — масштабируемость бд.
И здесь прометеусы и графиты предлагают архитектурно лучшее решение. (Которое так же сводит на нет и проблему даунскейлинга — он происходит при записи, как в rrd).
Для заббикса известно было только об одной попытке перехода на MongoDB в Ring Central и это не было реализовано. Теперь они используют грфит рядом с заббиксом, что говорит о многом.
Возможно заббикс — действительно просто не наш инструмент.
По поводу КДПВ — действительно я искал, но не смог найти, скриншот просмотра графиков для версии 1.4 (с которой я начинал). С тех пор этот экран не изменился.
Вопрос в том что настраивать конкретный проект в заббиксе тоже не очень-то удобно. Вы пробовали конфигурацию перенести? Экспортировать всё в XML и потом загрузить? Хорошо если половина у вас загрузится, а остальное опять напильником. Почему-то в Grafana достаточно JSON скопировать. А ещё можно делиться плагинами и дашбордами. Но это совсем пол беды. Вы пробовали это автоматизировать? Скажем с помощью Ansible настроить и сервер и клиентов автоматически? Ну положим с сервером самим всё просто. Хотя и нет в доке, но сформировать надо по сути один php конфиг и всё заработает. Ну а дальше? API также, Автоматизирует это на половину. Ни одной официально поддерживаемой имплементации или тулзы нет (скажем в составе, что-то вроде zabbix_cli). Можно на удачу попробовать использовать скжем какой-нибудь zabbix_api на питоне…
Скажите на милость, почему кастомные метрики надо до сих пор добавлять с двух сторон? На сервере Item с кучей настроек, а на клиенте ещё conf.d описывать команды как их посылать. По какой из причин это нельзя было сделать с одной стороны? Ну как Influxdb чтобы начать писать данные — нужно просто начать их писать. Любым инструментом, от агента, до REST запросов простых. И никаких обязательных агентов (хотя и имеется с пяток разных на выбор). А анализировать их, алармы делать или графики строить другие инструменты имеются. Что сложно в конфиге указать пару дополнительных параметров, каким это будет итемом на сервере и сколько я времени его там хочу хранить? Ну или в обратную сторону, уж если на сервере настроили всё, а агент всё равно постоянно ломится и имеет сетевое соединение, почему ещё требуется конфигурирование кастомных команд на клиенте, он не может это тоже получить с сервера как получает многие стандартные метрики?
И да, конечно многое побороть можно, и сами живём, кое-что доделываем. Вопрос больше стоит ли? На Highload в прошлом году опять общался с ребятами, и снова спрашивал, когда будет множественный пуш элементов, хаускипинг на партициях, JMX нормальный, не отваливающийся java gateway… Это всё вопросы которым много лет, а ответов так и нет. Также как постоянно обещаемый новый интерфейс.
В общем, если честно сам всё больше и больше смотрю на возможность перехода на что-то более простое, гибкое и современное типа Influxdb + Grafana. Останавливает прежде всего перенос того настроенного уже и любовно сформированного такими усилиями в заббиксе исторического скарба…
Скажите на милость, почему кастомные метрики надо до сих пор добавлять с двух сторон? На сервере Item с кучей настроек, а на клиенте ещё conf.d описывать команды как их посылать. По какой из причин это нельзя было сделать с одной стороны? Ну как Influxdb чтобы начать писать данные — нужно просто начать их писать. Любым инструментом, от агента, до REST запросов простых. И никаких обязательных агентов (хотя и имеется с пяток разных на выбор). А анализировать их, алармы делать или графики строить другие инструменты имеются. Что сложно в конфиге указать пару дополнительных параметров, каким это будет итемом на сервере и сколько я времени его там хочу хранить? Ну или в обратную сторону, уж если на сервере настроили всё, а агент всё равно постоянно ломится и имеет сетевое соединение, почему ещё требуется конфигурирование кастомных команд на клиенте, он не может это тоже получить с сервера как получает многие стандартные метрики?
И да, конечно многое побороть можно, и сами живём, кое-что доделываем. Вопрос больше стоит ли? На Highload в прошлом году опять общался с ребятами, и снова спрашивал, когда будет множественный пуш элементов, хаускипинг на партициях, JMX нормальный, не отваливающийся java gateway… Это всё вопросы которым много лет, а ответов так и нет. Также как постоянно обещаемый новый интерфейс.
В общем, если честно сам всё больше и больше смотрю на возможность перехода на что-то более простое, гибкое и современное типа Influxdb + Grafana. Останавливает прежде всего перенос того настроенного уже и любовно сформированного такими усилиями в заббиксе исторического скарба…
Попробую ответить некоторые вопросы.
Можете добавлять с одной стороны сервера, кто вам не дает, заббикс умеет ssh агентов и отдельный ставить вообще нет необходимости, это же к использованию Ansible, как и в обязательных агентах, для большинства железа есть SNMP, именно агенты тот еще костыль, соглашусь, но это не значит что им обязательно пользоваться.
Есть и описано в доке уже лет 10 как: раз, два, три
Чем оно современное, кроме ужасной графики и тормозов? Аналога того-же LLD нет, находить новые узлы автоматом не умеет, все только ручками, IPMI не умеет, чуть какая кастомизация — лезь правь код. Добавьте в него хотя-бы 500+ узлов и оно ляжет, нет может я конечно не умею это чудо готовить, но тут сравнение несравнимого. У zabbix конечно много проблем, но сравнивать промышленный инструмент с детской поделкой, я даже не знаю.
Скажите на милость, почему кастомные метрики надо до сих пор добавлять с двух сторон?
Можете добавлять с одной стороны сервера, кто вам не дает, заббикс умеет ssh агентов и отдельный ставить вообще нет необходимости, это же к использованию Ansible, как и в обязательных агентах, для большинства железа есть SNMP, именно агенты тот еще костыль, соглашусь, но это не значит что им обязательно пользоваться.
хаускипинг на партициях
Есть и описано в доке уже лет 10 как: раз, два, три
гибкое и современное типа Influxdb + Grafana
Чем оно современное, кроме ужасной графики и тормозов? Аналога того-же LLD нет, находить новые узлы автоматом не умеет, все только ручками, IPMI не умеет, чуть какая кастомизация — лезь правь код. Добавьте в него хотя-бы 500+ узлов и оно ляжет, нет может я конечно не умею это чудо готовить, но тут сравнение несравнимого. У zabbix конечно много проблем, но сравнивать промышленный инструмент с детской поделкой, я даже не знаю.
Не, в случае с любой Timeseries database (не обязательно Influxdb), вам не надо LLD или любого другого дискавери. Вы просто в любой момент начинаете писать данные и она их сохраняет. Ведь анализ от сбора всегда разнесён и во времени и в инструментах.
А про партиции я и говорю — велосипедов много и все вокруг.
А про партиции я и говорю — велосипедов много и все вокруг.
Hubbitus
В качестве предисловия, скажу, что я понимаю Вашу боль.
Я не могу согласиться с тем, что это проблема Заббикса или его некая «неисправимая слабая сторона». Скорее, проблема выбора подходящего инструмента под свою архитектуру.
Перенести какую конфигурацию и куда?
Шаблоны переносятся достаточно просто.
Не приходилось сталкиваться с таким. Разве что только при переносе старых шаблонов на новые версии Заббикса, но это бич почти любой системы, у которой между версиями есть разница в added/deprecated features/syntax/API.
Но если Вы уточните, какую конфигурацию и куда Вы переносили, можем рассмотреть подробнее. Не исключено, что есть какие-то нетривиальные сценарии, где это может протекать сложнее, чем хотелось бы.
Немного странно сравнивать эту область с Графаной.
Графана это визуализация графиков. That's all.
В Заббиксе отдельные элементы тоже экспортятся досаточно просто.
Подключение агентов к серверу? Запросто, любым CM.
Подключение шаблонов к агенту? Запросто, любым CM.
Подключение шаблонов к Hosts на сервере? Можно через Discovery/Auto registration Rules, критериев для обнаружения достаточно. Можно через API, он это умеет.
Потому, что не на всех проектах допустимо неконтроллируемо срать в мониторинг любые метрики в любом количестве.
У обоих подходов есть свои преимущества и свои недостатки, они оба применяются в разных средах.
Есть сценарии, когда возможен agentless забор метрик. RicoX как раз описывает несколько из них.
Цена гибкости. По сути нужно указать лишь имя айтема и тип. Всё остальное только по требованию. Если ваша архитектура мониторинга предполагает пулл заббиксом с хоста, то ещё и интервал пуллов.
Это и так делается, независимо от того, где. Всегда есть какая-то логика забора метрики.
Деплой скриптов автоматизируется через CM.
Мониторят разное. Не только метрики, отдаваемые вашим разрабатываемым приложением.
Для отправки метрик от приложения есть тип айтема «Trapper». Он тоже работае по принципу «просто шлёшь в мониторинг». conf.d ему для этого не нужен.
В Заббиксе всё это прямо из коробки, и работает в общем случае неплохо, работать можно. Специфические потребности тюнятся или заменяются другими утилитами.
Агент никуда не ломится и не держит никакое соединение.
Если проверка пассивна, сервер открывает соединение с агентом, получает метрику, закрывает.
Если проверка активна, агент сам открывает соединение с сервером, даёт метрику, закрывает.
В некоторых сценариях возможен agentless забор метрик.
Настройка кастомных команд на клиенте нужна только в том случае, если 1) забор метрики предполагает какую-то логику, которой нет в агенте; 2) нет возможности самому отправлять метрику в айтем типа Trapper.
Чудес не бывает. Любая система мониторинга должна откуда-то получить нужную Вам метрику. Можете рассматривать user_parameter-файлы, как интерфейс плагинов, подобно Nagios и т.п. системам.
Он есть и сейчас своими скриптами. Настраиваются трапперы, и метрики пушатся в них с хоста.
Он и так накануне обновлялся. Многие вещи AJAXнулись, повысилась отзывчивость.
Конкретные пожелания к интерфейсу принимаются в трекере и на митапах/конференциях. Если модификация критичная для вашего бизнеса, но небольшая, её можно сделать и самому, это несложно.
Да, только это Ваш субъективный опыт.
У каждого проекта разная модель, разные критические требования к мониторингу.
Для Вашего конкретного проекта, возможно, эта архитектура не подошла, но это недостаточный аргумент для ратования за его выброс на помойку и остальным, у кого схема с ним прижилась и отлично работает. На определённых проектах Заббикс удобен.
Зависит от проекта, от наиболее критичных ожиданий к мониторингу.
Если Заббикс архитектурно перестаёт Вам в нём подходить, то почему бы не посмотреть на другие инструменты? Их достаточно, и у каждого свой подход, свои ограничения.
Ниша Заббикса от этого не исчезнет. Он продолжает быть удобным в определённых ситуациях.
В качестве предисловия, скажу, что я понимаю Вашу боль.
Я не могу согласиться с тем, что это проблема Заббикса или его некая «неисправимая слабая сторона». Скорее, проблема выбора подходящего инструмента под свою архитектуру.
Вы пробовали конфигурацию перенести? Экспортировать всё в 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нулись, повысилась отзывчивость.
Конкретные пожелания к интерфейсу принимаются в трекере и на митапах/конференциях. Если модификация критичная для вашего бизнеса, но небольшая, её можно сделать и самому, это несложно.
настраивать конкретный проект в заббиксе тоже не очень-то удобно
Да, только это Ваш субъективный опыт.
У каждого проекта разная модель, разные критические требования к мониторингу.
Для Вашего конкретного проекта, возможно, эта архитектура не подошла, но это недостаточный аргумент для ратования за его выброс на помойку и остальным, у кого схема с ним прижилась и отлично работает. На определённых проектах Заббикс удобен.
Вопрос больше стоит ли?
Зависит от проекта, от наиболее критичных ожиданий к мониторингу.
Если Заббикс архитектурно перестаёт Вам в нём подходить, то почему бы не посмотреть на другие инструменты? Их достаточно, и у каждого свой подход, свои ограничения.
Ниша Заббикса от этого не исчезнет. Он продолжает быть удобным в определённых ситуациях.
Деплоить автоматически агенты и их конфиги не проблема, развернуть сервер тоже сделано. Но вот если вы мне покажете в любой CM автоматическое полное конфигурирование в заббиксе хоста, включая добавление хоста, включение его в группы (помимо простых discovery rule), назначение шаблонов, создание графиков, скринов для него, добавление его в другие существующие скрины и графики… Буду очень благодарен. Предпочтение конечно ansible. В его galaxy я не нашёл рецептов. Мы пока так и не дошли до полного конфигурирования без веб-интерфейса. Остановились на том что некоторая реализация API всё же потребуется, а упаковать в rpm и добавить в EPEL тот же zabbyx_py я пока вписал в todo на будущее…
landergate, я думаю мы очень сильно уклонились от темы публикации. Если вы не возражаете, в остальном я не буду продолжать дискуссию и отвечать по пунктам, хотя не совсем согласен. Хочу лишь сказать что sepich затронул интересную тему и провёл интересный обзор решений по визуализации данных для Заббикса, и мне тоже не удобно то что имеется в этом плане из коробки, хотя и использую и признаю что в общем можно использовать до какой-то степени. Немного огорчает вывод что пока нет даунсемплинга и нужно хакать сам заббикс, то и внешние решения нормальные использовать не так радужно…
landergate, я думаю мы очень сильно уклонились от темы публикации. Если вы не возражаете, в остальном я не буду продолжать дискуссию и отвечать по пунктам, хотя не совсем согласен. Хочу лишь сказать что sepich затронул интересную тему и провёл интересный обзор решений по визуализации данных для Заббикса, и мне тоже не удобно то что имеется в этом плане из коробки, хотя и использую и признаю что в общем можно использовать до какой-то степени. Немного огорчает вывод что пока нет даунсемплинга и нужно хакать сам заббикс, то и внешние решения нормальные использовать не так радужно…
Но вот если вы мне покажете в любой CM автоматическое полное конфигурирование в заббиксе хоста, включая добавление хоста, включение его в группы (помимо простых discovery rule), назначение шаблонов, создание графиков, скринов для него, добавление его в другие существующие скрины и графики… Буду очень благодарен.
Я вам готов показать это даже без использования CM вообще, сам заббикс это умеет из коробки:
Обнаружение автоматом
Авторегистрация агентов
Действия при обнаружении
Да нет же. Простые действия может конечно, я же изначально упомянул про них и правила обнаружения. Как с помощью них скажем с хоста, добавляемого в мониторинг, сказать типа «я сервер реплики Постгрес, приложения А», мне нужно применить шаблоны pg_monz, A, B, custom_stat_queries, и D. А в screen c именем «Количество сессий за 15 минут» добавить с этого хоста график C1 из шаблона custom_stat_queries?
На сколько я понимаю без API никак уже. Я не прав?
На сколько я понимаю без API никак уже. Я не прав?
Делается, я использую правила обнаружения с SNMP, но можно в лоб использовать Zabbix agent с system.uname
Пример:
Правило обнаружения заббикс агента вернуло системное имя Rep_pg_A
В действиях на обнаружение делаем правило, если хост активен более 5 минут и имеет в обнаружении pg цепляем к нему шаблон pg_monz (ну и другие нужные на остальные части system.uname), добавить в группу такую-то, для группы у нас есть связанный screen с кол-вом сессий, так-же с группой связан и необходимый шаблон. Ниже скрин-пример с реального проекта
SNMP вариант более гибкий, так-как мы можем задавать свои любые произвольные OID и использовать их в правилах обнаружения как идентификатор причастности хоста к определенной группе, но это требует предварительной настройки SNMPD, что прекрасно перекладывается на любой CM.
Заббикс не удобно настраивать если у вас несколько абсолютно разных серверов с разными критериями мониторинга, т.к. каждый придется натыкивать вручную, но очень удобно когда у вас сотни однотипных серверов или любых других железяк, шаблоны прекрасно автоматизируются в таком случае.
Пример:
Правило обнаружения заббикс агента вернуло системное имя Rep_pg_A
В действиях на обнаружение делаем правило, если хост активен более 5 минут и имеет в обнаружении pg цепляем к нему шаблон pg_monz (ну и другие нужные на остальные части system.uname), добавить в группу такую-то, для группы у нас есть связанный screen с кол-вом сессий, так-же с группой связан и необходимый шаблон. Ниже скрин-пример с реального проекта
SNMP вариант более гибкий, так-как мы можем задавать свои любые произвольные OID и использовать их в правилах обнаружения как идентификатор причастности хоста к определенной группе, но это требует предварительной настройки SNMPD, что прекрасно перекладывается на любой CM.
Заббикс не удобно настраивать если у вас несколько абсолютно разных серверов с разными критериями мониторинга, т.к. каждый придется натыкивать вручную, но очень удобно когда у вас сотни однотипных серверов или любых других железяк, шаблоны прекрасно автоматизируются в таком случае.
Да в догонку, обратите внимание на, любой из указанных параметров можно использовать для идентификации узла и навешивания на него по этому критерию нужных шаблонов, групп и т.п.
В Ansible есть несколько модулей для конфигурирования Zabbix, например, zabbix_host. Графики и скрины добавлять не умеет, но может добавить в группу и привязать шаблон.
Если бы данные в БД хранились в легкочитаемом виде, то построение графиков и вообще любая аналитика не была бы проблемой.
А Zabbix не умеет в базу писать данные?
Так они и хранятся в БД, таблицы trends_uint, history_uint, history, trends… — основной объем данных. Или вы что-то другое имеете в виду?
Просто не помню как это выглядит, смотрел очень-очень давно и не показалось «интуитивно понятным».
Все данные хранятся как раз в базе, причем логика базы неплохая, можно разобраться что за что отвечает и откуда берется даже без документации, другое дело что некоторые выборки строятся достаточно долго, ну если мы говорим а построй ка нам несколько сотен графиков сразу на одном экране за часовые данные, то селекты выполняются не очень быстро, но с каждой версией эта часть системы оптимизируется, ну и тюнинг базы с кешами спасает, но такие выборки нужны при траблшутинге и используются не так часто и только в ручном режиме, что общей производительности проблем не создает. У любого решения есть сильные и слабые стороны, надо выбирать инструмент под конкретную задачу, zabbix заточен под автоматизацию, а не визуализацию.
Да, к сожалению, производительность Zabbix API оставляет желать лучшего. Подумаваю даже о написании отдельной реализации для работы с метриками. Что-то вроде Zabbix Metrics API, с server-side аггрегациями как в графите. Боюсь только, что это усложнит использования плагина для Grafana, да и времени займет не мало.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Zabbix vs графики