История изменений

Очень многое, чего ждали от 4.0, так и не случилось,и это несколько обескураживает:

1) До сих пор нет возможности подключать любой драйвер для записи timeseries-данных. Если бы это было возможно, и если бы механизм был описан, сообщество само бы создало драйвер для записи в нормальную time series db, раз уж в Риге на это никак не решатся по каким-то неведомым причинам

2) Elastic Search - не time series db, накладные расходы на чтение истории метрик из неё тоже чрезмерно высоки, хотя и поменьше, чем в случае с MySQL и прочими РСУБД, по определению не предназначенными для хранения временных рядов

3) Нет подвижек в сторону развития малоюзабельных сейчас IT Services, хотя тема ITSI давно уже является ключевой в планах развития всех известных мне крупных систем мониторинга

4) При наличии очень странного разделения на нормальный серверный Zabbix API мизерных размеров и огромный тупой и неповоротливый PHP Zabbix API на стороне фронтенда, ничего не сделано для отказа от последнего в пользу первого. На мой взгляд, это не очень здорово хотя бы по той причине, что делает фронтенд zabbix не фронтендом, а по сути неотделимой от ядра компонентой. Традиционная архитектура подобного рода приложений предполагает, что можно легко выкинуть штатный фронтенд и заменить своим, но zabbix-морда предоставляет безальтернативный «как бы API», общающийся напрямую с базой данных, а не с сервером zabbix и к тому же делает вовсе странные вещи типа расчёта SLA для IT Services, хотя этим просто на 150% обязан заниматься сервер

5) Так и нет иерархии групп, как и не появилось даже проблеска понимания того факта, что «группа» может быть таким же объектом мониторинга, как и «хост». Привет, «сгруппированные»/агрегированные метрики, для которых по-прежнему нужно создавать фейковый «типа хост»

6) Триггеры, объединяющие метрики из разных шаблонов, триггеры по состоянию IT-сервисов - всё в минус.

7) До сих пор нет встроенного SNMP-трапера и нет «ленты событий», которая позволяла бы видеть временное окно с event'ами, генерируемыми теми же входящими trap-сообщениями. Вся логика событий безальтернативно триггерная, нельзя просто узнать о том, что железка tell me something, нужно непременно строить логику непонятно как закрываемых триггеров

8) До сих пор нет мониторинга systemd-сервисов и вообще поддержки systemd для мониторинга, хотя это вообще ключевая вещь в современных Linux-системах.

Что появилось: красивые графики, содержимое которых по прежнему вытаскивается тяжеленными запросами в РСУБД или в Эластик, какая-то ещё более забубённая и непонятно кому нужная логика закрытия «Проблем», развитие катастрофически реализованной с т.з. СУБД темы тэгов (тэг - не наследуемый объект, на который ссылаются из таблиц, тэг - это копируемая сущность без всех нормальных реляционных привязок, реализованы чуть лучше, чем откровенный треш с «ирерархическими группами», но всё равно на уровне ниже первого hello, world'а на тему СУБД). Сжатие притащили - видимо, из-за того, что его было просто реализовать, а не из-за того, что тьмы несметные пользователей об этом просили (мне это точно не нужно было никогда, но наверняка есть 1.5 человека, которым нужно). vfs.dir.count - замечательно, но смешно хвалиться такими изменениями при выходе мажорной версии системы мониторинга.

Фронтенд стал ещё более безальтернативным и незаменимым, ключевые возможности ядра системы не реализованы, хотя о многих из них просили давным-давно.

Очень надеюсь на подвижки в 4.2, как это было с Zabbix 3.2, когда в 3.0 ничего по сути не поменялось, а в 3.2 «приплыла» тонна важных и нужных изменений.

Очень многое, чего ждали от 4.0, так и не случилось,и это несколько обескураживает:

1) До сих пор нет возможности подключать любой драйвер для записи timeseries-данных. Если бы это было возможно, и если бы механизм был описан, сообщество само бы создало драйвер для записи в нормальную time series db, раз уж в Риге на это никак не решатся по каким-то неведомым причинам

2) Elastic Search - не time series db, накладные расходы на чтение истории метрик из неё тоже чрезмерно высоки, хотя и поменьше, чем в случае с MySQL и прочими РСУБД, по определению не предназначенными для хранения временных рядов

3) Нет подвижек в сторону развития малоюзабельных сейчас IT Services, хотя тема ITSI давно уже является ключевой в планах развития всех известных мне крупных систем мониторинга

