asap-query-engine: embedded always-on query tracker for passive auto-discovery #240

Problem

Today, sketch configurations must be generated upfront via asap-planner-rs before asap-query-engine can accelerate any queries. This requires users to manually collect a query workload and run the planner — a significant friction point for drop-in deployment.

Goal

asap-query-engine should passively observe all incoming PromQL queries, maintain a running frequency count, and trigger sketch configuration for queries automatically — without any manual user intervention.

Details

asap-query-engine sits in the request path between Grafana and Prometheus, so it sees every query. It should:

• Record each unique PromQL expression and its frequency in an in-memory (or lightweight on-disk) store
• For a configurable observation window or query count threshold, record all queries
• Pass those queries to asap-planner-rs (as a library — see related issue) to generate sketch configs
• Trigger asap-summary-ingest pipeline creation and asap-query-engine self-reconfiguration
• Continue proxying all queries to Prometheus until sketches are ready, then seamlessly serve accelerated responses

Configuration knobs (with sensible defaults):

• Observation window before first auto-config (e.g. 10 minutes)
• Minimum query frequency threshold
• Max number of queries to accelerate simultaneously

Acceptance Criteria

• A fresh asap-query-engine deployment with no config accelerates queries automatically after the observation window
• No queries are dropped or errored during the observation and reconfiguration phases
• The tracker adds <5ms overhead to proxied query latency

Notes

Depends on: embed asap-planner-rs as library, asap-query-engine programmatic control of asap-summary-ingest, runtime reconfiguration issues.