prometheus/prometheus was tagged: 2.3.1 / 2018-06-19 Link: https://github.com/prometheus/prometheus/releases/tag/v2.3.1 Release notes: * [BUGFIX] Avoid infinite loop on duplicate NaN values. [#4275](https://github.com/prometheus/prometheus/pull/4275) * [BUGFIX] Fix nil pointer deference when using various API endpoints [#4282](https://github.com/prometheus/prometheus/pull/4282) ... More

о, можно в прод

о, можно в прод

не сглазь. а то так до 2,4,3 ждать придется

я ваще на 2.1.0 до сих пор

не сглазь. а то так до 2,4,3 ждать придется

что, всё настолько ужасно, я тоже что то цифру увидел и удивился, вроде только 2.0 было

2.0 вышел прошлой осенью ещё

ваще переход с 1.х на 2.0 был самый болезненный

потому что сломали формат сторейжа

prometheus/prometheus was tagged: 2.3.1 / 2018-06-19 Link: https://github.com/prometheus/prometheus/releases/tag/v2.3.1 Release notes: * [BUGFIX] Avoid infinite loop on duplicate NaN values. [#4275](https://github.com/prometheus/prometheus/pull/4275) * [BUGFIX] Fix nil pointer deference when using various API endpoints [#4282](https://github.com/prometheus/prometheus/pull/4282) ... More

Вот же ж штампуют))

Ребят, может подскажите, кт ото встречался с такими ошибками?

carbon-c-relay[17302]: 2018-06-19 04:12:42] accept failed[2018-06-19 04:12:42] accept failed[2018-06-19 04:12:42] accept failed[2018-06-19 04:12:42] ac

си релей - форкнутый на libevent

Всем привет , подскажите пожалуйста кто использовал python клиент прометеуса - как там можно метрики удалить из выдачи вебсервером ? тоесть например я определяю метрику и набор лейблов для неё : tarantool_box_info_replication_lag = Gauge('tarantool_box_info_replication_lag', 'replication lag information', ['cluster_uuid', 'server_uuid', 'server_id', 'replication_status']) потом в цикле это всё заполняю , и допустим у меня появляются метрики вида : tarantool_box_info_replication_lag{cluster_uuid="9e863bc9-d8d5-4eda-ac0d-2808a7c90a6d",replication_status="follow",server_id="1",server_uuid="8fa58cff-1f2d-41dd-a605-a555622609cb"} 0.0 tarantool_box_info_replication_lag{cluster_uuid="9e863bc9-d8d5-4eda-ac0d-2808a7c90a6d",replication_status="disconnected",server_id="1",server_uuid="8fa58cff-1f2d-41dd-a605-a555622609cb"} 0.0 tarantool_box_info_replication_lag{cluster_uuid="9e863bc9-d8d5-4eda-ac0d-2808a7c90a6d",replication_status="stopped",server_id="1",server_uuid="8fa58cff-1f2d-41dd-a605-a555622609cb"} 0.0 Проблема в том , что на этом примере 3 метрики (а хочется видеть 1 , с текущим состоянием репликации) , я так понял что из за того что для клиента прометеуса одна и та же метрика с разным набором лейблов - это по сути разные метрики. И вот встал вопрос - как правильно удалить их (если это вобще возможно)

Всем привет , подскажите пожалуйста кто использовал python клиент прометеуса - как там можно метрики удалить из выдачи вебсервером ? тоесть например я определяю метрику и набор лейблов для неё : tarantool_box_info_replication_lag = Gauge('tarantool_box_info_replication_lag', 'replication lag information', ['cluster_uuid', 'server_uuid', 'server_id', 'replication_status']) потом в цикле это всё заполняю , и допустим у меня появляются метрики вида : tarantool_box_info_replication_lag{cluster_uuid="9e863bc9-d8d5-4eda-ac0d-2808a7c90a6d",replication_status="follow",server_id="1",server_uuid="8fa58cff-1f2d-41dd-a605-a555622609cb"} 0.0 tarantool_box_info_replication_lag{cluster_uuid="9e863bc9-d8d5-4eda-ac0d-2808a7c90a6d",replication_status="disconnected",server_id="1",server_uuid="8fa58cff-1f2d-41dd-a605-a555622609cb"} 0.0 tarantool_box_info_replication_lag{cluster_uuid="9e863bc9-d8d5-4eda-ac0d-2808a7c90a6d",replication_status="stopped",server_id="1",server_uuid="8fa58cff-1f2d-41dd-a605-a555622609cb"} 0.0 Проблема в том , что на этом примере 3 метрики (а хочется видеть 1 , с текущим состоянием репликации) , я так понял что из за того что для клиента прометеуса одна и та же метрика с разным набором лейблов - это по сути разные метрики. И вот встал вопрос - как правильно удалить их (если это вобще возможно)

