анекдот же

анекдот же

?!

"- Мыкола, а ти знаеш як москали наше пыво называють? - П-и-и-в-о. - Повбывав бы."

Не очень лопатно

Не очень лопатно

этому анекдоту лет 20, а то и больше тогда были другие kpi у анекдотов))

Когда графики ресуют маркетолохи

А что неправильно?

А что неправильно?

Толсто

Толсто

Не надо писать нижнее значение?

Не надо писать нижнее значение?

Столбчатые диаграммы должны всегда начинаться с нуля

Столбчатые диаграммы должны всегда начинаться с нуля

Ох лол, и правда. Спасибо.

Ох лол, и правда. Спасибо.

Вот видишь как тебя наебали

А сразу и не заметишь

Фороникс блджад

Вот видишь как тебя наебали

Ага, а разница там в несколько процентиков на самом деле

yandex/ClickHouse was tagged: v18.14.8-stable Link: https://github.com/yandex/ClickHouse/releases/tag/v18.14.8-stable Release notes: v18.14.8-stable

@Reuuke будет жить. Поприветствуем!

@f545_j_43g43u_jer3tfgu32fh3333 будет жить. Поприветствуем!

@Setox будет жить. Поприветствуем!

@snelyubin будет жить. Поприветствуем!

Сделали плейграунд для VictoriaMetrics - http://play-grafana.victoriametrics.com:3000/d/4ome8yJmz/node-exporter-on-victoriametrics-demo . Там можно редактировать графики.

@ngnixx будет жить. Поприветствуем!

Всем привет, коллеги поделитесь мыслями о производительности прометеуса в сравнении с графитом. К примеру Яндекс читал лекцию что они пихают в графит по 800 000 метрик в минуту и он тянет. Если у кого цифры о прометеуса?

800к в минуту?

У нас на проме было в секунду больше

Но в отрыве от реальности это сравнение не имеет смысла

Всем привет, коллеги поделитесь мыслями о производительности прометеуса в сравнении с графитом. К примеру Яндекс читал лекцию что они пихают в графит по 800 000 метрик в минуту и он тянет. Если у кого цифры о прометеуса?

Прометей быстрее

Но нужно понимать, что никто не использует однонодовые конфигурации

Всем привет, коллеги поделитесь мыслями о производительности прометеуса в сравнении с графитом. К примеру Яндекс читал лекцию что они пихают в графит по 800 000 метрик в минуту и он тянет. Если у кого цифры о прометеуса?

ну у него ведь немного другая модель , в отличии от graphite он сам забирает, и к тому же там прям из коробки у тебя есть метрика по скорости обработки данных

Так же есть вопрос со сценарием использования. Ну, типа только пишем или ещё и часто смотрим (и на какую глубину)

Поэтому тебе точных цифр никто не скажет

По графиту. Его основным пользователем является booking.com и именно они форсировали его переписывание на гошечке. Что привело к ускорению его работы на порядок

У всех использование очень разное, и пром и графит гибкие по настройке и сборке метрик, чей-то личный пример мало поможет в вашем использовании

У всех использование очень разное, и пром и графит гибкие по настройке и сборке метрик, чей-то личный пример мало поможет в вашем использовании

+1

Самая главная жопа Прометея - долговременное хранение (не оперативное)

Ну и даже если ты получаешь 1кк метрик в секунду, то это не значит, что у тебя с мониторингом всё классно

Ну у меня задачка слать все, даже то что я не знаю. Имеется ввиду слать метрики всех действий с кода , то есть я не знаю что именно я буду слать в систему сбора метрик. В таком подходе прометеус не выглядит лучшим решением

Варианты решения: второй Прометей, timescaledb, m3db

Настроить сбор метрик - даже не 20% работы

Но проблему пока не решили

Ну у меня задачка слать все, даже то что я не знаю. Имеется ввиду слать метрики всех действий с кода , то есть я не знаю что именно я буду слать в систему сбора метрик. В таком подходе прометеус не выглядит лучшим решением

Может в эластик?

Некоторые так тоже делают

Может в эластик?

Мне кажется это будет в несколько раз ресурсозатратнее но выхлоп пока не ясен.

То есть у тебя задача вида "не знаю чего хочу", и ты у нас спрашиваешь, что тебе лучше подойдёт?

Ты для начала пойми - какие ограничения

Ты же в курсе, что Прометей пуллит метрики ?

А в условный графит ты их сам пушишь ?

Не не, я ведь задал конкретный вопрос, а не кидаюсь пустыми фразами.

Ты же в курсе, что Прометей пуллит метрики ?

Да конечно в курсе. Тут вот какая проблема как пулить метрики о существовании которых ты не знаешь?

Я думаю, что самое верное - собрать PoC. И самому сделать выводы

У меня в голове вопрос звучит как: "не знаю как буду использовать, кто будет быстрее?"

