Комментарии 7
Вы метрики в графит через заббикс протаскиваете, или же просто начинаете слать вместо заббикса в графит?
Было бы интересно подробнее узнать о практической пользе данного подхода, насколько он применим на практике. Ведь понятно, что для разных метрик должны использоваться различные алгоритмы. Это означает то, что магии не будет — систему всё-равно придётся конфигурировать и долго тюнить. При этом, как мне кажется, она будет очень чувствительна к любым изменениям. Например, добавили дисков (cpu, память, нод и т.п.) и получили кучу false-positives об изменении поведения.
К слову сказать, потратив немного времени можно все эти алгоритмы реализовать и на стороне Заббикса. При этом, как мне кажется, мы получим лучшее решение без ограничений по количеству анализируемой информации и работающее в режиме реального времени.
К слову сказать, потратив немного времени можно все эти алгоритмы реализовать и на стороне Заббикса. При этом, как мне кажется, мы получим лучшее решение без ограничений по количеству анализируемой информации и работающее в режиме реального времени.
К сожалению, магии не существует. Любую систему мониторинга надо настраивать под себя.
Практическая польза данного подхода наступает когда число метрик достигает десятков тысяч: с каждого объекта мониторинга поступают сотни метрик и все это умножаем на сотни объектов. Даже используя шаблоны Zabbix настроить такое количество параметров вручную очень тяжело. И опять же, параметры срабатывания триггеров необходимо выставлять в большинстве случаев индивидуально. Таким образом, система остается чувствительной.
Я не предлагаю отказываться от классических систем мониторинга. Они обязаны работать вместе. Какие-то данные лучше отслеживать с помощью Zabbix, а какие-то — с помощью Kale. Для сбора данных Zabbix очень хорош, но для анализа он слабо подходит. Основная трудность — все исторические данные Zabbix хранятся в реляционной базе данных и регулярно делать выборки с целью анализа сильно нагружает базу. Существует прослойка (https://github.com/miraclelinux/HistoryGluon) для хранения данных в NoSQL, но пока до нее руки не добрались.
Практическая польза данного подхода наступает когда число метрик достигает десятков тысяч: с каждого объекта мониторинга поступают сотни метрик и все это умножаем на сотни объектов. Даже используя шаблоны Zabbix настроить такое количество параметров вручную очень тяжело. И опять же, параметры срабатывания триггеров необходимо выставлять в большинстве случаев индивидуально. Таким образом, система остается чувствительной.
Я не предлагаю отказываться от классических систем мониторинга. Они обязаны работать вместе. Какие-то данные лучше отслеживать с помощью Zabbix, а какие-то — с помощью Kale. Для сбора данных Zabbix очень хорош, но для анализа он слабо подходит. Основная трудность — все исторические данные Zabbix хранятся в реляционной базе данных и регулярно делать выборки с целью анализа сильно нагружает базу. Существует прослойка (https://github.com/miraclelinux/HistoryGluon) для хранения данных в NoSQL, но пока до нее руки не добрались.
Спасибо! Будет чем заняться на майских праздниках.
Интересно было бы сравнить Kale и Grok
Может проще было бы попросить пользователя shmuma продолжить цикл статей?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Kale — open source-инструмент для обнаружения и корреляции аномалий