Comments 18
Зашел на сайт Inperfo «Попробуйте мощный, но простой и очень дешёвый способ мониторинга вашей сети.»
Я так и не понял он бесплатный или нет? Пока времени нету разбираться но вроде бы удобный.
Я так и не понял он бесплатный или нет? Пока времени нету разбираться но вроде бы удобный.
Да, бесплатный.
А почему не open-source? Планируете продавать? Извините, но "бесплатный" ассоциируется с "бесплатными" программами под windows
Сделайте docker exec -ti… в контейнер – там всё на php, кроме подсчёта персентилей – на golang оно раз в 7 получилось быстрее.
Я немного не это имел в виду.
Мне не понятно — что побуждает человека разрабатывать софт и выкладывать в бесплатное пользование, когда есть гитхаб? Разместил там проект, попиарился на хабре, поставили звездочки куча людей — все, ты супер стар. А смысл просто давать кому-то бесплатно? При том, что сейчас "бесплатно" — не магические слово, на которое все поведутся, когда есть куча бесплатного опен сорса
Архитектуру системы мониторинга, которой я симпатизирую, можно разложить на компоненты ( за которыми можно увидеть процессы):
1) Ядро, позволяющее генерировать события на основе данных от агентов. Триггеры. Отправка событий дальше. В систему обработки событий, а если таковой нет, то непосредственно заниматься уведомлениями.
2) Агенты. Сбор данных(метрик) с конечных устройств. Агенты собирают данные с ОС и ПО или удаленно, используя разнообразные протоколы.
3) База данных истории. Тем или иным образом данные от агентов попадают в базу данных истории.
4) Ну и портал. Интерфейс для тех данных что доступны. Хоть реальные данные с агентов, хоть данные из истории.
5) Система отчетности. Генерация отчетов на основе данных истории. Вывод данных html, excel, pdf и т. п.
А дальше еще куча компонентов.
Разработчики систем мониторинга могут перетасовывать основные компоненты разнообразным образом, решая свои задачи.
Так вот. Мое мнение что надо было разобраться с системой отчетности от той системы мониторинга, которая максимально удовлетворяет ваши потребности. Или прикрутить готовую систему отчетности к системе мониторинга или написать свою. Создание компонентов, которые можно интегрировать с существующими системами более продуктивно, чем создавать с нуля новые системы целиком.
1) Ядро, позволяющее генерировать события на основе данных от агентов. Триггеры. Отправка событий дальше. В систему обработки событий, а если таковой нет, то непосредственно заниматься уведомлениями.
2) Агенты. Сбор данных(метрик) с конечных устройств. Агенты собирают данные с ОС и ПО или удаленно, используя разнообразные протоколы.
3) База данных истории. Тем или иным образом данные от агентов попадают в базу данных истории.
4) Ну и портал. Интерфейс для тех данных что доступны. Хоть реальные данные с агентов, хоть данные из истории.
5) Система отчетности. Генерация отчетов на основе данных истории. Вывод данных html, excel, pdf и т. п.
А дальше еще куча компонентов.
Разработчики систем мониторинга могут перетасовывать основные компоненты разнообразным образом, решая свои задачи.
Так вот. Мое мнение что надо было разобраться с системой отчетности от той системы мониторинга, которая максимально удовлетворяет ваши потребности. Или прикрутить готовую систему отчетности к системе мониторинга или написать свою. Создание компонентов, которые можно интегрировать с существующими системами более продуктивно, чем создавать с нуля новые системы целиком.
Not invented here, как оно есть. Вместо того, чтобы взять готовый заббикс и допилить к нему пару новых шаблонов + экран с отображением в удобном для вас виде, решили писать ещё один велосипед с нуля. Ну, ок.
Расскажите чуть подробнее, как именно в заббиксе допилить такой экран?
А зачем именно такой экран, что на нём смотреть и зачем? (просто интересно).
Ну а заббиксом я, например, постоянно нагрузку не мониторю — достаточно триггеров с оповещением, если на каких-то интерфейсах нагрузка держится дольше заданного или меньше нужного.
А если хочется картинок, можно собрать сводный график или «дашборд» графиков, на которых будут нужные нагрузки на интерфейсах с потолком.
Ну а заббиксом я, например, постоянно нагрузку не мониторю — достаточно триггеров с оповещением, если на каких-то интерфейсах нагрузка держится дольше заданного или меньше нужного.
А если хочется картинок, можно собрать сводный график или «дашборд» графиков, на которых будут нужные нагрузки на интерфейсах с потолком.
> А зачем именно такой экран, что на нём смотреть и зачем? (просто интересно).
Затем, что периодически просматривая такой график, становятся очевидны самые
нагруженные места сети. В голове остаётся «картинка» профиля нагрузки, и любые
отклонения вызывают соответствующие вопросы к команде программистов/продактов.
> А если хочется картинок, можно собрать сводный график или
> «дашборд» графиков, на которых будут нужные нагрузки на
> интерфейсах с потолком.
Каких именно графиков вы добавите в дашборд?
Представьте, у вас 100+ аплинков от access-свитчей и 1000+ портов от различных
сервисов (кеши, базы, прочая), нагрузка на которые меняется или неспешно растёт
«непредсказуемо» с точки зрения сетевика, но понятна с точки зрения продукт-менеджера.
Добавлять в такой дешборд придётся всё подряд, как-то сортировать и глазами отсматривать.
Затем, что периодически просматривая такой график, становятся очевидны самые
нагруженные места сети. В голове остаётся «картинка» профиля нагрузки, и любые
отклонения вызывают соответствующие вопросы к команде программистов/продактов.
> А если хочется картинок, можно собрать сводный график или
> «дашборд» графиков, на которых будут нужные нагрузки на
> интерфейсах с потолком.
Каких именно графиков вы добавите в дашборд?
Представьте, у вас 100+ аплинков от access-свитчей и 1000+ портов от различных
сервисов (кеши, базы, прочая), нагрузка на которые меняется или неспешно растёт
«непредсказуемо» с точки зрения сетевика, но понятна с точки зрения продукт-менеджера.
Добавлять в такой дешборд придётся всё подряд, как-то сортировать и глазами отсматривать.
Можно попробовать настроить grafana +
zabbix-plugin.
zabbix-plugin.
> Каких именно графиков вы добавите в дашборд?
Сводных графиков ключевых интерфейсов. А на дашборт пачку таких сводных графиков.
> Представьте, у вас 100+ аплинков от access-свитчей и 1000+ портов
При таком количестве картинки наблюдать не очень эффективно (по крайней мере у меня не получалось).
Лучше триггеров пораскидать с разными предельными значениями и уровнями угрозы.
А в целом — дело хозяйское, кому что удобнее.
Сводных графиков ключевых интерфейсов. А на дашборт пачку таких сводных графиков.
> Представьте, у вас 100+ аплинков от access-свитчей и 1000+ портов
При таком количестве картинки наблюдать не очень эффективно (по крайней мере у меня не получалось).
Лучше триггеров пораскидать с разными предельными значениями и уровнями угрозы.
А в целом — дело хозяйское, кому что удобнее.
Затем, что периодически просматривая такой график, становятся очевидны самые
нагруженные места сети.
ну если держать только ради того чтобы на него смотреть вот прямо сейчас — возможно. а если будет вопрос «что случилось в 4 утра, когда все спали, почему серисы были некоторым пользователям недоступны»?
и да, в заббиксе для таких целей вполне можно calculated значения (в %) сохранять, и выводить их столбиком. о триггерах и уведомлениях (звук при открытой вкладке, почта, смс) — думаю, и говорить не стоит.
Ну вы всяк пишете php+бд+вот это всё. Можете либо к вашему куску кода «снизу»
У меня например Zabbix + Observium. Отлично дополняют друг друга.
Такого рода обзорные дашборды в grafana вполне можно реализовать, например, с помощью natel-discrete-panel plugin, раскрасив пороговые значения по вкусу, или с помощью Heatmap панели.
Общая беда табличных обзорных гляделок в том, что экран не резиновый, а со скроллингом теряется юзабилити.
Выбор RRD для backend тоже не единственный вариант. Может пора уже "старичку" на покой? Почему не посмотреть в сторону influxdb, prometheus,clickhhouse?
Sign up to leave a comment.
Inperfo – минималистичный мониторинг сети