а вы не можете отфильтровать нужную вам метрику прямо в запросе?

а вы не можете отфильтровать нужную вам метрику прямо в запросе?

тоже сначала так хотел сделать , но это не совсем правильно как мне кажется сейчас немного поподробнее опишу : допустим в какой то момент времени реплика находится в статусе follow - соотв. для неё создастся такая метрика с лейблом : tarantool_box_info_replication_lag{replication_status="follow"} 0.0 затем , предположим что начались какие то сетевые проблемы , и реплика перешла в статус disconnected , тогда при обращении к бд экспортер создаст следующую метрику с набором лейблов : tarantool_box_info_replication_lag{replication_status="disconnected"} 0.0 при этом предыдущая метрика она останется (что вобщем то не совсем правильно , т.к состояние бд уже не follow а disconnected) далее происходит попытка переподключится к мастеру и допустим попытка была неудачной , реплика переходит в состояние stopped , экспортер создаст метрику с лейблом : tarantool_box_info_replication_lag{replication_status="stopped"} 0.0 При этом все предыдущие метрики сохранятся(что не правильно) , и при обращении к экспортеру он будет отдавать чтото вида : tarantool_box_info_replication_lag{replication_status="follow"} 0.0 tarantool_box_info_replication_lag{replication_status="disconnected"} 0.0 tarantool_box_info_replication_lag{replication_status="stopped"} 0.0

а ну и соотв, в прометеусе условие алерта запрос вида : tarantool_box_info_replication_lag{status!~"follow"} даже после того как реплика реально восстановится - продолжатся отдаваться disconnected и stopped из за чего алерт не закроется

Удалить метрику только как-то так: https://gitlab.com/SirEdvin/docker-prometheus-exporter/blob/master/app.py#L80 нормального пути я не видел

То есть чисто пересобрать список метрик

тоже сначала так хотел сделать , но это не совсем правильно как мне кажется сейчас немного поподробнее опишу : допустим в какой то момент времени реплика находится в статусе follow - соотв. для неё создастся такая метрика с лейблом : tarantool_box_info_replication_lag{replication_status="follow"} 0.0 затем , предположим что начались какие то сетевые проблемы , и реплика перешла в статус disconnected , тогда при обращении к бд экспортер создаст следующую метрику с набором лейблов : tarantool_box_info_replication_lag{replication_status="disconnected"} 0.0 при этом предыдущая метрика она останется (что вобщем то не совсем правильно , т.к состояние бд уже не follow а disconnected) далее происходит попытка переподключится к мастеру и допустим попытка была неудачной , реплика переходит в состояние stopped , экспортер создаст метрику с лейблом : tarantool_box_info_replication_lag{replication_status="stopped"} 0.0 При этом все предыдущие метрики сохранятся(что не правильно) , и при обращении к экспортеру он будет отдавать чтото вида : tarantool_box_info_replication_lag{replication_status="follow"} 0.0 tarantool_box_info_replication_lag{replication_status="disconnected"} 0.0 tarantool_box_info_replication_lag{replication_status="stopped"} 0.0

Нет, это совершенно нормальный подход

Ребят, может подскажите, кт ото встречался с такими ошибками?

Мы с таким конкретно не встречались, но мы с форка слезли, когда он начал ломать имена метрик на выходе из релея

Нет, это совершенно нормальный подход

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

Удалить метрику только как-то так: https://gitlab.com/SirEdvin/docker-prometheus-exporter/blob/master/app.py#L80 нормального пути я не видел

