fix(catalog-backend): cache and cheapen catalog_entities_count metric
The legacy Prometheus and OpenTelemetry observable gauges previously each ran the per-kind count query against the search table on every metrics scrape. With multiple pods and short scrape intervals, identical sequential scans piled up faster than they completed, contending for buffers in the database. Extract a shared helper that wraps a 30-second TTL cache around a single query, and have both gauges read from it. The query itself moves from the (large) search table to final_entities, parsing kind out of entity_ref via per-engine substring functions. The emitted labels and values are unchanged. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> Signed-off-by: Fredrik Adelöw <freben@spotify.com>
This commit is contained in:
@@ -0,0 +1,9 @@
|
||||
---
|
||||
'@backstage/plugin-catalog-backend': patch
|
||||
---
|
||||
|
||||
Improved the performance of the `catalog_entities_count` metric.
|
||||
|
||||
The legacy Prometheus and OpenTelemetry observable gauges previously each ran their own copy of the per-kind count query against the `search` table on every metrics scrape. On large catalogs this could pile up faster than the queries completed, contending for buffers and stalling the database.
|
||||
|
||||
The two callbacks now share a single query result with a short in-process TTL cache, and the underlying query reads from `final_entities` instead of `search`, avoiding the bitmap heap scans that dominated the previous form. The emitted labels and values are unchanged.
|
||||
Reference in New Issue
Block a user