Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 24
У вас, кажется, ошибка:
60, наверное?
retentions = 60s:1y
Это означает, что данные будут поступать в базу каждые 10 секунд
60, наверное?
Не сравнивали со связкой Logstash -> Elasticsearch -> Kibana?
Там вроде намного меньше технологий пересекается, должо быть проще в настройке.
Там вроде намного меньше технологий пересекается, должо быть проще в настройке.
Как я понимаю, такой набор технологий не для сбора метрик. Например, Whisper для этого подходит куда лучше + автоматическая чистка данных.
Я верю, что каждый инструмент хорош для выполнения своего спектра задач. Для наших задач текущий стэк подходит лучше всего: мы контролируем все железо, каждый отдельный сервис, получаем качественные оповещения с минимумом false-positive, имеем возможность в обход Nagios-а слать кастомные стат. данные из любых мест нашей платформы напрямую в Whisper и отслеживать всю эту прелесть со скоростью ее изменений на больших экранах.
К тому же, я лично за подход «убился — разобрался — работает как часы», чем за «проще в настройке — поставил — должно работать». Разве не для того мы тут все статьи пишем, чтобы как раз делиться опытом настройки сложных вещей?
К тому же, я лично за подход «убился — разобрался — работает как часы», чем за «проще в настройке — поставил — должно работать». Разве не для того мы тут все статьи пишем, чтобы как раз делиться опытом настройки сложных вещей?
У ELK-стека другой предназначение, он хорош для логов, которые содержат текстовые сообщения, структурированные или не очень. Так что это не альтернатива, а дополнение к описанным выше технологиям.
Метрики это числа, их можно естественным образом агрегировать и сжимать по времени. Данные за сегодня храним с разрешением в одну секунду, метрики за прошлый месяц усредняем поминутно, а для сравнения нынешнего года с предыдущим достаточно знать старые метрики с разрешением в час. Данные никогда полностью не удаляются, просто становятся менее подробными по мере устаревания.
Elasticsearch такого не может, да и бессмысленно это, усреднять текстовые данные. Зато хорошо помогает в поиске и устранении ошибок. Ограниченное время хранения (дни, недели) — не помеха, всё равно крайне редко интересует stack-trace исключения годичной давности. Баги обычно нужно фиксить здесь и сейчас. Декорирование записей тэгами также очень удобно, например у нас микросервисы вызывают друг-друга и каждый пишет в логи общий для всей цепочки correlation-id. Когда сервис в глубине системы рушится, в Кибане можно в пару кликов вывести всю цепочку вызовов приведшую к проблеме.
Понятно, что Kibana имеет простенькие средства агрегирования и примтивную математику по цифровым полям, так что при большом желании можно использовать её и для показа метрик, но остаются проблемы с историческими данными, плюс на средства визуализации невозможно смотреть без слёз. Например есть бессмысленный pie-chart, но нет горизонтального bar-chart. Хорошо хоть у Elasticsearch есть простой и понятный REST-API, так что легко приделать собственный интерфейс. Мы писали собственные плагины к AtlasBoard, которые тянут данные из ElasticSearch и показывают JavaScript-ом в браузере, благо графических JS-библиотек есть немерено, на любой вкус и цвет.
По моему мнению, Nagios+Grafana хорошо подходят для мониторинга железа, и «больших технологий» общих для всех, например «мы хостим веб-сайт». ELK хорош, если важна специфика работы конкретного приложения и требуются ответы на вопросы типа «пользователи жалуются, что проверка правильности почтового адреса часто рушится, если в названии города есть буква 'ё', проверь пожалуйста, так ли это».
Метрики это числа, их можно естественным образом агрегировать и сжимать по времени. Данные за сегодня храним с разрешением в одну секунду, метрики за прошлый месяц усредняем поминутно, а для сравнения нынешнего года с предыдущим достаточно знать старые метрики с разрешением в час. Данные никогда полностью не удаляются, просто становятся менее подробными по мере устаревания.
Elasticsearch такого не может, да и бессмысленно это, усреднять текстовые данные. Зато хорошо помогает в поиске и устранении ошибок. Ограниченное время хранения (дни, недели) — не помеха, всё равно крайне редко интересует stack-trace исключения годичной давности. Баги обычно нужно фиксить здесь и сейчас. Декорирование записей тэгами также очень удобно, например у нас микросервисы вызывают друг-друга и каждый пишет в логи общий для всей цепочки correlation-id. Когда сервис в глубине системы рушится, в Кибане можно в пару кликов вывести всю цепочку вызовов приведшую к проблеме.
Понятно, что Kibana имеет простенькие средства агрегирования и примтивную математику по цифровым полям, так что при большом желании можно использовать её и для показа метрик, но остаются проблемы с историческими данными, плюс на средства визуализации невозможно смотреть без слёз. Например есть бессмысленный pie-chart, но нет горизонтального bar-chart. Хорошо хоть у Elasticsearch есть простой и понятный REST-API, так что легко приделать собственный интерфейс. Мы писали собственные плагины к AtlasBoard, которые тянут данные из ElasticSearch и показывают JavaScript-ом в браузере, благо графических JS-библиотек есть немерено, на любой вкус и цвет.
По моему мнению, Nagios+Grafana хорошо подходят для мониторинга железа, и «больших технологий» общих для всех, например «мы хостим веб-сайт». ELK хорош, если важна специфика работы конкретного приложения и требуются ответы на вопросы типа «пользователи жалуются, что проверка правильности почтового адреса часто рушится, если в названии города есть буква 'ё', проверь пожалуйста, так ли это».
Спасибо за развернутый ответ. Я так понял если подытожить, то ELK — для хипстеров )
Врач начинает осмотр с измерения температуры и давления. Да, есть сотни разных болезней и других причин для повышенной температуры, и это крайне неточная метрика, но она проста в измерении и позволяет быстро определить кому из пациентов нужно уделить больше внимания. Больному с жаром назначают дополнительные, более точные, анализы.
Grafana хороша чтоб с одного взгляда на необычную загрузку процессора, памяти или долгое время отклика определить, что пора вызывать программистов. А вот они для вылавливания багов полезут в хранящиеся в Elasticsearch логи, потому как «средняя температура по больнице» недостаточно точный инструмент.
Кибана в роли Dashboard это действительно «для хипстеров». Она хороша как интерактивный инструмент, а для висящего под потолком телевизора подходит плохо.
Grafana хороша чтоб с одного взгляда на необычную загрузку процессора, памяти или долгое время отклика определить, что пора вызывать программистов. А вот они для вылавливания багов полезут в хранящиеся в Elasticsearch логи, потому как «средняя температура по больнице» недостаточно точный инструмент.
Кибана в роли Dashboard это действительно «для хипстеров». Она хороша как интерактивный инструмент, а для висящего под потолком телевизора подходит плохо.
Grafana хороша чтоб с одного взгляда на необычную загрузку процессора, памяти или долгое время отклика определить, что пора вызывать программистов. А вот они для вылавливания багов полезут в хранящиеся в Elasticsearch логи, потому как «средняя температура по больнице» недостаточно точный инструмент.
В точку!
А сам nagios настраивается по старинке в текстовых конфигах?
Можно посмотреть еще примеров красивых экранов?
Можно посмотреть еще примеров красивых экранов?
Почему решили использовать Nagios — допустим тот же Zabbix отрисовывает отличнейшие графики и достаточно гибок.
"допустим тот же Zabbix отрисовывает отличнейшие графики и достаточно гибок."
Немного на эту тему: https://habrahabr.ru/post/275737/
Графики в Zabbix — это боль и ничего, кроме боли.
В последней версии Grafana таки допилили алертинг, в частности со Slack. На скриншоте выглядит достойно )
https://github.com/grafana/grafana/issues/2209#issuecomment-236842179
https://github.com/grafana/grafana/issues/2209#issuecomment-236842179
Алекс, спасибо за статью. Всё здорово. Мы сами используем Grafana для мониторинга Kubernetes-кластера и в целом довольны. Вопрос не совсем по теме, но понравилась, как схема нарисована. Что использовали, если не секрет? В чём рисовали?
Не смотрели в сторону Centreon? Умеет и нагиос из GUI настраивать (правда, там сейчас они свой брокер пилят, но это не большая проблема) и графики понятные строить…
Centreon взял за основу ядро Nagios и, как это принято, решил создать новый, единый стандарт. Проблема заключается в том, что когда пытаешься делать все и сразу — хорошо получается ничего) Поэтому, да, это уже не Nagios, но еще и не Grafana. Так что я предпочитаю пользоваться инструментами, которые прекрасны в своей узкой и конкретной специфике, а потом связывать эти инструменты друг с другом.
Это как учитель младших классов — знает все и про все и детям кажется что это самый умный человек на земле. А потом детишки взрослеют и наступает пора отдельно учиться математике с математиком, языкам с лингвистами и тд.
Несомненно, Centreon для многих может стать отличной альтернативой. Вопрос только в подходе к своим задачам. Какие задачи, такие и инструменты.
Это как учитель младших классов — знает все и про все и детям кажется что это самый умный человек на земле. А потом детишки взрослеют и наступает пора отдельно учиться математике с математиком, языкам с лингвистами и тд.
Несомненно, Centreon для многих может стать отличной альтернативой. Вопрос только в подходе к своим задачам. Какие задачи, такие и инструменты.
Спасибо за ответ. Несомненно Grafana строит /более/ красивые графики. Но по трудозатратам на внедрение системы мониторинга (а затем ее поддержки), имхо, как-то несопоставимо: поставить один готовый продукт, который умеет практически все «из коробки», или взаимоувязывать 5 различных продуктов.
Про «делать все и сразу» и «все плохо» я как-то не понял. Что Центреон делает плохо?
Про «делать все и сразу» и «все плохо» я как-то не понял. Что Центреон делает плохо?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Визуальный мониторинг серверной инфраструктуры на базе Nagios + Grafana