спасибо

спасибо

Но как вам написали, лучше ничего не удалять и просто писать ноль, а в условие алерта добавить >0

Мы с таким конкретно не встречались, но мы с форка слезли, когда он начал ломать имена метрик на выходе из релея

Какой форк пробовали? Этот https://github.com/chbuescher/carbon-c-relay? Что в место него, штатный? Я пробовал исходный проект - он при больших берстах метрик совершенно спокойно может до 50% дропать.

Какой форк пробовали? Этот https://github.com/chbuescher/carbon-c-relay? Что в место него, штатный? Я пробовал исходный проект - он при больших берстах метрик совершенно спокойно может до 50% дропать.

именно этот и пробовали. Оригинал у нас себя хорошо ведет, но мы на 2.6 сидим и у нас burst нету

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

привет. подскажите по части prometheus: group в alert rule идеологически для чего предназначены? для того чтобы роутить удобнее было?

а новый релей Владимира не пробовали? https://github.com/go-graphite/gorelka

и тут в чатике полгода назад уже писали конкретный билд carbon-c-relay который вроде как стабилен

а новый релей Владимира не пробовали? https://github.com/go-graphite/gorelka

Да хочется попробовать но не понятно в каком он щас статусе.

Но как вам написали, лучше ничего не удалять и просто писать ноль, а в условие алерта добавить >0

да ну тут получается особенность экспортера , в итоге сделал следующим образом (если интересно) : tarantool_box_info_replication_lag._metrics = {} это будет вызываться перед записыванием метрики , да топорненьо но работает )

Владимир - в статусе швейцарца :)

да ну тут получается особенность экспортера , в итоге сделал следующим образом (если интересно) : tarantool_box_info_replication_lag._metrics = {} это будет вызываться перед записыванием метрики , да топорненьо но работает )

а я правильно понимаю что ты хочешь создавать-удалять метрики на ходу?

да

да ну тут получается особенность экспортера , в итоге сделал следующим образом (если интересно) : tarantool_box_info_replication_lag._metrics = {} это будет вызываться перед записыванием метрики , да топорненьо но работает )

Ну, это более-менее правильная особенность экспортера, все так делают :)

это страшный подход - динамические метрики :)

Ну, для докер контейнеров я ничего другого не придумал.

Опять же таки, если сущность пропадает - метрики для нее надо удалять

ну для контейнеров это норма, потому что сама сущность такая

Ну, это более-менее правильная особенность экспортера, все так делают :)

ну ведь не может быть так - что в один момент времени статус репликации одновременно follow , disconnected , и connecting :) я возможно не совсем правильно сделал организацию лейблов у этой метрики...

я про то что выше по треду (если правильно понял) там то сущности фиксированные но состояния меняются

я про то что выше по треду (если правильно понял) там то сущности фиксированные но состояния меняются

да, вы всё верно написали

ну ведь не может быть так - что в один момент времени статус репликации одновременно follow , disconnected , и connecting :) я возможно не совсем правильно сделал организацию лейблов у этой метрики...

Просто если вы делаете динамические метрики - вы немного ломаете структуру того, как работает prometheus. Возможно, вам стоит сделать другие метрики?

с промом тут лучше другие подскажут, в графите это либо 3 метрики с 0-1 либо одна с 3 значениями (зависит от переходов)

Что-то вроде: Gauge - запущена ли репликация Counter - количество ошибок

тогда мне нужно будет держать маппинг состояние реплики - значение в коде экспортера

хотелось бы этого избежать

Что-то вроде: Gauge - запущена ли репликация Counter - количество ошибок

интересный вариант , спасибо подумаю над ним

а новый релей Владимира не пробовали? https://github.com/go-graphite/gorelka

он не готов в prod

и тут в чатике полгода назад уже писали конкретный билд carbon-c-relay который вроде как стабилен

9cdf4d4 + patch для того чтобы починить статистику

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

можно наверное кстати запуск и окончание репликации 2 метриками с типом каунтер писать - тогда аггрегация по данной метрике будет иметь смысл - количество репликаций за неделю например :)

> Hello, my name is Anais Dotis-Georgiou, and I’m a new Influxer. они там в инфлюксе как гугл. но инфлюксеры.

