не то слово

Using interval and range variables Support for $__range, $__range_s and $__range_ms only available from Grafana v5.3

церкваны, а подскажите имена метри по сторейджам StatefulSet в кубернетисах, у меня есть метрики из cadvisor'а, хочу найти по имени стейтфулсета

kubelet_volume_stats_capacity_bytes во нашёл

там есть имя персистент клейма, осталось найти нужные мне клеймы по имени стейтфулсета

всем привет. Graphouse кто-то использует?

всем привет. Graphouse кто-то использует?

Вряд ли тут кто-то его трогал, есть же лучшая альтернатива.

да, я сейчас и пользуюсь graphi-clickhouse+carbon-clickhouse+carbonapi

всем привет. Graphouse кто-то использует?

так это же только замена carbon-clickouse (только прием метрик, с последующей записью батчами в КХ)

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

grafana/grafana was tagged: v5.3.0-beta1 Link: https://github.com/grafana/grafana/releases/tag/v5.3.0-beta1 Release notes: release v5.3.0-beta1

Вряд ли тут кто-то его трогал, есть же лучшая альтернатива.

Какая?

Какая?

ломиковский graphite-clickhouse и carbon-clickhouse

они шустрее, взрослее, в более поддерживаемом состоянии

Странно, когда я примерно полгода назад искал чем писать, пропустил их.

Да, подотстал я. Ещё можно выкинуть graphite-api и заменить на carbonapi, получается.

в принципе можно, да

а чо там в прометее между 2.1 и 2.3 сторейж опять оптимизировали?

до апгрейда у меня занятого места было 41gb, а сейчас 33gb

хм, нет, кол-во метрик уменьшилось сильно

Да, подотстал я. Ещё можно выкинуть graphite-api и заменить на carbonapi, получается.

Это отличная идея! С тем то учетом что graphite-api не обновлялся с октября прошлого года, не поддерживает теги(лейблы) и работал (по нашим замерам где то полтора года назад) в 4 раза медленнее чем carbonapi.

grafana/grafana was tagged: v5.3.0-beta1 Link: https://github.com/grafana/grafana/releases/tag/v5.3.0-beta1 Release notes: [Download Page](https://grafana.com/grafana/download/5.3.0-beta1) [Installation Guide](http://docs.grafana.org/installation/) [Release Notes](https://community.grafana.com/t/release-notes-v5-3-x/10244) # 5.3.0-beta1 (2018-09-06) ### New Major F... More

prometheus/prometheus was tagged: 2.4.0-rc.0 / 2018-09-06 Link: https://github.com/prometheus/prometheus/releases/tag/v2.4.0-rc.0 Release notes: This release includes multiple bugfixes and features. Further, the WAL implementation has been re-written so the storage is not backward compatible. Prometheus 2.3 storage will work on 2.4 but not vice-versa. * [CHANGE] Reduce remote write default... More

Шо, опять ломают?

[FEATURE] Add API providing recording and alerting rules #4318 #4501

а чё, таки делали?

grafana/grafana was tagged: v5.3.0-beta1 Link: https://github.com/grafana/grafana/releases/tag/v5.3.0-beta1 Release notes: [Download Page](https://grafana.com/grafana/download/5.3.0-beta1) [Installation Guide](http://docs.grafana.org/installation/) [Release Notes](https://community.grafana.com/t/release-notes-v5-3-x/10244) # 5.3.0-beta1 (2018-09-06) ### New Major F... More

У брендана много отличных статей

+

Набирем бета-тестеров для новой TSDB - https://gist.github.com/valyala/9075a4d375509451108962ac31840fd8 Завтра постараюсь ответить на возникшие вопросы

Набирем бета-тестеров для новой TSDB - https://gist.github.com/valyala/9075a4d375509451108962ac31840fd8 Завтра постараюсь ответить на возникшие вопросы

Особенно доставило: Что будет после завершения бета-тестирования: Вы сворачиваете бета-версию сервиса на своих серверах и переходите на Cloud-сервис VictoriaMetrics, если желаете продолжить сотрудничество.

А потом вам регулярно начинает приходить чек

У нас уже есть prometheus и akumuli, честно говоря)

А еще интеграции с clickhouse. И все бесплатные решения, которые вроде как успешно работают. Мне кажется, платное решение будет не очень успешно в этом плане .... Хотя мне сложно понять, зачем за них в целом платят, разве что оно коробочное

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

А еще интеграции с clickhouse. И все бесплатные решения, которые вроде как успешно работают. Мне кажется, платное решение будет не очень успешно в этом плане .... Хотя мне сложно понять, зачем за них в целом платят, разве что оно коробочное

SaaS обходится дешевле в контексте эксплуатации и обслуживания

Ну тут то не особо саас. Свой пром держать походу нужно будет

Да, но нет головняка с ретеншеном

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

ну тоесть ценность того же okmeter не в том, что он хранит метрики, а в том как он их собирает, и как помогает анализировать

