Как стать автором
Обновить

Комментарии 24

У вас, кажется, ошибка:
retentions = 60s:1y


Это означает, что данные будут поступать в базу каждые 10 секунд

60, наверное?
Поправил, благодарю!
Не сравнивали со связкой Logstash -> Elasticsearch -> Kibana?

Там вроде намного меньше технологий пересекается, должо быть проще в настройке.

Как я понимаю, такой набор технологий не для сбора метрик. Например, Whisper для этого подходит куда лучше + автоматическая чистка данных.

Да вроде даже крупные игроки (Netflix) если не ошибаюсь используют этот стек. Счетчики пишуться на Go. Данные удаляются дропаньем индекса. Есть механизм алертов (сам не использовал)
Данные удаляются дропаньем индекса

Если не ошибаюсь, Whisper позволяет чистить данные не полностью, а скажем, после того, как данным стали старше 6 месяцев, их сжимать.


Слабой стороной этой штуки может быть отсутствие нативных алертов и проблемы с кластеризацией.

увы-увы, лично мой опыт работы с данной связкой крайне печален
все отлично работает пока каждое по одной копии и/или на одном сервере
для масштабирования связка крайне неудобоварима, кибана с еластиком требуют ежедневного администрования, постоянно то индексы на одном из кластеров побились то кибана отвалилась
могу посоветовать посмотреть в сторону telegraf -> influx -> chronograf
связка намного проще и в настройки и в обслуживании
telegraf -> influx(с использованием CQ) -> grafana -> kapacitor — вот реально шикарно. И практически не кушает ресурсов даже на очень больших объемах данных для мониторинга.
Я верю, что каждый инструмент хорош для выполнения своего спектра задач. Для наших задач текущий стэк подходит лучше всего: мы контролируем все железо, каждый отдельный сервис, получаем качественные оповещения с минимумом 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 хорош, если важна специфика работы конкретного приложения и требуются ответы на вопросы типа «пользователи жалуются, что проверка правильности почтового адреса часто рушится, если в названии города есть буква 'ё', проверь пожалуйста, так ли это».
Спасибо за развернутый ответ. Я так понял если подытожить, то ELK — для хипстеров )
Врач начинает осмотр с измерения температуры и давления. Да, есть сотни разных болезней и других причин для повышенной температуры, и это крайне неточная метрика, но она проста в измерении и позволяет быстро определить кому из пациентов нужно уделить больше внимания. Больному с жаром назначают дополнительные, более точные, анализы.

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
Алекс, спасибо за статью. Всё здорово. Мы сами используем Grafana для мониторинга Kubernetes-кластера и в целом довольны. Вопрос не совсем по теме, но понравилась, как схема нарисована. Что использовали, если не секрет? В чём рисовали?
Часть схемы нашел где-то на просторах и дорисовал под свои нужды в Ps. Такие вещи делаются на раз-два в том же Ps или Ai — по сути, просто набор из прямоугольников, линий и текста.
Не смотрели в сторону Centreon? Умеет и нагиос из GUI настраивать (правда, там сейчас они свой брокер пилят, но это не большая проблема) и графики понятные строить…
Centreon взял за основу ядро Nagios и, как это принято, решил создать новый, единый стандарт. Проблема заключается в том, что когда пытаешься делать все и сразу — хорошо получается ничего) Поэтому, да, это уже не Nagios, но еще и не Grafana. Так что я предпочитаю пользоваться инструментами, которые прекрасны в своей узкой и конкретной специфике, а потом связывать эти инструменты друг с другом.

Это как учитель младших классов — знает все и про все и детям кажется что это самый умный человек на земле. А потом детишки взрослеют и наступает пора отдельно учиться математике с математиком, языкам с лингвистами и тд.

Несомненно, Centreon для многих может стать отличной альтернативой. Вопрос только в подходе к своим задачам. Какие задачи, такие и инструменты.
Спасибо за ответ. Несомненно Grafana строит /более/ красивые графики. Но по трудозатратам на внедрение системы мониторинга (а затем ее поддержки), имхо, как-то несопоставимо: поставить один готовый продукт, который умеет практически все «из коробки», или взаимоувязывать 5 различных продуктов.
Про «делать все и сразу» и «все плохо» я как-то не понял. Что Центреон делает плохо?
Концепт не в том, что «все плохо», а в том, что «мало хорошего») Сами говорите, что графики в Grafana на более высоком уровне. По остальным критериям то же самое.
Про графики — понятно. А остальное-то что?
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории