Grafana Logs Drilldown
Keep Grafana Logs Drilldown working with VictoriaLogs
Logs Drilldown is stricter than generic Loki clients. It depends on specific datasource resources, service buckets, detected fields, field values, and pattern grouping. Loki-VL-proxy treats those as explicit compatibility contracts rather than hoping generic query compatibility is enough.
What Drilldown needs beyond basic queries
- Datasource resource endpoints used by the app scenes.
- Service-selection buckets and service-detail volume views.
- Detected fields and detected field values that do not leak the wrong label surfaces.
- Pattern grouping responses with non-empty grouped payloads.
Why this is a separate compatibility track
Logs Drilldown is opinionated around its own runtime and contract expectations. The project therefore keeps a dedicated compatibility track rather than assuming a generic Loki datasource pass means the Drilldown experience is safe.
The operational view you want during rollout
Drilldown regressions often show up in metadata and pattern paths before they show up in raw query results. That is why route-specific rates, latency, errors, and cache efficiency matter here as much as generic request totals.
Patterns latency and errors
Patterns are a separate contract now, with explicit runtime gating. Watch them like a product feature, not an optional side path.
Field discovery cache efficiency
Detected fields and field values should be warm enough that the app does not repeatedly force expensive scans for the same service or filter combinations.
Service-name correctness
Volume endpoints and service buckets depend on consistent service naming. That behavior is explicitly tested because wrong service buckets degrade the whole app flow.
Upstream versus proxy cost
If Drilldown feels slow, split the blame. The observability model can distinguish backend latency from proxy-side shaping or metadata work.