Про скорость -- там пузомерка была с инфлюксом.. Ща..

Latest commit 2d1fc93 on 3 Feb 2017

@dkirhlarov ну я блог читалю их, они типа в 4-6 раз быстрее постгреса

9 запросов в секунду

28 машин жмет 3М строк в секунду на вставку

очень все похоже на эластик

У него всё с первого раза отлично получилось!

28 машин жмет 3М строк в секунду на вставку

28 машин. 3 милиона. чот это как то кисловато

не, ну можно посмотреть

Чего не понятного, берешь и мажешь

Тогда надо подробнее читать...

28 машин. 3 милиона. чот это как то кисловато

ну судя по числам они в эластик как бэкнд упираются

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

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

Там на сайте менюшка Use Cases. :)

Horizontal scaling. Millions of inserts per second. Real-time SQL. Dynamic schema.

Horizontal scaling. Millions of inserts per second. Real-time SQL. Dynamic schema.

Ну не врут же

Тактично умолчали требования, а так все есть

нет умолчали - умолчали. инженерили то зачем так

чот мне это на "так исторически сложилось" похоже

Давайте попробую рассказать что хочу, а вы может быть подскажете куда смотреть... 1. Несколько локаций. Несколько продуктов. Соответственно, поллеров до двух десятков. (Нравится прометей за тэги). 2. 5 лет хранения агрегированных данных. 3. Одна линия на графане для сырых и агрегированных данных. (т.е. не только write из прометея, но и read в него в ту же метрику). Походив по просторам интернета требования, первые два требования можно либо на prometheus+influxdb, либо на prometheus federation закрыть. Но при агрегации в обоих случаях появятся новые метрики и п.3 они не покрывают. Кроме того, influx community это только одна нода, а federation -- еще и лаг во времени, когда федеративный сервер придет из поллера данные дергать. Вот про связку prometheus+cratedb думаю, либо да, в кликхаус идти смотреть...

какая цель хранение данных 5 лет ?

за 5 лет сервера/каналы/архитектура несколько раз сменятся. какой план по склейке данных ?

Сезонные изменения, рост.

5 лет надо хранить ключевые параметры или все ?

врятли есть смысл хранить больше года потребленное место в разделе /var

Не думал над этим. Это важно для выбора архитектуры?

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

врятли есть смысл хранить больше года потребленное место в разделе /var

потом же можно сказать: "твоя глюкалка два года назад место логами сожрала!"

колво метрик в секунду * стоимость точки * резервирование = цена на схд

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

даунсемплинг поможет но тоже требует проектирования

ну тоесть колво юзеров на сайте явно писькомерка. её надо хранить долго. а место на диске нет. ее надо хранить мало.

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

Дешевле железом закидать, чем человеческое время тратить на сортировку долго-недолго. :)

Давайте исходить из того, что хотим хранить все.

если метрик много и требуется хороший ha то железом закидать будет очень дорого....

трудо-дни потратить разово при планировании не жалко, а нужно

Приняли, что храним все. Давайте дальше.

считайте улетающее бабло на железо

если метрик много и требуется хороший ha то железом закидать будет очень дорого....

Я думаю что пугать не стоит, количество используемых мощностей вполне соизмеримо с проектом который данная система призвана мониторить

Приняли, что храним все. Давайте дальше.

Если с прометеусом не выгорит, могу рассказать как это сделать на "графит+кликхаус"

Там лейблы кстати тоже теперь есть

Если с прометеусом не выгорит, могу рассказать как это сделать на "графит+кликхаус"

Спасибо. Буду иметь ввиду.

Приняли, что храним все. Давайте дальше.

какая вселенская наивность. 600 серверов под такое похоронить готовы? А то есть примеры к чему такое отношение приводит.

Дешевле железом закидать, чем человеческое время тратить на сортировку долго-недолго. :)

не понял, почему чувака на вилы поднимают? он дело говорит, если что

железо и облака сейчас действительно сильно дешевле чем время разработчиков

и менее рискованно с долгосрочной точки зрения

а разработчики тут причём?

не понял, почему чувака на вилы поднимают? он дело говорит, если что

ну если проект на годик а потом в утиль, то да, планировать не надо. сейчас сделали, а потом пусть следующее поколение сношается

https://github.com/cloudflare/unsee

а я правильно перевожу название проекта как "развидеть"

Ж))))))))))))))))))))))))))))))))))))))))))

а я правильно перевожу название проекта как "развидеть"

?

Страшна там https://raw.githubusercontent.com/cloudflare/unsee/master/screenshot.png

