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

Думаю тогда попробовать таймауты на remote_write поставить, хотя там дефолт 30 секунд

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

А, ну и ещё кстати, у них вот такая форма, там по низам идут настоящие значения

вот у меня такая же картинка была, когда не успевали scrape-ы отрабатывать...и irate строил такую дичь

Окей, тогда покопаю в ту сторону.
У тебя не успевал скрапинг отработать или инстансы прома, которые делают remote_write?
т.е. проблемы была на локальных, которые не успевали данные собрать или по пути между локальными и remote, из-за чего remote строил такую дичь?

у меня была проблема в скрэйпах. Но сути это не меняет. Если данные криво долетают. То irate будет строить дерьмо.
И если можно посмотреть напрямую в сырые данные. то с этого надо начать =)

Окей, спасибо за уточнение

Аналогичная проблема с дефолтным дащбордом

Кто-нибудь пробовал уже испльзовать questdb вместо influxdb или victoriametrics? По предварительным тестам questdb требует в 20 раз больше места на диске, чем victoriametrics. Это значит, что запросы по историческим данным будут торомзить, т.к. ей нужно будет вычитать в 20 раз больше данных с диска. Также questdb странно себя ведет при количестве активных рядов, превышающем 400К - скорость вставки падает почти до нуля. При этом проц остается прилично загруженным, а в лог пишется большое количество строк вида i.q.c.TableWriter sorting o3.

Было бы интересно, если бы кто-нибудь провел независимое сравнение questdb с influxdb и victoriametrics в продакшн :)

По предварительным тестам questdb требует в 20 раз больше места на диске, чем victoriametrics

а в чем профит тогда ?

в sql

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

Кто-нибудь сталкивался с проблемой синхронизации alertmanager следующего рода:
после запуска инстанс пишет

level=info ts=2021-06-09T04:05:13.775Z caller=cluster.go:648 component=cluster msg="gossip not settled" polls=0 before=0 now=2 elapsed=2.000124256s
level=info ts=2021-06-09T04:05:21.774Z caller=cluster.go:632 component=cluster msg="gossip not settled but continuing anyway" polls=4 elapsed=9.998719927s

Сайленсы появляются в свежезапущенном инстансе мгновенно. Сами сработавшие алерты едут долго, минут 5. А потом в какой-то момент они просто пропадают в этом инстансе, и остаются только в других членах кластера, а в этом видно только No alert groups found и нормально синхронизированные сайленсы. В логе пусто.

Всем привет
не стартует прометеус, пишет invalidargument
c точно такими же флагами стартует на другой машинке
права на директорию которая указана storage.tsdb.path и на конфиги все у prometheus:prometheus
что может быть?

разве что на /usr/share/prometheus овнер рут, но там 755
это может влиять?

версия prometheus одинаковая на обоих машинах?

да

я ловил такую ошибку, поменял овнера на директорию для бд и у меня взлетело
на проде могу только по заявке что-то менять -_-