Да конечно в курсе. Тут вот какая проблема как пулить метрики о существовании которых ты не знаешь?

Так Прометей автоматически подсасывает новые метрики

Не надо ими рулить

Вот да, попробуй что-то и потом считай

И старые автоматом удаляет вроде

После хх времени

В графите же придется скорее всего руками настраивать

Каждую

ERROR: S client not available

Хотя....

Так Прометей автоматически подсасывает новые метрики

Можно чуть подробнее , к примеру есть часть в ода она создаёт обьект, объект что то делает и пушит метрики своих промежуточных состояний в графит, как только объект закончил свою задачу он погибает. Как со стороны прометеуса будет выглядеть пулинг таких метрик особенно если объекты создаются и погибают с очень большой частотой

Можно чуть подробнее , к примеру есть часть в ода она создаёт обьект, объект что то делает и пушит метрики своих промежуточных состояний в графит, как только объект закончил свою задачу он погибает. Как со стороны прометеуса будет выглядеть пулинг таких метрик особенно если объекты создаются и погибают с очень большой частотой

Графит

Ему нужно аллоцировать файл под все время существования метрики

Можно чуть подробнее , к примеру есть часть в ода она создаёт обьект, объект что то делает и пушит метрики своих промежуточных состояний в графит, как только объект закончил свою задачу он погибает. Как со стороны прометеуса будет выглядеть пулинг таких метрик особенно если объекты создаются и погибают с очень большой частотой

Будет предагрегация на стороне агента/инструментария

Прометей: тупо насрать. Все сбросится на диск в файл нарастающего размера

В графите же придется скорее всего руками настраивать

В графите ни чего настраивать на надо. С кода ты указываешь имя метрики значение и куда слать. Со стороны сервера ни чего не настраивается. Графит на основании имении метрики в дот формате раскладывает их по структуре

Короче, для динамичной среды, имхо, Прометей лусше

В графите ни чего настраивать на надо. С кода ты указываешь имя метрики значение и куда слать. Со стороны сервера ни чего не настраивается. Графит на основании имении метрики в дот формате раскладывает их по структуре

Я про другое

Понятно, что ты запкшил метрику - графит ее создал

Вопрос в эффективном выборе ретеншион и прочей херни

Чтобы эта шарманка нормально работала

Короче, для динамичной среды, имхо, Прометей лусше

Так чем именно то лучше? Можно подробнее?

Так чем именно то лучше? Можно подробнее?

Производительность (?), Сервис-ориентированный подход, теги (есть и в графите), нормальный ретеншион.

P.s. я вообще долгое время жил на tick (telegraf + influx ... )

Ну у меня задачка слать все, даже то что я не знаю. Имеется ввиду слать метрики всех действий с кода , то есть я не знаю что именно я буду слать в систему сбора метрик. В таком подходе прометеус не выглядит лучшим решением

Звучит как то что ты не метрики будешь слать, а трейсы и тебе надо смотреть не на пром и графит, а на jeager какой нибудь и всякие zipkin/opencensus

Звучит как то что ты не метрики будешь слать, а трейсы и тебе надо смотреть не на пром и графит, а на jeager какой нибудь и всякие zipkin/opencensus

А логи можно грузить тачками и пачками в эластик / грейлог

Кстати, в эластик есть какой-то примитивный АРМ

Звучит как то что ты не метрики будешь слать, а трейсы и тебе надо смотреть не на пром и графит, а на jeager какой нибудь и всякие zipkin/opencensus

Слать как раз буду метрики, речь о неком финансовом продукте у которого много модулей, возмем пример - модуль скоринга, он постоянно что-то делает с клиентом, и в самом продукте виден конечный результат в виде скорингового балла, но что происходит внутри скоринга , на всех его шагах, промежуточных статусах и т.д вот что надо видеть. Это не логи а именно метрики. Технические логи и так есть в ELK , тут речь о показателях для бизнеса.

Слать как раз буду метрики, речь о неком финансовом продукте у которого много модулей, возмем пример - модуль скоринга, он постоянно что-то делает с клиентом, и в самом продукте виден конечный результат в виде скорингового балла, но что происходит внутри скоринга , на всех его шагах, промежуточных статусах и т.д вот что надо видеть. Это не логи а именно метрики. Технические логи и так есть в ELK , тут речь о показателях для бизнеса.

Просто то что ты описал не звучит как метрики)

Язабан

прохладная история

Язабан

придержите коней

Самая главная жопа Прометея - долговременное хранение (не оперативное)

А в чем жопность ?

Ну у меня задачка слать все, даже то что я не знаю. Имеется ввиду слать метрики всех действий с кода , то есть я не знаю что именно я буду слать в систему сбора метрик. В таком подходе прометеус не выглядит лучшим решением

Почему ?

Язабан

Да ладно