можно наверное кстати запуск и окончание репликации 2 метриками с типом каунтер писать - тогда аггрегация по данной метрике будет иметь смысл - количество репликаций за неделю например :)

да) сейчас в итоге сделал отдельный (от replication lag) метрику , с названием replication_status тип каунтер , и туда просто при каждом обращение к бд инкремент делаю перестало replication_status{status="follow"} изменятся , значит всё плохо ну и irate'ом её проверять

influx reliability engineer

интересно только что будет когда достигнет максимального значения

Кто-нибудь собирал метрики с каких-нибудь скриптов в prometheus? Допустим у меня есть скрипт, который обрабатывает файлы раз в 10 минут например и я хочу иметь статистику по файлам и их содержимому. И вроде как планирую использовать для этого prometheus push gateway. Prometheus собирает данные раз в минуту скажем. Получается мне надо либо обнулять все данные раз в минуту скриптом в надежде на то, что prometheus их собрал (именно обнулять, а не удалять насколько я понимаю и именно все счетчики со всеми возможными значениями меток). То есть например если я в метке метрики использую информацию из файла, но заранее не знаю всех возможных значений, то я в пролете?

nodeexporter file collector

тебе нужен textfile collector

pushgateway - ниочинь

Ну то есть решение на самом деле - персистить метрики на клиенте и только так можно добиться нормальной совместимости с моделью сбора метрик prometheus?

¯\_(ツ)_/¯

интересно только что будет когда достигнет максимального значения

Переполнить float64 счетчиком репликаций? Интересно что наступит раньше: вымирание человечества или переполнение этого счетчика :)

Переполнить float64 счетчиком репликаций? Интересно что наступит раньше: вымирание человечества или переполнение этого счетчика :)

?

1.7976931348623157e+308 да это наверное очень много )

ERROR: S client not available

я всётаки надеюсь что мы не вымрем

Проблема в том, что там начнутся ошибки округления и пропуски сначала единиц, потом десятков и так далее

Это уже можно назвать переполнением и это не так то далеко

Переполнить float64 счетчиком репликаций? Интересно что наступит раньше: вымирание человечества или переполнение этого счетчика :)

главное что бы одно от другого не зависело.

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

Просто число не влезет в мантиссу и начнутся проблемы, как я понимаю.

побежал отливать в мраморе последние 10 сообщений

ну учитывая что репликация идет не каждую секунду...а то и не каждую неделю

ну учитывая что репликация идет не каждую секунду...а то и не каждую неделю

это у вас просто bad design

У меня получилось где-то максимум 9007199254740992 репликаций.

минутки математики в чатике :)

Всего-то надо делать по одной репликации 285616414 лет и будет переполнение

в секунду же?

Да

У меня получилось где-то максимум 9007199254740992 репликаций.

285 милионов лет всеголишь. если раз в секунду репликация

да тоже пересчитал

смерть солнца намечена на сильно позже.

Ну ... я думаю, к тому времени prometheus перейдет на float1024

вооот а если репликацию делать раз в 1 такт процессора то можно легко словить этот веселый эффект

может все таки уйдем на квантовое хранение?

srsly?

все станут философами

хотя да, такт процессора это медленно

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

Ну, можно же запускать несколько репликаций за раз

это чит

у каждой должен быть свой счетчик :)

Какой форк пробовали? Этот https://github.com/chbuescher/carbon-c-relay? Что в место него, штатный? Я пробовал исходный проект - он при больших берстах метрик совершенно спокойно может до 50% дропать.

вот как эта бага выглядит https://github.com/grobian/carbon-c-relay/issues/216

вот как эта бага выглядит https://github.com/grobian/carbon-c-relay/issues/216

Ну да, я туда уже писал :)

Ну да, я туда уже писал :)

ок, гланое чтобы https://github.com/grobian/carbon-c-relay/issues/216#issuecomment-383576466 не стало сюрпризом

ну как сказать, с цпу пока все хорошо насколько я вижу

У меня cbuechter fork радостно сожрал 120ГБ памяти за 2 недели и помер. Да еще и имена метрик бил до кучи. Откатился на 2.6