LINUX.ORG.RU
ФорумTalks

Смысл graphite, prometheues и opentsdb?

 ,


0

2

Не понимаю, в чём собственно смысл систем мониторинга, которые не являются по факту системами мониторинга: ни сборщиков данных, ни расчёта триггеров. А без этого - зачем нужны графики? Даже если какие-то чудо-скрипты, понаписанные ВМЕСТО нормальной системы мониторинга, отправят в Prometheus или Graphite метрики - кто их смотреть будет и как использовать? Не может же админ повесить себе в лучшем случае десяток тысяч графиков - и на все смотреть, не отрываясь, дабы что-нибудь важное не пропустить?

Видимо, для того же Graphite данные должна чудесным образом собирать некая внешняя система мониторинга, а Graphite должен по сути только предоставлять быстрый доступ к историческим данным?

Для мониторинга работы хитроумного местечкового самописного приклада вещи типа Graphite, может, и подходят (всё равно же мониторинг по существу костыльный: ни у кого нет времени делать нормальный внешний мониторинг своих приложений - perf_counter'ы, SNMP, WMI, каждый раз приходится ковырять чёрный ящик снаружи), но я что-то совсем не врубаюсь, а как это для мониторинга инфраструктуры заюзать?

P.S. Конкретно для Zabbix'а начиная с 3-й версии можно написать на Си плагин, сгружающий историческое барахло не в РСУБД, а в те же тайм-серии: это пока для меня единственное очевидное применение даже не Graphite, а всего одной его компоненты.

★★★★★

Последнее исправление: DRVTiny (всего исправлений: 2)

Так а что «система мониторинга» должна делать, что Prometheus+AlertManager не умеет?

v9lij ★★★★★
()

С готовыми бесплатными решениями по мониторингу сразу всей инфраструктуры вообще слёзы и горе. Ни одним решением нельзя нормально пользоваться без предварительных танцев с бубном в рабочий месяц.
Тот же заббикс на рынке уже сколько? Лет 15? А начинаешь ставить и просто офигиваешь от количества костылей на ровном месте, будто его только неделю назад закончили писать рабы под плетьми сдавая на пол года раньше срока

anonymoos ★★★★★
()

Дали в отделе пареньку задачку: Настроить мониторинг чернил на всех МФУ в организации, чтобы он примерно вычислял где скоро должны закончится чернила и заранее уведомлял об этом.
Перед сотней фирм из ста стоит подобная задача. Она абсолютно типовая. Как вы думаете, сколько систем мониторинга позволяют её с ходу решить? Ноль. В том же заббиксе пришлось изрядно позаниматься сексом для этого.

anonymoos ★★★★★
()
Ответ на: комментарий от anonymoos

Как вы думаете, сколько систем мониторинга позволяют её с ходу решить? Ноль.

Severcart мелькал тут в новостях. Оно не готово или вообще не рассматривалось?

mandala ★★★★★
()
Последнее исправление: mandala (всего исправлений: 1)
Ответ на: комментарий от mandala

Не рассматривалось, т.к. хотелось весь мониторинг в одном решении иметь

anonymoos ★★★★★
()

Я не понимаю, что ты хочешь этим сказать, потому-что не думаю, что ты не знаешь как все обычно работает.
А конкретно: скрипт или мониторинг (назовем это просто приложение) собирает метрики. Далее метрики отправляются в TSDB (назовем это источником данных, потому-что именно отсюда данные подключаются). И напоследок к примеру таже Grafana и ее аналоги, которая подключает к себе источник/источники данных, где как раз ты строишь красивые графики и делаешь оповещения (чаще всего дополнительные) на основе этих данных.
Но ведь мониторинг может сам слать оповещения и некоторые тоже строят графики, скажешь ты? Так дело, в том что это первоначальный инструмент, которые работает с данными обычно в реальном времени. А для того чтобы хранить за долгий период и далее более полно обрабатывать данные тебе и нужны следующие инструменты. Далее, если графиков слишком, много или ты неверно выделил ключевые, тебе может понадобиться еще следующий инструмент, который будет уже заниматься deep learning'ом этого всего (причем такой инструмент, не отменит необходимость в других инструментах, плюс скорей всего его лучше подключать к источнику данных, в данном примере к TSDB), но как правило большинству хватает админа или просто оповещений и выделения ключевых для бизнес процесса графиков.

anonymous_sama ★★★★★
()

Не понимаю, в чём собственно смысл систем мониторинга, которые не являются по факту системами мониторинга: ни сборщиков данных, ни расчёта триггеров. А без этого - зачем нужны графики?

Это не «контрольная панель», а «сбор телеметрии», если ты понимаешь о чём я

Ты не спамишь себе на почту, тупо собираешь все данные, которые теоретически могут пригодиться. А уже потом, при возникновении инцидента или при оценке производительности, ты имеешь данные для анализа. И смотришь на эти данные и достигаешь просветления - причина была в parameter1 = 0, если parameter2 >= 200. И уже понимаешь, что нужно добавить в основную систему мониторинга

router ★★★★★
()
Ответ на: комментарий от anonymous_sama

Если резюмировать: коллекционирование исторических данных, построение графиков, оповещения. Оповещения в graphite не идут ни в какое сравнение с тем же zabbix'ом.

В принципе вижу ещё одно практическое применение тайм-серий: построение отчётов за период для начальства/заказчика... Пока не сталкивался с ситуациями, когда бы мне не хватало бы графиков заббикса (несмотря на то, что там почти всегда графики строятся по трендам, т.е. по среднему/максимальному/минимальному за час), но исторические данные из него тянуть - это действительно просто БОЛЬ :)

