Вопрос в том что настраивать конкретный проект в заббиксе тоже не очень-то удобно. Вы пробовали конфигурацию перенести? Экспортировать всё в 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. Останавливает прежде всего перенос того настроенного уже и любовно сформированного такими усилиями в заббиксе исторического скарба…