4) При наличии очень странного разделения на нормальный серверный Zabbix API мизерных размеров и огромный тупой и неповоротливый PHP Zabbix API на стороне фронтенда, ничего не сделано для отказа от последнего в пользу первого. На мой взгляд, это не очень здорово хотя бы по той причине, что делает фронтенд zabbix не фронтендом, а по сути неотделимой от ядра компонентой. Традиционная архитектура подобного рода приложений предполагает, что можно легко выкинуть штатный фронтенд и заменить своим, но zabbix-морда предоставляет безальтернативный «как бы API», общающийся напрямую с базой данных, а не с сервером zabbix и к тому же делает вовсе странные вещи типа расчёта SLA для IT Services, хотя этим просто на 150% обязан заниматься сервер

5) Так и нет иерархии групп, как и не появилось даже проблеска понимания того факта, что «группа» может быть таким же объектом мониторинга, как и «хост». Привет, «сгруппированные»/агрегированные метрики, для которых по-прежнему нужно создавать фейковый «типа хост»

6) Триггеры, объединяющие метрики из разных шаблонов, триггеры по состоянию IT-сервисов - всё в минус.

7) До сих пор нет встроенного SNMP-трапера и нет «ленты событий», которая позволяла бы видеть временное окно с event'ами, генерируемыми теми же входящими trap-сообщениями. Вся логика событий безальтернативно триггерная, нельзя просто узнать о том, что железка tell me something, нужно непременно строить логику непонятно как закрываемых триггеров.

Что появилось: красивые графики, содержимое которых по прежнему вытаскивается тяжеленными запросами в РСУБД или в Эластик, какая-то ещё более забубённая и непонятно кому нужная логика закрытия «Проблем», развитие катастрофически реализованной с т.з. СУБД темы тэгов (тэг - не наследуемый объект, на который ссылаются из таблиц, тэг - это копируемая сущность без всех нормальных реляционных привязок, реализованы чуть лучше, чем откровенный треш с «ирерархическими группами», но всё равно на уровне ниже первого hello, world'а на тему СУБД). Сжатие притащили - видимо, из-за того, что его было просто реализовать, а не из-за того, что тьмы несметные пользователей об этом просили (мне это точно не нужно было никогда, но наверняка есть 1.5 человека, которым нужно).

Фронтенд стал ещё более безальтернативным и незаменимым, ключевые возможности ядра системы не реализованы, хотя о многих из них просили давным

Очень многое, чего ждали от 4.0, так и не случилось,и это несколько обескураживает:

1) До сих пор нет возможности подключать любой драйвер для записи timeseries-данных. Если бы это было возможно, и если бы механизм был описан, сообщество само бы создало драйвер для записи в нормальную time series db, раз уж в Риге на это никак не решатся по каким-то неведомым причинам

2) Elastic Search - не time series db, накладные расходы на чтение истории метрик из неё тоже чрезмерно высоки, хотя и поменьше, чем в случае с MySQL и прочими РСУБД, по определению не предназначенными для хранения временных рядов

3) Нет подвижек в сторону развития малоюзабельных сейчас IT Services, хотя тема ITSI давно уже является ключевой в планах развития всех известных мне крупных систем мониторинга

4) При наличии очень странного разделения на нормальный серверный Zabbix API мизерных размеров и огромный тупой и неповоротливый PHP Zabbix API на стороне фронтенда, ничего не сделано для отказа от последнего в пользу первого. На мой взгляд, это не очень здорово хотя бы по той причине, что делает фронтенд zabbix не фронтендом, а по сути неотделимой от ядра компонентой. Традиционная архитектура подобного рода приложений предполагает, что можно легко выкинуть штатный фронтенд и заменить своим, но zabbix-морда предоставляет безальтернативный «как бы API», общающийся напрямую с базой данных, а не с сервером zabbix и к тому же делает вовсе странные вещи типа расчёта SLA для IT Services, хотя этим просто на 150% обязан заниматься сервер

5) Так и нет иерархии групп, как и не появилось даже проблеска понимания того факта, что «группа» может быть таким же объектов мониторинга, как и «хост». Привет, «сгруппированные» метрики, для которых по-прежнему нужно создавать фейковый «типа хост»

6) Триггеры, объединяющие метрики из разных шаблонов, триггеры по состоянию IT-сервисов - всё в минус.

7) До сих пор нет встроенного SNMP-трапера и нет «ленты событий», которая позволяла бы видеть временное окно с event'ами, генерируемыми теми же входящими trap-сообщениями. Вся логика событий безальтернативно триггерная, нельзя просто узнать о том, что железка tell me something, нужно непременно строить логику непонятно как закрываемых триггеров.

