🚨 VictoriaMetrics Error: 'cannot parse labels' — Cause, Fix, and Troubleshooting Guide

Overview

When VictoriaMetrics ingests Prometheus text-exposition data — whether scraped from a /metrics endpoint or pushed to /api/v1/import/prometheus — it parses each line into a metric name, label set, value, and optional timestamp. If a label value is not wrapped in double quotes, the parser cannot tell where the value ends and rejects the sample:

cannot parse labels "http_requests_total{method=GET,code=200}": missing quotes for label value; got "GET"

The Prometheus exposition format requires every label value to be a double-quoted string: {method="GET",code="200"}. An exporter emitting {method=GET} is producing invalid text, and VictoriaMetrics (like Prometheus itself) refuses it rather than guessing. This is a producer-side formatting bug or a mismatch between the payload you are sending and the endpoint you are sending it to.

Symptoms

• Ingest logs show cannot parse labels ...: missing quotes for label value and the offending sample is dropped.
• A specific exporter’s series never appear, while other targets scrape cleanly.
• A custom push script to /api/v1/import/prometheus returns an error on some or all lines.
• The bad sample renders fine to the human eye but is missing quotes, unescaped, or posted in the wrong format.
• promtool check metrics on the exporter’s output flags the same line.

Common Root Causes

• Unquoted label values — the exporter emits {method=GET} instead of {method="GET"}.
• Malformed exposition text — hand-built or templated /metrics output that does not conform to the Prometheus text format.
• Bad escaping — a label value containing a quote or backslash that was not escaped (\", \\), breaking the tokenizer.
• Wrong import endpoint — sending Prometheus text to a JSON/CSV/Influx importer (or vice-versa), so the parser applies the wrong grammar to the payload.

How to diagnose

Validate the exporter’s raw output with promtool, which uses the same exposition grammar VictoriaMetrics expects:

# Fetch and lint the exporter's exposition text
curl -s 'http://localhost:9100/metrics' > /tmp/metrics.txt
promtool check metrics < /tmp/metrics.txt

Isolate the failing line and post just it to confirm the fix before reprocessing a full payload:

# A correctly quoted sample should ingest cleanly
printf 'http_requests_total{method="GET",code="200"} 42\n' \
  | curl -s --data-binary @- 'http://localhost:8428/api/v1/import/prometheus'

If the same bytes fail, grep the payload for unquoted values — the classic tell is an = immediately followed by a non-quote character inside the braces ({method= rather than {method=").

Fixes

1. Quote every label value. The correct form is {method="GET",code="200"}. Fix the exporter or the code generating the exposition text so every value between the braces is a double-quoted string.

2. Correct the exporter output. If a custom or hand-rolled exporter is emitting invalid text, bring it into line with the Prometheus text-exposition format — quoted values, one sample per line, and properly escaped special characters (\", \\, \n).

3. Post to the endpoint that matches your format. Prometheus text goes to /api/v1/import/prometheus; do not send it to the JSON, CSV, or Influx importers. Route each payload to the import endpoint built for its format:

# Prometheus exposition text -> the prometheus importer, on single-node 8428
curl -s --data-binary @metrics.txt \
  'http://localhost:8428/api/v1/import/prometheus'

4. Lint in CI. Add promtool check metrics against the exporter’s /metrics output to your pipeline so unquoted or malformed labels are caught before they reach ingestion.

What to watch out for

• The error names the exact substring it choked on (got "GET") — read it literally to find the offending label instead of guessing.
• One bad line only drops that sample, so a partly-broken exporter can silently lose a subset of series while looking healthy overall.
• Quotes and backslashes inside a value must be escaped; an unescaped quote produces the same parse failure even when the outer quoting looks correct.
• Sending a valid-but-wrong format (e.g. Influx line protocol) to the Prometheus importer yields parse errors too — match payload to endpoint first.

Related

• VictoriaMetrics Error Guide: cannot parse MetricsQL
• VictoriaMetrics Error Guide: cannot parse timestamp
• VictoriaMetrics Error Guide: promscrape maxScrapeSize