deckhouse/prompp v0.8.15

on GitHub

Features

1. Head IDs are now generated as UUIDv7. catalog.DefaultIDGenerator returns a UUIDv7 instead of a random UUIDv4, falling back to v4 if generation fails. A UUIDv7 starts with a millisecond timestamp, so head directories and catalog records now sort lexicographically in creation order, which makes reading the data directory and debugging much easier. The format is unchanged (RFC 4122, 36 characters), so existing heads, catalog records and log files need no migration (#519).
2. Prom++ can now report that it is running with a feature set other than the expected one. The new optional PROMPP_FEATURES_DEFAULT environment variable holds the expected set; at startup it is compared with PROMPP_FEATURES and the result is exposed as the prompp_features_differ_from_default gauge — 1 when they differ, 0 when they match — registered only when the variable is set. A mismatch is also logged at warn level with added / removed / changed fields, so it is clear what exactly drifted. The comparison ignores order, whitespace and empty tokens and compares values by meaning: default_sample_age_limit=60m equals =1h, head_read_concurrency equals head_read_concurrency=1 (#523).

Fixes

1. A scrape target serving a malformed native histogram over protobuf could crash Prom++. ProtobufParser.Histogram() calls Compact(0) before anything validates the payload, and compactBuckets assumed the span lengths add up to the bucket count — a histogram with buckets behind only zero-length spans walked past the end of the span slice and panicked (found by FuzzParseProtobuf). Compaction is now skipped whenever the spans don't cover exactly as many buckets as the histogram has, and the histogram goes on to Validate(), which rejects it with ErrHistogramSpansBucketsMismatch; nothing is dropped or rewritten silently. Upstream Prometheus guards only the case where every span is zero-length (#520).
2. A head.log migration would have wiped the catalog. createSwapFile opened the swap file O_WRONLY, but after a migration or a compaction that file becomes the working FileLog and has to be readable too: catalog.sync read right after NewFileLog, got bad file descriptor, concluded the log was corrupted and overwrote head.log with an empty one — losing the active head, the rotated heads not yet persisted and the remote write positions. It never fired in production, because the log is opened as V2 and no migration takes place, but it blocked moving head.log to V3 (#518).
3. moment updated to 2.31.0 in the web UI, closing GHSA-4p3w-j4w9-5jqw — a path traversal through a crafted non-string locale name.

Performance

1. A rotated head no longer carries its ingestion lookup structures until retention. They are released in two stages, each at the earliest safe point. On rotation, once the old head is read-only, the label set → ls id hash set and the relabeler input LSS are freed: only relabeling on the active head and the shrink during the added-series copy need them, and both are finished by then. After a successful persist, the sorted ls id set is freed as well — it has to survive until the block is written, because ChunkRecoder and RevertableLoader iterate it, and it is kept for the retry if the persist or the status update fails. Rotated heads loaded from disk on restart skip the rotator but still free both. These structures cost several bytes per series per LSS and used to stay allocated while the new active head was already growing, so this lowers both the peak right after rotation and the steady-state memory of every rotated head (#522, #527).
2. Rotation no longer makes the first commit of the new head expensive. The first WAL segment of a new head holds the label sets of every series copied from the old head, so finalizing it costs far more than a regular commit — and it used to happen on the first Commit of the already active head, through fastcgo (which occupies the P for the whole call, blocking the Go scheduler and delaying GC stop-the-world) while holding the WAL encoder lock and the LSS read lock, i.e. blocking both the ingest path and new series. That segment is now committed, flushed and synced for every shard right after the added series are copied, before the new head goes live, through a regular cgo call that releases the P. Shards run concurrently, up to GOMAXPROCS at a time; a failure is logged and rotation continues. Rotation itself takes longer as a result, while the old head keeps accepting writes. The new prompp_rotator_head_wal_encoder_long_finalize_duration_nanoseconds metric reports the longest such call (#525).
3. Encoding became about 10% faster. The combined Gorilla path is gone from DataStorage — every encoder now keeps timestamps and values in separate streams. The Gorilla codec itself stays and is still used elsewhere. The prompp_data_storage_gorilla_count metric is removed along with the path (#515).
4. Rebuilding the sorting index no longer scans the whole B-tree. The maximum ls id used to be found by walking the tree; the bound now comes from QueryableEncodingBimap, which already knows it as next_item_index(). Build, rebuild and sort take an exclusive ls id bound, so the index size always matches the id space that update() appends to (#516).