Есть несколько моментов, которые включены в третьем проме, но не поддерживаются в промпп:
1. Нативные гистограммы
2. Экземпляры
3. Скрейп в формате протобафа
4. Пуш в формате open-telemetry
Если ничего из этого у вас не используется, то можно переключаться. Промпп читает и продуцирует блоки ванильного прома и поддерживает для чтения блоки третьего прома, а производит блоки второго. Так что можно будет переключиться и туда, и вернуться обратно на третий пром
Evgeniy BastrykovЕсть несколько моментов, которые включены в третьем проме, но не поддерживаются в промпп:
1. Нативные гистограммы
2. Экземпляры
3. Скрейп в формате протобафа
4. Пуш в формате open-telemetry
Если ничего из этого у вас не используется, то можно переключаться. Промпп читает и продуцирует блоки ванильн
Спасибо за подробный ответ
Slava RaФотография
Фотография
нажмите — покажем
нажмите — покажем
Заработало! 🥳 Чтобы "вырезать лишние лэйблы" надо было использовать не relabel_configs, а metric_relabel_configs 😋🙈
https://www.robustperception.io/relabel_configs-vs-metric_relabel_configs/
Slava RaЗаработало! 🥳 Чтобы "вырезать лишние лэйблы" надо было использовать не relabel_configs, а metric_relabel_configs 😋🙈
https://www.robustperception.io/relabel_configs-vs-metric_relabel_configs/
точно! Постоянно забываю про это. relabel_configs применяются к лейблам таргетов
Ссылка
нажмите — покажем
нажмите — покажем
Всем привет! Сегодня вышел очередной релиз — v0.8.4.
В этой версии добавили в prompptool команду persist-head — она умеет
записать отдельный head в TSDB-блоки прямо по пути к его каталогу,
без обращения к head.log. Удобно, когда нужно восстановить или сохранить
конкретный (например, повреждённый) head при разборе инцидента. Заодно
поправили работу с диском: при старте теперь подчищаются «хвосты» временных
каталогов блоков после прерванной компакции, а запись блоков пропускает
те, что целиком уже вышли за период хранения, — меньше лишних записей.
По памяти и наблюдаемости тоже подкрутили: буфер индекса для блоков теперь
выделяется лениво, что заметно снижает потребление памяти при персисте головы с данными за большой промежуток времени. Появился HTTP-эндпоинт /debug/jemalloc — снимает
heap-профиль jemalloc по запросу (нужно запустить процесс с
`MALLOC_CONF="prof:true"`), удобно для диагностики роста памяти в C++-ядре.
А новая метрика prompp_localstorage_unknown_bytes показывает суммарный размер неизвестных объектов на диске, чтобы корректнее оценивать ретеншен по месту.
Из важного по стабильности — починили редкое падение (heap-buffer-overflow)
в обработчике устаревших чанков. И обновили Go до 1.26.5, закрыв несколько CVE.
Релиз: https://github.com/deckhouse/prompp/releases/tag/v0.8.4
Ссылка
нажмите — покажем
нажмите — покажем
Всем привет! Сегодня вышел очередной релиз — v0.8.5.
Главное — починили определение модели процессора. Раньше из‑за слишком ранней инициализации движок всегда выбирал самый базовый набор инструкций, даже на современных CPU, и работал медленнее, чем мог бы. Теперь флейвор процессора определяется корректно, так что на новых CPU вы получаете более быстрые пути обработки «из коробки».
Ещё ускорили разбор метрик при скрейпе и снизили пиковое потребление памяти при приёме данных — снапшот транзакции теперь освобождается сразу после коммита. Плюс закрыли неприятный баг с обращением к уже освобождённой странице внутренних метрик движка C++ во время скрейпа, который в редких случаях мог приводить к порче памяти. В прошлом релизе эти метрики были отключены до устранения ошибки, теперь вернули обратно.
И, как обычно, подтянули обновления безопасности в зависимостях (golang.org/x/net, x/text, grpc и несколько пакетов web‑UI).
Релиз: https://github.com/deckhouse/prompp/releases/tag/v0.8.5
Подробнее — в [CHANGELOG](https://github.com/deckhouse/prompp/blob/release-0.8/CHANGELOG.md).
Ссылка
нажмите — покажем
нажмите — покажем
Ребят, привет!
Не знаю уместно ли писать в чатике или лучше через гитхаб, но в версии v0.8.1 получаю такую ошибку в конфигурации с thanos-sidecar:
{"caller":"pp_handler.go:183","component":"pp_handler","err":"void prompp_wal_protobuf_hashdex_snappy_presharding(void*, void*): Exception f666cea4f74038c7: Max Label Names count per Timeseries limit exceeded\u0000","level":"error","msg":"failed processing remote_write","ts":"2026-07-16T14:21:45.632Z"}
И похоже, что часть блоков в S3 не уезжает. Похоже на вот этот issue - https://github.com/deckhouse/prompp/issues/176, я туда отписал, но не уверен, что связано, если честно.
Куда можно покопать?
Evgeniy BastrykovПривет! Это ошибка приёма метрик по протоколу remote write. Собственно превышен лимит по количеству пар лейблов в серии
Так, забираю свои слова про thanos-sidecar и блоки пока 😀 remote-write у меня действительно есть, тогда подожду ответа куда копать тут - потому что на ванильном проме я не замечал никаких проблем до переключения.
привет, мне тоже помогите советом или дайте направление куда копать, пожалуйста. есть около 10 кластеров, которые через remoteWrite пишут метрики в prometheus сервер и все работает хорошо. понадобилось подключить еще кластер и с ним проблемы (настроен идентично другим кластерам через argo application set)
лог на prometheus agent
prometheus {"caller":"logger.go:31","component":"pp","level":"error","msg":"failed to send protobuf: Post \"http://prometheus-server-domain:9090/api/v1/write\": context deadline exceeded","pp_caller":"iterator.go:363","ts":"2026-07-24T13:16:38.361Z"}
на prometheus
Jul 24 16:13:36 prometheus-server-domain prometheus[378131]: ts=2026-07-24T13:13:36.524Z caller=pp_handler.go:183 level=error component=web component=pp_handler msg="failed processing remote_write" err="read tcp 10.110.10.6:9090->10.20.12.3:57420: read: connection reset by peer"
толи надо тюнить параметры remoteWrite, но с наскока не получилось исправить. толи с сетью проблемы... но prometheus сервер спокойно сам ходит на ноды этого кластера и забирает метрики с самих нод. а в другую сторону по remoteWrite нет метрик
Evgeniy Bastrykovс сетью или промежуточными прокси. По сути он отправлял-отправлял, но не отправил
вот тоже подозрение такое. они связаны через впн, наверно туда копать нужно
Evgeniy Bastrykovможно попробовать уменьшить maxSamplesPerSend, но там и так 2К по умолчанию, это обычно несколько КБ сообщение, даже не десятков. Тут как будто соединение установилось, но данные не прошли
- url: http://{{metadata.labels.prom_host}}:9090/api/v1/write
queueConfig:
minShards: 10
maxShards: 100
capacity: 30000
maxSamplesPerSend: 10000
minBackoff: 1s
maxBackoff: 5s
сейчас такой конфиг для всех агентов. с дефолтами была проблема, что зависал сервер, когда агенты интенсивно писали в него. это наверно нейросетью делал, может и галлюцинация, но работает
Ссылка
нажмите — покажем
нажмите — покажем
Всем привет! Сегодня вышел очередной релиз — v0.8.6.
Под нагрузкой запросов память могла раздуваться: буферы результатов запросов жили дольше, чем нужно, и копились. Теперь они освобождаются сразу после построения ответа — пики памяти на query path должны стать спокойнее.
Починили неприятных багов:
- ActiveQueryTracker больше не ловит SIGBUS на sparse-файле лога активных запросов;
- при отключённых per-DataStorage метриках убрали гонку при создании хранилищ, которая могла приводит к SIGILL на устаревших процессорах.
Ещё чуть ускорили чтение WAL-сегментов — буферы переиспользуются из пула вместо аллокаций на каждом чтении.
Релиз: https://github.com/deckhouse/prompp/releases/tag/v0.8.6
Подробнее — в CHANGELOG.
Ссылка
нажмите — покажем
нажмите — покажем
Всем привет! Сегодня вышел очередной релиз — v0.8.7.
Главное — починили парсинг при очень больших ответах (> 4GB).
Заметно поработали над памятью и скоростью. Запросы по индексу серий стали экономнее по аллокациям — особенно там, где в запросе много матчеров. На некоторых запросах ускорение до 30%. Разбор скрейпов ускорился за счёт обновлённого генератора токенизаторов. Сборщик мусора для объектов, живущих в C++, но принадлежащих Go, перенастроен так, чтобы освобождать память заметно раньше под растущей нагрузкой. И отдельно: при большом количестве групп правил (от тысячи и выше) процесс раньше заводил столько арен аллокатора, что тот сам начинал притормаживать — теперь короткоживущие хранилища создаются без арен, которые им всё равно не давали выигрыша.
Также обновили веб-зависимости postcss и sanitize-html, закрыв известные уязвимости.
Релиз: https://github.com/deckhouse/prompp/releases/tag/v0.8.7
Подробнее — в CHANGELOG: https://github.com/deckhouse/prompp/blob/release-0.8/CHANGELOG.md