Grafana + VictoriaLogs
Loki Proxy for VictoriaLogs
Use Grafana's native Loki datasource, Explore, and Logs Drilldown with VictoriaLogs. No plugin required.
What this project actually solves
Loki-VL-proxy exists for teams that want VictoriaLogs as the backend while preserving Grafana and Loki client workflows that already assume the Loki HTTP API.
Keep Grafana workflows intact
Grafana continues to use the native Loki datasource, Explore, and Logs Drilldown paths. The proxy handles the read-side compatibility and translation work in the middle.
Expose VictoriaLogs safely
VictoriaLogs remains the source of log data while the proxy shapes labels, metadata, patterns, rules, and alerts views into Loki-like contracts where those contracts matter.
Handle dotted OTel fields
The project supports translation profiles for dotted VictoriaLogs fields and Loki-safe underscore labels so operators can keep Grafana usable without giving up native field semantics upstream.
Make the proxy observable
Route-aware metrics and structured logs break out client latency, proxy overhead, upstream slowness, and cache behavior so the translation layer does not become a blind spot.
Practical operator guides
These pages are written as real deployment and migration playbooks, not just keyword landing pages. They map directly onto the docs, chart recipes, cache model, and observability surface the project already ships.
Run Loki-VL-proxy
Start with a local binary or container, prove the Loki-compatible read path, and verify readiness before any Grafana cutover.
Set Up the Grafana Datasource
Keep Grafana on the native Loki datasource and point it at the proxy, then validate translation, labels, metadata, and latency.
Install with Helm
Choose the right chart topology for day one: basic Deployment, StatefulSet with disk cache, or multi-replica peer-cache fleet.
Monitor the Proxy
See downstream, proxy, cache, and upstream behavior with route-aware metrics, logs, and runtime resource signals.
Compare Cost and Performance
See what Loki docs, VictoriaLogs docs, third-party benchmarks, and the proxy cache model actually support about savings.
Migrate from Loki
Use a parallel datasource path, validate Grafana workflows, and cut over only after route-aware checks are green.
Use Cache and Fleet Cache
Understand how Tier0, local cache, disk cache, peer cache, and long-range window reuse reduce repeated backend work.
Search-focused entry points
These pages answer the exact discovery queries operators and Grafana users search for when they are trying to make VictoriaLogs work behind Loki-compatible tooling.
Loki Proxy for VictoriaLogs
The core deployment pattern: put a Loki-compatible read proxy in front of VictoriaLogs so Grafana and Loki API clients stay unchanged.
Grafana Loki Datasource for VictoriaLogs
Exact datasource-level answer for teams searching how to use VictoriaLogs without building a custom Grafana plugin.
Grafana Explore with VictoriaLogs
How query_range, labels, label values, and latency or cache visibility behave when Grafana Explore sits on top of the proxy.
VictoriaLogs with Grafana Loki Datasource
The deployment pattern for keeping Grafana on the Loki datasource while routing reads through Loki-VL-proxy into VictoriaLogs.
Logs Drilldown with VictoriaLogs
Patterns, detected fields, service buckets, and the compatibility contracts that keep Grafana Logs Drilldown usable on VictoriaLogs.
LogQL on VictoriaLogs
Translation modes, dot-versus-underscore semantics, and the limits you need to understand before treating VictoriaLogs as a Loki read backend.
Loki vs VictoriaLogs for Grafana Query Workflows
Operational comparison of a native Loki backend versus VictoriaLogs routed through Loki-VL-proxy for Grafana query paths.
VictoriaLogs vs Loki Cost and Performance
Source-backed comparison of indexing model, high-cardinality posture, operational shape, and the extra savings levers from the proxy.
The path operators actually run
Keep the path simple: clients and Grafana on the left, the compatibility and cache layer in the middle, VictoriaLogs and optional rules backends on the right.
Why operators keep this layer visible
The proxy is not just a protocol adapter. It carries compatibility contracts, latency, and cache behavior that need to be observed as a real production component.
Compatibility is explicit, not implied
The project keeps separate compatibility tracks for Grafana Loki datasource behavior, Logs Drilldown, and VictoriaLogs runtime bands. CI exercises the contracts instead of relying on vague claims.
Translation stays bounded
Route-aware metrics, structured logs, tuple contracts, and label or metadata translation modes are built so operators can see where the proxy adds work and where it passes VictoriaLogs behavior through safely.
Caching is part of the product surface
Tier0 compatibility cache, in-memory cache, disk cache, and optional peer or fleet cache are first-class operational levers, not hidden implementation details.
Observability follows the runtime path
The packaged dashboard follows Client -> Proxy -> VictoriaLogs and breaks out route, latency, errors, cache efficiency, and operational resources for both Prometheus pull and OTLP push setups.
Start from the practical guides, then drop into the deep docs
The landing pages should get you to the right operating model fast. The deep docs still cover exact flags, compatibility matrices, benchmarks, scaling decisions, and runbooks.