ну а тут все равно придется метрики самостоятельно собирать, какой в этом смысл - непонятно

Собрать метрики - вообще очень малая часть проблемы

Нарисовать внятные графики/дашборды и алерты - намного сложнее

Собрать метрики - вообще очень малая часть проблемы

а как же надёжность(чтобы не рухнула при большом объеме метрик/запросов_на_чтение), доступность(отказоустойчивость/балансировка), историчность(для тех же алертов)?

Да, но нет головняка с ретеншеном

Учитывая, насколько этот ретеншн на самом деле нужен - я сомневаюсь, что кто-то будет платить за это внятые деньги. Как уже описали выше - собрать и хранить, это не проблема.

а как же надёжность(чтобы не рухнула при большом объеме метрик/запросов_на_чтение), доступность(отказоустойчивость/балансировка), историчность(для тех же алертов)?

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

Ну и есть некоторые отрытые наработки на эту тему

Гайз, а подскажите, alertmanager всегда алерты отправляет группами? Т.е. вот у меня есть 2 алерта в группе в статусе FIRING, по ним уведомление пришло. Случается еще один алерт, который попадает в эту группу и в новом уведомлении приходит инфа о всех трех. Я правильно понял концепнцию?)

Вроде не должно так

Хм, может где-то туплю тогда, пойду ка еще потестирую.

Можно на собесах пояснять божественно.

При этом одной фразой, самой последней в статье.

Всем привет. подскажите, может быть есть какой интересный и в тоже время не сложный в эксплуатации экспортер для прометей собирающий информацию по запуску cron заданий? Например, интервал, коды запуска , ну и другую инфу?

если у тебя крон == systemd.timer, то наверное готовый node_exporter с включенным модулем systemd подойдёт

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

Всем привет! Подскажите, плз, не могу сходу разобраться: есть пром с графаной, есть самописный экспортер, который ходит в REST, что-то оттуда забирает и выдает прому. scrape interval стоит в 30 минут, т.к данные меняются нечасто, а флудить сервис не хочется. проблема в том, что в графане это выводится с разрывом в те самые полчаса. можно ли сделать так, чтобы недостающие данные как-то аппроксимировались (или просто пром/графана брали последнее доступное значение и на их основании рисовали график)? Буду признателен за совет.

Всем привет! Подскажите, плз, не могу сходу разобраться: есть пром с графаной, есть самописный экспортер, который ходит в REST, что-то оттуда забирает и выдает прому. scrape interval стоит в 30 минут, т.к данные меняются нечасто, а флудить сервис не хочется. проблема в том, что в графане это выводится с разрывом в те самые полчаса. можно ли сделать так, чтобы недостающие данные как-то аппроксимировались (или просто пром/графана брали последнее доступное значение и на их основании рисовали график)? Буду признателен за совет.

Display -> Null value -> connected

ERROR: S client not available

О, другое дело. Спасибо. Думал, надо это как-то на стороне квери отрабатывать.

Всем привет! Подскажите, плз, не могу сходу разобраться: есть пром с графаной, есть самописный экспортер, который ходит в REST, что-то оттуда забирает и выдает прому. scrape interval стоит в 30 минут, т.к данные меняются нечасто, а флудить сервис не хочется. проблема в том, что в графане это выводится с разрывом в те самые полчаса. можно ли сделать так, чтобы недостающие данные как-то аппроксимировались (или просто пром/графана брали последнее доступное значение и на их основании рисовали график)? Буду признателен за совет.

поставить интервал в 30m

который min step

поставить интервал в 30m

А что это даст и в чем разница с вариантом через null value?

Шаг запроса изменит

графана будет запрашивать точки с интервалом в 30 мин и график будет без «плато»

grafana/grafana was tagged: v5.2.4 Link: https://github.com/grafana/grafana/releases/tag/v5.2.4 Release notes: release v5.2.4

А потом вам регулярно начинает приходить чек

Чек будет меньше, чем затраты на хранение данных в локальном сторедже прометеуса, и меньше, чем у конкурентов. Для клиентов, записывающих меньше нескольких миллионов metric values в месяц, будет вообще бесплатно. Также планируется выпустить open source решение для тех, кто хочет держать данные под собственным контролем и готов самостоятельно заниматься обеспечением доступности сервиса и данных.

А еще интеграции с clickhouse. И все бесплатные решения, которые вроде как успешно работают. Мне кажется, платное решение будет не очень успешно в этом плане .... Хотя мне сложно понять, зачем за них в целом платят, разве что оно коробочное

Мы будем взимать плату за обеспечение доступности сервиса и данных. Те, кто предпочитает самостоятельно управлять сервисами и данными, платят за это своим девопсам / хостерам. И, скорее всего, чек получится намного больше, чем если бы они использовали платное Cloud-решение.