DRVTiny ★★★★★
() автор топика
Ответ на: комментарий от anonymoos

В Zabbix'е есть предсказания значений метрики в будущем на базе собранных в прошлом, появились в 3.0, а сейчас уже 3.2...

DRVTiny ★★★★★
() автор топика
Ответ на: комментарий от DRVTiny

Тут еще и проблема масштабирования. Ты можешь иметь сразу несколько небольших TSDB в качестве источников данных. А вот с одной огромной базой и «классический» мониторинг с агентами уже скорей всего начнет тормозить. А иметь сразу два и более того же Zabbix'а уже не так интересно. Впрочем Zabbix отлично подключается к той же Grafana. Так что промежуточные варианты тоже возможны. Ну и плюс zabbix на калькуляторе ты не запустишь, а ту же современную netdata (более того netdata, даже быстрее будет чем просто скрипт, на том же bash/python), вполне, причем получишь уже более 900 метрик и куча графиков из коробки.

anonymous_sama ★★★★★
()
Ответ на: комментарий от anonymous_sama

Ну и плюс zabbix на калькуляторе ты не запустишь

В смысле? На калькуляторе запускается агент мониторинга, а он просто как 5 копеек и не требует для своей работы почти ничего.

Графана подключается к Заббиксу (если речь о плагине) не в том направлении: она подключается через кошмарно тормозной «API» (отвратительного качества PHP-код на стороне веб-морды заббикса) и вытягивает исторические данные только для графиков - вместо того, чтобы подключаться напрямую к базе, делать селекты, соъхранять тайм-серии и уже по ним что-то строить. Но графана - просто движок для отрисовки деловой графики, поэтому творить чудеса не может.

DRVTiny ★★★★★
() автор топика
Ответ на: комментарий от anonymous_sama

api_jsonrpc.php очень тормозной , что вкупе с катастрофически тормозными history даёт феерический эффект. Вот использование InfluxDB вместо РСУБД для истории Zabbix'а было бы просто бесценно...

DRVTiny ★★★★★
() автор топика
Последнее исправление: DRVTiny (всего исправлений: 1)
Ответ на: комментарий от DRVTiny

Вот использование InfluxDB вместо РСУБД для истории Zabbix'а было бы просто бесценно...

Так в этом основная проблема zabbix и прочих: эти комбайны очень сложно интегрировать и адаптировать под чуть другие задачи или в другую инфраструктуру.

поэтому появляются более модульные системы, типа prometheus + alertmanager + grafana, когда каждый модуль отвечает за свое и соответственно чище в плане кода и более гибок.

prometheus вообще под kubernetes пишется, где у тебя контейнеры рождаются и умирают раз в пять минут, а приложение - это абстрактный сервис, за которым не стоит никакой фиксированной железки. Там метрики агрегируются иначе, и историю надо не по хостам показывать.

alpha ★★★★★
()
Последнее исправление: alpha (всего исправлений: 1)
Ответ на: комментарий от alpha

Zabbix модульный, и сейчас там есть интерфейс наподобие унифицированного интерфейса драйверов ФС для подключения внешних хранилищ history - они же не идиоты, и уже давно поняли, что как раз этого все хотят. Но... почему-то до сих пор нет готового плагина... или я что-то упустил.

DRVTiny ★★★★★
() автор топика
Ответ на: комментарий от alpha

когда каждый модуль отвечает за свое и соответственно чище в плане кода и более гибок.

С этим не соглашусь как минмум из-за того, что каждый модуль, написанный независимыми разработчиками - это вещь в себе, со всеми её траблами, нереализованными возможностями, багтрекерами и дисклеймерами в открытой лицензии.

DRVTiny ★★★★★
() автор топика
Ответ на: комментарий от DRVTiny

Угу, это был один из аргументов в пользу его конечного выбора (хотя дело было в 2015 а 3.0 вышел в 2016, но что-то там вроде уже было реализовано на счет предсказаний)

Возвращаясь к теме топика, как там дела с Forecasting во всех этих посейдонусах?

anonymoos ★★★★★
()
Ответ на: комментарий от anonymoos

В том же заббиксе пришлось изрядно позаниматься сексом для этого.

на самом деле это называется работа системного администратора.

Перед сотней фирм из ста стоит подобная задача.

не нужно себе льстить. лично я ни в одной фирме с этой задачей не сталкивался. возможно, потому что количество серверов заметно превышало количество принтеров.

без предварительных танцев с бубном

возможность их адаптировать является их основным преимуществом. это не понимают в основном windows админы.

crypt ★★★★★
()
Ответ на: комментарий от crypt

В том же заббиксе пришлось изрядно позаниматься сексом для этого.

на самом деле это называется работа системного администратора.

На самом деле, это называется «непродуманный интерфейс». Zabbix именно как система мониторинга - ад и израиль

без предварительных танцев с бубном

возможность их адаптировать является их основным преимуществом. это не понимают в основном windows админы.

«Возможность адаптировать» и «необходимость писать с нуля» несколько разные вещи. Только студенты и менеджеры это не понимают ;)

router ★★★★★
()
Ответ на: комментарий от router

Zabbix именно как система мониторинга - ад и израиль

то что-то хорошо делает, а что-то плохо? согласен.

«Возможность адаптировать» и «необходимость писать с нуля» несколько разные вещи. Только студенты и менеджеры это не понимают ;)

с моей т.з. СМ уже написана, а конкретные чеки - это адаптация. будем здесь искать, о чем поспорить? про недостатки zabbix я в курсе. у меня есть по нему и сертификация, и опыт (правда не по последним версиям).

p.s.

ты бы лучше также бодро в собственном треде про фото и камеры отвечал, где я тебе хороший совет оставил)

crypt ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.