Что появилось: красивые графики, содержимое которых по прежнему вытаскивается тяжеленными запросами в РСУБД или в Эластик, какая-то ещё более забубённая и непонятно кому нужная логика закрытия «Проблем», развитие катастрофически реализованной с т.з. СУБД темы тэгов (тэг - не наследуемый объект, на который ссылаются из таблиц, тэг - это копируемая сущность без всех нормальных реляционных привязок, реализованы чуть лучше, чем откровенный треш с «ирерархическими группами», но всё равно на уровне ниже первого hello, world'а на тему СУБД). Сжатие притащили - видимо, из-за того, что его было просто реализовать, а не из-за того, что тьмы несметные пользователей об этом просили (мне это точно не нужно было никогда, но наверняка есть 1.5 человека, которым нужно).

Фронтенд стал ещё более безальтернативным и незаменимым, ключевые возможности ядра системы не реализованы, хотя о многих из них просили давным

Очень многое, чего ждали от 4.0, так и не случилось,и это несколько обескураживает:

1) До сих пор нет возможности подключать любой драйвер для записи timeseries-данных. Если бы это было возможно, и если бы механизм был описан, сообщество само бы создало драйвер для записи в нормальную time series db, раз уж в Риге на это никак не решатся по каким-то неведомым причинам

2) Elastic Search - не time series db, накладные расходы на чтение истории метрик из неё тоже чрезмерно высоки, хотя и поменьше, чем в случае с MySQL

3) Ничего не сделано в сторону развития малоюзабельных сейчас IT Services, хотя тема ITSI давно уже является ключевой в планах развития всех известных мне крупных систем мониторинга

4) При наличии очень странного разделения на нормальный серверный Zabbix API мизерных размеров и огромный тупой и неповоротливый PHP Zabbix API на стороне фронтенда, ничего не сделано для отказа от последнего в пользу первого. На мой взгляд, это не очень здорово хотя бы по той причине, что делает фронтенд zabbix не фронтендом, а по сути неотделимой от ядра компонентой. Традиционная архитектура подобного рода приложений предполагает, что можно легко выкинуть штатный фронтенд и заменить своим, но zabbix-морда предоставляет безальтернативный «как бы API», общающийся напрямую с базой данных, а не с сервером zabbix и к тому же делает вовсе странные вещи типа расчёта SLA для IT Services, хотя этим просто на 150% обязан заниматься сервер

5) Так и нет иерархии групп, как и не появилось даже проблеска понимания того факта, что «группа» может быть таким же объектов мониторинга, как и «хост». Привет, «сгруппированные» метрики, для которых по-прежнему нужно создавать фейковый «типа хост»

6) Триггеры, объединяющие метрики из разных шаблонов, триггеры по состоянию IT-сервисов - всё в минус.

7) До сих пор нет встроенного SNMP-трапера и нет «ленты событий», которая позволяла бы видеть временное окно с event'ами, генерируемыми теми же входящими trap-сообщениями. Вся логика событий безальтернативно триггерная, нельзя просто узнать о том, что железка tell me something, нужно непременно строить логику непонятно как закрываемых триггеров.

Что появилось: красивые графики, содержимое которых по прежнему вытаскивается тяжеленными запросами в РСУБД или в Эластик, какая-то ещё более забубённая и непонятно кому нужная логика закрытия «Проблем», развитие катастрофически реализованной с т.з. СУБД темы тэгов (тэг - не наследуемый объект, на который ссылаются из таблиц, тэг - это копируемая сущность без всех нормальных реляционных привязок, реализованы чуть лучше, чем откровенный треш с «ирерархическими группами», но всё равно на уровне ниже первого hello, world'а на тему СУБД). Сжатие притащили - видимо, из-за того, что его было просто реализовать, а не из-за того, что тьмы несметные пользователей об этом просили (мне это точно не нужно было никогда, но наверняка есть 1.5 человека, которым нужно).

Фронтенд стал ещё более безальтернативным и незаменимым, ключевые возможности ядра системы не реализованы, хотя о многих из них просили давным

Очень многое, чего ждали от 4.0, так и не случилось,и это несколько обескураживает: 1) До сих пор нет возможности подключать любой драйвер для записи timeseries-данных. Если бы это было возможно, и если бы механизм был описан, сообщество само бы создало драйвер для записи в нормальную time series db, раз уж в Риге на это никак не решатся по каким-то неведомым причинам