Когда вы так оценочно говорите "намного большое" - звучит так, как будто для того, что бы обеспечивать long-term storage нанимается целый отдел. Но обычно это 5-10% от одного человека.

хорошо если 10 минут в день уходит времени на мониторинг

насчет интеграции с ClickHouse - VictoriaMetrics появилась как раз после неудачной попытки использовать ClickHouse в качестве TSDB. У этого решения выявилось два недостатка, которых нет в VictoriaMetrics: 1) не получилось сделать нормальный индекс по тэгам (aka metric labels). Можно использовать костыль в виде стороннего сервиса для управления таким индексом, но в рамках ClickHouse это пока не решается 2) в ClickHouse пока отсутствуют методы упаковки, оптмизированные под time series данные. Поэтому данные занимают больше места на диске, чем могли бы.

По akumuli ничего сказать не могу, т.к. не работал с ним. Читал только статьи на хабре. Вроде интересное решение. Может, будем конкурировать с ним

Ну тут то не особо саас. Свой пром держать походу нужно будет

VictoriaMetrics - это SaaS для хранения и обработки time series данных. Прометеус может использовать этот SaaS в качестве remote storage, чтобы не хранить много данных локально. В будущем планируется добавление интеграций с другими системами мониторинга, поэтому на прометеусе свет клином не сошелся. Он был выбран в качестве стартового решения, т.к. он достаточно популярен и удобен в использовании.

"собирать и хранить метрики" - даже не 10% работы

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

полностью согласен :) Может, к этому придем в будущем. Сначала хотим создать лучший в мире SaaS для хранения и обработки time series данных. Потом поверх него можно делать сервисы наподобие okmeter или даже интегрироваться с ними, чтобы они хранили данные у нас.

ну а тут все равно придется метрики самостоятельно собирать, какой в этом смысл - непонятно

если вы уже используете прометеус и настроили все необходимые дашборды с алертами, но столкнулись хотя бы с одной из проблем, перечисленными в https://gist.github.com/valyala/9075a4d375509451108962ac31840fd8 , то VictoriaMetrics поможет их решить путем добавления одной строчки в конфиг прометеуса - remote_write.url

конкурент для project thanos?

а как же надёжность(чтобы не рухнула при большом объеме метрик/запросов_на_чтение), доступность(отказоустойчивость/балансировка), историчность(для тех же алертов)?

+1

а как же надёжность(чтобы не рухнула при большом объеме метрик/запросов_на_чтение), доступность(отказоустойчивость/балансировка), историчность(для тех же алертов)?

это всё ещё очень малая часть работы по созданию приличного мониторинга на основе prometheus

grafana/grafana was tagged: v5.2.4 Link: https://github.com/grafana/grafana/releases/tag/v5.2.4 Release notes: [Download Page](https://grafana.com/grafana/download/5.2.4) [Installation Guide](http://docs.grafana.org/installation/) [Release Notes](https://community.grafana.com/t/release-notes-v5-2-x/7894) * **GrafanaCli**: Fixed issue with grafana-cli i... More

Учитывая, насколько этот ретеншн на самом деле нужен - я сомневаюсь, что кто-то будет платить за это внятые деньги. Как уже описали выше - собрать и хранить, это не проблема.

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

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

Затраты на свою команду могут оказаться намного выше затрат на Cloud-решение. Как раз на таких клиентов мы и нацеливаемся в первую очередь.

насчет интеграции с ClickHouse - VictoriaMetrics появилась как раз после неудачной попытки использовать ClickHouse в качестве TSDB. У этого решения выявилось два недостатка, которых нет в VictoriaMetrics: 1) не получилось сделать нормальный индекс по тэгам (aka metric labels). Можно использовать костыль в виде стороннего сервиса для управления таким индексом, но в рамках ClickHouse это пока не решается 2) в ClickHouse пока отсутствуют методы упаковки, оптмизированные под time series данные. Поэтому данные занимают больше места на диске, чем могли бы.

Неудачной попытки кого? Вас? Мы используем graphite+clickhouse, у нас есть теги, и мы умеем дружить с данными из промитеуса. Что касается места, то это вопрос легко решаемый шардированием, который в КХ отлично работает, по крайней мере у нас.

я честно говоря пользовался бы подобным сервисом если бы он был в комплекте например с amazon ec2 и стоил бы столько же сколько например RDS, как отдельный сервис лично мне не очень понятно, кто будет это покупать

Когда вы так оценочно говорите "намного большое" - звучит так, как будто для того, что бы обеспечивать long-term storage нанимается целый отдел. Но обычно это 5-10% от одного человека.

По первоначальным расчетам мы сможем установить цену ниже, чем стоимость хранения аналогичного объема metric values в локальном сторедже прометеуса. Поэтому любые дополнительные затраты в виде 5-10% времени одного девопса только увеличивают разрыв в стоимости

5-10% это на весь мониторинг, наверное, а не на сторейдж

"время одного дивапса" - это прекрасно