Skip to main content

Query semantics

Run LogQL-style read workflows on VictoriaLogs

Loki-VL-proxy does not claim that VictoriaLogs is natively Loki. It provides a controlled read-side translation layer so LogQL-oriented clients can keep working while operators stay explicit about field naming, metadata surfaces, and compatibility limits.

Label style control
Choose underscore or passthrough label behavior on label-facing APIs
Useful for Loki-safe UX.
Metadata field mode
Native, translated, or hybrid field surfaces are explicit
Important for dotted OTel fields.
Custom mapping
Field mappings let you pin non-standard schemas to stable aliases
Good for dashboards and alerts.
Known limits stay documented
The project documents the surfaces it translates and the ones it leaves out
No hidden magic.

How to think about compatibility

Treat the proxy as a read compatibility layer, not as proof that the storage engines are identical. The right operational question is whether the specific query, label, field, and metadata surfaces your clients use are covered and observable.

Where translation shows up

Translation affects stream labels, label APIs, detected fields, structured metadata, and alias resolution for dotted and underscore field names. Those surfaces can be tuned independently.

The translation profiles that matter most

Loki-first

Use underscore label style and translated metadata fields when users mainly live in Grafana builder paths and want the most Loki-like experience.

Balanced compatibility

Use underscore labels with hybrid metadata fields when you need both Grafana-friendly label ergonomics and dotted OTel correlation.

OTel-native field workflows

Keep label surfaces Loki-safe while exposing dotted field names on field-oriented APIs if your operators reason in OTel-native terms.

Custom schema mapping

Use explicit field mappings when your backend schema does not follow common OTel conventions and you need stable aliases for dashboards, alerts, or client tooling.

Current differences to plan for

The current codebase supports the read path broadly, but a few boundaries are still important if you want predictable Grafana and Loki-client behavior.

Read compatibility, not generic Loki identity

The proxy keeps Loki-facing reads usable on VictoriaLogs. It does not turn VictoriaLogs into a native Loki backend, and it does not open the normal Loki write path.

Dotted fields still need explicit UX choices

Underscore labels and dotted field APIs can coexist, but Grafana builder flows are still safer when operators use the underscore aliases for click-to-filter paths.

Some compatibility work stays in the proxy

Parser compatibility, formatting helpers, alias resolution, and parts of binary or subquery behavior still run in the proxy. They are supported, but they are not zero-cost native VictoriaLogs operations.

Patterns and parsed fields have warm-state caveats

`/patterns` is optional and capped per request, and parsed-only field discovery can still rely on bounded sampling when there is no safe indexed metadata path.