Grafana Explore
Keep Grafana Explore usable on top of VictoriaLogs
Grafana Explore depends on more than a single query endpoint. It needs label discovery, route consistency, stable field semantics, and enough visibility to see whether slowness is coming from the client path, the proxy, cache misses, or VictoriaLogs itself.
What Explore users feel first
Slow query_range calls, missing label values, and inconsistent field semantics show up in Explore immediately. The proxy exposes those user-facing paths with normalized routes so they can be monitored instead of guessed at.
What operators should inspect
Use the route-aware request metrics to separate downstream client latency from upstream VictoriaLogs latency, and use cache-hit or cache-miss views to see whether expensive browsing paths are staying warm enough.
The Explore paths worth watching
Latency
Compare end-to-end request latency with backend-only latency. The difference is where translation work, shaping, coalescing, and cache lookup time live.
Errors
Separate client-side bad requests from upstream failures. That keeps Grafana builder regressions distinct from VictoriaLogs or network pain.
Cache efficiency
Explore tends to stress repeated metadata browsing. Route-aware hit and miss metrics are what tell you whether labels, field values, and query paths should be tuned or warmed differently.
Translation profile drift
If users click dotted OTel fields in Explore, validate whether your deployment should stay in a hybrid metadata mode or fully translated mode. The wrong choice shows up as broken click-to-filter behavior.