Но с миллионами файлов и иопсами поможет, да

Ну здась тебе скорее посоветуют воспользоваться clickhouse, с carbon-clickhouse + graphite-clickhouse + carbonapi эта связка на ура решает проблему жрущих много иопсов whisper \ ceres

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

Я сейчас посматриваю в сторону Прометея + инфлюкс. С Инфлюксом у нас проблемы только при чтении и даже если он потеряет данные, самые актуальные (читай нужные) останутся в проме

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

Ну текущие сборки вполне стабильны, плюс всегда можно присоедениться к разработке :)

Я сейчас посматриваю в сторону Прометея + инфлюкс. С Инфлюксом у нас проблемы только при чтении и даже если он потеряет данные, самые актуальные (читай нужные) останутся в проме

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

Но серебрянной пули нету :(

А большие это сколько?

Инфлюкс я уже использую и уже не люблю) Изначально на него пытались мигрировать, но даже при наших объемах он выжирал по 64GB памяти. Особенно у него проблемы со сжатием данных, в моменты когда он начинает пережимать старые метрики все умирает. Просто в случае с прометеусом он планируется как хранилище для старых метрик. И его производительность не так важна.

Вот сейчас 93 гига памяти. Хотя туда даже не все пишется, я уже не говорю про чтение

А большие это сколько?

От кардиналити зависит сколько он сожрет ОЗУ на индексы

Инфлюкс я уже использую и уже не люблю) Изначально на него пытались мигрировать, но даже при наших объемах он выжирал по 64GB памяти. Особенно у него проблемы со сжатием данных, в моменты когда он начинает пережимать старые метрики все умирает. Просто в случае с прометеусом он планируется как хранилище для старых метрик. И его производительность не так важна.

О, а можете свои объемы метрик раскрыть?

О, а можете свои объемы метрик раскрыть?

Ну, точно я не скажу, т.к у нас несколько проектов пишут

Дело не в просто количестве, а именно в кардиналити - https://www.influxdata.com/blog/path-1-billion-time-series-influxdb-high-cardinality-indexing-ready-testing/

По статье - не знаю насколько помог новый индекс

Он вроде как "боевой" пока по умолчанию всё ещё не идёт, да и миграции со старого движка на новый автоматом нет. У меня 64 гига перестало хватать при ~25М серий,после чего пришлось до 128 гигов временно увеличить просто чтобы данные вытащить для миграции в кликхаус.

http://www.timescale.com/ А эту штуку кто-то юзал? Выглядит заманчиво.

http://www.timescale.com/ А эту штуку кто-то юзал? Выглядит заманчиво.

форк постгреса?

Нет

Почитай

http://www.timescale.com/ А эту штуку кто-то юзал? Выглядит заманчиво.

да.

ща

форк постгреса?

модуль к нему

О, Алексей, а расскажи что-нить

ща.

@hitmaker позову. он тыкал

Там какое-то ограничение мне не понравилось на бумаге. Но точно не помню

А, первое что - в RDS незя пока запустить

rds?

в амазоне, да.

http://www.timescale.com/ А эту штуку кто-то юзал? Выглядит заманчиво.

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

Как кандидат на использование Лонг терм сторадж для метрик думаю

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

Просто голую постгрю для TS? интересно

На своем железе

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

С моим меншеном отпишитесь плиз, чтоб не потерять сообщение. Спасибо!

Как кандидат на использование Лонг терм сторадж для метрик думаю

без кластера? Ну если есть большая и жирная железка...

без кластера? Ну если есть большая и жирная железка...

А почему без? Можно и "с" :)

Поставлю три железки и сделаю кластер

У TimescaleDB нету кластера

А она ж с пгскл работает, его кластеризацию нельзя использовать?

нет

было б все так просто

https://docs.timescale.com/v0.8/faq

"Is there a clustered version and how can I try it? A clustered version is actively being developed. If you'd like to learn more, please contact us at hello@timescale.com. In the meantime, please read the two questions below about the extent of TimescaleDB's single-node scalability. [Top]"

У TimescaleDB нету кластера

а, вот да.

"We've first focused on scaling TimescaleDB up on a single node, which you can read about in the next question. On our internal benchmarks, we have consistently scaled TimescaleDB 10+ billion rows, while sustaining insert rates of 100-200k rows / second (or 1-2 million metric inserts / second). That said, the principal design decisions implemented for scaling up are the same for allowing TimescaleDB to scale out horizontally in a linear fashion across many servers. When clustering is released, all servers can receive and process queries, and store data; TimescaleDB will not use any specialized primary server or transaction coordination. It is designed to combine the scalability of popular NoSQL databases, with the native query complexity supported by RDBMS systems. [Top]"

Ага ясно. Ну я пока хз нужен ли мне кластер, может и одной жирной железки хватит

Ага ясно. Ну я пока хз нужен ли мне кластер, может и одной жирной железки хватит

которая может упасть.

ребята node_exporter есть альтеранитва для windows ??

Ну и пусть падает, я с нее читать не буду

Данные то не потеряются, а даун не страшен

ребята node_exporter есть альтеранитва для windows ??

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

да задавал но только щас проверил тк ответ был что node_exporter подходит для windows

Данные то не потеряются, а даун не страшен

с таким же успехом можно хранить в блобе и json файлах

Нет.

Почему нет?

wmi_exporter ещё был

@sabien_bot тогда ты вот это пропустил

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

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

Ну, я и говорю, почему не хранить это все в папках и json?

еще gzipнуть

А визуализировать это как предлагаешь?

эффективность разная выйдет

еще gzipнуть

ну а как же тренды и смузи?

Так звучит как архивный cold storage. Нафига оттуда визуализировать?

а нахрена хранить в жсоне что-то архивное?

а нахрена хранить в жсоне что-то архивное?

какбэ монга получится ?

ERROR: S client not available

ну, например, если хочется сложить на s3

или прогнать через hadoop

ну, например, если хочется сложить на s3

ну а чо б не виспер?

или прогнать через hadoop

ну а чо б не виспер?

а, ну формат серализации - ок, хоть паркет

я скорее о "не СУБД"

json просто как формат сериализации для любых данных превышающих околонихуя - DNIWE же

json просто как формат сериализации для любых данных превышающих околонихуя - DNIWE же

я точного сравнения размера на точку виспера и gzipped json не знаю, но по идее он нормально компрессится

"виспер" в плане компрессии тоже DNIWE

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

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

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

#reminder #напоминалка #напоминание #минидоклад

(для себя)

Коллеги, как освобожусь - дам знать и mentions выставлю

ребята подскажите почему это не работает sum by (mode) (rate(wmi_cpu_time_total{}[5m])) / count (wmi_cpu_tme_total) by (mode)

tme ?

tme ?

что это?

прочитай свой запрос ещё раз

если верно сюда принёс, то у тебя опечатка

sum by (mode) (rate(wmi_cpu_time_total{}[5m])) / 8

вот такое работает

а count (wmi_cpu_tme_total) by (mode)?

работает

ну да я опечатку сделал

но все равно работает только когда я делаю число а count не работает

щас всё ок?

нет

я гдето чтото не так делаю и не могу понять как

сравни что тебе первый запрос возвращает и что второй

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

ну первый возвращает пять метрик и второй

Ребята а появился уже какой то спосбо из prometheus в телеграм слать сообщения?