Но вообще всё так

Очень глаза болят от этой штуки

Развидеть прямо очень хочется

а у тя она в работе ?

Программисты притащили

Но я им стараюсь отвыкать

Так Go программисты видят мир JS Web разработки

Не самый плохой дашборд. В нем хотя бы блоки информации не перекрывают друг друга

И в него не захардкожены проверки. И он не на PHP.

Давайте попробую рассказать что хочу, а вы может быть подскажете куда смотреть... 1. Несколько локаций. Несколько продуктов. Соответственно, поллеров до двух десятков. (Нравится прометей за тэги). 2. 5 лет хранения агрегированных данных. 3. Одна линия на графане для сырых и агрегированных данных. (т.е. не только write из прометея, но и read в него в ту же метрику). Походив по просторам интернета требования, первые два требования можно либо на prometheus+influxdb, либо на prometheus federation закрыть. Но при агрегации в обоих случаях появятся новые метрики и п.3 они не покрывают. Кроме того, influx community это только одна нода, а federation -- еще и лаг во времени, когда федеративный сервер придет из поллера данные дергать. Вот про связку prometheus+cratedb думаю, либо да, в кликхаус идти смотреть...

А сколько это в метриках и точках в секунду?

Агрегаты то хранить как бы недораха... только надо на берегу договориться о том насколько жать. Вот наш "индустриальный стандарт системы мониторинга" говорит о почасовых агрегатах - от этого можно в какую то сторону плясать.

ERROR: S client not available

Привет, подскажите, у вас есть примеры написанных service discovery для Prometheus? Чтобы самому посмотреть на примеры и написать.

Всем привет , а никто случайно не натыкался на какой нибудь вебинтерфейс для управления конфигами прометеуса ? Столкнулся с такой проблемой - что сейчас конфиг прометеуса очень сильно разросся (накатываю конечно через ансибл , всё норм но немного размер смущает в пару тысяч строк - возможно я както неверно использую его ...) В голову приходит только - какойто service discovery с вебинтерфейсом (для добавления сервисов) и на него натравить прометеус

Всем привет , а никто случайно не натыкался на какой нибудь вебинтерфейс для управления конфигами прометеуса ? Столкнулся с такой проблемой - что сейчас конфиг прометеуса очень сильно разросся (накатываю конечно через ансибл , всё норм но немного размер смущает в пару тысяч строк - возможно я както неверно использую его ...) В голову приходит только - какойто service discovery с вебинтерфейсом (для добавления сервисов) и на него натравить прометеус

https://github.com/line/promgen Я хотел предложить это, но тут только к алертменеджеру относится

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

https://github.com/line/promgen Я хотел предложить это, но тут только к алертменеджеру относится

я вчера его как раз искал и наткнулся на этот unsee

до сих пор не развидел?

сразу это сделал

до сих пор не развидел?

там же цвета настраивать можно ) на более адекватные

В grafana при установке threshold lt не должно ли заполнять цветом от нуля до заданного значения?

Всем привет , а никто случайно не натыкался на какой нибудь вебинтерфейс для управления конфигами прометеуса ? Столкнулся с такой проблемой - что сейчас конфиг прометеуса очень сильно разросся (накатываю конечно через ансибл , всё норм но немного размер смущает в пару тысяч строк - возможно я както неверно использую его ...) В голову приходит только - какойто service discovery с вебинтерфейсом (для добавления сервисов) и на него натравить прометеус

Кубернетес не предлагать?

Или любой другой SD

Ага

В grafana при установке threshold lt не должно ли заполнять цветом от нуля до заданного значения?

Если fill включен, то должно

Если fill включен, то должно

fill включен, ну вот T3 удаляю и меняю в T2 на lt, и закрашивает от нуля. Все с параметр fill включенным.

Похоже на баг. Какая версия?

Похоже на баг. Какая версия?

5.1.3

Я проверю.

Вот так работает, когда в порядке убывания выставлять.

Добрый день, подскажите, нормальная ли это практика хранить в elasticsearch метрики? Какие будут плюсы и минусы данного решения?

а зачем у вас такая задумка вообще возникла?

Плюсы думать не надо. Минусы думать не надо и дорого

Это путь Заббикса.

а зачем у вас такая задумка вообще возникла?

коллега хранит, я говорю это очень странно, но доводов против не вижу

ниразу не видел чтоб на митапах обсуждали реализацию хранения метрик в еластике

Это путь Заббикса.

?

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

Они тоже эластик прикрутили вместо SQL.