Slow queries do not need more telemetry, they need three metrics you can page on

A guide published on the CNCF blog opens by rejecting the reflex response to slow SQL: the traditional fix is to collect more telemetry, and more telemetry means more things to look at, not necessarily more understanding ^[1]. Its alternative is narrow enough to be testable, which is why it matters: take OpenTelemetry database spans and distil them into span-derived metrics you can put on a dashboard and alert on ^[2].

The framing worth stealing is the phrase "the moment of decision." The authors argue teams should be opinionated about what matters then, rather than treating traces as a stream someone might analyse someday, and that raw telemetry only becomes useful once meaningful patterns are extracted from it ^[3]. That argument is developed in a companion talk by Endre Sara on managing telemetry overload ^[4]. Collection is the cheap part of the pipeline to buy and the expensive part to keep. Decision is the part nobody budgets for.

The guide reduces the problem to two questions: which queries yield the most value if made faster, weighted by traffic, and which queries are behaving abnormally right now ^[5]. The lab it describes is staged in that order, from simple slow query detection, to traffic-weighted impact, to anomaly detection ^[6]. Note what is absent: a general-purpose query explorer.

Traffic weighting earns its place because "slow" is not one number. A 50ms query can be fine for a reporting dashboard and catastrophic for checkout ^[7], and the guide catalogues causes that need different fixes: excessive work from missing or unusable indexes, resource contention from locks and connection pool exhaustion, environmental pressure such as CPU saturation and I/O bottlenecks, and plan regressions from parameter-sensitive plans or stale statistics after bulk loads ^{[8][9][10][11]}. Its scaling example is the one to keep: without an index on customer_id, a single-predicate SELECT on orders goes from 20ms at 10K rows to minutes at 10M rows, with the query unchanged and only the data volume moving ^[12], a thousandfold increase in rows ^[13]. A query spending 95% of its time waiting on locks is not fixed by query optimisation, it needs transaction redesign ^[9].

Then there is the case that breaks threshold alerting outright. The N+1 pattern runs 100 queries at 2ms each in sequence, adding 200ms plus network overhead, and no individual query is slow ^[14]. Any slow-query threshold above 2ms logs none of those 100 queries while the user waits 200ms ^[15]. Databases ship good tools here, including slow query logs, pg_stat_statements and EXPLAIN, but they report what is expensive inside the database, not which service triggered it, whether it is user-facing or background, or whether it correlates with the latency spike under investigation ^[16][17]. The usual bridge is a human one: a developer notices a slow endpoint and takes the query to a DBA ^[18]. The guide's claim is that this manual linking is the automatable part ^[18].

What to watch: whether the traffic-weighted metric actually displaces that developer-to-DBA handoff, and whether the anomaly detection stage, which the guide sequences last, survives contact with real traffic patterns ^[6][18].