Comments 36
Расскажите, чем это решение лучше Prometheus/TICK и чего-нибудь, основанного на OpenTracing? Почему отказались от версионируемой текстовой конфигурации и discovery в пользу API? Кто целевая аудитория?
Конфигурация текстовая будет в дальнейшем, сейчас было сделано через API по той причине что Dashboard нужен был больше чем тектовая концигурация.
Ох, вы опять? Олдскульный — есть nagios, есть shinken, есть icinga, есть zabbix.
Новое поколение — Prom (и проигравшие, типа kapacitor'а).
Как только вы пишите "своих агентов", мониторинг можно заканчивать.
Например, не поддерживает пром инцидентов. Ну, напишите. Принимает алерты из прома, делает над ними бизнес-логику. Но зачем изобретать велосипед целиком, если вам отсутствие корзинки сзади мешало? Мешало? Приделайте.
Вы смешиваите все в кучу. Каждая система должна приносить что то новое. Если судить как Вы, то фактически можно остановить развитие на первой появившейся системе. И получить велосипед с автомобильным рулем, кузовом КАМАЗа, двигателем Феррари и все тем же педальным управлением.
Попытка хорошая, но это скорее для саморазвития.
Для продакшена — лучше взять проверенное решение типа прометеуса или graphite (clickhouse) + moira.
Потому что иначе залипнете на традиционных вопросах по реализации мониторинга — например, как обеспечить правильную доливку данных (скажем, агент не выходил на связь неделю и пошел наливать данные с самых старых — новые метрики очевидно в наивном алгоритме можете не получить никогда), как обеспечить оптимальность скорости вычисления алертов (потому что для них нужно держать в памяти определенное "окно" с актуальными метриками) и прочее-прочее-прочее
Чем бы дитя не тешалось…
В чем Zabbix-то неустроил?
Zabbix покрывает только агентов и external/internal чеки, нет мониторинга приложений, нет инцидентов, уведомлений, мониторинга web приложений
Вот www.zabbix.com/documentation/current/ru/manual/acknowledges инциденты
Вот www.zabbix.com/documentation/current/ru/manual/config/notifications уведомления
Вот www.zabbix.com/documentation/current/ru/manual/web_monitoring мониторинг веб-приложений
Что такое мониторинг приложений в вашем понимании?
www.zabbix.com/documentation/current/ru/manual/acknowledges — где тут инциденты? тут. ложных срабатываний будет очень много, по факту у вас допустим загрузка CPU 80%, но почему это вдруг инцидент
www.zabbix.com/documentation/current/ru/manual/config/notifications — с ними согласен проглядел.
Мониторинг приложений в нашей понимании: resource usage + transaction + metric + tracing
тут. ложных срабатываний будет очень много, по факту у вас допустим загрузка CPU 80%, но почему это вдруг инцидент
Во-первых, с чего вы взяли, что у вас не будет ложных срабатываний. Во-вторых, такие вещи можно и нужно настраивать под себя.
Ложные срабатывания будут всегда, но чем правильнее ты можешь описать инциденты тем меньше их будет, допустим нагрузка на ЦП за последние 7 подряд измерений 80% плюс, допустим выросло количество памяти
моё «хозяйство»— это очень большое понятие
Не в обиду, но если вам кажется, что в такой системе, как Icinga, чего-то нет, оно либо там есть, либо это можно довольно просто добавить через плагины, корректную конфигурацию (RTFM) или API. Это по поводу статуса (инцидентов).
А по поводу нагрузок и графиков, InfluxDB + Grafana или другие аналоги, решают эту часть.
К тому-же, у вас свой агент. Вы бы сэкономили кучу времени использовав NRPE, к примеру. Он готов уже, в нем есть практически всё, что нужно, и есть в любом Линукс дистрибутиве и в Windows. Тоже самое про нагрузки. Есть, к примеру, collectd, в котором многое уже есть.
Но это, опять же, моё личное мнение. Вам виднее, если вы решили делать свою систему.
1. Кусочничество (большинство делают солянку из нескольких, но качество получается разное)
2. Комплексы NewRelic/sentry платные
3. Ограниченность функционала, поскольку комплексы почти все закрытые, то все ищут новые куски(маленькие системы с интеграцией к большой).
Вот эти задачи мы и пытаемся решить, open-source потому что мы пишешь большой комплекс, в котором стараемся покрыть все, но пока понемножку, но open-source в теории дает коммьюнити развивать. Self-host — никто не должен хранить ваши внутренние данные, даже о инфраструктуре(а без исходного кода понять что он собирает не слишком легко), я так считаю.
- Комплексы NewRelic/sentry платные
это недостоверная информация — раз. Два — сентри решает ДРУГУЮ задачу. Не мониторинг, а уведомление разработчиков об эксепшенах (багах) в софте. Повторю тезис, что аналог сентри можно построить на бесплатном ELK стеке, но усилий придется приложить… И, да, он-премис инсталляции сентри бесплатнa
А шаблоны хостов и инцидентов есть?
В нашей реализации они не нужны, вы можете написать правила с многими map/reduce функциями поэтому нам группы не нужны, плюс так же есть временные функции такие как n измерений подарят итд.
инциденты тем меньше их будет, допустим нагрузка на ЦП за последние 7 подряд измерений 80% плюс, допустим выросло количество памяти
Вы не поверите, но это прекрасно описывается в настройках триггеров. Более того, есть даже эскалация и зависимости.
в мониторинг веб приложений входит: routing, painting, first touch action как минимум.
А вы в описаниях веб-мониторинга до вкладки «Шаги» домотали?
Для графиков, InfluxDB + Grafana + CollectD. Если чего-то не хватает… пишу свой плагин.
Из статьи не понятно можно ли делать свои плагины, например. Выглядит так, как будто, мониторить нужно только хосты с web приложением. А ведь есть ещё сетевое оборудование, системы хранения и т.д.
Вспоминается история, когда Лари Пейджу (основателю гугла) говорили: зачем ещё один поисковик, когда есть яху?! Что из этого получилось знают все.
Авторам желаю успехов. Выбор и конкуренция — это всегда хорошо.
@PYXRU как успехи?
чот демка сломана, а сайт отжал какой-то ресторан
Squzy — бесплатная open-source self-host система мониторинга с инцидентами и уведомлениями